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 manualmente l'upgrade 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 della versione del node pool.
Per eseguire l'upgrade di un cluster, GKE aggiorna la versione in cui vengono eseguiti il piano di controllo e i nodi. 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 ulteriori informazioni, consulta 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 gli upgrade automatici configurando periodi di manutenzione ed esclusioni.
Le nuove versioni di GKE vengono annunciate regolarmente e puoi ricevere una notifica relativa alle nuove versioni disponibili per ogni cluster specifico con le notifiche del cluster. Per trovare destinazioni di upgrade automatico specifiche per i cluster, ottieni informazioni sugli upgrade di un cluster (anteprima).
Per informazioni 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 operazioni:
- Attiva l'API Google Kubernetes Engine. Attiva l'API Google Kubernetes Engine
- Se vuoi utilizzare Google Cloud CLI per questa attività,
installa e poi
inizializza gcloud CLI. Se hai già installato gcloud CLI, ottieni la versione più recente eseguendo
gcloud components update.
Salvare 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 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.
Le seguenti limitazioni riguardano i dischi permanenti:
- I nodi su cui sono in esecuzione i pod devono essere VM 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 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 su un canale di rilascio.
Per ricevere proattivamente le notifiche di upgrade, consulta Ricevere notifiche del cluster.
Limitazioni
Non è possibile eseguire l'upgrade dei cluster alpha.
Versioni supportate
Le note di rilascio annunciano quando le nuove versioni diventano disponibili e quando quelle precedenti non sono più disponibili. Puoi elencare tutte le versioni di cluster e nodi supportate in qualsiasi momento 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 con patch in un altro canale di rilascio con la stessa versione secondaria del tuo control plane. Ad esempio, puoi eseguire l'upgrade del cluster dalla versione 1.21.12-gke.1700 nel canale regolare alla versione 1.21.13-gke.900 nel canale rapido. Per saperne di più, consulta Eseguire le versioni delle 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 precedente.
Per mitigare un upgrade del piano di controllo del cluster non riuscito, puoi eseguire il downgrade del piano di controllo a una release di patch precedente se la versione è una release di 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 alla versione 1.25.2-gke.100, se questa versione è ancora disponibile.
Non puoi eseguire il downgrade del piano di controllo di un cluster Kubernetes a una versione minore precedente. Ad esempio, se il tuo piano di controllo esegue GKE nella 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 minore del piano di controllo di un cluster, pertanto ti consigliamo di testare e qualificare gli upgrade delle versioni minori con i cluster in un ambiente di test quando una nuova versione minore viene resa disponibile, ma prima che diventi predefinita. Questo è particolarmente consigliato se il tuo cluster potrebbe essere interessato da modifiche significative nella versione secondaria successiva, ad esempio la rimozione di API o funzionalità ritirate.
Per ridurre al minimo i problemi di un upgrade pool di nodi non riuscito, puoi eseguire il downgrade di un pool di nodi a una release di patch o a una versione minore precedente. Assicurati di non eseguire il downgrade dei nodi a una versione che è più di due versioni secondarie precedenti alla versione del piano di controllo 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 registrarli 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 Upgrade.
Puoi avviare un upgrade manuale in qualsiasi momento dopo che una nuova versione diventa disponibile.
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 i tempi di riposo durante gli upgrade del piano di controllo, valuta la possibilità di utilizzare un cluster Autopilot o un cluster Standard a livello di area geografica. Questa operazione non influisce sulla disponibilità dei nodi worker su cui vengono eseguiti i carichi di lavoro, poiché 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 il seguente comando:
gcloud container clusters upgrade CLUSTER_NAME --master
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 \
--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.
Console
Per aggiornare manualmente il piano di controllo del cluster, svolgi i seguenti passaggi:
Vai alla pagina Google Kubernetes Engine nella console Google Cloud.
Fai clic sul nome del cluster che ti interessa.
In Impostazioni di base del cluster, fai clic su edit Upgrade disponibile accanto a Versione.
Seleziona la versione che ti interessa e fai clic su Salva modifiche.
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 questo avviene automaticamente. Autopilot esegue sempre l'upgrade dei nodi automaticamente.
Downgrade dei cluster
- Imposta un'esclusione della manutenzione prima del downgrade per impedire a GKE di eseguire automaticamente l'upgrade del piano di controllo dopo il downgrade.
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à elevata per GKE e, di conseguenza, viene eseguito l'upgrade dei piani di controllo 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.
Sebbene non sia consigliato, puoi disattivare l'upgrade automatico dei nodi.
Controllare la cronologia degli upgrade del control plane recenti
Per uno snapshot della cronologia degli upgrade automatici recenti di un cluster, ottieni informazioni sugli upgrade di un cluster (anteprima).
In alternativa, puoi elencare le operazioni recenti per vedere quando è stato eseguito l'upgrade del piano di controllo:
gcloud container operations list --filter="TYPE:UPGRADE_MASTER AND TARGET:CLUSTER_NAME"
Sostituisci CLUSTER_NAME con il nome del cluster.
Eseguire l'upgrade dei node pool
Per impostazione predefinita, i nodi di un cluster hanno attivato l'upgrade automatico. Gli upgrade automatici dei nodi assicurano che la versione del piano di controllo e del nodo del cluster rimangano sincronizzate e in conformità con le norme relative al disallineamento delle versioni di Kubernetes, che garantiscono che i piani di controllo siano compatibili con i nodi fino a due versioni secondarie precedenti rispetto al piano di controllo. Ad esempio, i piani di controllo Kubernetes 1.29 sono compatibili con i nodi Kubernetes 1.27.
Evita di disattivare gli upgrade automatici dei nodi in modo che il cluster possa usufruire degli upgrade elencati nel paragrafo precedente.
Con gli upgrade dei pool di nodi GKE, puoi scegliere tra due strategie di upgrade configurabili, ovvero gli upgrade di sovraccarico e gli upgrade blue-green.
Scegli una strategia e utilizza i parametri per ottimizzarla in base alle esigenze del tuo ambiente cluster.
Come funzionano gli upgrade dei nodi
Durante l'upgrade di un nodo, GKE smette di pianificare nuovi pod su di esso e tenta di pianificare i pod in esecuzione su altri nodi. È simile ad altri eventi che ricreano il nodo, ad esempio l'attivazione o la disattivazione di una funzionalità nel pool di nodi.
Durante gli upgrade dei nodi automatici o manuali,
PodDisruptionBudget (PDB)
e il periodo di tolleranza per l'interruzione dei pod
vengono rispettati per un massimo di 1 ora. Se dopo un'ora non è possibile pianificare i pod in esecuzione sul nodo su nuovi nodi, GKE avvia comunque l'upgrade. Questo comportamento si applica anche se configuri i PDB in modo da avere sempre tutte le repliche disponibili impostando il campo maxUnavailable su 0 o 0% oppure 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 l'eliminazione del nodo possa avvenire.
Se un carico di lavoro richiede una maggiore flessibilità con l'interruzione controllata, utilizza gli upgrade blue-green che forniscono impostazioni per un tempo di attesa aggiuntivo per estendere i controlli PDB oltre l'ora predefinita.
Per scoprire di più su cosa aspettarti durante l'interruzione del nodo in generale, consulta l'argomento sui pod.
L'upgrade è completo 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 piano di controllo, GKE lo contrassegna come pianificabile.
Le nuove istanze di nodi eseguono la versione di Kubernetes desiderata, nonché:
Upgrade manuale di un node pool
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 l'upgrade manuale di più pool di nodi in parallelo, mentre GKE esegue l'upgrade automatico di un solo pool di nodi alla volta.
Quando esegui l'upgrade manuale di un pool di nodi, GKE rimuove le etichette aggiunte 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 presenti le seguenti condizioni:
- L'upgrade di un pool di nodi potrebbe interrompere i workload 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.
- Se esegui l'upgrade di un pool di nodi con un Ingress in uno stato di errore, il gruppo di istanze non si sincronizza. 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 il Ingress.
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: il nome del cluster del node pool 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.2ocluster-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 parametro facoltativo --cluster-version:
gcloud container clusters upgrade CLUSTER_NAME \
--node-pool=NODE_POOL_NAME \
--cluster-version VERSION
Per ulteriori informazioni sulla specifica delle versioni, vedi 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, svolgi i seguenti passaggi:
Vai alla pagina Google Kubernetes Engine nella console Google Cloud.
Accanto al cluster che vuoi modificare, fai clic su more_vert Azioni e poi su edit Modifica.
Nella pagina Dettagli cluster, fai clic sulla scheda Nodi.
Nella sezione Pool di nodi, fai clic sul nome del pool di nodi di cui vuoi eseguire l'upgrade.
Fai clic su edit Modifica.
Fai clic su Cambia in Versione nodo.
Seleziona la versione che ti interessa dall'elenco a discesa Versione nodo, quindi fai clic su Cambia.
La modifica della versione del nodo potrebbe richiedere alcuni minuti.
Downgrade dei node pool
Puoi eseguire il downgrade di un pool di nodi, ad esempio per attenuare un upgrade pool di nodi non riuscito. Esamina le limitazioni prima di eseguire il downgrade di un pool di nodi.
Utilizza la strategia di upgrade dei nodi blu-verde se devi ottimizzare per la mitigazione dei rischi per gli upgrade dei 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.
- Imposta un'esclusione di manutenzione per il cluster per impedire a GKE di eseguire l'upgrade automatico del pool di nodi dopo il downgrade.
- Per eseguire il downgrade di un pool di nodi, specifica una versione precedente seguendo le istruzioni per eseguire l'upgrade manuale di un pool di nodi.
Modificare i 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:
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 sarà simile all'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 visualizzare 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 tuoi node pool utilizzando il comando gcloud container node-pools
describe. Per gli upgrade blu/verdi, 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 mostrerà 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 dell'upgrade blu/verde e sulla relativa fase intermedia corrente. L'esempio seguente mostra un esempio di come potrebbe essere:
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
Puoi annullare un upgrade in qualsiasi momento. Per scoprire di più su cosa succede quando annulli un upgrade di sovraccarico, consulta Annullare un upgrade di sovraccarico. Per scoprire di più su cosa succede quando annulli un upgrade blu/verde, consulta Annullare un upgrade blu/verde.
Recupera l'ID operazione dell'upgrade:
gcloud container operations listAnnullare l'upgrade:
gcloud container operations cancel OPERATION_ID
Consulta la documentazione di gcloud container operations cancel.
Riavviare un upgrade del pool di nodi
Puoi riprendere un upgrade avviandolo manualmente nuovamente, specificando la versione di destinazione dell'upgrade originale.
Ad esempio, se 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 node pool annullato.
Per saperne di più, consulta la documentazione di gcloud container clusters upgrade.
Eseguire il rollback di un upgrade del 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, se l'upgrade non è riuscito o se è incompleto a causa del timeout di una finestra di manutenzione. In alternativa, se vuoi specificare la versione, segui le istruzioni per 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 il seguente 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 del pool di nodi.CLUSTER_NAME: il nome del cluster del pool di nodi per cui eseguire il rollback dell'upgrade.
Consulta la documentazione di gcloud container node-pools rollback.
Completare un upgrade del pool di nodi
Se utilizzi la strategia di upgrade blu/verde, puoi completare un upgrade del pool di nodi durante la fase di assorbimento, omettendo il resto del tempo di assorbimento.
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 blue-green, esegui il seguente 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 pool di nodi per cui vuoi completare l'upgrade.
Consulta la documentazione di gcloud container node-pools complete-upgrade.
Problemi noti
Se hai configurato oggetti PodDisruptionBudget che non sono in grado di consentire ulteriori interruzioni, l'upgrade dei nodi alla versione del control plane potrebbe non riuscire dopo ripetuti tentativi. Per evitare questo errore, consigliamo di eseguire l'upgrade di Deployment o HorizontalPodAutoscaler per consentire lo svuotamento del nodo rispettando al contempo 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}'
Sebbene gli upgrade automatici potrebbero 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
Ripristinare o rollback un upgrade incompleto del pool di nodi
Se GKE non ha completato un upgrade del pool di nodi e i nodi sono stati sottoposti a upgrade parziale alla nuova versione, puoi riprendere o ripristinare l'upgrade. Questo è importante per gli upgrade pool di nodi che utilizzano la strategia di upgrade dei nodi, gli upgrade per picchi o gli upgrade blu/verde.
Potresti avere un pool di nodi di cui è stato eseguito l'upgrade parziale per uno dei seguenti motivi:
- Hai annullato l'upgrade del pool di nodi.
- L'upgrade non è riuscito a causa di un problema imprevisto.
- L'upgrade non è stato completato a causa del timeout del periodo di manutenzione.
Segui le istruzioni per ripristinare o eseguire il rollback dell'upgrade in modo che tutti i nodi del pool di nodi eseguano una versione coerente. Se non fai nulla, GKE 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 in cui alcuni nodi utilizzano un utilizzo della CPU superiore a quello previsto dai pod in esecuzione.
Questo può verificarsi se nel cluster o nei nodi non è in esecuzione una versione supportata. Consulta le note di rilascio per assicurarti che le versioni in uso siano disponibili e supportate. Puoi anche eseguire il seguente comando per elencare tutte le versioni del cluster e dei nodi supportate:
gcloud container get-server-config
Passaggi successivi
- Scopri di più sull'architettura del cluster.
- Scopri di più sui canali di rilascio.