Upgrade di cluster standard

Questo documento descrive il funzionamento degli upgrade automatici e manuali per i cluster Google Kubernetes Engine (GKE) Standard, inclusi i link a ulteriori informazioni su attività e impostazioni correlate. Puoi utilizzare queste informazioni per mantenere i tuoi cluster aggiornati per 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 sul funzionamento degli upgrade dei cluster specifici per i cluster Autopilot, consulta Upgrade dei cluster Autopilot.

Come funzionano gli upgrade di cluster e pool di nodi

Questa sezione descrive cosa succede nel cluster durante gli aggiornamenti 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 esecuzione sul control plane e sui nodi. I cluster vengono aggiornati 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 cluster a 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 control plane del cluster e l'avvio dell'upgrade del pool di nodi oppure se è stato eseguito l'upgrade manuale del control plane. Per saperne di più, consulta le note di rilascio.

Upgrade dei cluster

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

  • I Zonal zonali hanno un solo control plane. Durante l'upgrade, i tuoi 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 finché l'upgrade non è completato.

  • I cluster regionali hanno più repliche del control plane e solo una replica viene sottoposta ad upgrade alla volta, in un ordine non definito. Durante l'upgrade, il cluster rimane a disponibilità elevata 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 del pool di nodi. Queste informazioni sono pertinenti sia per i pool di nodi standard sia per i pool di nodi gestiti da Autopilot.

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, i nodi all'interno di unpool di nodil vengono aggiornati 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 verrà eseguito in un ordine indefinito.

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

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

Per ciascuna di queste strategie di upgrade dei nodi, puoi ottimizzare la procedura di upgrade in base alle esigenze dell'ambiente del cluster. I pool di nodi gestiti da Autopilot nei cluster Standard utilizzano sempre gli upgrade inattivi e non puoi modificare la configurazione della strategia o le relative impostazioni.

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

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

Come vengono eseguiti gli 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 da come la configuri, se possibile. Tuttavia, i passaggi di base rimangono invariati. Per eseguire l'upgrade di un nodo, GKE rimuove i pod dal nodo in modo che possa essere aggiornato.

Quando viene eseguito l'upgrade di un nodo, accade 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 sovraccarico, GKE rispetta le impostazioni di PodDisruptionBudget e GracefulTerminationPeriod del pod per un massimo di un'ora. Con gli upgrade blu/verde, questo può essere esteso se configuri un tempo di attesa più lungo.
  3. Il control plane ripianifica i pod gestiti dai controller su altri nodi. I pod che non possono essere riprogrammati rimangono nella fase In attesa finché non possono essere riprogrammati.

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 causare un upgrade del nodo più lungo da completare 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 di sovraccarico. Questa strategia viene sempre utilizzata per i node pool gestiti da Autopilot. Gli upgrade inattivi utilizzano un metodo sequenziale per eseguire l'upgrade dei nodi. Questa strategia è ideale per le applicazioni in grado di gestire modifiche incrementali e non distruttive. Con questa strategia, i nodi vengono aggiornati in una finestra mobile. 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 l'equilibrio ottimale tra velocità e interruzione per le esigenze del tuo ambiente.

Upgrade blu/verde

Un approccio alternativo per i node pool Standard è l'upgrade blu/verde, in cui vengono mantenuti contemporaneamente due set di ambienti (quello originale e quello nuovo), rendendo il rollback il più semplice possibile. Il deployment blu/verde richiede più risorse ed è più adatto 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 periodo di rodaggio per convalidarli con la nuova configurazione. Se necessario, i carichi di lavoro possono essere rapidamente ripristinati nell'ambiente "blu" esistente.

Per maggiori informazioni su come funzionano le strategie di upgrade dei nodi, vedi Strategie di upgrade dei nodi.

Upgrade blu/verde con scalabilità automatica

Gli upgrade blue-green con scalabilità automatica (anteprima) sono una strategia di upgrade dei nodi in cui i workload possono essere eseguiti più a lungo, riducendo al minimo i costi derivanti da 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 e 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 tuo 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 il tuo ambiente è vincolato dalle risorse, consulta Garantisci 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 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 e, di conseguenza, i control plane vengono aggiornati 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 di GKE, sei responsabile della protezione di nodi, container e pod. L'upgrade automatico dei nodi è abilitato per impostazione predefinita. Anche se non è consigliabile, puoi disattivare l'upgrade automatico dei nodi. La disattivazione degli upgrade automatici dei nodi non blocca l'upgrade del control plane del cluster. Se disattivi gli upgrade automatici dei nodi, è tua responsabilità assicurarti che i nodi del cluster eseguano una versione compatibile con la versione del cluster e che la versione rispetti le norme relative alla differenza di versione di GKE.

Per un maggiore controllo su quando può o non può verificarsi 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 precedenti alla versione del control plane, per mantenere la compatibilità con l'API cluster. 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, 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 del cluster sufficiente a dimostrarne la stabilità nel tempo, GKE la seleziona come target di upgrade automatico per i cluster che eseguono un sottoinsieme di versioni precedenti. Per ottenere le destinazioni dell'upgrade automatico per un cluster specifico, consulta Ottenere informazioni sugli upgrade di un cluster.

Le nuove destinazioni di upgrade automatico vengono annunciate 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 secondaria, la versione secondaria meno recente disponibile in genere non è più supportata. I cluster che eseguono versioni secondarie non supportate vengono aggiornati automaticamente alla versione secondaria successiva.

All'interno di una versione secondaria (ad esempio v1.14.x), i cluster possono essere aggiornati automaticamente a una nuova release 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é gestirla direttamente.

Fattori che influiscono sui tempi di implementazione delle versioni

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

Queste pratiche includono, a titolo esemplificativo:

  • GKE implementa gradualmente le modifiche in tutte le Google Cloud regioni e zone.
  • GKE implementa gradualmente le versioni patch nei canali di rilascio. Una patch viene sottoposta a un periodo di test nel canale di rilascio rapido, poi 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 test su un canale di rilascio, questa versione non viene promossa al canale successivo e il problema viene risolto in una versione patch più recente.
  • GKE implementa gradualmente le versioni secondarie, seguendo un processo di soaking simile a quello delle versioni patch. Le versioni secondarie hanno periodi di rodaggio 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 esposti a un'API o una funzionalità deprecata che verrà rimossa nella versione secondaria successiva.
  • GKE potrebbe ritardare l'implementazione di nuove versioni durante i periodi di punta (ad esempio, le festività principali) per garantire la continuità operativa.

Configurazione del momento in cui possono verificarsi gli upgrade automatici

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

Eseguire l'upgrade manualmente

Puoi richiedere di eseguire manualmente l'upgrade del control plane del cluster o dei relativi pool di nodi a una versione disponibile e compatibile in qualsiasi momento. Nei cluster Standard, puoi eseguire l'upgrade manuale sia dei node pool Standard sia di quelli gestiti da Autopilot. Gli upgrade manuali ignorano eventuali periodi di manutenzione ed 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 control plane 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 control plane non è disponibile alla volta durante l'upgrade, ma il cluster rimane a disponibilità elevata durante l'upgrade.

Puoi avviare manualmente un upgrade del nodo a una versione compatibile con il control plane.

Come risponde GKE all'errore di 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 di Compute Engine.
  • I nuovi nodi di picco non sono stati registrati con il control plane del cluster.
  • L'eliminazione dei nodi ha richiesto troppo tempo.

Quando si verificano problemi con i singoli upgrade dei 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 riprova l'upgrade automatico del pool di nodi finché tutti i nodi non vengono aggiornati correttamente.

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 rispettare la quota e continuare l'upgrade.

Ricezione di notifiche di upgrade

GKE pubblica notifiche relative a eventi pertinenti per il tuo cluster, come upgrade di versione 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 del 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. Il log degli eventi di upgrade fornisce visibilità sul processo di upgrade e include informazioni preziose per la risoluzione dei problemi, se necessario.

Log dell'upgrade del control plane

È 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 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: un upgrade alla versione del control plane Kubernetes.
  • UPDATE_CLUSTER: un aggiornamento che non modifica la versione del control plane Kubernetes.

Entrambi i tipi di upgrade del cluster possono causare la perdita di disponibilità del control plane 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 l'API che 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 control plane 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 control plane 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 sull'evento di upgrade:

Il campo protoPayload.methodName mostra se l'upgrade è stato attivato manualmente o automaticamente, come segue.

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 di sistema gke-metadata-server supporta Workload Identity Federation for 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 patch in cui sono incluse. Per ottenere l'ultima versione di un componente, consulta la documentazione associata o le note di rilascio per istruzioni sull'upgrade del control plane o dei nodi alla versione appropriata.

Passaggi successivi