Mengonfigurasi load balancing yang dipaketkan

Halaman ini menjelaskan cara mengonfigurasi load balancing yang dipaketkan untuk GDCV untuk Bare Metal. GDCV untuk Bare Metal men-deploy load balancer Lapisan 4 yang berjalan di kumpulan worker node khusus atau pada node yang sama dengan bidang kontrol.

Lihat Ringkasan load balancer untuk mengetahui contoh topologi load balancing yang tersedia di GDCV untuk 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-range
  • name: Nama kumpulan alamat, pool-name, untuk tujuan organisasi Anda sendiri.
  • 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.
  • 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.
  • alamat 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).

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. Contoh di bawah ini menunjukkan kumpulan node dengan dua node. Node pertama, 1.2.3.4, menggunakan kolom k8sIP untuk menentukan alamat IP node di cluster. Alamat 1.2.3.4 hanya digunakan untuk akses SSH.

nodePoolSpec:
  nodes:
  - address: 1.2.3.4
    k8sIP: 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 node memiliki k8sIP yang telah dikonfigurasi, 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 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. GDCV untuk 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. GDCV untuk Bare Metal menggunakan MetalLB yang berjalan dalam mode Lapisan 2 untuk load balancing bidang data. Load balancing bidang data hanya dapat dikonfigurasi melalui GDCV untuk 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