Eseguire la migrazione dal bilanciatore del carico Seesaw a MetalLB

Questo documento mostra come eseguire la migrazione dal bilanciatore del carico Seesaw al bilanciatore del carico MetalLB per le versioni da 1.16 a 1.29. Se i tuoi cluster sono alla versione 1.30 o successiva, ti consigliamo di seguire le istruzioni riportate in Pianificare la migrazione dei cluster alle funzionalità consigliate.

L'utilizzo di MetalLB offre diversi vantaggi rispetto ad altre opzioni di bilanciamento del carico.

1.28 e 1.29: GA
1.16: anteprima

Per controllare externalTrafficPolicy, esegui il seguente comando:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get svc -A -o yaml | grep "externalTrafficPolicy: Local"

Contatta l'Assistenza Google per ricevere aiuto in merito a questo problema.

Note sul tempo di riposo

Il carico di lavoro non è disponibile durante la migrazione. Le seguenti note si applicano solo ai cluster di amministrazione non ad alta disponibilità (non HA) perché il bilanciatore del carico SeeSaw non supporta i cluster di amministrazione HA.

  • Durante la migrazione di un cluster di amministrazione:

    • Durante la migrazione di controlPlaneVIP si verificano tempi di inattività del piano di controllo per i cluster utente kubeception. Il tempo di riposo dovrebbe essere inferiore a 10 minuti, ma la durata dipende dall'infrastruttura.

    • Il piano di controllo del cluster di amministrazione è inattivo perché il nodo principale di amministrazione deve essere ricreato con controlPlaneVIP direttamente collegato alla VM. Il tempo di riposo dovrebbe essere inferiore a 20 minuti, ma la durata del tempo di riposo dipende dall'infrastruttura.

  • Durante la migrazione di un cluster utente, si verifica un'interruzione del servizio per i VIP dopo lo spegnimento del bilanciatore del carico Seesaw e prima dell'avvio dei pod MetalLB. In genere, questa procedura richiede circa un minuto.

Migrazione dei cluster utente

Devi scegliere un pool di nodi e abilitarlo per l'utilizzo con MetalLB. MetalLB verrà eseguito su tutti i nodi di questo pool di nodi.

Nel file di configurazione del cluster utente, scegli un pool di nodi e imposta enableLoadBalancer su true:

nodePools:
- name: pool-1
  replicas: 3
  enableLoadBalancer: true

Aggiorna il cluster:

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Sostituisci quanto segue:

  • ADMIN_CLUSTER_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione

  • USER_CLUSTER_CONFIG: il percorso del file di configurazione del cluster utente

Rimuovi le sezioni Seesaw dal file e aggiungi una sezione MetalLB.

Poi aggiorna di nuovo il cluster:

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Verifica che i componenti MetalLB siano in esecuzione correttamente:

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

L'output mostra i pod per il controller e lo speaker MetalLB. Ad esempio:

metallb-controller-744884bf7b-rznr9   1/1     Running
metallb-speaker-6n8ws                 1/1     Running
metallb-speaker-nb52z                 1/1     Running
metallb-speaker-rq4pp                 1/1     Running

Dopo una migrazione riuscita, elimina manualmente le VM Seesaw, che sono già spente, per il cluster di utenti. Puoi trovare i nomi delle VM Seesaw nella sezione vmnames del file seesaw-for-[USERCLUSTERNAME].yaml nella directory di configurazione.

Esempio: cluster utente, indirizzi IP statici

Supponiamo che tu abbia un cluster utente che utilizza indirizzi IP statici per i suoi nodi. Supponiamo inoltre che il cluster abbia due servizi di tipo LoadBalancer e che gli indirizzi esterni di questi servizi siano 172.16.21.41 e 172.16.21.45.

Modifica il file di configurazione del cluster utente nel seguente modo:

  • Mantieni la sezione network.hostConfig.
  • Imposta loadBalancer.kind su MetalLB.
  • Rimuovi la sezione loadBalancer.seesaw.
  • Aggiungi una sezione loadBalancer.metalLB.

Esempio:

network:
  hostConfig:
    dnsServers:
    - "172.16.255.1"
    - "172.16.255.2"
    ntpServers:
    - "216.239.35.0"
loadBalancer:
  vips:
    controlPlaneVIP: "172.16.20.30"
    ingressVIP: "172.16.20.31"
  kind: MetalLB Seesaw
  seesaw:
    ipBlockFilePath: "user-cluster-1-ipblock.yaml"
    vrid: 1
    masterIP: ""
    cpus: 4
    memoryMB: 3072
  metalLB:
    addressPools:
    - name: "address-pool-1"
      addresses:
      - "172.16.20.31/32"
      - "172.16.20.40 - 172.16.21.49"

Punti chiave dell'esempio precedente:

  • Anche se il cluster non utilizzerà più il bilanciatore del carico Seesaw, la sezione network.hostConfig è necessaria perché i nodi del cluster utilizzano indirizzi IP statici.

  • Il valore ingressVIP viene visualizzato nel pool di indirizzi MetalLB.

  • Gli indirizzi IP esterni 172.16.21.41 e 172.16.21.45 per i servizi esistenti di tipo LoadBalancer sono inclusi nel pool di indirizzi MetalLB.

Esempio: cluster di utenti kubeception, DHCP

Supponiamo che tu abbia un cluster utente che utilizza DHCP per i suoi nodi. Supponiamo inoltre che il cluster abbia due servizi di tipo LoadBalancer e che gli indirizzi esterni di questi servizi siano 172.16.21.61 e 172.16.21.65.

Modifica il file di configurazione del cluster utente nel seguente modo:

  • Rimuovi la sezione network.hostConfig.
  • Imposta loadBalancer.kind su MetalLB.
  • Rimuovi la sezione loadBalancer.seesaw.
  • Aggiungi una sezione loadBalancer.metalLB.

Esempio:

enableControlplaneV2: false
network:
  hostConfig:
    dnsServers:
    - "172.16.255.1"
    - "172.16.255.2"
    ntpServers:
    - "216.239.35.0"
loadBalancer:
  vips:
    controlPlaneVIP: "172.16.20.50"
    ingressVIP: "172.16.20.51"
  kind: MetalLB Seesaw
  seesaw:
    ipBlockFilePath: "user-cluster-2-ipblock.yaml"
    vrid: 1
    masterIP: ""
    cpus: 4
    memoryMB: 3072
  metalLB:
    addressPools:
    - name: "address-pool-1"
      addresses:
      - "172.16.20.51/32"
      - "172.16.20.60 - 172.16.21.69"

Punti chiave dell'esempio precedente:

  • Il cluster non utilizzerà più il bilanciatore del carico Seesaw e non userà indirizzi IP statici per i suoi nodi. Pertanto, la sezione network.hostConfig non è necessaria.

  • Il valore ingressVIP viene visualizzato nel pool di indirizzi MetalLB.

  • Gli indirizzi IP esterni 172.16.21.61 e 172.16.21.65 per i servizi esistenti di tipo LoadBalancer sono inclusi nel pool di indirizzi MetalLB.

Esempio: cluster utente Controlplane V2, DHCP

Supponiamo di avere un cluster utente in cui è attivato il piano di controllo v2 e che utilizza DHCP per i nodi worker. Supponiamo inoltre che il cluster abbia due servizi di tipo LoadBalancer e che gli indirizzi esterni di questi servizi siano 172.16.21.81 e 172.16.21.85.

Modifica il file di configurazione del cluster utente nel seguente modo:

  • Mantieni la sezione network.hostconfig.
  • Imposta loadBalancer.kind su MetalLB.
  • Rimuovi la sezione loadBalancer.seesaw.
  • Aggiungi una sezione loadBalancer.metalLB.

Esempio:

enableControlplaneV2: true
network:
  hostConfig:
    dnsServers:
    - "172.16.255.1"
    - "172.16.255.2"
    ntpServers:
    - "216.239.35.0"
loadBalancer:
  vips:
    controlPlaneVIP: "172.16.20.70"
    ingressVIP: "172.16.20.71"
  kind: MetalLB Seesaw
  seesaw:
    ipBlockFilePath: "user-cluster-2-ipblock.yaml"
    vrid: 1
    masterIP: ""
    cpus: 4
    memoryMB: 3072
  metalLB:
    addressPools:
    - name: "address-pool-1"
      addresses:
      - "172.16.20.71/32"
      - "172.16.20.80 - 172.16.21.89"

Punti chiave dell'esempio precedente:

  • Il cluster non utilizzerà più indirizzi IP statici per i nodi worker, ma utilizzerà indirizzi IP statici per i nodi del control plane. Pertanto, è necessaria la sezione network.hostConfig.

  • Il valore ingressVIP viene visualizzato nel pool di indirizzi MetalLB.

  • Gli indirizzi IP esterni 172.16.21.81 e 172.16.21.85 per i servizi esistenti di tipo LoadBalancer sono inclusi nel pool di indirizzi MetalLB.

Migrazione del cluster di amministrazione

Nel file di configurazione del cluster di amministrazione, imposta loadBalancer.kind su MetalLB e rimuovi la sezione loadBalancer.seesaw.

Aggiorna il cluster:

gkectl update admin --kubeconfig  ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG

Sostituisci quanto segue:

  • ADMIN_CLUSTER_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione

  • ADMIN_CLUSTER_CONFIG: il percorso del file di configurazione del cluster di amministrazione

Verifica che i componenti MetalLB siano in esecuzione correttamente: 

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

L'output mostra i pod per il controller e lo speaker MetalLB. Ad esempio:

metallb-controller-744884bf7b-rznr9   1/1     Running
metallb-speaker-6n8ws                 1/1     Running
metallb-speaker-nb52z                 1/1     Running
metallb-speaker-rq4pp                 1/1     Running

Dopo una migrazione riuscita, elimina manualmente le VM Seesaw, che sono già spente, per il cluster di amministrazione. Puoi trovare i nomi delle VM Seesaw nella sezione vmnames del file seesaw-for-gke-admin.yaml nella directory di configurazione.

Esempio: cluster di amministrazione, indirizzi IP statici

Supponiamo che tu abbia un cluster di amministrazione che utilizza indirizzi IP statici per i suoi nodi.

Modifica il file di configurazione del cluster di amministrazione come segue:

  • Mantieni la sezione network.hostConfig.
  • Imposta loadBalancer.kind su MetalLB.
  • Rimuovi la sezione loadBalancer.seesaw.

Esempio:

network:
  hostConfig:
    dnsServers:
    - "172.16.255.1"
    - "172.16.255.2"
    ntpServers:
    - "216.239.35.0"
loadBalancer:
  vips:
    controlPlaneVIP: "172.16.20.30"
  kind: MetalLB Seesaw
  seesaw:
    ipBlockFilePath: "user-cluster-1-ipblock.yaml"
    vrid: 1
    masterIP: ""
    cpus: 4
    memoryMB: 3072

Punto chiave dell'esempio precedente:

  • Anche se il cluster non utilizzerà più il bilanciatore del carico Seesaw, la sezione network.hostConfig è necessaria perché i nodi del cluster utilizzano indirizzi IP statici.

Esempio: cluster di amministrazione, DHCP

Supponiamo che tu abbia un cluster di amministrazione che utilizza DHCP per i suoi nodi del cluster.

Modifica il file di configurazione del cluster di amministrazione come segue:

  • Rimuovi la sezione network.hostConfig.
  • Imposta loadBalancer.kind su MetalLB.
  • Rimuovi la sezione loadBalancer.seesaw.

Esempio:

network:
  hostConfig:
    dnsServers:
    - "172.16.255.1"
    - "172.16.255.2"
    ntpServers:
    - "216.239.35.0"
loadBalancer:
  vips:
    controlPlaneVIP: "172.16.20.30"
  kind: MetalLB Seesaw
  seesaw:
    ipBlockFilePath: "user-cluster-1-ipblock.yaml"
    vrid: 1
    masterIP: ""
    cpus: 4
    memoryMB: 3072

Punto chiave dell'esempio precedente:

  • Il cluster non utilizzerà più il bilanciatore del carico Seesaw e non userà indirizzi IP statici per i suoi nodi. Pertanto, la sezione network.hostConfig non è necessaria.

Risoluzione dei problemi

Se gkectl update non riesce durante la migrazione del cluster utente e i pod MetalLB non sono in esecuzione nel cluster utente, accendi manualmente le VM Seesaw del cluster utente. In questo modo, il traffico verrà ristabilito per i VIP attualmente in uso. Tuttavia, i VIP appena creati potrebbero non essere pubblicati dalle VM Seesaw se il pod load-balancer-seesaw non è attivo. In questo caso, crea un ticket di assistenza.

Se gkectl update non riesce durante la migrazione del cluster di amministrazione e i pod MetalLB non sono in esecuzione nel cluster di amministrazione, accendi manualmente le VM Seesaw del cluster di amministrazione. In questo modo, il traffico verso i VIP del control plane attualmente in uso per i cluster di utenti potrebbe funzionare di nuovo. Tuttavia, l'indirizzo VIP per il control plane del cluster di amministrazione potrebbe non funzionare. In questo caso, modifica il file kubeconfig del cluster di amministrazione per utilizzare direttamente l'indirizzo IP del nodo del control plane del cluster di amministrazione.

Inoltre, nello spazio dei nomi kube-system, modifica il kube-apiserver tipo di servizio da ClusterIP a LoadBalancer. Se necessario, crea un ticket di assistenza.