Tentang Service LoadBalancer

Autopilot Standard

Halaman ini menyajikan ringkasan umum tentang cara Google Kubernetes Engine (GKE) membuat dan mengelola Google Cloud load balancer saat Anda menerapkan manifes Layanan LoadBalancer Kubernetes. Dokumen ini menjelaskan jenis LoadBalancer, parameter konfigurasi, dan memberikan rekomendasi praktik terbaik.

Sebelum membaca halaman ini, pastikan Anda memahami konsep jaringan GKE.

Ringkasan

Saat Anda membuat Service LoadBalancer, GKE mengonfigurasi Google Cloud load balancer passthrough yang karakteristiknya bergantung pada parameter manifes Service Anda.

Menyesuaikan Layanan LoadBalancer

Saat memilih konfigurasi Service LoadBalancer yang akan digunakan, pertimbangkan aspek berikut:

• Jenis load balancer – Internal atau Eksternal
• Kebijakan traffic eksternal
• Load balancing berbobot
• Afinitas zona

Gambar: Pohon keputusan Service LoadBalancer

Jenis load balancer – Internal atau Eksternal

Saat membuat Service LoadBalancer di GKE, Anda menentukan apakah load balancer memiliki alamat internal atau eksternal:

• Layanan LoadBalancer Eksternal diterapkan menggunakan Load Balancer Jaringan passthrough eksternal. Klien yang berada di luar jaringan VPC dan Google Cloud VM dengan akses internet dapat mengakses Service LoadBalancer eksternal.

  Untuk membuat Layanan LoadBalancer eksternal, gunakan salah satu teknik berikut:

  • Di cluster yang menjalankan GKE 1.33.1-gke.1779000 atau yang lebih baru, tambahkan spec.loadBalancerClass: "networking.gke.io/l4-regional-external" ke manifes Layanan sebelum Anda mengirimkan manifes ke cluster. Sebaiknya Anda menggunakan kolom ini karena kolom ini selalu membuat Load Balancer Jaringan passthrough eksternal berbasis layanan backend dengan backend NEG GCE_VM_IP. Kolom spec.loadBalancerClass bersifat tetap dan tidak dapat diubah setelah Anda membuat Layanan.

  • Di cluster yang menjalankan versi GKE yang didukung, Anda dapat menambahkan anotasi cloud.google.com/l4-rbs: "enabled" ke manifes Layanan sebelum Anda mengirimkan manifes ke cluster. Anotasi ini juga membuat Load Balancer Jaringan passthrough eksternal berbasis layanan backend. Load balancer menggunakan backend NEG GCE_VM_IP jika manifes dikirimkan ke cluster yang menjalankan GKE 1.32.2-gke.1652000 atau yang lebih baru. Jika tidak, load balancer akan menggunakan backend grup instance. GKE hanya mengevaluasi anotasi ini saat manifes Layanan pertama kali diterapkan ke cluster.

• Service LoadBalancer Internal diterapkan menggunakan Load Balancer Jaringan passthrough internal. Klien yang berada di jaringan VPC yang sama atau dalam jaringan yang terhubung ke jaringan VPC cluster dapat mengakses Service LoadBalancer internal.

  Sebagai praktik terbaik, sebelum membuat Service LoadBalancer internal, pastikan subsetelan GKE diaktifkan. Subsetting GKE diaktifkan secara otomatis jika cluster Anda menjalankan GKE 1.36 atau yang lebih baru. Untuk versi GKE yang lebih lama, Anda harus mengaktifkan subsetelan GKE secara eksplisit.

  Untuk membuat Service LoadBalancer internal, gunakan salah satu teknik berikut:

  • Di cluster yang menjalankan GKE 1.33.1-gke.1779000 atau yang lebih baru yang mengaktifkan subset GKE, tambahkan spec.loadBalancerClass: "networking.gke.io/l4-regional-internal" ke manifes Layanan sebelum Anda mengirimkan manifes ke cluster. Sebaiknya Anda menggunakan kolom ini karena kolom ini selalu membuat Load Balancer Jaringan passthrough internal dengan backend NEG GCE_VM_IP. Kolom spec.loadBalancerClass bersifat tetap dan tidak dapat diubah setelah Anda membuat Layanan.

  • Di cluster yang menjalankan versi GKE yang didukung, Anda dapat menambahkan anotasi networking.gke.io/load-balancer-type: "Internal" ke manifes Layanan sebelum mengirimkan manifes ke cluster. Tindakan ini juga membuat Load Balancer Jaringan passthrough internal. Load balancer menggunakan backend NEG GCE_VM_IP jika manifes dikirimkan ke cluster yang mengaktifkan subset GKE. Jika tidak, load balancer akan menggunakan backend grup instance.

Manifes Layanan LoadBalancer yang tidak memiliki spec.loadBalancerClass dan yang tidak memiliki anotasi cloud.google.com/l4-rbs: "enabled" atau networking.gke.io/load-balancer-type: "Internal" akan membuat Load Balancer Jaringan passthrough eksternal berbasis kumpulan target. Sebaiknya jangan gunakan Load Balancer Jaringan passthrough eksternal berbasis kumpulan target.

Prasyarat HttpLoadBalancing

Untuk membuat Layanan LoadBalancer yang didukung oleh Load Balancer Jaringan passthrough eksternal berbasis layanan backend atau Load Balancer Jaringan passthrough internal, pastikan add-on HttpLoadBalancing diaktifkan jika cluster Anda menjalankan versi GKE sebelum 1.36. Add-on HttpLoadBalancing diaktifkan secara default.

Layanan LoadBalancer di GKE versi 1.36 dan yang lebih baru tidak bergantung pada add-on HttpLoadBalancing.

Pengaruh externalTrafficPolicy

Parameter externalTrafficPolicy mengontrol hal berikut:

• Node mana yang menerima paket dari load balancer
• Apakah paket dapat dirutekan antar-node dalam cluster, setelah load balancer mengirimkan paket ke node
• Apakah alamat IP klien asli dipertahankan atau hilang

externalTrafficPolicy dapat berupa Local atau Cluster:

• Gunakan externalTrafficPolicy: Local untuk memastikan bahwa paket hanya dikirim ke node dengan setidaknya satu Pod yang aktif, siap, dan tidak berhenti, serta mempertahankan alamat IP sumber klien asli. Opsi ini paling cocok untuk workload dengan jumlah node yang relatif konstan dengan Pod aktif, meskipun jumlah keseluruhan node dalam cluster bervariasi. Opsi ini diperlukan untuk mendukung load balancing berbobot.

Catatan: Penggunaan kebijakan Local untuk mempertahankan alamat IP sumber tidak akan berfungsi jika ip-masq-agent berjalan di cluster Anda dan rentang alamat IP Pod tidak dikecualikan dari penyamaran IP. Lihat custom nonMasqueradeCIDRs list in the ip-masq-agent configMap untuk mendapatkan petunjuk tentang cara mengecualikan rentang alamat IP dari penyamaran.

• Gunakan externalTrafficPolicy: Cluster dalam situasi ketika jumlah keseluruhan node di cluster Anda relatif konstan, tetapi jumlah node dengan Pod aktif bervariasi. Opsi ini tidak mempertahankan alamat IP sumber klien asli, dan dapat menambah latensi karena paket mungkin dirutekan ke Pod penayangan di node lain setelah dikirim ke node dari load balancer. Opsi ini tidak kompatibel dengan load balancing berbobot.

Untuk mengetahui informasi selengkapnya tentang pengaruh externalTrafficPolicy terhadap pemilihan rute paket dalam node, lihat pemrosesan paket.

Penting: Untuk Layanan LoadBalancer internal, externalTrafficPolicy juga secara tidak langsung menentukan jumlah node dengan Pod yang melayani yang didukung. Untuk mengetahui informasi selengkapnya, lihat Pertimbangan jumlah node.

Load balancing berbobot

Layanan LoadBalancer eksternal mendukung load balancing berbobot, yang memungkinkan node dengan lebih banyak Pod yang siap, tidak berhenti, dan melayani untuk menerima proporsi koneksi baru yang lebih besar dibandingkan dengan node dengan lebih sedikit Pod. Untuk mengetahui informasi selengkapnya tentang cara konfigurasi load balancer berubah dengan load balancing berbobot, lihat Pengaruh load balancing berbobot.

Gambar: Distribusi traffic load balancing berbobot

Seperti yang diilustrasikan diagram, Layanan dengan load balancing berbobot yang diaktifkan mendistribusikan koneksi baru secara proporsional ke jumlah Pod siap di setiap node.

Untuk menggunakan load balancing berbobot, Anda harus memenuhi semua persyaratan berikut:

• Cluster GKE Anda harus menggunakan versi 1.31.0-gke.1506000 atau yang lebih baru.

• Anda harus membuat Layanan LoadBalancer eksternal yang menghasilkan Load Balancer Jaringan passthrough eksternal berbasis layanan backend. Anda dapat menggunakan salah satu teknik berikut:

  • Di cluster yang menjalankan GKE 1.33.1-gke.1779000 atau yang lebih baru, tambahkan spec.loadBalancerClass: "networking.gke.io/l4-regional-external" ke manifes Layanan sebelum Anda mengirimkan manifes ke cluster. Ini adalah metode yang lebih disukai.

  • Di cluster yang menjalankan versi GKE yang didukung, tambahkan anotasi cloud.google.com/l4-rbs: "enabled" ke manifes Layanan sebelum Anda mengirimkan manifes ke cluster.

• Anda harus menyertakan anotasi networking.gke.io/weighted-load-balancing: pods-per-node dalam manifes Service untuk mengaktifkan fitur load balancing berbobot.

• Manifes Layanan LoadBalancer harus menggunakan externalTrafficPolicy: Local. GKE tidak mencegah Anda menggunakan externalTrafficPolicy: Cluster, tetapi externalTrafficPolicy: Cluster secara efektif menonaktifkan load balancing berbobot karena paket mungkin dirutekan, setelah load balancer, ke node yang berbeda.

Untuk menggunakan load balancing berbobot, lihat Mengaktifkan load balancing berbobot.

Afinitas zonal

Layanan LoadBalancer Internal mendukung afinitas zona (Pratinjau), yang dapat merutekan koneksi baru ke node dengan Pod aktif di zona yang sama dengan klien. Jika tidak ada Pod yang responsif di zona tersebut, GKE akan merutekan traffic ke zona lain. Mempertahankan traffic dalam zona dapat meminimalkan traffic lintas zona, yang mengurangi biaya dan latensi. Untuk mengaktifkan afinitas zona di cluster GKE, Anda harus mengaktifkan subsetelan GKE.

Untuk mengetahui informasi selengkapnya tentang cara konfigurasi load balancer berubah dengan afinitas zonal, termasuk kapan Anda dapat mempertahankan traffic dalam zona, lihat Pengaruh afinitas zonal. Untuk mengetahui informasi selengkapnya tentang pengaruh afinitas zona dan externalTrafficPolicy terhadap pemilihan rute paket di VM node, lihat Terjemahan dan pemilihan rute Alamat Jaringan Sumber di node.

Pertimbangan khusus untuk Layanan LoadBalancer internal

Bagian ini menjelaskan fitur subsetelan GKE, yang unik untuk Layanan LoadBalancer internal, dan cara subsetelan GKE berinteraksi dengan externalTrafficPolicy untuk memengaruhi jumlah maksimum node yang di-load balance.

Subsetelan GKE

Subsetelan GKE untuk Layanan LoadBalancer internal diaktifkan secara default untuk cluster GKE yang menjalankan versi 1.36 dan yang lebih baru. Untuk versi ini, subset GKE tetap aktif meskipun tanda --enable-l4-ilb-subsetting tingkat cluster ditetapkan ke false dalam konfigurasi cluster atau alat Infrastructure as Code (IaC) seperti Terraform.

Opsi konfigurasi seluruh cluster ini meningkatkan skalabilitas Load Balancer Jaringan passthrough internal dengan mengelompokkan endpoint node secara lebih efisien ke dalam grup endpoint jaringan (NEG) GCE_VM_IP. NEG digunakan sebagai backend load balancer.

Diagram berikut menunjukkan dua Service di cluster zona dengan tiga node. Cluster telah mengaktifkan subsetelan GKE. Setiap Service memiliki dua Pod. GKE membuat satu NEG GCE_VM_IP untuk setiap Service. Endpoint di setiap NEG adalah node dengan Pod aktif untuk masing-masing Service.

Untuk cluster yang menjalankan versi sebelum 1.36, Anda dapat mengaktifkan subsetelan GKE secara manual saat membuat cluster atau mengupdate cluster yang ada. Setelah subsetelan GKE diaktifkan, Anda tidak dapat menonaktifkannya.

Subsetelan GKE memerlukan:

• GKE versi 1.18.19-gke.1400 atau yang lebih baru, dan
• Jika cluster Anda menggunakan versi yang lebih lama dari 1.36, add-on HttpLoadBalancing harus diaktifkan. Add-on ini diaktifkan secara default. Fungsi ini memungkinkan cluster mengelola load balancer yang menggunakan layanan backend. Jika cluster Anda menggunakan versi 1.36 dan yang lebih baru, add-on HttpLoadBalancing bukan prasyarat untuk penyubsetan GKE.

Catatan: Subsetelan GKE berbeda dengan Google Cloud subsetelan backend Load Balancer Jaringan passthrough internal. Load Balancer Jaringan passthrough internal yang dibuat oleh GKE tidak pernah dikonfigurasi untuk menggunakan subsetelan backend Load Balancer Jaringan passthrough internal.

Jumlah node

Cluster dengan subsetelan GKE yang dinonaktifkan dapat mengalami masalah dengan Service LoadBalancer internal jika cluster memiliki lebih dari 250 total node (di antara semua node pool). Hal ini terjadi karena Load Balancer Jaringan passthrough internal yang dibuat oleh GKE hanya dapat mendistribusikan paket ke 250 VM node backend atau kurang. Batasan ini ada karena dua alasan berikut:

• GKE tidak menggunakan subsetelan backend load balancer.
• Load Balancer Jaringan passthrough internal dibatasi untuk mendistribusikan paket ke 250 backend atau kurang saat subsetelan backend load balancer dinonaktifkan.

Cluster dengan subsetelan GKE mendukung Layanan LoadBalancer internal di cluster dengan lebih dari 250 total node.

Jumlah node yang didukung dengan subsetelan GKE bergantung pada nilai kolom externalTrafficPolicy untuk Service LoadBalancer internal:

• externalTrafficPolicy: Local: mendukung hingga 250 node dengan Pod yang melayani untuk Layanan tertentu.

• externalTrafficPolicy: Cluster: tidak membatasi jumlah node dengan Pod penayangan. Perilaku ini terjadi karena GKE mengonfigurasi maksimum 25 endpoint node di NEG GCE_VM_IP untuk setiap Service. Untuk mengetahui informasi selengkapnya, lihat Keanggotaan node di backend NEG GCE_VM_IP.

Distribusi traffic

Secara default, Layanan LoadBalancer internal dan eksternal membuat Load Balancer Jaringan passthrough dengan afinitas sesi yang ditetapkan ke NONE. Load Balancer Jaringan Passthrough menggunakan afinitas sesi, informasi responsivitas, dan—dalam keadaan tertentu—detail seperti bobot untuk mengidentifikasi dan memilih backend node yang memenuhi syarat untuk koneksi baru.

Koneksi baru membuat entri tabel pelacakan koneksi, yang digunakan untuk merutekan paket berikutnya dengan cepat untuk koneksi ke backend node yang memenuhi syarat yang dipilih sebelumnya. Untuk mengetahui informasi selengkapnya tentang cara Network Load Balancer passthrough mengidentifikasi dan memilih backend yang memenuhi syarat, serta menggunakan tracking koneksi, lihat artikel berikut:

• Distribusi traffic untuk Load Balancer Jaringan passthrough internal

• Distribusi traffic untuk Load Balancer Jaringan passthrough eksternal

Efek load balancing berbobot

Saat Anda mengonfigurasi load balancing berbobot untuk Layanan Load Balancer eksternal, GKE akan mengaktifkan load balancing berbobot pada Load Balancer Jaringan passthrough eksternal yang sesuai. GKE mengonfigurasi software kube-proxy atau cilium-agent untuk menyertakan header respons dalam jawaban terhadap health check load balancer. Header respons ini menentukan bobot yang proporsional dengan jumlah Pod yang melayani, siap, dan tidak dihentikan di setiap node.

Load balancer menggunakan informasi bobot sebagai berikut:

• Kumpulan backend node yang memenuhi syarat dari load balancer terdiri dari semua node yang sehat dan memiliki bobot tidak nol.

• Load balancer mempertimbangkan bobot saat memilih salah satu backend node yang memenuhi syarat. Saat Layanan menggunakan externalTrafficPolicy: Local (diperlukan agar load balancing berbobot efektif), backend node yang memenuhi syarat dan memiliki lebih banyak Pod aktif, siap, dan tidak berhenti lebih mungkin dipilih daripada backend node yang memenuhi syarat dengan lebih sedikit Pod.

Efek afinitas zonal

Saat Anda mengonfigurasi afinitas zonal untuk Layanan Load Balancer internal, GKE akan mengonfigurasi Load Balancer Jaringan passthrough internal yang sesuai dengan opsi ZONAL_AFFINITY_SPILL_CROSS_ZONE dan rasio pelimpahan nol.

Dengan konfigurasi afinitas zona ini, load balancer mempersempit set asli backend node yang memenuhi syarat hanya ke backend node yang memenuhi syarat yang berada di zona yang sama dengan klien saat semua hal berikut terpenuhi:

• Klien kompatibel dengan afinitas zonal.

• Setidaknya ada satu backend node yang sehat dan memenuhi syarat di zona klien.

Dalam situasi lainnya, load balancer akan terus menggunakan kumpulan backend node yang memenuhi syarat asli, tanpa menerapkan pengoptimalan afinitas zona.

Untuk mengetahui detail selengkapnya tentang pengaruh konfigurasi afinitas zonal terhadap perilaku load balancer, lihat dokumentasi Afinitas zonal.

Pengelompokan node

Versi GKE, anotasi manifes Service, dan untuk Layanan LoadBalancer Internal, opsi subset GKE menentukan load balancer Google Cloud yang dihasilkan dan jenis backend.

Tabel berikut menguraikan metode pengelompokan node untuk berbagai konfigurasi Layanan LoadBalancer:

Detail layanan dan cluster	Load balancer Google Cloud yang dihasilkan	Metode pengelompokan node
Layanan LoadBalancer internal
GKE versi 1.33.1-gke.1779000 atau yang lebih baru di cluster dengan subset GKE diaktifkan^1. Manifes layanan dikirimkan ke cluster dengan spec.loadBalancerClass: "networking.gke.io/l4-regional-internal".	Load Balancer Jaringan passthrough internal yang layanan backend-nya menggunakan backend grup endpoint jaringan (NEG) GCE_VM_IP	VM Node dikelompokkan ke dalam NEG zona GCE_VM_IP per Service berdasarkan externalTrafficPolicy Service dan jumlah node di cluster. externalTrafficPolicy Service juga mengontrol node mana yang lulus health check load balancer dan pemrosesan paket.
Semua versi GKE yang didukung di cluster dengan subsetelan GKE diaktifkan^1. Manifes layanan dikirimkan ke cluster dengan anotasi networking.gke.io/load-balancer-type: "Internal".
Versi GKE sebelum 1.36 di cluster dengan subsetelan GKE dinonaktifkan^1. Manifes layanan dikirimkan ke cluster dengan anotasi networking.gke.io/load-balancer-type: "Internal".	Load Balancer Jaringan passthrough internal yang layanan backend-nya menggunakan backend grup instance tidak terkelola di zona	Semua VM node ditempatkan ke dalam grup instance tidak terkelola di zona yang GKE gunakan sebagai backend untuk layanan backend Load Balancer Jaringan passthrough internal. externalTrafficPolicy Service mengontrol node mana yang lulus health check load balancer dan pemrosesan paket. Grup instance tidak terkelola yang sama digunakan untuk layanan backend load balancer lain yang dibuat di cluster karena keterbatasan satu grup load-balanced instance.
Layanan LoadBalancer Eksternal
GKE versi 1.33.1-gke.1779000 atau yang lebih baru. Manifes layanan dikirimkan ke cluster dengan spec.loadBalancerClass: "networking.gke.io/l4-regional-external".	Load Balancer Jaringan passthrough eksternal berbasis layanan backend dengan backend grup endpoint jaringan (NEG) GCE_VM_IP	VM Node dikelompokkan ke dalam NEG zona GCE_VM_IP per Service berdasarkan externalTrafficPolicy Service dan jumlah node di cluster. externalTrafficPolicy Service juga mengontrol node mana yang lulus health check load balancer dan pemrosesan paket.
GKE versi 1.32.2-gke.1652000 atau yang lebih baru. Manifes Service dikirimkan ke cluster dengan anotasi cloud.google.com/l4-rbs: "enabled"^2.
GKE versi sebelum 1.32.2-gke.1652000^3. Manifes Service dikirimkan ke cluster dengan anotasi cloud.google.com/l4-rbs: "enabled"^2.	Load Balancer Jaringan passthrough eksternal berbasis layanan backend dengan backend grup instance tidak terkelola di zona	Semua VM node ditempatkan ke dalam grup instance tidak terkelola di zona yang GKE gunakan sebagai backend untuk layanan backend Load Balancer Jaringan passthrough eksternal. externalTrafficPolicy Service mengontrol node mana yang lulus health check load balancer dan pemrosesan paket. Grup instance tidak terkelola yang sama digunakan untuk layanan backend load balancer lain yang dibuat di cluster karena keterbatasan satu grup load-balanced instance.
Semua versi GKE yang didukung. Manifes layanan dikirimkan ke cluster tanpa semua hal berikut: spec.loadBalancerClass networking.gke.io/load-balancer-type anotasi cloud.google.com/l4-rbs anotasi	Load Balancer Jaringan passthrough eksternal berbasis kumpulan target yang kumpulan targetnya berisi semua node cluster	Kumpulan target adalah API lama yang tidak bergantung pada NEG atau grup instance. Semua node memiliki keanggotaan langsung di kumpulan target. externalTrafficPolicy Service mengontrol node mana yang lulus health check load balancer dan pemrosesan paket.

¹Subsetelan GKE diaktifkan secara otomatis di GKE versi 1.36 dan yang lebih baru. Subsetelan GKE tidak dapat dinonaktifkan setelah Anda mengaktifkannya.

²Anotasi cloud.google.com/l4-rbs: "enabled" hanya diterapkan saat manifes Layanan dikirimkan ke cluster. Menambahkan anotasi ini ke manifes Service yang ada tidak akan mengonversi Load Balancer Jaringan passthrough eksternal berbasis kumpulan target menjadi Load Balancer Jaringan passthrough eksternal berbasis layanan backend.

³GKE tidak otomatis mengupdate Load Balancer Jaringan passthrough eksternal berbasis layanan backend dengan backend grup instance ke Load Balancer Jaringan passthrough eksternal berbasis layanan backend dengan backend NEG GCE_VM_IP. Untuk petunjuk migrasi manual, lihat Bermigrasi ke backend NEG GCE_VM_IP.

Keanggotaan node di backend NEG GCE_VM_IP

Saat membuat Load Balancer Jaringan passthrough internal atau Load Balancer Jaringan passthrough eksternal berbasis layanan backend dengan backend NEG GCE_VM_IP, GKE akan membuat dan mengelola NEG seperti ini:

• GKE membuat NEG GCE_VM_IP unik di setiap zona untuk setiap Service LoadBalancer. Tidak seperti grup instance, node dapat menjadi anggota lebih dari satu NEG GCE_VM_IP yang di-load balanced.

• externalTrafficPolicy Service dan jumlah node di cluster menentukan node mana yang ditambahkan sebagai endpoint ke NEG GCE_VM_IP Service.

Catatan: NEG GCE_VM_IP berbeda dengan NEG GCE_VM_IP_PORT. GCE_VM_IP_PORT NEG berisi endpoint port container dan IP Pod, serta digunakan oleh Gateway dan Ingress (berbasis container). NEG GCE_VM_IP mengidentifikasi antarmuka jaringan VM node menggunakan alamat IP node, meskipun paket yang di-load balance memiliki tujuan yang cocok dengan alamat IP aturan penerusan load balancer dan salah satu port yang dikonfigurasi untuk aturan penerusan.

Bidang kontrol cluster mengelola endpoint node di NEG GCE_VM_IP sesuai dengan nilai externalTrafficPolicy Service dan jumlah node di cluster, seperti yang diringkas dalam tabel berikut.

Node di Load Balancer Jaringan passthrough internal

externalTrafficPolicy	Jumlah node di cluster	Keanggotaan endpoint
Cluster	1 hingga 25 node	GKE menggunakan semua node di cluster sebagai endpoint untuk NEG Service, meskipun node tidak berisi Pod aktif untuk Service.
Cluster	lebih dari 25 node	GKE menggunakan subset acak hingga 25 node sebagai endpoint untuk NEG Service, meskipun node tidak berisi Pod aktif untuk Service.
Local	sejumlah node^1	GKE hanya menggunakan node yang memiliki setidaknya satu Pod aktif Service sebagai endpoint untuk NEG Service.

¹Dibatasi hingga 250 node dengan Pod aktif. Lebih dari 250 node dapat ada di cluster, tetapi Load Balancer Jaringan passthrough internal hanya dapat mendistribusikan ke 250 VM backend saat subsetelan backend Load Balancer Jaringan passthrough internal dinonaktifkan. Meskipun subsetelan GKE diaktifkan, GKE tidak pernah mengonfigurasi Load Balancer Jaringan passthrough internal dengan subsetelan backend Load Balancer Jaringan passthrough internal. Untuk mengetahui detail terkait batasan ini, lihat Jumlah maksimum instance VM per layanan backend internal.

Node di Load Balancer Jaringan passthrough eksternal

externalTrafficPolicy	Jumlah node di cluster	Keanggotaan endpoint
Cluster	1 hingga 250 node	GKE menggunakan semua node di cluster sebagai endpoint untuk NEG Service, meskipun node tidak berisi Pod aktif untuk Service.
Cluster	lebih dari 250 node	GKE menggunakan subset acak hingga 250 node sebagai endpoint untuk NEG Service, meskipun node tidak berisi Pod aktif untuk Service.
Local	sejumlah node^1	GKE hanya menggunakan node yang memiliki setidaknya satu Pod aktif Service sebagai endpoint untuk NEG Service.

¹Dibatasi hingga 3.000 node dengan Pod aktif. Lebih dari 3.000 node dapat ada di cluster, tetapi GKE hanya mendukung pembuatan hingga 3.000 endpoint saat membuat Load Balancer Jaringan passthrough eksternal berbasis layanan backend yang menggunakan backend NEG GCE_VM_IP.

Keterbatasan grup load-balanced instance tunggal

Compute Engine API melarang VM menjadi anggota lebih dari satu grup instance yang di-load balanced. Node GKE tunduk kepada batasan ini.

Saat menggunakan backend grup instance tidak terkelola, GKE akan membuat atau memperbarui grup instance tidak terkelola yang berisi semua node dari semua node pool di setiap zona yang digunakan cluster tersebut. Grup instance tidak terkelola ini adalah backend untuk load balancer yang dibuat GKE berikut:

• Load Balancer Jaringan passthrough internal yang dibuat untuk Layanan LoadBalancer internal yang manifesnya memiliki anotasi networking.gke.io/load-balancer-type: "Internal", dikirimkan ke cluster yang menjalankan versi GKE sebelum 1.36, dengan subsetelan GKE dinonaktifkan.
• Load Balancer Jaringan passthrough eksternal berbasis layanan backend yang dibuat untuk Service LoadBalancer eksternal yang manifesnya memiliki anotasi cloud.google.com/l4-rbs: "enabled", dikirimkan ke cluster yang menjalankan versi GKE sebelum 1.32.2-gke.1652000.
• Load Balancer Aplikasi eksternal yang dibuat untuk Ingress GKE eksternal, menggunakan pengontrol Ingress GKE, tetapi tidak menggunakan load balancing berbasis container.

Karena VM node tidak dapat menjadi anggota lebih dari satu grup instance yang di-load balanced, GKE tidak dapat membuat dan mengelola Load Balancer Jaringan passthrough internal, Load Balancer Jaringan passthrough eksternal berbasis layanan backend, dan Load Balancer Aplikasi eksternal yang dibuat untuk resource Ingress GKE jika salah satu kondisi berikut terpenuhi:

• Di luar GKE, Anda telah membuat setidaknya satu load balancer berbasis layanan backend, dan menggunakan grup instance terkelola cluster sebagai backend untuk layanan backend load balancer.
• Di luar GKE, Anda telah membuat grup instance tidak terkelola kustom yang berisi beberapa atau semua node cluster, lalu menambahkan grup instance tidak terkelola kustom tersebut ke layanan backend untuk load balancer.

Untuk mengatasi keterbatasan ini, Anda dapat menginstruksikan GKE untuk menggunakan backend NEG:

• Buat Layanan LoadBalancer yang menggunakan NEG GCE_VM_IP. Untuk mengetahui informasi selengkapnya, lihat Pengelompokan node.
• Konfigurasikan resource Ingress GKE eksternal untuk menggunakan load balancing berbasis container. Untuk mengetahui informasi selengkapnya, lihat Load balancing berbasis container GKE.

Health check load balancer

Semua Service LoadBalancer GKE menerapkan pemeriksaan kondisi load balancer. Sistem health check load balancer beroperasi di luar cluster dan berbeda dengan pemeriksaan kesiapan, keaktifan, atau waktu mulai Pod.

Paket health check load balancer dijawab oleh software kube-proxy (dataplane lama) atau cilium-agent (GKE Dataplane V2) yang berjalan di setiap node. Health check load balancer untuk Layanan LoadBalancer tidak dapat dijawab oleh Pod.

externalTrafficPolicy Service menentukan node mana yang lulus health check load balancer. Untuk mengetahui informasi selengkapnya tentang cara load balancer menggunakan informasi health check, lihat Distribusi traffic.

externalTrafficPolicy	Node yang lulus health check	Port yang digunakan
Cluster	Semua node cluster lulus health check, termasuk node tanpa Pod aktif. Jika ada setidaknya satu Pod aktif di node, node tersebut lulus health check load balancer, terlepas dari status Pod-nya.	Port health check load balancer harus berupa port TCP 10256. Hal ini tidak dapat disesuaikan.
Local	Health check load balancer menganggap node responsif jika setidaknya ada satu Pod aktif yang siap dan tidak berhenti di node, terlepas dari status Pod lainnya. Node tanpa Pod aktif, node yang semua Pod aktifnya gagal dalam pemeriksaan kesiapan, dan node yang semua Pod aktifnya dihentikan akan gagal dalam health check load balancer. Selama transisi status, node masih lulus health check load balancer hingga batas tidak responsif health check load balancer tercapai. Status transisi terjadi saat semua Pod aktif di node mulai menggagalkan pemeriksaan kesiapan atau saat semua Pod aktif di node dihentikan. Cara paket diproses dalam situasi ini tergantung pada versi GKE. Untuk mengetahui detail tambahan, lihat bagian berikutnya, Pemrosesan paket.	Bidang kontrol Kubernetes menetapkan port health check dari rentang port node, kecuali Anda menentukan port health check kustom.

Jika load balancing berbobot diaktifkan, load balancer akan menggunakan informasi kesehatan dan bobot untuk mengidentifikasi kumpulan backend node yang memenuhi syarat. Untuk mengetahui informasi selengkapnya, lihat Efek load balancing berbobot.

Jika afinitas zona diaktifkan, load balancer dapat menyempurnakan set backend node yang memenuhi syarat. Untuk mengetahui informasi selengkapnya, lihat Efek afinitas zonal.

Pemrosesan paket

Bagian berikut menjelaskan cara load balancer dan node cluster bekerja sama untuk merutekan paket yang diterima untuk Service LoadBalancer.

Load balancing passthrough

Load Balancer Jaringan passthrough merutekan paket ke antarmuka nic0 node cluster GKE. Setiap paket yang di-load balanced yang diterima di node memiliki karakteristik berikut:

• Alamat IP tujuan paket cocok dengan alamat IP aturan penerusan load balancer.
• Protokol dan port tujuan paket cocok dengan kedua hal berikut:
  • protokol dan port yang ditentukan di spec.ports[] manifes Service
  • protokol dan port yang dikonfigurasi pada aturan penerusan load balancer

Penafsiran Alamat Jaringan Tujuan di node

Setelah node menerima paket, node menjalankan pemrosesan paket tambahan. Di cluster GKE yang menggunakan bidang data lama, node menggunakan iptables untuk memproses paket yang di-load balanced. Di cluster GKE dengan GKE Dataplane V2 yang diaktifkan, node menggunakan eBPF. Pemrosesan paket level node selalu mencakup tindakan berikut:

• Node menjalankan Penafsiran Alamat Jaringan Tujuan (DNAT) pada paket, dengan menyetel alamat IP tujuannya ke alamat IP Pod aktif.
• Node mengubah port tujuan paket ke targetPort dari spec.ports[] Service yang sesuai.

Penafsiran Alamat Jaringan Sumber dan perutean di node

Tabel berikut menunjukkan hubungan antara externalTrafficPolicy dan apakah node yang menerima paket yang di-load balance melakukan penafsiran alamat jaringan sumber (SNAT) sebelum mengirim paket yang di-load balance ke Pod:

externalTrafficPolicy	Perilaku SNAT
Cluster	Di cluster GKE yang menggunakan dataplane lama, setiap node yang menerima paket yang di-load balance selalu mengubah alamat IP sumber paket tersebut agar cocok dengan alamat IP node, baik node merutekan paket ke Pod lokal atau Pod di node yang berbeda. Di cluster GKE yang menggunakan GKE Dataplane V2, setiap node yang menerima paket yang di-load balance akan mengubah alamat IP sumber paket tersebut agar cocok dengan alamat IP node hanya jika node penerima merutekan paket ke Pod di node lain. Jika node yang menerima paket yang di-load balanced merutekan paket ke Pod lokal, node tidak mengubah alamat IP sumber paket tersebut.
Local	Setiap node yang menerima paket yang di-load balanced merutekan paket secara eksklusif ke Pod lokal, dan node tidak mengubah alamat IP sumber paket tersebut.

Tabel berikut menunjukkan cara externalTrafficPolicy mengontrol cara node merutekan paket yang di-load balance dan paket respons:

externalTrafficPolicy	Load balancing perutean paket	Perutean paket respons
Cluster	Berikut adalah perilaku dasar untuk merutekan paket yang di-load balanced: Jika node yang menerima paket yang di-load balance tidak memiliki Pod yang aktif, siap, dan tidak berhenti, node tersebut akan merutekan paket ke node lain yang memiliki Pod yang aktif, siap, dan tidak berhenti. Jika node yang menerima paket yang di-load balance memiliki Pod yang aktif, siap, dan tidak berhenti, node dapat merutekan paket ke salah satu dari: Pod lokal. Node lain yang memiliki Pod penayangan, siap, dan tidak berhenti. Di cluster regional, jika node yang menerima paket yang di-load balanced merutekan paket ke node lain, afinitas zonal akan memiliki efek berikut: Jika afinitas zona tidak diaktifkan, node yang berbeda mungkin berada di zona mana pun. Jika afinitas zona diaktifkan, node yang menerima paket yang di-load balancing akan mencoba merutekannya ke node lain di zona yang sama. Jika hal itu tidak memungkinkan, node yang berbeda dapat berada di zona mana pun. Sebagai upaya terakhir, jika tidak ada Pod aktif, siap, dan tidak dihentikan untuk Service di semua node dalam cluster, hal berikut akan terjadi: Jika Endpoint Penghentian Proxy diaktifkan^1, node yang menerima paket yang di-load balance akan merutekannya ke Pod yang aktif, tetapi berhenti jika memungkinkan. Jika Endpoint Penghentian Proxy dinonaktifkan, atau tidak ada Pod di seluruh cluster, node yang menerima paket yang di-load balance akan menutup koneksi dengan reset TCP.	Paket respons selalu dikirim dari node menggunakan Direct Server Return: Jika node dengan Pod aktif bukan node yang menerima paket load-balanced yang sesuai, node aktif akan mengirim paket respons kembali ke node penerima. Kemudian, node penerima mengirim paket respons menggunakan Direct Server Return. Jika node dengan Pod aktif adalah node yang menerima paket yang di-load balance, node tersebut akan mengirimkan paket respons menggunakan Direct Server Return.
Local	Berikut adalah perilaku dasar untuk merutekan paket yang di-load balance: node yang menerima paket yang di-load balance umumnya memiliki Pod aktif, siap, dan tidak berhenti (karena memiliki Pod seperti itu diperlukan untuk lulus health check load balancer). Node merutekan paket yang di-load balance ke Pod lokal. Di cluster regional, afinitas zona tidak mengubah perilaku dasar untuk merutekan paket yang di-load balance. Sebagai upaya terakhir, jika tidak ada Pod yang aktif, siap, dan tidak berhenti untuk Service di node yang menerima paket yang di-load balance, hal berikut akan terjadi: Jika Proxy Terminating Endpoints diaktifkan^1, node yang menerima paket yang di-load balance akan merutekannya ke Pod lokal yang aktif, tetapi berhenti jika memungkinkan. Jika Endpoint Penghentian Proxy dinonaktifkan, atau node yang menerima paket yang di-load balance tidak memiliki Pod yang melayani, node tersebut akan menutup koneksi dengan reset TCP.	Node dengan Pod yang melayani selalu merupakan node yang menerima paket yang di-load balance, dan node tersebut mengirimkan paket respons dengan menggunakan Direct Server Return.

¹ Proxy Terminating Endpoints diaktifkan dalam konfigurasi berikut:

• Cluster GKE yang menggunakan bidang data lama: GKE versi 1.26 dan yang lebih baru
• Cluster GKE yang menggunakan GKE Dataplane V2: GKE versi 1.26.4-gke.500 dan yang lebih baru

Harga dan kuota

Harga jaringan berlaku untuk paket yang diproses oleh load balancer. Untuk mengetahui informasi selengkapnya, lihat Harga Cloud Load Balancing dan aturan penerusan. Anda juga dapat memperkirakan biaya penagihan menggunakan Google Cloud kalkulator harga.

Jumlah aturan penerusan yang dapat Anda buat dikontrol oleh kuota load balancer:

• Load Balancer Jaringan passthrough internal menggunakan kuota layanan backend per project, kuota health check per project, dan Aturan penerusan Load Balancer Jaringan passthrough internal per kuota jaringan Virtual Private Cloud.
• Load Balancer Jaringan passthrough eksternal berbasis layanan backend menggunakan kuota layanan backend per project, kuota health check per project, dan kuota aturan penerusan Load Balancer Jaringan passthrough eksternal per project.
• Load Balancer Jaringan passthrough eksternal berbasis kumpulan target menggunakan kuota kumpulan target per project, kuota health check per project, dan kuota aturan penerusan Load Balancer Jaringan passthrough eksternal per project.

Langkah berikutnya

• Pelajari parameter Service LoadBalancer.
• Pelajari cara menyiapkan load balancer internal.
• Baca ringkasan Ingress untuk Load Balancer Aplikasi.
• Pelajari cara menggunakan NEG mandiri.
• Pelajari Gateway API.