Upgrade di cluster standard

Questa pagina descrive il funzionamento degli upgrade automatici e manuali nei cluster Google Kubernetes Engine (GKE) Standard, inclusi i link per ulteriori informazioni sulle attività e sulle impostazioni correlate. Puoi utilizzare queste informazioni per mantenere i cluster aggiornati per stabilità e sicurezza con interruzioni minime dei carichi di lavoro.

Per informazioni su come funzionano gli upgrade dei cluster per Autopilot, consulta Upgrade dei cluster Autopilot.

Come funzionano gli upgrade di cluster e pool di nodi

Questa sezione illustra cosa succede nel cluster durante gli upgrade automatici o manuali. Per gli upgrade automatici, GKE avvia l'upgrade automatico. GKE osserva gli upgrade automatici e manuali in tutti i cluster GKE e interviene in caso di problemi.

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.

Se registri il cluster in un canale di rilascio, i nodi eseguono la stessa versione di GKE del cluster, tranne durante un breve periodo (in genere alcuni giorni, a seconda della release attuale) tra il completamento dell'upgrade del piano di controllo del cluster e l'avvio dell'upgrade del pool di nodi, oppure se è stato eseguito manualmente l'upgrade del piano di controllo. Consulta le note di rilascio per ulteriori informazioni.

Upgrade dei cluster

Questa sezione illustra cosa aspettarsi quando GKE esegue l'upgrade automatico del cluster o quando avvii un upgrade manuale.

  • I cluster a livello di zona hanno un solo piano di controllo. Durante l'upgrade, i carichi di lavoro continuano a essere eseguiti, ma non puoi eseguire il deployment di nuovi carichi di lavoro, modificare quelli esistenti o apportare altre modifiche alla configurazione del cluster fino al completamento dell'upgrade.

  • I cluster a livello di regionale hanno più repliche del piano di controllo e viene eseguito l'upgrade di una sola replica alla volta, in un ordine non definito. Durante l'upgrade, il cluster rimane ad alta disponibilità e ogni replica del piano di controllo non è disponibile solo durante l'upgrade.

Se configuri un periodo di manutenzione o un'esclusione, se possibile viene rispettata.

Upgrade del pool di nodi

Questa sezione illustra cosa aspettarsi quando GKE esegue automaticamente l'upgrade del pool di nodi o avvii un upgrade manuale del pool di nodi.

GKE esegue automaticamente l'upgrade di un pool di nodi alla volta in un cluster. In alternativa, puoi eseguire manualmente l'upgrade di uno o più pool di nodi in parallelo. Per impostazione predefinita, l'upgrade dei nodi all'interno di un pool di nodi viene eseguito uno alla volta in ordine arbitrario. In un pool di nodi distribuito in più zone, gli upgrade avvengono zona per zona. All'interno di una zona, l'upgrade dei nodi verrà eseguito in un ordine indefinito.

Con gli upgrade dei pool di nodi GKE, puoi scegliere tra due strategie di upgrade integrate e configurabili che consentono di ottimizzare il processo di upgrade in base alle esigenze dell'ambiente del cluster. Per scoprire di più sulle strategie di upgrade di picco e blu/verde, consulta Strategie di upgrade.

Durante l'upgrade di un pool di nodi, non puoi apportare modifiche alla configurazione del cluster, a meno che non annulli l'upgrade.

GKE rispetta periodi di manutenzione ed esclusioni durante gli upgrade automatici, se possibile. Gli upgrade manuali ignorano i periodi di manutenzione e le esclusioni configurati.

Modalità di upgrade dei nodi

Durante l'upgrade di un pool di nodi, la modalità di upgrade dei nodi dipende dalla strategia di upgrade del pool di nodi e dalla modalità di configurazione. Tuttavia, i passaggi di base rimangono coerenti. Per eseguire l'upgrade di un nodo, GKE rimuove i pod dal nodo stesso.

Quando viene eseguito l'upgrade di un nodo, si verifica quanto segue con i pod:

  1. Il nodo è contrassegnato come non pianificabile in modo che Kubernetes non pianifica nuovi pod.
  2. Il nodo viene quindi svuotato, il che significa che i pod vengono rimossi. Per gli upgrade di sovraccarico, GKE rispetta le impostazioni di PodDisruptionBudget e GracefulTerminationPeriod del pod per un massimo di un'ora. Con gli upgrade blu/verde, l'operazione può essere estesa se configuri un tempo di attesa più lungo.
  3. Il piano di controllo ripianifica i pod gestiti dai controller su altri nodi. I pod che non possono essere ripianificati rimangono nella fase In attesa fino a quando non possono essere ripianificati.

Il processo di upgrade del pool di nodi può richiedere fino a alcune ore, a seconda della strategia di upgrade, del numero di nodi e delle configurazioni dei carichi di lavoro.

Considerazioni che influiscono sulla durata dell'upgrade dei nodi

Le configurazioni che possono richiedere più tempo per il completamento dell'upgrade di un nodo includono:

Strategie di upgrade dei nodi

GKE offre strategie configurabili integrate che determinano le modalità di upgrade del pool di nodi. Per saperne di più sui tipi di modifiche che utilizzano una strategia di upgrade dei nodi, consulta Quando GKE utilizza gli upgrade surge e Quando GKE utilizza upgrade blu/verde.

Upgrade di Surge

Per impostazione predefinita, per gli upgrade dei pool di nodi viene utilizzata la strategia di upgrade di picco. Gli upgrade di Surge utilizzano un metodo continuativo per eseguire l'upgrade dei nodi. Questa strategia è ideale per le applicazioni in grado di gestire modifiche incrementali e non dirompenti. Con questa strategia, l'upgrade dei nodi viene eseguito in una finestra temporale continua. Con le impostazioni puoi modificare il numero di nodi di cui eseguire l'upgrade contemporaneamente e quanto possono essere invasivi gli upgrade, trovando l'equilibrio ottimale tra velocità e interruzione in base alle esigenze del tuo ambiente.

Upgrade blu/verde

L'approccio alternativo è costituito dagli upgrade blu/verde, che consentono di gestire due insiemi di ambienti (originale e nuovo) contemporaneamente, semplificando il più possibile il rollback. Il blu/verde consuma più risorse ed è più adatto alle applicazioni più sensibili ai cambiamenti. Con questa strategia, i carichi di lavoro vengono gradualmente migrati dall'ambiente "blu" originale al nuovo ambiente "verde" e viene concesso il tempo di attesa per convalidarli con la nuova configurazione. Se necessario, puoi eseguire rapidamente il rollback dei carichi di lavoro nell'ambiente "blu".

Per saperne di più su come funzionano le strategie di upgrade dei nodi, consulta Strategie di upgrade dei nodi.

Requisiti delle risorse per le strategie di upgrade dei nodi

Gli upgrade di sovraccarico creano nodi aggiuntivi se il valore maxSurge è impostato su un valore superiore a 0 e gli upgrade blu/verde raddoppiano temporaneamente il numero di nodi in un pool di nodi. Ciò richiede risorse aggiuntive, che sono soggette alla quota di Compute Engine, alla disponibilità delle risorse e alla capacità di prenotazione. Se il pool di nodi non dispone di risorse sufficienti, gli upgrade possono richiedere più tempo o non riuscire.

Per scoprire di più su come assicurarti che il progetto disponga di risorse sufficienti per gli upgrade dei nodi e su cosa fare se il tuo ambiente è vincolato dalle risorse, consulta Garantire le risorse per gli upgrade dei nodi.

Upgrade automatico

Quando crei un cluster Standard, per impostazione predefinita l'upgrade automatico è abilitato nel cluster e nei relativi pool di nodi.

GKE è responsabile della protezione del piano di controllo del cluster e dell'upgrade dei cluster quando viene selezionata una nuova versione di GKE per l'upgrade automatico. La sicurezza dell'infrastruttura è una priorità elevata per GKE, pertanto l'upgrade di questi 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.

Nell'ambito del modello di responsabilità condivisa di GKE, sei responsabile della sicurezza di nodi, container e pod. L'upgrade automatico dei nodi è abilitato per impostazione predefinita. Sebbene sia sconsigliato, puoi disabilitare l'upgrade automatico dei nodi. La disattivazione degli upgrade automatici dei nodi non blocca l'upgrade del piano di controllo del cluster. Se disattivi gli upgrade automatici dei nodi, hai la responsabilità di assicurarti che i nodi del cluster eseguano una versione compatibile con la versione del cluster e che la versione sia conforme ai criteri di supporto per il disallineamento delle versioni di Kubernetes.

Per un maggiore controllo su quando può avvenire (o non deve avvenire) un upgrade automatico, puoi configurare periodi di manutenzione ed esclusioni.

I pool di nodi di un cluster non possono essere più di due versioni secondarie rispetto alla versione del piano di controllo, per mantenere la compatibilità con l'API cluster. La versione del pool di nodi determina anche le versioni dei pacchetti software installati su ciascun nodo. Ti consigliamo di mantenere i pool di nodi aggiornati alla versione del cluster.

Se registri il tuo cluster in un canale di rilascio, i nodi eseguono sempre la stessa versione di GKE del cluster stesso, tranne durante un breve periodo (in genere alcuni giorni, a seconda della release attuale) tra il completamento dell'upgrade del piano di controllo del cluster e l'inizio dell'upgrade di un determinato pool di nodi. Per ulteriori informazioni, consulta le note di rilascio.

Come vengono selezionate le versioni per l'upgrade automatico

Nuove versioni di GKE vengono rilasciate regolarmente, ma non ne viene selezionata una versione subito per l'upgrade automatico. Quando una versione di GKE ha accumulato un utilizzo dei cluster sufficiente a dimostrare la stabilità nel tempo, GKE la seleziona come destinazione dell'upgrade automatico per i cluster che eseguono un sottoinsieme di versioni precedenti.

I nuovi target di upgrade automatico sono annunciati nelle note di rilascio. Finché non viene selezionata una versione disponibile per l'upgrade automatico, puoi eseguire l'upgrade a una versione manuale. Occasionalmente, viene selezionata una versione per l'upgrade automatico del cluster e dei nodi in settimane diverse.

Poco dopo che una nuova versione secondaria diventa generalmente disponibile, in genere la versione secondaria meno recente disponibile non è più supportata. Per i cluster che eseguono versioni secondarie che non sono più supportate viene eseguito automaticamente l'upgrade alla versione secondaria successiva.

All'interno di una versione secondaria (come v1.14.x), è possibile eseguire automaticamente l'upgrade dei cluster a una nuova release della patch.

I canali di rilascio ti consentono di controllare la versione del cluster e del pool di nodi in base alla stabilità di una versione anziché alla gestione diretta.

Fattori che influiscono sulle tempistiche di implementazione della versione

Per garantire la stabilità e l'affidabilità dei cluster nelle nuove versioni, GKE segue determinate prassi durante i lanci delle versioni.

Queste pratiche includono, a titolo esemplificativo:

  • GKE implementa gradualmente le modifiche nelle regioni e nelle zone di Google Cloud.
  • GKE implementa gradualmente le versioni patch nei canali di rilascio. Una patch viene assegnata al canale di rilascio rapido e poi nel canale di rilascio regolare, prima di essere promossa sul canale di rilascio stabile dopo che ha accumulato un utilizzo e continuato a dimostrare stabilità. Se viene rilevato un problema con una versione patch durante il periodo di attesa su un canale di rilascio, la versione non viene promossa al canale successivo e il problema viene risolto in una versione della patch più recente.
  • GKE implementa gradualmente le versioni secondarie, seguendo un processo simile per le versioni con patch. Le versioni secondarie hanno periodi di attesa più lunghi perché introducono modifiche più significative.
  • GKE può ritardare gli upgrade automatici quando una nuova versione influisce su un gruppo di cluster. Ad esempio, GKE mette in pausa gli upgrade automatici per i cluster che rileva sono esposti a un'API o una funzionalità deprecata che verrà rimossa nella versione secondaria successiva.
  • GKE potrebbe ritardare l'implementazione delle nuove versioni durante i periodi di picco (ad es. durante le festività più importanti) per garantire la continuità aziendale.

Configurazione dei casi in cui possono essere eseguiti upgrade automatici

Per impostazione predefinita, gli upgrade automatici possono essere eseguiti in qualsiasi momento per preservare la sicurezza dell'infrastruttura. Gli upgrade automatici causano interruzioni minime, in particolare per i cluster a livello di regione. Tuttavia, alcuni carichi di lavoro potrebbero richiedere un controllo più granulare. Puoi configurare periodi di manutenzione ed esclusioni per gestire i casi in cui possono e non devono essere eseguiti gli upgrade automatici.

Upgrade manuale

Puoi richiedere di eseguire l'upgrade manuale del cluster o dei suoi pool di nodi a una versione disponibile e compatibile in qualsiasi momento. Gli upgrade manuali ignorano eventuali periodi di manutenzione ed esclusioni di manutenzione configurati.

Quando esegui l'upgrade manuale di un cluster, la sua disponibilità dipende dal fatto che il cluster sia a livello di regione o meno:

  • Per i cluster di zona, il piano di controllo non è disponibile durante l'upgrade. Nella maggior parte dei casi, i carichi di lavoro vengono eseguiti normalmente, ma non possono essere modificati durante l'upgrade.

  • Per i cluster a livello di regione, una replica del piano di controllo non è disponibile alla volta durante l'upgrade, ma il cluster rimane ad alta disponibilità durante l'upgrade.

Puoi avviare manualmente un upgrade del nodo a una versione compatibile con il piano di controllo.

In che modo GKE risponde all'errore di upgrade automatico

Gli upgrade automatici dei pool di nodi possono non riuscire a causa di problemi con le istanze di Compute Engine sottostanti o di problemi con Kubernetes. Ad esempio, gli upgrade automatici non riescono nelle situazioni seguenti:

  • L'impostazione maxSurge configurata supera la quota di risorse di Compute Engine.
  • I nuovi nodi di incremento non sono stati registrati con il piano di controllo del cluster.
  • Lo svuotamento dei nodi ha richiesto troppo tempo o ha impiegato troppo tempo per eliminarli.

Quando si verificano problemi con gli upgrade dei singoli nodi, GKE riprova a eseguire l'upgrade alcune volte, con un intervallo crescente tra i diversi tentativi. Se l'upgrade dei nodi nel pool di nodi non riesce, GKE non esegue il rollback dei nodi di cui è stato eseguito l'upgrade. ma GKE ritenterà l'upgrade automatico del pool di nodi.

Se gli upgrade dei nodi non vanno a buon fine perché le richieste di nodi di incremento superano la quota di Compute Engine, GKE riduce il numero di nodi di incremento simultanei per tentare di raggiungere la quota e continuare l'upgrade.

Ricezione di notifiche relative agli upgrade

GKE pubblica notifiche sugli eventi pertinenti per il tuo cluster, come upgrade delle versioni e bollettini sulla sicurezza, su Pub/Sub, fornendoti un canale per ricevere informazioni da GKE sui tuoi cluster.

Per ulteriori informazioni, consulta Ricezione di notifiche relative al cluster.

Controlla i log dell'upgrade

Per impostazione predefinita, GKE registra gli eventi di upgrade del piano di controllo e del pool di nodi in Cloud Logging. Il log degli eventi dell'upgrade fornisce visibilità sul processo di upgrade e include informazioni preziose per la risoluzione dei problemi, se necessario.

Log di upgrade del piano di controllo

Puoi eseguire query sugli eventi di upgrade del cluster utilizzando il seguente filtro:

resource.type="gke_cluster"
protoPayload.metadata.operationType=~"(UPDATE_CLUSTER|UPGRADE_MASTER)"
resource.labels.cluster_name="CLUSTER_NAME"

Questi log vengono registrati come formati di logging strutturato. Puoi utilizzare i seguenti campi per i dettagli degli eventi di upgrade:



Campo Descrizione
protoPayload.metadata.operationType Esistono due tipi di eventi di upgrade del cluster: UPGRADE_MASTER e UPDATE_CLUSTER.
UPGRADE_MASTER cambia la versione del piano di controllo Kubernetes.
UPDATE_CLUSTER indica un aggiornamento che non modifica la versione del piano di controllo Kubernetes.
Entrambi i tipi di upgrade dei cluster possono causare la perdita della disponibilità del piano di controllo per i cluster di zona. Per saperne di più, consulta Come funzionano gli upgrade di cluster e pool di nodi.
protoPayload.methodName Questo campo mostra quale API ha attivato l'upgrade del cluster.
google.container.v1.ClusterManager.UpdateCluster: upgrade manuale del piano di controllo
google.container.internal.ClusterManagerInternal.UpdateClusterInternal: upgrade automatico del piano di controllo
google.container.v1.ClusterManager.PatchCluster: modifica della configurazione del cluster.
protoPayload.metadata.previousMasterVersion Questo campo viene utilizzato solo per il tipo di operazione MASTER_UPGRADE e contiene la versione precedente del piano di controllo utilizzata prima dell'upgrade.
protoPayload.metadata.currentMasterVersion Questo campo viene utilizzato solo per il tipo di operazione MASTER_UPGRADE e contiene il numero di versione del nuovo piano di controllo utilizzato dopo l'upgrade.

Log di upgrade dei pool di nodi

Utilizza la seguente query per visualizzare gli eventi di upgrade del pool di nodi: 

resource.type="gke_nodepool"
protoPayload.metadata.operationType="UPGRADE_NODES"
resource.labels.cluster_name="CLUSTER_NAME"

Utilizza il seguente campo per i dettagli sull'evento di upgrade:

Il campo protoPayload.methodName mostra se l'upgrade è stato attivato manualmente o automaticamente come indicato di seguito.

Upgrade dei componenti

GKE esegue carichi di lavoro di sistema sui nodi worker per supportare funzionalità specifiche per i cluster. Ad esempio, il carico di lavoro del sistema gke-metadata-server supporta la federazione delle identità per i carichi di lavoro per GKE. GKE è responsabile dell'integrità di questi carichi di lavoro. Per saperne di più su questi componenti, consulta la documentazione delle funzionalità associate.

Quando sono disponibili nuove funzionalità o correzioni per un componente, GKE indica la versione della patch in cui sono incluse. Per ottenere la versione più recente di un componente, consulta la documentazione associata o le note di rilascio per istruzioni sull'upgrade del piano di controllo o dei nodi alla versione appropriata.

Passaggi successivi