Bilanciamento del carico in bundle con MetalLB

Questo documento mostra come configurare Google Distributed Cloud per utilizzare il bilanciamento del carico integrato con il bilanciatore del carico MetalLB. Questo documento è rivolto agli specialisti di networking che progettano e creano l'architettura della rete per la propria organizzazione, nonché installano, configurano e supportano le apparecchiature di rete. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti di Google Cloud, consulta Ruoli e attività comuni degli utenti GKE.

In Google Distributed Cloud, MetalLB viene eseguito in modalità di livello 2.

Esempio di configurazione di MetalLB

Ecco un esempio di configurazione per i cluster che eseguono il bilanciatore del carico MetalLB:

Configurazione del bilanciatore del carico MetalLB.
Configurazione del bilanciatore del carico MetalLB

Il diagramma precedente mostra un deployment di MetalLB. MetalLB viene eseguito direttamente sui nodi del cluster. In questo esempio, il cluster di amministrazione e il cluster utente si trovano su due VLAN separate e ogni cluster si trova in una subnet separata:

Cluster Subnet
Cluster di amministrazione 172.16.20.0/24
Cluster utente 172.16.40.0/24

admin-cluster.yaml

La seguente parte di un file di configurazione del cluster di amministrazione mostra la configurazione mostrata nel diagramma precedente di:

  • Control plane per l'alta affidabilità

  • Bilanciatore del carico MetalLB

  • VIP su MetalLB per il server API Kubernetes del cluster di amministrazione

network:
  ...
  controlPlaneIPBlock:
    netmask: "255.255.255.0"
    gateway: "172.16.20.1"
    ips:
    - ip: "172.16.20.50"
      hostname: "admin-cp-1"
    - ip: "172.16.20.51"
      hostname: "admin-cp-2"
    - ip: "172.16.20.52"
      hostname: "admin-cp-3"
loadBalancer:
  kind: "MetalLB"
  ...
  vips:
    controlPlaneVIP: "172.16.20.100"
...
adminMaster:
  cpus: 4
  memoryMB: 16384
  replicas: 3

user-cluster.yaml

La seguente parte di un file di configurazione del cluster utente mostra la configurazione di:

  • Pool di indirizzi da cui il controller MetalLB può scegliere e assegnare ai servizi di tipo LoadBalancer. Il VIP Ingress si trova in questo pool.

  • VIP designato per il server API Kubernetes del cluster utente e il VIP in entrata che hai scelto di configurare per il proxy in entrata.

  • Un pool di nodi abilitato per l'utilizzo di MetalLB. MetalLB verrà distribuito sui nodi in questo pool di nodi.

enableControlplaneV2: true
...
network:
  hostConfig:
  ...

  ipMode:
    type: "static"
    ipBlockFilePath: "config-folder/user-cluster-ipblock.yaml"
...
  controlPlaneIPBlock:
    netmask: "255.255.255.0"
    gateway: "172.16.40.1"
    ips:
    - ip: "172.16.40.21"
      hostname: "user-cp"
loadBalancer:
  kind: MetalLB
  metalLB:
    addressPools:
    - name: "address-pool-1"
      addresses:
      - "172.16.40.101-172.16.40.112
      avoidBuggyIPs: true
  ...

  vips:
    controlPlaneVIP: "172.16.20.100"
    ingressVIP: "172.16.40.101"
...
nodePools:
- name: "node-pool-1"
  cpus: 4
  memoryMB: 8192
  replicas: 3
  enableLoadBalancer: true

La configurazione nell'esempio precedente specifica un insieme di indirizzi disponibili per i servizi. Quando uno sviluppatore di applicazioni crea un servizio di tipo LoadBalancer nel cluster utente, il controller MetalLB sceglie un indirizzo IP da questo pool.

user-cluster-ipblock.yaml

Il seguente esempio di file di blocco IP mostra l'assegnazione degli indirizzi IP per i nodi worker nel cluster utente. Questo include un indirizzo IP aggiuntivo da utilizzare durante gli upgrade, gli aggiornamenti e la riparazione automatica del cluster.

blocks:
- netmask: "255.255.255.0"
  gateway: "17.16.40.1"
  ips:
  - ip: 172.16.40.22
    hostname: user-vm-1
  - ip: 172.16.40.23
    hostname: user-vm-2
  - ip: 172.16.40.24
    hostname: user-vm-3
  - ip: 172.16.40.25
    hostname: user-vm-4
  - ip: 172.16.40.26
    hostname: user-vm-5
  - ip: 172.16.40.27
    hostname: user-vm-6

Configura MetalLB

Apri le porte del firewall

MetalLB utilizza la libreria Go memberlist per l'elezione del leader. La libreria memberlist utilizza la porta TCP 7946 e la porta UDP 7946 per scambiare informazioni. Assicurati che queste porte siano accessibili per il traffico in entrata e in uscita su tutti i nodi del bilanciatore del carico.

Abilita MetalLB per un nuovo cluster di amministrazione

Nel file di configurazione del cluster di amministrazione, imposta loadBalancer.kind su "MetalLB".

loadBalancer:
  kind: "MetalLB"

Compila il resto del file di configurazione del cluster di amministrazione e crea il cluster di amministrazione come descritto in Crea un cluster di amministrazione.

Specifica i pool di indirizzi

Il controller MetalLB assegna gli indirizzi IP per i servizi. Quando uno sviluppatore di applicazioni crea un servizio di tipo LoadBalancer in un cluster utente, il controller MetalLB assegna automaticamente un indirizzo IP al servizio. Il controller MetalLB seleziona un indirizzo IP da un pool di indirizzi specificato da te.

Per assicurarti che il cluster utente abbia un numero sufficiente di indirizzi IP, considera il numero massimo di servizi LoadBalancer che potrebbero essere attivi. Quindi, specifica un numero sufficiente di indirizzi IP nella sezione loadBalancer.metalLB.addressPools del file di configurazione del cluster utente.

Gli indirizzi nel pool devono essere in formato CIDR o intervallo. Per specificare un indirizzo individuale, utilizza un CIDR /32. Ad esempio:

addresses:
  -   "192.0.2.0/26"
  -   "192.0.2.64-192.0.2.72"
  -   "192.0.2.75/32"

Escludi gli indirizzi IP utilizzati per altri scopi

Non includere i seguenti indirizzi IP in nessun pool di indirizzi:

Dopo aver creato il cluster, puoi utilizzare gkectl update cluster per aggiungere pool di indirizzi IP. La possibilità di modificare gli indirizzi IP in un pool di indirizzi esistente dipende dalla versione del cluster e dall'attivazione o meno dei cluster avanzati. Per saperne di più, consulta Aggiorna MetalLB.

Abilita MetalLB per un nuovo cluster utente

Nel file di configurazione del cluster utente:

  • Imposta loadBalancer.kind su "MetalLB".
  • Specifica uno o più pool di indirizzi per i servizi. Il VIP Ingress deve essere in uno di questi pool.

  • Imposta enableLoadBalancer su true per almeno un pool di nodi nel cluster. Se impostato su true, questo campo consente l'esecuzione dello speaker MetalLB sui nodi del pool. Tieni presente che la versione del pool di nodi del bilanciatore del carico deve corrispondere alla versione del cluster durante gli upgrade; il disallineamento delle versioni non è supportato per i pool di nodi del bilanciatore del carico.

    Tieni presente le seguenti differenze nel comportamento del campo enableLoadBalancer quando enableAdvancedCluster è impostato su true (cluster avanzati abilitati): nella versione 1.31, quando i cluster avanzati sono abilitati, questo campo non ha alcun effetto perché l'oratore MetalLB viene sempre eseguito sui nodi del control plane del cluster utente. Nella versione 1.32, quando i cluster avanzati sono abilitati, questa limitazione è stata rimossa e devi specificare almeno un pool di nodi su cui viene eseguito lo speaker MetalLB.

Compila il resto del file di configurazione del cluster utente e crea il cluster utente come descritto in Crea un cluster utente.

Assegnazione manuale degli indirizzi di emergenza

Se non vuoi che il controller MetalLB assegni automaticamente gli indirizzi IP di un determinato pool ai servizi, imposta il campo manualAssign del pool su true. In seguito, uno sviluppatore può creare un servizio di tipo LoadBalancer e specificare manualmente uno degli indirizzi del pool. Ad esempio:

loadBalancer:
  metalLB:
    addressPools:
    - name: "my-address-pool-2"
      addresses:
      - "192.0.2.73-192.0.2.80"
      manualAssign: true

Evita indirizzi IP che presentano bug

Se imposti il campo avoidBuggyIPs di un pool di indirizzi su true, il controller MetalLB non utilizzerà indirizzi del pool che terminano con .0 o .255. In questo modo si evita il problema dei dispositivi consumer con bug che eliminano erroneamente il traffico inviato a questi indirizzi IP speciali. Ad esempio:

loadBalancer:
  metalLB:
    addressPools:
    - name: "my-address-pool-1"
      addresses:
      - "192.0.2.0/24"
      avoidBuggyIPs: true

Crea un servizio di tipo LoadBalancer

Ecco due manifest: uno per un deployment e uno per un servizio:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  selector:
    matchLabels:
      greeting: hello
  replicas: 3
  template:
    metadata:
      labels:
        greeting: hello
    spec:
      containers:
      - name: hello
        image: gcr.io/google-samples/hello-app:2.0
---
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: LoadBalancer
  selector:
    greeting: hello
  ports:
  - name: metal-lb-example-port
    protocol: TCP
    port: 60000
    targetPort: 8080

Tieni presente che il manifest del servizio non specifica un indirizzo IP esterno. Il controller MetalLB sceglierà un indirizzo IP esterno dal pool di indirizzi specificato nel file di configurazione del cluster utente.

Salva i manifest in un file denominato my-dep-svc.yaml. Quindi crea gli oggetti Deployment e Service:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG apply -f my-dep-svc.yaml

Visualizza il servizio:

kubectl --kubeconfig USER_CLUSTER_KUBECONIFG get service my-service --output wide

L'output mostra l'indirizzo IP esterno assegnato automaticamente al servizio. Ad esempio:

NAME         TYPE           CLUSTER-IP    EXTERNAL-IP   PORT(S)           AGE   SELECTOR
my-service   LoadBalancer   10.96.2.166   192.0.2.2   60000:31914/TCP   28s

Verifica che l'indirizzo IP esterno assegnato sia stato preso dal pool di indirizzi specificato nel file di configurazione del cluster utente. Ad esempio, 192.0.2.2 si trova in questo pool di indirizzi:

metalLB:
  addressPools:
  - name: "address-pool-1"
    addresses:
     - "192.0.2.0/24"
     - "198.51.100.1-198.51.100.3"

Chiama il servizio:

curl EXTERNAL_IP_ADDRESS:60000

L'output mostra un messaggio Hello, world!:

Hello, world!
Version: 2.0.0

Aggiorna MetalLB

Dopo aver creato il cluster, puoi aggiornare i pool di indirizzi MetalLB e il campo enableLoadBalancer nei pool di nodi. Apporta le modifiche desiderate al file di configurazione del cluster utente, quindi chiama gkectl update cluster:

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Se i cluster avanzati sono abilitati, non puoi modificare gli indirizzi IP di un pool di indirizzi esistente. L'aggiunta, la rimozione e il riordinamento degli indirizzi IP non sono supportati. Nella versione 1.33 e successive, tutti i nuovi cluster sono cluster avanzati. Per aggiungere indirizzi IP, aggiungi un nuovo pool di indirizzi contenente i nuovi indirizzi IP e mantieni invariati i pool di indirizzi esistenti. Ad esempio, la seguente configurazione aggiunge address-pool-2 e lascia invariato address-pool-1:

loadBalancer:
  kind: MetalLB
  metalLB:
    addressPools:
    - name: "address-pool-1"
      addresses:
      - "172.16.40.101-172.16.40.112"
      avoidBuggyIPs: true
    - name: "address-pool-2"
      addresses:
      - "172.16.40.121-172.16.40.130"
      avoidBuggyIPs: true

Il controller MetalLB può assegnare indirizzi IP da qualsiasi pool di indirizzi che non ha manualAssign impostato su true, quindi un nuovo pool di indirizzi aggiunge capacità. Per mantenere lo stesso comportamento per i nuovi indirizzi IP, imposta manualAssign e avoidBuggyIPs nel nuovo pool di indirizzi sugli stessi valori del pool di indirizzi esistente.

Per informazioni dettagliate sulle modifiche supportate in ogni versione, consulta il campo addresses nel riferimento per i file di configurazione dei cluster utente.

Pod e ConfigMap MetalLB

Il controller MetalLB viene eseguito come deployment e l'altoparlante MetalLB viene eseguito come DaemonSet sui nodi nei pool in cui enableLoadBalancer è impostato su true. Il controller MetalLB gestisce gli indirizzi IP assegnati ai servizi. Lo speaker MetalLB esegue l'elezione del leader e annuncia i VIP del servizio.

Visualizza tutti i pod MetalLB:

kubectl --kubeconfig USER_CLUSTER_KUBECONIFG get pods --namespace kube-system --selector app=metallb

Puoi utilizzare i log dei pod MetalLB per la risoluzione dei problemi.

La configurazione di MetalLB è archiviata in un ConfigMap in un formato noto a MetalLB. Non modificare direttamente il ConfigMap. Utilizza invece gkectl update cluster come descritto in precedenza. Per visualizzare il ConfigMap per la risoluzione dei problemi:

kubectl --kubeconfig USER_CLUSTER_KUBECONIFG get configmap metallb-config --namespace kube-system

Vantaggi dell'utilizzo di MetalLB

  • MetalLB viene eseguito direttamente sui nodi del cluster, quindi non richiede VM aggiuntive.

  • Il controller MetalLB gestisce gli indirizzi IP per i servizi, quindi non devi scegliere manualmente un indirizzo IP per ogni servizio.

  • Le istanze attive di MetalLB per servizi diversi possono essere eseguite su nodi diversi.

  • Puoi condividere un indirizzo IP tra diversi servizi.

MetalLB rispetto a F5 BIG-IP e Seesaw

  • I VIP devono trovarsi nella stessa subnet dei nodi del cluster. Questo è anche un requisito per Seesaw, ma non per F5 BIG-IP.

  • Non sono presenti metriche per il traffico.

  • Non è previsto un failover senza interruzioni; le connessioni esistenti vengono reimpostate durante il failover.

  • Il traffico esterno verso i pod di un determinato servizio passa attraverso un singolo nodo che esegue lo speaker MetalLB. Ciò significa che l'indirizzo IP client di solito non è visibile ai container in esecuzione nel pod.

  • Cisco Application Centric Infrastructure (ACI) con Dataplane IP Learning non è compatibile con i bilanciatori del carico Seesaw e MetalLB. Ti consigliamo di utilizzare il bilanciamento manuale del carico o di disattivare l'apprendimento IP di Dataplane quando utilizzi Seesaw o MetalLB come bilanciatore del carico. Inoltre, Seesaw è in modalità di manutenzione. A partire dalla versione 1.32 di Google Distributed Cloud, gli upgrade sono bloccati per i cluster che utilizzano Seesaw. Devi eseguire la migrazione dei cluster alle funzionalità consigliate prima di eseguire l'upgrade alla versione 1.32.