Upgrade di Cluster Anthos su VMware

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

Panoramica della procedura di upgrade

Puoi eseguire l'upgrade direttamente a qualsiasi versione presente nella stessa release secondaria o nella release secondaria successiva. Ad esempio, puoi eseguire l'upgrade da 1.13.0 a 1.13.1 oppure da 1.12.1 a 1.13.0.

Se stai eseguendo l'upgrade a una versione che non fa parte della release secondaria successiva, devi eseguire l'upgrade tramite una versione di ogni release secondaria tra la versione attuale e quella desiderata. Ad esempio, se esegui l'upgrade dalla versione 1.11.2 alla versione 1.13.0, non è possibile eseguire l'upgrade direttamente. Devi prima eseguire l'upgrade dalla versione 1.11.2 alla versione 1.12.x, quindi eseguire l'upgrade alla versione 1.13.0.

Questo argomento illustra come eseguire l'upgrade dalla versione 1.12.x alla versione 1.13.y.

Consulta le best practice per l'upgrade del cluster prima di iniziare il processo di upgrade.

Ecco il flusso di lavoro generale per l'upgrade.

Esegui l'upgrade della workstation di amministrazione alla versione di destinazione dell'upgrade.
Dalla workstation di amministrazione, esegui l'upgrade dei cluster utente.
Dopo aver eseguito l'upgrade di tutti i cluster utente, potrai eseguire l'upgrade del cluster dalla Console di amministrazione. Questo passaggio è facoltativo, a meno che non siano richieste le funzionalità disponibili nell'upgrade.

Nota: se esegui l'upgrade alla versione 1.13.0 o successive, puoi eseguire l'upgrade del cluster di amministrazione solo dopo aver registrato il cluster. Per saperne di più, vedi Registrare un cluster di amministrazione.

Upgrade di cluster utente asincrono

Per un upgrade del cluster utente, esistono due due varianti del comando gkectl upgrade cluster:

Asincrona (consigliata)
Sincrona

Con la variante asincrona, il comando avvia l'upgrade e poi viene completato. Non è necessario controllare l'output del comando per l'intera durata dell'upgrade. Puoi invece controllare periodicamente l'avanzamento dell'upgrade eseguendo gkectl list cluster e gkectl describe cluster.

Per utilizzare la variante asincrona, includi il flag --async nel comando. Per maggiori dettagli, consulta Eseguire l'upgrade di un cluster utente.

Preparare l'upgrade

Prima di creare la workstation di amministrazione, 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.

La workstation ha anche un file informativo. Il nome predefinito di questo file corrisponde al nome della tua workstation di amministrazione.

Individua il file di configurazione della workstation di amministrazione e il file delle informazioni. Ti serviranno per eseguire la procedura di upgrade. Se questi file si trovano nella directory attuale e hanno i nomi predefiniti, non dovrai specificarli quando esegui i comandi di upgrade. Se questi file si trovano in un'altra directory o se hai cambiato i nomi dei file, puoi specificarli utilizzando i flag --config e --info-file.

Se il file delle informazioni di output non è presente, puoi ricrearlo. Vedi Ricreare un file informativo se non è presente.

Esegui l'upgrade della workstation di amministrazione

Scarica gkeadm:
```
gkeadm upgrade gkeadm --target-version TARGET_VERSION
```
Sostituisci TARGET_VERSION con la versione di destinazione dell'upgrade.
Esegui l'upgrade della workstation di amministrazione:
```
gkeadm upgrade admin-workstation --config AW_CONFIG_FILE --info-file INFO_FILE
```
Sostituisci quanto segue:
- 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 ed è denominato 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:

Esegue il backup di tutti i file nella home directory della workstation di amministrazione corrente. Queste includono:
- Il file di configurazione del tuo cluster di amministrazione. Il nome predefinito è admin-cluster.yaml.
- Il file di configurazione del cluster utente. Il nome predefinito è user-cluster.yaml.
- I file kubeconfig per il cluster di amministrazione e per 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 del tuo account di servizio di accesso ai componenti. Tieni presente che questo file deve avere l'autorizzazione di lettura e scrittura del proprietario.
- I file della chiave JSON dei tuoi account di servizio connect-register e logging.
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.

Verifica che siano disponibili indirizzi IP sufficienti

Prima di eseguire l'upgrade dei cluster, assicurati di aver assegnato un numero sufficiente di indirizzi IP. Se necessario, puoi allocare ulteriori indirizzi IP. Consulta Gestire gli indirizzi IP del nodo per determinare quanti indirizzi IP sono necessari.

Upgrade di un cluster utente

Riga di comando

Esistono due tipi di upgrade dei cluster utente che puoi eseguire dalla riga di comando:

Asincrona
Sincrona

Upgrade asincrono

Esegui gkectl prepare per importare immagini sistema operativo in vSphere:

gkectl prepare \
  --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Nel file di configurazione del cluster utente, imposta gkeOnPremVersion sulla versione di destinazione dell'upgrade.

Sulla workstation di amministrazione, avvia un upgrade asincrono:

gkectl upgrade cluster \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --config USER_CLUSTER_CONFIG \
  --async

Il comando precedente viene completato e puoi continuare a utilizzare il cluster utente mentre è in corso l'upgrade.

Per visualizzare lo stato dell'upgrade:

gkectl list clusters --kubeconfig ADMIN_CLUSTER_KUBECONFIG

L'output mostra un valore per il cluster STATE. Se è ancora in corso l'upgrade del cluster, il valore di STATE è UPGRADING. Ad esempio:

NAMESPACE             NAME    READY   STATE       AGE   VERSION
my-uc-gkeonprem-mgmt  my-uc   False   UPGRADING   9h    1.13.0-gke.1

I valori possibili per STATE sono PROVISIONING, UPGRADING, DELETING, UPDATING, RUNNING, RECONCILING, ERROR e UNKNOWN.

Per maggiori dettagli sull'avanzamento dell'upgrade e sugli eventi del cluster:

gkectl describe cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --cluster USER_CLUSTER_NAME -v 5

L'output mostra la risorsa personalizzata OnPremUserCluster per il cluster utente specificato, che include stato, condizioni ed eventi del cluster.

Registriamo gli eventi per l'inizio e la fine di ogni fase critica dell'upgrade, tra cui:

Upgrade del piano di controllo
Upgrade nodo master
Upgrade componenti aggiuntivi
Upgrade dei pool di nodi

Output di esempio:

Events:
Type    Reason                      Age    From                            Message
----     ------                     ----   ----                            -------
Normal  NodePoolsUpgradeStarted     22m    onprem-user-cluster-controller  Creating or updating node pools: pool-2: Creating or updating node pool
Normal  AddonsUpgradeStarted        22m    onprem-user-cluster-controller  Creating or updating addon workloads
Normal  ControlPlaneUpgradeStarted  25m    onprem-user-cluster-controller  Creating or updating cluster control plane workloads: deploying user-kube-apiserver-base, ...: 14/15 pods are ready
Normal  ControlPlaneUpgradeFinished 23m    onprem-user-cluster-controller  Control plane is running

Al termine dell'upgrade, gkectl list cluster mostra un STATUS di RUNNING:

NAMESPACE             NAME    READY   STATE     AGE     VERSION
my-uc-gkeonprem-mgmt  my-uc   True    RUNNING   9h      1.13.0-gke.1

Inoltre, una volta completato l'upgrade, gkectl describe cluster mostra un campo LastGKEOnPremVersion in Status. Ad esempio:

Status:
Cluster State:  RUNNING
LastGKEOnOremVersion:  1.12.0-gke.0

Risolvere i problemi relativi all'upgrade asincrono

Per un upgrade asincrono, la durata del timeout si basa sul numero di nodi nel cluster. Se l'upgrade richiede più tempo della durata di timeout, lo stato del cluster viene modificato da UPGRADING a ERROR, con un evento che indica che l'operazione di upgrade è scaduta. Tieni presente che lo stato ERROR indica che l'upgrade sta richiedendo più tempo del previsto, ma non è stato terminato. Il controller continua la riconciliazione e continua a riprovare.

Di solito un timeout è il risultato di un deadlock causato da un PodDisruptionBudget (PDB). In questo caso, i pod non possono essere rimossi dai vecchi nodi e i nodi precedenti non possono essere svuotati. Se l'eliminazione del pod dura più di 10 minuti, scriviamo un evento nell'oggetto OnPremUserCluster. Puoi acquisire l'evento eseguendo gkectl describe cluster. Puoi quindi regolare il PDB per consentire lo svuotamento del nodo. In seguito, l'upgrade potrà essere completato e, in un secondo momento, completato.

Evento di esempio:

Warning  PodEvictionTooLong  96s (x2 over 4m7s)  onprem-user-cluster-controller
Waiting too long(>10m0.00000003s) for (kube-system/coredns-856d6dbfdf-dl6nz) eviction.

Inoltre, quando un upgrade viene bloccato o non riesce, puoi eseguire gkectl diagnose per controllare i problemi comuni del cluster. In base al risultato, puoi decidere se eseguire una correzione manuale o contattare il team di assistenza di Anthos per ulteriore assistenza.

Upgrade sincrono

Il comando gkectl upgrade esegue controlli preflight. Se i controlli preflight non sono riusciti, il comando viene bloccato. Devi correggere gli errori o utilizzare il flag --skip-preflight-check-blocking. Dovresti saltare i controlli preflight solo se hai la certezza che non ci siano errori critici.

Procedi nel seguente modo sulla tua workstation di amministrazione:

Esegui gkectl prepare per importare immagini sistema operativo in vSphere:

gkectl prepare \
 --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz \
 --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Nel file di configurazione del cluster utente, imposta gkeOnPremVersion sulla versione di destinazione dell'upgrade.

Esegui l'upgrade del cluster:

gkectl upgrade cluster \
 --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
 --config USER_CLUSTER_CONFIG_FILE

Se esegui l'upgrade alla versione 1.14.0 o successive, viene generato un nuovo file kubeconfig per il cluster utente che sovrascrive qualsiasi file esistente. Per visualizzare i dettagli del cluster nel file, esegui questo comando:

kubectl config view --kubeconfig USER_CLUSTER_KUBECONFIG

console Google Cloud

Nella workstation di amministrazione, esegui il comando seguente:
```
gkectl prepare \
    --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --upgrade-platform
```
Sostituisci quanto segue:
- ADMIN_CLUSTER_KUBECONFIG è il percorso del file kubeconfig del cluster di amministrazione.
Questo comando esegue l'upgrade dei criteri del controller del cluster utente e del controllo dell'accesso basato sui ruoli (RBAC) che consentono alla console di Google Cloud di gestire il cluster utente.
Nella console Google Cloud, vai alla pagina Cluster Anthos.

Vai a Cluster Anthos di Anthos
Seleziona il progetto Cloud in cui si trova il cluster utente.
Nell'elenco dei cluster, fai clic sul cluster di cui vuoi eseguire l'upgrade.
Se il Tipo è vm Anthos (VMware) nel riquadro Dettagli, esegui questi passaggi per eseguire l'upgrade del cluster utilizzando la console Google Cloud:
1. Nel riquadro Dettagli, fai clic su Altri dettagli.
2. Nella sezione Nozioni di base sul cluster, fai clic su Esegui l'upgrade.
3. Nell'elenco Versione di Anthos clusters on VMware, seleziona la versione a cui vuoi eseguire l'upgrade.
4. Fai clic su Esegui upgrade.
Se il Tipo è esterno, significa che il cluster è stato creato utilizzando gkectl. In questo caso, segui i passaggi nella scheda Riga di comando per eseguire l'upgrade del cluster.

Riprendi un upgrade

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

gkectl upgrade cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE \
    --skip-validation-all

Esegui l'upgrade del cluster di amministrazione

Prima di iniziare:

Determina se i certificati sono aggiornati e rinnovali se necessario.
Se esegui l'upgrade alla versione 1.13 o successive, devi prima registrare il cluster di amministrazione compilando la sezione gkeConnect nel file di configurazione del cluster di amministrazione. Esegui il comando di aggiornamento con le modifiche al file di configurazione.

Esegui i passaggi descritti in questa sezione sulla nuova workstation di amministrazione. Assicurati che gkectl e i cluster siano la versione appropriata per un upgrade e di aver scaricato il pacchetto appropriato.

Assicurati che il campo bundlepath nel file di configurazione del cluster di amministrazione corrisponda al percorso del bundle a cui vuoi eseguire l'upgrade.

Se apporti altre modifiche ai campi del file di configurazione del cluster di amministrazione, queste verranno ignorate durante l'upgrade. Per rendere effettive queste modifiche, devi prima eseguire l'upgrade del cluster, quindi eseguire un comando di aggiornamento con le modifiche al file di configurazione per apportare altre modifiche al cluster.
Esegui questo comando:
```
gkectl upgrade admin \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config ADMIN_CLUSTER_CONFIG_FILE \
    FLAGS
```
Sostituisci quanto segue:
- ADMIN_CLUSTER_KUBECONFIG: il file kubeconfig del cluster di amministrazione.
- ADMIN_CLUSTER_CONFIG_FILE: il file di configurazione del cluster di amministrazione Cluster Anthos su VMware sulla tua nuova workstation 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.

Se stai eseguendo l'upgrade alla versione 1.14.0 o successive, viene generato un nuovo file kubeconfig per il cluster di amministrazione che sovrascrive qualsiasi file esistente. Per visualizzare i dettagli del cluster nel file, esegui questo comando:

  kubectl config view --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Se hai scaricato un bundle completo e hai eseguito correttamente i comandi gkectl prepare e gkectl upgrade admin, dovresti eliminare l'intero bundle per risparmiare spazio su disco nella workstation di amministrazione. Utilizza questo comando:

rm /var/lib/gke/bundles/gke-onprem-vsphere-${TARGET_VERSION}-full.tgz

Ripresa di un upgrade del cluster di amministrazione

Se un upgrade del cluster di amministrazione viene interrotto o non riesce, l'upgrade può essere ripristinato se il checkpoint del cluster di amministrazione contiene lo stato necessario per ripristinare lo stato precedente l'interruzione.

Avviso: non riparare il master amministratore con gkectl repair admin-master dopo un tentativo di upgrade non riuscito. Questo provocherà lo stato non valido del cluster di amministrazione.

Segui questi passaggi:

Controlla se il piano di controllo dell'amministratore è integro prima di iniziare il tentativo di upgrade iniziale. Consulta Diagnosticare i problemi del cluster. Come discusso in questo argomento, esegui il comando gkectl diagnose cluster per il cluster di amministrazione.
Se il piano di controllo dell'amministratore non è integro prima del tentativo di upgrade iniziale, ripara il piano di controllo dell'amministratore con il comando gkectl repair admin-master.
Quando esegui di nuovo il comando di upgrade dopo che un upgrade è stato interrotto o non è andato a buon fine, utilizza lo stesso bundle e la stessa versione di destinazione specificati nel precedente tentativo di upgrade.

Quando esegui nuovamente il comando di upgrade, l'upgrade ripristinato ricrea lo stato del cluster di amministrazione dal checkpoint ed esegue nuovamente l'intero upgrade. A partire dalla 1.12.0, se il piano di controllo dell'amministratore è in stato non integro, il processo di upgrade verrà eseguito direttamente nella versione di destinazione senza tentare di ripristinare il cluster di amministrazione nella versione di origine prima di eseguire l'upgrade.

L'upgrade riprenderà dal punto in cui non è riuscito o è stato chiuso se il checkpoint del cluster di amministrazione è disponibile. Se il checkpoint non è disponibile, l'upgrade farà affidamento sul piano di controllo dell'amministratore, pertanto il piano di controllo dell'amministratore deve essere integro per procedere con l'upgrade. Dopo aver eseguito correttamente l'upgrade, il checkpoint viene rigenerato.

Se gkectl si arresta in modo imprevisto durante un upgrade del cluster di amministrazione, il tipo di cluster non viene pulito. Prima di eseguire di nuovo il comando di upgrade, ripristina l'upgrade del cluster di tipo:

docker stop gkectl-control-plane && docker rm gkectl-control-plane

Dopo aver eliminato il cluster di tipo, esegui nuovamente il comando di upgrade.

Eseguire il rollback di una workstation di amministrazione dopo un upgrade

Puoi eseguire il rollback della workstation di amministrazione alla versione utilizzata prima dell'upgrade.

Durante l'upgrade, gkeadm registra la versione precedente all'upgrade nel file delle informazioni di output. Durante il rollback, gkeadm utilizza la versione indicata per scaricare il file precedente.

Per eseguire il rollback della tua workstation di amministrazione alla versione precedente:

gkeadm rollback admin-workstation --config=AW_CONFIG_FILE

Puoi omettere --config=AW_CONFIG_FILE se il file di configurazione della workstation di amministrazione è admin-ws-config.yaml predefinito. In caso contrario, sostituisci AW_CONFIG_FILE con il percorso del file di configurazione della workstation di amministrazione.

Il comando di rollback esegue questi passaggi:

Scarica la versione di rollback di gkeadm.
Esegue il backup della home directory della workstation di amministrazione corrente.
Crea una nuova workstation di amministrazione utilizzando la versione di rollback di gkeadm.
Elimina la workstation di amministrazione originale.

Installa il bundle con una versione diversa per eseguire l'upgrade

Se esegui l'upgrade della workstation, verrà installato un bundle con una versione corrispondente per eseguire l'upgrade dei cluster. Se vuoi avere una versione diversa, segui questi passaggi per installare il bundle per TARGET_VERSION, ossia la versione a cui vuoi eseguire l'upgrade.

Per controllare le versioni attuali di gkectl e cluster, esegui questo comando. Utilizza il flag --details/-d per informazioni più dettagliate.
```
gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG --details
```
L'output fornisce informazioni sulle versioni del cluster.
Cerca i problemi elencati di seguito in base all'output e correggili se necessario.
- Se la versione attuale del cluster di amministrazione è superiore a una versione secondaria rispetto a TARGET_VERSION, esegui l'upgrade di tutti i cluster in modo che sia una versione secondaria inferiore a quella di TARGET_VERSION.
- Se la versione di gkectl è precedente alla 1.11 e vuoi eseguire l'upgrade alla versione 1.12.x, dovrai eseguire più upgrade. Esegui l'upgrade di una versione secondaria alla volta, finché non arrivi alla versione 1.11.x, quindi segui le istruzioni riportate in questo argomento.
- Se la versione di gkectl è inferiore a quella di TARGET_VERSION, esegui l'upgrade della workstation di amministrazione alla versione TARGET_VERSION.
Dopo aver stabilito che le versioni di gkectl e del cluster sono appropriate per un upgrade, scarica il bundle.

Controlla se il tarball del bundle esiste già sulla workstation di amministrazione.
```
stat /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz
```
Se il bundle non si trova nella workstation di amministrazione, scaricalo.
```
gsutil cp gs://gke-on-prem-release/gke-onprem-bundle/TARGET_VERSION/gke-onprem-vsphere-TARGET_VERSION.tgz /var/lib/gke/bundles/
```
Installa il cofanetto.
```
gkectl prepare --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz --kubeconfig ADMIN_CLUSTER_KUBECONFIG
```
Sostituisci ADMIN_CLUSTER_KUBECONFIG con il percorso del file kubeconfig. Puoi omettere questo flag se il file si trova nella directory attuale ed è denominato kubeconfig.

Nota: per impostazione predefinita, viene scaricato il bundle standard, anziché l'intero pacchetto. Il bundle completo contiene tutte le immagini container e VM, mentre il bundle normale scarica le immagini container e VM da Google Cloud Platform nella workstation di amministrazione durante l'installazione. Per utilizzare il pacchetto completo, il percorso del pacchetto nel comando di installazione è gke-onprem-vsphere-TARGET_VERSION-full.tgz.
Elenca le versioni disponibili del cluster e assicurati che la versione target sia inclusa nelle versioni disponibili del cluster utente.
```
gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG --details
```

Ora puoi creare un cluster utente nella versione di destinazione o eseguire l'upgrade di un cluster utente alla versione di destinazione.

Risoluzione dei problemi relativi al processo di upgrade

Se riscontri un problema durante la procedura di upgrade consigliata, segui questi consigli per risolverli. Questi suggerimenti presuppongono che tu abbia iniziato la configurazione della versione 1.11.x e che tu stia procedendo alla procedura di upgrade consigliata.

Vedi anche Risoluzione dei problemi di creazione e upgrade dei cluster

Risoluzione dei problemi di upgrade di un cluster utente

Supponiamo di riscontrare un problema con la versione di upgrade durante l'upgrade di un cluster utente. Stabilite dall'Assistenza Google che il problema verrà risolto in una futura release della patch. Puoi procedere come segue:

Continua a utilizzare la versione attuale per la versione di produzione.
Testare la release della patch in un cluster non di produzione quando viene rilasciata.
Esegui l'upgrade dei cluster utente di produzione alla versione di release della patch quando hai certezza.
Esegui l'upgrade del cluster di amministrazione alla versione di rilascio della patch.

Risoluzione dei problemi di upgrade di un cluster di amministrazione

Se riscontri un problema durante l'upgrade del cluster di amministrazione, devi contattare l'Assistenza Google per risolverlo.

Nel frattempo, con il nuovo flusso di upgrade, puoi comunque trarre vantaggio dalle nuove funzionalità del cluster utente senza essere bloccato dall'upgrade del cluster di amministrazione, che consente di ridurre la frequenza di upgrade del cluster di amministrazione se lo desideri. La procedura di upgrade può procedere come segue:

Esegui l'upgrade dei cluster utente di produzione a 1.12.x.
Mantieni la versione precedente del cluster di amministrazione e continua a ricevere patch di sicurezza.
Esegui l'upgrade del cluster di amministrazione da 1.11.x a 1.12.x in un ambiente di test e segnala eventuali problemi.
Se il problema viene risolto da una release di patch 1.12.x, puoi scegliere di eseguire l'upgrade del cluster di amministrazione di produzione a questa release di patch, se preferisci.

Problemi noti relativi alle versioni recenti

I seguenti problemi noti potrebbero influire sugli upgrade se esegui l'upgrade dalla versione 1.7 o successiva.

Vedi anche: Problemi noti

L'upgrade della workstation di amministrazione potrebbe non riuscire se il disco dati è quasi esaurito

Se esegui l'upgrade della workstation di amministrazione con il comando gkectl upgrade admin-workstation, l'upgrade potrebbe non riuscire se il disco dati è quasi esaurito, perché il sistema tenta di eseguire il backup locale della workstation di amministrazione attuale durante l'upgrade a una nuova workstation di amministrazione. Se non riesci a liberare spazio sufficiente sul disco dati, utilizza il comando gkectl upgrade admin-workstation con il flag aggiuntivo --backup-to-local=false per evitare di eseguire un backup locale della workstation di amministrazione corrente.

Interruzione dei carichi di lavoro con PodDisruptionBudget

Attualmente, l'upgrade dei cluster può causare interruzioni o tempi di inattività per carichi di lavoro che utilizzano PodDisruptionBudget (PDB).

I nodi non riescono a completare il processo di upgrade

Se hai configurato PodDisruptionBudget oggetti che non sono in grado di consentire ulteriori interruzioni, gli upgrade dei nodi potrebbero non riuscire a eseguire l'upgrade alla versione del piano di controllo dopo ripetuti tentativi. Per evitare questo errore, ti consigliamo di fare lo scale up di Deployment o HorizontalPodAutoscaler per consentire lo svuotamento del nodo rispettando la configurazione PodDisruptionBudget.

Per vedere tutti gli oggetti PodDisruptionBudget che non consentono interruzioni:

kubectl get poddisruptionbudget --all-namespaces -o jsonpath='{range .items[?(@.status.disruptionsAllowed==0)]}{.metadata.name}/{.metadata.namespace}{"\n"}{end}'

Appendice

Informazioni sulle regole DRS VMware abilitate nella versione 1.1.0-gke.6

A partire dalla versione 1.1.0-gke.6, i cluster Anthos su VMware creano automaticamente regole anti-affinità VMware Distributed Resource Scheduler (DRS) per i nodi del cluster utente, causando la loro distribuzione su almeno tre host fisici nel tuo data center. A partire dalla versione 1.1.0-gke.6, questa funzionalità viene attivata automaticamente per i nuovi cluster e per i cluster esistenti.

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

DRS VMware è abilitato. VMware DRS richiede l'edizione della licenza vSphere Enterprise Plus. Per informazioni su come abilitare DRS in un cluster, consulta Abilitare DRS VMware in un cluster
Il nome utente vSphere fornito nel tuo file di configurazione delle credenziali ha l'autorizzazione Host.Inventory.EditCluster.
Sono disponibili almeno tre host fisici.

Se il tuo ambiente vSphere non soddisfa le condizioni precedenti, puoi comunque 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 questo problema noto nelle note di rilascio di Cluster Anthos su VMware.

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 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 aspettarti tempi di inattività significativi per i piani di controllo del cluster utente. Tuttavia, le connessioni a lunga esecuzione al server API Kubernetes potrebbero interrompersi e dover essere ristabilite. 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 inattività durante l'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 per il cluster. I carichi di lavoro esistenti non sono interessati.
Nodi cluster utente	Se un upgrade richiede una modifica ai nodi del cluster utente, Cluster Anthos su VMware ricrea i nodi in modo continuativo e ripianifica i pod in esecuzione su questi nodi. Puoi prevenire l'impatto sui tuoi carichi di lavoro configurando PodDisruptionBudget e regole di affinità appropriati.

Ricrea un file di informazioni, se mancante

Se il file delle informazioni di output per la workstation di amministrazione non è presente, devi ricrearlo per poter continuare l'upgrade. Questo file è stato creato durante la creazione iniziale della workstation e, se hai eseguito un upgrade in seguito, è stato aggiornato con nuove informazioni.

Il file delle informazioni di output ha il seguente formato:

Admin workstation version: GKEADM_VERSION
Created using gkeadm version: GKEADM_VERSION
VM name: ADMIN_WS_NAME
IP: ADMIN_WS_IP
SSH key used: FULL_PATH_TO_ADMIN_WS_SSH_KEY
To access your admin workstation:
ssh -i FULL-PATH-TO-ADMIN-WS-SSH-KEY ubuntu@ADMIN-WS-IP

Di seguito è riportato un file con informazioni di output di esempio:

Admin workstation version: v1.10.3-gke.49
Created using gkeadm version: v1.10.3-gke.49
VM name: admin-ws-janedoe
IP: 172.16.91.21
SSH key used: /usr/local/google/home/janedoe/.ssh/gke-admin-workstation
Upgraded from (rollback version): v1.10.0-gke.194
To access your admin workstation:
ssh -i /usr/local/google/home/janedoe/.ssh/gke-admin-workstation ubuntu@172.16.91.21

Crea il file in un editor, sostituendo i parametri appropriati. Salva il file con un nome file che corrisponda al nome della VM nella directory da cui viene eseguito gkeadm. Ad esempio, se il nome della VM è admin-ws-janedoe, salva il file come admin-ws-janedoe.