Esegui la migrazione di un cluster utente al piano di controllo V2

Anteprima

Questa funzionalità è soggetta ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici dei servizi. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

Questo documento mostra come eseguire la migrazione di un cluster utente versione 1.29 o successiva utilizzando kubeception per il piano di controllo V2.

1.29: Anteprima
1.28: Non disponibile
1.16: Non disponibile

Informazioni sui piani di controllo dei cluster utente

Prima di Google Distributed Cloud versione 1.13, il piano di controllo per un cluster utente eseguito su uno o più nodi in un cluster di amministrazione. Questo tipo di piano di controllo noto come kubeception. Nella versione 1.13, è stato introdotto il piano di controllo V2 per i nuovi cluster utente. Quando il piano di controllo V2 è abilitato, il piano di controllo per il cluster utente viene eseguito nel cluster utente stesso.

Ecco i vantaggi del piano di controllo V2:

• Isolamento per errore. L'errore di un cluster di amministrazione non influisce sui cluster utente.

• Separazione operativa. L'upgrade del cluster di amministrazione non causa tempi di inattività per i cluster utente.

• Separazione dei deployment. Puoi collocare i cluster di amministrazione e utente domini o siti geografici in errore. Ad esempio, un cluster utente in un la posizione sul perimetro potrebbe essere in un sito diverso da quello dell'amministratore in un cluster Kubernetes.

Requisiti

Per eseguire la migrazione di un cluster utente al piano di controllo V2, il cluster utente deve soddisfare i seguenti requisiti:

• La versione del cluster utente deve essere 1.29 o successiva. Il cluster di amministrazione e I pool di nodi possono essere una o due versioni secondarie inferiori al cluster utente. Se necessario, esegui l'upgrade del cluster.

• Il cluster utente deve avere Dataplane V2 in un bucket in cui è abilitato il controllo delle versioni. Questo campo è immutabile, quindi se Dataplane V2 non è abilitato sulla non puoi eseguirne la migrazione al piano di controllo V2.

• Il cluster utente deve essere configurato in modo da utilizzare MetalLB o un cluster manuale con il bilanciatore del carico di rete passthrough esterno regionale. Se il cluster utente utilizza il bilanciatore del carico SeeSaw, puoi eseguire la migrazione a MetalLB.

• Esamina il documento di pianificazione degli indirizzi IP, e assicurati di avere a disposizione un numero sufficiente di indirizzi IP per l'utente dai nodi del piano di controllo del cluster. I nodi del piano di controllo richiedono indirizzi IP statici, mentre è necessario un indirizzo IP aggiuntivo per un nuovo IP virtuale (VIP) del piano di controllo.

Aggiorna il file di configurazione del cluster utente

Apporta le seguenti modifiche al file di configurazione del cluster utente esistente:

1. Imposta enableControlplaneV2 su true.

2. Facoltativamente, crea il piano di controllo per il cluster utente del piano di controllo V2 ad alta disponibilità (HA). Per passare da un cluster non ad alta disponibilità a uno ad alta disponibilità, modifica masterNode.replicas da 1 a 3.

3. Aggiungi l'indirizzo o gli indirizzi IP statici per il piano di controllo del cluster utente uno o più nodi network.controlPlaneIPBlock.ips .

4. Compila la netmask e il gateway nella network.controlPlaneIPBlock .

5. Se network.hostConfig è vuota, compilala.

6. Se il cluster utente utilizza bilanciamento del carico manuale, al tuo bilanciatore del carico per includere IP dei nodi del piano di controllo per il traffico del piano dati:

   • (ingressVIP:80) -> (CP_NODE_IP_ADDRESSES:ingressHTTPNodePort)
   • (ingressVIP:443) -> (CP_NODE_IP_ADDRESSES:ingressHTTPSNodePort)

7. Aggiorna il loadBalancer.vips.controlPlaneVIP con il nuovo indirizzo IP per il VIP del piano di controllo. Tieni presente che deve Essere nella stessa VLAN degli IP dei nodi del piano di controllo.

8. Tutti i campi precedenti sono immutabili, tranne durante l'aggiornamento del cluster per la migrazione. Assicurati di controllare attentamente tutte le impostazioni.

9. Esegui gkectl diagnose cluster, e risolvere eventuali problemi rilevati dal comando.

   gkectl diagnose cluster --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
         --cluster-name=USER_CLUSTER_NAME

   Sostituisci quanto segue:

   • ADMIN_CLUSTER_KUBECONFIG: il percorso dell'amministratore kubeconfig del cluster.

   • CLUSTER_NAME: il nome del cluster utente.

Regola la configurazione manuale del bilanciatore del carico

Se il cluster utente utilizza il bilanciamento del carico manuale, esegui il passaggio in questa sezione. In caso contrario, salta questa sezione.

Analogamente alla configurazione del bilanciatore del carico per un cluster utente CPv2, per ciascuno dei tre nuovi indirizzi IP dei nodi del piano di controllo che hai specificato nel network.controlPlaneIPBlock configura le mappature nel tuo bilanciatore del carico:

• (ingressVIP:80) -> (NEW_NODE_IP_ADDRESS:ingressHTTPNodePort)
• (ingressVIP:443) -> (NEW_NODE_IP_ADDRESS:ingressHTTPNodePort)

Aggiorna il cluster

Esegui questo comando per eseguire la migrazione del cluster a Controlplane V2:

gkectl update cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG

Sostituisci quanto segue:

• ADMIN_CLUSTER_KUBECONFIG: il percorso del cluster di amministrazione kubeconfig.

• USER_CLUSTER_CONFIG: il percorso del cluster utente di configurazione del deployment.

Il comando esegue queste operazioni:

1. Crea il piano di controllo di un nuovo cluster con il piano di controllo V2 abilitato.

2. Arresta il piano di controllo Kubernetes del cluster kubeception.

3. Acquisisci uno snapshot etcd del cluster kubeception.

4. Spegni i nodi del piano di controllo del cluster kubeception. Tieni presente che per il ripristino da errori, ovvero per fare ricorso al cluster kubeception, i nodi non vengono eliminati fino al completamento della migrazione.

5. Ripristina i dati del cluster nel nuovo piano di controllo con lo snapshot etcd sopra indicato.

6. Connetti i nodi del pool di nodi del cluster kubeception al nuovo piano di controllo, a cui è possibile accedere con il nuovo controlPlaneVIP.

7. Riconcilia il cluster utente ripristinato per soddisfare lo stato finale del cluster con ControlPlane V2 abilitato.

Note

• Durante la migrazione, non sono previsti tempi di inattività per i carichi di lavoro del cluster utente.

• Durante la migrazione, si è verificato un tempo di inattività per il piano di controllo del cluster utente. In particolare, il piano di controllo non sarà disponibile tra il passaggio 2 e il completamento del passaggio 6. In base ai nostri test, il tempo di inattività è inferiore a 7 minuti, ma la durata effettiva dipende dall'infrastruttura.

• Al termine della migrazione, i nodi del piano di controllo del cluster utente dei cluster kubeception vengono eliminati. Se nel cluster di amministrazione il campo network.ipMode.type è impostato su "statico", puoi riciclare alcuni IP statici inutilizzati rimuovendoli dal file di configurazione del cluster di amministrazione ed eseguire gkectl update admin. Puoi elencare i nodi del cluster di amministrazione con kubectl get nodes -o wide per vedere quali IP sono in uso.