Praktik terbaik Kubernetes. Memetakan layanan eksternal

Praktik terbaik Kubernetes. Membuat Kontainer Kecil
Kubernetes Praktik Terbaik. Organisasi Kubernetes dengan Kubernetes
Best Practices Namespace. Uji Kelayakan Kubernetes dengan Tes Kesiapan dan Uji Kekuatan
Praktik Terbaik Kubernetes . Mengatur Kueri dan Batas Sumber Daya
Praktik Terbaik Kubernetes. Pemutusan yang benar dari Terminate

Jika Anda seperti kebanyakan orang, kemungkinan besar Anda menggunakan sumber daya yang beroperasi di luar cluster Anda. Anda mungkin menggunakan Taleo API untuk mengirim pesan teks atau menganalisis gambar menggunakan Google Cloud Vision API.

Jika Anda menggunakan titik akhir yang sama - titik penerimaan permintaan sisi server di semua lingkungan Anda dan tidak berencana untuk mentransfer server Anda ke Kubernetes, maka sangat normal untuk memiliki layanan titik akhir langsung dalam kode Anda. Namun, ada banyak skenario lain. Dalam seri Praktik Terbaik Kubernetes ini, Anda akan belajar cara menggunakan mekanisme bawaan Kubernetes untuk menemukan layanan di dalam dan di luar cluster.

Contoh dari layanan eksternal yang tersebar luas adalah database yang berjalan di luar cluster Kubernetes. Tidak seperti basis data cloud seperti Google Cloud Data Store atau Google Cloud Spanner, yang menggunakan titik akhir yang sama untuk semua jenis akses, kebanyakan basis data memiliki titik akhir yang terpisah untuk keadaan yang berbeda.
Praktik terbaik untuk menggunakan database tradisional, seperti MySQL dan MongoDB, biasanya mengharuskan Anda untuk terhubung ke komponen yang berbeda untuk lingkungan yang berbeda. Anda mungkin memiliki mesin besar untuk data produksi dan mesin yang lebih kecil untuk lingkungan pengujian. Masing-masing dari mereka akan memiliki alamat IP atau nama domain sendiri, tetapi Anda mungkin tidak ingin mengubah kode Anda ketika berpindah dari satu lingkungan ke lingkungan lain. Oleh karena itu, alih-alih mengkodekan alamat-alamat ini, Anda dapat menggunakan layanan bawaan Kubernetes untuk menemukan layanan eksternal berbasis DNS dengan cara yang sama seperti untuk layanan asli Kubernetes.



Misalkan Anda menjalankan database MongoDB di Google Compute Engine. Anda akan terjebak di dunia hybrid ini hingga Anda berhasil mentransfernya ke sebuah cluster.

Untungnya, Anda dapat menggunakan layanan statis Kubernetes untuk membuat hidup Anda sedikit lebih mudah. Dalam contoh ini, saya membuat server MongoDB menggunakan Google Cloud Launcher. Karena dibuat di jaringan yang sama (atau kluster Kubernetes VPC), ini diakses menggunakan alamat IP internal berkinerja tinggi.



Ini adalah pengaturan default di Google Cloud, jadi Anda tidak perlu mengonfigurasi apa pun. Sekarang Anda memiliki alamat IP, langkah pertama adalah membuat layanan. Anda mungkin memperhatikan bahwa tidak ada penyeleksi perapian untuk layanan ini. Artinya, kami menciptakan layanan yang tidak akan tahu ke mana harus mengirim lalu lintas. Ini akan memungkinkan Anda untuk secara manual membuat objek titik akhir, yang akan menerima lalu lintas dari layanan ini.



Contoh kode berikut menunjukkan bahwa titik akhir menentukan alamat IP untuk database menggunakan nama mongo yang sama dengan layanan.



Kubernetes akan menggunakan semua alamat IP untuk menemukan titik akhir seolah-olah mereka adalah pod Kubernet biasa, jadi sekarang Anda dapat mengakses database menggunakan string koneksi sederhana ke nama di atas mongodb: // mongo. Namun, sama sekali tidak perlu menggunakan alamat IP dalam kode Anda.

Jika alamat IP berubah di masa mendatang, Anda dapat memperbarui titik akhir dengan alamat IP baru, dan aplikasi Anda tidak perlu diubah dengan cara tambahan apa pun.

Jika Anda menggunakan database yang dihosting pada host pihak ketiga, maka kemungkinan besar pemilik host memberi Anda URI pengidentifikasi sumber daya terpadu untuk koneksi. Jadi jika Anda diberi alamat IP, Anda cukup menggunakan metode sebelumnya. Contoh ini menunjukkan bahwa saya memiliki dua database MongoDB yang di-host pada host mLab.



Salah satunya adalah database pengembang, dan yang lainnya adalah database produksi. String koneksi untuk database ini adalah sebagai berikut - mLab memberi Anda URI dinamis dan port dinamis. Seperti yang Anda lihat, mereka berbeda.



Untuk mengabaikan ini, kami menggunakan Kubernetes dan terhubung ke database pengembang. Anda dapat membuat nama layanan Kubernetes eksternal, yang akan memberi Anda layanan statis yang akan mengarahkan lalu lintas ke layanan eksternal.



Layanan ini akan melakukan pengalihan CNAME tingkat kernel sederhana, yang akan memiliki dampak kinerja minimal. Berkat ini, Anda dapat menggunakan string koneksi yang lebih sederhana.



Tetapi karena nama eksternal menggunakan pengalihan CNAME, itu tidak dapat melakukan penerusan port. Oleh karena itu, solusi ini hanya berlaku untuk port statis dan tidak dapat digunakan dengan port dinamis. Tetapi Tier Gratis mLab gratis, secara default, memberikan pengguna dengan nomor port dinamis, dan Anda tidak dapat mengubahnya. Ini berarti bahwa untuk dev dan prod Anda memerlukan baris perintah koneksi yang berbeda. Kabar buruknya adalah Anda perlu meng-hard-code nomor port. Jadi, bagaimana Anda mendapatkan penerusan port untuk bekerja?

Langkah pertama adalah mendapatkan alamat IP dari URI. Jika Anda menjalankan perintah nslookup, nama host atau ping URI, Anda bisa mendapatkan alamat IP dari database. Jika pada saat yang sama layanan mengembalikan beberapa alamat IP kepada Anda, maka semua alamat ini dapat digunakan pada titik akhir objek.



Ingatlah bahwa IP URI dapat berubah tanpa pemberitahuan sebelumnya, sehingga cukup berisiko untuk menggunakannya dalam prod. Dengan menggunakan alamat IP ini, Anda dapat terhubung ke basis data jauh tanpa menentukan port. Dengan demikian, layanan Kubernetes melakukan penerusan port dengan cukup transparan.



Memetakan, atau memetakan sumber daya eksternal ke sumber internal, memberi Anda kemampuan untuk secara fleksibel menggunakan layanan ini di dalam cluster di masa depan sambil meminimalkan upaya refactoring. Ini juga memfasilitasi manajemen dan memberikan wawasan tentang layanan eksternal apa yang digunakan perusahaan Anda.

Akan dilanjutkan segera ...

Sedikit iklan :)

Terima kasih untuk tetap bersama kami. Apakah Anda suka artikel kami? Ingin melihat materi yang lebih menarik? Dukung kami dengan melakukan pemesanan atau merekomendasikan kepada teman Anda VPS berbasis cloud untuk pengembang mulai $ 4,99 , analog unik dari server entry-level yang diciptakan oleh kami untuk Anda: Seluruh kebenaran tentang VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps mulai dari $ 19 atau cara membagi server? (opsi tersedia dengan RAID1 dan RAID10, hingga 24 core dan hingga 40GB DDR4).

Dell R730xd 2 kali lebih murah di pusat data Equinix Tier IV di Amsterdam? Hanya kami yang memiliki 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV dari $ 199 di Belanda!Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - mulai dari $ 99! Baca tentang Cara Membangun Infrastruktur Bldg. kelas c menggunakan server Dell R730xd E5-2650 v4 seharga 9.000 euro untuk satu sen?