Upgrade di cluster standard

Questa pagina illustra il funzionamento degli upgrade automatici e manuali sui cluster Google Kubernetes Engine (GKE) standard, inclusi i link a ulteriori informazioni su attività e impostazioni correlate. Puoi utilizzare queste informazioni per mantenere aggiornati i tuoi cluster in termini di stabilità e sicurezza con interruzioni minime dei tuoi workload.

Per una panoramica generale degli upgrade dei cluster, consulta Informazioni sugli upgrade dei cluster GKE. Per informazioni su come funzionano gli upgrade dei cluster specificamente per Autopilot, consulta Upgrade dei cluster Autopilot.

Come funzionano gli upgrade di cluster e pool di nodi

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

Per eseguire l'upgrade di un cluster, GKE aggiorna la versione in esecuzione del piano di controllo e dei 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.

Se registri il tuo 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 corrente) tra il completamento dell'upgrade del piano di controllo del cluster e l'avvio dell'upgrade del pool di nodi o se è stato eseguito l'upgrade manuale del piano di controllo. Per ulteriori informazioni, consulta le note di rilascio.

Upgrade dei cluster

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

  • I cluster 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 regione hanno più repliche del piano di controllo e viene eseguito l'upgrade di una sola replica alla volta, in un ordine indefinito. 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, viene rispettato, se possibile.

Upgrade dei node pool

Questa sezione illustra cosa aspettarsi quando GKE esegue l'upgrade automatico del pool di nodi o quando 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ù node pool in parallelo. Per impostazione predefinita, l'upgrade dei nodi all'interno di un pool di nodi viene eseguito uno alla volta in un ordine arbitrario. In un pool di nodi distribuito su più zone, gli upgrade vengono eseguiti zona per zona. All'interno di una zona, l'upgrade dei nodi verrà eseguito in un ordine non definito.

Con gli upgrade dei pool di nodi GKE, puoi scegliere tra due strategie di upgrade predefinite e configurabili, in cui puoi ottimizzare il processo di upgrade in base alle esigenze del tuo ambiente cluster. Per approfondire le strategie di upgrade di incremento e blu/verde, consulta Strategie di upgrade.

Durante un upgrade del pool di nodi, non puoi apportare modifiche alla configurazione del cluster se 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 ed esclusioni configurati.

Come viene eseguito l'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 dal modo in cui la configuri. Tuttavia, i passaggi di base rimangono invariati. Per eseguire l'upgrade di un nodo, GKErimuove i pod dal nodo in modo che sia possibile eseguire l'upgrade.

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

  1. Il nodo è isolato in modo che Kubernetes non pianifichi nuovi pod.
  2. Il nodo viene quindi svuotato, il che significa che i pod vengono rimossi. Per gli upgrade di picco, GKE rispetta le impostazioni PodDisruptionBudget e GracefulTerminationPeriod del pod per un massimo di un'ora. Con gli upgrade blu/verde, questo tempo può essere esteso 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 riprogrammati rimangono nella fase In attesa finché non è possibile riprogrammarli.

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

Considerazioni che influiscono sulla durata dell'upgrade dei nodi

Le configurazioni che possono causare un tempo di completamento più lungo dell'upgrade di un nodo includono:

Strategie di upgrade dei nodi

GKE offre strategie configurabili integrate che determinano come viene eseguito l'upgrade del pool di nodi. Per scoprire di più sui tipi di modifiche che utilizzano una strategia di upgrade dei nodi, consulta Quando GKE utilizza gli upgrade di picco e Quando GKE utilizza gli upgrade blue-green.

Upgrade di incremento

Per impostazione predefinita, la strategia di upgrade per picchi viene utilizzata per gli upgrade dei pool di nodi. Gli upgrade di picco utilizzano un metodo incrementale per eseguire l'upgrade dei nodi. Questa strategia è ideale per le applicazioni che possono gestire modifiche incrementali e non invasive. Con questa strategia, l'upgrade dei nodi viene eseguito in un periodo di tempo. Con queste impostazioni puoi modificare il numero di nodi di cui è possibile eseguire l'upgrade contemporaneamente e l'entità dell'interruzione causata dagli upgrade, trovando il giusto equilibrio tra velocità e interruzione in base alle esigenze del tuo ambiente.

Upgrade blu/verde

L'approccio alternativo è costituito dagli upgrade blue-green, in cui vengono gestiti contemporaneamente due insiemi di ambienti (l'ambiente originale e quello nuovo), semplificando al massimo il rollback. Il metodo blue-green richiede più risorse ed è più adatto per le applicazioni più sensibili alle modifiche. Con questa strategia, i carichi di lavoro vengono migrati gradualmente dall'ambiente "blu" originale al nuovo ambiente "verde" e viene concesso un tempo di attesa per convalidarli con la nuova configurazione. Se necessario, è possibile eseguire rapidamente il rollback dei carichi di lavoro nell'ambiente "blu" esistente.

Per scoprire 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 maxSurge è impostato su un valore maggiore di 0 e gli upgrade blue-green raddoppiano temporaneamente il numero di nodi in un pool di nodi. Ciò richiede risorse aggiuntive, che sono soggette alla quota Compute Engine, alla disponibilità delle risorse e alla capacità di prenotazione. Se il tuo 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 tuo progetto disponga di risorse sufficienti per gli upgrade dei nodi e su cosa fare se il tuo ambiente è limitato in termini di risorse, consulta Garantire le risorse per gli upgrade dei nodi.

Eseguire l'upgrade automaticamente

Quando crei un cluster standard, per impostazione predefinita l'upgrade automatico è abilitato sul cluster e sui relativi pool di nodi.

GKE è responsabile della protezione del control plane del tuo cluster e esegue l'upgrade dei tuoi cluster quando viene selezionata una nuova versione di GKE per l'upgrade automatico. La sicurezza dell'infrastruttura è una priorità elevata per GKE, pertanto i piani di controllo vengono sottoposti ad upgrade 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.

Nell'ambito del modello di responsabilità condivisa GKE, sei responsabile della protezione dei tuoi nodi, contenitori e pod. L'upgrade automatico dei nodi è attivo per impostazione predefinita. Sebbene non sia consigliato, puoi disattivare 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, è tua responsabilità assicurarti che i nodi del cluster eseguano una versione compatibile con quella del cluster e che la versione rispetti le norme relative allo sfasamento delle versioni GKE.

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

I pool di nodi di un cluster non possono essere più indietro di due versioni secondarie rispetto alla versione del control plane, per mantenere la compatibilità con l'API del cluster. La versione del pool di nodi determina anche le versioni dei pacchetti software installati su ogni nodo. Ti consigliamo di mantenere aggiornati i node pool 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 per un breve periodo (in genere alcuni giorni, a seconda della release corrente) tra il completamento dell'upgrade del piano di controllo del cluster e l'inizio dell'upgrade di un determinato pool di nodi. Per saperne di più, consulta le note di rilascio.

Come vengono selezionate le versioni per l'upgrade automatico

Le nuove versioni di GKE vengono rilasciate regolarmente, ma una versione non viene selezionata subito per l'upgrade automatico. Quando una versione di GKE ha accumulato un utilizzo sufficiente del cluster per dimostrare la stabilità nel tempo, GKE la seleziona come destinazione di upgrade automatico per i cluster che eseguono un sottoinsieme di versioni precedenti. Per ottenere i target di upgrade automatico per un cluster specifico, consulta Ottenere informazioni sugli upgrade di un cluster (anteprima).

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

Poco dopo la disponibilità generale di una nuova versione minore, la versione minore precedente 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 (ad esempio la v1.14.x), è possibile eseguire automaticamente l'upgrade dei cluster a una nuova release con patch.

I canali di rilascio ti consentono di controllare la versione del cluster e del pool di nodi in base alla sua stabilità anziché gestirla direttamente.

Fattori che influiscono sulle tempistiche di implementazione della versione

Per garantire la stabilità e l'affidabilità dei cluster sulle nuove versioni, GKE segue determinate pratiche durante l'implementazione 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 delle patch nei canali di rilascio. A una patch viene assegnato un tempo di attesa nel canale di rilascio rapido, quindi nel canale di rilascio regolare, prima di essere promossa al canale di rilascio stabile dopo aver accumulato utilizzo e aver continuato a dimostrare stabilità. Se viene rilevato un problema con una versione della patch durante il periodo di attesa in 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 di assorbimento simile a quello delle versioni patch. Le versioni minori hanno periodi di attesa più lunghi in quanto introducono modifiche più significative.
  • GKE potrebbe 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 essere esposti a un'API o a una funzionalità non più supportata che verrà rimossa nella versione secondaria successiva.
  • GKE potrebbe ritardare l'implementazione delle nuove versioni durante i periodi di picco (ad esempio le festività principali) per garantire la continuità aziendale.

Configurare quando possono verificarsi gli upgrade automatici

Per impostazione predefinita, gli upgrade automatici possono avvenire in qualsiasi momento per preservare la sicurezza dell'infrastruttura. Gli upgrade automatici sono minimamente invasivi, soprattutto per i cluster regionali. Tuttavia, alcuni carichi di lavoro potrebbero richiedere un controllo più granulare. Puoi configurare periodi di manutenzione ed esclusioni per gestire quando possono e non devono verificarsi gli upgrade automatici.

Eseguire l'upgrade manualmente

Puoi richiedere di eseguire manualmente l'upgrade del cluster o dei relativi 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 sia regionale o meno:

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

  • Per i cluster regionali, 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.

Come GKE risponde al fallimento dell'upgrade automatico

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

  • L'impostazione maxSurge configurata supera la quota di risorse Compute Engine.
  • I nuovi nodi di picco non sono stati registrati nel piano di controllo del cluster.
  • Lo svuotamento o l'eliminazione dei nodi ha richiesto troppo tempo.

Quando si verificano problemi con gli upgrade dei singoli nodi, GKE riprova l'upgrade alcune volte, con un intervallo crescente tra i tentativi. Se l'upgrade dei nodi nel pool di nodi non va a buon fine, GKE non esegue il rollback dei nodi di cui è stato eseguito l'upgrade. GKE tenta di nuovo l'upgrade automatico del pool di nodi fino a quando non viene eseguito l'upgrade di tutti i nodi.

Se gli upgrade dei nodi non riescono perché le richieste di nodi di picco superano la quota di Compute Engine, GKE riduce il numero di nodi di picco simultanei per tentare di soddisfare la quota e continuare l'upgrade.

Ricevere notifiche di upgrade

GKE pubblica notifiche relative a 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 la sezione Ricevere notifiche del cluster.

Controllare i log di 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 di upgrade fornisce visibilità sulla procedura di upgrade e include informazioni preziose per la risoluzione dei problemi, se necessario.

Log dell'upgrade del piano di controllo

È possibile 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 log strutturati. 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 modifica 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 del cluster possono causare la perdita della disponibilità del piano di controllo per i cluster zonali. Per scoprire di più, consulta l'articolo Come funzionano gli upgrade dei cluster e pool di nodi pool.
protoPayload.methodName Questo campo mostra l'API che 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 nuovo numero di versione del piano di controllo utilizzato dopo l'upgrade.

Log dell'upgrade del node pool

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 indica se l'upgrade è stato attivato manualmente o automaticamente come segue.

Upgrade dei componenti

GKE esegue i 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 scoprire di più su questi componenti, consulta la documentazione relativa alle funzionalità associate.

Quando diventano 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 su come eseguire l'upgrade del piano di controllo o dei nodi alla versione appropriata.

Passaggi successivi