Mengelola load balancer

Halaman ringkasan ini menjelaskan cara mengonfigurasi load balancer internal dan eksternal di Google Distributed Cloud (GDC) yang terisolasi untuk konfigurasi jaringan zonal dan global.

Load balancing untuk GDC memastikan distribusi traffic yang efisien di seluruh workload backend, sehingga meningkatkan ketersediaan dan performa aplikasi. Algoritma yang digunakan untuk mendistribusikan traffic adalah Maglev; untuk mengetahui detail selengkapnya, lihat Algoritma load balancing.

Halaman ini ditujukan bagi administrator jaringan dalam grup administrator platform, atau developer dalam grup operator aplikasi, yang bertanggung jawab untuk mengelola traffic jaringan bagi organisasi mereka. Untuk mengetahui informasi selengkapnya, lihat dokumentasi Audiens untuk GDC yang terisolasi dari internet.

Arsitektur load balancing

GDC menyediakan load balancer yang memungkinkan aplikasi mengekspos layanan satu sama lain. Load balancer mengalokasikan alamat IP virtual (VIP) yang stabil yang menyeimbangkan traffic di serangkaian workload backend. Load balancer di GDC melakukan load balancing lapisan empat (L4), yang berarti load balancer tersebut memetakan serangkaian port TCP atau UDP frontend yang dikonfigurasi ke port backend yang sesuai. Load balancer dikonfigurasi di tingkat project.

Load balancer dikonfigurasi untuk jenis workload berikut:

  • Workload yang berjalan di VM.
  • Workload dalam container di dalam cluster Kubernetes.

Ada tiga cara untuk mengonfigurasi load balancer di GDC:

  • Gunakan Networking Kubernetes Resource Model (KRM) API. Anda dapat menggunakan API ini untuk membuat load balancer global atau zonal.
  • Gunakan gdcloud CLI. Anda dapat menggunakan API ini untuk membuat load balancer global atau zonal.
  • Gunakan Layanan Kubernetes langsung dari cluster Kubernetes. Metode ini hanya membuat load balancer zonal.

Komponen load balancer

Saat menggunakan KRM API atau gcloud CLI untuk mengonfigurasi load balancer, Anda menggunakan load balancer penerusan L4:

  • L4 berarti protokolnya adalah TCP atau UDP.
  • Passthrough berarti tidak ada proxy antara beban kerja dan klien.

Load balancer terdiri dari komponen yang dapat dikonfigurasi berikut:

  • Aturan penerusan: menentukan traffic yang diteruskan, dan ke layanan backend mana. Aturan penerusan memiliki spesifikasi berikut:

    • Terdiri dari tiga tuple, CIDR, port, dan protokol, untuk diakses klien.
    • Mendukung protokol TCP dan UDP.
    • Menawarkan aturan penerusan internal dan eksternal. Klien dapat mengakses aturan penerusan internal dari dalam Virtual Private Cloud (VPC). Klien dapat mengakses aturan penerusan eksternal dari luar platform GDC atau dari dalam oleh workload yang memiliki nilai EgressNAT yang ditentukan.
    • Aturan penerusan terhubung ke layanan backend. Anda dapat mengarahkan beberapa aturan penerusan untuk mengarah ke layanan backend yang sama.

  • Layanan backend: adalah hub load balancing yang menghubungkan aturan penerusan, health check, dan backend. Layanan backend mereferensikan objek backend yang mengidentifikasi workload yang menjadi tujuan penerusan traffic oleh load balancer. Ada batasan pada backend yang dapat dirujuk oleh satu layanan backend:

    • Satu resource backend zona per zona.
    • Satu resource backend cluster per cluster. Hal ini tidak dapat digabungkan dengan backend project.

  • Backend: objek zonal yang menentukan endpoint yang berfungsi sebagai backend untuk layanan backend yang dibuat. Resource backend harus dicakup ke zona. Pilih endpoint menggunakan label. Cakupan pemilih ke project atau cluster:

    • Backend project adalah backend yang tidak menentukan kolom ClusterName. Dalam hal ini, label yang ditentukan berlaku untuk semua beban kerja dalam project tertentu, di VPC zona tertentu. Label diterapkan ke workload VM dan pod di beberapa cluster. Saat layanan backend menggunakan backend project, Anda tidak dapat mereferensikan backend lain untuk zona tersebut di layanan backend tersebut.

    • Backend cluster adalah backend yang memiliki kolom ClusterName yang ditentukan. Dalam hal ini, label yang ditentukan berlaku untuk semua beban kerja dalam cluster bernama di project yang ditentukan. Anda dapat menentukan paling banyak satu backend per zona per cluster dalam satu layanan backend.

  • Health check: menentukan pemeriksaan untuk menentukan apakah endpoint workload tertentu di backend responsif atau tidak. Endpoint yang tidak responsif akan dikeluarkan dari load balancer, hingga endpoint tersebut responsif kembali. Pemeriksaan kondisi hanya berlaku untuk workload VM. Workload Pod dapat menggunakan mekanisme pemeriksaan Kubernetes bawaan untuk menentukan apakah endpoint tertentu berfungsi dengan baik. Lihat health check untuk mengetahui informasi selengkapnya.

Saat menggunakan Layanan Kubernetes langsung dari cluster pengguna Kubernetes, Anda menggunakan objek Service, bukan komponen yang tercantum sebelumnya. Anda hanya dapat menargetkan workload di cluster tempat objek Service dibuat.

Load balancing eksternal dan internal

Aplikasi GDC memiliki akses ke jenis layanan jaringan berikut:

  • Load Balancer Internal (ILB): memungkinkan Anda mengekspos layanan ke cluster lain dalam organisasi.
  • Load Balancer Eksternal (ELB): mengalokasikan alamat IP Virtual (VIP) dari rentang yang dapat dirutekan dari workload eksternal dan mengekspos layanan di luar organisasi GDC, seperti organisasi lain di dalam atau di luar instance GDC. Gunakan afinitas sesi untuk ELB guna memastikan bahwa permintaan dari klien secara konsisten dirutekan ke backend yang sama.

Load balancer global dan zonal

Anda dapat membuat load balancer global atau zonal. Cakupan load balancer global mencakup seluruh semesta GDC. Setiap semesta GDC dapat terdiri dari beberapa zona GDC yang disusun ke dalam region yang saling terhubung dan berbagi bidang kontrol. Misalnya, semesta yang terdiri dari dua region dengan masing-masing tiga zona mungkin terlihat seperti: us-virginia1-a, us-virginia1-b, us-virginia1-c dan eu-ams1-a, eu-ams1-b, eu-ams1-c.

Cakupan load balancer zonal terbatas pada zona yang ditentukan pada saat pembuatan. Setiap zona adalah domain bencana independen. Zona mengelola infrastruktur, layanan, API, dan alat yang menggunakan bidang kontrol lokal.

Untuk mengetahui informasi selengkapnya tentang resource global dan zona di semesta GDC, lihat Ringkasan multi-zona.

Anda dapat membuat load balancer global menggunakan metode berikut:

Anda dapat membuat load balancer zonal menggunakan metode berikut:

  • Gunakan Networking Kubernetes Resource Model (KRM) API. Gunakan versi API networking.gdc.goog untuk membuat resource zona.
  • Gunakan gdcloud CLI. Gunakan flag --zone saat menggunakan perintah gdcloud CLI untuk menentukan zona tempat load balancer akan dibuat.
  • Gunakan Service Kubernetes langsung dari cluster Kubernetes.

Alamat IP virtual layanan

ILB mengalokasikan alamat VIP yang hanya bersifat internal bagi organisasi. Alamat VIP ini tidak dapat dijangkau dari luar organisasi; oleh karena itu, Anda hanya dapat menggunakannya untuk mengekspos layanan ke aplikasi lain dalam organisasi. Alamat IP ini mungkin tumpang-tindih antar-organisasi dalam instance yang sama.

Di sisi lain, ELB mengalokasikan alamat VIP yang dapat dijangkau secara eksternal dari luar organisasi. Oleh karena itu, alamat VIP ELB harus unik di antara semua organisasi. Biasanya, lebih sedikit alamat VIP ELB yang tersedia untuk digunakan oleh organisasi.

Algoritma load balancing

Load Balancer kami menggunakan Maglev, algoritma hashing yang konsisten, untuk mendistribusikan traffic masuk ke target backend. Algoritma ini dirancang untuk performa dan ketahanan tinggi, memastikan traffic didistribusikan secara merata dan dapat diprediksi, sekaligus memaksimalkan lokalitas data di backend.

Cara kerja Maglev: mekanisme hashing

Maglev membuat keputusan penerusan dengan melakukan hashing pada properti setiap paket masuk. Hal ini memastikan bahwa semua paket untuk koneksi tertentu dikirim secara konsisten ke backend yang sama untuk memaksimalkan lokalitas data.

  • Input Hashing (5-tuple): Algoritma ini menggunakan 5-tuple standar dari header paket untuk menghasilkan hash. Tuple ini terdiri dari:
    1. Alamat IP Sumber
    2. Port Sumber
    3. Alamat IP Tujuan
    4. Port Tujuan
    5. Protokol (misalnya, TCP, UDP)
  • Keputusan Penerusan: Hasil hash ini secara deterministik memetakan koneksi ke salah satu backend yang sehat dalam kumpulan load balancing. Selama masa aktif koneksi tersebut, semua paketnya akan diteruskan ke backend yang sama.
  • Entropi untuk Penyeimbangan: Dengan menggunakan kelima elemen tuple, Maglev menghasilkan entropi yang cukup untuk memastikan bahwa koneksi yang berbeda didistribusikan secara merata di semua backend yang tersedia.

Menangani kesehatan dan kegagalan backend

Maglev dirancang agar tangguh dan meminimalkan gangguan saat set backend yang tersedia berubah.

  • Kegagalan Backend: Jika backend gagal dalam health check, backend tersebut akan dihapus dari daftar target yang tersedia. Koneksi yang sebelumnya dirutekan ke backend yang gagal akan dihentikan. Koneksi baru akan didistribusikan ulang secara otomatis di antara backend yang responsif yang tersisa berdasarkan algoritma hashing. Yang penting, koneksi ke backend responsif lainnya tidak terpengaruh atau dialihkan.
  • Pemulihan Backend: Saat backend yang tidak responsif menjadi responsif kembali dan ditambahkan kembali ke kumpulan, sifat hash yang konsisten memastikan backend ini ditambahkan ke kumpulan dengan gangguan minimal, dan LB akan menyeimbangkan kembali beban dengan mengambil backend yang baru responsif ini. Pendekatan "gangguan minimal" ini mencegah penataan ulang besar-besaran semua koneksi yang ada, yang dapat membebani cache atau status aplikasi.

Perilaku dalam deployment multi-zona

Penting untuk memahami bahwa Maglev tidak mengetahui topologi. Load balancer ini mendistribusikan traffic hanya berdasarkan hasil matematika hash, tanpa mempertimbangkan lokasi fisik atau jalur jaringan ke backend.

  • Distribusi yang Sama Terlepas dari Lokasi: Maglev memperlakukan semua backend dalam pool-nya sebagai target yang sama. Jika Anda memiliki backend yang tersebar di berbagai zona, traffic akan didistribusikan secara merata di antara semuanya. Algoritma tidak memilih backend di zona "lokal" atau memperhitungkan latensi jaringan antar-zona.
  • Memastikan kapasitas MultiZone Interconnect:Karena backend dapat mencakup beberapa Zona, administrator jaringan harus memastikan bahwa MultiZone Interconnect memiliki kapasitas jaringan yang memadai untuk menangani traffic Lintas Zona antara node Load Balancer dan backend.

Batasan

  • Resource BackendService tidak boleh dikonfigurasi dengan resource HealthCheck untuk beban kerja pod. HealthCheckName dalam spesifikasi BackendService bersifat opsional dan harus dihilangkan saat mengonfigurasi load balancer dengan pod.

  • Konfigurasi load balancer tidak dapat menargetkan workload campuran yang melibatkan pod dan VM. Oleh karena itu, backend campuran yang melibatkan pod dan VM dalam satu BackendService resource tidak diizinkan.

  • Resource kustom load balancer global, seperti ForwardingRuleExternal, ForwardingRuleInternal, BackendService, atau HealthCheck, tidak boleh memiliki nama yang sama dengan resource kustom load balancer zonal ini.

  • Organisasi dapat menentukan maksimum 500 aturan penerusan per zona tempat organisasi tersebut berada. Aturan penerusan global dihitung dalam batas ini untuk semua zona.

Batasan untuk cluster standar

Batasan berikut berlaku untuk load balancing untuk cluster standar:

Cakupan cluster tunggal

  • Cakupan cluster tunggal: Load Balancer (ILB atau ELB) yang disediakan untuk cluster standar menggunakan resource Service type=LoadBalancer harus menargetkan endpoint backend yang merupakan pod yang berlokasi secara eksklusif dalam satu cluster standar tersebut. Satu definisi Load Balancer yang mencoba mendistribusikan traffic ke pod yang berjalan di beberapa cluster standar yang berbeda, atau di campuran cluster standar dan cluster bersama, tidak didukung.

  • gdcloud CLI dan Networking Kubernetes Resource Model API tidak didukung untuk cluster standar. Gunakan resource Service Kubernetes standar dengan type=LoadBalancer dan anotasi terkait untuk mengelola load balancing untuk cluster standar.

  • Load balancer cakupan project akan mengabaikan cluster standar. Jika konfigurasi load balancer cakupan project dibuat menggunakan perintah gdcloud CLI atau Networking Kubernetes Resource Model API, konfigurasi tersebut akan mengabaikan cluster standar apa pun dalam project.

  • Load balancing global tidak didukung. Resource ILB dan ELB yang disediakan untuk cluster standar adalah resource zona yang dicakup ke satu zona. Load balancing global tidak didukung untuk load balancer cluster standar.

  • Konektivitas ILB lintas zona tidak didukung. Konektivitas dari pod cluster standar ke ILB global atau ILB zona di zona yang berbeda tidak didukung.

Langkah berikutnya