Questo documento mostra come eseguire la migrazione dal bilanciatore del carico Seesaw Bilanciatore del carico MetalLB per dalla versione 1.16 alla 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'uso di MetalLB prevede diverse vantaggi rispetto ad altri 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 risolvere questo problema.
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 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. Questo processo richiede in genere 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
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
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 Seesaw nella sezione vmnames
del file seesaw-for-[USERCLUSTERNAME].yaml
nella directory di configurazione.
Esempio: cluster utente, indirizzi IP statici
Supponi di avere un cluster utente che utilizza indirizzi IP statici per il proprio cluster
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 come segue:
- Conserva 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 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 di utenti kubeception, DHCP
Supponiamo che tu abbia un cluster utente che utilizza DHCP per i suoi nodi. 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
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, 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 i servizi esistenti di tipo
LoadBalancer
sono inclusi nel pool di indirizzi MetalLB.
Esempio: cluster utente del piano di controllo V2, DHCP
Supponiamo di avere un cluster utente in cui è attivato Control Plane 2 e che utilizza DHCP per i 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 nel seguente modo:
- 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, utilizzerà indirizzi IP statici per i nodi del piano di controllo. Pertanto, è necessaria la sezione
network.hostConfig
.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 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 di Seesaw
Sezione vmnames
del file seesaw-for-gke-admin.yaml
nel tuo
di configurazione del deployment.
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
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 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
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 userà indirizzi IP statici per i suoi nodi. Quindi la
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 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
non riesce 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. 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 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.