Upgrade di cluster Anthos su VMware

Questa pagina spiega come eseguire l'upgrade dei cluster Anthos su VMware (GKE On-Prem).

Versioni target

A partire dai cluster Anthos su VMware versione 1.3.2, puoi eseguire l'upgrade direttamente a qualsiasi versione che si trova nella stessa release secondaria o nella release secondaria successiva. Ad esempio, puoi eseguire l'upgrade da 1.3.2 a 1.3.5 o da 1.5.2 a 1.6.1.

Se la versione corrente è precedente alla 1.3.2, devi prima eseguire gli upgrade sequenziali per raggiungere la versione 1.3.2. Ad esempio, per eseguire l'upgrade da 1.3.0 a 1.3.2, devi prima eseguire l'upgrade da 1.3.0 a 1.3.1 e poi da 1.3.1 a 1.3.2.

Se esegui l'upgrade dalla versione 1.3.2 o successiva a una versione che non fa parte della prossima release secondaria, devi eseguire l'upgrade tramite una versione di ogni release secondaria tra la versione corrente e la versione desiderata. Ad esempio, se esegui l'upgrade dalla versione 1.3.2 alla versione 1.6.1, non è possibile eseguire direttamente l'upgrade. Devi prima eseguire l'upgrade dalla versione 1.3.2 alla versione 1.4.x, dove x rappresenta qualsiasi release della patch in quella release secondaria. Puoi quindi eseguire l'upgrade alla versione 1.5.x e infine alla versione 1.6.1.

Nota: se utilizzi i cluster Anthos su VMware con Anthos Service Mesh 1.7 o versioni successive, consulta questo problema noto se vuoi eseguire l'upgrade alle versioni 1.6.0-1.6.3 o 1.7.0-1.7.2.

Panoramica della procedura di upgrade

1. Scarica lo strumento gkeadm. La versione di gkeadm deve essere uguale alla versione di destinazione dell'upgrade.

2. Utilizza gkeadm per eseguire l'upgrade della workstation di amministrazione.

3. Dalla workstation di amministrazione, esegui l'upgrade del cluster di amministrazione.

4. Dalla workstation di amministrazione, esegui l'upgrade dei cluster utente.

Criterio di upgrade

Dopo aver eseguito l'upgrade del cluster di amministrazione:

• Eventuali nuovi cluster utente creati devono avere la stessa versione del cluster di amministrazione.

• Se esegui l'upgrade di un cluster utente esistente, devi eseguire l'upgrade alla stessa versione del tuo cluster di amministrazione.

• Prima di eseguire nuovamente l'upgrade del cluster di amministrazione, devi eseguire l'upgrade di tutti i cluster utente nella stessa versione del cluster di amministrazione attuale.

Individuare la configurazione e i file di informazioni

Quando hai creato la workstation di amministrazione attuale, hai compilato un file di configurazione della workstation di amministrazione generato da gkeadm create config. Il nome predefinito di questo file è admin-ws-config.yaml.

Quando hai creato la tua workstation di amministrazione attuale, gkeadm ha creato un file informativo per te. Il nome predefinito di questo file corrisponde al nome della workstation di amministrazione corrente.

Individua il file di configurazione della workstation di amministrazione e il file delle informazioni. Devi seguire i passaggi illustrati in questa guida. Se questi file si trovano nella directory attuale e hanno i loro nomi predefiniti, non li dovrai specificare quando esegui gkeadm upgrade admin-workstation. Se i file si trovano in un'altra directory o se hai modificato i nomi file, li specifichi utilizzando i flag --config e --info-file.

Upgrade della workstation di amministrazione

Per eseguire l'upgrade della workstation di amministrazione, scarica prima una nuova versione dello strumento gkeadm, quindi utilizzala per eseguire l'upgrade della configurazione della workstation di amministrazione. La versione di gkeadm deve corrispondere alla versione di destinazione dell'upgrade.

Download della lingua gkeadm in corso...

Per scaricare la versione appropriata di gkeadm, segui le istruzioni nella pagina Download.

Upgrade della workstation di amministrazione

gkeadm upgrade admin-workstation --config [AW_CONFIG_FILE] --info-file [INFO_FILE]

dove:

• [AW_CONFIG_FILE] è il percorso del file di configurazione della workstation di amministrazione. Puoi omettere questo flag se il file si trova nella directory attuale e ha il nome admin-ws-config.yaml.

• [INFO_FILE] è il percorso del file delle informazioni. Puoi omettere questo flag se il file si trova nella directory attuale. Il nome predefinito di questo file corrisponde al nome della tua workstation di amministrazione.

Il comando precedente esegue le attività seguenti:

• Esegui il backup di tutti i file nella home directory della workstation di amministrazione corrente. Sono inclusi:

  • Il tuo file di configurazione Cluster Anthos su VMware. Il nome predefinito di questo file è config.yaml.

  • I file kubeconfig per il cluster di amministrazione e i cluster utente.

  • Il certificato radice per il server vCenter. Tieni presente che questo file deve avere l'autorizzazione di lettura e scrittura del proprietario.

  • Il file della chiave JSON dell'account di servizio di accesso ai componenti. Tieni presente che questo file deve disporre dell'autorizzazione di lettura e scrittura del proprietario.

  • I file della chiave JSON per gli account di servizio Connect-Agent, connect-agent e logging-monitoring.

• Crea una nuova workstation di amministrazione e copia tutti i file di cui è stato eseguito il backup nella nuova workstation.

• Elimina la vecchia workstation di amministrazione.

Aggiornamento dell'immagine del sistema operativo del nodo e delle immagini Docker in corso...

Nella nuova workstation di amministrazione, esegui il comando seguente:

gkectl prepare --config [ADMIN_CONFIG] [FLAGS]

dove:

• [ADMIN_CONFIG] è il percorso del file di configurazione del cluster di amministrazione.

• [FLAGS] è un insieme facoltativo di flag. Ad esempio, puoi includere il flag --skip-validation-infra per saltare il controllo della tua infrastruttura vSphere.

Il comando precedente esegue le attività seguenti:

• Se necessario, copia una nuova immagine del sistema operativo nodo nel tuo ambiente vSphere e contrassegna l'immagine sistema operativo come modello.

• Se hai configurato un registro Docker privato, esegui il push di immagini Docker aggiornate al tuo registro Docker privato.

Verifica che siano disponibili indirizzi IP sufficienti

Esegui i passaggi descritti in questa sezione sulla nuova workstation di amministrazione.

Prima di eseguire l'upgrade, assicurati di avere a disposizione un numero sufficiente di indirizzi IP per i tuoi cluster.

DHCP

Quando esegui l'upgrade del cluster di amministrazione, i cluster Anthos su VMware creano un nodo temporaneo nel cluster di amministrazione. Quando esegui l'upgrade di un cluster utente, Cluster Anthos su VMware crea un nodo temporaneo nel cluster utente. Lo scopo del nodo temporaneo è garantire una disponibilità senza interruzioni. Prima di eseguire l'upgrade di un cluster, assicurati che il tuo server DHCP possa fornire un numero sufficiente di indirizzi IP per il nodo temporaneo. Per ulteriori informazioni, consulta gli indirizzi IP necessari per i cluster di amministrazione e utente.

IP statici

Quando esegui l'upgrade del cluster di amministrazione, i cluster Anthos su VMware creano un nodo temporaneo nel cluster di amministrazione. Quando esegui l'upgrade di un cluster utente, Cluster Anthos su VMware crea un nodo temporaneo nel cluster utente. Lo scopo del nodo temporaneo è garantire una disponibilità senza interruzioni. Prima di eseguire l'upgrade di un cluster, verifica di aver prenotato un numero sufficiente di indirizzi IP. Per ogni cluster, è necessario prenotare almeno un indirizzo IP in più rispetto al numero di nodi del cluster. Per saperne di più, consulta Configurazione di indirizzi IP statici.

Determina il numero di nodi nel cluster di amministrazione:

kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] get nodes

dove [ADMIN_CLUSTER_KUBECONFIG] è il percorso del file kubeconfig del cluster di amministrazione.

Quindi, visualizza gli indirizzi riservati al cluster di amministrazione:

kubectl get cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -o yaml

Nell'output, nel campo reservedAddresses, puoi vedere il numero di indirizzi IP riservati ai nodi del cluster di amministrazione. Ad esempio, il seguente output mostra che sono presenti cinque indirizzi IP riservati per i nodi del cluster di amministrazione:

...
reservedAddresses:
- gateway: 21.0.135.254
  hostname: admin-node-1
  ip: 21.0.133.41
  netmask: 21
- gateway: 21.0.135.254
  hostname: admin-node-2
  ip: 21.0.133.50
  netmask: 21
- gateway: 21.0.135.254
  hostname: admin-node-3
  ip: 21.0.133.56
  netmask: 21
- gateway: 21.0.135.254
  hostname: admin-node-4
  ip: 21.0.133.47
  netmask: 21
- gateway: 21.0.135.254
  hostname: admin-node-5
  ip: 21.0.133.44
  netmask: 21

Il numero di indirizzi IP riservati deve essere almeno uno superiore al numero di nodi nel cluster di amministrazione. In caso contrario, puoi prenotare un indirizzo aggiuntivo modificando l'oggetto Cluster.

Apri l'oggetto Cluster per la modifica:

kubectl edit cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG]

In reservedAddresses, aggiungi un blocco aggiuntivo con gateway, hostname, ip e netmask.

Per determinare il numero di nodi in un cluster utente:

kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] get nodes

dove [USER_CLUSTER_KUBECONFIG] è il percorso del file kubeconfig del cluster utente.

Per visualizzare gli indirizzi riservati a un cluster utente:

kubectl get cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
-n [USER_CLUSTER_NAME] [USER_CLUSTER_NAME] -o yaml

dove:

• [ADMIN_CLUSTER_KUBECONFIG] è il percorso del file kubeconfig del cluster di amministrazione.

• [USER_CLUSTER_NAME] è il nome del cluster utente.

Il numero di indirizzi IP riservati deve essere almeno uno superiore al numero di nodi nel cluster utente. In caso contrario, procedi nel seguente modo:

• Apri il file di blocco IP del cluster utente per eseguire la modifica.

• Aggiungi un altro indirizzo IP al blocco e chiudi il file.

• Aggiorna il cluster utente:

  gkectl update cluster --kubeconfig [ADMIN_CLUSTER_KUBECONIFG] \
    --config [USER_CLUSTER_CONFIG]
  

(Facoltativo) Disattivare le nuove funzionalità di vSphere

Una nuova versione di Cluster Anthos su VMware potrebbe includere nuove funzionalità o supporto per specifiche funzionalità VMware vSphere. A volte, l'upgrade a una versione di Cluster Anthos su VMware abilita automaticamente tali funzionalità. Scopri di più sulle nuove funzionalità nei cluster Anthos sulle note di rilascio di VMware. A volte, le nuove funzionalità vengono visualizzate nel file di configurazione dei cluster Anthos su VMware.

Se devi disabilitare una nuova funzionalità abilitata automaticamente in una nuova versione di cluster Anthos su VMware e basata sul file di configurazione, esegui i passaggi seguenti prima di eseguire l'upgrade del cluster:

1. Dalla workstation di amministrazione aggiornata, crea un nuovo file di configurazione con un nome diverso da quello in uso:

   gkectl create-config --config [CONFIG_NAME]

2. Apri il nuovo file di configurazione e prendi nota del campo della funzionalità. Chiudi il file.

3. Apri il file di configurazione corrente e aggiungi il campo della nuova funzionalità. Imposta il valore del campo su false o equivalente.

4. Salva il file di configurazione.

Controlla le Note di rilascio prima di eseguire l'upgrade dei cluster. Non puoi modificare in modo dichiarativo la configurazione di un cluster esistente dopo aver eseguito l'upgrade.

Upgrade del cluster di amministrazione

Nota: prima di iniziare questo upgrade, determina se i tuoi certificati sono aggiornati e rinnovali se necessario.

Esegui i passaggi descritti in questa sezione sulla nuova workstation di amministrazione.

Ricorda che la versione di destinazione del tuo upgrade deve essere la stessa della versione di gkeadm.

Esegui questo comando:

gkectl upgrade admin \
    --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
    --config [ADMIN_CLUSTER_CONFIG_FILE] \
    [FLAGS]

dove:

• [ADMIN_CLUSTER_KUBECONFIG] è il percorso del file kubeconfig del cluster di amministrazione.

• [ADMIN_CLUSTER_CONFIG_FILE] è il percorso del file di configurazione del cluster di amministrazione.

• [FLAGS] è un insieme facoltativo di flag. Ad esempio, puoi includere il flag --skip-validation-infra per saltare il controllo della tua infrastruttura vSphere.

Nota: questo non esegue l'upgrade di tutti i nodi del cluster di amministrazione, perché alcuni dei nodi del cluster di amministrazione sono nodi del piano di controllo per i cluster utente. Questi upgrade verranno eseguiti quando esegui l'upgrade dei cluster utente.

Nota: il comando gkectl upgrade esegue i controlli preliminari. Se i controlli preliminari non vanno a buon fine, il comando viene bloccato. Devi correggere gli errori o utilizzare il flag --skip-preflight-check-blocking con il comando per sbloccarlo.

Upgrade di un cluster utente

Esegui i passaggi descritti in questa sezione sulla nuova workstation di amministrazione.

Ricorda che la versione di destinazione del tuo upgrade deve essere la stessa della versione di gkeadm.

Gkectl

gkectl upgrade cluster \
    --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
    --config [USER_CLUSTER_CONFIG_FILE] \
    [FLAGS]

dove:

• [ADMIN_CLUSTER_KUBECONFIG] è il percorso del file kubeconfig del cluster di amministrazione.

• [USER_CLUSTER_CONFIG_FILE] è il percorso del file di configurazione del cluster utente.

• [FLAGS] è un insieme facoltativo di flag. Ad esempio, puoi includere il flag --skip-validation-infra per saltare il controllo della tua infrastruttura vSphere.

console

Puoi scegliere di registrare i tuoi cluster utente con Google Cloud Console durante l'installazione o dopo averli creati. Puoi visualizzare e accedere ai tuoi cluster Anthos registrati e ai tuoi cluster GKE in Google Cloud Console.

Quando diventa disponibile un upgrade per un cluster d'uso, viene visualizzata una notifica in Google Cloud Console. Se fai clic su questa notifica viene visualizzato un elenco delle versioni disponibili e un comando gkectl che puoi eseguire per eseguire l'upgrade del cluster:

1. Visita la pagina di Google Kubernetes Engine in Google Cloud Console.

   Visita la pagina di Google Kubernetes Engine

2. Nella colonna Notifiche per il cluster utente, fai clic su Upgrade disponibile, se disponibile.

3. Copia il comando gkectl upgrade cluster.

4. Nella workstation di amministrazione, esegui il comando gkectl upgrade cluster, dove [ADMIN_CLUSTER_KUBECONFIG] è il percorso del file kubeconfig del cluster di amministrazione, [CLUSTER_NAME] è il nome del cluster utente di cui stai eseguendo l'upgrade e [USER_CLUSTER_CONFIG_FILE] è il percorso del file di configurazione del cluster utente.

Nota: il comando gkectl upgrade esegue i controlli preliminari. Se i controlli preliminari non superano il comando, il comando viene bloccato. Devi correggere gli errori o utilizzare il flag --skip-preflight-check-blocking con il comando.

Ripresa dell'upgrade

Se un upgrade del cluster utente viene interrotto, puoi riprendere l'upgrade eseguendo lo stesso comando di upgrade con il flag --skip-validation-all:

gkectl upgrade cluster \
    --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
    --config [USER_CLUSTER_CONFIG_FILE] \
    --cluster-name [CLUSTER_NAME] \
    --skip-validation-all

Ripresa dell'upgrade del cluster di amministrazione

Non interrompere un upgrade del cluster di amministrazione. Gli upgrade dei cluster di amministrazione non sono sempre ripristinabili. Se un upgrade del cluster di amministrazione viene interrotto per qualsiasi motivo, devi contattare l'assistenza.

Creazione di un nuovo cluster utente dopo un upgrade.

Dopo aver eseguito l'upgrade della workstation di amministrazione e del cluster di amministrazione, tutti i nuovi cluster utente creati devono avere la stessa versione della versione di destinazione di upgrade.

Regole DRS VMware

I cluster Anthos su VMware creano automaticamente le regole anti-affinità VMware Distributed Resource Scheduler(DRS) per i nodi del cluster utente, determinando la loro diffusione in almeno tre host fisici nel tuo data center. Questa funzionalità viene abilitata automaticamente per i cluster nuovi ed esistenti.

Prima di eseguire l'upgrade, assicurati che il tuo ambiente vSphere soddisfi le seguenti condizioni:

• VMware DRS è abilitato. VMware DRS richiede la versione di licenza vSphere Enterprise Plus. Per informazioni su come abilitare gli DRS, consulta Abilitare DRS VMware in un cluster
• L'account utente vSphere fornito nel campo vcenter dispone dell'autorizzazione Host.Inventory.EditCluster.
• Sono disponibili almeno tre host fisici.

Se il tuo ambiente vSphere non soddisfa le condizioni precedenti, puoi eseguire l'upgrade, ma per eseguire l'upgrade di un cluster utente da 1.3.x a 1.4.x devi disabilitare i gruppi anti-affinità. Per ulteriori informazioni, consulta le note di rilascio per la versione 1.4.0.

Inattività

Informazioni sul tempo di inattività durante gli upgrade

Risorsa	Descrizione
Cluster di amministrazione	Quando un cluster di amministrazione è inattivo, i piani di controllo e i carichi di lavoro dei cluster utente dei cluster utente continuano a essere eseguiti, a meno che non siano stati interessati da un errore che ha causato il tempo di inattività.
Piano di controllo del cluster utente	In genere, non sono previsti tempi di inattività visibili per i piani di controllo del cluster utente. Tuttavia, le connessioni a lunga durata al server API Kubernetes potrebbero interrompersi e dovrebbero essere ripristinate. In questi casi, il chiamante dell'API deve riprovare finché non stabilisce una connessione. Nel peggiore dei casi, può essere necessario fino a un minuto di tempo di inattività durante un upgrade. Nota: se i nodi del cluster utente non sono in grado di raggiungere il piano di controllo dell'utente durante l'upgrade, i nuovi carichi di lavoro non vengono pianificati nel cluster. I carichi di lavoro esistenti non sono interessati.
Nodi del cluster utente	Se un upgrade richiede una modifica ai nodi del cluster utente, i cluster Anthos su VMware ricreano i nodi in modo continuativo e ripianificano i pod in esecuzione su questi nodi. Puoi evitare l'impatto sui tuoi carichi di lavoro configurando PodDisruptionBudget e regole di affinità appropriati.

Problemi noti

Vedi Problemi noti.

Risolvere i problemi

Consulta Risoluzione dei problemi di creazione e upgrade del cluster