Migrazione di un cluster di amministrazione ad alta disponibilità

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.

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

Nota: se i tuoi cluster sono alla versione 1.30 o successiva, ti consigliamo di utilizzare un approccio semplificato descritto in Pianificare la migrazione dei cluster alle funzionalità consigliate.

1.29: Anteprima
1.28: Non disponibile

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

• Un cluster di amministrazione non ad alta disponibilità ha un nodo del piano di controllo e due nodi aggiuntivi.
• Un cluster di amministrazione ad alta disponibilità ha tre nodi del piano di controllo e nessun nodo aggiuntivo. la disponibilità è notevolmente migliorata.

Prepararsi per la migrazione

Se la versione del tuo 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 nella 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 potrà decriptare i secret.

Per verificare se è possibile che il cluster utilizzi 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":""}]

Se necessario, ruota la chiave di crittografia

Se i passaggi nella sezione precedente hanno mostrato che devi ruotare di crittografia dei dati, segui questi passaggi:

1. Aumenta 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, viene sottoposta a nuova crittografia ogni secret e i vecchi secret vengono cancellati in modo sicuro. Tutti i nuovi secret successivi usando la nuova chiave di crittografia.

Avviso: se hai avviato la migrazione senza ruotare la chiave di crittografia, contatta dall'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 queste operazioni:

   • Attiva un cluster esterno (kind) e garantisce che l'amministratore attuale non ad alta disponibilità è in stato integro.

   • Crea un nuovo piano di controllo del cluster di amministrazione utilizzando la specifica HA e un nuovo VIP del piano di controllo.

   • Disattiva il control plane del cluster di amministrazione esistente.

   • Acquisisce uno snapshot etcd del cluster di amministrazione esistente.

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

   • Riconcilia il cluster di amministrazione ripristinato in modo che soddisfi lo stato finale del cluster di amministrazione ad alta disponibilità.

Note

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

• Durante la migrazione, si è verificato un tempo di inattività per il piano di controllo del cluster di amministrazione. (Il tempo di riposo è inferiore a 18 minuti, in base ai nostri test, ma la durata effettiva dipende dai singoli ambienti di infrastruttura).

• I requisiti per i cluster di amministrazione ad alta disponibilità sono ancora validi per la migrazione da un'alta disponibilità ad alta disponibilità. Ad esempio, i cluster di amministrazione ad alta disponibilità non supportano Seesaw, quindi se utilizzi il bilanciatore del carico Seesaw per un cluster di amministrazione non ad alta disponibilità, devi prima eseguire la migrazione a MetalLB prima di eseguire la migrazione a un cluster di amministrazione ad alta disponibilità.

• Una volta completata la migrazione, le risorse rimanenti, come la VM principale amministrativa non HA, vengono intenzionalmente conservate per il recupero in caso di errore.

Prima e dopo la migrazione

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

	Prima della migrazione	Dopo la migrazione
Repliche del nodo control plane	1	3
Nodi aggiuntivi	2	0
Repliche dei pod del piano di controllo (kube-apiserver, kube-etcd e così via)	1	3
Dimensione del disco dati	100GB * 1	25 GB * 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 piano di controllo	Impostato da loadBalancer.kind nel file di configurazione del cluster di amministrazione	keepalived + haproxy
Allocazione degli indirizzi IP per i nodi del piano di controllo del cluster di amministrazione	DHCP o statico, a seconda di network.ipMode.type	3 indirizzi IP statici
Alloca gli 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 dei checkpoint	Questa opzione è attiva per impostazione predefinita	Non utilizzate

Modifica il file di configurazione del cluster di amministrazione

Devi specificare altri quattro indirizzi IP:

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

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

Specifica gli indirizzi IP

1. Nel file di configurazione del cluster di amministrazione, compila 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 campi di configurazione aggiuntivi

1. Imposta adminMaster.replicas su 3:

   adminMaster:
    replicas: 3
    cpus: 4
    memoryMB: 8192
   

2. Rimuovi il vCenter.dataDisk . Per un cluster amministrativo ad alta disponibilità, i percorsi dei tre dischi di dati utilizzati dai nodi del piano di controllo vengono generati automaticamente nella directory principale anthos nel datastore.

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

Modificare 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 piano di controllo specificati nella sezione network.controlPlaneIPBlock, configura la seguente mappatura nel bilanciatore del carico:

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

Questa mappatura garantisce il funzionamento del vecchio VIP del control plane durante la migrazione.

Aggiorna il cluster di amministrazione

Esamina le modifiche apportate alla configurazione perché i campi sono immutabili. Dopo aver confermato che le modifiche sono 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 della configurazione del cluster di amministrazione file

2. Il comando visualizza l'avanzamento della migrazione.

   Quando richiesto, inserisci Y per continuare.

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