Questa pagina è stata tradotta dall'API Cloud Translation.

Esegui la 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

Questi sono i passaggi principali di 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 (Tipo) e assicurati che l'attuale cluster di amministrazione non ad alta disponibilità sia in stato integro.
- Creare 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à.
- Riconcilia il 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 si verifica un tempo di inattività per il piano di controllo del cluster di amministrazione. (Il tempo di inattività è inferiore a 18 minuti in base al nostro test, ma la durata effettiva dipende dai singoli ambienti di infrastruttura).
I requisiti per i cluster di amministrazione ad alta disponibilità continuano a essere validi per la migrazione da non ad alta disponibilità ad alta disponibilità. Ciò significa che se utilizzi il bilanciatore del carico di Seesaw per un cluster di amministrazione non ad alta disponibilità, devi prima eseguire la migrazione a MetalLB e poi a un cluster di amministrazione ad alta disponibilità. Questo perché un cluster di amministrazione ad alta disponibilità non supporta Seesaw.
Al termine della migrazione, ci saranno le risorse rimaste (ad es. la VM master dell'amministratore non ad alta disponibilità) che abbiamo conservato intenzionalmente per 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 del pod del piano di controllo (kube-apiserver, kube-etcd ecc.)	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 di 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 di 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 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. Il motivo è che, per un cluster di amministrazione ad alta disponibilità, i percorsi dei tre dischi 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 descritto in questa sezione. In caso contrario, salta questa sezione.

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

(controlPlaneVIP:443 precedente) -> (NEW_NODE_IP_ADDRESS:vecchio controlPlaneNodePort)

In questo modo, il VIP del piano di controllo precedente 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 lo stato di avanzamento della migrazione.

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

Se necessario, pulisci manualmente le risorse rimaste

Durante la migrazione, gkectl non elimina la VM del piano di controllo del cluster di amministrazione. Piuttosto, arresta la VM anziché 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 del piano di controllo precedente e le risorse correlate:

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

Di seguito sono riportati i comandi govc se è preferibile 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