Cluster Anthos on bare metal kini menjadi Google Distributed Cloud (khusus software) untuk bare metal. Untuk mengetahui informasi selengkapnya, lihat ringkasan produk.

Halaman ini diterjemahkan oleh Cloud Translation API.

Mengonfigurasi load balancing yang dipaketkan dengan MetalLB

Halaman ini menjelaskan cara mengonfigurasi load balancing yang dipaketkan dengan MetalLB untuk Google Distributed Cloud. Load balancer MetalLB berjalan di kumpulan node pekerja 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 serampangan dan meneruskan paket ARP ke node load balancer.

Kolom konfigurasi

Edit bagian cluster.spec.loadBalancer file konfigurasi cluster untuk mengonfigurasi load balancing yang dipaketkan. Untuk 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 cantumkan alamat ini di bagian address pools dalam file konfigurasi.

loadBalancer.vips.ingressVIP

Nilai ini menentukan alamat IP yang akan digunakan untuk Layanan di balik load balancer untuk traffic masuk. Kolom ini tidak diizinkan dalam file konfigurasi cluster admin. 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 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 tujuan organisasi Anda sendiri. Kolom ini tidak dapat diubah.
avoidBuggyIPs: (Opsional) true atau false. Jika true, kumpulan akan menghapus alamat IP yang diakhiri dengan .0 dan .255. Beberapa hardware jaringan menghentikan 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 dalam 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 tempat load balancer akan dijalankan. 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 antara kumpulan node akan memblokir pembuatan cluster dan operasi cluster lainnya.

Jika Anda ingin mencegah workload berjalan di node dalam 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 dalam kumpulan node load balancer harus berada di subnet Lapisan 2 yang sama dengan VIP load balancer yang dikonfigurasi di bagian loadBalancer.addressPools dalam 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 yang dipaketkan akan berjalan di node panel 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. 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

Load balancer bidang data ditujukan untuk semua Layanan Kubernetes jenis 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 ConfigMap MetalLB 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 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 didistribusikan di seluruh node load balancer jika ada beberapa Layanan.

Load balancer bidang data dapat berjalan di node bidang kontrol atau di sebagian node pekerja. Memaketkan load balancer bidang data di node bidang kontrol akan meningkatkan penggunaan node bidang kontrol. Selain itu, pengelompokan di node bidang kontrol juga meningkatkan risiko overload 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.

Google Distributed Cloud mendukung dua metode untuk mempertahankan alamat IP sumber klien:

Tetapkan mode penerusan untuk load balancing ke Direct Server Return (DSR). Untuk 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 dan Ingress terkait sebagaimana mestinya. 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 persis 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 menjalankan SNAT, tetapi Anda harus memastikan ada pod yang berjalan persis di IP node yang Anda pilih.

Masuk

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

Buka Layanan istio-ingress untuk mengedit:

kubectl edit service -n gke-system istio-ingress

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

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

Buka Deployment istio-ingress untuk mengedit:

kubectl edit deployment -n gke-system istio-ingress

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 balik Ingress akan melihat header X-Forwarded-For dengan IP klien, seperti contoh berikut:

X-Forwarded-For: 21.0.104.4