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 Layer 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 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:

loadBalancer.mode

Nilai ini harus 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 API Kubernetes).

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 Layer 2 yang sama dengan node di cluster. Jangan mencantumkan alamat ini di bagian address pools file konfigurasi.

loadBalancer.vips.ingressVIP

Nilai ini menentukan alamat IP yang akan digunakan untuk Layanan di balik load balancer untuk traffic ingress. Kolom ini tidak diizinkan dalam file konfigurasi admin cluster. Alamat ini harus tercantum di bagian address pools dalam 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 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) true atau false. Jika true, pool menghilangkan alamat IP yang diakhiri dengan .0 dan .255. Beberapa hardware jaringan akan membuang traffic ke alamat khusus ini. Anda dapat menghapus kolom ini, nilai defaultnya adalah false. Kolom ini dapat diubah.
  • manualAssign: (Opsional) true atau false. Jika true, alamat di kumpulan ini tidak otomatis ditetapkan ke Layanan Kubernetes. Jika true, alamat IP dalam kumpulan ini hanya digunakan jika ditentukan secara eksplisit oleh layanan. Anda dapat menghapus kolom ini, nilai defaultnya 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, 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 dalam lebih dari satu node pool. Alamat IP node yang tumpang-tindih antara node pool 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). Saat Anda menentukan alamat k8sIP opsional untuk node, alamat tersebut dikhususkan 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 kumpulan node load balancer harus berada di subnet Layer 2 yang sama dengan VIP load balancer yang dikonfigurasi di bagian loadBalancer.addressPools file konfigurasi. Namun, jika Anda menentukan alamat IP Kubernetes k8sIP untuk sebuah node, hanya alamat tersebut yang harus berada di subnet Layer 2 yang sama dengan VIP load balancer lainnya.

Jika nodePoolSpec tidak ditetapkan, load balancer yang dibundel 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) pada node load balancer untuk ketersediaan tinggi.

Load balancing bidang data

Load balancer bidang data adalah untuk semua Layanan Kubernetes jenis LoadBalancer. Google Distributed Cloud menggunakan MetalLB yang berjalan dalam mode Layer 2 untuk load balancing bidang data. Penyeimbangan beban bidang data hanya dapat dikonfigurasi melalui Google Distributed Cloud, jangan ubah ConfigMap MetalLB 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 di seluruh node load balancer jika ada beberapa Layanan.

Load balancer bidang data dapat berjalan di node bidang kontrol atau di subset worker node. 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 membebani bidang kontrol secara berlebihan dan meningkatkan profil risiko informasi rahasia di bidang kontrol, seperti kunci SSH.

Pemisahan load balancer

Sebelum rilis 1.32, saat Anda mengonfigurasi load balancing Layer 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 kumpulan node load balancer.

Diagram berikut menunjukkan konfigurasi load balancer bawaan default dengan load balancer bidang kontrol dan bidang data yang berjalan di node bidang kontrol atau keduanya berjalan di kumpulan node load balancer:

Konfigurasi load balancer default

Dengan cluster versi 1.32, Anda dapat mengonfigurasi load balancer bidang kontrol agar berjalan di node bidang kontrol dan load balancer bidang data agar 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 terpisah 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.33
  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 tinggi, 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:

Load balancer bidang kontrol dan bidang data yang terpisah

Untuk memisahkan load balancer saat membuat cluster, gunakan langkah-langkah berikut:

  1. Dalam 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 tinggi yang tidak menetapkan controlPlane.loadBalancer.mode maupun loadBalancer.nodePoolSpec, load balancer bidang kontrol dan load balancer bidang data akan berjalan di kumpulan node bidang kontrol. Anda dapat memperbarui cluster untuk memigrasikan load balancer data plane 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:

Load balancer bidang data dimigrasikan ke kumpulan node load balancer

Untuk memigrasikan load balancer bidang data ke node pool load balancer saat Anda memperbarui cluster, gunakan langkah-langkah berikut:

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

    • ADMIN_KUBECONFIG: jalur file kubeconfig cluster admin.

Mempertahankan alamat IP sumber klien

Layanan LoadBalancer yang dibuat dengan solusi load balancing Layer 2 yang dibundel menggunakan setelan Cluster default untuk kebijakan traffic eksternal. Setelan ini, spec.externalTrafficPolicy: Cluster, merutekan traffic eksternal ke endpoint 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 LoadBalancer Service dan konfigurasi Service dan Ingress terkait dengan tepat. Bagian berikut menjelaskan cara mengonfigurasi cluster 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 NodePort Layanan. Untuk mempertahankan alamat IP sumber klien, tetapkan service.spec.externalTrafficPolicy ke Local. Kubernetes tidak akan melakukan SNAT lagi, tetapi Anda harus memastikan ada pod yang berjalan tepat di IP node yang Anda pilih.

Masuk

Jika aplikasi Anda adalah layanan HTTP, Anda dapat memperoleh 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, lalu 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, lalu 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