Mengonfigurasi load balancing yang dipaketkan dengan MetalLB

Halaman ini menjelaskan cara mengonfigurasi load balancing yang dipaketkan dengan MetalLB untuk GKE di Bare Metal. Load balancer MetalLB berjalan di kumpulan node pekerja khusus atau pada node yang sama dengan bidang kontrol.

Baca Ringkasan load balancer untuk mengetahui contoh topologi load balancing yang tersedia di GKE pada Bare Metal.

Persyaratan

  • Semua node load balancer harus berada dalam 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 yang tidak beralasan 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 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 belakang load balancer untuk traffic masuk. Kolom ini tidak diizinkan di file konfigurasi cluster admin. Alamat ini harus tercantum 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 Service dari jenis LoadBalancer, alamat IP eksternal untuk Layanan akan 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, kumpulan akan menghilangkan alamat IP yang diakhiri dengan .0 dan .255. Beberapa perangkat keras jaringan menurunkan lalu lintas data ke alamat khusus ini. Anda dapat menghilangkan kolom ini, nilai defaultnya adalah false. Kolom ini dapat berubah.
  • manualAssign: (Opsional) true atau false. Jika true, alamat dalam kumpulan ini tidak otomatis ditetapkan ke Layanan Kubernetes. Jika true, alamat IP dalam kumpulan ini hanya digunakan jika ditetapkan secara eksplisit oleh layanan. Anda dapat menghilangkan kolom ini, nilai defaultnya adalah false. Kolom ini dapat berubah.
  • 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 dalam subnet yang sama dengan node yang menjalankan load balancer.

loadBalancer.nodePoolSpec

Bagian konfigurasi ini menetapkan daftar node yang akan digunakan untuk menjalankan load balancer. Node load balancer dapat menjalankan beban kerja reguler secara default; tidak ada taint khusus pada node tersebut. Meskipun node dalam kumpulan node load balancer dapat menjalankan beban kerja, node tersebut terpisah dari node dalam kumpulan node pekerja. Anda tidak dapat menyertakan node cluster tertentu di lebih dari satu kumpulan node. Alamat IP node yang tumpang-tindih antara kumpulan node akan memblokir pembuatan cluster dan operasi cluster lainnya.

Jika Anda ingin mencegah beban kerja berjalan pada sebuah node dalam kumpulan node load balancer, tambahkan taint berikut ke node tersebut:

node-role.kubernetes.io/load-balancer:NoSchedule

GKE di Bare Metal menambahkan toleransi terhadap taint ini ke pod yang diperlukan untuk load balancing.

nodePoolSpec:
  nodes:
  - address: 10.0.0.32
  - address: 10.0.0.33

Semua node dalam kumpulan node load balancer harus berada dalam subnet Lapisan 2 yang sama dengan VIP load balancer yang dikonfigurasi di bagian loadBalancer.addressPools file konfigurasi.

Jika nodePoolSpec tidak ditetapkan, load balancer yang dipaketkan akan dijalankan 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. GKE di Bare Metal menjalankan Keepalive dan HAProxy sebagai pod statis Kubernetes pada node load balancer untuk mengumumkan bidang kontrol VIP. Keepalive menggunakan Virtual Router Redundancy Protocol (VRRP) pada node load balancer untuk ketersediaan tinggi.

Load balancing bidang data

Load balancer bidang data ditujukan untuk semua Layanan Kubernetes jenis LoadBalancer. GKE di Bare Metal menggunakan MetalLB yang berjalan dalam mode Lapisan 2 untuk load balancing bidang data. Load balancing bidang data hanya dapat dikonfigurasi melalui GKE di Bare Metal. Jangan mengubah MetalLB ConfigMap secara langsung. Anda dapat menggunakan semua fitur MetalLB, termasuk berbagi alamat IP di seluruh Layanan. Lihat dokumentasi MetalLB untuk informasi fitur.

MetalLB menjalankan Pod speaker pada setiap node menggunakan daemonset, menggunakan memberlist untuk ketersediaan tinggi. Ada node load balancer khusus MetalLB untuk setiap Layanan Kubernetes, bukan satu node untuk seluruh cluster. Dengan cara ini, traffic akan didistribusikan ke berbagai node load balancer jika ada beberapa Layanan.

Load balancer bidang data dapat berjalan di node bidang kontrol atau pada subset worker node. Memaketkan load balancer bidang data pada node bidang kontrol akan meningkatkan penggunaan node bidang kontrol. Namun, pemaketan pada node bidang kontrol juga meningkatkan risiko kelebihan beban pada bidang kontrol dan meningkatkan profil risiko informasi rahasia di bidang kontrol, seperti kunci SSH.

Mempertahankan alamat IP sumber klien

Layanan 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 seluruh cluster, tetapi juga mengaburkan alamat IP sumber klien.

Bagian berikut menjelaskan cara mengonfigurasi cluster Anda untuk mempertahankan alamat IP sumber klien.

Layanan NodePort

Kubernetes melakukan penafsiran alamat jaringan (NAT) sumber untuk Layanan NodePort. Untuk mempertahankan alamat IP sumber klien, tetapkan service.spec.externalTrafficPolicy ke Local. Kubernetes tidak akan menjalankan NAT sumber lagi, tetapi Anda harus memastikan ada pod yang berjalan tepat di IP node yang Anda pilih.

Layanan LoadBalancer

Saat menggunakan externalTrafficPolicy: Local di Layanan LoadBalancer, setel 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"
...

Masuk

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