Strategie di upgrade dei nodi

Questa pagina illustra le strategie di upgrade dei nodi che puoi utilizzare con i tuoi cluster Google Kubernetes Engine (GKE).

Nei cluster GKE Standard, puoi configurare una delle seguenti strategie di upgrade dei nodi per ogni pool di nodi:

  • Upgrade di picco: l'upgrade dei nodi viene eseguito in una finestra temporale continua. Puoi controllare quanti nodi possono essere aggiornati contemporaneamente e quanto sono invasivi gli upgrade per i carichi di lavoro.
  • Upgrade blu/verde: i nodi esistenti vengono mantenuti disponibili per il rollback mentre i carichi di lavoro vengono convalidati nella nuova configurazione dei nodi.

Nei cluster Autopilot, GKE utilizza gli upgrade di sovraccarico. Per saperne di più, consulta la sezione Upgrade di Surge della pagina degli upgrade dei cluster Autopilot.

Scegliendo una strategia di upgrade per il tuo pool di nodi cluster Standard, puoi selezionare il processo con il giusto equilibrio tra velocità, interruzione dei carichi di lavoro, mitigazione del rischio e ottimizzazione dei costi. Per scoprire di più sulla strategia di upgrade dei nodi più adatta al tuo ambiente, consulta Scegliere gli upgrade di incremento e Scegliere gli upgrade blu/verde.

Con entrambe le strategie, puoi configurare le impostazioni di upgrade per ottimizzare il processo in base alle esigenze del tuo ambiente. Per saperne di più, consulta Configurare la strategia di upgrade scelta. Assicurati che, per la strategia che scegli, la quota, la disponibilità delle risorse o la capacità di prenotazione siano sufficienti per eseguire l'upgrade dei nodi utilizzando questa strategia. Per maggiori informazioni, consulta Garantire le risorse per gli upgrade dei nodi.

Upgrade di Surge

Gli upgrade di Surge sono la strategia predefinita, ideale per le applicazioni in grado di gestire modifiche incrementali. Gli upgrade di Surge utilizzano un metodo in sequenza per eseguire l'upgrade dei nodi. Trova l'equilibrio ottimale tra velocità e interruzione per il tuo ambiente scegliendo il numero di nuovi nodi di picco che è possibile creare con maxSurge e quanti nodi esistenti possono essere interrotti contemporaneamente con maxUnavailable.

Gli upgrade di Surge funzionano anche con il gestore della scalabilità automatica dei cluster per impedire modifiche ai nodi in fase di upgrade.

Scegli gli upgrade di sovraccarico per il tuo ambiente

Se l'ottimizzazione dei costi è importante per te e il tuo carico di lavoro può tollerare l'arresto in meno di 60 minuti, ti consigliamo di scegliere upgrade di incremento per i pool di nodi.

Gli upgrade di Surge sono la soluzione ottimale per i seguenti scenari:

  • per ottimizzare la velocità degli upgrade.
  • i carichi di lavoro tollerano meglio le interruzioni, dove è accettabile una terminazione controllata fino a 60 minuti.
  • se vuoi controllare i costi riducendo al minimo la creazione di nuovi nodi.

Quando GKE utilizza gli upgrade di sovraccarico

Se l'opzione è abilitata, GKE utilizza gli upgrade di picco quando si verificano i seguenti tipi di modifiche:

Le altre modifiche, inclusa l'applicazione di aggiornamenti alle etichette dei nodi e alle incompatibilità dei pool di nodi esistenti, non utilizzano gli upgrade di picco perché non richiedono la nuova creazione dei nodi.

Informazioni sulle impostazioni di upgrade di Surge

Utilizza le impostazioni di upgrade di incremento per selezionare l'equilibrio appropriato tra velocità e interruzione per il pool di nodi durante la manutenzione del cluster utilizzando le impostazioni di incremento. Puoi cambiare il numero di nodi GKE tenta di eseguire l'upgrade contemporaneamente modificando i parametri di upgrade di picco in un pool di nodi Standard.

Il comportamento di upgrade di picco è determinato dalle impostazioni maxSurge e maxUnavailable, che determinano quanti nodi vengono aggiornati contemporaneamente in una finestra continuativa con i passaggi descritti.

maxSurge: GKE crea un nuovo nodo di picco prima di rimuoverne uno esistente

Imposta maxSurge per scegliere il numero massimo di nodi di picco aggiuntivi che possono essere aggiunti al pool di nodi durante un upgrade, per zona, aumentando la probabilità che i carichi di lavoro in esecuzione sul nodo esistente possano eseguire immediatamente la migrazione su un nuovo nodo. Il valore predefinito è uno. Per eseguire l'upgrade di un nodo, GKE esegue questi passaggi:

  1. Eseguire il provisioning di un nuovo nodo.
  2. Attendi che il nuovo nodo sia pronto.
  3. Esegui il Cordon del nodo esistente.
  4. Svuota il nodo esistente, rispettando le impostazioni di PodDisruptionBudget e GracefulTerminationPeriod per un massimo di un'ora.
  5. Eliminare il nodo esistente.

Affinché GKE possa creare nodi di sovraccarico, il tuo progetto deve disporre delle risorse per creare temporaneamente nodi aggiuntivi. Se non disponi di capacità aggiuntiva, GKE non avvia l'upgrade di un nodo finché le risorse non sono disponibili. Per scoprire di più, consulta Risorse per upgrade di sovraccarico.

maxUnavailable: GKE rende un nodo esistente non disponibile per ricrearlo

Imposta maxUnavailable per scegliere il numero massimo di nodi che possono essere contemporaneamente non disponibili durante un upgrade, per zona. Il valore predefinito è zero. I carichi di lavoro in esecuzione sul nodo esistente potrebbero dover attendere l'upgrade del nodo esistente, se nessun altro nodo ha capacità disponibile. Per eseguire l'upgrade di un nodo, GKE svolge i seguenti passaggi:

  1. Esegui cordon il nodo esistente.
  2. Svuota il nodo esistente, rispettando le impostazioni di PodDisruptionBudget e GracefulTerminationPeriod per un massimo di un'ora.
  3. Ricrea il nodo esistente con la nuova configurazione.
  4. Attendi che il nodo esistente sia pronto.
  5. Contrassegna il nodo esistente di cui è stato eseguito l'upgrade.

Quando GKE ricrea il nodo esistente, GKE rilascia temporaneamente la capacità del nodo se non proviene da una prenotazione. Ciò significa che se la capacità è limitata, rischi di perdere quella esistente. Quindi, se il tuo ambiente è vincolato dalle risorse, utilizza questa impostazione solo se impieghi nodi riservati. Per scoprire di più, consulta Eseguire l'upgrade in un ambiente con risorse limitate.

Esempio di utilizzo delle impostazioni maxSurge e maxUnavailable

Ad esempio, un cluster GKE ha un pool di nodi a zona singola con 5 nodi e la seguente configurazione di upgrade di picco: maxSurge=2;maxUnavailable=1.

Durante un upgrade di sovraccarico con questo pool di nodi, in una finestra temporale continua GKE crea due nodi di cui è stato eseguito l'upgrade e interrompe al massimo un nodo esistente alla volta. Quando i nodi sottoposti ad upgrade sono pronti, GKE arresta i nodi al massimo. Durante il processo di upgrade, il pool di nodi includerà tra quattro e sette nodi.

Considerazioni sulle impostazioni di upgrade di Surge

Prima di configurare le impostazioni di upgrade di Surge, considera le seguenti informazioni:

Ottimizza le impostazioni di upgrade di Surge per bilanciare velocità e interruzioni

La seguente tabella descrive quattro diversi profili di upgrade come esempi per aiutarti a comprendere le diverse configurazioni:

Descrizione Configurazione Caso d'uso tipico
Bilanciata (predefinita), più lenta ma meno invasiva maxSurge=1 maxUnavailable=0 La maggior parte dei carichi di lavoro
Veloce, senza risorse di picco, più dirompente maxSurge=0 maxUnavailable=20 Pool di nodi di grandi dimensioni dopo che i job devono essere eseguiti fino al completamento
Veloce, con la maggior parte delle risorse di picco e meno fastidiose maxSurge=20 maxUnavailable=0 Pool di nodi grandi
Risorse più lente, invasive e senza sovratensione maxSurge=0 maxUnavailable=1 Pool di nodi limitato dalle risorse con prenotazione

Bilanciata (valore predefinito)

Il modo più semplice per sfruttare gli upgrade di sovraccarico è utilizzare la configurazione predefinita, maxSurge=1;maxUnavailable=0.. Con questa configurazione, gli upgrade avanzano lentamente, con un solo nodo di incremento alla volta, ovvero viene eseguito l'upgrade di un solo nodo alla volta. I pod possono riavviarsi sul nuovo nodo di picco. Questa configurazione richiede alle risorse solo di creare temporaneamente un nuovo nodo.

Risorse veloci e senza sovratensione

Se hai un pool di nodi di grandi dimensioni e il tuo carico di lavoro non è sensibile alle interruzioni (ad esempio, un job batch è stato eseguito fino al completamento), utilizza la configurazione seguente per massimizzare la velocità senza utilizzare risorse aggiuntive: maxSurge=0;maxUnavailable=20. Questa configurazione non attiva ulteriori nodi di picco e consente l'upgrade di 20 nodi contemporaneamente.

Veloce e meno invasivo

Se il tuo carico di lavoro è sensibile alle interruzioni, hai già configurato PodDisruptionBudgets (PDB) e non utilizzi externalTrafficPolicy: Local, che non funziona con lo svuotamento dei nodi parallelo, puoi aumentare la velocità dell'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. Questa configurazione richiede alle risorse di creare temporaneamente 20 nuovi nodi.

Risorse lente ma senza sovratensione

Se non puoi utilizzare risorse aggiuntive, puoi utilizzare maxSurge=0;maxUnavailable=1 per ricreare un nodo alla volta.

Controllo di un upgrade di picco in corso

Con gli upgrade di Surge, mentre è in corso un upgrade puoi utilizzare i comandi per esercitarne il controllo. Per un maggiore controllo sul processo di upgrade, ti consigliamo di utilizzare gli upgrade blu/verde.

Annullamento (pausa) di un upgrade di Sorge

Puoi annullare un upgrade di incremento in corso in qualsiasi momento durante il processo di upgrade. L'annullamento mette in pausa l'upgrade, interrompendo GKE dall'upgrade dei nuovi nodi, ma non esegue automaticamente il rollback dei nodi di cui è già stato eseguito l'upgrade. Dopo aver annullato un upgrade, puoi ripristinarlo o ripristinarlo.

Quando annulli un upgrade, GKE esegue le seguenti operazioni con ciascuno dei nodi:

  • I nodi che hanno avviato l'upgrade lo completano.
  • I nodi che non hanno avviato l'upgrade non vengono aggiornati.
  • I nodi che hanno già completato l'upgrade non sono interessati e non ne viene eseguito il rollback.

Ciò significa che il pool di nodi potrebbe trovarsi in uno stato in cui i nodi eseguono due versioni diverse. Se sono abilitati upgrade automatici per il pool di nodi, quest'ultimo può essere pianificato di nuovo per l'upgrade automatico, eseguendo l'upgrade dei nodi rimanenti nel pool che esegue la versione precedente.

Scopri come annullare l'upgrade di un pool di nodi.

Riprendi un upgrade di Surge

Se l'upgrade di un pool di nodi è stato annullato e ne è stato lasciato parzialmente l'upgrade, puoi riprendere l'upgrade per completare il processo per il pool di nodi. Verrà eseguito l'upgrade di tutti i nodi rimanenti di cui non è stato eseguito l'upgrade nell'operazione originale. Scopri come riprendere l'upgrade di un pool di nodi.

Esegui il rollback di un upgrade di sovraccarico

Se viene eseguito l'upgrade parziale di un pool di nodi, puoi eseguire il rollback del pool di nodi per riportarlo allo stato precedente. Non puoi eseguire il rollback dei pool di nodi una volta eseguito l'upgrade. I nodi che non hanno avviato un upgrade non sono interessati. Scopri come eseguire il rollback di un upgrade di un pool di nodi.

Se vuoi eseguire il downgrade di un pool di nodi alla versione precedente dopo che l'upgrade è già stato completato, consulta Eseguire il downgrade dei pool di nodi.

Upgrade blu/verde

Gli upgrade blu/verde sono una strategia di upgrade alternativa alla strategia di upgrade di picco predefinita. Con gli upgrade blu/verde, GKE crea prima un nuovo set di risorse dei nodi (nodi "verdi") con la nuova configurazione, prima di rimuovere eventuali carichi di lavoro sulle risorse originali (nodi "blu"). Se necessario, GKE mantiene le risorse "blu" per il rollback dei carichi di lavoro. Puoi regolare il ritmo degli upgrade e il tempo di attesa in base alle esigenze del tuo ambiente.

Con questa strategia, hai un maggiore controllo sul processo di upgrade. Puoi eseguire il rollback di un upgrade in corso, se necessario, poiché l'ambiente originale viene mantenuto durante l'upgrade. Questa strategia di upgrade, tuttavia, richiede anche un maggior numero di risorse. Poiché l'ambiente originale viene replicato, il pool di nodi utilizza il doppio del numero di risorse durante l'upgrade.

Scegli upgrade blu/verde per il tuo ambiente

Se hai carichi di lavoro di produzione ad alta disponibilità di cui devi poter eseguire il rollback rapido nel caso in cui il carico di lavoro non tollera l'upgrade e se è accettabile un aumento temporaneo dei costi, ti consigliamo di scegliere upgrade blu/verde per i tuoi pool di nodi.

Gli upgrade blu/verde sono ottimali per i seguenti scenari:

  • se vuoi un'implementazione graduale in cui la mitigazione del rischio è più importante, dove è necessaria una terminazione tolleranza superiore a 60 minuti.
  • se i tuoi carichi di lavoro sono meno tolleranti alle interruzioni.
  • qualora sia accettabile un aumento temporaneo dei costi dovuto a un maggiore utilizzo delle risorse.

Quando GKE utilizza gli upgrade blu/verde

Per i nodi GKE, esistono diversi tipi di modifiche alla configurazione che richiedono di ricreare i nodi. Se l'opzione è abilitata, GKE utilizza gli upgrade blu/verde quando si verificano i seguenti tipi di modifiche:

Gli upgrade di Surge vengono utilizzati per tutte le altre funzionalità che richiedono la nuova creazione dei nodi. Per scoprire di più, consulta Quando vengono utilizzati upgrade di Surge.

Fasi degli upgrade blu/verde

Con gli upgrade blu/verde, puoi personalizzare e controllare il processo:

Questa sezione illustra le fasi del processo di upgrade. Puoi utilizzare le impostazioni di upgrade per ottimizzare il funzionamento delle fasi e i comandi per controllare il processo di upgrade.

Fase 1: creazione di un pool verde

In questa fase, viene creato un nuovo insieme di gruppi di istanze gestite, noti come pool "verde", per ogni zona nel pool di destinazione con la nuova configurazione dei nodi (nuova versione o tipo di immagine).

La quota verrà verificata prima di iniziare il provisioning di nuove risorse verdi.

In questa fase, i gruppi di istanze gestite originali, noti come pool blu, del gestore della scalabilità automatica del cluster smetteranno di fare lo scale up o lo scale down. Il pool verde può fare lo scale up solo in questa fase.

In questa fase, puoi annullare l'upgrade, se necessario. Quando annulli un upgrade blu/verde, l'upgrade viene messo in pausa nella fase attuale. Dopo l'annullamento, puoi ripristinarlo o ripristinarlo. In questa fase, il rollback eliminerà il pool verde.

Fase 2: piscina blu non pianificabile

In questa fase, tutti i nodi originali nel pool blu (i gruppi di istanze gestite esistenti) verranno non pianificabili (contrassegnati come non pianificabili). I carichi di lavoro esistenti continueranno a essere eseguiti, ma i nuovi carichi di lavoro non verranno pianificati sui nodi esistenti.

In questa fase, puoi annullare l'upgrade, se necessario. Quando annulli un upgrade blu/verde, l'upgrade viene messo in pausa nella fase attuale. Dopo l'annullamento, puoi ripristinarlo o ripristinarlo. In questa fase, il rollback annullerà il pool blu ed eliminerà quello verde.

Fase 3: svuota il pool blu

In questa fase, i nodi originali nel pool blu (i gruppi di istanze gestite esistenti) verranno svuotati in batch. Quando Kubernetes svuota i nodi, le richieste di rimozione vengono inviate a tutti i pod in esecuzione su di essi. I pod verranno ripianificati. Per i pod con violazioni di PodDisruptionBudget o con una lunga terminationGracePeriodSeconds durante lo svuotamento, verranno eliminati nella fase Elimina pool blu quando il nodo viene eliminato. Puoi utilizzare BATCH_SOAK_DURATION e NODE_POOL_SOAK_DURATION, descritti qui e nella sezione successiva, per estendere il periodo prima dell'eliminazione dei pod.

Puoi controllare le dimensioni dei batch con una delle seguenti impostazioni:

  • BATCH_NODE_COUNT: il numero assoluto di nodi da svuotare in un batch.
  • BATCH_PERCENT: la percentuale di nodi da svuotare in un batch, espressa con un numero decimale compreso tra 0 e 1 inclusi. GKE arrotonda per difetto alla percentuale di nodi più vicina, a un valore minimo di 1 nodo, se la percentuale non è un numero intero di nodi.

Se una di queste impostazioni è impostata su zero, GKE salta questa fase e passa alla fase Soak pool di nodi.

Inoltre, puoi controllare per quanto tempo ogni svuotamento batch rimane in attesa con BATCH_SOAK_DURATION. Questa durata è definita in secondi, con il valore predefinito di zero secondi.

In questa fase, puoi comunque annullare l'upgrade, se necessario. Quando annulli un upgrade blu/verde, viene messo in pausa nella fase attuale. Dopo l'annullamento, puoi ripristinarlo o ripristinarlo. In questa fase, il rollback interromperà il svuotamento del pool blu e lo scollegherà il pool blu. I carichi di lavoro possono quindi essere ripianificati sul pool blu (non garantito) e il pool verde verrà eliminato.

Fase 4: operazioni di "blocco del pool di nodi"

Questa fase consente di verificare l'integrità del carico di lavoro dopo lo svuotamento dei nodi blu del pool.

Il tempo di attesa è impostato su NODE_POOL_SOAK_DURATION, in secondi. Per impostazione predefinita, è impostato su un'ora (3600 secondi). Se la durata totale di soak raggiunge 7 giorni (604.800 secondi), la fase Elimina pool blu inizia immediatamente.

La durata totale dell'operazione è data dalla somma di NODE_POOL_SOAK_DURATION, più BATCH_SOAK_DURATION moltiplicata per il numero di batch, che viene determinato da BATCH_NODE_COUNT o BATCH_PERCENT.

In questa fase, puoi completare l'upgrade e saltare l'eventuale tempo di attesa rimanente completando l'upgrade. Il processo di rimozione dei nodi del pool blu verrà avviato immediatamente.

Se necessario, puoi comunque annullare l'upgrade. Quando annulli un upgrade blu/verde, questo viene messo in pausa nella fase attuale. Dopo l'annullamento, puoi ripristinarlo o ripristinarlo.

In questa fase, il gestore della scalabilità automatica dei cluster può ora fare lo scale up o lo scale down del green pool normalmente.

Fase 5: eliminazione del pool blu

Dopo la scadenza del tempo di immersione, i nodi del pool blu verranno rimossi dal pool di destinazione. Questa fase non può essere messa in pausa. Inoltre, questa fase non utilizza l'eliminazione, ma tenta di eliminare i pod. A differenza dell'eliminazione, l'eliminazione non rispetta i PDB ed elimina forzatamente i pod. L'eliminazione limita il valore terminationGracePeriodSeconds di un pod a un massimo di 60 minuti. Dopo questo tentativo finale di eliminare i pod rimanenti, i nodi del pool blu vengono eliminati dal pool di nodi.

Al termine di questa fase, il pool di nodi avrà solo nuovi nodi con la configurazione aggiornata (versione o tipo di immagine).

Come funziona il gestore della scalabilità automatica dei cluster con gli upgrade blu/verde

Durante le fasi di un upgrade blu/verde, il pool "blu" originale non esegue lo scale up o lo scale down. Quando viene creato il nuovo pool "verde", è possibile fare lo scale up solo fino alla fase del pool di nodi Soak, dove è possibile fare lo scale up o lo scale down. Se viene eseguito un rollback di un upgrade, il pool "blu" originale potrebbe fare lo scale up durante questo processo se è necessaria ulteriore capacità.

Controlla un upgrade blu/verde in corso

Con gli upgrade blu/verde, mentre è in corso un upgrade puoi usare i comandi per controllarlo. Questo ti offre un elevato livello di controllo sul processo nel caso in cui stabilisca, ad esempio, che i carichi di lavoro devono essere riportati alla configurazione del nodo precedente.

Annullare (pausa) un upgrade blu/verde

Quando annulli un upgrade blu/verde, lo metti in pausa nella fase attuale. Questo comando può essere utilizzato in tutte le fasi, tranne che nella fase Elimina pool blu. Se annullato, il pool di nodi verrà messo in pausa in uno stato intermedio in base alla fase in cui è stata emessa la richiesta.

Scopri come annullare l'upgrade di un pool di nodi.

Dopo l'annullamento di un upgrade, puoi scegliere uno dei due percorsi in avanti disponibili: riprendi o rollback.

Riprendi un upgrade blu/verde

Se hai stabilito che l'upgrade può essere completato, puoi riprenderlo.

Se riprendi, il processo di upgrade continuerà nella fase intermedia in cui era stato messo in pausa. Per scoprire come riprendere l'upgrade di un pool di nodi, consulta Riprendere l'upgrade di un pool di nodi.

Esegui il rollback di un upgrade blu/verde

Se hai stabilito che l'upgrade non dovrebbe andare avanti e vuoi riportare il pool di nodi allo stato originale, puoi eseguire il rollback. Per scoprire come eseguire il rollback di un upgrade di un pool di nodi, consulta Eseguire il rollback di un upgrade di un pool di nodi.

Con il flusso di lavoro di rollback, il processo si inverte per riportare il pool di nodi allo stato originale. Il pool blu non sarà pianificato in modo che i carichi di lavoro possano essere ripianificati per il pool. Durante questo processo, il gestore della scalabilità automatica dei cluster può fare lo scale up del pool blu in base alle esigenze. Il pool verde verrà svuotato ed eliminato.

Se vuoi eseguire il downgrade di un pool di nodi alla versione precedente dopo che l'upgrade è già stato completato, consulta Eseguire il downgrade dei pool di nodi.

Completa un upgrade blu/verde

Durante la fase di soak, puoi completare un upgrade se hai stabilito che il carico di lavoro non richiede un'ulteriore convalida della nuova configurazione dei nodi e che i nodi precedenti possono essere rimossi. Il completamento di un upgrade ignora il resto della fase di soak e passa alla fase di eliminazione del pool blu.

Per saperne di più su come utilizzare il comando complete, consulta Completare un upgrade del pool di nodi blu/verde.

Passaggi successivi