Aggiornamento manuale di un cluster o di un pool di nodi

Autopilot Standard

---

Per impostazione predefinita, gli upgrade automatici sono abilitate per i cluster Google Kubernetes Engine (GKE) e nei 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 esegui l'upgrade manuale della versione come segue:

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

Per eseguire l'upgrade di un 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, 1.24 to 1.25) o versione patch più recente (ad esempio, da 1.24.2-gke.100 a 1.24.5-gke.200). Per ulteriori 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 gli upgrade automatici possono o non possono essere eseguiti configurando periodi di manutenzione ed esclusioni.

Nota sulla terminologia: l'architettura di un cluster il piano di controllo e i nodi non eseguono necessariamente la stessa versione volte. In questo argomento, upgrade del cluster e upgrade del piano di controllo sono usati in modo intercambiabile e sono rispetto agli upgrade dei nodi.

Le nuove versioni di GKE vengono annunciate regolarmente, e potrai ricevere notifiche sulle nuove versioni con le notifiche del cluster.

Per saperne di più sulle versioni disponibili, consulta Controllo delle versioni. Per scoprire di più su vedi 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à:

• Attiva l'API Google Kubernetes Engine.
Abilita l'API Google Kubernetes Engine
• Se vuoi utilizzare Google Cloud CLI per questa attività, install e poi inizializzare con gcloud CLI. Se hai già installato gcloud CLI, scarica la versione più recente eseguendo gcloud components update.
  Nota: per gcloud CLI esistente di installazione, assicurati di impostare compute/region e compute/zone proprietà. Se imposti località predefinite, puoi evitare errori in gcloud CLI come i seguenti: 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 mediante volumi permanenti che impiegano dischi permanenti. Durante gli upgrade, i dischi permanenti vengono smontati, anziché cancellati, e la loro dati vengono "consegnati" tra i pod.

Le seguenti limitazioni riguardano i 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 disco permanente

Per scoprire 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

Viene eseguito l'upgrade del piano di controllo e dei nodi di un cluster separatamente.

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

Per ricevere notifiche di upgrade in modo proattivo, consulta l'articolo Ricevere notifiche relative ai cluster.

Limitazioni

I cluster alpha non possono essere con upgrade eseguito.

Versioni supportate

Le note di rilascio annunciano quando nuovi diventano disponibili e quando le versioni precedenti non sono più disponibili. Alle ore in qualsiasi momento, puoi elencare tutte le versioni di cluster e nodi supportate utilizzando :

gcloud container get-server-config

Se il cluster è registrato in un canale di rilascio, puoi eseguire l'upgrade a una patch versione in un altro canale di rilascio con la stessa versione secondaria del tuo dal 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 ulteriori informazioni, consulta Esecuzione delle versioni delle 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 alcune diversi scenari.

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

Non puoi eseguire il downgrade di un piano di controllo del cluster Kubernetes a un piano di controllo minore precedente completamente gestita. Ad esempio, se il tuo piano di controllo esegue GKE versione 1.25, non puoi eseguire il downgrade alla versione 1.24. Se tenti di farlo, appare 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, consigliamo di testare e qualificare gli upgrade della versione secondaria con i cluster in un ambiente di test, quando una nuova versione secondaria diventa disponibile, ma prima che la versione diventi predefinita. Questa opzione è consigliata soprattutto se il cluster potrebbe essere interessato da Modifiche nella versione secondaria successiva, ad esempio API o funzionalità ritirate che viene rimosso.

Per ridurre l'esito di un upgrade del pool di nodi non riuscito, puoi eseguire il downgrade di un pool di nodi in di una patch di release precedente o di una versione secondaria. Assicurati di non eseguire il downgrade dei nodi a una versione superiore a due versioni secondarie dietro alla versione del piano di controllo del cluster.

Upgrade del cluster

Google esegue automaticamente l'upgrade di cluster e nodi. Per un maggiore controllo su quali di upgrade automatici del cluster e dei suoi nodi, puoi registrarlo 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 una nuova versione del deployment.

Upgrade manuale del piano di controllo

Nota: non puoi eseguire l'upgrade del cluster per più di una versione secondaria per ogni volta. Ad esempio, puoi eseguire l'upgrade di un cluster dalla versione 1.25 alla 1.26, ma non direttamente da 1,25 a 1,27. Per ulteriori informazioni, consulta Posso saltare le versioni durante l'upgrade di un cluster?.

Quando avvii un upgrade del cluster, non puoi modificare per alcuni minuti, finché il piano di controllo non sarà di nuovo accessibile. Se devi 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 e carichi di lavoro già eseguiti man mano che rimangono disponibili durante gli upgrade del piano di controllo.

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

gcloud

Per vedere le versioni disponibili per il piano di controllo del tuo cluster, esegui seguente 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 la --cluster-version come nel seguente comando:

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

Sostituisci VERSION con la versione che vuoi eseguire l'upgrade del tuo cluster. Puoi utilizzare una versione specifica, ad esempio 1.18.17-gke.100 oppure puoi utilizzare un alias di versione, come latest. Per maggiori informazioni consulta la sezione su come specificare la versione del cluster.

Nota: se il cluster è registrato in un canale di rilascio, la VERSION deve essere una versione secondaria valida per la release un 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 propri nodi. Per impostazione predefinita, i nodi standard create utilizzando la console Google Cloud hanno l'upgrade automatico abilitato, quindi questo automaticamente. Autopilot esegue sempre l'upgrade dei nodi automaticamente.

Downgrade dei cluster in corso...

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

1. Impostare un'esclusione per la manutenzione prima di eseguire il downgrade per impedire l'upgrade automatico di GKE per il piano di controllo dopo il downgrade.

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

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

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

Disabilitazione degli upgrade automatici dei cluster

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

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

Upgrade dei pool di nodi

Per impostazione predefinita, i nodi di un cluster upgrade automatico è attivata ed è consigliabile non disattivare . Nodo gli upgrade automatici assicurano che il piano di controllo e la versione dei nodi del tuo cluster restino sincronizzato e conforme al disallineamento delle versioni di Kubernetes , che garantisce che sono compatibili con nodi fino a due versioni secondarie precedenti al dal piano di controllo. Ad esempio, i piani di controllo Kubernetes 1.29 sono compatibili di Kubernetes 1.27.

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

Scegli una strategia e usa i parametri per mettere a punto la strategia in base alle tue esigenze in base alle esigenze dell'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. Questo è in modo simile ad altri eventi che ricreano il nodo, come l'abilitazione o la disabilitazione di un sul pool di nodi.

Nota: durante gli upgrade automatici o manuali dei nodi, BudgetDisruptionBudget (PDB) e periodo di tolleranza per la chiusura dei pod vengono rispettati per un massimo di 1 ora. Se i pod in esecuzione su un nodo non possono sui nuovi nodi entro un'ora, viene avviato l'upgrade, comunque. Se un carico di lavoro richiede una maggiore flessibilità con una terminazione controllata, consigliamo utilizzando gli upgrade blu/verde, che forniscono impostazioni per un tempo di sospensione aggiuntivo per estendere i controlli PDB oltre Valore predefinito: 1 ora. Per ulteriori informazioni su cosa aspettarsi durante la terminazione del nodo in generale, vedi l'argomento su Pod.

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

Le nuove istanze dei nodi eseguono la versione Kubernetes desiderata, oltre a:

• 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 affinché corrisponda alla versione del controllo o a una versione precedente che sia 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 aggiunti a singoli nodi utilizzando kubectl. Per evitare che questo accada, applica etichette ai pool di nodi .

Nota: l'upgrade di un pool di nodi potrebbe interrompere i carichi di lavoro in esecuzione in quel pool. A puoi evitare questo problema, puoi creare un nuovo pool di nodi con la versione che preferisci ed eseguire la migrazione 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 con errori, il gruppo di istanze non si sincronizza. Per aggirare il problema, controlla innanzitutto usando il comando kubectl get ing. Se il gruppo di istanze non è sincronizzato, puoi aggirare il problema applicando nuovamente il manifest utilizzato per creare in entrata.

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

gcloud

Nei comandi di questa sezione vengono utilizzate le seguenti variabili:

• CLUSTER_NAME: il nome del cluster del nodo di cui eseguire l'upgrade.
• NODE_POOL_NAME: il nome del pool di nodi da utilizzare con upgrade eseguito.
• VERSION: la versione 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 flag facoltativo --cluster-version:

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

Per ulteriori informazioni su come specificare le versioni, consulta la sezione Controllo delle versioni.

Per ulteriori informazioni, consulta gcloud container clusters upgrade.

Console

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

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

   Vai a Google Kubernetes Engine

2. Accanto al cluster da 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 vuoi eseguire l'upgrade.

5. Fai clic su Modifica.

6. Fai clic su Cambia in Versione nodo.

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

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

Downgrade dei pool di nodi in corso

Puoi eseguire il downgrade di un pool di nodi, ad esempio, per mitigare upgrade del pool di nodi non riuscito. Esamina il limitazioni prima di eseguire il downgrade di un pool di nodi.

Nota: consigliamo la strategia di upgrade del nodo blu/verde se necessario ottimizzare per la mitigazione del rischio per gli upgrade del pool di nodi che influiscono sui carichi di lavoro. Con questa strategia, puoi eseguire il rollback un upgrade in corso ai nodi originali se l'upgrade non va a buon fine.

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

Modifica dei parametri di upgrade di sovraccarico

Per saperne di più su come modificare i parametri di upgrade di sovraccarico, consulta Configurare gli upgrade di sovraccarico.

Controllo dello stato di 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 sono assegnati un ID operazione, un tipo di operazione e le ore di inizio e di fine, il cluster di destinazione e lo stato. L'elenco appare simile a nell'esempio seguente:

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 in corso...

Puoi vedere i dettagli sulla strategia di upgrade dei nodi utilizzata per i tuoi pool di nodi utilizzando il comando gcloud container node-pools describe. Per gli upgrade blu/verde, il comando restituisce anche 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. Nell'esempio che segue mostra l'output se stai utilizzando 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 corrente. L'esempio seguente mostra il seguente 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 di un upgrade del pool di nodi in corso...

Puoi annullare un upgrade in qualsiasi momento. Per saperne di più su cosa succede quando per annullare un upgrade di incremento, consulta Annullare un upgrade di sovraccarico. Per scoprire di più su cosa succede quando annulli uno stato eseguire l'upgrade, 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 le gcloud container operations cancel documentazione.

Ripresa dell'upgrade di un pool di nodi in corso...

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

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

Per saperne di più su cosa succede quando riprendi un upgrade, consulta Riprendi un upgrade di sovraccarico 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: il 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 del nodo annullato upgrade della piscina.

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

Rollback di un upgrade del pool di nodi in corso

Puoi eseguire il rollback di un pool di nodi per eseguire il downgrade dei nodi di cui è stato eseguito l'upgrade al pool originale precedente all'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 timeout. 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 eseguito l'upgrade. Devi eseguire il downgrade. il pool di nodi se vuoi che i nodi utilizzino la versione precedente.

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

Consulta le gcloud container node-pools rollback documentazione.

Completare l'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 una l'upgrade del pool durante la fase di sospensione, di saltare il resto del tempo di sospensione.

Per scoprire come funziona l'upgrade di un pool di nodi, consulta Completare l'upgrade del pool di nodi.

Per completare un upgrade quando viene utilizzato l'upgrade blu/verde strategia, 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: il nome del cluster del nodo per il quale vuoi completare l'upgrade.

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

Problemi noti

Se hai configurato PodDisruptionBudget di oggetti che non riesci a consentire eventuali interruzioni aggiuntive, l'upgrade dei nodi potrebbe non riuscire della versione del piano di controllo dopo ripetuti tentativi. Per evitare questo errore, ti consigliamo di fare lo scale up di Deployment o HorizontalPodAutoscaler per consenti lo svuotamento del nodo rispettando PodDisruptionBudget configurazione.

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, forza l'upgrade dei nodi. Tuttavia, l'upgrade richiede un'ora in più per ogni nodo nello spazio dei nomi istio-system che viola le PodDisruptionBudget.

Risoluzione dei problemi

Utilizzo della CPU dei nodi superiore al previsto

Potresti riscontrare un problema per cui alcuni nodi utilizzano una CPU più elevata rispetto a come previsto dai pod in esecuzione.

Questo può accadere se sul cluster o sui nodi non è in esecuzione un versione supportata. Leggi le note di rilascio per assicurarti che le versioni che stai utilizzando siano disponibili e supportate. Puoi anche esegui 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.