Esegui la migrazione di un cluster di amministrazione ad HA

Anteprima

Questa funzionalità è soggetta ai "Termini dell'offerta pre-GA" nella sezione dei 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 ulteriori informazioni, consulta le descrizioni della fase di lancio.

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

Nota: se i cluster sono alla 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 HA 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 dei componenti aggiuntivi 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 abilitata nel cluster di amministrazione alla versione 1.14 o precedenti, devi ruotare la chiave di crittografia prima di avviare 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":""}]

Ruotare la chiave di crittografia, se necessario

Se i passaggi della sezione precedente hanno indicato che devi ruotare la chiave di crittografia, esegui i passaggi seguenti:

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 ricrittografato 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 ruotare la 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:

   • Attiva un cluster esterno (Kind) e garantisce che il cluster di amministrazione non HA corrente sia in uno stato 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 HA.

   • Riconcilia il cluster di amministrazione ripristinato per soddisfare lo stato finale del cluster di amministrazione HA.

Note

• Durante la migrazione, non si verifica alcun tempo di inattività per il carico di lavoro del cluster utente.

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

• I requisiti per i cluster di amministrazione HA sono ancora validi per la migrazione da non HA a HA. Ad esempio, i cluster di amministrazione HA non supportano Seesaw, quindi se utilizzi il bilanciatore 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.

• Al termine della migrazione, le risorse rimanenti, come la VM master di amministrazione non HA, vengono mantenute intenzionalmente per il ripristino in caso di errori.

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 del control plane	1	3
Nodi dei componenti aggiuntivi	2	0
Repliche 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 degli 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 di checkpoint	Questa opzione è attiva per impostazione predefinita	Non utilizzata

Modificare 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.

Specificare gli indirizzi IP

1. Nel file di configurazione del cluster di amministrazione, compila la network.controlPlaneIPBlock sezione. I nomi host sono obbligatori per i cluster di amministrazione HA. 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 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"
   

Aggiornare i 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 di amministrazione HA, i percorsi dei tre dischi dati utilizzati dai nodi del control plane vengono generati automaticamente nella directory principale anthos nel datastore.

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

Regolare la configurazione manuale del bilanciatore del carico

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

Per ognuno dei tre nuovi indirizzi IP dei nodi del control plane specificati nella 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.

Aggiornare il cluster di amministrazione

Esamina le modifiche alla configurazione apportate 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.