Ringkasan jaringan layanan

Halaman ini menjelaskan cara men-deploy Layanan di Google Kubernetes Engine (GKE). Gunakan halaman ini sebagai panduan untuk lebih memahami fase 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 akan menyeimbangkan traffic untuk memberikan latensi yang lebih rendah dan meningkatkan ketahanan bagi 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 tersebut 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 memungkinkan komunikasi pribadi berlangsung 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 bawaan dan pengontrol Layanan GKE 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 pada cluster GKE mereka. Pengontrol Ingress dan Service memantau resource jaringan GKE (seperti objek Ingress) dan men-deploy load balancer (ditambah penentuan alamat IP, aturan firewall, dll.) berdasarkan manifesnya.

Pengontrol akan terus mengelola load balancer dan backend berdasarkan perubahan lingkungan dan traffic. Oleh karena itu, load balancing GKE menjadi load balancer yang dinamis dan mandiri dengan antarmuka 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 Service GKE, Anda dapat mengekspos aplikasi 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 terkait 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, mereka akan mengakses aplikasi Anda dari dalam jaringan cluster, sehingga memungkinkan mereka menggunakan load balancing ClusterIP berbasis 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 mencakup 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
Traffic Masuk Eksternal

1 Cluster GKE publik menyediakan alamat IP publik dan pribadi untuk setiap node GKE, 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 		Traffic Masuk Internal
Traffic Masuk Eksternal

Solusi lain untuk eksposur aplikasi

Solusi sebelumnya bukan satu-satunya yang tersedia untuk mengekspos aplikasi. Solusi berikut mungkin juga merupakan pengganti atau pelengkap yang tepat 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 GKE Ingress, yang menghosting dan mengelola infrastruktur load balancing mereka secara terpisah dari cluster Kubernetes. Solusi pihak ketiga ini biasanya di-deploy sendiri dan dikelola sendiri oleh operator cluster. istio-ingressgateway dan nginx-ingress adalah dua contoh pengontrol Ingress dalam cluster yang bersifat open source dan 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 dekat 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 yang luas, yang dibuat berdasarkan komunitas open source yang menyediakan fitur lanjutan dan dukungan untuk 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 memperbarui IP backend Pod secara dinamis untuk NEG, tetapi memungkinkan frontend load balancer untuk di-deploy secara manual. Hal ini memberikan kontrol maksimum dan langsung atas load balancer, sekaligus mempertahankan backend dinamis yang dikontrol oleh cluster GKE.

Mesh layanan

Mesh layanan menyediakan load balancing sisi klien melalui bidang kontrol terpusat. Traffic Director dan Anthos 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 Service sebelumnya umumnya men-deploy load balancer tengah-proxy untuk klien yang tidak memiliki proxy file bantuannya sendiri. Namun, jika klien dan server berada di mesh yang sama, eksposur aplikasi dapat ditangani menggunakan mesh, bukan load balancing middle-proxy.

Langkah selanjutnya