Upgrade di cluster standard


In questa pagina viene spiegato come funzionano gli upgrade automatici e manuali sui cluster standard di Google Kubernetes Engine (GKE), compresi i link a ulteriori informazioni su attività e impostazioni correlate. Puoi utilizzare queste informazioni per mantenere aggiornati i tuoi cluster per aumentare la stabilità e la sicurezza con interruzioni minime nei tuoi carichi di lavoro.

Per informazioni sul funzionamento degli upgrade dei cluster per Autopilot, consulta Upgrade dei cluster Autopilot.

Come funzionano gli upgrade dei cluster e dei pool di nodi

Questa sezione spiega cosa succede nel cluster durante gli upgrade automatici o manuali. Per gli upgrade automatici, Google avvia l'upgrade automatico. Google osserva gli upgrade automatici e manuali in tutti i cluster GKE e interviene in caso di problemi.

Se registri il tuo cluster in un canale di rilascio, i nodi eseguono sempre la stessa versione di GKE del cluster, ad eccezione di 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. Per ulteriori informazioni, consulta le note di rilascio.

Upgrade dei cluster

Questa sezione illustra cosa aspettarsi dall'upgrade automatico del tuo cluster da parte di Google o quando avvii un upgrade manuale.

  • I cluster zonal hanno un solo piano di controllo. Durante l'upgrade, i tuoi carichi di lavoro continuano a essere eseguiti, ma non puoi eseguire il deployment di nuovi carichi di lavoro, modificare i carichi di lavoro esistenti o apportare altre modifiche alla configurazione del cluster fino al completamento dell'upgrade.

  • I cluster a livello di area geografica hanno più repliche del piano di controllo e viene eseguita l'upgrade di una sola replica in un ordine non definito. Durante l'upgrade, il cluster rimane altamente disponibile e ogni replica del piano di controllo non è disponibile solo durante l'upgrade.

Se configuri un periodo di manutenzione o un'esclusione, questo verrà rispettato, se possibile.

Upgrade del pool di nodi

Il cluster e i relativi pool di nodi non eseguono necessariamente la stessa versione di GKE. Questa sezione spiega cosa aspettarsi quando Google esegue automaticamente l'upgrade del pool di nodi o se avvii un upgrade manuale del pool di nodi.

Viene eseguito l'upgrade dei pool di nodi uno alla volta. Per impostazione predefinita, viene eseguito l'upgrade dei nodi uno alla volta, in ordine non definito. Puoi cambiare il numero di nodi di cui è stato eseguito l'upgrade insieme agli upgrade di sovraccarico.

In un pool di nodi distribuito su più zone, gli upgrade avvengono una zona alla volta. All'interno di una zona, verrà eseguito l'upgrade dei nodi in ordine non definito.

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

Questo processo potrebbe richiedere diverse ore in base al numero di nodi e alle relative configurazioni del carico di lavoro. Le configurazioni che possono rallentare la frequenza degli upgrade dei nodi includono:

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

Quando GKE esegue l'upgrade di un nodo, si verifica quanto segue:

  1. Se sono abilitati gli upgrade di sovraccarico, GKE crea un nuovo nodo di sovraccarico con la versione aggiornata e attende che venga registrato con il piano di controllo.
  2. GKE seleziona un nodo esistente (il nodo di destinazione) per eseguire l'upgrade. Corona e inizia a drenare il nodo di destinazione. A questo punto, GKE non è in grado di pianificare nuovi pod sul nodo di destinazione.
    • PodDisruptionBudget viene rispettato per un massimo di un'ora. Se il nodo di destinazione non viene completamente svuotato dopo un'ora, GKE elimina i pod rimanenti e il processo di upgrade continua.
    • GracefulTerminaPeriod è limitato a un'ora.
  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 pianificati.
  4. Se è stato creato un nodo di sovraccarico, viene eliminato. Se non è stato creato un nodo di sovraccarico, GKE esegue l'upgrade del nodo di destinazione dopo averlo svuotato, quindi attende la registrazione del nodo aggiornato con il piano di controllo.

Upgrade automatico

Quando crei un cluster standard, l'upgrade automatico è abilitato per impostazione predefinita nel cluster e nei relativi pool di nodi.

Google è responsabile della protezione del piano di controllo del cluster e dell'upgrade dei cluster quando viene selezionata una nuova versione di GKE per l'upgrade automatico. La sicurezza dell'infrastruttura è la priorità assoluta per GKE, pertanto i piani di controllo vengono aggiornati regolarmente e non possono essere disabilitati. Tuttavia, puoi applicare periodi di manutenzione ed esclusioni per sospendere temporaneamente gli upgrade per i piani di controllo e i nodi.

Nel modello di responsabilità condivisa, sei responsabile della protezione dei nodi, dei container e dei pod. L'upgrade automatico dei nodi è abilitato per impostazione predefinita. Anche se non è 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 disabiliti gli upgrade automatici dei nodi, hai la responsabilità di assicurare 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 la versione e il disallineamento delle versioni di Kubernetes.

Per un maggiore controllo sui casi in cui può essere eseguito (o non deve essere eseguito) un upgrade automatico, puoi configurare i periodi di manutenzione e le esclusioni.

I pool di nodi di un cluster non possono superare le due versioni secondarie rispetto alla versione del piano di controllo, per mantenere la compatibilità con l'API del cluster. La versione del 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 che per un breve periodo di tempo (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 dato pool di nodi. Per ulteriori informazioni, consulta le note di rilascio.

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 del cluster sufficiente per dimostrare la stabilità nel tempo, Google la seleziona come target di upgrade automatico per i cluster che eseguono un sottoinsieme di versioni precedenti.

Nelle nuove note di rilascio vengono annunciati nuovi target di upgrade automatico. Finché non viene selezionata una versione disponibile per l'upgrade automatico, puoi eseguirla manualmente. A volte, è selezionata una versione per l'upgrade automatico dei cluster e l'upgrade automatico dei nodi durante settimane diverse.

Subito dopo l'introduzione di una nuova versione secondaria in genere, la versione secondaria predefinita diventa in genere non supportata. Per i cluster che eseguono versioni secondarie non più supportate viene eseguito l'upgrade automatico 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 della patch.

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

Configurare quando 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 improvvisi, soprattutto per i cluster a livello di area geografica. Tuttavia, alcuni carichi di lavoro potrebbero richiedere un controllo più granulare. Puoi configurare periodi di manutenzione ed esclusioni per gestire i casi in cui gli upgrade automatici possono e non devono avvenire.

Upgrade manuale

Puoi richiedere di eseguire manualmente l'upgrade del cluster o dei relativi pool di nodi a una versione disponibile e compatibile in qualsiasi momento. Gli upgrade manuali ignorano qualsiasi periodo di manutenzione ed esclusioni di manutenzione configurato.

Quando esegui l'upgrade manuale di un cluster, la sua disponibilità dipende dal fatto che il cluster sia a livello di area geografica 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 possono essere modificati durante l'upgrade.

  • Per i cluster a livello di area geografica, non è disponibile una replica del piano di controllo 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 piano di controllo.

Upgrade di sovraccarico

Gli upgrade di sovraccarico consentono di controllare il numero di nodi che GKE può eseguire contemporaneamente e di controllare quanto siano invasivi gli upgrade dei tuoi carichi di lavoro.

Modifica delle impostazioni di upgrade per bilanciare velocità e interruzione

Puoi cambiare il numero di nodi che GKE tenta di eseguire contemporaneamente una volta modificando i parametri dell'upgrade di sovraccarico in un pool di nodi. Gli upgrade di sovraccarico riducono le interruzioni dei carichi di lavoro durante la manutenzione del cluster e ti consentono anche di controllare il numero di nodi di cui è stato eseguito l'upgrade in parallelo. Gli upgrade di sovraccarico funzionano anche con il gestore della scalabilità automatica dei cluster per impedire modifiche ai nodi in fase di upgrade.

Il comportamento di upgrade di sovraccarico è determinato da due impostazioni:

max-surge-upgrade

Il numero di nodi aggiuntivi che possono essere aggiunti al pool di nodi durante un upgrade. L'aumento di max-surge-upgrade aumenta il numero di nodi di cui è possibile eseguire l'upgrade contemporaneamente. Il valore predefinito è 1. Può essere impostato su 0 o un valore superiore.

max-unavailable-upgrade

Il numero di nodi che possono essere contemporaneamente non disponibili durante un upgrade. Il valore predefinito è 0. L'aumento di max-unavailable-upgrade aumenta il numero di nodi di cui è possibile eseguire l'upgrade in parallelo.

Il numero di nodi di cui è stato eseguito l'upgrade simultaneo è la somma di max-surge-upgrade e max-unavailable-upgrade. Il numero massimo di nodi di cui è stato eseguito l'upgrade contemporaneamente è limitato a 20.

Ad esempio, viene creato un pool a 5 nodi con max-surge-upgrade impostato su 2 e max-unavailable-upgrade impostato su 1. Durante un upgrade del pool di nodi, GKE crea due nodi di cui è stato eseguito l'upgrade. GKE riduce al massimo tre (la somma di max-surge-upgrade e max-unavailable-upgrade) dei nodi esistenti quando i nodi di cui è stato eseguito l'upgrade sono pronti. GKE renderà disponibile solo un nodo alla volta (max-unavailable-upgrade) alla volta. Durante la procedura di upgrade, il pool di nodi includerà da quattro a sette nodi.

Puoi configurare i parametri di upgrade di sovraccarico per i pool di nodi che utilizzano gli upgrade automatici e gli upgrade manuali. Per ulteriori informazioni e provare Surge Upgrade, completa il tutorial "Utilizza Surge Upgrade per ridurre le interruzioni da upgrade dei nodi GKE.

Determinazione della configurazione di incremento ottimale

La seguente tabella descrive tre diverse impostazioni di upgrade come dimostrazione per aiutarti a comprendere le diverse configurazioni:

Descrizione Configurazione
Bilanciata (impostazione predefinita), più lenta, ma meno invasiva maxSurge=1 maxUnavailable=0
Veloce, nessuna sovratensione, risorse rivoluzionarie maxSurge=0 maxUnavailable=20
Veloci, principali risorse a picco e meno interruzioni maxSurge=20 maxUnavailable=0

Bilanciata (impostazione predefinita)

Il modo più semplice per usufruire dell'upgrade di sovraccarico è configurare maxSurge=1 maxUnavailable=0. Questo significa che è possibile aggiungere un solo nodo di sovraccarico al pool di nodi durante un upgrade, quindi verrà eseguito l'upgrade di un solo nodo alla volta. Questa impostazione è superiore alla configurazione di upgrade esistente (maxSurge=0 maxUnavailable=1) perché accelera il riavvio dei pod durante gli upgrade mentre avanza in modo prudente.

Risorse veloci e senza picchi

Se il tuo carico di lavoro non è sensibile a interruzioni, come la maggior parte dei job batch, puoi utilizzare la velocità maxSurge=0 maxUnavailable=20 per enfatizzare la velocità. Questa configurazione non conduce altri nodi di sovraccarico e consente di eseguire l'upgrade di 20 nodi contemporaneamente.

Veloce e meno fastidioso

Se il tuo carico di lavoro è sensibile all'interruzione e hai già configurato PodDisruptionBudget (PDB) e non utilizzi externalTrafficPolicy: Local, non funziona con gli svuotamenti dei nodi paralleli, puoi aumentare la velocità di upgrade utilizzando maxSurge=20 maxUnavailable=0. Questa configurazione esegue l'upgrade di 20 nodi in parallelo, mentre il PDB limita il numero di pod che possono essere svuotati in un determinato momento. Anche se le configurazioni dei PDB possono variare, se crei un PDB con maxUnavailable: 1 per uno o più carichi di lavoro in esecuzione sul pool di nodi, puoi rimuovere un solo pod di questi carichi di lavoro alla volta, limitando il parallelismo dell'intero upgrade.

Relazione con quota

Anche se la ricreazione dei nodi non richiede risorse di Compute Engine aggiuntive, il sovraccarico richiede un aggiornamento dei nodi. L'allocazione delle risorse è soggetta alla quota di Compute Engine. A seconda della configurazione, questa quota può limitare il numero di upgrade paralleli o anche causare l'esito negativo dell'upgrade.

Per ulteriori informazioni sulle quote, consulta questa pagina relativa a Upgrade e quota di nodi.

Modalità di risposta di GKE all'errore di upgrade automatico

Gli upgrade automatici dei pool di nodi possono non riuscire a causa di problemi con le istanze di Compute Engine sottostanti o di problemi 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 si sono registrati con il piano di controllo del cluster.
  • Lo svuotamento dei nodi ha richiesto troppo tempo o l'eliminazione ha richiesto troppo tempo.

Quando si verificano problemi con i singoli upgrade dei nodi, GKE riprova l'upgrade alcune volte, con un intervallo 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 invece di nuovo 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 sovraccarico superano la quota di Compute Engine, GKE riduce il numero di nodi di sovraccarico simultanee per tentare di raggiungere la quota e continuare l'upgrade.

Ricevere notifiche di upgrade

GKE pubblica notifiche su eventi pertinenti per il tuo cluster, ad esempio gli upgrade delle versioni e i bollettini sulla sicurezza, in Pub/Sub, fornendoti un canale per ricevere informazioni da GKE sui tuoi cluster.

Per ulteriori informazioni, vedi Ricezione di notifiche del cluster.

Passaggi successivi