Upgrade di cluster standard

Questa pagina illustra il funzionamento degli upgrade automatici e manuali Cluster Google Kubernetes Engine (GKE) Standard, con link a ulteriori informazioni su attività e impostazioni correlate. Puoi utilizzare queste informazioni per mantenere i tuoi cluster aggiornati e garantire stabilità e sicurezza con e interruzioni 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 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 cluster in un canale di rilascio, i nodi eseguono la stessa versione di GKE del cluster, in 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 del pool di nodi o se è stato eseguito manualmente l'upgrade 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.

  • Zonal di rete hanno un solo piano di controllo. Durante l'upgrade, i carichi di lavoro continuano a essere eseguiti, ma non puoi eseguirne il deployment carichi di lavoro esistenti o apportare altre modifiche alla configurazione del cluster l'upgrade è completo.

  • A livello di regione cluster hanno più repliche del piano di controllo e solo una replica viene eseguito simultaneamente, 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 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. Di per impostazione predefinita, l'upgrade dei nodi all'interno di un pool di nodi viene eseguito uno alla volta in ordine. In un pool di nodi distribuito zone, upgrade avvengono zona per zona. All'interno di una zona, l'upgrade dei nodi verrà eseguito in un ordine indefinito.

Con gli upgrade dei pool di nodi GKE, puoi scegliere tra due strategie di upgrade integrate e configurabili in cui puoi ottimizzare il processo di upgrade in base alle esigenze dell'ambiente del 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 i periodi di manutenzione 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 coerenti. 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 è 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 picco degli upgrade, GKE rispetta il PodDisruptionBudget del pod e GracefulTerminationPeriod impostazioni 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 ripianificati rimangono nella fase In attesa fino a quando non possono essere riprogrammato.

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 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 viene eseguito l'upgrade del pool di nodi. Per scoprire di più sui tipi di modifiche che utilizzano un nodo di upgrade, consulta Quando GKE utilizza un picco upgrade e Quando GKE utilizza blu/verde upgrade.

Upgrade di incremento

Per impostazione predefinita, la strategia di upgrade per picchi viene utilizzata per gli upgrade dei pool di nodi. 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 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 sono gli upgrade blu/verde, in cui due insiemi di ambienti (quello originale e quello nuovo) vengono gestiti contemporaneamente, semplificando il più possibile il rollback. Blu/verde richiede un maggiore utilizzo di risorse e migliore 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, i carichi di lavoro possono ha eseguito rapidamente il rollback allo stato "blu" esistente completamente gestito di Google Cloud.

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 e gli upgrade blu/verde 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 pool di nodi non dispone di risorse sufficienti, gli upgrade possono richiedere più tempo non riuscito.

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 di garantire il controllo del cluster aereo e upgrade dei cluster quando viene selezionata una nuova versione GKE 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 una manutenzione finestre ed esclusioni, per sospendere temporaneamente gli upgrade di piani di controllo e nodi.

Nell'ambito del modello di responsabilità condivisa GKE, sei responsabile della protezione di 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 i criteri relativi 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. Il pool di nodi determina anche le versioni dei pacchetti software installati su ciascun nodo. Ti consigliamo di mantenere aggiornati i pool di nodi 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.

I nuovi target dell'upgrade automatico sono annunciati nelle note di rilascio. Fino a quando sia selezionata la versione per l'upgrade automatico, puoi eseguire l'upgrade manuale. A volte, 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 in disponibilità generale, la più vecchia disponibile la versione secondaria in genere non è più supportata. Cluster che eseguono versioni secondarie che non saranno più supportate verrà 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 versione 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 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 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 con patch. Le versioni minori hanno periodi di attesa più lunghi in quanto introducono modifiche più significative.
  • GKE può ritardare gli upgrade automatici quando una nuova versione interessa un di 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 l'infrastruttura sicurezza. 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 stabilire quando gli upgrade automatici possono o non devono essere eseguiti.

Upgrade manuale

Puoi richiedere di eseguire in qualsiasi momento un upgrade manuale del cluster o dei relativi pool di nodi a una versione disponibile e compatibile. 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 di zona, il piano di controllo non è disponibile mentre è in corso l'upgrade. Nella maggior parte dei casi, i carichi di lavoro vengono eseguiti normalmente, ma non 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 i nodi in non viene eseguito l'upgrade del pool di nodi, GKE non esegue il rollback per i nodi con upgrade eseguito. 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 vanno a buon fine perché le richieste dei nodi di picco superano le risorse di Compute Engine quota, GKE riduce il numero di nodi di picco simultanei da tentare per raggiungere la quota e continuare l'upgrade.

Ricezione di notifiche di upgrade

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

Per ulteriori informazioni, vedi Ricezione di notifiche 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 cambia 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 dei cluster possono causare la perdita della disponibilità del piano di controllo per i cluster di zona. Per scoprire 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.
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 dell'upgrade del pool di nodi

Usa 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 per i cluster. Ad esempio, il sistema gke-metadata-server per i carichi di lavoro Federazione delle identità dei carichi di lavoro per GKE. GKE è responsabile l'integrità di questi carichi di lavoro. Per saperne di più su questi componenti, consulta: alla documentazione per le funzionalità associate.

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