Configurare 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 tramite il gateway della subnet.
  • Il gateway della subnet del bilanciatore del carico deve ascoltare i 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 e su esempi di configurazioni valide, consulta una delle seguenti pagine:

loadBalancer.mode

Questo valore deve essere bundled per attivare 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 del 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 address pools 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 per il 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 le tue finalità organizzative. 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 interrompono il traffico verso questi indirizzi speciali. Puoi omettere questo campo, il cui valore predefinito è false. Questo campo è mutabile.
  • 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 se specificato esplicitamente da un servizio. Puoi omettere questo campo, il cui valore predefinito è false. Questo campo è mutabile.
  • addresses Un elenco di uno o più intervalli di indirizzi IP non sovrapposti. ip-range può essere specificato in notazione CIDR (come 198.51.100.0/24) o in notazione di intervallo (come 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 su cui sono in esecuzione i bilanciatori del carico.

loadBalancer.nodePoolSpec

Questa sezione della configurazione specifica un elenco di nodi su cui eseguire i bilanciatori del carico. Per impostazione predefinita, i nodi del bilanciatore del carico possono eseguire carichi di lavoro normali; su questi nodi non è presente alcuna incompatibilità speciale. Sebbene i nodi del pool di nodi del bilanciatore del carico possano eseguire carichi di lavoro, sono separati dai nodi dei pool di nodi worker. Non puoi includere un determinato nodo del cluster in più di un pool di nodi. Gli indirizzi IP dei nodi sovrapposti tra i pool di nodi bloccano la creazione del cluster e altre operazioni del cluster.

Se vuoi impedire l'esecuzione dei 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 questo taint ai pod necessari per il bilanciamento del carico.

L'esempio seguente mostra un pool di nodi di bilanciamento del carico con due nodi. Il primo nodo ha un indirizzo IP standard nodePoolSpec.nodes.address ("1.2.3.4") e un nodePoolSpec.nodes.k8sIP indirizzo IP Kubernetes (10.0.0.32). Quando specifichi l'indirizzo facoltativo k8sIP per un nodo, questo è dedicato alla gestione del traffico di dati per il nodo, ad esempio richieste e risposte per l'API Kubernetes, il kubelet e i carichi di lavoro. In questo caso, l'indirizzo IP standardnodePoolSpec.nodes.address viene utilizzato per le connessioni SSH al nodo per le operazioni di cluster amministrativo. Se non specifichi un indirizzo k8sIP, l'indirizzo IP del nodo standard gestisce tutto il traffico per il nodo.

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

Per impostazione predefinita, tutti i nodi del 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. Tuttavia, se specifichi un indirizzo IP Kubernetes k8sIP per un nodo, solo questo indirizzo deve trovarsi nella stessa subnet di livello 2 degli altri VIP del bilanciatore del carico.

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

Bilanciamento del carico del control plane

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

Bilanciamento del carico del piano dati

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

MetalLB esegue un pod speaker su ogni nodo utilizzando un daemonset, utilizzando memberlist per l'alta disponibilità. Esiste un nodo bilanciatore del carico MetalLB dedicato 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 di 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 di dati sui nodi del piano di controllo aumenta l'utilizzo dei nodi del piano di controllo. Inoltre, 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, come le chiavi SSH.

Separazione del bilanciatore del carico

Prima della release 1.32, quando configuri il bilanciamento del carico a livello 2 con MetalLB, i bilanciatori del carico del piano di controllo e i bilanciatori del carico del piano dati vengono eseguiti sugli stessi nodi. A seconda della configurazione, i bilanciatori del carico vengono eseguiti tutti sui nodi del piano di controllo o tutti nel pool di nodi del bilanciatore del carico.

Il seguente diagramma mostra la configurazione predefinita del bilanciatore del carico in bundle con entrambi i bilanciatori del carico del piano di controllo e del piano di dati in esecuzione sui nodi del piano di controllo o entrambi in esecuzione nel pool di nodi del bilanciatore del carico:

Configurazione predefinita del bilanciatore del carico

Con i cluster della versione 1.32, puoi configurare i bilanciatori del carico del piano di controllo per l'esecuzione sui nodi del piano di controllo e i bilanciatori del carico del piano dati per l'esecuzione nel pool di nodi del bilanciatore del carico. Puoi specificare questa separazione dei bilanciatori del carico quando crei un nuovo cluster 1.32 o puoi aggiornare un cluster 1.32 per eseguire la migrazione dei bilanciatori del carico del piano dati dai nodi del piano di controllo al pool di nodi del bilanciatore del carico.

La configurazione del cluster per i bilanciatori del carico separati dovrebbe essere simile all'esempio riportato di seguito:

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: hybrid-ha-lb
  namespace: cluster-hybrid-ha-lb
spec:
  type: hybrid
  profile: default
  anthosBareMetalVersion: 1.32
  gkeConnect:
    projectID: project-fleet
  controlPlane:
    loadBalancer:
      mode: bundled
    nodePoolSpec:
      nodes:
      - address: 10.200.0.2
      - address: 10.200.0.3
      - address: 10.200.0.4
  clusterNetwork:
    pods:
      cidrBlocks:
      - 192.168.0.0/16
    services:
      cidrBlocks:
      - 10.96.0.0/20
  ...
  loadBalancer:
    mode: bundled
    ...
    nodePoolSpec:
      nodes:
      - address: 10.200.0.5
      - address: 10.200.0.6
      - address: 10.200.0.7
  clusterOperations:
  ...

Bilanciatori del carico separati durante la creazione di un cluster

Se stai creando un nuovo cluster della versione 1.32 o successiva, puoi configurare i bilanciatori del carico in modo che eseguano i bilanciatori del carico del piano di controllo sui nodi del piano di controllo e i bilanciatori del carico del piano di dati sul pool di nodi del bilanciatore del carico.

Il seguente diagramma mostra i bilanciatori del carico del piano di controllo e del piano di dati separati in nodi diversi:

Bilanciatori del carico del piano di controllo e del piano dati separati

Per separare i bilanciatori del carico quando crei un cluster, segui i passaggi riportati di seguito:

  1. Nel file di configurazione del cluster, specifica un pool di nodi del bilanciatore del carico con loadBalancer.nodePoolSpec come descritto nella sezione loadBalancer.nodePoolSpec di questo documento.

  2. Aggiungi controlPlane.loadBalancer.mode al file di configurazione del cluster e imposta il valore mode su bundled.

  3. Completa la configurazione del cluster ed esegui bmctl create cluster per crearlo.

Esegui la migrazione dei bilanciatori del carico del piano dati dal piano di controllo

Se hai già un cluster della versione 1.32 o successiva in cui non è impostato né controlPlane.loadBalancer.mode né loadBalancer.nodePoolSpec, sia il bilanciatore del carico del piano di controllo sia il bilanciatore del carico del piano dati vengono eseguiti nel pool di nodi del piano di controllo. Puoi aggiornare il cluster per eseguire la migrazione del bilanciatore del carico del piano dati a un pool di nodi del bilanciatore del carico.

Il seguente diagramma mostra i bilanciatori del carico del piano di controllo e del piano dati separati dopo la migrazione del bilanciatore del carico del piano dati dai nodi del piano di controllo:

Il bilanciatore del carico del piano dati è stato sottoposto a migrazione al pool di nodi del bilanciatore del carico

Per eseguire la migrazione del bilanciatore del carico del piano dati a un pool di nodi del bilanciatore del carico quando aggiorni un cluster:

  1. Nel file di configurazione del cluster, specifica un pool di nodi del bilanciatore del carico con loadBalancer.nodePoolSpec come descritto nella sezione loadBalancer.nodePoolSpec di questo documento.

  2. Aggiungi controlPlane.loadBalancer.mode al file di configurazione del cluster e imposta il valore mode su bundled.

  3. Aggiorna il cluster eseguendo il seguente comando:

    bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG

    Sostituisci quanto segue:

    • CLUSTER_NAME: il nome del cluster che stai aggiornando.

    • ADMIN_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione.

Preservazione dell'indirizzo IP di origine del client

Il servizio LoadBalancer creato con la soluzione di bilanciamento del carico di livello 2 in dotazione utilizza l'impostazione predefinita Cluster 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.

Google Distributed Cloud supporta due metodi per preservare l'indirizzo IP di origine del client:

  • Imposta la modalità di inoltro per il bilanciamento del carico su Direct Server Return (DSR). Per ulteriori informazioni sulla modalità di inoltro DSR, incluse le istruzioni per attivarla, consulta Configurare la modalità di inoltro del bilanciamento del carico.

  • Imposta il criterio di traffico esterno su local per il servizio LoadBalancer e configura di conseguenza i servizi e Ingress correlati. Le sezioni seguenti descrivono come configurare il cluster per utilizzare questo metodo.

Servizi LoadBalancer

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

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

Servizi NodePort

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

In entrata

Se le tue applicazioni sono servizi HTTP, puoi ottenere la visibilità dell'indirizzo IP del client configurando i componenti di ingresso:

  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 per la modifica:

    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 servizi dietro Ingress vedono un'intestazione X-Forwarded-For con l'IP del cliente, come nell'esempio seguente:

X-Forwarded-For: 21.0.104.4