Aggiornamento manuale di un cluster o di un pool di nodi

Questo documento spiega come richiedere manualmente un upgrade o un downgrade per il control plane o i nodi di un cluster Google Kubernetes Engine (GKE). GKE esegue automaticamente l'upgrade della versione del control plane e dei nodi per garantire che il cluster riceva nuove funzionalità, correzioni di bug e patch di sicurezza. Tuttavia, come spiegato in questo documento, puoi anche eseguire manualmente questi upgrade.

Per ulteriori informazioni sul funzionamento degli upgrade automatici e manuali dei cluster, vedi Informazioni sugli upgrade dei cluster GKE. Puoi anche controllare quando possono essere eseguiti gli upgrade automatici configurando periodi di manutenzione ed esclusioni.

Puoi eseguire manualmente l'upgrade della versione nel seguente modo:

Per eseguire l'upgrade di un cluster, GKE aggiorna la versione eseguita dal control plane e dai nodi in operazioni separate. I cluster vengono aggiornati a una versione secondaria più recente (ad esempio, dalla versione 1.33 alla 1.34) o a una versione patch più recente (ad esempio, dalla versione 1.33.4-gke.1350000 alla 1.33.5-gke.1080000). La versione del control plane e dei nodi di un cluster non è necessariamente sempre la stessa. Per maggiori informazioni sulle versioni, consulta Controllo delle versioni e assistenza di GKE.

Per saperne di più sul funzionamento degli upgrade dei cluster, inclusi quelli automatici e manuali, consulta Informazioni cluster GKE GKE.

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 saperne di più sulle versioni disponibili, consulta Controllo delle versioni. Per saperne di più sui cluster, consulta Architettura del 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 inizializza gcloud CLI. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo il comando gcloud components update. Le versioni precedenti di gcloud CLI potrebbero non supportare l'esecuzione dei comandi in questo documento.
  • Assicurati di avere un cluster Autopilot o Standard esistente. Per creare un nuovo cluster, vedi Crea un cluster Autopilot.

Informazioni sull'upgrade

L'upgrade del control plane e dei nodi di un cluster viene eseguito separatamente. La versione del control plane e dei nodi del cluster non è necessariamente sempre la stessa.

L'upgrade dei piani di controllo e dei nodi del cluster viene 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 \
    --location=CONTROL_PLANE_LOCATION

Sostituisci CONTROL_PLANE_LOCATION con la località (regione o zona) per il control plane, ad esempio us-central1 o us-central1-a.

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.33.4-gke.1350000 nel canale regolare alla versione 1.33.5-gke.1162000 nel canale Rapid. Per saperne di più, consulta Esecuzione di versioni patch da un canale più recente. Tutti i cluster Autopilot sono registrati nei canali di rilascio.

Informazioni sul downgrade

Puoi eseguire il downgrade della versione del cluster a una versione precedente in determinati scenari:

A parte gli scenari descritti nei punti precedenti, non puoi eseguire il downgrade di un cluster. Non puoi eseguire il downgrade di un control plane del cluster a una versione secondaria precedente, anche dopo un upgrade secondario del control plane in un unico passaggio. Ad esempio, se il control plane esegue GKE versione 1.34, non puoi eseguire il downgrade alla versione 1.33. 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.33.4-gke.1350000": specified version is
not newer than the current version.

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 la destinazione dell'upgrade automatico per il tuo cluster. 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 ulteriori informazioni sulla disponibilità delle versioni, vedi Quali versioni sono disponibili in un canale.

Esegui l'upgrade del control plane del cluster

GKE esegue automaticamente l'upgrade dei nodi e dei control plane del cluster. Per gestire la modalità di upgrade dei cluster GKE, consulta Controllare gli upgrade dei cluster.

Con i cluster Autopilot e i cluster standard regionali, il control plane rimane disponibile durante gli upgrade del control plane. Tuttavia, quando avvii l'upgrade del control plane per i cluster zonali, non puoi modificare la configurazione del cluster finché il control plane non è nuovamente accessibile dopo alcuni minuti. Gli upgrade del control plane non influiscono sulla disponibilità dei nodi worker su cui vengono eseguiti i carichi di lavoro, perché rimangono disponibili durante gli upgrade del control plane.

Nell'ambito della gestione delle versioni del cluster, puoi avviare un upgrade manuale in qualsiasi momento dopo che una nuova versione diventa disponibile, utilizzando uno dei seguenti metodi:

  • Upgrade in un solo passaggio: esegui l'upgrade del control plane direttamente a una versione secondaria o patch successiva il più rapidamente possibile. Puoi utilizzare questo approccio se hai già convalidato le prestazioni del cluster e del workload nella nuova versione secondaria.
  • Upgrade secondario del control plane in due passaggi con rollback sicuro (anteprima): esegui l'upgrade del control plane a una versione secondaria successiva utilizzando una procedura in due passaggi in cui puoi convalidare la nuova versione secondaria per un periodo di tempo di rodaggio e eseguire il rollback, se necessario. Questo metodo di upgrade è disponibile solo per l'upgrade alla versione 1.33 o successive, per gli upgrade secondari manuali del control plane.

Esegui manualmente l'upgrade del control plane con un upgrade in un solo passaggio

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

Console

Per aggiornare manualmente il control plane del cluster, svolgi i seguenti passaggi:

  1. Vai alla pagina Google Kubernetes Engine nella console Google Cloud .

    Vai a Google Kubernetes Engine

  2. Fai clic sul nome del cluster.

  3. In Impostazioni di base sul cluster, fai clic su Upgrade disponibile accanto a Versione.

  4. Seleziona la nuova versione, quindi fai clic su Salva modifiche.

gcloud

Per visualizzare le versioni disponibili per il piano di controllo del cluster, esegui questo comando:

gcloud container get-server-config \
    --location=CONTROL_PLANE_LOCATION

Per eseguire l'upgrade alla versione predefinita del cluster, esegui questo comando:

gcloud container clusters upgrade CLUSTER_NAME \
    --master \
    --location=CONTROL_PLANE_LOCATION

Per eseguire l'upgrade a una versione specifica diversa da quella predefinita, specifica il flag --cluster-version come nel seguente comando:

gcloud container clusters upgrade CLUSTER_NAME \
    --master \
    --location=CONTROL_PLANE_LOCATION \
    --cluster-version=VERSION

Sostituisci VERSION con la versione a cui vuoi eseguire l'upgrade del cluster. Puoi utilizzare una versione specifica, ad esempio 1.32.9-gke.1072000, oppure un alias di versione, come latest. Per ulteriori informazioni, vedi Specifica della versione del cluster.

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.

Upgrade secondario del control plane in due passaggi con rollback sicuro

Puoi eseguire manualmente l'upgrade del control plane del tuo cluster GKE Autopilot o Standard alla versione secondaria successiva con un upgrade in due passaggi. In questo processo in due passaggi, puoi testare le prestazioni del cluster con la nuova versione secondaria, nota come versione binaria, utilizzando le funzionalità e le API della versione secondaria precedente, nota come versione emulata. Durante questo periodo di attesa, in cui il control plane viene eseguito in quella che è nota come modalità emulata, puoi eseguire il rollback alla versione secondaria precedente, se necessario. Per ulteriori informazioni su come Kubernetes consente questo tipo di upgrade, consulta Versione di compatibilità per i componenti del control plane Kubernetes.

Gli upgrade in due passaggi funzionano nel seguente modo:

  1. Upgrade binario: GKE esegue l'upgrade del binario del control plane alla nuova versione secondaria, ma emula la versione secondaria precedente:

    • Emula la versione precedente: il cluster esegue il nuovo binario, ma continua a emulare il comportamento dell'API della versione secondaria precedente. Ad esempio, puoi chiamare API rimosse nella nuova versione secondaria, ma ancora disponibili nella versione secondaria precedente.
    • Testa il nuovo binario: puoi testare i nuovi binari per regressioni, correzioni e modifiche delle prestazioni prima di rendere accessibili le funzionalità di Kubernetes disponibili con la nuova versione secondaria. Monitora le metriche, i log, gli stati dei pod, le percentuali di errore e la latenza dell'applicazione.
    • Assorbi le modifiche: attendi da 6 ore a 7 giorni per avere il tempo di testare e monitorare. Trascorso questo periodo di tempo, GKE esegue l'upgrade della versione emulata.
    • Esegui il rollback o completa l'upgrade: puoi eseguire il rollback, se necessario. In alternativa, puoi passare alla fase successiva se hai familiarità con la nuova versione secondaria, non vuoi attendere il completamento del periodo di prova e sei pronto per iniziare a utilizzare le nuove funzionalità e le modifiche all'API.

  2. Upgrade della versione emulata: GKE aggiorna la versione emulata in modo che corrisponda alla nuova versione binaria.

    • Abilita nuove funzionalità: tutte le nuove funzionalità e le modifiche all'API della nuova versione secondaria sono abilitate.
    • Nessun rollback: dopo questo passaggio, non puoi eseguire il rollback alla versione secondaria originale. L'upgrade è stato completato.

Durante questa operazione, si applicano le seguenti limitazioni:

  • Non puoi avviare un upgrade secondario del control plane in un unico passaggio.
  • Non puoi creare o eseguire l'upgrade dei nodi a una versione successiva a quella emulata.
  • GKE non esegue alcun tipo di upgrade automatico del control plane o dei nodi.

Avviare un upgrade in due passaggi

Avvia un upgrade in due passaggi eseguendo questo comando:

gcloud beta container clusters upgrade CLUSTER_NAME \
  --location=CONTROL_PLANE_LOCATION \
  --cluster-version VERSION \
  --control-plane-soak-duration SOAK_DURATION \
  --master

Sostituisci quanto segue:

  • CLUSTER_NAME: il nome del cluster.
  • CONTROL_PLANE_LOCATION: la località (regione o zona) per il control plane, ad esempio us-central1 o us-central1-a.
  • VERSION: una patch specifica della prossima versione secondaria. Ad esempio, se il cluster esegue la versione 1.33, 1.34.1-gke.1829001.
  • SOAK_DURATION: il tempo di attesa nella fase di rollback sicuro. Puoi impostare questo valore per un minimo di 6 ore e un massimo di 7 giorni utilizzando i formati di durata assoluta, come spiegato nel riferimento per gcloud topic datetimes. Ad esempio, utilizza 2d1h per un tempo di ammollo di due giorni e un'ora.

Testare il nuovo binario durante un upgrade in due passaggi

Durante il tempo di sospensione, verifica che il cluster, con il control plane che esegue il nuovo binario, e i workload funzionino come previsto. Puoi eseguire uno dei seguenti passaggi, a seconda che tu riesca a verificare che i carichi di lavoro siano compatibili con il nuovo binario:

  • Rollback: se riscontri un problema con i tuoi carichi di lavoro in esecuzione sul nuovo binario, puoi eseguire il rollback alla versione secondaria precedente.
  • Completa l'upgrade: se hai verificato che i tuoi carichi di lavoro vengono eseguiti senza problemi sul nuovo binario, puoi completare l'upgrade se vuoi iniziare a utilizzare le funzionalità e le API della nuova versione.
  • Attendi: puoi anche attendere il tempo di ammollo. Successivamente, GKE esegue l'upgrade della versione emulata, in cui passa all'utilizzo delle funzionalità e delle API della nuova versione secondaria.
Osserva l'upgrade in corso

Per ottenere informazioni su un upgrade in corso, utilizza una delle seguenti risorse:

Eseguire il rollback di un upgrade in due passaggi dopo l'upgrade della versione binaria

Durante un upgrade in due passaggi, dopo l'upgrade della versione binaria c'è il periodo di soaking. Durante questo periodo, se necessario, puoi eseguire il rollback alla versione secondaria precedente. Non puoi eseguire il rollback dopo che GKE esegue l'upgrade della versione emulata.

Al termine dell'operazione di rollback, il control plane esegue la versione secondaria precedente come prima di avviare l'upgrade in due passaggi.

Se possibile, segui questi passaggi per eseguire il rollback:

  1. Verifica di poter ancora eseguire il rollback del control plane alla versione secondaria precedente eseguendo il comando gcloud CLI in Visualizzare le informazioni sugli upgrade a livello di cluster. Determina se puoi eseguire il rollback in base all'output del comando:

    • Puoi eseguire il rollback se nell'output è presente una sezione rollbackSafeUpgradeStatus. In questa sezione, salva previousVersion per la variabile VERSION nel passaggio successivo. Vai al passaggio successivo.
    • Non puoi eseguire il rollback se non è presente una sezione rollbackSafeUpgradeStatus. Ciò indica che GKE ha già eseguito l'upgrade della versione emulata. Non puoi eseguire il passaggio successivo.

  2. Se il passaggio precedente ha stabilito che il rollback è possibile, esegui il rollback alla versione precedente:

    gcloud container clusters upgrade CLUSTER_NAME \
  --location=CONTROL_PLANE_LOCATION \
  --cluster-version VERSION
  --master

    VERSION deve essere la versione della patch esatta utilizzata in precedenza. Hai salvato questa versione nel passaggio precedente.

Dopo aver eseguito questo comando ed eseguito il downgrade alla versione precedente, puoi determinare perché il tuo workload non è stato eseguito correttamente sul nuovo binario. Se necessario, puoi contattare l'assistenza clienti Google Cloud fornendo log, messaggi di errore e dettagli pertinenti sull'errore di convalida riscontrato. Per saperne di più, consulta Richiedere assistenza.

Dopo aver risolto il problema, puoi eseguire di nuovo l'upgrade manuale alla nuova versione secondaria.

Completa l'upgrade in due passaggi

Durante il periodo di test, se hai verificato che i workload vengono eseguiti correttamente con il nuovo binario, puoi saltare il resto del periodo di test:

gcloud beta container clusters clusters complete-control-plane-upgrade CLUSTER_NAME  \
  --location=CONTROL_PLANE_LOCATION

Dopo aver eseguito questo comando, non potrai più eseguire il downgrade alla versione secondaria precedente.

Esegui il downgrade del control plane a una versione patch precedente

  1. Imposta un'esclusione dalla 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 \
     --location=CONTROL_PLANE_LOCATION \
     --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 per i pool di nodi standard.

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" \
    --location=CONTROL_PLANE_LOCATION

Esegui l'upgrade dei node pool

Per impostazione predefinita, i pool di nodi Standard hanno l'upgrade automatico abilitato e tutti i pool di nodi gestiti da Autopilot nei cluster Standard hanno sempre l'upgrade automatico abilitato. Gli upgrade automatici dei nodi assicurano che la versione del piano di controllo e dei nodi del cluster rimangano sincronizzate e conformi alle norme relative al disallineamento delle versioni di Kubernetes, che garantiscono che i control plane siano compatibili con i nodi fino a due versioni secondarie precedenti a quella del control plane. Ad esempio, i piani di controllo Kubernetes 1.34 sono compatibili con i nodi Kubernetes 1.32.

Best practice:

Evita di disabilitare gli upgrade automatici dei nodi con i pool di nodi Standard in modo che il cluster possa usufruire degli upgrade elencati nel paragrafo precedente.

Con gli upgrade pool di nodi GKE Standard, puoi scegliere tra tre strategie di upgrade configurabili, tra cui upgrade surge, upgrade blue-green e upgrade blue-green con scalabilità automatica (anteprima). I pool di nodi gestiti da Autopilot nei cluster Standard utilizzano sempre gli upgrade inattivi.

Per i node pool standard, scegli una strategia e utilizza i parametri per ottimizzare la strategia in modo da soddisfare al meglio le esigenze dell'ambiente del 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à sul pool di nodi.

Durante gli upgrade automatici o manuali dei nodi, i budget di interruzione dei pod (PDB) e il periodo di tolleranza per il termine 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.

Best practice:

Se un carico di lavoro in esecuzione in un pool di nodi Standard richiede maggiore flessibilità con l'arresto controllato, utilizza gli upgrade blu/verde, che forniscono impostazioni per un tempo di attesa aggiuntivo per estendere i controlli PDB oltre l'ora predefinita.

Per scoprire di più su cosa aspettarsi durante l'interruzione del nodo in generale, consulta l'argomento relativo ai pod.

L'upgrade viene completato solo quando tutti i nodi sono stati ricreati e il cluster si trova nel nuovo stato. 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 nuova versione di Kubernetes e quanto segue:

Affinché l'upgrade di un pool di nodi venga considerato completato, tutti i nodi del pool di nodi devono essere ricreati. Se un upgrade è iniziato 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 del node pool dopo un upgrade incompleto del node pool. Per determinare che l'upgrade del pool di nodi è stato completato, controlla lo stato dell'upgrade del pool di nodi 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.

Salva i dati su dischi permanenti prima di eseguire l'upgrade

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 sono in esecuzione 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 di nodo esistente, consulta la sezione Aggiunta o ridimensionamento di dischi permanenti a livello di zona nella documentazione di Compute Engine.

Upgrade manuale di un node pool

Puoi eseguire manualmente l'upgrade della versione di un pool di nodi Standard o di pool di nodi gestito da Autopilot in un cluster Standard. Puoi corrispondere alla versione del control plane o utilizzare 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 solpool di nodiol 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 richiesta e migrare il 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 questo 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 node pool a una versione compatibile con il control plane:

  • Per i pool di nodi Standard, puoi utilizzare la console Google Cloud o Google Cloud CLI.

  • Per i pool di nodi gestiti da Autopilot, puoi utilizzare solo Google Cloud CLI.

Console

Per eseguire l'upgrade di un pool di nodi Standard utilizzando la console Google Cloud , segui questi passaggi:

  1. Vai alla pagina Google Kubernetes Engine nella console Google Cloud .

    Vai a Google Kubernetes Engine

  2. Fai clic sul nome del cluster.

  3. Nella pagina Dettagli cluster, fai clic sulla scheda Nodi.

  4. Nella sezione Pool di nodi, fai clic sul nome del pool di nodi di cui vuoi eseguire l'upgrade.

  5. Fai clic su Modifica.

  6. Fai clic su Cambia in Versione nodo.

  7. Seleziona la versione richiesta dall'elenco a discesa Versione nodo, quindi fai clic su Cambia.

La modifica della versione del nodo potrebbe richiedere alcuni minuti.

gcloud

Nei comandi di questa sezione vengono utilizzate le seguenti variabili:

  • CLUSTER_NAME: il nome del cluster del node pool da aggiornare.
  • NODE_POOL_NAME: il nome del pool di nodi da aggiornare.
  • CONTROL_PLANE_LOCATION: la località (regione o zona) per il control plane, ad esempio us-central1 o us-central1-a.
  • VERSION: la versione di Kubernetes a cui vengono eseguiti l'upgrade dei nodi. Ad esempio, --cluster-version=1.34.1-gke.1293000 o cluster-version=latest.

Esegui l'upgrade di un pool di nodi:

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

Per specificare una versione diversa di GKE sui nodi, utilizza il flag facoltativo --cluster-version:

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

Per saperne di più sulla specifica delle versioni, vedi Controllo delle versioni.

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

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

Best practice:

Utilizza la strategia di upgrade dei nodi blu/verde se devi ottimizzare la mitigazione dei rischi per gli upgrade pool di nodi che influiscono sui tuoi carichi di lavoro. Con questa strategia, puoi eseguire il rollback di un upgrade in corso ai nodi originali se l'upgrade non va a buon fine.

  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.

Modificare i parametri dell'upgrade di sovraccarico

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

Controllare lo 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 \
    --location=CONTROL_PLANE_LOCATION

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 è 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 maggiori informazioni su un'operazione specifica, specifica l'ID operazione come mostrato nel seguente comando:

gcloud container operations describe OPERATION_ID \
    --location=CONTROL_PLANE_LOCATION

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 è andato a buon fine ed è stato completato parzialmente, puoi riprenderlo o eseguirne il rollback.

Controlla le 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 attuale dell'upgrade.

Esegui questo comando:

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

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.
  • CONTROL_PLANE_LOCATION: la località (regione o zona) per il control plane, ad esempio us-central1 o us-central1-a.

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 sua fase intermedia attuale. 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

Annulla l'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 saperne 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 \
      --location=CONTROL_PLANE_LOCATION

  2. Annulla l'upgrade:

    gcloud container operations cancel OPERATION_ID \
      --location=CONTROL_PLANE_LOCATION

Consulta la documentazione gcloud container operations cancel.

Riprendi l'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 \
  --location=CONTROL_PLANE_LOCATION \
  --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.
  • CONTROL_PLANE_LOCATION: la località (regione o zona) per il control plane, ad esempio us-central1 o us-central1-a.
  • VERSION: la versione di destinazione dell'upgrade del node pool annullato.

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

Esegui il 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 del pool di nodi.

Utilizza il comando rollback se un upgrade in corso è stato annullato, l'upgrade non è riuscito o è incompleto a causa di un intervallo di manutenzione che ha raggiunto il timeout. In alternativa, se vuoi specificare la versione, segui le istruzioni per eseguire il downgrade depool di nodiol.

Per scoprire di più su cosa succede quando esegui il rollback di un upgrade del pool di nodi, vedi 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 \
    --location=CONTROL_PLANE_LOCATION

Sostituisci quanto segue:

  • NODE_POOL_NAME: il nome del pool di nodi per cui eseguire il rollback dellpool di nodi#39;upgrade.
  • CLUSTER_NAME: il nome del cluster del pool di nodi per cui eseguire il rollback dell'upgrade.
  • CONTROL_PLANE_LOCATION: la località (regione o zona) per il control plane, ad esempio us-central1 o us-central1-a.

Consulta la documentazione relativa a gcloud container node-pools rollback.

Completa l'upgrade di un pool di nodi

Se utilizzi la strategia di upgrade blu/verde, puoi completare l'upgrade di un node pool 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 Completare un pool di nodi pool.

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

gcloud container node-pools complete-upgrade NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION

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.
  • CONTROL_PLANE_LOCATION: la località (regione o zona) per il control plane, ad esempio us-central1 o us-central1-a.

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

Problemi noti

Se hai configurato oggetti PodDisruptionBudget 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

Per informazioni sulla risoluzione dei problemi, vedi Risolvere i problemi relativi agli upgrade dei cluster.

Passaggi successivi