Upgrade di cluster standard

Questo documento illustra il funzionamento degli upgrade automatici e manuali per i cluster Google Kubernetes Engine (GKE) Standard, inclusi i link a ulteriori informazioni sulle attività e sulle impostazioni correlate. Puoi utilizzare queste informazioni per mantenere i tuoi cluster aggiornati per garantire stabilità e sicurezza con interruzioni minime dei 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 del control plane 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 se vengono rilevati problemi.

Per eseguire l'upgrade di un cluster, GKE aggiorna la versione del control plane e dei nodi in esecuzione. 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 in un canale di rilascio, i nodi eseguono la stessa versione di GKE del cluster, ad eccezione di 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 del pool di nodi o se è stato eseguito l'upgrade manuale del control plane. Per saperne di più, consulta le note di rilascio.

Upgrade del control plane

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

La disponibilità del cluster GKE durante gli upgrade del control plane dipende dal tipo di cluster Standard che esegui:

  • I cluster Zonal hanno un solo control plane. Durante l'upgrade, i tuoi workload continuano a essere eseguiti, ma non puoi eseguire il deployment di nuovi workload, modificare quelli esistenti o apportare altre modifiche alla configurazione del cluster fino al completamento dell'upgrade.

  • I cluster regionali hanno più repliche del control plane e viene eseguito l'upgrade di una sola replica alla volta, in un ordine non definito. Durante l'upgrade, il cluster rimane ad alta affidabilità e ogni replica del control plane non è disponibile solo durante l'upgrade.

Se configuri un periodo di manutenzione o un'esclusione, il periodo di manutenzione o l'esclusione vengono rispettati per gli upgrade automatici, se possibile.

Metodi di upgrade del control plane

GKE utilizza i seguenti metodi per eseguire gli upgrade del control plane:

  • Upgrade automatici: GKE esegue gli upgrade automatici utilizzando i seguenti metodi, a seconda del tipo di upgrade:

    • Upgrade delle versioni patch: GKE utilizza un upgrade in un unico passaggio, che esegue l'upgrade del control plane direttamente a una versione patch successiva.
    • Upgrade delle versioni secondarie: per eseguire l'upgrade alla versione secondaria 1.33 o successiva di GKE, GKE utilizza un processo in due passaggi in cui puoi convalidare la nuova versione secondaria per un periodo di soak time ed eseguire il rollback, se necessario. Per ulteriori informazioni, consulta Upgrade secondario del control plane in due passaggi con sicurezza del rollback. Per l'upgrade alle versioni precedenti, GKE utilizza invece il processo di upgrade in un solo passaggio.

  • Upgrade manuali: puoi eseguire l'upgrade del control plane del cluster a seconda del tipo di upgrade:

    • Upgrade della versione patch: puoi utilizzare un upgrade in un solo passaggio.
    • Upgrade delle versioni secondarie: puoi utilizzare l'upgrade in un solo passaggio o l'upgrade in due passaggi.

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. Queste informazioni sono pertinenti sia per i pool di nodi Standard sia per i pool di nodi gestiti da Autopilot.

Per impostazione predefinita, GKE esegue automaticamente l'upgrade di un pool di nodi alla volta in un cluster. Per ridurre il tempo di upgrade complessivo per i cluster con più pool di nodi, puoi configurare gli upgrade dei pool di nodi simultanei (anteprima), che consente a GKE di eseguire automaticamente l'upgrade di più pool di nodi contemporaneamente. In alternativa, puoi eseguire manualmente l'upgrade di uno o più node pool in parallelo. Per impostazione predefinita, i nodi all'interno di un pool di nodi 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 non definito.

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

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

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

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.

Upgrade invasivi per i node pool che utilizzano acceleratori ed eseguono workload AI/ML

Poiché le istanze di Compute Engine con acceleratori (GPU o TPU) non supportano la migrazione live, Compute Engine deve arrestare e ricreare i nodi durante la manutenzione dell'host. Questo processo può interrompere workload come i job di addestramento o inferenza AI/ML. Per ridurre al minimo le interruzioni, ti consigliamo di eseguire contemporaneamente la manutenzione dell'host di Compute Engine e gli upgrade dei nodi GKE. Per saperne di più, consulta Esegui la manutenzione dell'host per i nodi che eseguono workload di addestramento e inferenza.

Come viene eseguito l'upgrade dei nodi

Durante l'upgrade di un pool di nodi, l'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 sia possibile eseguirne l'upgrade.

Quando viene eseguito l'upgrade di un nodo, i pod vengono gestiti come segue:

  1. Il nodo viene isolato in modo che Kubernetes non pianifichi nuovi pod al suo interno.
  2. Il nodo viene quindi svuotato, il che significa che i pod vengono 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 control plane 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 potrebbe richiedere fino a qualche ora, a seconda della strategia di upgrade, del numero di nodi e delle relative configurazioni dei workload.

Considerazioni che influiscono sulla durata dell'upgrade dei nodi

Le configurazioni che possono causare un prolungamento del tempo di completamento di un upgrade dei nodi includono:

Strategie di upgrade dei nodi

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

Upgrade di incremento

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 di sovraccarico utilizzano un metodo in sequenza 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 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 che gli upgrade possono causare, 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 sono gli upgrade blu/verde, in cui vengono mantenuti contemporaneamente due set di ambienti (l'ambiente originale e quello nuovo), in modo da semplificare il più possibile il rollback. La strategia blu-verde richiede più risorse ed è più adatta per le applicazioni più sensibili alle modifiche. Con questa strategia, i workload 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 workload all'ambiente "blu" esistente.

Per saperne di più su come funzionano le strategie di upgrade dei nodi, consulta Strategie di upgrade dei 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 workload possono essere eseguiti più a lungo, riducendo al contempo i costi dei 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 alla quota di 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 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 ha risorse limitate, consulta Garantisci le risorse per gli upgrade dei nodi.

Upgrade automatico

Quando crei un cluster Standard, l'upgrade automatico è abilitato per impostazione predefinita 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, pertanto i control plane vengono aggiornati regolarmente e non possono essere disattivati. Tuttavia, puoi utilizzare periodi di manutenzione ed esclusioni per sospendere temporaneamente gli upgrade dei control plane.

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 e puoi utilizzare periodi di manutenzione ed esclusioni per controllare quando può o non può essere eseguito un upgrade automatico. Se impedisci gli upgrade automatici dei nodi, è tua responsabilità assicurarti che i nodi del cluster eseguano una versione compatibile con quella del control plane e che la versione rispetti la policy di disallineamento delle versioni di GKE. Indipendentemente dalle impostazioni del cluster, GKE esegue gli upgrade automatici al termine del periodo di assistenza.

I pool di nodi di un cluster possono essere al massimo due versioni secondarie precedenti alla versione del control plane, per mantenere la compatibilità con l'API del cluster. La versione pool di nodi determina anche le versioni dei pacchetti software installati su ciascun nodo. Ti consigliamo di mantenere i node pool aggiornati alla versione del cluster.

Se mantieni il cluster registrato in un canale di rilascio, i nodi in genere 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'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 non viene selezionata immediatamente una versione per l'upgrade automatico. Quando una versione di GKE ha accumulato un utilizzo del cluster sufficiente 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 Ottieni 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. In alcuni casi, una versione viene selezionata per l'upgrade automatico del cluster e l'upgrade automatico dei nodi in settimane diverse.

Poco dopo che una nuova versione secondaria diventa disponibile a livello generale, la versione secondaria più vecchia disponibile in genere non è più supportata. I cluster che eseguono versioni secondarie non più supportate vengono automaticamente aggiornati 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 pool di nodi in base alla stabilità di una versione, anziché gestire direttamente la versione.

Fattori che influiscono sulle tempistiche di implementazione delle versioni

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 Google Cloud.
  • GKE implementa gradualmente le versioni patch nei canali di rilascio. A una patch viene concesso un tempo di soak 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 un utilizzo e ha continuato a dimostrare stabilità. Se viene rilevato un problema con una versione patch durante il tempo di soak su un canale di rilascio, la 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 soaking 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 una funzionalità deprecata che verrà rimossa nella versione secondaria successiva.
  • GKE potrebbe ritardare l'implementazione di nuove versioni durante i periodi di picco (ad esempio, le festività principali) per garantire la continuità aziendale.

Configurazione del momento in cui possono essere eseguiti 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.

Upgrade manuale

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 di quelli gestiti da Autopilot. Gli upgrade manuali ignorano i periodi di manutenzione e le esclusioni dalla 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 control plane non è disponibile durante l'upgrade. Per la maggior parte, i workload 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 ad alta affidabilità durante l'upgrade.

Puoi avviare manualmente un upgrade dei nodi a una versione compatibile con il control plane.

Come GKE risponde a un errore di upgrade automatico

Gli upgrade automatici dei node pool 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 surge non sono stati registrati nel control plane del cluster.
  • Il drain 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 riprova a eseguire l'upgrade automatico del pool di nodi finché non viene eseguito l'upgrade di tutti i nodi.

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

Ricezione di notifiche di upgrade

GKE pubblica notifiche relative agli eventi pertinenti per il tuo cluster, come upgrade di versione e bollettini sulla sicurezza, in Pub/Sub, fornendoti un canale per ricevere informazioni da GKE sui tuoi cluster.

Per saperne di più, consulta Ricezione delle notifiche del cluster.

Controlla 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 offre visibilità sul processo di upgrade e include informazioni preziose per la risoluzione dei problemi, se necessario.

Log di upgrade del control plane

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

Entrambi i tipi di upgrade dei cluster possono causare la perdita della disponibilità del control plane 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 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 del control plane precedente 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 control plane utilizzato dopo l'upgrade.

Log di upgrade dei 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 i workload di sistema sui nodi worker per supportare funzionalità specifiche per i cluster. Ad esempio, il workload di sistema gke-metadata-server supporta Workload Identity Federation for GKE. GKE è responsabile dell'integrità di questi workload. Per scoprire di più su questi componenti, consulta la documentazione relativa alle funzionalità associate.

Quando sono 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 su come eseguire l'upgrade del control plane o dei nodi alla versione appropriata.

Passaggi successivi