Ringkasan jaringan layanan

Halaman ini menjelaskan cara men-deploy Layanan di Google Kubernetes Engine (GKE). Gunakan halaman ini sebagai panduan untuk lebih memahami faset jaringan Layanan dan fitur jaringan Layanan yang ada di GKE.

Ringkasan jaringan layanan

Jaringan layanan adalah publikasi aplikasi dengan suatu cara yang memisahkan kepemilikan, implementasi, atau lingkungan dasar dari aplikasi yang sedang digunakan oleh klien. Dalam bentuknya yang paling sederhana, Layanan adalah endpoint yang aman, konsisten, dan tersedia yang digunakan untuk mengakses aplikasi.

Klien dan aplikasi memiliki kebutuhan yang beragam akan cara mereka dapat dan seharusnya berkomunikasi. Hal ini sesederhana mengekspos aplikasi Anda di cluster Kubernetes untuk digunakan oleh Pod, atau serumit mengarahkan traffic ke aplikasi Anda dari klien internet di seluruh dunia. GKE menyediakan banyak cara untuk mengekspos aplikasi sebagai Layanan yang sesuai dengan kasus penggunaan unik Anda.

Elemen Layanan

Mengekspos aplikasi ke klien melibatkan tiga elemen utama Layanan:

  • Frontend: Frontend load balancer menentukan cakupan yang memungkinkan klien mengakses dan mengirim traffic ke load balancer. Frontend adalah lokasi jaringan yang memproses traffic data. Layanan ini memiliki jaringan, region tertentu (atau subnet dalam jaringan), satu atau beberapa IP dalam jaringan, port, protokol tertentu, dan sertifikat TLS yang ditampilkan untuk membuat koneksi aman.

  • Perutean dan load balancing: Perutean dan load balancing menentukan cara Anda memproses dan merutekan traffic. Anda dapat mengarahkan traffic ke Layanan berdasarkan parameter seperti protokol, header HTTP, dan jalur HTTP. Bergantung pada load balancer yang Anda gunakan, load balancer mungkin menyeimbangkan traffic untuk memberikan latensi yang lebih rendah dan peningkatan ketahanan kepada pelanggan Anda.

  • Backend: Backend load balancer ditentukan oleh jenis endpoint, platform aplikasi, dan integrasi penemuan layanan backend. GKE menggunakan integrasi penemuan layanan untuk memperbarui backend load balancer secara dinamis saat endpoint GKE muncul dan turun.

Diagram berikut mengilustrasikan konsep ini untuk traffic internal dan eksternal:

Dalam diagram ini, Load Balancer Aplikasi eksternal memproses traffic di internet publik melalui ratusan titik kehadiran Google di seluruh dunia. Frontend global ini memungkinkan traffic dihentikan di edge, yang dekat dengan klien, sebelum melakukan load balancing traffic ke backend-nya di pusat data Google.

Load Balancer Aplikasi internal memproses dalam cakupan jaringan VPC Anda sehingga komunikasi pribadi dapat terjadi secara internal. Properti load balancer ini membuatnya cocok untuk berbagai jenis kasus penggunaan aplikasi.

Memahami load balancing GKE

Untuk mengekspos aplikasi di luar cluster GKE, GKE menyediakan pengontrol GKE Ingress dan pengontrol Layanan GKE bawaan yang men-deploy load balancer atas nama pengguna GKE. Ini sama dengan infrastruktur load balancing VM, tetapi siklus prosesnya sepenuhnya otomatis dan dikontrol oleh GKE. Pengontrol jaringan GKE menyediakan load balancing IP Pod native container menggunakan antarmuka level lebih tinggi yang tidak fleksibel dan sesuai dengan standar Ingress and Layanan API.

Diagram berikut menggambarkan cara pengontrol jaringan GKE mengotomatiskan pembuatan load balancer:

Seperti yang ditampilkan dalam diagram, administrator aplikasi atau infrastruktur men-deploy manifes deklaratif di cluster GKE-nya. Pengontrol Ingress dan Layanan memantau resource jaringan GKE (seperti objek Ingress) dan men-deploy load balancer (beserta alamat IP, aturan firewall, dll.) berdasarkan manifes.

Pengontrol akan terus mengelola load balancer dan backend berdasarkan perubahan lingkungan dan traffic. Karena itu, load balancing GKE menjadi load balancer yang dinamis dan berkelanjutan dengan antarmuka yang berorientasi developer.

Memilih metode untuk mengekspos aplikasi Anda

Saat Anda memilih metode untuk mengekspos aplikasi di GKE, jaringan klien, protokol, dan regionalitas aplikasi merupakan faktor inti yang harus dipertimbangkan. Dengan rangkaian pengontrol Ingress dan Layanan GKE, Anda dapat mengekspos aplikasi Anda dengan mempertimbangkan setiap faktor ini.

Meskipun bagian berikut tidak membahas setiap aspek jaringan aplikasi, menguasai setiap faktor berikut dapat membantu Anda menentukan solusi yang terbaik untuk aplikasi Anda. Sebagian besar lingkungan GKE menghosting berbagai jenis aplikasi, semuanya memiliki persyaratan unik masing-masing, sehingga kemungkinan Anda akan menggunakan lebih dari satu aplikasi di cluster tertentu.

Untuk perbandingan mendetail tentang kemampuan Ingress, lihat Konfigurasi Ingress.

Jaringan klien

Jaringan klien mengacu pada jaringan tempat klien aplikasi Anda mengakses aplikasi. Jaringan klien ini memengaruhi tempat pemrosesan frontend load balancer Anda yang seharusnya. Misalnya, klien bisa berada di dalam cluster GKE yang sama dengan aplikasi. Dalam hal ini, klien akan mengakses aplikasi Anda dari dalam jaringan cluster sehingga mereka dapat menggunakan Load balancing ClusterIP native Kubernetes.

Klien juga dapat berupa klien jaringan internal, yang mengakses aplikasi Anda dari dalam Virtual Private Cloud (VPC) atau dari jaringan lokal di seluruh Cloud Interconnect.

Klien juga dapat berada di pihak eksternal yang mengakses aplikasi Anda dari seluruh internet publik. Setiap jenis jaringan menentukan topologi load balancing yang berbeda.

Di GKE, Anda dapat memilih antara load balancer internal dan eksternal. Internal mengacu pada jaringan VPC yang merupakan jaringan pribadi internal yang tidak dapat diakses secara langsung dari internet. Eksternal mengacu pada internet publik. Layanan ClusterIP bersifat internal untuk satu cluster GKE sehingga dicakupkan ke jaringan yang lebih kecil daripada jaringan VPC.

Tabel berikut memberikan ringkasan solusi yang tersedia untuk jaringan internal dan eksternal.

Jenis jaringan Solusi yang tersedia
Internal Layanan ClusterIP
Layanan NodePort
Layanan LoadBalancer Internal
Ingress Internal
Eksternal Layanan NodePort1
Layanan LoadBalancer Eksternal
Ingress Eksternal
Multi Cluster Ingress

1 Cluster GKE yang menggunakan tanda --no-enable-private-nodes dapat memiliki node dengan alamat IP publik dan pribadi sehingga Layanan NodePort dapat diakses secara internal dan eksternal.

Protokol

Protokol adalah bahasa yang digunakan klien untuk aplikasi. Aplikasi suara, game, dan latensi rendah biasanya menggunakan TCP atau UDP secara langsung sehingga memerlukan load balancer yang memiliki kontrol terperinci di lapisan 4. Aplikasi lain menggunakan HTTP, HTTPS, gRPC, atau HTTP2, dan memerlukan load balancer dengan dukungan eksplisit dari protokol ini. Persyaratan protokol menentukan lebih lanjut jenis metode eksposur aplikasi yang paling sesuai.

Di GKE, Anda dapat mengonfigurasi load balancer Lapisan 4, yang merutekan traffic berdasarkan informasi jaringan seperti port dan protokol, serta load balancer Lapisan 7 yang memiliki kesadaran akan informasi aplikasi seperti sesi klien. Setiap load balancer yang berbeda dilengkapi dengan dukungan protokol khusus seperti yang ditunjukkan dalam tabel berikut:

Lapisan Protokol Solusi yang tersedia
L4 TCP
UDP		 Layanan ClusterIP
Layanan NodePort
Layanan LoadBalancer Internal
Layanan LoadBalancer Eksternal
L7 HTTP
HTTPS
HTTP2 		Ingress Internal
Ingress Eksternal
Multi Cluster Ingress

Regionalitas aplikasi

Regionalitas aplikasi mengacu pada tingkat distribusi aplikasi Anda di lebih dari satu region atau cluster GKE. Menghosting satu instance aplikasi memiliki persyaratan yang berbeda dengan menghosting instance aplikasi redundan di dua cluster GKE independen. Menghosting aplikasi yang terdistribusi secara geografis di lima cluster GKE untuk menempatkan workload lebih dekat ke pengguna akhir untuk mendapatkan latensi yang lebih rendah memerlukan kesadaran multi-cluster dan multi-regional yang lebih tinggi untuk load balancer.

Anda dapat membagi regionalitas solusi load balancing GKE menjadi dua area:

  • Cakupan backend (atau cakupan cluster): Cakupan ini mengacu pada kemampuan load balancer untuk mengirim traffic ke backend di beberapa cluster GKE. Multi Cluster Ingress memiliki kemampuan untuk mengekspos satu alamat IP virtual yang mengarahkan traffic ke Pod dari berbagai cluster dan berbagai region.

  • Cakupan frontend: Cakupan ini mengacu pada kemampuan IP load balancer untuk memproses dalam satu atau di beberapa region. Semua load balancer eksternal memantau internet, yang pada dasarnya bersifat multi-region, tetapi beberapa load balancer internal hanya memproses satu region.

Tabel berikut menguraikan solusi load balancing GKE di kedua dimensi ini.

Cakupan backend
(cakupan cluster)		 Solusi yang tersedia
Cluster tunggal Layanan ClusterIP
Layanan NodePort
Layanan LoadBalancer Internal
Layanan LoadBalancer Eksternal
Ingress Internal
Ingress Eksternal
Multi-cluster Multi Cluster Ingress
Cakupan frontend Solusi yang tersedia
Regional Layanan ClusterIP
Ingress Internal
Global Layanan ClusterIP
Layanan NodePort
Layanan LoadBalancer Internal
Layanan LoadBalancer Eksternal
Ingress Eksternal
Multi Cluster Ingress

Solusi lain untuk eksposur aplikasi

Solusi sebelumnya bukan satu-satunya solusi yang tersedia untuk mengekspos aplikasi. Solusi berikut juga dapat menjadi pengganti atau pelengkap yang layak untuk load balancer GKE.

Ingress dalam cluster

Ingress dalam cluster mengacu pada pengontrol Ingress software dengang proxy Ingress yang dihosting di dalam cluster Kubernetes itu sendiri. Hal ini berbeda dengan pengontrol Ingress GKE, yang menghosting dan mengelola infrastruktur load balancing-nya secara terpisah dari cluster Kubernetes. Solusi pihak ketiga ini biasanya di-deploy dan dikelola sendiri oleh operator cluster. istio-ingressgateway dan nginx-ingress adalah dua contoh pengontrol Ingress dalam cluster open source dan sudah umum digunakan.

Pengontrol Ingress dalam cluster biasanya sesuai dengan spesifikasi Ingress Kubernetes, dan menyediakan beragam kemampuan serta kemudahan penggunaan. Solusi open source cenderung memerlukan pengelolaan yang lebih cermat dan tingkat keahlian teknis yang lebih tinggi, tetapi mungkin sesuai dengan kebutuhan Anda jika solusi tersebut menyediakan fitur khusus yang diperlukan aplikasi Anda. Ada juga ekosistem solusi Ingress perusahaan berukuran luas yang dibangun berdasarkan komunitas open source yang menyediakan fitur lanjutan dan dukungan perusahaan.

Grup Endpoint Jaringan (NEG) Mandiri

Pengontrol GKE Ingress dan Layanan menyediakan metode otomatis, deklaratif, dan berbasis Kubernetes untuk men-deploy Cloud Load Balancing. Ada juga beberapa kasus penggunaan yang valid untuk men-deploy load balancer secara manual untuk backend GKE, misalnya memiliki kontrol langsung dan lebih terperinci atas load balancer, atau load balancing antara backend container dan VM.

NEG mandiri memberikan kemampuan ini dengan cara memperbarui IP backend Pod secara dinamis untuk NEG, tetapi memungkinkan frontend load balancer di-deploy secara manual. Solusi ini memberikan kontrol langsung dan maksimum atas load balancer sembari mempertahankan backend dinamis yang dikontrol oleh cluster GKE.

Mesh layanan

Mesh layanan menyediakan load balancing sisi klien melalui bidang kontrol terpusat. Cloud Service Mesh dan Cloud Service Mesh mendukung kemampuan untuk melakukan load balancing traffic internal di seluruh cluster GKE, lintas region, dan juga antara container dan VM. Dengan ini, garis antara load balancing internal (traffic timur-barat) dan eksposur aplikasi (traffic utara-selatan) menjadi buram. Dengan fleksibilitas dan jangkauan bidang kontrol mesh layanan modern, makin besar kemungkinan untuk memiliki klien dan server dalam cakupan mesh layanan yang sama. Solusi GKE Ingress dan Layanan sebelumnya umumnya men-deploy load balancer middle-proxy untuk klien yang tidak memiliki proxy file bantuannya sendiri. Namun, jika klien dan server berada dalam mesh yang sama, eksposur aplikasi dapat ditangani menggunakan mesh, bukan load balancing middle-proxy.

Langkah selanjutnya