Konsep Service LoadBalancer

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 berbagai jenis load balancer dan cara setelan seperti subsetelan externalTrafficPolicy dan GKE untuk load balancer internal L4 menentukan cara load balancer dikonfigurasi.

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

Ringkasan

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

Memilih Service LoadBalancer

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

  • Jenis alamat IP LoadBalancer. Load balancer Anda dapat memiliki alamat IP internal atau eksternal.
  • Jumlah dan jenis node yang didukung LoadBalancer.

Setelah menentukan persyaratan arsitektur jaringan, gunakan pohon keputusan berikut untuk menentukan Service LoadBalancer yang harus dipilih untuk konfigurasi jaringan Anda.

Service LoadBalancer di GKE dapat memiliki alamat internal atau eksternal.
Gambar: Pohon keputusan Service LoadBalancer

Load balancing eksternal versus internal

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

  • Jika klien Anda berada di jaringan VPC yang sama atau dalam jaringan yang terhubung ke cluster (jaringan VPC), gunakan Service LoadBalancer Internal. 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 menggunakan alamat IP load balancer.

    Untuk membuat Service LoadBalancer internal, sertakan salah satu anotasi berikut di metadata.annotations[] manifes Service:

    • networking.gke.io/load-balancer-type: "Internal" (GKE 1.17 dan yang lebih baru)
    • cloud.google.com/load-balancer-type: "Internal" (versi lebih lama dari 1.17)

  • Jika klien Anda berada di luar jaringan VPC, gunakan Service LoadBalancer eksternal. Anda dapat menggunakan salah satu jenis Load Balancer Jaringan passthrough eksternal berikut yang dapat diakses di internet (termasuk VM Google Cloud dengan akses internet):

Pengaruh externalTrafficPolicy

Anda dapat menetapkan externalTrafficPolicy ke Local atau Cluster untuk menentukan cara paket dirutekan ke node dengan Pod yang siap dan aktif. Pertimbangkan skenario berikut saat menentukan externalTrafficPolicy:

  • Gunakan externalTrafficPolicy: Local untuk mempertahankan alamat IP klien asli atau jika Anda ingin meminimalkan gangguan saat jumlah node tanpa Pod aktif di cluster berubah.

  • Gunakan externalTrafficPolicy: Cluster jika jumlah keseluruhan node tanpa Pod aktif di cluster tetap konsisten, tetapi jumlah node dengan Pod aktif berubah. Opsi ini tidak mempertahankan alamat IP klien asli.

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

Subsetelan GKE

Opsi konfigurasi seluruh cluster subsetelan GKE untuk load balancer internal L4, atau subsetelan GKE, meningkatkan skalabilitas Load Balancer Jaringan passthrough internal dengan mengelompokkan endpoint node secara lebih efisien untuk backend load balancer.

Diagram berikut menunjukkan dua Service di cluster zona dengan tiga node dan subsetelan GKE yang diaktifkan. Setiap Service memiliki dua Pod. GKE membuat satu grup endpoint jaringan (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 mengedit cluster yang sudah ada. Setelah diaktifkan, Anda tidak dapat menonaktifkan subsetelan GKE. Untuk mengetahui informasi selengkapnya, lihat 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.

Pertimbangan jumlah node saat mengaktifkan subsetelan GKE

Sebagai praktik terbaik, jika perlu membuat Service LoadBalancer internal, Anda harus mengaktifkan subsetelan GKE. Dengan subsetelan GKE, Anda dapat mendukung lebih banyak node di cluster:

  • Jika subsetelan GKE di cluster dinonaktifkan, Anda tidak boleh membuat lebih dari 250 total node (di antara semua node pool). Jika Anda membuat lebih dari 250 total node di cluster, Service LoadBalancer internal dapat mengalami distribusi traffic yang tidak merata atau kehilangan konektivitas sepenuhnya.

  • Jika cluster memiliki subsetelan GKE yang diaktifkan, Anda dapat menggunakan externalTrafficPolicy: Local atau externalTrafficPolicy: Cluster, selama jumlah node unik dengan setidaknya satu Pod aktif tidak lebih dari 250 node. Node tanpa Pod aktif menjadi tidak relevan. Jika membutuhkan lebih dari 250 node dengan setidaknya satu Pod aktif, Anda harus menggunakan externalTrafficPolicy: Cluster.

Load Balancer Jaringan passthrough internal yang dibuat oleh GKE hanya dapat mendistribusikan paket ke 250 VM node backend atau kurang. Keterbatasan ini ada karena GKE tidak menggunakan subsetelan backend load balancer, dan Load Balancer Jaringan passthrough internal dibatasi untuk mendistribusikan paket ke 250 backend atau kurang saat subsetelan backend load balancer dinonaktifkan.

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 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 cloud.google.com/l4-rbs: "enabled" anotasi2 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.

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

2GKE 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.

3Penghapusan 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.

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 Layanan, meskipun jika node tidak berisi Pod yang aktif untuk Service.
Local sejumlah node1 GKE hanya menggunakan node yang memiliki setidaknya satu Pod aktif Service sebagai endpoint untuk NEG Service.

1Dibatasi 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 memerlukan health check load balancer. Health check load balancer diterapkan di luar cluster dan berbeda dengan pemeriksaan kesiapan atau keaktifan.

externalTrafficPolicy Service menentukan cara health check load balancer beroperasi. Dalam semua kasus, penguji health check load balancer mengirimkan paket ke software kube-proxy yang berjalan di setiap node. Health check load balancer adalah proxy untuk informasi yang dikumpulkan kube-proxy, seperti apakah Pod ada, sedang berjalan, dan telah lulus pemeriksaan kesiapan. Health check untuk Service LoadBalancer tidak dapat dirutekan ke Pod aktif. Health check load balancer dirancang untuk mengarahkan koneksi TCP baru ke node.

Tabel berikut menjelaskan perilaku health check:

externalTrafficPolicy Node yang lulus health check Port yang digunakan
Cluster Semua node cluster lulus health check meskipun node tersebut tidak memiliki Pod aktif. Jika ada satu atau beberapa Pod aktif di node, node tersebut melewati health check load balancer meskipun Pod aktif berhenti atau gagal dalam pemeriksaan kesiapan. Port health check load balancer harus berupa port TCP 10256. Hal ini tidak dapat disesuaikan.
Local

Hanya node dengan setidaknya satu Pod yang siap dan tidak berhenti yang akan lulus health check load balancer. Node tanpa Pod aktif, node yang semua Pod aktifnya gagal dalam pemeriksaan kesiapan, dan node yang semua Pod aktifnya gagal melewati health check load balancer.

Selama transisi status, node masih lulus health check load balancer hingga batas tidak responsif 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.

 Port health check adalah port TCP 10256, kecuali Anda menentukan port health check kustom.

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 passthrough Google Cloud merutekan paket ke antarmuka nic0 node cluster GKE. Setiap paket yang di-load balanced yang diterima oleh 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 tanpa GKE Dataplane V2 yang diaktifkan, 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:

Langkah selanjutnya