Aggiornamento manuale di un cluster o di un pool di nodi

Autopilot Standard

---

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 piano di controllo o i nodi di un cluster GKE. Puoi eseguire l'upgrade manuale della versione nel seguente modo:

• Autopilot: esegui l'upgrade della versione del piano di controllo.
• Standard: esegui l'upgrade della versione del piano di controllo e della versione del pool di nodi.

Per eseguire l'upgrade di un cluster, GKE aggiorna la versione del piano di controllo e dei nodi in esecuzione. Viene eseguito l'upgrade dei cluster 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 saperne di più, vedi Controllo delle versioni e assistenza di GKE.

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

Nota sulla terminologia: il piano di controllo e i nodi di un cluster non eseguono necessariamente la stessa versione in ogni momento. In questo argomento, l'upgrade del cluster e l'upgrade del piano di controllo sono utilizzati in modo intercambiabile e sono distinti dagli upgrade dei nodi.

Le nuove versioni di GKE vengono annunciate regolarmente e puoi ricevere avvisi sulle nuove versioni a cui è possibile eseguire l'upgrade di un cluster specifico mediante le notifiche del cluster.

Per scoprire di più sulle versioni disponibili, consulta 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 attività:

• Abilita l'API Google Kubernetes Engine.
Abilita l'API Google Kubernetes Engine
• Se vuoi utilizzare Google Cloud CLI per questa attività, installa e initialize gcloud CLI. Se hai già installato gcloud CLI, scarica la versione più recente eseguendo gcloud components update.
  Nota: per le installazioni esistenti dell'interfaccia a riga di comando gcloud, assicurati di impostare le proprietà compute/region e compute/zone. Impostando le località predefinite, puoi evitare errori nellgcloud CLI come segue: One of [--zone, --region] must be supplied: Please specify location.

Salva i dati su dischi permanenti

Prima di eseguire l'upgrade di un pool di nodi, devi assicurarti che tutti i dati che vuoi conservare siano archiviati 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.

I dischi permanenti sono soggetti alle seguenti restrizioni:

• 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 informazioni su come aggiungere un disco permanente a un'istanza di nodo esistente, consulta Aggiunta o ridimensionamento di dischi permanenti a livello di zona nella documentazione di Compute Engine.

Informazioni sull'upgrade

L'upgrade del piano di controllo e dei nodi di un cluster viene eseguito separatamente.

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

Per ricevere proattivamente le notifiche relative agli upgrade, consulta Ricevere notifiche relative al cluster.

Limitazioni

Impossibile 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 di cluster e nodi supportate utilizzando questo comando:

gcloud container get-server-config

Se il 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 piano di controllo. Ad esempio, puoi eseguire l'upgrade del cluster dalla versione 1.21.12-gke.1700 nel canale regolare a 1.21.13-gke.900 nel canale rapido. Per saperne di più, consulta Esecuzione di versioni patch da un canale più recente. Tutti i cluster Autopilot sono registrati in un canale di rilascio.

Limitazioni del downgrade

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

Per limitare un upgrade del piano di controllo del cluster non riuscito, puoi eseguire il downgrade del piano di controllo a una release patch precedente se si tratta di una release patch precedente all'interno della stessa versione secondaria. Ad esempio, se il piano di controllo del cluster esegue GKE 1.25.3-gke.400, puoi eseguire il downgrade del piano di controllo a 1.25.2-gke.100, se quella versione è ancora disponibile.

Non puoi eseguire il downgrade di un piano di controllo di un cluster Kubernetes a una versione secondaria precedente. Ad esempio, se il tuo piano di controllo esegue GKE versione 1.25, non puoi eseguire il downgrade alla versione 1.24. Se provi a 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 piano di controllo di un cluster, quindi 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 la versione diventi predefinita. Ciò è particolarmente consigliato se il cluster potrebbe essere interessato da cambiamenti significativi nella versione secondaria successiva, ad esempio la rimozione di API o funzionalità deprecate.

Per limitare un upgrade del pool di nodi non riuscito, puoi eseguire il downgrade di un pool di nodi a una release patch precedente o a una versione secondaria. Assicurati di non eseguire il downgrade dei nodi a una versione che contenga più di due versioni secondarie rispetto alla versione del piano di controllo del cluster.

Upgrade del cluster

Google esegue automaticamente l'upgrade 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 saperne di più sulla gestione della versione GKE del cluster, consulta Upgrade.

Puoi avviare un upgrade manuale in qualsiasi momento dopo che una nuova versione diventa disponibile.

Upgrade manuale del piano di controllo

Nota: non puoi eseguire l'upgrade del cluster più di una versione secondaria alla volta. Ad esempio, puoi eseguire l'upgrade di un cluster dalla versione 1.25 alla 1.26, ma non direttamente dalla versione 1.25 alla 1.27. Per maggiori informazioni, consulta Posso saltare le versioni durante un upgrade del cluster?.

Quando avvii un upgrade del cluster, non puoi modificare la configurazione per diversi minuti finché il piano di controllo non è di nuovo accessibile. Se hai bisogno di evitare tempi di inattività durante gli upgrade del piano di controllo, valuta la possibilità di utilizzare un cluster Autopilot o un cluster Standard a livello di regione. Questa operazione non influisce sulla disponibilità dei nodi worker su cui vengono eseguiti i carichi di lavoro perché rimangono disponibili durante gli upgrade del piano di controllo.

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

gcloud

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

gcloud container get-server-config

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

gcloud container clusters upgrade CLUSTER_NAME --master

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

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

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

Nota: se il cluster è registrato in un canale di rilascio, VERSION deve essere una versione secondaria valida per il canale di rilascio o una versione patch valida in un canale di rilascio più recente. Tutti i cluster Autopilot sono registrati in un canale di rilascio.

Console

Per aggiornare manualmente il piano di controllo del cluster, 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 che ti interessa.

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

4. Seleziona la versione che ti interessa e fai clic su Salva modifiche.

Dopo aver eseguito l'upgrade di un piano di controllo Standard, puoi eseguire l'upgrade dei relativi nodi. Per impostazione predefinita, per i nodi standard creati utilizzando la console Google Cloud è abilitato l'upgrade automatico, che avviene automaticamente. Autopilot esegue sempre l'upgrade dei nodi in modo automatico.

Eseguire il downgrade dei cluster

Nota: assicurati di comprendere le limitazioni prima di tentare di eseguire il downgrade di un cluster.

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

2. Esegui il downgrade del piano di controllo del cluster a una versione precedente della patch:

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

Nota: se il cluster è iscritto a un canale di rilascio, VERSION deve essere una versione patch disponibile per il canale di rilascio. Tutti i cluster Autopilot sono registrati in un canale di rilascio.

Disabilitazione degli upgrade automatici dei cluster

La sicurezza dell'infrastruttura è una priorità elevata per GKE, per cui l'upgrade dei piani di controllo viene eseguito regolarmente e non può essere disabilitato. Tuttavia, puoi applicare periodi di manutenzione ed esclusioni per sospendere temporaneamente gli upgrade di piani di controllo e nodi.

Sebbene sia sconsigliato, puoi disabilitare l'upgrade automatico dei nodi.

Upgrade dei pool di nodi

Per impostazione predefinita, l'upgrade automatico è abilitato per i nodi di un cluster e ti consigliamo di non disabilitarlo. Gli upgrade automatici dei nodi assicurano che il piano di controllo e la versione dei nodi del cluster rimangano sincronizzati e conformi al criterio per il disallineamento delle versioni di Kubernetes, garantendo che i piani di controllo siano compatibili con nodi fino a due versioni secondarie precedenti al piano di controllo. Ad esempio, i piani di controllo 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 gli upgrade di picco e gli upgrade blu/verdi.

Scegli una strategia e utilizza i parametri per ottimizzarla in base alle esigenze del tuo ambiente cluster.

Durante l'upgrade di un nodo, GKE smette di pianificare nuovi pod e tenta di pianificare i pod in esecuzione su altri nodi. È simile ad altri eventi che ricreano il nodo, come l'abilitazione o la disattivazione di una funzionalità nel pool di nodi.

Nota: durante gli upgrade automatici o manuali dei nodi, i podDisruptionBudget (PDB) e il periodo di tolleranza per la terminazione dei pod vengono rispettati per un massimo di un'ora. Se non è possibile pianificare i pod in esecuzione su un nodo su nuovi nodi entro un'ora, l'upgrade viene avviato comunque. Se un carico di lavoro richiede una maggiore flessibilità con una terminazione controllata, ti consigliamo di utilizzare gli upgrade blu/verde, che forniscono impostazioni per tempi di attesa aggiuntivi al fine di estendere i controlli PDB oltre il valore predefinito di un'ora. Per ulteriori informazioni su cosa aspettarsi durante la terminazione dei nodi in generale, consulta l'argomento relativo ai pod.

L'upgrade è completo solo quando tutti i nodi sono stati ricreati e il cluster si trova nello stato desiderato. Quando un nodo di cui è stato eseguito l'upgrade di recente si registra con il piano di controllo, GKE lo contrassegna come pianificabile.

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

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

Upgrade manuale di un pool di nodi

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

Quando esegui manualmente l'upgrade di un pool di nodi, GKE rimuove eventuali etichette aggiunte a singoli nodi utilizzando kubectl. Per evitare che questo accada, applica etichette ai pool di nodi.

Nota: l'upgrade di un pool di nodi può interrompere i carichi di lavoro in esecuzione in quel pool di nodi. Per evitarlo, puoi creare un nuovo pool di nodi con la versione desiderata ed eseguire la migrazione del carico di lavoro. Dopo la migrazione, puoi eliminare il vecchio pool di nodi.

Nota: se esegui l'upgrade di un pool di nodi con una risorsa 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 applicando di nuovo il manifest utilizzato per creare il traffico in entrata.

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

gcloud

Nei comandi di questa sezione vengono utilizzate le seguenti variabili:

• CLUSTER_NAME: nome del cluster del pool di nodi di cui eseguire l'upgrade.
• NODE_POOL_NAME: il nome del pool di nodi di cui eseguire l'upgrade.
• VERSION: la versione di Kubernetes a cui viene eseguito l'upgrade dei nodi. Ad esempio, --cluster-version=1.7.2 o cluster-version=latest.

Esegui l'upgrade di un pool di nodi:

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

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 \
  --cluster-version VERSION

Per saperne di più su come specificare le versioni, consulta Controllo delle versioni.

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

Console

Per eseguire l'upgrade di un pool di nodi 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. Accanto al cluster che vuoi modificare, fai clic su Azioni e poi su Modifica.

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 che ti interessa dall'elenco a discesa Versione nodo, poi fai clic su Cambia.

Nota: la modifica della versione del nodo potrebbe richiedere diversi minuti.

Eseguire il downgrade dei pool di nodi

Puoi eseguire il downgrade di un pool di nodi, ad esempio, per limitare l'upgrade di un pool di nodi non riuscito. Esamina le limitazioni prima di eseguire il downgrade di un pool di nodi.

Nota: ti consigliamo la strategia di upgrade dei nodi blu/verde se devi ottimizzare per la mitigazione del rischio degli upgrade del pool di nodi che influiscono sui 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 di 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 riportate per eseguire l'upgrade manuale di un pool di nodi.

Modifica dei parametri di upgrade di incremento

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

Controllo dello stato dell'upgrade del pool di nodi in corso...

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

Visualizza un elenco di tutte le operazioni in esecuzione e completate nel cluster:

gcloud container operations list

A ogni operazione vengono assegnati un ID operazione, un tipo di operazione, l'ora di inizio e di fine, il cluster di destinazione e lo 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 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

Controllo delle impostazioni di upgrade del pool di nodi

Puoi visualizzare i dettagli sulla strategia di upgrade dei nodi utilizzata per i pool di nodi 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

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 attuali. 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 i dettagli sulle impostazioni di upgrade blu/verde e sulla sua fase intermedia attuale. L'esempio seguente mostra il possibile aspetto:

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 saperne di più su cosa succede quando annulli un upgrade di incremento, consulta Annullare un upgrade di incremento. Per scoprire di più su cosa succede quando annulli un upgrade blu/verde, consulta Annullare un upgrade blu/verde.

1. Ottieni l'ID operazione dell'upgrade:

   gcloud container operations list
   

2. Annulla l'upgrade:

   gcloud container operations cancel OPERATION_ID
   

Consulta la documentazione di gcloud container operations cancel.

Ripresa dell'upgrade di un pool di nodi

Puoi riprendere un upgrade riavviando manualmente l'upgrade, specificando la versione di destinazione dell'upgrade originale.

Ad esempio, se hai messo in pausa un upgrade continuo alla versione 1.23.1-gke.100, potresti riprendere l'upgrade annullato avviando di nuovo lo stesso upgrade sul pool di nodi con il targeting della versione 1.23.1-gke.100.

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 comando seguente:

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

Sostituisci quanto segue:

• NODE_POOL_NAME: nome del pool di nodi per il quale vuoi riprendere l'upgrade del pool di nodi.
• 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 di 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 al loro stato originale prima dell'avvio 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 periodo di manutenzione in scadenza. In alternativa, se vuoi specificare la versione, segui le istruzioni per eseguire il downgrade del pool di nodi.

Nota: non puoi eseguire il rollback dei pool di nodi una volta completato l'upgrade. Devi eseguire il downgrade del pool di nodi se vuoi che i nodi utilizzino la versione precedente.

Per scoprire di più su cosa succede quando esegui il rollback di un upgrade di un pool di nodi, consulta Eseguire il rollback di un upgrade di picco 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: nome del pool di nodi per cui eseguire il rollback dell'upgrade del pool di nodi.
• CLUSTER_NAME: nome del cluster del pool di nodi per cui eseguire il rollback dell'upgrade.

Consulta la documentazione di gcloud container node-pools rollback.

Completamento dell'upgrade di un pool di nodi

Avviso: l'utilizzo del comando complete-upgrade è possibile solo con gli upgrade blu/verde.

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

Per informazioni su come funziona il completamento dell'upgrade di un pool di nodi, vedi Eseguire l'upgrade del pool di nodi.

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 il quale vuoi completare l'upgrade.
• CLUSTER_NAME: nome del cluster del pool di nodi per il quale vuoi completare l'upgrade.

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

Problemi noti

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 pur rispettando la configurazione di 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}'

Anche se il problema potrebbe verificarsi con gli upgrade automatici, il processo di upgrade automatico forza l'upgrade dei nodi. Tuttavia, l'upgrade richiede un'ora aggiuntiva per ogni nodo nello spazio dei nomi istio-system che viola PodDisruptionBudget.

Risoluzione dei problemi

Utilizzo della CPU dei nodi superiore al previsto

Potresti riscontrare un problema per cui alcuni nodi utilizzano un utilizzo della CPU maggiore rispetto a quello previsto dai pod in esecuzione.

Questo 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 di cluster e nodi supportate:

gcloud container get-server-config

Passaggi successivi

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