Tentang Service LoadBalancer

Autopilot Standard

---

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

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

Ringkasan

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

Menyesuaikan Layanan LoadBalancer untuk Jaringan

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

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

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 VM Google Cloud dengan akses internet dapat mengakses Service LoadBalancer eksternal.

  Saat Anda membuat layanan LoadBalancer dan tidak menentukan setelan kustom apa pun, layanan tersebut akan ditetapkan secara default ke konfigurasi ini.

  Sebagai praktik terbaik, saat membuat Layanan LoadBalancer eksternal, sertakan anotasi cloud.google.com/l4-rbs: "enabled" dalam manifes Layanan. Menyertakan anotasi ini dalam manifes Layanan akan membuat Load Balancer Jaringan passthrough eksternal berbasis layanan backend.

  Manifes Layanan LoadBalancer yang menghilangkan anotasi cloud.google.com/l4-rbs: "enabled" akan membuat Load Balancer Jaringan passthrough eksternal berbasis kumpulan target. Penggunaan Load Balancer Jaringan passthrough eksternal berbasis kumpulan target tidak lagi direkomendasikan.

• 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.

  Untuk membuat Service LoadBalancer internal:

  • Sebagai praktik terbaik, pastikan subsetelan GKE diaktifkan sehingga GKE dapat mengelompokkan node secara efisien menggunakan grup endpoint jaringan (NEG) GCE_VM_IP. Subsetelan GKE tidak diperlukan, tetapi sangat direkomendasikan.

  • Sertakan anotasi networking.gke.io/load-balancer-type: "Internal" dalam manifes Layanan.

Pengaruh externalTrafficPolicy

Parameter externalTrafficPolicy mengontrol hal berikut:

• Node yang menerima paket dari load balancer
• Apakah paket dapat dirutekan di antara 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 aktif, siap, dan tidak berhenti, yang mempertahankan alamat IP sumber klien asli. Opsi ini paling cocok untuk workload dengan jumlah node yang relatif konstan dengan Pod aktif, meskipun jumlah node secara keseluruhan dalam cluster bervariasi. Opsi ini diperlukan untuk mendukung load balancing berbobot.

• Gunakan externalTrafficPolicy: Cluster dalam situasi saat 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 menambahkan 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 Service LoadBalancer internal, externalTrafficPolicy juga secara tidak langsung menentukan jumlah node dengan Pod aktif 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 aktif menerima proporsi koneksi baru yang lebih besar dibandingkan dengan node dengan lebih sedikit Pod aktif.

Catatan: Load balancing berbobot untuk Layanan LoadBalancer Eksternal masih dalam Pratinjau.

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.

• Add-on HttpLoadBalancing harus diaktifkan untuk cluster Anda. Add-on ini diaktifkan secara default. Fungsi ini memungkinkan cluster mengelola load balancer yang menggunakan layanan backend.

• Anda harus menyertakan anotasi cloud.google.com/l4-rbs: "enabled" dalam manifes Layanan LoadBalancer agar GKE membuat Load Balancer Jaringan passthrough eksternal berbasis layanan backend. Load Balancer Jaringan passthrough eksternal berbasis kumpulan target tidak mendukung load balancing berbobot.

• Anda harus menyertakan anotasi networking.gke.io/weighted-load-balancing: pods-per-node dalam manifes Service LoadBalancer 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 lain.

Untuk informasi selengkapnya tentang load balancing berbobot dari perspektif load balancer, lihat Load balancing berbobot di Load Balancer Jaringan passthrough eksternal berbasis layanan backend.

Pertimbangan khusus untuk Service LoadBalancer internal

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

Subsetelan GKE

Praktik terbaik:

Aktifkan subsetelan GKE untuk meningkatkan skalabilitas Service LoadBalancer internal.

Subsetelan GKE, yang juga disebut subsetelan GKE untuk load balancer internal Lapisan 4, adalah opsi konfigurasi seluruh cluster yang 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 Layanan memiliki dua Pod. GKE membuat satu NEG GCE_VM_IP untuk setiap Layanan. Endpoint di setiap NEG adalah node dengan Pod aktif untuk masing-masing Layanan.

Anda dapat mengaktifkan subsetelan GKE saat membuat cluster atau dengan mengupdate cluster yang ada. Setelah diaktifkan, Anda tidak dapat menonaktifkan subsetting GKE. Subsetelan GKE memerlukan:

• GKE versi 1.18.19-gke.1400 atau yang lebih baru, dan
• Add-on HttpLoadBalancing diaktifkan untuk cluster. Add-on ini diaktifkan secara default. Fungsi ini memungkinkan cluster mengelola load balancer yang menggunakan layanan backend.

Catatan: Subsetelan GKE berbeda dengan subsetelan backend Load Balancer Jaringan passthrough internal Google Cloud. 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 total node lebih dari 250.

• Layanan LoadBalancer internal yang menggunakan externalTrafficPolicy: Local di cluster yang mengaktifkan subsetelan GKE mendukung hingga 250 node dengan Pod aktif yang mendukung Layanan ini.

• Layanan LoadBalancer internal yang menggunakan externalTrafficPolicy: Cluster di cluster yang mengaktifkan subsetelan GKE tidak memberlakukan batasan apa pun pada jumlah node dengan Pod aktif, karena GKE mengonfigurasi tidak lebih dari 25 endpoint node di NEG GCE_VM_IP. Untuk mengetahui informasi selengkapnya, lihat Keanggotaan node di backend NEG GCE_VM_IP.

Pengelompokan node

Anotasi manifes Service dan untuk Service LoadBalancer Internal, status subsetelan GKE menentukan load balancer Google Cloud yang dihasilkan dan jenis backend. Backend untuk load balancer passthrough Google Cloud mengidentifikasi antarmuka jaringan (NIC) node GKE, bukan node atau alamat IP Pod tertentu. Jenis load balancer dan backend menentukan cara node dikelompokkan ke dalam NEG GCE_VM_IP, grup instance, atau kumpulan target.

Service LoadBalancer GKE	Menghasilkan load balancer Google Cloud	Metode pengelompokan node
Service LoadBalancer Internal yang dibuat di cluster dengan subsetelan GKE diaktifkan^1	Load Balancer Jaringan passthrough internal yang layanan backend-nya menggunakan backend grup endpoint jaringan (NEG) GCE_VM_IP	VM Node dikelompokkan menurut zona menjadi NEG GCE_VM_IP per layanan berdasarkan externalTrafficPolicy Service dan jumlah node di cluster. externalTrafficPolicy Service juga mengontrol node mana yang lulus health check load balancer dan pemrosesan paket.
Service LoadBalancer Internal yang dibuat di cluster dengan subsetelan GKE dinonaktifkan	Load Balancer Jaringan passthrough internal yang layanan backend-nya menggunakan backend grup instance tidak terkelola di zona	Semua VM node ditempatkan ke dalam grup 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.
Service LoadBalancer Eksternal dengan cloud.google.com/l4-rbs: "enabled" anotasi^2	Load Balancer Jaringan passthrough eksternal berbasis layanan backend yang layanan backend-nya menggunakan backend grup instance tidak terkelola di zona	Semua VM node ditempatkan ke dalam grup 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.
Service LoadBalancer Eksternal tanpa cloud.google.com/l4-rbs: "enabled" anotasi^3	Load Balancer jaringan passthrough eksternal berbasis kumpulan target yang kumpulan targetnya berisi semua node cluster	Kumpulan target adalah API lama yang tidak tergantung pada grup instance. Semua node memiliki keanggotaan langsung di kumpulan target. externalTrafficPolicy Service mengontrol node mana yang lulus health check load balancer dan pemrosesan paket.

¹ Hanya Load Balancer Jaringan passthrough internal yang dibuat setelah mengaktifkan subsetelan GKE yang menggunakan NEG GCE_VM_IP. Setiap Service LoadBalancer internal yang dibuat sebelum mengaktifkan subsetelan GKE terus menggunakan backend grup instance tidak terkelola. Untuk mengetahui contoh dan panduan konfigurasi, lihat Membuat Service LoadBalancer internal.

²GKE tidak secara otomatis memigrasikan Service LoadBalancer eksternal yang sudah ada dari Load Balancer Jaringan passthrough eksternal berbasis kumpulan target ke Load Balancer Jaringan passthrough eksternal berbasis layanan backend. Untuk membuat Service LoadBalancer eksternal yang didukung oleh Load Balancer Jaringan passthrough eksternal berbasis layanan backend, Anda harus menyertakan anotasi cloud.google.com/l4-rbs: "enabled" di manifes Service pada saat pembuatan.

³Penghapusan anotasi cloud.google.com/l4-rbs: "enabled" dari Service LoadBalancer eksternal yang sudah ada dan didukung oleh Load Balancer Jaringan passthrough eksternal berbasis layanan backend tidak menyebabkan GKE membuat Load Balancer Jaringan passthrough eksternal berbasis kumpulan target. Untuk membuat Service LoadBalancer eksternal yang didukung oleh Load Balancer Jaringan passthrough eksternal berbasis kumpulan target, Anda harus menghilangkan anotasi cloud.google.com/l4-rbs: "enabled" dari manifes Service pada saat pembuatan.

Keanggotaan node di backend NEG GCE_VM_IP

Saat subsetelan GKE diaktifkan untuk sebuah cluster, GKE membuat NEG GCE_VM_IP unik di setiap zona untuk setiap Service LoadBalancer internal. 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 jenis GCE_VM_IP_PORT NEG zona yang digunakan untuk load balancing Ingress berbasis container. NEG GCE_VM_IP mengidentifikasi antarmuka jaringan VM node berdasarkan alamat IP node; namun, paket memiliki tujuan yang cocok dengan alamat IP aturan penerusan load balancer dan salah satu port yang dikonfigurasi untuk aturan penerusan.

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

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 untuk Service LoadBalancer internal. Lebih dari 250 node bisa ada di cluster, namun Load Balancer Jaringan passthrough internal hanya 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.

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 digunakan untuk:

• Load Balancer Jaringan passthrough internal yang dibuat untuk Service LoadBalancer internal saat subsetelan GKE dinonaktifkan.
• Load Balancer Jaringan passthrough eksternal berbasis layanan backend yang dibuat untuk Service LoadBalancer eksternal dengan anotasi cloud.google.com/l4-rbs: "enabled".
• Load Balancer Aplikasi Eksternal yang dibuat untuk resource Ingress GKE eksternal menggunakan pengontrol Ingress GKE, namun 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 jika memungkinkan:

• Aktifkan subsetelan GKE. Akibatnya, Service LoadBalancer internal yang baru menggunakan NEG GCE_VM_IP.
• 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 status load balancer. Sistem health check load balancer beroperasi di luar cluster dan berbeda dengan pemeriksaan kesiapan, keaktifan, atau startup 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 Layanan menentukan node mana yang lulus health check load balancer:

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 akan 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 satu Pod aktif yang siap dan tidak berhenti ada 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 berhenti 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 gagal dalam 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.	Port health check adalah port TCP 10256, kecuali Anda menentukan port health check kustom.

Jika load balancing berbobot diaktifkan, software kube-proxy atau cilium-agent akan menyertakan header respons dalam jawabannya ke health check load balancer. Header respons ini menentukan bobot yang sebanding dengan jumlah Pod yang ditayangkan, siap, dan tidak dihentikan di node. Load balancer merutekan koneksi baru ke Pod yang ditayangkan berdasarkan bobot ini.

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 dataplane 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 di node

externalTrafficPolicy menentukan apakah pemrosesan paket level node juga menjalankan penafsiran alamat jaringan sumber (SNAT) serta jalur yang diambil paket dari node ke Pod:

externalTrafficPolicy	Perilaku SNAT Node	Perilaku pemilihan rute
Cluster	Node mengubah alamat IP sumber paket yang di-load balanced agar cocok dengan alamat IP node yang menerimanya dari load balancer.	Node merutekan paket ke Pod aktif mana pun. Pod aktif mungkin ada di node yang sama atau tidak. Jika node yang menerima paket dari load balancer tidak memiliki Pod yang siap dan aktif, node akan merutekan paket ke node lain yang berisi Pod yang siap dan aktif. Paket respons dari Pod dirutekan dari node-nya kembali ke node yang menerima paket permintaan dari load balancer. Node pertama tersebut kemudian mengirimkan paket respons ke klien asli menggunakan Direct Server Return.
Local	Node tidak mengubah alamat IP sumber dari paket yang di-load balanced.	Dalam kebanyakan situasi, node merutekan paket ke Pod aktif yang berjalan di node dan menerima paket dari load balancer. Node tersebut mengirimkan paket respons ke klien asli menggunakan Direct Server Return. Hal ini adalah intent utama dari jenis kebijakan traffic ini. Dalam beberapa situasi, node menerima paket dari load balancer meskipun node tidak memiliki Pod yang siap dan tidak berhenti untuk Service. Situasi ini terjadi saat health check load balancer belum mencapai batas kegagalannya, tetapi Pod yang sebelumnya siap dan aktif tidak lagi siap atau dihentikan (misalnya, saat melakukan update berkelanjutan). Cara paket diproses dalam situasi ini tergantung pada versi GKE, apakah cluster menggunakan GKE Dataplane V2, dan nilai externalTrafficPolicy: Tanpa GKE Dataplane V2 di GKE 1.26 dan yang lebih baru, serta dengan GKE Dataplane V2 di GKE versi 1.26.4-gke.500 dan yang lebih baru, Proxy yang Menghentikan Endpoint diaktifkan. Paket dirutekan ke Pod yang berhenti sebagai upaya terakhir, jika semua kondisi berikut terpenuhi: Jika semua Pod aktif dihentikan dan externalTrafficPolicy adalah Cluster. Jika semua Pod aktif di node dihentikan dan externalTrafficPolicy adalah Local. Untuk semua versi GKE lainnya, paket dijawab oleh kernel node dengan reset TCP.

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 kalkulator harga Google Cloud.

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 selanjutnya

• Pelajari parameter Service LoadBalancer GKE.
• Pelajari Layanan Kubernetes.