Tentang Service LoadBalancer

Halaman ini menyajikan ringkasan umum tentang cara Google Kubernetes Engine (GKE) membuat dan mengelola Trusted Cloud by S3NS load balancer saat Anda menerapkan manifes Service 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 Trusted 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

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

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

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

  Manifes Layanan LoadBalancer yang tidak menyertakan 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 agar GKE dapat mengelompokkan node secara efisien menggunakan grup endpoint jaringan (NEG) GCE_VM_IP. Subsetelan GKE tidak wajib, tetapi sangat direkomendasikan.

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

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.

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

Load balancing berbobot

Layanan LoadBalancer eksternal mendukung load balancing berbobot, yang memungkinkan node dengan lebih banyak Pod yang siap, aktif, dan tidak berhenti 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.

Seperti yang diilustrasikan diagram, Layanan dengan load balancing berbobot yang diaktifkan mendistribusikan koneksi baru secara proporsional ke jumlah Pod yang siap di setiap node, sehingga memastikan bahwa node dengan lebih banyak Pod menerima bagian koneksi baru yang lebih besar.

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 di 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 yang berbeda.

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

Afinitas zona

Layanan LoadBalancer Internal mendukung afinitas zona (Pratinjau), yang dapat merutekan koneksi baru ke node dengan Pod yang melayani di zona yang sama dengan klien. Mempertahankan traffic dalam satu zona dapat meminimalkan traffic lintas zona, yang mengurangi biaya dan latensi.

Untuk menggunakan afinitas zonal, lihat Menggunakan afinitas zonal. Untuk mengetahui informasi selengkapnya tentang cara konfigurasi load balancer berubah dengan afinitas zona, termasuk kapan Anda dapat mempertahankan traffic dalam zona, lihat Efek afinitas zona. 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 opsi 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

Praktik terbaik:

Aktifkan subsetelan GKE untuk meningkatkan skalabilitas Service LoadBalancer internal.

Subsetelan GKE, yang juga disebut subsetelan GKE untuk load balancer internal Layer 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 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.

Anda dapat mengaktifkan subsetelan GKE saat membuat cluster atau dengan mengupdate cluster yang sudah ada. Setelah diaktifkan, Anda tidak dapat menonaktifkan subsetelan 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.

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.

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

• Service LoadBalancer internal yang menggunakan externalTrafficPolicy: Cluster di cluster yang mengaktifkan subsetelan GKE tidak membatasi 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.

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 kondisi, 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 sebanding 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 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 yang 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 backend node yang memenuhi syarat awal 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 semua 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 Trusted Cloud yang dihasilkan dan jenis backend. Jenis load balancer dan backend menentukan cara node dikelompokkan ke dalam NEG GCE_VM_IP, grup instance, atau kumpulan target. Dalam semua keadaan,load balancer passthrough mengidentifikasi antarmuka jaringan (NIC) node GKE, bukan node atau alamat IP Pod tertentu. Trusted Cloud

Service LoadBalancer GKE	Load balancer Trusted Cloud yang dihasilkan	Metode pengelompokan node
Service LoadBalancer Internal yang dibuat di cluster dengan subsetelan GKE diaktifkan1	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 anotasi cloud.google.com/l4-rbs: "enabled"2 diterapkan ke cluster yang menjalankan GKE versi 1.32.2-gke.1652000 atau yang lebih baru4	Load Balancer Jaringan passthrough eksternal berbasis layanan backend 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 Eksternal dengan anotasi cloud.google.com/l4-rbs: "enabled"2 yang diterapkan ke cluster yang menjalankan GKE versi sebelum 1.32.2-gke.16520004	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" anotasi3	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.

Keanggotaan node di backend NEG GCE_VM_IP

Saat subsetelan GKE diaktifkan untuk cluster, atau Load Balancer Jaringan passthrough eksternal dengan cloud.google.com/l4-rbs: "enabled" dibuat di GKE versi 1.32.2-gke.1652000 atau yang lebih baru, GKE membuat NEG GCE_VM_IP unik di setiap zona untuk setiap Layanan 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.

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.

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 node1	GKE hanya menggunakan node yang memiliki setidaknya satu Pod aktif Service sebagai endpoint untuk NEG Service.

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 node1	GKE hanya menggunakan node yang memiliki setidaknya satu Pod aktif Service sebagai endpoint untuk NEG Service.

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 kondisi 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 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 pemilihan rute 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 diaktifkan1, 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 mengirimkan paket respons menggunakan Direct Server Return. Jika node dengan Pod yang melayani 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 yang 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 Endpoint Penghentian Proxy diaktifkan1, node yang menerima paket yang di-load balance akan merutekannya ke Pod lokal yang aktif, tetapi menghentikan Pod 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.

Kuota

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 Layanan LoadBalancer GKE.
• Pelajari Service Kubernetes.