Mengonfigurasi load balancing yang dipaketkan dengan MetalLB

Halaman ini menjelaskan cara mengonfigurasi paket load balancing dengan MetalLB untuk Google Distributed Cloud. Load balancer MetalLB berjalan pada kumpulan pada node pekerja atau pada node yang sama dengan bidang kontrol.

Lihat Ringkasan load balancer untuk 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 dalam subnet node load balancer dan dapat dirutekan melalui gateway subnet tertentu.
  • Gateway subnet load balancer harus memproses pesan ARP yang tidak beralasan dan meneruskan paket ARP ke {i>node<i} load balancer.

Kolom konfigurasi

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

loadBalancer.mode

Nilai ini harus bundled agar dapat mengaktifkan load balancing yang dipaketkan.

loadBalancer.ports.controlPlaneLBPort

Nilai ini menentukan porta 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 mencantumkan ini di bagian address pools pada konfigurasi .

loadBalancer.vips.ingressVIP

Nilai ini menentukan alamat IP yang akan digunakan untuk Layanan di balik beban untuk traffic masuk. Kolom ini tidak diizinkan di admin kelompok file konfigurasi. Alamat ini harus tercantum di alamat pool pada konfigurasi.

loadBalancer.addressPools

Bagian konfigurasi ini berisi satu atau beberapa kumpulan alamat. Masing-masing kumpulan alamat menentukan daftar rentang alamat IP. Saat Anda membuat Layanan jenis 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 Anda sendiri tujuan organisasi. Kolom ini tidak dapat diubah.
  • avoidBuggyIPs: (Opsional) true atau false. Jika true, atribut kumpulan menghilangkan alamat IP yang diakhiri dengan .0 dan .255. Beberapa penurunan hardware jaringan lalu lintas 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 di kumpulan ini hanya akan digunakan jika ditentukan secara eksplisit oleh suatu 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, 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 dalam subnet yang sama dengan node yang menjalankan load balancer.

loadBalancer.nodePoolSpec

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

Jika Anda ingin mencegah workload berjalan pada node di load balancer kumpulan node, 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 kumpulan node load balancing dengan dua node. Yang pertama node 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, node ini 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 operasional cluster administratif. Jika Anda tidak menentukan alamat k8sIP, alamat IP node standar menangani semua lalu lintas untuk node.

nodePoolSpec:
  nodes:
  - address: 1.2.3.4
    k8sIP: 10.0.0.32
  - address: 10.0.0.33

Secara default, semua node dalam kumpulan node load balancer harus berada di Lapisan 2 yang sama subnet instance VM sebagai load balancer yang dikonfigurasi di Bagian loadBalancer.addressPools file konfigurasi. Namun, jika Anda menentukan k8sIP alamat IP Kubernetes untuk sebuah node, hanya harus berada di subnet Lapisan 2 yang sama dengan VIP load balancer lainnya.

Jika nodePoolSpec tidak ditetapkan, load balancer yang dipaketkan berjalan di kontrol node bidang. Sebaiknya jalankan load balancer pada kumpulan node terpisah jika sebaik mungkin.

Load balancing bidang kontrol

Load balancer bidang kontrol menyalurkan alamat IP virtual bidang kontrol (VIP). Google Distributed Cloud menjalankan Keepalive dan HAProxy sebagai pod statis Kubernetes di {i>node<i} load-balancer untuk mengumumkan VIP bidang kontrol. Keepalive menggunakan Protokol Redundansi Router Virtual (VRRP) pada node load balancer untuk ketersediaan tinggi.

Load balancing bidang data

Load balancer bidang data ditujukan untuk semua jenis Layanan Kubernetes 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 pada setiap node menggunakan daemonset, daftar anggota untuk ketersediaan tinggi. Ada node load balancer khusus MetalLB untuk setiap node Layanan Kubernetes, bukan satu untuk seluruh cluster. Dengan cara ini lalu lintas yang didistribusikan di seluruh node load balancer jika ada beberapa Layanan.

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

Mempertahankan alamat IP sumber klien

Layanan LoadBalancer dibuat dengan load balancing Lapisan 2 yang dipaketkan solusi ini menggunakan setelan Cluster default untuk kebijakan traffic eksternal. Setelan ini, spec.externalTrafficPolicy: Cluster, merutekan traffic eksternal ke endpoint tingkat cluster, tetapi juga menyamarkan alamat IP sumber klien.

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

Layanan NodePort

Kubernetes melakukan penafsiran alamat jaringan sumber (SNAT) untuk NodePort Layanan. Untuk mempertahankan alamat IP sumber klien, setel service.spec.externalTrafficPolicy hingga Local. Kubernetes tidak akan menjalankan SNAT lagi, tetapi Anda harus memastikan ada pod yang berjalan persis pada IP node yang Anda pilih.

Layanan LoadBalancer

Saat menggunakan externalTrafficPolicy: Local di Layanan LoadBalancer, setel pod aplikasi Anda agar berjalan tepat pada node load balancer. Tambahkan mengikuti nodeSelector 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 masuk:

  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 .

    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 .

    apiVersion: apps/v1
kind: Deployment
...
spec:
  ...
  template:
    ...
    spec:
      ...
      nodeSelector:
          baremetal.cluster.gke.io/lbnode: "true"
...

Sekarang, semua layanan Anda di belakang Ingress melihat header X-Forwarded-For dengan IP klien, seperti contoh berikut:

X-Forwarded-For: 21.0.104.4