Mengonfigurasi load balancing gabungan dengan MetalLB

Halaman ini menjelaskan cara mengonfigurasi load balancing gabungan dengan MetalLB untuk Google Distributed Cloud. Load balancer MetalLB berjalan di kumpulan worker node khusus atau di node yang sama dengan bidang kontrol.

Lihat Ringkasan load balancer untuk mengetahui contoh topologi load balancing yang tersedia di Google Distributed Cloud.

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 gratis dan meneruskan paket ARP ke node load balancer.

Kolom konfigurasi

Edit bagian cluster.spec.loadBalancer dari file konfigurasi cluster untuk mengonfigurasi load balancing gabungan. Untuk mengetahui informasi tentang file konfigurasi cluster dan contoh konfigurasi yang valid, lihat salah satu halaman berikut:

• Membuat cluster admin
• Membuat cluster pengguna
• Membuat cluster hybrid
• Membuat cluster mandiri

loadBalancer.mode

Nilai ini harus berupa bundled untuk mengaktifkan load balancing gabungan.

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 di cluster. Jangan cantumkan alamat ini di bagian address pools file konfigurasi.

loadBalancer.vips.ingressVIP

Nilai ini menentukan alamat IP yang akan digunakan untuk Layanan di belakang load balancer untuk traffic ingress. Kolom ini tidak diizinkan dalam admin cluster file konfigurasi. Alamat ini harus dicantumkan di bagian kumpulan alamat konfigurasi.

loadBalancer.addressPools

Bagian konfigurasi ini berisi satu atau beberapa kumpulan alamat. Setiap kumpulan alamat menentukan daftar rentang alamat IP. Saat Anda membuat Layanan berjenis LoadBalancer, alamat IP eksternal untuk Layanan akan dipilih dari rentang ini.

Catatan: Mulai dari Google Distributed Cloud versi 1.16.0, Anda dapat mengupdate kumpulan alamat load balancer yang ada kapan saja untuk mengubah dua kolom berikut: avoidBuggyIPs dan manualAssign.

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) true atau false. Jika true, kumpulan akan menghilangkan alamat IP yang berakhiran .0 dan .255. Beberapa hardware jaringan akan menghilangkan traffic ke alamat khusus ini. Anda dapat menghilangkan kolom ini, nilai default-nya adalah false. Kolom ini dapat diubah.
• manualAssign: (Opsional) true atau false. Jika true, alamat di kumpulan ini tidak akan otomatis ditetapkan ke Layanan Kubernetes. Jika true, alamat IP di kumpulan ini hanya akan digunakan jika ditentukan secara eksplisit oleh layanan. Anda dapat menghilangkan kolom ini, nilai default-nya adalah false. Kolom ini dapat diubah.
• addresses Daftar satu atau beberapa rentang alamat IP yang tidak tumpang tindih. ip-range dapat ditentukan dalam notasi CIDR (seperti 198.51.100.0/24) atau notasi rentang (seperti 198.51.100.0-198.51.100.10, dengan 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 pekerja. Anda tidak dapat menyertakan node cluster tertentu di lebih dari satu node pool. Alamat IP node yang tumpang tindih antar-node pool akan memblokir pembuatan cluster dan operasi cluster lainnya.

Jika Anda ingin mencegah workload berjalan di node di 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). Jika Anda menentukan alamat k8sIP opsional untuk node, alamat tersebut akan didedikasikan untuk menangani traffic data untuk node, 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.

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 loadBalancer.addressPools bagian file konfigurasi. Namun, jika Anda menentukan alamat IP Kubernetes k8sIP untuk node, hanya alamat tersebut yang harus berada di subnet Lapisan 2 yang sama dengan VIP load balancer lainnya.

Jika nodePoolSpec tidak ditetapkan, load balancer gabungan akan berjalan di node bidang kontrol. Sebaiknya jalankan load balancer di node pool terpisah jika memungkinkan.

Load balancing bidang kontrol

Load balancer bidang kontrol melayani 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) di node load balancer untuk ketersediaan tinggi.

Load balancing bidang data

Catatan: MetalLB dalam mode BGP tidak didukung. Untuk load balancing dalam mode BGP, lihat Mengonfigurasi load balancer gabungan dengan BGP.

Load balancer bidang data adalah untuk semua Layanan Kubernetes berjenis 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 ubah MetalLB ConfigMap secara langsung. Anda dapat menggunakan semua fitur MetalLB, termasuk berbagi alamat IP di seluruh Layanan. 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 Layanan Kubernetes, bukan satu untuk seluruh cluster. Dengan cara ini, traffic akan didistribusikan ke seluruh node load balancer jika ada beberapa Layanan.

Load balancer bidang data dapat berjalan di node bidang kontrol atau di subset node pekerja. Menggabungkan load balancer bidang data di node bidang kontrol akan meningkatkan pemanfaatan node bidang kontrol. Selain itu, penggabungan di node bidang kontrol juga meningkatkan risiko kelebihan beban pada bidang kontrol dan meningkatkan profil risiko informasi rahasia di 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 gabungan 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 mirip dengan 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.35
  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:
  ...

Memisahkan load balancer saat membuat cluster

Jika 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 membuat cluster, gunakan langkah-langkah berikut:

1. Di file konfigurasi cluster, tentukan node pool load balancer dengan loadBalancer.nodePoolSpec seperti yang dijelaskan di bagian loadBalancer.nodePoolSpec dalam dokumen ini.

2. Tambahkan controlPlane.loadBalancer.mode ke file konfigurasi cluster dan tetapkan nilai mode ke bundled.

3. Selesaikan konfigurasi cluster Anda dan jalankan bmctl create cluster untuk membuat cluster.

Memigrasikan load balancer bidang data dari bidang kontrol

Jika Anda memiliki cluster versi 1.32 atau yang lebih baru yang tidak menetapkan controlPlane.loadBalancer.mode maupun 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:

1. Di file konfigurasi cluster, tentukan node pool load balancer dengan loadBalancer.nodePoolSpec seperti yang dijelaskan di bagian loadBalancer.nodePoolSpec dalam dokumen ini.

2. Tambahkan controlPlane.loadBalancer.mode ke file konfigurasi cluster dan tetapkan nilai mode ke bundled.

3. Update cluster dengan menjalankan perintah berikut:

   bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG
   

   Ganti kode berikut:

   • CLUSTER_NAME: nama cluster yang Anda update.

   • ADMIN_KUBECONFIG: jalur file kubeconfig cluster admin.

Mempertahankan alamat IP sumber klien

Layanan LoadBalancer yang dibuat dengan solusi load balancing Lapisan 2 gabungan 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 Layanan LoadBalancer dan konfigurasi Layanan serta Ingress terkait. Bagian berikut menjelaskan cara mengonfigurasi cluster untuk menggunakan metode ini.

Layanan LoadBalancer

Saat menggunakan externalTrafficPolicy: Local di Layanan LoadBalancer, tetapkan pod aplikasi Anda untuk 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 Layanan NodePort. Untuk mempertahankan alamat IP sumber klien, tetapkan service.spec.externalTrafficPolicy ke Local. Kubernetes tidak akan lagi melakukan SNAT, tetapi Anda harus memastikan ada pod yang berjalan tepat di IP node yang Anda pilih.

Ingress

Jika aplikasi Anda adalah layanan HTTP, Anda dapat mencapai visibilitas IP klien dengan mengonfigurasi komponen ingress:

1. Buka Layanan istio-ingress untuk mengedit:

   kubectl edit service -n gke-system istio-ingress
   

2. Tambahkan externalTrafficPolicy: Local ke spec, simpan, dan keluar dari editor.

   apiVersion: v1
   kind: Service
   ...
   spec:
   ...
     externalTrafficPolicy: Local
   

3. Buka Deployment istio-ingress untuk mengedit:

   kubectl edit deployment -n gke-system istio-ingress
   

4. Tambahkan nodeSelector berikut 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