Upgrade di un cluster

Questo documento spiega come eseguire l'upgrade dei cluster in Google Distributed Cloud (solo software) per VMware. Questo documento fornisce i passaggi per l'upgrade della workstation di amministrazione, dei cluster utente e dei cluster di amministrazione. I passaggi per l'upgrade di un cluster utente mostrano come eseguire l'upgrade del piano di controllo e di tutti i pool di nodi. Se vuoi eseguire l'upgrade del control plane e dei node pool del cluster utente separatamente, consulta Eseguire l'upgrade dei node pool.

Questa pagina è rivolta agli amministratori IT e agli operatori che gestiscono il ciclo di vita dell'infrastruttura tecnologica sottostante. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti di Google Cloud , consulta la pagina Ruoli e attività comuni degli utenti di GKE Enterprise.

Prima di procedere, ti consigliamo di consultare la seguente documentazione:

• Panoramica dell'upgrade
  Questo documento descrive, tra le altre cose, la distorsione della versione supportata e le regole di versione per gli upgrade, che sono cambiate per la versione 1.28 e successive.

• Best practice per l'upgrade
  Questo documento fornisce elenchi di controllo e best practice per l'upgrade dei cluster.

Differenze tra i cluster avanzati

Quando sono abilitati i cluster avanzati, ci sono alcune differenze con gli upgrade, in particolare nell'anteprima dei cluster avanzati nella versione 1.31. Per visualizzare le differenze dell'upgrade, cerca la parola advanced in questo documento. Per una tabella di tutte le differenze, consulta Differenze durante l'esecuzione di cluster avanzati.

Requisiti

Questa sezione fornisce informazioni sui requisiti relativi alla versione e sui requisiti per l'utilizzo dei client API GKE On-Prem (la console Google Cloud , Google Cloud CLI e Terraform) per gli upgrade.

Regole di versione

Le regole per gli upgrade dipendono dalla versione secondaria del cluster.

• Per le versioni 1.30 e precedenti, la versione secondaria del cluster utente deve essere maggiore o uguale a quella del cluster di amministrazione. La versione patch non è importante. Ad esempio, se un cluster utente ha la versione 1.30.1, il cluster di amministrazione può essere aggiornato a una versione patch superiore, ad esempio 1.30.3.

• Per le versioni 1.31 e successive, la versione del cluster di amministrazione, inclusa la versione della patch, deve essere maggiore o uguale alla versione del cluster utente. Ad esempio, se un cluster di amministrazione ha la versione 1.31.1, la versione più recente a cui è possibile eseguire l'upgrade del cluster utente è la 1.31.1.

Quando vuoi eseguire l'upgrade dei cluster alla versione 1.31, devi prima portare tutti i cluster alla versione 1.30. Dopo che tutti i cluster sono alla versione 1.30, esegui l'upgrade del cluster di amministrazione alla versione 1.31. Dopodiché, puoi eseguire l'upgrade dei cluster utente alla stessa versione patch 1.31 del cluster di amministrazione.

Regole di versione per gkectl

La versione di gkectl che puoi utilizzare per l'upgrade dipende dalla versione del cluster di destinazione (ovvero la versione del cluster a cui stai eseguendo l'upgrade). In genere, utilizzi la stessa versione di gkectl della versione di destinazione del cluster. Durante l'upgrade vengono applicate le seguenti regole:

• La versione gkectl non può essere una versione secondaria precedente a quella del cluster secondario di destinazione. Ad esempio, se esegui l'upgrade di un cluster 1.29 alla versione 1.30, non puoi utilizzare gkectl 1.29 perché è inferiore alla versione del cluster di destinazione. Le versioni patch non sono importanti. Ad esempio, puoi utilizzare gkectl la versione 1.29.0-gke.1456 per eseguire l'upgrade a una versione patch superiore, ad esempio 1.29.1000-gke.94.

• La versione di gkectl non può essere superiore di più di due versioni secondarie rispetto alla versione attuale del cluster. Ad esempio, se esegui l'upgrade di un cluster 1.28 alla versione 1.29, la versione di gkectl può essere 1.29 o 1.30. Tuttavia, non puoi utilizzare la versione 1.31 perché è tre versioni secondarie successive alla versione del cluster.gkectl

Se necessario, consulta la sezione Scaricare gkectl per ottenere una versione supportata di gkectl.

Esamina le regole firewall

Nella versione 1.29 e successive, i controlli preliminari lato server sono abilitati per impostazione predefinita. I controlli preliminari lato server richiedono regole firewall aggiuntive. In Regole firewall per i cluster di amministrazione, cerca "Controlli preliminari" e assicurati che tutte le regole firewall richieste siano configurate.

Con i controlli preliminari lato server, quando esegui l'upgrade di un cluster utente utilizzando gkectl, i controlli preliminari vengono eseguiti sul cluster di amministrazione anziché localmente sulla workstation di amministrazione. I controlli preflight lato server vengono eseguiti anche sul cluster di amministrazione quando utilizzi la console Google Cloud , Google Cloud CLI o Terraform per eseguire l'upgrade di un cluster.

Quando esegui l'upgrade di un cluster di amministrazione, Google Distributed Cloud esegue il deployment di un cluster Kubernetes in Docker (kind) per ospitare temporaneamente i controller Kubernetes necessari per l'upgrade del cluster di amministrazione. Questo cluster temporaneo è chiamato cluster di bootstrap. I controlli preflight lato server vengono eseguiti sul cluster di bootstrap quando esegui l'upgrade di un cluster di amministrazione.

Abilita Dataplane V2

A partire dalla versione 1.31, Dataplane V2 deve essere abilitato su tutti i cluster utente. Prima di eseguire l'upgrade di un cluster utente alla versione 1.31, esegui i seguenti passaggi. Se hai dubbi in merito alla rimozione temporanea della specifica NetworkPolicy, contatta l'Assistenza Google.

Imposta enableDataplaneV2 su true nel file di configurazione del cluster utente.

Se il cluster utilizza un NetworkPolicy, rimuovi temporaneamente la relativa specifica dal cluster nel seguente modo:

1. Controlla se al tuo cluster è applicato un NetworkPolicy non di sistema:

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get networkpolicy -A -o wide | grep -v kube-system
   

2. Se l'output del passaggio precedente non era vuoto, salva ogni specifica NetworkPolicy in un file in modo da poterla riapplicare dopo l'upgrade del cluster.

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get networkpolicy NETWORK_POLICY_NAME -n NETWORK_POLICY_NAMESPACE -o yaml > NETWORK_POLICY_NAME.yaml
   

   Sostituisci quanto segue:

   • NETWORK_POLICY_NAME: il nome del NetworkPolicy che stai salvando.
   • NETWORK_POLICY_NAMESPACE: lo spazio dei nomi di NetworkPolicy.

3. Elimina NetworkPolicy utilizzando il seguente comando:

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete networkpolicy NETWORK_POLICY_NAME -n NETWORK_POLICY_NAMESPACE
   

4. Continua con l'upgrade.

5. Al termine dell'upgrade, se hai rimosso specifiche NetworkPolicy non di sistema, riapplicale con questo comando:

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG apply -f NETWORK_POLICY_NAME.yaml
   

Requisiti di Google API e IAM

Per eseguire l'upgrade di un cluster alla versione 1.28 e successive, devi attivare kubernetesmetadata.googleapis.com e concedere il ruolo IAM kubernetesmetadata.publisher all'account di servizio logging-monitoring. Queste modifiche sono necessarie per utilizzare Cloud Monitoring.

1. Attiva kubernetesmetadata.googleapis.com:

   gcloud services enable --project PROJECT_ID  \
       kubernetesmetadata.googleapis.com
   

   Sostituisci PROJECT_ID con l'ID del progetto host del parco di cui il cluster utente è membro. Questo è il progetto che hai specificato al momento della creazione del cluster. Se hai creato il cluster utilizzando gkectl, questo è l'ID progetto nel campo gkeConnect.projectID del file di configurazione del cluster.

2. Se la tua organizzazione ha configurato una lista consentita che consente al traffico delle API di Google e di altri indirizzi di passare attraverso il server proxy, aggiungi kubernetesmetadata.googleapis.com alla lista consentita.

3. Concedi il ruolo kubernetesmetadata.publisher all'account di servizio logging-monitoring:

   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member "serviceAccount:SERVICE_ACCOUNT_EMAIL" \
       --role "roles/kubernetesmetadata.publisher"
   

   Sostituisci SERVICE_ACCOUNT_EMAIL con l'indirizzo email del tuoaccount di serviziot di logging e monitoraggio.

Funzionalità legacy bloccate negli upgrade

Le seguenti funzionalità legacy sono bloccate durante l'upgrade del cluster alla versione 1.32:

• Dataplane V1 (Calico)
• Configurazione del bilanciatore del carico F5 Big IP integrato
• Cluster di amministrazione non HA
• Cluster utente Kubeception
• Bilanciatore del carico Seesaw

Prima di eseguire l'upgrade alla versione 1.32, devi eseguire la migrazione dei cluster alle funzionalità consigliate.

Requisiti IAM per l'upgrade dei cluster utente

Ignora questa sezione se prevedi di utilizzare gkectl per l'upgrade del cluster utente.

Se vuoi utilizzare la console Google Cloud , Google Cloud CLI o Terraform per eseguire l'upgrade di un cluster utente e non sei il proprietario del progetto, devi disporre del ruolo Identity and Access Management roles/gkeonprem.admin nel progetto Google Cloud in cui è stato creato il cluster. Per informazioni dettagliate sulle autorizzazioni incluse in questo ruolo, consulta Ruoli GKE On-Prem nella documentazione IAM.

Per utilizzare la console per eseguire l'upgrade del cluster, devi disporre almeno di quanto segue:

• roles/container.viewer. Questo ruolo consente agli utenti di visualizzare la pagina Cluster GKE e altre risorse container nella console. Per informazioni dettagliate sulle autorizzazioni incluse in questo ruolo o per concedere un ruolo con autorizzazioni di lettura/scrittura, consulta Ruoli Kubernetes Engine nella documentazione IAM.

• roles/gkehub.viewer. Questo ruolo consente agli utenti di visualizzare i cluster nella console. Per informazioni dettagliate sulle autorizzazioni incluse in questo ruolo o per concedere un ruolo con autorizzazioni di lettura/scrittura, consulta Ruoli GKE Hub nella documentazione IAM.

Limitazioni relative ai cluster avanzati

Tieni presenti le seguenti limitazioni se hai abilitato i cluster avanzati:

• Per eseguire l'upgrade dei cluster devi utilizzare gkectl. I client API GKE On-Prem (la console, gcloud CLI e Terraform) non sono supportati.

• Sono supportati solo gli upgrade sincroni.

Apportare modifiche alla configurazione prima o dopo un upgrade

Se devi apportare modifiche alla configurazione dei cluster, esegui l'aggiornamento del cluster prima o dopo l'upgrade. L'unica modifica alla configurazione del cluster per un upgrade deve riguardare la versione. A seconda della versione e del tipo di cluster, altre modifiche alla configurazione vengono ignorate automaticamente o causano l'errore dell'upgrade. Per ulteriori informazioni, vedi Rimuovere le modifiche non supportate per sbloccare l'upgrade.

Controllare le versioni disponibili per gli upgrade del cluster

Esegui questo comando per vedere quali versioni sono disponibili per l'upgrade:

gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Sostituisci ADMIN_CLUSTER_KUBECONFIG con il percorso del file kubeconfig del cluster di amministrazione.

L'output mostra la versione attuale e le versioni disponibili per l'upgrade.

Se prevedi di utilizzare la console, gcloud CLI o Terraform per l'upgrade, sono necessari circa 7-14 giorni dopo il rilascio prima che la versione sia disponibile nell'API GKE On-Prem in tutte le regioni Google Cloud . La console elenca solo le versioni disponibili per l'upgrade del cluster utente. I passaggi per l'upgrade di un cluster utente utilizzando gcloud CLI o Terraform includono un passaggio per eseguire gcloud container vmware clusters query-version-config per ottenere le versioni disponibili per l'upgrade.

Esegui l'upgrade della workstation di amministrazione

Il modo in cui esegui l'upgrade della workstation di amministrazione dipende da come l'hai creata: gkeadm o gestita dall'utente.

Esegui l'upgrade del cluster di amministrazione

I passaggi per l'upgrade del cluster di amministrazione variano leggermente a seconda della versione secondaria a cui esegui l'upgrade (la versione di destinazione):

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

Prima di iniziare:

1. 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 gkectl update cluster con le modifiche al file di configurazione.

2. Assicurati che gkectl e i cluster siano della versione appropriata per un upgrade e di aver scaricato il bundle appropriato. La differenza di versione tra i cluster di amministrazione e utente dipende dalla versione di Google Distributed Cloud. Per assicurarti di poter eseguire l'upgrade del cluster di amministrazione, consulta la sezione Differenza di versione tra cluster di amministrazione e cluster utente.

3. 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 nel file di configurazione del cluster di amministrazione, queste modifiche vengono ignorate durante l'upgrade. Per applicare queste modifiche, devi prima eseguire l'upgrade del cluster e poi eseguire un comando update cluster con le modifiche al file di configurazione per apportare altre modifiche al cluster.

Esegui l'upgrade

Esegui i passaggi di questa sezione sulla workstation di amministrazione. Esistono due varianti del comando gkectl upgrade admin:

• Asincrono:
  Con la variante asincrona, il comando avvia l'upgrade e poi lo completa. Non è necessario osservare l'output del comando per l'intera durata dell'upgrade. In alternativa, puoi controllare periodicamente l'avanzamento dell'upgrade eseguendo gkectl list admin e gkectl describe admin. Per utilizzare la variante asincrona, includi il flag --async nel comando.

  Requisiti per l'upgrade asincrono:

  • Supportato solo per i cluster di amministrazione HA con versione 1.29 o successive.
  • In tutti i cluster utente deve essere abilitato Controlplane V2.
  • Versione 1.31: non supportata nei cluster avanzati.
  • Versione 1.32 e successive: disponibile sui cluster avanzati.

• Sincrono:
  Con la variante sincrona, il comando gkectl upgrade admin restituisce messaggi di stato alla workstation di amministrazione man mano che l'upgrade procede.

Esegui l'upgrade di un cluster utente

Puoi utilizzare gkectl, la console, gcloud CLI o Terraform per eseguire l'upgrade di un cluster utente. Per informazioni su quale strumento utilizzare, consulta Scegliere uno strumento per eseguire l'upgrade dei cluster utente.

gkectl upgrade cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG \
    --dry-run

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

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

Rimuovere l'intero bundle

Se hai scaricato un bundle completo e hai eseguito correttamente gkectl prepare e hai eseguito l'upgrade del cluster di amministrazione e di tutti i cluster utente, devi eliminare il bundle completo per risparmiare spazio su disco nella workstation di amministrazione. Esegui questo comando per eliminare l'intero bundle:

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

Ripresa dell'upgrade di un cluster di amministrazione

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

Avviso: non riparare l'amministratore principale con gkectl repair admin-master dopo un tentativo di upgrade non riuscito. In questo modo, il cluster di amministrazione entrerà in uno stato anomalo.

Segui questi passaggi:

1. Verifica che il piano di controllo amministrativo sia integro prima di iniziare il primo tentativo di upgrade. Consulta Diagnostica dei problemi relativi ai cluster. Come descritto in questo argomento, esegui il comando gkectl diagnose cluster per il cluster di amministrazione.

2. Se il control plane amministrativo non è integro prima del tentativo di upgrade iniziale, riparalo con il comando gkectl repair admin-master.

3. 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 del tentativo di upgrade precedente.

Quando esegui di nuovo il comando di upgrade, l'upgrade ripreso ricrea lo stato del cluster di amministrazione dal checkpoint e riesegue l'intero upgrade. A partire dalla versione 1.12.0, se il control plane amministrativo non è integro, la procedura di upgrade eseguirà direttamente l'upgrade alla versione di destinazione senza tentare di ripristinare il cluster di amministrazione alla versione di origine prima di procedere con l'upgrade.

L'upgrade riprenderà dal punto in cui non è riuscito o è stato interrotto se il checkpoint del cluster di amministrazione è disponibile. Se il checkpoint non è disponibile, l'upgrade si baserà sul control plane dell'amministratore, che deve essere integro per poter procedere con l'upgrade. Dopo un upgrade riuscito, il checkpoint viene rigenerato.

Se gkectl esce in modo imprevisto durante l'upgrade di un cluster di amministrazione, il cluster kind non viene pulito. Prima di eseguire di nuovo il comando di upgrade per riprenderlo, elimina il cluster kind:

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

Dopo aver eliminato il cluster kind, 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 di informazioni di output. Durante il rollback, gkeadm utilizza la versione elencata per scaricare il file precedente.

Per eseguire il rollback della 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 amministrativa è quello predefinito admin-ws-config.yaml. In caso contrario, sostituisci AW_CONFIG_FILE con il percorso del file di configurazione della workstation amministrativa.

Il comando di rollback esegue questi passaggi:

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

Installare il bundle con una versione diversa per l'upgrade

Se esegui l'upgrade della workstation, viene installato un bundle con una versione corrispondente per l'upgrade dei cluster. Se vuoi un'altra versione, segui questi passaggi per installare un bundle per TARGET_VERSION, ovvero la versione a cui vuoi eseguire l'upgrade.

1. Per controllare le versioni attuali di gkectl e del 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.

2. In base all'output ottenuto, cerca i seguenti problemi e risolvili se necessario.

   • Se la versione attuale del cluster di amministrazione è inferiore di più di una versione secondaria rispetto a TARGET_VERSION, esegui l'upgrade di tutti i cluster in modo che siano inferiori di una versione secondaria rispetto a 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, fino a raggiungere la versione 1.11.x, quindi procedi con le istruzioni riportate in questo argomento.

   • Se la versione di gkectl è inferiore a TARGET_VERSION, esegui l'upgrade della workstation di amministrazione a TARGET_VERSION.

3. Dopo aver stabilito che le versioni di gkectl e del cluster sono adatte a un upgrade, scarica il bundle.

   Controlla se il file tar.gz del bundle esiste già sulla workstation di amministrazione.

   stat /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz

   Se il bundle non è presente sulla workstation amministrativa, scaricalo.

   gcloud storage cp gs://gke-on-prem-release/gke-onprem-bundle/TARGET_VERSION/gke-onprem-vsphere-TARGET_VERSION.tgz /var/lib/gke/bundles/
   

4. Installa il bundle.

   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.

5. Elenca le versioni del cluster disponibili e assicurati che la versione di destinazione sia inclusa nelle versioni del cluster utente disponibili.

   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 del processo di upgrade

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

Vedi anche: Risoluzione dei problemi relativi alla creazione e all'upgrade dei cluster

Risoluzione dei problemi relativi all'upgrade di un cluster utente

Supponiamo che tu riscontri un problema con la versione di upgrade durante l'upgrade di un cluster utente. Determini con l'assistenza Google che il problema verrà risolto in una patch release futura. Puoi procedere nel seguente modo:

1. Continua a utilizzare la versione attuale per la produzione.
2. Testa la release della patch in un cluster non di produzione quando viene rilasciata.
3. Esegui l'upgrade di tutti i cluster utente di produzione alla versione della patch quando sei pronto.
4. Esegui l'upgrade del cluster di amministrazione alla versione di rilascio della patch.

Risoluzione dei problemi relativi all'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 usufruire delle nuove funzionalità del cluster utente senza essere bloccato dall'upgrade del cluster di amministrazione, il che ti consente di ridurre la frequenza di upgrade del cluster di amministrazione, se vuoi. La procedura di upgrade può procedere come segue:

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

Problemi noti per le versioni recenti

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

Vedi anche: Problemi noti

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

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 pieno, 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 impedire la creazione di un backup locale della workstation amministrativa corrente.

Interruzione per i workload con PodDisruptionBudgets

L'upgrade dei cluster può causare interruzioni o tempi di inattività per i workload che utilizzano i PodDisruptionBudgets (PDB).

I nodi non riescono a completare la procedura di upgrade

Se hai configurato PodDisruptionBudget oggetti che non possono consentire ulteriori interruzioni, l'upgrade dei nodi potrebbe non riuscire a eseguire l'upgrade alla versione del control plane dopo ripetuti tentativi. Per evitare questo errore, ti consigliamo di aumentare le dimensioni di Deployment o HorizontalPodAutoscaler per consentire lo svuotamento del nodo rispettando comunque la configurazione PodDisruptionBudget.

Per visualizzare 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 VMware DRS abilitate nella versione 1.1.0-gke.6

A partire dalla versione 1.1.0-gke.6, Google Distributed Cloud crea automaticamente regole anti-affinità VMware Distributed Resource Scheduler (DRS) per i nodi del cluster utente, in modo da distribuirli in almeno tre host fisici del data center. A partire dalla versione 1.1.0-gke.6, questa funzionalità viene abilitata automaticamente per i cluster nuovi ed esistenti.

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

• VMware DRS è abilitato. VMware DRS richiede la licenza vSphere Enterprise Plus. Per scoprire come attivare DRS, consulta Attivazione di VMware DRS in un cluster

• Il nome utente vSphere fornito nel file di configurazione delle credenziali dispone dell'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 l'upgrade di un cluster utente dalla versione 1.3.x alla 1.4.x, devi disattivare i gruppi anti-affinità. Per saperne di più, consulta questo problema noto nelle note di rilascio di Google Distributed Cloud.

Informazioni sul tempo di inattività durante gli upgrade

Ricrea un file di informazioni se mancante

Se il file di informazioni di output per la workstation di amministrazione non è presente, devi ricrearlo per poter procedere con l'upgrade. Questo file è stato creato quando hai creato inizialmente la workstation e, se hai eseguito un upgrade, è stato aggiornato con nuove informazioni.

Il file di informazioni sull'output ha questo 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

Ecco un file di informazioni sull'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 uguale 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.

Passaggi successivi

• Documentazione di riferimento gcloud CLI

  • gcloud container vmware clusters
  • gcloud container vmware node-pools
  • gcloud container vmware admin-clusters

• Documentazione di riferimento di Terraform

  • google_gkeonprem_vmware_cluster
  • google_gkeonprem_vmware_node_pool