Aggiornamento manuale di un cluster o di un pool di nodi

Per impostazione predefinita, gli upgrade automatici sono abilitati per i cluster Google Kubernetes Engine (GKE) e per i pool di nodi GKE Standard.

Questa pagina spiega come richiedere manualmente un upgrade o un downgrade per il control plane o i nodi di un cluster GKE. Puoi eseguire l'upgrade manuale della versione nel seguente modo:

• Autopilot: esegui l'upgrade della versione del control plane.
• Standard: esegui l'upgrade della versione del control plane e della versione del node pool.

Per eseguire l'upgrade di un cluster, GKE aggiorna la versione in esecuzione del control plane e dei nodi. I cluster vengono aggiornati a una versione secondaria più recente (ad esempio, da 1.24 a 1.25) o a una versione patch più recente (ad esempio, da 1.24.2-gke.100 a 1.24.5-gke.200). Per maggiori informazioni, consulta Controllo delle versioni e assistenza di GKE.

Puoi scoprire di più su come funzionano gli upgrade automatici e manuali dei cluster. Puoi anche controllare quando possono essere eseguiti gli upgrade automatici configurando periodi di manutenzione ed esclusioni.

Le nuove versioni di GKE vengono annunciate regolarmente e puoi ricevere una notifica sulle nuove versioni disponibili per ogni cluster specifico con le notifiche del cluster. Per trovare target di upgrade automatico specifici per i cluster, ottieni informazioni sugli upgrade di un cluster.

Per scoprire di più sulle versioni disponibili, consulta la sezione Controllo delle versioni. Per scoprire di più sui cluster, consulta Architettura dei cluster. Per indicazioni sull'upgrade dei cluster, consulta Best practice per l'upgrade dei cluster.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti operazioni:

• Attiva l'API Google Kubernetes Engine.
Attiva l'API Google Kubernetes Engine
• Se vuoi utilizzare Google Cloud CLI per questa attività, installala e poi inizializzala. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo gcloud components update.

• Assicurati di avere un cluster Autopilot o Standard esistente. Per creare un nuovo cluster, consulta Crea un cluster Autopilot.

Salvare i dati sui dischi permanenti

Prima di eseguire l'upgrade di un pool di nodi, devi assicurarti che tutti i dati che devi conservare siano memorizzati in un pod utilizzando volumi permanenti che utilizzano dischi permanenti. I dischi permanenti vengono smontati, anziché cancellati, durante gli upgrade e i relativi dati vengono "trasferiti" tra i pod.

Si applicano le seguenti limitazioni ai dischi permanenti:

• I nodi su cui vengono eseguiti i pod devono essere VM di Compute Engine
• Queste VM devono trovarsi nello stesso progetto e nella stessa zona di Compute Engine del disco permanente.

Per scoprire come aggiungere un disco permanente a un'istanza del nodo esistente, consulta Aggiunta o ridimensionamento di dischi permanenti a livello di zona nella documentazione di Compute Engine.

Informazioni sull'upgrade

L'upgrade del control plane e dei nodi di un cluster viene eseguito separatamente.

L'upgrade dei control plane del cluster viene sempre eseguito regolarmente, indipendentemente dal fatto che il cluster sia registrato o meno su un canale di rilascio.

Limitazioni

Non è possibile eseguire l'upgrade dei cluster alpha.

Versioni supportate

Le note di rilascio annunciano quando diventano disponibili nuove versioni e quando le versioni precedenti non sono più disponibili. In qualsiasi momento, puoi elencare tutte le versioni supportate di cluster e nodi utilizzando questo comando:

gcloud container get-server-config

Se il tuo cluster è registrato in un canale di rilascio, puoi eseguire l'upgrade a una versione patch in un canale di rilascio diverso con la stessa versione secondaria del control plane. Ad esempio, puoi eseguire l'upgrade del cluster dalla versione 1.21.12-gke.1700 nelcanale regolarer alla versione 1.21.13-gke.900 nelcanale rapidod. Per maggiori informazioni, consulta Esecuzione di versioni patch da un canale più recente. Tutti i cluster Autopilot sono registrati in un canale di rilascio.

Limitazioni del downgrade

In alcuni scenari, puoi eseguire il downgrade della versione del cluster a una versione precedente.

Per mitigare un upgrade non riuscito del control plane del cluster, puoi eseguire il downgrade del control plane a una patch release precedente se la versione è una patch release precedente all'interno della stessa versione secondaria. Ad esempio, se il control plane del cluster esegue GKE 1.25.3-gke.400, puoi eseguire il downgrade del control plane alla versione 1.25.2-gke.100, se questa versione è ancora disponibile.

Non puoi eseguire il downgrade del control plane di un cluster Kubernetes a una versione secondaria precedente. Ad esempio, se il tuo control plane esegue GKE versione 1.25, non puoi eseguire il downgrade alla versione 1.24. Se tenti di farlo, viene visualizzato il seguente messaggio di errore:

ERROR: (gcloud.container.clusters.upgrade) ResponseError: code=400,
message=Master cannot be upgraded to "1.24.3-gke.100": specified version is not
newer than the current version.

Non puoi eseguire il downgrade della versione secondaria del control plane di un cluster, pertanto ti consigliamo di testare e qualificare gli upgrade delle versioni secondarie con i cluster in un ambiente di test quando una nuova versione secondaria diventa disponibile, ma prima che diventi predefinita. Ciò è particolarmente consigliato se il tuo cluster potrebbe essere interessato da modifiche significative nella prossima versione secondaria, ad esempio la rimozione di API o funzionalità deprecate.

Per risolvere un upgrade non riuscito del pool di nodi, puoi eseguire il downgrade di un pool di nodi a una versione patch o secondaria precedente. Assicurati di non eseguire il downgrade dei nodi a una versione precedente di più di due versioni secondarie rispetto alla versione del control plane del cluster.

Upgrade del cluster

Google esegue l'upgrade automatico di cluster e nodi. Per un maggiore controllo sugli upgrade automatici ricevuti dal cluster e dai relativi nodi, puoi registrarlo in un canale di rilascio. Tutti i cluster Autopilot vengono registrati automaticamente in un canale di rilascio.

Per scoprire di più sulla gestione della versione GKE del cluster, consulta la sezione Upgrade.

Puoi avviare un upgrade manuale in qualsiasi momento dopo la disponibilità di una nuova versione.

Upgrade manuale del piano di controllo

Quando avvii l'upgrade di un cluster, non puoi modificare la configurazione del cluster per diversi minuti finché il control plane non è nuovamente accessibile. Se devi evitare tempi di inattività durante gli upgrade del control plane, valuta la possibilità di utilizzare un cluster Autopilot o un cluster Standard regionale. Questa operazione non influisce sulla disponibilità dei nodi worker su cui vengono eseguiti i carichi di lavoro, in quanto rimangono disponibili durante gli upgrade del control plane.

Puoi eseguire l'upgrade manuale del piano di controllo Autopilot o Standard utilizzando la console Google Cloud o Google Cloud CLI.

gcloud container get-server-config

gcloud container clusters upgrade CLUSTER_NAME --master

gcloud container clusters upgrade CLUSTER_NAME --master \
    --cluster-version VERSION

Dopo aver eseguito l'upgrade di un control plane Standard, puoi eseguire l'upgrade dei relativi nodi. Per impostazione predefinita, i nodi Standard creati utilizzando la console Google Cloud hanno l'upgrade automatico abilitato, quindi questa operazione viene eseguita automaticamente. Autopilot esegue sempre l'upgrade automatico dei nodi.

Downgrade dei cluster

1. Imposta un'esclusione della manutenzione prima di eseguire il downgrade per impedire a GKE di eseguire automaticamente l'upgrade del control plane dopo il downgrade.

2. Esegui il downgrade del control plane del cluster a una versione patch precedente:

    gcloud container clusters upgrade CLUSTER_NAME \
        --master --cluster-version VERSION
   

Disattivazione degli upgrade automatici dei cluster

La sicurezza dell'infrastruttura è una priorità assoluta per GKE e, di conseguenza, i control plane vengono aggiornati regolarmente e non possono essere disattivati. Tuttavia, puoi applicare periodi di manutenzione ed esclusioni per sospendere temporaneamente gli upgrade per i control plane e i nodi.

Anche se non è consigliabile, puoi disattivare l'upgrade automatico dei nodi.

Controllare la cronologia recente degli upgrade del control plane

Per uno snapshot della cronologia recente degli upgrade automatici di un cluster, ottieni informazioni sugli upgrade di un cluster.

In alternativa, puoi elencare le operazioni recenti per vedere quando è stato eseguito l'upgrade del control plane:

gcloud container operations list --filter="TYPE:UPGRADE_MASTER AND TARGET:CLUSTER_NAME"

Sostituisci CLUSTER_NAME con il nome del cluster.

Upgrade dei node pool

Per impostazione predefinita, i nodi di un cluster hanno l'upgrade automatico abilitato. Gli upgrade automatici dei nodi assicurano che la versione del control plane e dei nodi del cluster rimangano sincronizzate e conformi alle norme sul disallineamento delle versioni di Kubernetes, che garantiscono che i control plane siano compatibili con i nodi fino a due versioni secondarie precedenti al control plane. Ad esempio, i control plane Kubernetes 1.29 sono compatibili con i nodi Kubernetes 1.27.

Con gli upgrade dei pool di nodi GKE, puoi scegliere tra due strategie di upgrade configurabili, ovvero upgrade di sovraccarico e upgrade blu/verde.

Scegli una strategia e utilizza i parametri per ottimizzarla in modo che si adatti meglio alle esigenze del tuo ambiente cluster.

Come funzionano gli upgrade dei nodi

Durante l'upgrade di un nodo, GKE smette di pianificare nuovi pod e tenta di pianificare i pod in esecuzione su altri nodi. Questo è simile ad altri eventi che ricreano il nodo, ad esempio l'attivazione o la disattivazione di una funzionalità supool di nodiol.

Durante gli upgrade automatici o manuali dei nodi, i PodDisruptionBudget (PDB) e il periodo di tolleranza per l'interruzione dei pod vengono rispettati per un massimo di 1 ora. Se i pod in esecuzione sul nodo non possono essere pianificati su nuovi nodi dopo un'ora, GKE avvia comunque l'upgrade. Questo comportamento si applica anche se configuri i PDB in modo che abbiano sempre tutte le repliche disponibili impostando il campo maxUnavailable su 0 o 0% o impostando il campo minAvailable su 100% o sul numero di repliche. In tutti questi scenari, GKE elimina i pod dopo un'ora in modo che possa avvenire l'eliminazione del nodo.

L'upgrade viene completato solo quando tutti i nodi sono stati ricreati e il cluster è nello stato desiderato. Quando un nodo di cui è stato eseguito l'upgrade si registra con il control plane, GKE lo contrassegna come pianificabile.

Le nuove istanze dei nodi eseguono la versione di Kubernetes desiderata, nonché:

• L'immagine del nodo
• kubelet
• kube-proxy

Affinché l'upgrade di un pool di nodi venga considerato completato, tutti i nodi del pool di nodi devono essere ricreati. Se un upgrade è stato avviato ma non è stato completato e si trova in uno stato di upgrade parziale, la versione del pool di nodi potrebbe non riflettere la versione di tutti i nodi. Per saperne di più, consulta Alcune versioni dei nodi non corrispondono alla versione pool di nodi dopo un upgrade incompleto del node pool. Per determinare che l'upgrade del pool di nodi è stato completato, controlla lo stato dell'upgrade delpool di nodie pool. Se l'operazione di upgrade supera il periodo di conservazione, verifica che la versione di ogni nodo corrisponda alla versione del pool di nodi.

Upgrade manuale di un node pool

Puoi eseguire manualmente l'upgrade della versione di un pool di nodi in modo che corrisponda alla versione del control plane o a una versione precedente ancora disponibile e compatibile con il control plane. Puoi eseguire l'upgrade manuale di più node pool in parallelo, mentre GKE esegue automaticamente l'upgrade di un solo pool di nodi alla volta.

Quando esegui l'upgrade manuale di un pool di nodi, GKE rimuove tutte le etichette che hai aggiunto ai singoli nodi utilizzando kubectl. Per evitare questo problema, applica le etichette ai pool di nodi.

Prima di eseguire l'upgrade manuale del pool di nodi, tieni presente le seguenti condizioni:

• L'upgrade di un pool di nodi potrebbe interrompere i workload in esecuzione in quel pool di nodi. Per evitare questo problema, puoi creare un nuovo pool di nodi con la versione desiderata ed eseguire la migrazione del workload. Dopo la migrazione, puoi eliminare il vecchio pool di nodi.
• Se esegui l'upgrade di un pool di nodi con un Ingress in stato di errore, il gruppo di istanze non viene sincronizzato. Per risolvere il problema, controlla innanzitutto lo stato utilizzando il comando kubectl get ing. Se il gruppo di istanze non è sincronizzato, puoi risolvere il problema riapplicando il manifest utilizzato per creare l'ingresso.

Puoi eseguire manualmente l'upgrade dei tuoi pool di nodi a una versione compatibile con il piano di controllo utilizzando la console Google Cloud o Google Cloud CLI.

gcloud container clusters upgrade CLUSTER_NAME \
  --node-pool=NODE_POOL_NAME

gcloud container clusters upgrade CLUSTER_NAME \
  --node-pool=NODE_POOL_NAME \
  --cluster-version VERSION

Eseguire il downgrade dei node pool

Puoi eseguire il downgrade di un pool di nodi, ad esempio, per mitigare un upgradepool di nodil non riuscito. Consulta le limitazioni prima di eseguire il downgrade di un pool di nodi.

1. Imposta un'esclusione della manutenzione per il cluster per impedire l'upgrade automatico del pool di nodi da parte di GKE dopo il downgrade.
2. Per eseguire il downgrade di un pool di nodi, specifica una versione precedente seguendo le istruzioni per eseguire l'upgrade manuale di un node pool.

Modifica dei parametri di upgrade di sovraccarico

Per scoprire di più sulla modifica dei parametri di upgrade di sovraccarico, consulta Configurare gli upgrade di sovraccarico.

Controllo dello stato dell'upgrade del pool di nodi

Puoi controllare lo stato di un upgrade utilizzando gcloud container operations.

Visualizza un elenco di tutte le operazioni in esecuzione e completate nel cluster degli ultimi 12 giorni se le operazioni sono meno di 5000 o le ultime 5000 operazioni:

gcloud container operations list

A ogni operazione viene assegnato un ID operazione e un tipo di operazione, nonché ora di inizio e di fine, cluster di destinazione e stato. L'elenco ha un aspetto simile al seguente esempio:

NAME                              TYPE                ZONE           TARGET              STATUS_MESSAGE  STATUS  START_TIME                      END_TIME
operation-1505407677851-8039e369  CREATE_CLUSTER      us-west1-a     my-cluster                          DONE    20xx-xx-xxT16:47:57.851933021Z  20xx-xx-xxT16:50:52.898305883Z
operation-1505500805136-e7c64af4  UPGRADE_CLUSTER     us-west1-a     my-cluster                          DONE    20xx-xx-xxT18:40:05.136739989Z  20xx-xx-xxT18:41:09.321483832Z
operation-1505500913918-5802c989  DELETE_CLUSTER      us-west1-a     my-cluster                          DONE    20xx-xx-xxT18:41:53.918825764Z  20xx-xx-xxT18:43:48.639506814Z

Per ottenere ulteriori informazioni su un'operazione specifica, specifica l'ID operazione come mostrato nel seguente comando:

gcloud container operations describe OPERATION_ID

Ad esempio:

gcloud container operations describe operation-1507325726639-981f0ed6
endTime: '20xx-xx-xxT21:40:05.324124385Z'
name: operation-1507325726639-981f0ed6
operationType: UPGRADE_CLUSTER
selfLink: https://container.googleapis.com/v1/projects/.../kubernetes-engine/docs/zones/us-central1-a/operations/operation-1507325726639-981f0ed6
startTime: '20xx-xx-xxT21:35:26.639453776Z'
status: DONE
targetLink: https://container.googleapis.com/v1/projects/.../kubernetes-engine/docs/zones/us-central1-a/clusters/...
zone: us-central1-a

Se l'upgrade è stato annullato o non è riuscito ed è stato completato parzialmente, puoi riprenderlo o eseguirne il rollback.

Controllo delle impostazioni di upgrade del pool di nodi

Puoi visualizzare i dettagli sulla strategia di upgrade dei nodi utilizzata per i tuoi node pool utilizzando il comando gcloud container node-pools describe. Per gli upgrade blu/verde, il comando restituisce anche la fase corrente dell'upgrade.

Esegui questo comando:

gcloud container node-pools describe NODE_POOL_NAME \
--cluster=CLUSTER_NAME

Sostituisci quanto segue:

• NODE_POOL_NAME: il nome del pool di nodi da descrivere.
• CLUSTER_NAME: il nome del cluster del pool di nodi da descrivere.

Questo comando restituirà le impostazioni di upgrade correnti. L'esempio seguente mostra l'output se utilizzi la strategia di upgrade blu/verde.

upgradeSettings:
  blueGreenSettings:
    nodePoolSoakDuration: 1800s
    standardRolloutPolicy:
      batchNodeCount: 1
      batchSoakDuration: 10s
  strategy: BLUE_GREEN

Se utilizzi la strategia di upgrade blu/verde, l'output include anche dettagli sulle impostazioni di upgrade blu/verde e sulla relativa fase intermedia corrente. Il seguente esempio mostra come potrebbe apparire:

updateInfo:
  blueGreenInfo:
    blueInstanceGroupUrls:
    - https://www.googleapis.com/compute/v1/projects/{PROJECT_ID}/zones/{LOCATION}/instanceGroupManagers/{BLUE_INSTANCE_GROUP_NAME}
    bluePoolDeletionStartTime: {BLUE_POOL_DELETION_TIME}
    greenInstanceGroupUrls:
    - https://www.googleapis.com/compute/v1/projects/{PROJECT_ID}/zones/{LOCATION}/instanceGroupManagers/{GREEN_INSTANCE_GROUP_NAME} 
    greenPoolVersion: {GREEN_POOL_VERSION}
    phase: DRAINING_BLUE_POOL

Annullamento dell'upgrade di un pool di nodi

Puoi annullare un upgrade in qualsiasi momento. Per scoprire di più su cosa succede quando annulli un upgrade di incremento, vedi Annullare un upgrade di incremento. Per scoprire di più su cosa succede quando annulli un upgrade blu/verde, vedi Annullare un upgrade blu/verde.

1. Recupera l'ID operazione dell'upgrade:

   gcloud container operations list
   

2. Annulla l'upgrade:

   gcloud container operations cancel OPERATION_ID
   

Consulta la gcloud container operations cancel documentazione.

Ripresa dell'upgrade di un pool di nodi

Puoi riprendere un upgrade avviandolo manualmente di nuovo, specificando la versione di destinazione dell'upgrade originale.

Se, ad esempio, un upgrade non è riuscito o se hai messo in pausa un upgrade in corso, puoi riprendere l'upgrade annullato avviando di nuovo lo stesso upgrade nel pool di nodi, specificando la versione di destinazione dell'operazione di upgrade iniziale.

Per scoprire di più su cosa succede quando riprendi un upgrade, consulta Riprendere un upgrade di incremento e upgrade blu/verde.

Per riprendere un upgrade, utilizza il seguente comando:

    gcloud container clusters upgrade CLUSTER_NAME \
      --node-pool=NODE_POOL_NAME \
      --cluster-version VERSION

Sostituisci quanto segue:

• NODE_POOL_NAME: il nome del pool di nodi per cui vuoi riprendere l'upgrade.
• CLUSTER_NAME: il nome del cluster del pool di nodi per cui vuoi riprendere l'upgrade.
• VERSION: la versione di destinazione dell'upgrade del pool di nodi annullato.

Per saperne di più, consulta la documentazione relativa a gcloud container clusters upgrade.

Rollback dell'upgrade di un pool di nodi

Puoi eseguire il rollback di un pool di nodi per eseguire il downgrade dei nodi di cui è stato eseguito l'upgrade allo stato originale precedente all'inizio dell'upgrade delpool di nodil.

Utilizza il comando rollback se un upgrade in corso è stato annullato, l'upgrade non è riuscito o è incompleto a causa di un intervallo di manutenzione scaduto. In alternativa, se vuoi specificare la versione, segui le istruzioni per eseguire il downgrade del pool di nodi.

Per scoprire di più su cosa succede quando esegui il rollback di un upgrade del pool di nodi, consulta Eseguire il rollback di un upgrade di incremento o Eseguire il rollback di un upgrade blu/verde.

Per eseguire il rollback di un upgrade, esegui questo comando:

gcloud container node-pools rollback NODE_POOL_NAME \
  --cluster CLUSTER_NAME

Sostituisci quanto segue:

• NODE_POOL_NAME: il nome del pool di nodi per cui eseguire il rollback dell'upgrade delpool di nodil.
• CLUSTER_NAME: il nome del cluster del pool di nodi per cui eseguire il rollback dell'upgrade.

Consulta la documentazione gcloud container node-pools rollback.

Completamento dell'upgrade di un pool di nodi

Se utilizzi la strategia di upgrade blu/verde, puoi completare l'upgrade di un pool di nodi durante la fase di test, saltando il resto del tempo di test.

Per scoprire come funziona il completamento di un upgrade del pool di nodi, consulta Completa un pool di nodi pool.

Per completare un upgrade quando utilizzi la strategia di upgrade blu/verde, esegui questo comando:

gcloud container node-pools complete-upgrade NODE_POOL_NAME \
  --cluster CLUSTER_NAME

Sostituisci quanto segue:

• NODE_POOL_NAME: il nome del pool di nodi per cui vuoi completare l'upgrade.
• CLUSTER_NAME: il nome del cluster del node pool per cui vuoi completare l'upgrade.

Consulta la documentazione gcloud container node-pools complete-upgrade.

Problemi noti

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}'

Sebbene gli upgrade automatici possano riscontrare il problema, il processo di upgrade automatico forza l'upgrade dei nodi. Tuttavia, l'upgrade richiede un'ora in più per ogni nodo nello spazio dei nomi istio-system che viola il PodDisruptionBudget.

Risoluzione dei problemi

Alcune versioni dei nodi non corrispondono alla versione del pool di nodi dopo un upgrade incompleto del pool di nodi

Un'operazione di upgrade del pool di nodi potrebbe non essere completata per uno dei seguenti motivi:

• L'upgrade è stato annullato da te o da GKE.
• L'upgrade non è riuscito a causa di un problema imprevisto.
• L'upgrade non è completo a causa del timeout di un periodo di manutenzione o di un'esclusione dalla manutenzione che impedisce gli upgrade.

Puoi confermare lo stato dell'operazione di upgrade del pool di nodi se l'operazione è stata completata controllando lo stato dell'upgrade del pool di nodi pool.

Se l'upgrade di un pool di nodi è stato completato parzialmente, potrebbe verificarsi quanto segue:

• Alcuni nodi hanno versioni che non corrispondono a quella del pool di nodi.
• La versione del pool di nodi è quella esistente o quella nuova.

Per riportare il pool di nodi a uno stato in cui tutti i nodi eseguono la stessa versione, riprendi o esegui il rollback di un upgrade incompleto del pool di nodi.

Riprendere o eseguire il rollback di un upgrade incompleto del pool di nodi

Se GKE non ha completato l'upgrade di un pool di nodi e i nodi sono stati aggiornati parzialmente alla nuova versione, puoi riprendere o rollback dell'upgrade. Ciò è pertinente per gli upgrade pool di nodi che utilizzano la strategia di upgrade dei nodi, gli upgrade inattivi o gli upgrade blu/verdi.

Segui le istruzioni per riprendere o ripristinare l'upgrade in modo che tutti i nodi del pool di nodi eseguano una versione coerente. Se non fai nulla, GKE alla fine tenta di eseguire nuovamente l'upgrade del pool di nodi quando è disponibile la manutenzione.

Utilizzo della CPU dei nodi superiore al previsto

Potresti riscontrare un problema per cui alcuni nodi utilizzano una CPU superiore a quella prevista dai pod in esecuzione.

Ciò può verificarsi se il cluster o i nodi non eseguono una versione supportata. Consulta le note di rilascio per assicurarti che le versioni che utilizzi siano disponibili e supportate. Puoi anche eseguire questo comando per elencare tutte le versioni supportate di cluster e nodi:

gcloud container get-server-config

Passaggi successivi

• Scopri di più sull'architettura dei cluster.
• Scopri di più sui canali di rilascio.