Upgrade di cluster standard

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

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 i cluster Autopilot, consulta Upgrade dei cluster Autopilot.

Come funzionano gli upgrade dei cluster e pool di nodi

Questa sezione descrive 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 in cui sono in esecuzione il control plane e i nodi. L'upgrade dei cluster viene eseguito 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ù, consulta Controllo delle versioni e supporto 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 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 saperne di più, consulta le note di rilascio.

Upgrade dei cluster

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

  • I Zonal 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 regionali 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 a elevata disponibilità e ogni replica del control plane 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 descrive cosa aspettarsi quando GKE esegue l'upgrade automatico del pool di nodi o quando avvii un upgrade manuale pool di nodi. Queste informazioni sono pertinenti sia per i node pool standard sia per i node pool gestiti da Autopilot.

Per impostazione predefinita, GKE esegue l'upgrade automatico di un pool di nodi alla volta in un cluster. Per ridurre il tempo di upgrade complessivo per i cluster con più node pool, puoi configurare gli upgrade simultanei dei node pool (anteprima), che consentono a GKE di eseguire automaticamente l'upgrade di più node pool contemporaneamente. 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 node pool distribuito su più zone, gli upgrade vengono eseguiti zona per zona. All'interno di una zona, l'upgrade dei nodi viene eseguito in un ordine non definito.

Con gli upgrade pool di nodi standard di GKE, puoi scegliere tra le seguenti strategie di upgrade dei nodi:

  • Upgrade di sovraccarico
  • Upgrade blu/verde
  • Upgrade blu/verde con scalabilità automatica (anteprima)

Per ognuna di queste strategie di upgrade dei nodi, puoi ottimizzare il processo di upgrade in base alle esigenze dell'ambiente del cluster. I node pool gestiti da Autopilot nei cluster standard utilizzano sempre gli upgrade di sovraccarico e non puoi modificare la configurazione della strategia o delle relative impostazioni.

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

Quando possibile, GKE rispetta i periodi di manutenzione e le esclusioni durante gli upgrade automatici. Gli upgrade manuali ignorano i periodi di manutenzione e le 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 node pool e dalla sua configurazione, se possibile. Tuttavia, i passaggi di base rimangono coerenti. Per eseguire l'upgrade di un nodo, GKE rimuove i pod dal nodo in modo che possa essere eseguito l'upgrade.

Quando viene eseguito l'upgrade di un nodo, i pod vengono gestiti nel seguente modo:

  1. Il nodo viene isolato in modo che Kubernetes non pianifichi nuovi pod su di esso.
  2. I pod vengono quindi svuotati, ovvero rimossi. Per gli upgrade di sovraccarico, GKE rispetta le impostazioni PodDisruptionBudget e GracefulTerminationPeriod del pod per un massimo di un'ora. Con gli upgrade blu/verde, questo periodo può essere esteso se configuri un tempo di soak 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 finché non possono essere ripianificati.

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 configurazioni dei carichi di lavoro.

Considerazioni che influiscono sulla durata dell'upgrade dei nodi

Le configurazioni che possono allungare i tempi di completamento dell'upgrade di un nodo includono:

Strategie di upgrade dei nodi

GKE offre strategie configurabili integrate che determinano la modalità di upgrade del pool di nodi. Per saperne di più sui tipi di modifiche che utilizzano una strategia di upgrade dei nodi, consulta quanto segue:

Upgrade di sovraccarico

Per impostazione predefinita, per gli upgrade dei pool di nodi viene utilizzata la strategia di upgrade surge. Questa strategia viene sempre utilizzata per i node pool gestiti da Autopilot. Gli upgrade di sovraccarico utilizzano un metodo di rolling per eseguire l'upgrade dei nodi. Questa strategia è ideale per le applicazioni in grado di gestire modifiche incrementali e non disruptive. Con questa strategia, l'upgrade dei nodi viene eseguito in una finestra di rolling. Per i node pool standard, puoi modificare impostazioni come il numero di nodi di cui è possibile eseguire l'upgrade contemporaneamente e il livello di interruzione degli upgrade, trovando il bilanciamento ottimale tra velocità e interruzione per le esigenze del tuo ambiente.

Upgrade blu/verde

Un approccio alternativo per i node pool standard è rappresentato dagli upgrade blu/verde, in cui vengono mantenuti contemporaneamente due set di ambienti (l'ambiente originale e il nuovo ambiente), rendendo il rollback il più semplice possibile. La strategia blu/verde richiede più risorse ed è più adatta alle 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 soak per convalidarli con la nuova configurazione. Se necessario, è possibile eseguire rapidamente il rollback dei carichi di lavoro all'ambiente "blu" esistente.

Per saperne di più sul funzionamento delle strategie di upgrade dei nodi, consulta Strategie di upgradedei nodi.

Upgrade blu/verde con scalabilità automatica

Gli upgrade blu/verde con scalabilità automatica (anteprima) sono una strategia di upgrade dei nodi in cui i carichi di lavoro possono essere eseguiti più a lungo, riducendo al contempo i costi dovuti a nodi inattivi o sottoutilizzati.

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, mentre gli upgrade blu/verde raddoppiano temporaneamente il numero di nodi in un pool di nodi. Ciò richiede risorse aggiuntive, soggette a quota di Compute Engine, disponibilità delle risorse, e capacità di prenotazione. Se il pool di nodi non dispone di risorse sufficienti, gli upgrade possono richiedere più tempo o non riuscire.

Per saperne di più su come assicurarti che il tuo progetto disponga di risorse sufficienti per gli upgrade dei nodi e su cosa fare se l'ambiente è vincolato dalle risorse, consulta Assicurati che siano disponibili 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 node pool.

GKE è responsabile della protezione del piano di controllo del cluster ed esegue l'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 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 per i piani di controllo e i nodi.

Nell'ambito del modello di responsabilità condivisa di GKE, sei responsabile della protezione dei nodi, dei container e dei pod. L'upgrade automatico dei nodi è abilitato per impostazione predefinita. Sebbene non sia consigliato, 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, sei responsabile di assicurarti che i nodi del cluster eseguano una versione compatibile con la versione del cluster e che la versione rispetti i criteri di disallineamento delle versioni di GKE policy.

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

Per mantenere la compatibilità con l'API cluster, i node pool di un cluster non possono essere più di due versioni secondarie precedenti alla versione del piano di controllo. La versione 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 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 corrente) tra il completamento dell'upgrade del control plane 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 immediatamente 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 target 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.

I nuovi target di upgrade automatico vengono annunciati nelle note di rilascio. Finché una versione disponibile non viene selezionata 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 durante settimane diverse.

Poco dopo che una nuova versione secondaria diventa disponibile a livello generale, la versione secondaria disponibile più vecchia in genere non è più supportata. I cluster che eseguono versioni secondarie non supportate vengono sottoposti automaticamente all'upgrade alla versione secondaria successiva.

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

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

Fattori che influiscono sulla tempistica del rollout delle versioni

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

Queste pratiche includono, a titolo esemplificativo:

  • GKE esegue gradualmente il rollout delle modifiche in Google Cloud regioni e zone.
  • GKE esegue gradualmente il rollout delle versioni patch nei canali di rilascio. Una patch viene sottoposta a un periodo di soak nel canale di rilascio rapido, quindi nel canale di rilascio regolare, prima di essere promossa al canale di rilascio stabile una volta che ha accumulato utilizzo e ha continuato a dimostrare stabilità. Se viene rilevato un problema con una versione patch durante il periodo di soak in un canale di rilascio, la versione non viene promossa al canale successivo e il problema viene risolto in una versione patch più recente.
  • GKE esegue gradualmente il rollout delle versioni secondarie, seguendo un processo di soak simile a quello delle versioni patch. Le versioni secondarie hanno periodi di soak più lunghi perché 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à deprecata che verrà rimossa nella versione secondaria successiva.
  • GKE potrebbe ritardare il rollout di nuove versioni durante i periodi di punta (ad esempio, le festività principali) per garantire la continuità operativa.

Configurare quando possono verificarsi gli upgrade automatici

Per impostazione predefinita, gli upgrade automatici possono verificarsi in qualsiasi momento per preservare la sicurezza dell'infrastruttura. Gli upgrade automatici sono minimamente disruptive, 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 control plane o dei node pool del cluster a una versione disponibile e compatibile in qualsiasi momento. Nei cluster standard, puoi eseguire manualmente l'upgrade sia dei node pool standard sia dei node pool gestiti da Autopilot. Gli upgrade manuali ignorano i periodi di manutenzione e le esclusioni dalla manutenzione configurati.

Quando esegui manualmente l'upgrade di un cluster, la sua disponibilità dipende dal fatto che il cluster sia regionale 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 regionali, una replica del piano di controllo non è disponibile alla volta durante l'upgrade, ma il cluster rimane a elevata disponibilità durante l'upgrade.

Puoi avviare manualmente un upgrade dei nodi a una versione compatibile con il piano di controllo.

Come risponde GKE a un errore di upgrade automatico

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

  • L'impostazione maxSurge configurata supera la quota di risorse di Compute Engine.
  • I nuovi nodi di sovraccarico 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 i singoli upgrade dei nodi, GKE riprova a eseguire l'upgrade alcune volte, con un intervallo crescente tra i 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. GKE riprova invece a eseguire l'upgrade automatico del pool di nodi finché l'upgrade di tutti i nodi non viene eseguito correttamente.

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

Ricevere notifiche di upgrade

GKE pubblica notifiche su eventi pertinenti al 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 saperne di più, consulta Ricevere notifiche dei cluster.

Controllare i log di upgrade

Per impostazione predefinita, GKE registra gli eventi di upgrade del control plane e pool di nodi in Cloud Logging. I log degli eventi di upgrade forniscono visibilità sul processo di upgrade e includono informazioni utili per la risoluzione dei problemi, se necessario.

Log di upgrade del piano di controllo

È possibile eseguire query sugli eventi di upgrade dei 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 dei cluster:

  • UPGRADE_MASTER: un upgrade alla versione del piano di controllo Kubernetes.
  • UPDATE_CLUSTER: 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 dei cluster e pool di nodi pool.
protoPayload.methodName

Questo campo mostra quale API ha attivato l'upgrade 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 di 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 dell'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 di sistema gke-metadata-server supporta Workload Identity Federation for GKE. GKE è responsabile dell'integrità di questi carichi di lavoro. Per saperne di più su questi componenti, consulta la documentazione delle funzionalità associate.

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

Passaggi successivi