Migrazione dal bilanciatore del carico di Seesaw a MetalLB

Questo documento mostra come eseguire la migrazione dal bilanciatore del carico Seesaw Bilanciatore del carico MetalLB.

L'uso di MetalLB prevede diverse vantaggi rispetto ad altri opzioni di bilanciamento del carico.

1.28 e successive: GA

1.16: Anteprima

Note sul tempo di inattività

Si è verificato un tempo di inattività del carico di lavoro durante la migrazione. Le note seguenti sono valide solo ai cluster di amministrazione ad alta disponibilità (non ad alta disponibilità) perché il carico di SeeSaw non supporta i cluster di amministrazione ad alta disponibilità.

  • Quando esegui la migrazione di un cluster di amministrazione:

    • È previsto un tempo di inattività del piano di controllo per i cluster utente kubeception È stata eseguita la migrazione di controlPlaneVIP. Il tempo di inattività deve essere inferiore a 10 minuti, ma la durata del tempo di inattività dipende dall'infrastruttura.

    • Tempo di inattività per il piano di controllo del cluster di amministrazione in quanto amministratore master il nodo deve essere ricreato con il controlPlaneVIP direttamente collegato la VM. Il tempo di inattività dovrebbe essere inferiore a 20 minuti, ma la durata il tempo di inattività dipende dall'infrastruttura.

  • Durante la migrazione di un cluster utente, i VIP subiscono un'interruzione dopo il Il bilanciatore del carico Seesaw è spento e prima che vengano visualizzati i pod MetalLB. Questo processo richiede in genere circa un minuto.

Migrazione del cluster utente

Nel file di configurazione del cluster utente, scegli un pool di nodi e imposta Da enableLoadBalancer a 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 di kubeconfig del cluster di amministrazione file

  • USER_CLUSTER_CONFIG: il percorso della configurazione del cluster utente file

Quindi, rimuovi le sezioni Seesaw dal file e aggiungi una sezione MetalLB.

Quindi aggiorna di nuovo il cluster:

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Verifica che i componenti MetalLB funzionino 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

Al termine della migrazione, elimina manualmente le VM di Seesaw, che sono già per il cluster utente. Puoi trovare i nomi delle VM di Seesaw Sezione vmnames del file seesaw-for-[USERCLUSTERNAME].yaml nel tuo di configurazione del deployment.

Esempio: cluster utente, indirizzi IP statici

Supponi di avere un cluster utente che utilizza indirizzi IP statici per il proprio cluster nodi. Supponi inoltre che il cluster abbia due servizi di tipo LoadBalancer, e gli indirizzi esterni per tali Servizi sono 172.16.21.41 e 172.16.21.45.

Modifica il file di configurazione del cluster utente come segue:

  • Conserva 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 un IP statico indirizzi IP esterni.

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

  • Gli indirizzi IP esterni, 172.16.21.41 e 172.16.21.45, per gli indirizzi IP I servizi di tipo LoadBalancer sono inclusi nel pool di indirizzi MetalLB.

Esempio: cluster utente kubeception, DHCP

Supponi di avere un cluster utente che utilizza DHCP per i nodi del cluster. Inoltre supponiamo che il cluster abbia due servizi di tipo LoadBalancer e gli indirizzi esterni per tali Servizi sono 172.16.21.61 e 172.16.21.65.

Modifica il file di configurazione del cluster utente come segue:

  • 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, che non utilizzino indirizzi IP statici per i nodi del cluster. Quindi la network.hostConfig non è necessaria.

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

  • Gli indirizzi IP esterni, 172.16.21.61 e 172.16.21.65, per gli indirizzi IP I servizi di tipo LoadBalancer sono inclusi nel pool di indirizzi MetalLB.

Esempio: cluster utente del piano di controllo V2, DHCP

Supponi di avere un cluster utente con il piano di controllo V2 abilitato e che utilizza DHCP per i suoi nodi worker. Supponi inoltre che il cluster abbia due servizi di tipo LoadBalancer, e gli indirizzi esterni per tali Servizi sono 172.16.21.81 e 172.16.21.85.

Modifica il file di configurazione del cluster utente come segue:

  • Conserva 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, utilizzerà indirizzi IP statici per i nodi del piano di controllo. Quindi, La sezione network.hostConfig è obbligatoria.

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

  • Gli indirizzi IP esterni, 172.16.21.81 e 172.16.21.85, per gli indirizzi IP I servizi 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 di kubeconfig del cluster di amministrazione file

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

Verifica che i componenti Metallb funzionino 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

Al termine della migrazione, elimina manualmente le VM di Seesaw, che sono già per il cluster di amministrazione. Puoi trovare i nomi delle VM di Seesaw Sezione vmnames del file seesaw-for-gke-admin.yaml nel tuo di configurazione del deployment.

Esempio: cluster di amministrazione, indirizzi IP statici

Supponi di avere un cluster di amministrazione che utilizza indirizzi IP statici per il proprio cluster nodi.

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

  • Conserva 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 un IP statico indirizzi IP esterni.

Esempio: cluster di amministrazione, DHCP

Supponi di avere un cluster di amministrazione che utilizza DHCP per il proprio cluster nodi.

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, che non utilizzino indirizzi IP statici per i nodi del cluster. Quindi la network.hostConfig non è necessaria.

Risoluzione dei problemi

Se gkectl update si verifica un errore durante la migrazione del cluster utente e i pod metallb vengono se non è in esecuzione nel cluster utente, attiva manualmente le VM Seesaw del cluster utente. In questo modo verrà ristabilito il traffico per i VIP attualmente in uso. ma i VIP appena creati potrebbe non essere gestito dalle VM di Seesaw se il pod load-balancer-seesaw non è in esecuzione. In questo caso, crea un ticket di assistenza.

Se gkectl update si verifica un errore durante la migrazione del cluster di amministrazione e i pod metallb non sono in esecuzione nel cluster di amministrazione, accendi manualmente il cluster di amministrazione Seesaw delle VM in esecuzione. Ciò potrebbe consentire il traffico verso i VIP del piano di controllo attualmente utilizzati per l'utente per far funzionare di nuovo i cluster. Il VIP per il piano di controllo del cluster di amministrazione potrebbe non funzionare. In tal caso, modifica il file kubeconfig del modulo per utilizzare direttamente l'indirizzo IP del nodo del piano di controllo del cluster di amministrazione.

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