Configura il bilanciamento del carico in bundle con MetalLB

Questa pagina descrive come configurare il bilanciamento del carico in bundle con MetalLB per Google Distributed Cloud. I bilanciatori del carico MetalLB vengono eseguiti su un pool dedicato di nodi worker o sugli stessi nodi del piano di controllo.

Consulta la Panoramica dei bilanciatori del carico per esempi di topologie di bilanciamento del carico disponibili in Google Distributed Cloud.

Requisiti

  • Tutti i nodi del bilanciatore del carico devono trovarsi nella stessa subnet di livello 2.
  • Tutti i VIP devono trovarsi nella subnet dei nodi del bilanciatore del carico ed essere instradabili attraverso il gateway della subnet.
  • Il gateway della subnet del bilanciatore del carico deve ascoltare messaggi ARP gratuiti e inoltrare i pacchetti ARP ai nodi del bilanciatore del carico.

Campi di configurazione

Modifica la sezione cluster.spec.loadBalancer del file di configurazione del cluster per configurare il bilanciamento del carico in bundle. Per informazioni sui file di configurazione del cluster ed esempi di configurazioni valide, consulta una delle seguenti pagine:

loadBalancer.mode

Questo valore deve essere bundled per abilitare il bilanciamento del carico in bundle.

loadBalancer.ports.controlPlaneLBPort

Questo valore specifica la porta di destinazione da utilizzare per il traffico inviato al piano di controllo Kubernetes (server API Kubernetes).

loadBalancer.vips.controlPlaneVIP

Questo valore specifica l'indirizzo IP di destinazione da utilizzare per il traffico inviato al piano di controllo Kubernetes (server API Kubernetes). Questo indirizzo IP deve trovarsi nella stessa subnet di livello 2 dei nodi nel cluster. Non elencare questo indirizzo nella sezione address pools del file di configurazione.

loadBalancer.vips.ingressVIP

Questo valore specifica l'indirizzo IP da utilizzare per i servizi dietro il bilanciatore del carico per il traffico in entrata. Questo campo non è consentito nei file di configurazione del cluster di amministrazione. Questo indirizzo deve essere elencato nella sezione pool di indirizzi della configurazione.

loadBalancer.addressPools

Questa sezione della configurazione contiene uno o più pool di indirizzi. Ogni pool di indirizzi specifica un elenco di intervalli di indirizzi IP. Quando crei un servizio di tipo LoadBalancer, gli indirizzi IP esterni del servizio vengono scelti da questi intervalli.

I pool di indirizzi sono specificati nel seguente formato:

- name: POOL_NAME
  avoidBuggyIPs: BOOLEAN
  manualAssign: BOOLEAN
  addresses:
  - IP_RANGE
  - IP_RANGE2
  • name: il nome del pool di indirizzi, pool-name, per i tuoi scopi organizzativi. Questo campo è immutabile.
  • avoidBuggyIPs: (facoltativo) true o false. Se true, il pool omette gli indirizzi IP che terminano con .0 e .255. Alcuni hardware di rete eliminano il traffico verso questi indirizzi speciali. Puoi omettere questo campo. Il valore predefinito è false. Questo campo è modificabile.
  • manualAssign: (facoltativo) true o false. Se true, gli indirizzi in questo pool non vengono assegnati automaticamente ai servizi Kubernetes. Se true, un indirizzo IP in questo pool viene utilizzato solo quando è specificato esplicitamente da un servizio. Puoi omettere questo campo. Il suo valore predefinito è false. Questo campo è modificabile.
  • addresses Un elenco di uno o più intervalli di indirizzi IP non sovrapposti. ip-range può essere specificato in notazione CIDR (ad esempio 198.51.100.0/24) o in notazione di intervallo (ad esempio 198.51.100.0-198.51.100.10, senza spazi intorno al trattino). Questo campo è immutabile.

Gli intervalli di indirizzi IP nell'elenco addresses non devono sovrapporsi e devono trovarsi nella stessa subnet dei nodi che eseguono i bilanciatori del carico.

loadBalancer.nodePoolSpec

Questa sezione della configurazione specifica un elenco di nodi su cui eseguire i bilanciatori del carico. I nodi dei bilanciatori del carico possono eseguire carichi di lavoro regolari per impostazione predefinita; non c'è alcuna incompatibilità speciale sui nodi. Sebbene i nodi nel pool di nodi del bilanciatore del carico possano eseguire carichi di lavoro, sono separati dai nodi nei pool di nodi worker. Non puoi includere un determinato nodo cluster in più di un pool di nodi. La sovrapposizione degli indirizzi IP dei nodi tra i pool di nodi blocca la creazione del cluster e altre operazioni del cluster.

Se vuoi impedire l'esecuzione di carichi di lavoro su un nodo nel pool di nodi del bilanciatore del carico, aggiungi la seguente incompatibilità al nodo:

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

Google Distributed Cloud aggiunge tolleranze per questa incompatibilità ai pod necessari per il bilanciamento del carico.

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

Tutti i nodi nel pool di nodi del bilanciatore del carico devono trovarsi nella stessa subnet di livello 2 dei VIP del bilanciatore del carico configurati nella sezione loadBalancer.addressPools del file di configurazione.

Se nodePoolSpec non è impostato, i bilanciatori del carico in bundle vengono eseguiti sui nodi del piano di controllo. Ti consigliamo di eseguire i bilanciatori del carico su pool di nodi separati, se possibile.

Bilanciamento del carico del piano di controllo

Il bilanciatore del carico del piano di controllo gestisce l'indirizzo IP virtuale (VIP) del piano di controllo. Google Distributed Cloud esegue KeepaLive e HAProxy come pod statici Kubernetes sui nodi del bilanciatore del carico per annunciare il VIP del piano di controllo. KeepaLifetime utilizza il protocollo VRRP (Virtual Router Redundancy Protocol) sui nodi del bilanciatore del carico per garantire l'alta disponibilità.

Bilanciamento del carico del piano dati

Il bilanciatore del carico del piano dati è per tutti i servizi Kubernetes di tipo LoadBalancer. Google Distributed Cloud utilizza MetalLB in modalità di livello 2 per il bilanciamento del carico del piano dati. Il bilanciamento del carico del piano dati può essere configurato solo tramite Google Distributed Cloud, non modificare direttamente MetalLB ConfigMap. Puoi utilizzare tutte le funzionalità di MetalLB, inclusa la condivisione degli indirizzi IP tra i servizi. Per informazioni sulle funzionalità, consulta la documentazione MetalLB.

MetalLB esegue un pod dello speaker su ciascun nodo utilizzando un daemonset, utilizzando memberlist per l'alta disponibilità. Esiste un nodo del bilanciatore del carico dedicato MetalLB per ogni servizio Kubernetes, anziché uno per l'intero cluster. In questo modo il traffico viene distribuito tra i nodi del bilanciatore del carico se sono presenti più servizi.

I bilanciatori del carico del piano dati possono essere eseguiti sui nodi del piano di controllo o su un sottoinsieme di nodi worker. Il raggruppamento dei bilanciatori del carico del piano dati sui nodi del piano di controllo aumenta l'utilizzo dei nodi del piano di controllo. Tuttavia, il raggruppamento sui nodi del piano di controllo aumenta anche il rischio di sovraccaricare il piano di controllo e il profilo di rischio delle informazioni riservate sul piano di controllo, ad esempio le chiavi SSH.

Conservazione dell'indirizzo IP di origine del client

Il servizio LoadBalancer creato con la soluzione di bilanciamento del carico di livello 2 in bundle utilizza l'impostazione Cluster predefinita per il criterio del traffico esterno. Questa impostazione, spec.externalTrafficPolicy: Cluster, instrada il traffico esterno agli endpoint a livello di cluster, ma oscura anche l'indirizzo IP di origine del client.

Le sezioni seguenti descrivono come configurare il cluster per conservare l'indirizzo IP di origine client.

Servizi NodePort

Kubernetes esegue Network Address Translation (NAT) di origine per i servizi NodePort. Per conservare gli indirizzi IP di origine client, imposta service.spec.externalTrafficPolicy su Local. Kubernetes non eseguirà più il NAT di origine, ma devi assicurarti che ci siano pod in esecuzione esattamente sull'IP del nodo che hai selezionato.

Servizi LoadBalancer

Quando utilizzi externalTrafficPolicy: Local nei servizi LoadBalancer, imposta i pod delle applicazioni in modo che vengano eseguiti esattamente sui nodi del bilanciatore del carico. Aggiungi nodeSelector seguente ai pod dell'applicazione per apportare questa modifica:

apiVersion: v1
kind: Pod
...
spec:
  nodeSelector:
      baremetal.cluster.gke.io/lbnode: "true"
...

In entrata

Se le tue applicazioni sono servizi HTTP, puoi ottenere visibilità IP client configurando i componenti in entrata:

  1. Apri il servizio istio-ingress per la modifica:

    kubectl edit service -n gke-system istio-ingress

  2. Aggiungi externalTrafficPolicy: Local a spec, salva ed esci dall'editor.

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

  3. Apri il deployment istio-ingress da modificare:

    kubectl edit deployment -n gke-system istio-ingress

  4. Aggiungi il seguente nodeSelector al deployment, salva ed esci dall'editor.

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

Ora, tutti i tuoi servizi dietro a Ingress vedranno un'intestazione X-Forwarded-For con l'IP del client, come nell'esempio seguente:

X-Forwarded-For: 21.0.104.4