Upgrade di cluster standard

Questa pagina illustra come funzionano gli upgrade automatici e manuali sui cluster Google Kubernetes Engine (GKE) Standard e include link a ulteriori informazioni su attività e impostazioni correlate. Puoi utilizzare queste informazioni per mantenere aggiornati i cluster in termini di stabilità e sicurezza con interruzioni minime dei carichi di lavoro.

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

Come funzionano gli upgrade dei cluster e dei 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 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 che per 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 il piano di controllo è stato eseguito manualmente. 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 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 regionali 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, se possibile, questa operazione viene rispettata.

Upgrade del pool di nodi

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ù pool di nodi in parallelo. Per impostazione predefinita, l'upgrade dei nodi in un pool di nodi viene eseguito uno alla volta in ordine arbitrario. In un pool di nodi distribuito in più zone, gli upgrade vengono eseguiti zona per zona. All'interno di una zona, verrà eseguito l'upgrade dei nodi in un ordine indefinito.

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

Durante un upgrade del 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 configurate.

Modalità di upgrade dei nodi

Durante un upgrade del pool di nodi, il modo in cui viene eseguito l'upgrade dei nodi dipende dalla strategia di upgrade del pool di nodi e da come la configuri. Tuttavia, i passaggi di base rimangono coerenti. Per eseguire l'upgrade di un nodo, GKE rimuove i pod dal nodo in modo da eseguirne l'upgrade.

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

  1. Il nodo è contrassegnato come non pianificabile in modo che Kubernetes non pianifica nuovi pod al suo interno.
  2. Il nodo viene quindi svuotato, il che significa che i pod vengono rimossi. Per gli upgrade di incremento, GKE rispetta le impostazioni di PodDisruptionBudget e GracefulTerminationPeriod del pod per un massimo di un'ora. Con gli upgrade blu/verde, questa può essere estesa se configuri un tempo di sospensione 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 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 comportare tempi più lunghi per il completamento dell'upgrade di un nodo includono:

Strategie di upgrade dei nodi

GKE offre strategie integrate configurabili 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, vedi Quando GKE utilizza upgrade di sovraccarico e Quando GKE utilizza upgrade blu/verdi.

Upgrade di Surge

Per impostazione predefinita, la strategia di upgrade dell'incremento viene utilizzata per gli upgrade del pool di nodi. Gli upgrade di sovraccarico utilizzano un metodo in sequenza per eseguire l'upgrade dei nodi. Questa strategia è ideale per le applicazioni in grado di gestire modifiche incrementali non di disturbo. Con questa strategia, viene eseguito l'upgrade dei nodi in una finestra temporale continua. Con le impostazioni puoi modificare il numero di nodi di cui è possibile eseguire l'upgrade contemporaneamente e il livello di disturbo degli upgrade, trovando l'equilibrio ottimale tra velocità e interruzione per le esigenze del tuo ambiente.

Upgrade blu/verde

L'approccio alternativo sono gli upgrade blu/verde, in cui vengono gestiti contemporaneamente due insiemi di ambienti (l'ambiente originale e quello nuovo), rendendo il rollback il più semplice possibile. Il blu/verde richiede più risorse ed è migliore per le applicazioni più sensibili alle modifiche. Con questa strategia, i carichi di lavoro vengono gradualmente migrati dall'ambiente "blu" originale al nuovo ambiente "verde" e viene loro concesso il tempo di sospensione 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 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. Gli upgrade blu/verdi 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 pool di nodi non ha risorse sufficienti, gli upgrade possono richiedere più tempo o non riuscire.

Per ulteriori informazioni su come assicurarti che il progetto abbia risorse sufficienti per gli upgrade dei nodi e su cosa fare se il tuo ambiente è vincolato alle risorse, consulta Garantire le risorse per gli upgrade dei nodi.

Upgrade automatico

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

GKE è responsabile di proteggere il piano di controllo del cluster e di eseguire l'upgrade dei cluster quando viene selezionata una nuova versione di GKE per l'upgrade automatico. La sicurezza dell'infrastruttura ha una priorità elevata per GKE e, di conseguenza, l'upgrade dei piani di controllo viene eseguito regolarmente e non può essere disabilitato. Tuttavia, puoi applicare finestre di manutenzione ed esclusioni per sospendere temporaneamente gli upgrade per nodi e piani di controllo.

Nell'ambito del modello di responsabilità condivisa di GKE, hai la responsabilità della sicurezza di nodi, container e 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, hai la responsabilità di garantire 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ò verificarsi (o non deve avvenire) un upgrade automatico, puoi configurare periodi di manutenzione ed esclusioni.

Per mantenere la compatibilità con l'API del cluster, i pool di nodi di un cluster non possono essere più di due versioni secondarie dietro la versione del piano di controllo. 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 che per 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. Consulta le note di rilascio per ulteriori informazioni.

Come vengono selezionate le versioni per l'upgrade automatico

Le nuove versioni di GKE vengono rilasciate regolarmente, ma non è selezionata una versione per l'upgrade automatico immediato. Quando una versione di GKE ha accumulato un utilizzo sufficiente del cluster per dimostrarne 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 dell'upgrade automatico sono annunciati nelle note di rilascio. Finché non selezioni una versione disponibile per l'upgrade automatico, puoi eseguire l'upgrade manuale. A volte, viene selezionata una versione per l'upgrade automatico del cluster e dei nodi in settimane diverse.

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

All'interno di una versione secondaria (ad esempio v1.14.x), è possibile eseguire l'upgrade automatico dei cluster a una nuova 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é gestire direttamente la versione.

Fattori che influenzano i tempi di implementazione della versione

Per garantire la stabilità e l'affidabilità dei cluster nelle nuove versioni, GKE segue alcune pratiche durante le implementazioni 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 concesso il tempo di sospensione nel canale di rilascio rapido, quindi nel canale di rilascio regolare, per poi passare al canale di rilascio Stabile dopo che ha accumulato utilizzo e continuato a dimostrare stabilità. Se viene rilevato un problema con una versione patch durante il periodo di sospensione su un canale di rilascio, la versione non viene promossa al canale successivo e il problema viene risolto su una versione più recente della patch.
  • GKE implementa gradualmente le versioni secondarie, seguendo un processo di sospensione simile alle versioni patch. Le versioni secondarie hanno periodi di sospensione più lunghi poiché introducono modifiche più significative.
  • GKE può ritardare gli upgrade automatici quando una nuova versione interessa 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 l'implementazione delle nuove versioni durante i periodi di punta (ad es. durante le festività più importanti) per garantire la continuità aziendale.

Configurare il momento in cui possono essere eseguiti gli upgrade automatici

Per impostazione predefinita, gli upgrade automatici possono avvenire 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 il momento in cui possono e non devono essere eseguiti gli upgrade automatici.

Upgrade manuale

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

Quando esegui l'upgrade manuale 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 a livello di regione, non è disponibile una replica del piano di controllo 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 agli errori di upgrade automatico

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

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

Quando si verificano problemi con gli upgrade dei singoli nodi, GKE esegue nuovamente l'upgrade alcune volte, con intervalli sempre più lunghi tra i nuovi tentativi. Se l'upgrade dei nodi nel pool di nodi non riesce, GKE non esegue il rollback dei nodi sottoposti ad upgrade. GKE esegue un nuovo upgrade automatico del pool di nodii fino al completamento dell'upgrade.

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

Ricezione di notifiche di upgrade

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

Per ulteriori informazioni, vedi Ricezione di notifiche cluster.

Controlla i log di upgrade

Per impostazione predefinita, gli eventi di upgrade del piano di controllo e del pool di nodi di GKE 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 di 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 logging strutturati. Per i dettagli degli eventi di upgrade, puoi utilizzare i seguenti campi:



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 che un aggiornamento 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 dei pool di nodi.
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 alla 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 di upgrade del 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 campo seguente 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 del sistema gke-metadata-server supporta la Federazione delle identità dei carichi di lavoro per GKE. GKE è responsabile dell'integrità di questi carichi di lavoro. Per saperne di più su questi componenti, consulta la documentazione relativa alle funzionalità associate.

Quando nuove funzionalità o correzioni diventano disponibili per un componente, GKE indica la versione 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