Load balancing yang dipaketkan memungkinkan Anda menjalankan load balancer untuk cluster Google Distributed Cloud di node cluster itu sendiri. Keepalived dan HAProxy melayani alamat IP virtual (VIP) bidang kontrol, dan MetalLB dalam mode Lapisan 2 menyediakan load balancing bidang data untuk Service jenis LoadBalancer.
Load balancer dapat berjalan di node bidang kontrol atau di node pool load balancer khusus. Anda juga dapat menjalankan load balancer bidang kontrol dan bidang data di node yang berbeda.
Untuk contoh topologi load balancing yang didukung, lihat Ringkasan load balancer.
Persyaratan
- Semua node load balancer harus berada di subnet Lapisan 2 yang sama.
- Semua VIP harus berada di subnet node load balancer dan dapat dirutekan melalui gateway subnet.
- Gateway subnet load balancer harus memproses pesan ARP serampangan dan meneruskan paket ARP ke node load balancer.
Kolom konfigurasi
Edit bagian cluster.spec.loadBalancer pada file konfigurasi cluster
untuk mengonfigurasi load balancing yang dipaketkan. Untuk mengetahui informasi tentang file konfigurasi cluster dan contoh konfigurasi yang valid, lihat salah satu halaman berikut:
loadBalancer.mode
Nilai ini harus bundled untuk mengaktifkan load balancing yang dipaketkan.
loadBalancer.ports.controlPlaneLBPort
Nilai ini menentukan port tujuan yang akan digunakan untuk traffic yang dikirim ke bidang kontrol Kubernetes (server Kubernetes API).
loadBalancer.vips.controlPlaneVIP
Nilai ini menentukan alamat IP tujuan yang akan digunakan untuk traffic yang dikirim ke bidang kontrol Kubernetes (server Kubernetes API). Alamat IP ini harus berada di subnet Lapisan 2 yang sama dengan node dalam cluster. Jangan cantumkan alamat ini di bagian address pools pada file konfigurasi.
loadBalancer.vips.ingressVIP
Nilai ini menentukan alamat IP yang akan digunakan untuk Service di balik load balancer untuk traffic masuk. Kolom ini tidak diizinkan dalam file konfigurasi cluster admin. Alamat ini harus tercantum di bagian kumpulan alamat pada konfigurasi.
loadBalancer.addressPools
Bagian konfigurasi ini berisi satu atau beberapa kumpulan alamat. Setiap kumpulan alamat menentukan daftar rentang alamat IP. Saat Anda membuat
Service jenis LoadBalancer,
alamat IP eksternal untuk Service dipilih dari rentang ini.
Kumpulan alamat ditentukan dalam format berikut:
- name: POOL_NAME
avoidBuggyIPs: BOOLEAN
manualAssign: BOOLEAN
addresses:
- IP_RANGE
- IP_RANGE2
name: Nama kumpulan alamat, pool-name, untuk tujuan organisasi Anda sendiri. Kolom ini tidak dapat diubah.avoidBuggyIPs: (Opsional)trueataufalse. Jikatrue, kumpulan akan menghilangkan alamat IP yang diakhiri dengan.0dan.255. Beberapa hardware jaringan menghentikan traffic ke alamat khusus ini. Anda dapat menghapus kolom ini, nilai defaultnya adalahfalse. Kolom ini dapat diubah.manualAssign: (Opsional)trueataufalse. Jikatrue, alamat dalam kumpulan ini tidak ditetapkan secara otomatis ke Service Kubernetes. Jikatrue, alamat IP di kumpulan ini hanya digunakan jika ditentukan secara eksplisit oleh layanan. Anda dapat menghapus kolom ini, nilai defaultnya adalahfalse. Kolom ini dapat diubah.addressesDaftar satu atau beberapa rentang alamat IP yang tidak tumpang-tindih. ip-range dapat ditentukan dalam notasi CIDR (seperti198.51.100.0/24) atau notasi rentang (seperti198.51.100.0-198.51.100.10, tanpa spasi di sekitar tanda hubung). Kolom ini tidak dapat diubah.
Rentang alamat IP dalam daftar addresses tidak boleh tumpang-tindih dan harus berada di subnet yang sama dengan node yang menjalankan load balancer.
loadBalancer.nodePoolSpec
Bagian konfigurasi ini menentukan daftar node untuk menjalankan load balancer. Node load balancer dapat menjalankan workload reguler secara default; tidak ada taint khusus pada node tersebut. Meskipun node di node pool load balancer dapat menjalankan workload, node tersebut terpisah dari node di node pool worker. Anda tidak dapat menyertakan node cluster tertentu di lebih dari satu node pool. Alamat IP node yang tumpang-tindih antara node pool akan memblokir pembuatan cluster dan operasi cluster lainnya.
Jika Anda ingin mencegah workload berjalan di node dalam node pool load balancer, tambahkan taint berikut ke node:
node-role.kubernetes.io/load-balancer:NoSchedule
Google Distributed Cloud menambahkan toleransi untuk taint ini ke pod yang diperlukan untuk load balancing.
Contoh berikut menunjukkan node pool load balancing dengan dua node. Node pertama
memiliki alamat IP standar nodePoolSpec.nodes.address ('1.2.3.4') dan
alamat IP Kubernetes nodePoolSpec.nodes.k8sIP (10.0.0.32). Saat Anda menentukan
alamat k8sIP opsional untuk sebuah node, alamat tersebut dikhususkan untuk menangani traffic data
untuk node tersebut, seperti permintaan dan respons untuk Kubernetes API, kubelet, dan workload. Dalam hal ini, alamat IP standar
nodePoolSpec.nodes.address digunakan untuk koneksi SSH ke node untuk
operasi cluster administratif. Jika Anda tidak menentukan alamat k8sIP, alamat IP node standar akan menangani semua traffic untuk node tersebut.
nodePoolSpec:
nodes:
- address: 1.2.3.4
k8sIP: 10.0.0.32
- address: 10.0.0.33
Secara default, semua node di node pool load balancer harus berada di subnet Lapisan 2 yang sama dengan VIP load balancer yang dikonfigurasi di bagian loadBalancer.addressPools pada file konfigurasi.
Namun, jika Anda menentukan alamat IP Kubernetes k8sIP untuk sebuah node, hanya alamat tersebut yang harus berada di subnet Lapisan 2 yang sama dengan VIP load balancer lainnya.
Jika nodePoolSpec tidak ditetapkan, load balancer yang dipaketkan akan berjalan di node bidang kontrol. Sebaiknya jalankan load balancer di node pool terpisah jika memungkinkan.
Load balancing bidang kontrol
Load balancer bidang kontrol menyalurkan alamat IP virtual (VIP) bidang kontrol. Google Distributed Cloud menjalankan Keepalived dan HAProxy sebagai pod statis Kubernetes di node load balancer untuk mengumumkan VIP bidang kontrol. Keepalived menggunakan Virtual Router Redundancy Protocol (VRRP) pada node load balancer untuk ketersediaan tinggi.
Load balancing bidang data
Load balancer bidang data ditujukan untuk semua Service Kubernetes jenis
LoadBalancer.
Google Distributed Cloud menggunakan MetalLB yang berjalan dalam mode Lapisan 2 untuk load balancing bidang data. Load balancing bidang data
hanya dapat dikonfigurasi melalui Google Distributed Cloud, jangan mengubah ConfigMap MetalLB
secara langsung. Anda dapat menggunakan semua fitur MetalLB, termasuk berbagi alamat IP di seluruh Service.
Lihat dokumentasi MetalLB untuk mengetahui informasi fitur.
MetalLB menjalankan Pod speaker di setiap node menggunakan daemonset, menggunakan memberlist untuk ketersediaan tinggi. Ada node load balancer khusus MetalLB untuk setiap Service Kubernetes, bukan satu node untuk seluruh cluster. Dengan cara ini, traffic didistribusikan ke seluruh node load balancer jika ada beberapa Service.
Load balancer bidang data dapat berjalan di node bidang kontrol atau di subset worker node. Menggabungkan load balancer bidang data pada node bidang kontrol akan meningkatkan pemanfaatan node bidang kontrol. Selain itu, penggabungan pada node bidang kontrol juga meningkatkan risiko kelebihan beban pada bidang kontrol dan meningkatkan profil risiko informasi rahasia pada bidang kontrol, seperti kunci SSH.
Pemisahan load balancer
Sebelum rilis 1.32, saat Anda mengonfigurasi load balancing Lapisan 2 dengan MetalLB, load balancer bidang kontrol dan load balancer bidang data berjalan di node yang sama. Bergantung pada konfigurasi Anda, semua load balancer berjalan di node bidang kontrol atau semuanya berjalan di node pool load balancer.
Diagram berikut menunjukkan konfigurasi load balancer paket default dengan load balancer bidang kontrol dan bidang data yang berjalan di node bidang kontrol atau keduanya berjalan di node pool load balancer:
Dengan cluster versi 1.32, Anda dapat mengonfigurasi load balancer bidang kontrol untuk berjalan di node bidang kontrol dan load balancer bidang data untuk berjalan di node pool load balancer. Anda dapat menentukan pemisahan load balancer ini saat membuat cluster versi 1.32 baru, atau Anda dapat mengupdate cluster versi 1.32 untuk memigrasikan load balancer bidang data dari node bidang kontrol ke node pool load balancer.
Konfigurasi cluster untuk load balancer yang dipisahkan akan terlihat seperti contoh berikut:
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: hybrid-ha-lb
namespace: cluster-hybrid-ha-lb
spec:
type: hybrid
profile: default
anthosBareMetalVersion: 1.36
gkeConnect:
projectID: project-fleet
controlPlane:
loadBalancer:
mode: bundled
nodePoolSpec:
nodes:
- address: 10.200.0.2
- address: 10.200.0.3
- address: 10.200.0.4
clusterNetwork:
pods:
cidrBlocks:
- 192.168.0.0/16
services:
cidrBlocks:
- 10.96.0.0/20
...
loadBalancer:
mode: bundled
...
nodePoolSpec:
nodes:
- address: 10.200.0.5
- address: 10.200.0.6
- address: 10.200.0.7
clusterOperations:
...
Load balancer terpisah saat membuat cluster
Jika Anda membuat cluster versi 1.32 atau yang lebih baru, Anda dapat mengonfigurasi load balancer untuk menjalankan load balancer bidang kontrol di node bidang kontrol dan load balancer bidang data di node pool load balancer.
Diagram berikut menunjukkan load balancer bidang kontrol dan bidang data yang dipisahkan ke node yang berbeda:
Untuk memisahkan load balancer saat Anda membuat cluster, gunakan langkah-langkah berikut:
Dalam file konfigurasi cluster, tentukan node pool load balancer dengan
loadBalancer.nodePoolSpecseperti yang dijelaskan di bagianloadBalancer.nodePoolSpecdalam dokumen ini.Tambahkan
controlPlane.loadBalancer.modeke file konfigurasi cluster dan tetapkan nilaimodekebundled.Selesaikan konfigurasi cluster Anda dan jalankan
bmctl create clusteruntuk membuat cluster.
Memigrasikan load balancer bidang data dari bidang kontrol
Jika Anda memiliki cluster versi 1.32 atau yang lebih tinggi yang tidak menetapkan
controlPlane.loadBalancer.mode atau loadBalancer.nodePoolSpec, load balancer bidang kontrol dan load balancer bidang data akan berjalan di
node pool bidang kontrol. Anda dapat mengupdate cluster untuk memigrasikan load balancer bidang data ke node pool load balancer.
Diagram berikut menunjukkan load balancer bidang kontrol dan bidang data yang dipisahkan setelah load balancer bidang data dimigrasikan dari node bidang kontrol:
Untuk memigrasikan load balancer bidang data ke node pool load balancer saat Anda mengupdate cluster, gunakan langkah-langkah berikut:
Dalam file konfigurasi cluster, tentukan node pool load balancer dengan
loadBalancer.nodePoolSpecseperti yang dijelaskan di bagianloadBalancer.nodePoolSpecdalam dokumen ini.Tambahkan
controlPlane.loadBalancer.modeke file konfigurasi cluster dan tetapkan nilaimodekebundled.Update cluster dengan menjalankan perintah berikut:
bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIGGanti kode berikut:
CLUSTER_NAME: nama cluster yang Anda perbarui.ADMIN_KUBECONFIG: jalur file kubeconfig cluster admin.
Mempertahankan alamat IP sumber klien
Service LoadBalancer yang dibuat dengan solusi load balancing Lapisan 2 yang dipaketkan menggunakan setelan Cluster default untuk kebijakan traffic eksternal.
Setelan ini, spec.externalTrafficPolicy: Cluster, merutekan traffic eksternal ke endpoint di seluruh cluster, tetapi juga menyamarkan alamat IP sumber klien.
Google Distributed Cloud mendukung dua metode untuk mempertahankan alamat IP sumber klien:
Tetapkan mode penerusan untuk load balancing ke Direct Server Return (DSR). Untuk mengetahui informasi selengkapnya tentang mode penerusan DSR, termasuk petunjuk untuk mengaktifkannya, lihat Mengonfigurasi mode penerusan load balancing.
Tetapkan kebijakan traffic eksternal ke lokal untuk Service
LoadBalancerdan konfigurasikan Service dan Ingress terkait. Bagian berikut menjelaskan cara mengonfigurasi cluster Anda untuk menggunakan metode ini.
Layanan LoadBalancer
Saat menggunakan externalTrafficPolicy: Local di Layanan LoadBalancer, tetapkan pod aplikasi Anda agar berjalan tepat di node load balancer. Tambahkan nodeSelector berikut ke pod aplikasi Anda untuk melakukan perubahan ini:
apiVersion: v1
kind: Pod
...
spec:
nodeSelector:
baremetal.cluster.gke.io/lbnode: "true"
...
Layanan NodePort
Kubernetes melakukan penafsiran alamat jaringan sumber (SNAT) untuk Service NodePort. Untuk mempertahankan alamat IP sumber klien, tetapkan service.spec.externalTrafficPolicy ke Local. Kubernetes tidak akan lagi menjalankan SNAT, tetapi Anda harus memastikan ada pod yang berjalan tepat di IP node yang Anda pilih.
Masuk
Jika aplikasi Anda adalah layanan HTTP, Anda dapat mencapai visibilitas IP klien dengan mengonfigurasi komponen ingress:
Buka Service
istio-ingressuntuk mengedit:kubectl edit service -n gke-system istio-ingressTambahkan
externalTrafficPolicy: Localkespec, simpan, dan keluar dari editor.apiVersion: v1 kind: Service ... spec: ... externalTrafficPolicy: LocalBuka Deployment
istio-ingressuntuk mengedit:kubectl edit deployment -n gke-system istio-ingressTambahkan
nodeSelectorberikut ke Deployment, simpan, dan keluar dari editor.apiVersion: apps/v1 kind: Deployment ... spec: ... template: ... spec: ... nodeSelector: baremetal.cluster.gke.io/lbnode: "true" ...
Sekarang, semua layanan Anda di belakang Ingress akan melihat header X-Forwarded-For dengan IP klien, seperti contoh berikut:
X-Forwarded-For: 21.0.104.4