Questo documento mostra come eseguire la migrazione dal bilanciatore del carico Seesaw al bilanciatore del carico MetalLB.
L'utilizzo di MetalLB presenta diversi vantaggi rispetto ad altre opzioni di bilanciamento del carico.
Migrazione del cluster utente
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
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
Dopo una migrazione riuscita, elimina manualmente le VM di Seesaw, già disattivate, per il cluster utente. Puoi trovare i nomi delle VM Seesaw nella sezione vmnames
del file seesaw-for-[USERCLUSTERNAME].yaml
nella tua directory di configurazione.
Esempio: cluster utente, indirizzi IP statici
Supponi di avere un cluster utente che utilizza indirizzi IP statici per i nodi del cluster. Supponiamo anche che il cluster abbia due servizi di tipo LoadBalancer
e che gli indirizzi esterni per questi servizi siano 172.16.21.41 e 172.16.21.45.
Modifica il file di configurazione del cluster utente come segue:
- Mantieni la sezione
network.hostConfig
. - Imposta
loadBalancer.kind
suMetalLB
. - 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: MetalLBSeesawseesaw: ipBlockFilePath: "user-cluster-1-ipblock.yaml" vrid: 1 masterIP: "" cpus: 4 memoryMB: 3072metalLB: 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 di Seesaw, è necessaria la sezione
network.hostConfig
perché i nodi del cluster utilizzano indirizzi IP statici.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 i servizi esistenti 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. Supponiamo inoltre che il cluster abbia due servizi di tipo LoadBalancer
e che gli indirizzi esterni per questi servizi siano 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
suMetalLB
. - 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: MetalLBSeesawseesaw: ipBlockFilePath: "user-cluster-2-ipblock.yaml" vrid: 1 masterIP: "" cpus: 4 memoryMB: 3072metalLB: 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 utilizza indirizzi IP statici per i nodi del cluster. Pertanto, la sezione
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 i servizi esistenti di tipo
LoadBalancer
sono inclusi nel pool di indirizzi MetalLB.
Esempio: cluster utente Controlplane V2, DHCP
Supponi di avere un cluster utente per cui è abilitato Controlplane 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 per questi servizi siano 172.16.21.81 e 172.16.21.85.
Modifica il file di configurazione del cluster utente come segue:
- Mantieni la sezione
network.hostconfig
. - Imposta
loadBalancer.kind
suMetalLB
. - 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: MetalLBSeesawseesaw: ipBlockFilePath: "user-cluster-2-ipblock.yaml" vrid: 1 masterIP: "" cpus: 4 memoryMB: 3072metalLB: 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 indirizzi IP statici per i nodi del piano di controllo. Di conseguenza, la sezione
network.hostConfig
è necessaria.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 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 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
Dopo una migrazione riuscita, elimina manualmente le VM di Seesaw, già disattivate, per il cluster di amministrazione. Puoi trovare i nomi delle VM Seesaw nella sezione vmnames
del file seesaw-for-gke-admin.yaml
nella tua directory di configurazione.
Esempio: cluster di amministrazione, indirizzi IP statici
Supponi di avere un cluster di amministrazione che utilizza indirizzi IP statici per i nodi del cluster.
Modifica il file di configurazione del cluster di amministrazione come segue:
- Mantieni la sezione
network.hostConfig
. - Imposta
loadBalancer.kind
suMetalLB
. - 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: MetalLBSeesawseesaw: 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 di Seesaw, è necessaria la sezione
network.hostConfig
perché i nodi del cluster utilizzano indirizzi IP statici.
Esempio: cluster di amministrazione, DHCP
Supponi di avere un cluster di amministrazione che utilizza DHCP per i nodi del cluster.
Modifica il file di configurazione del cluster di amministrazione come segue:
- Rimuovi la sezione
network.hostConfig
. - Imposta
loadBalancer.kind
suMetalLB
. - 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: MetalLBSeesawseesaw: 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 utilizza indirizzi IP statici per i nodi del cluster. Pertanto, la sezione
network.hostConfig
non è necessaria.
Risoluzione dei problemi
Se gkectl update
ha esito negativo durante la migrazione del cluster utente e i pod Metallb non sono in esecuzione nel cluster utente, attiva manualmente le VM di Seesaw del cluster utente.
In questo modo il traffico verrà ripristinato ai VIP attualmente utilizzati. Tuttavia, i VIP appena creati
potrebbero non essere serviti dalle VM Seesaw se il pod load-balancer-seesaw
non è
in esecuzione. 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. Ciò potrebbe consentire il traffico ai VIP del piano di controllo attualmente in uso per far funzionare di nuovo i cluster utente. Tuttavia, il VIP per il piano di controllo
del cluster di amministrazione stesso potrebbe non funzionare. In questo caso, modifica il file kubeconfig del cluster di amministrazione in modo che utilizzi 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
da ClusterIP
a LoadBalancer
. Se necessario, crea un ticket di assistenza.