Esegui la migrazione di un cluster di amministrazione ad HA

Anteprima

Questa funzionalità è soggetta ai "Termini delle Offerte pre-GA" nella sezione Termini di servizio generali 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.

Questa pagina mostra come eseguire la migrazione a un cluster di amministrazione ad alta disponibilità (HA) da un cluster di amministrazione non HA alla versione 1.29.

Nota: se i tuoi cluster hanno la versione 1.30 o successive, ti consigliamo di utilizzare un approccio semplificato descritto in Pianificare la migrazione del cluster alle funzionalità consigliate.

1.29: Anteprima
1.28: Non disponibile

Prima e dopo la migrazione, il cluster di amministrazione ha tre nodi:

• Un cluster di amministrazione non ad alta disponibilità ha un nodo del control plane e due nodi dei componenti aggiuntivi.
• Un cluster di amministrazione HA ha tre nodi del control plane e nessun nodo aggiuntivo e la disponibilità è notevolmente migliorata.

Prepararsi per la migrazione

Se la versione del cluster di amministrazione è 1.29.0-1.29.600 o 1.30.0-1.30.100 e se la crittografia dei secret sempre attiva è stata attivata nel cluster di amministrazione alla versione 1.14 o precedente, devi ruotare la chiave di crittografia prima di iniziare la migrazione. In caso contrario, il nuovo cluster di amministrazione HA non sarà in grado di decriptare i secret.

Per verificare se il cluster potrebbe utilizzare una vecchia chiave di crittografia:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secret -n kube-system admin-master-component-options -o jsonpath='{.data.data}' | base64 -d | grep -oP '"GeneratedKeys":\[.*?\]'

Se l'output mostra una chiave vuota, come nell'esempio seguente, devi ruotare la chiave di crittografia.

"GeneratedKeys":[{"KeyVersion":"1","Key":""}]

Ruota la chiave di crittografia, se necessario

Se i passaggi della sezione precedente hanno mostrato che devi ruotare la chiave di crittografia, segui questi passaggi:

1. Incrementa keyVersion nel file di configurazione del cluster di amministrazione.

2. Aggiorna il cluster di amministrazione:

   gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
     --config ADMIN_CLUSTER_CONFIG
   

   Viene creata una nuova chiave corrispondente al nuovo numero di versione, ogni secret viene nuovamente criptato e i vecchi secret vengono cancellati in modo sicuro. Tutti i nuovi secret successivi vengono criptati utilizzando la nuova chiave di crittografia.

Avviso: se hai avviato la migrazione senza eseguire la rotazione della chiave di crittografia, contatta l'assistenza Google.

Panoramica della procedura

La migrazione prevede i seguenti passaggi principali:

1. Modifica il file di configurazione del cluster di amministrazione.

2. Esegui gkectl update admin. Questo comando esegue le seguenti operazioni:

   • Visualizza un cluster esterno (Kind) e verifica che il cluster di amministrazione non HA corrente sia integro.

   • Crea un nuovo control plane del cluster di amministrazione utilizzando la specifica HA e un nuovo VIP del control plane.

   • Disattiva il control plane del cluster di amministrazione esistente.

   • Acquisisce uno snapshot etcd del cluster di amministrazione esistente.

   • Ripristina i vecchi dati del cluster di amministrazione nel nuovo control plane ad alta disponibilità.

   • Esegue la riconciliazione del cluster di amministrazione ripristinato per soddisfare lo stato finale del cluster di amministrazione ad alta disponibilità.

Note

• Durante la migrazione, non si verificano tempi di inattività per il carico di lavoro del cluster utente.

• Durante la migrazione, il control plane del cluster di amministrazione non è disponibile per un breve periodo. (Il tempo di inattività è inferiore a 18 minuti, in base ai nostri test, ma la durata effettiva dipende dai singoli ambienti dell'infrastruttura).

• I requisiti per i cluster di amministrazione ad alta disponibilità valgono anche per la migrazione da non ad alta disponibilità ad alta disponibilità. Ad esempio, i cluster di amministrazione HA non supportano Seesaw, quindi se utilizzi il bilanciamento del carico Seesaw per un cluster di amministrazione non HA, devi prima eseguire la migrazione a MetalLB prima di eseguire la migrazione a un cluster di amministrazione HA.

• Una volta completata correttamente la migrazione, le risorse rimanenti, come la VM master amministratore non HA, vengono mantenute intenzionalmente per il ripristino in caso di errore.

Prima e dopo la migrazione

La seguente tabella mostra le principali differenze nel cluster prima e dopo la migrazione:

	Prima della migrazione	Dopo la migrazione
Repliche del nodo control plane	1	3
Nodi aggiuntivi	2	0
Replica dei pod del control plane (kube-apiserver, kube-etcd e così via)	1	3
Dimensione disco dati	100GB * 1	25GB * 3
Percorso dei dischi dati	Impostato da vCenter.dataDisk nel file di configurazione del cluster di amministrazione	Generato automaticamente nella directory: /anthos/[ADMIN_CLUSTER_NAME]/default/[MACHINE_NAME]-data.vmdk
Bilanciatore del carico per il VIP del control plane	Impostato da loadBalancer.kind nel file di configurazione del cluster di amministrazione	keepalived + haproxy
Allocazione degli indirizzi IP per i nodi del control plane del cluster di amministrazione	DHCP o statico, a seconda di network.ipMode.type	3 indirizzi IP statici
Allocazione di indirizzi IP per i nodi del control plane del cluster utente kubeception	DHCP o statico, a seconda di network.ipMode.type	DHCP o statico, a seconda di network.ipMode.type
File checkpoint	Questa opzione è attiva per impostazione predefinita	Non utilizzata

Modifica il file di configurazione del cluster di amministrazione

Devi specificare quattro indirizzi IP aggiuntivi:

• Tre indirizzi IP per i nodi del control plane del cluster di amministrazione
• Un nuovo VIP del control plane per il bilanciatore del carico del cluster di amministrazione

Devi anche modificare alcuni altri campi nel file di configurazione del cluster di amministrazione, come descritto nelle sezioni seguenti.

Specifica gli indirizzi IP

1. Nel file di configurazione del cluster di amministrazione, compila la sezione network.controlPlaneIPBlock. Ad esempio:

   controlPlaneIPBlock:
     netmask: "255.255.255.0"
     gateway: "172.16.20.1"
     ips:
     - ip: "172.16.20.50"
       hostname: "admin-cp-node-1"
     - ip: "172.16.20.51"
       hostname: "admin-cp-node-2"
     - ip: "172.16.20.52"
       hostname: "admin-cp-node-3"
   

2. Compila la sezione hostconfig. Se il cluster di amministrazione utilizza indirizzi IP statici, questa sezione è già compilata. Ad esempio:

   hostConfig:
     dnsServers:
     - 203.0.113.1
     - 198.51.100.1
     ntpServers:
     - 216.239.35.12
   

3. Sostituisci il valore di loadBalancer.vips.controlPlaneVIP con un nuovo VIP. Ad esempio:

   loadBalancer:
    vips:
      controlPlaneVIP: "172.16.20.59"
   

Aggiorna i campi di configurazione aggiuntivi

1. Imposta adminMaster.replicas su 3:

   adminMaster:
    replicas: 3
    cpus: 4
    memoryMB: 8192
   

2. Rimuovi il campo vCenter.dataDisk. Per un cluster di amministrazione HA, i percorsi dei tre dischi dati utilizzati dai nodi del control plane vengono generati automaticamente nella directory radice anthos nel datastore.

3. Se loadBalancer.manualLB.controlPlaneNodePort ha un valore diverso da zero, impostalo su 0.

Modifica la configurazione del bilanciatore del carico manuale

Se il cluster di amministrazione utilizza il bilanciamento del carico manuale, completa questa sezione. In caso contrario, salta questa sezione.

Per ciascuno dei tre nuovi indirizzi IP dei nodi del control plane specificati nella sezione network.controlPlaneIPBlock, configura il seguente mapping nel bilanciatore del carico:

(old controlPlaneVIP:443) -> (NEW_NODE_IP_ADDRESS:old controlPlaneNodePort)

Questo mapping garantisce che il vecchio VIP del control plane funzioni durante la migrazione.

Aggiorna il cluster di amministrazione

Rivedi le modifiche alla configurazione che hai apportato perché i campi sono immutabili. Dopo aver verificato che le modifiche siano corrette, aggiorna il cluster.

1. Avvia la migrazione:

   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

2. Il comando mostra l'avanzamento della migrazione.

   Quando richiesto, inserisci Y per continuare.

3. Al termine della migrazione, il file kubeconfig del cluster di amministrazione viene aggiornato automaticamente per utilizzare il nuovo VIP del control plane. Il VIP del control plane precedente continua a funzionare e può essere utilizzato anche per accedere al nuovo cluster di amministrazione HA.