Questa pagina è stata tradotta dall'API Cloud Translation.

Migrazione di un cluster di amministrazione ad alta disponibilità

Questo documento mostra come eseguire la migrazione a un cluster di amministrazione ad alta disponibilità da un cluster di amministrazione non ad alta disponibilità.

1.29: Anteprima
1.28: Non disponibile
1.16: Non disponibile

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

Panoramica della procedura

Di seguito sono riportati i passaggi principali necessari per una migrazione:

Modifica il file di configurazione del cluster di amministrazione.
Esegui gkectl update admin. Questo comando esegue le seguenti operazioni:
- Apri un cluster esterno (Kind) e assicurati che il cluster di amministrazione non ad alta disponibilità attuale sia in stato integro.
- Crea un nuovo piano di controllo del cluster di amministrazione utilizzando le specifiche ad alta disponibilità e un nuovo VIP del piano di controllo.
- Disattiva il piano di controllo del cluster di amministrazione esistente.
- Acquisisci uno snapshot etcd del cluster di amministrazione esistente.
- Ripristina i dati del cluster di amministrazione precedente nel nuovo piano di controllo ad alta disponibilità.
- Riconciliazione del cluster di amministrazione ripristinato per soddisfare 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 verifica un tempo di inattività per il piano di controllo del cluster di amministrazione. Secondo il nostro test, il tempo di inattività è inferiore a 18 minuti, ma la durata effettiva dipende dai singoli ambienti dell'infrastruttura.
I requisiti dei cluster di amministrazione ad alta disponibilità sono ancora validi per la migrazione da un'alta disponibilità ad alta disponibilità. In altre parole, se utilizzi il bilanciatore del carico Seesaw per un cluster di amministrazione non ad alta disponibilità, devi prima eseguire la migrazione a MetalLB, quindi eseguire la migrazione a un cluster di amministrazione ad alta disponibilità. Questo perché un cluster di amministrazione ad alta disponibilità non supporta Seesaw.
Al termine della migrazione, le risorse rimaste (ad es. la VM master di amministrazione non ad alta disponibilità) saranno conservate intenzionalmente per garantire il ripristino da errori. Se necessario, puoi pulirli manualmente.

Prima e dopo la migrazione

Queste sono le differenze principali nel cluster prima e dopo la migrazione:

	Prima della migrazione	Dopo la migrazione
Repliche del nodo del piano di controllo	1	3
Nodi aggiuntivi	2	0
Repliche dei pod del piano di controllo (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 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
Allocazione degli indirizzi IP per i nodi del piano di controllo 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 quattro indirizzi IP aggiuntivi:

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 nel file di configurazione del cluster di amministrazione.

Specifica gli indirizzi IP

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"

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
```
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

Imposta adminMaster.replicas su 3:

adminMaster:
 replicas: 3
 cpus: 4
 memoryMB: 8192

Rimuovi il campo vCenter.dataDisk. Questo perché, per un cluster di amministrazione ad alta disponibilità, i percorsi dei tre dischi di dati utilizzati dai nodi del piano di controllo vengono generati automaticamente nella directory principale anthos del datastore.
Se loadBalancer.manualLB.controlPlaneNodePort ha un valore diverso da zero, impostalo su 0.

Regola la configurazione manuale del bilanciatore del carico

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

Per ciascuno dei tre nuovi indirizzi IP dei nodi del piano di controllo che hai specificato nella sezione network.controlPlaneIPBlock, configura questa mappatura nel tuo bilanciatore del carico:

(vecchio pianodicontrolloVIP:443) -> (NEW_NODE_IP_ADDRESS:vecchio pianodicontrolloNodePort)

In questo modo, il VIP precedente del piano di controllo funzionerà durante la migrazione.

Aggiorna il cluster di amministrazione

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
Il comando mostra l'avanzamento della migrazione.

Quando richiesto, inserisci Y per continuare.
Al termine della migrazione, il file kubeconfig del cluster di amministrazione viene aggiornato automaticamente per utilizzare il nuovo VIP del piano di controllo. Nel frattempo, il VIP del piano di controllo precedente continua a funzionare e può essere utilizzato anche per accedere al nuovo cluster di amministrazione ad alta disponibilità.

Se necessario, esegui la pulizia manuale delle risorse rimaste

Durante la migrazione, gkectl non elimina la VM del piano di controllo del cluster di amministrazione. ma arresta la VM invece di eliminarla da vSphere. Se vuoi eliminare la VM del piano di controllo precedente dopo una migrazione riuscita, devi eseguire l'eliminazione manualmente.

Per eliminare manualmente la VM precedente del piano di controllo e le risorse correlate:

Assicurati che la VM master di amministrazione non ad alta disponibilità gke-admin-master-xxx sia già spenta.
Elimina la VM master di amministrazione non ad alta disponibilità gke-admin-master-xxx da vSphere.
Elimina il modello di VM master di amministrazione non ad alta disponibilità gke-admin-master-xxx-tmpl da vSphere.
Elimina il disco dei dati amministrativi non ad alta disponibilità e il file del punto di controllo amministratore.
Pulisci i file temporanei salvati in /home/ubuntu/admin-ha-migration/[ADMIN_CLUSTER_NAME]/.

Di seguito sono riportati i comandi govc se si preferisce utilizzare l'interfaccia a riga di comando:

  // Configure govc credentials
  export GOVC_INSECURE=1
  export GOVC_URL=VCENTER_URL
  export GOVC_DATACENTER=DATACENTER
  export GOVC_DATASTORE=DATASTORE
  export GOVC_USERNAME=USERNAME
  export GOVC_PASSWORD=PASSWORD

  // Configure admin master VM name (you can find the master VM name from the "[HA Migration]" logs)
  export ADMIN_MASTER_VM=ADMIN_MASTER_VM_NAME

  // Configure datadisk path (remove ".vmdk" suffix)
  export DATA_DISK_PATH=DATADISK_PATH_WITHOUT_VMDK

  // Check whether admin master is in "poweredOff" state:
  govc vm.info $ADMIN_MASTER_VM | grep Power

  // Delete admin master VM
  govc vm.destroy $ADMIN_MASTER_VM

  // Delete admin master VM template
  govc vm.destroy "$ADMIN_MASTER_VM"-tmpl

  // Delete data disk
  govc datastore.ls $DATA_DISK_PATH
  govc datastore.rm $DATA_DISK_PATH

  // Delete admin checkpoint file
  govc datastore.ls "$DATA_DISK_PATH"-checkpoint.yaml
  govc datastore.rm "$DATA_DISK_PATH"-checkpoint.yaml