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 per picchi: l'upgrade dei nodi viene eseguito in una finestra mobile. Puoi controllare quanti nodi possono essere sottoposti ad upgrade contemporaneamente e quanto gli upgrade influiscono sui carichi di lavoro.
  • Upgrade blue-green: i nodi esistenti vengono mantenuti disponibili per il rollback mentre i carichi di lavoro vengono convalidati nella nuova configurazione del nodo.

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

Scegliendo una strategia di upgrade per il pool di nodi del cluster standard, puoi selezionare il processo con il giusto equilibrio tra velocità, interruzione dei carichi di lavoro, mitigazione dei rischi e ottimizzazione dei costi. Per scoprire di più sulla strategia di upgrade dei node più adatta al tuo ambiente, consulta Scegliere gli upgrade per i picchi di domanda 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 scoprire di più, consulta Configurare la strategia di upgrade scelta. Assicurati che per la strategia scelta tu disponga di quota, disponibilità di risorse o capacità di prenotazione sufficienti per eseguire l'upgrade dei tuoi nodi utilizzando questa strategia. Per ulteriori informazioni, consulta Garantire le risorse per gli upgrade dei nodi.

Upgrade di incremento

Gli upgrade di picco sono la strategia di upgrade predefinita e sono ideali per le applicazioni che possono gestire modifiche incrementali. Gli upgrade di picco utilizzano un metodo incrementale per eseguire l'upgrade dei nodi in un ordine indefinito. Trova il giusto equilibrio tra velocità e interruzione per il tuo ambiente scegliendo quanti nuovi nodi di picco possono essere creati con maxSurge e quanti nodi esistenti possono essere interrotti contemporaneamente con maxUnavailable.

Gli upgrade di picco funzionano anche con il gestore della scalabilità automatica del cluster per impedire modifiche ai nodi su cui viene eseguito l'upgrade.

Scegliere gli upgrade per i picchi per il tuo ambiente

Se l'ottimizzazione dei costi è importante per te e il tuo workload può tollerare l'interruzione in meno di 60 minuti, ti consigliamo di scegliere gli upgrade per picchi per i tuoi pool di nodi.

Gli upgrade per picchi sono ottimali per i seguenti scenari:

  • se vuoi ottimizzare per la velocità degli upgrade.
  • se i carichi di lavoro sono più tolleranti alle interruzioni, dove è accettabile un'interruzione graduale fino a 60 minuti.
  • Se vuoi controllare i costi riducendo al minimo la creazione di nuovi nodi.

Quando GKE utilizza gli upgrade di picco

Se abilitato, GKE utilizza gli upgrade di picco quando si verificano i seguenti tipi di modifiche:

Altre modifiche, tra cui l'applicazione di aggiornamenti alle etichette e ai taint dei pool di nodi esistenti, non utilizzano gli upgrade di picco perché non richiedono la ricreazione dei nodi.

Informazioni sulle impostazioni di upgrade di sovraccarico

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

Il comportamento dell'upgrade di picco è determinato dalle impostazioni maxSurge e maxUnavailable, che determinano il numero di nodi di cui viene eseguito l'upgrade contemporaneamente in una finestra mobile 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 workload in esecuzione sul nodo esistente possano eseguire la migrazione a un nuovo nodo immediatamente. Il valore predefinito è 1. Per eseguire l'upgrade di un nodo, GKE esegue i seguenti passaggi:

  1. Esegui il provisioning di un nuovo nodo.
  2. Attendi che il nuovo nodo sia pronto.
  3. Contrassegna il nodo esistente come non pianificabile.
  4. Drain il nodo esistente, rispettando le impostazioni di PodDisruptionBudget e GracefulTerminationPeriod per un massimo di un'ora.
  5. Elimina il nodo esistente.

Affinché GKE possa creare nodi di picco, il progetto deve disporre delle risorse per creare temporaneamente nodi aggiuntivi. Se non hai capacità aggiuntiva, GKE non inizierà l'upgrade di un nodo finché le risorse non saranno disponibili. Per saperne di più, consulta Risorse per gli upgrade per picchi.

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 dispone della capacità necessaria. Per eseguire l'upgrade di un nodo, GKE esegue i seguenti passaggi:

  1. Contrassegna come non pianificabile il nodo esistente.
  2. Drain 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. Stacca il nodo di cui è stato eseguito l'upgrade.

Quando GKE ricrea il nodo esistente, libera temporaneamente la capacità del nodo se non proviene da una prenotazione. Ciò significa che, se la capacità è limitata, rischi di perdere la capacità esistente. Pertanto, se il tuo ambiente è limitato in termini di risorse, utilizza questa impostazione solo se utilizzi i nodi riservati. Per saperne 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 sovraccarico: maxSurge=2;maxUnavailable=1.

Durante un upgrade per picco con questo pool di nodi, in una finestra mobile, GKE crea due nodi di cui è stato eseguito l'upgrade e interrompe al massimo un nodo esistente alla volta. GKE arresta al massimo tre nodi esistenti dopo che i nodi di cui è stato eseguito l'upgrade sono pronti. Durante la procedura di upgrade, il pool di nodi includerà da quattro a sette nodi.

Considerazioni per le impostazioni di upgrade di sovraccarico

Tieni presente le seguenti informazioni prima di configurare le impostazioni di upgrade per i picchi:

Modificare le impostazioni di upgrade per l'aumento improvviso del carico per bilanciare velocità e interruzioni

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

Descrizione Configurazione Caso d'uso tipico
Bilanciato (impostazione predefinita), più lento, ma meno invasivo maxSurge=1 maxUnavailable=0 La maggior parte dei carichi di lavoro
Veloce, nessuna risorsa di picco, più dirompente maxSurge=0 maxUnavailable=20 Pool di nodi di grandi dimensioni dopo che i job devono essere eseguiti fino al completamento
Risorse rapide, con un maggiore picco e meno invasive maxSurge=20 maxUnavailable=0 Pool di nodi di grandi dimensioni
Risorse più lente, che causano interruzioni e non supportano i picchi di domanda maxSurge=0 maxUnavailable=1 Pool di nodi con risorse limitate e prenotazione

Bilanciato (impostazione predefinita)

Il modo più semplice per sfruttare gli upgrade di picco è utilizzare la configurazione predefinita. maxSurge=1;maxUnavailable=0. Con questa configurazione, gli upgrade procedono lentamente, con l'aggiunta di un solo nodo di picco alla volta, il che significa che viene eseguito l'upgrade di un solo nodo alla volta. I pod possono essere riavviati immediatamente sul nuovo node di picco. Questa configurazione richiede solo le risorse per creare temporaneamente un nuovo nodo.

Risorse rapide e senza picchi

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

Veloce e meno invasivo

Se il tuo carico di lavoro è sensibile alle interruzioni e hai già configurato PodDisruptionBudgets (PDB) e non utilizzi externalTrafficPolicy: Local, che non funziona con i tiri dei nodi paralleli, 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. Sebbene le configurazioni dei PDB possano variare, se crei un PDB con maxUnavailable=1 per uno o più carichi di lavoro in esecuzione nel pool di nodi, puoi espellere un solo pod di questi carichi di lavoro alla volta, limitando il parallelismo dell'intero upgrade. Questa configurazione richiede le risorse per creare temporaneamente 20 nuovi nodi.

Risorse lente, ma senza picchi

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

Controllare un upgrade di sovraccarico in corso

Con gli upgrade per picchi di domanda, mentre è in corso un upgrade puoi utilizzare dei comandi per esercitare un certo controllo. Per un maggiore controllo sulla procedura di upgrade, consigliamo di utilizzare gli upgrade blu/verde.

Annullare (mettere in pausa) un upgrade di sovraccarico

Puoi annullare un upgrade per picco in corso in qualsiasi momento durante la procedura. L'annullamento mette in pausa l'upgrade, impedendo a GKE di eseguire l'upgrade dei nuovi nodi, ma non esegue il rollback automatico dell'upgrade dei nodi di cui è già stato eseguito l'upgrade. Dopo aver annullato un upgrade, puoi ripristinare o eseguire il rollback.

Quando annulli un upgrade, GKE esegue le seguenti operazioni su ciascun nodo:

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

Ciò significa che il pool di nodi potrebbe finire in uno stato in cui i nodi eseguono due versioni diverse. Se gli upgrade automatici sono abilitati per il pool di nodi, è possibile pianificare nuovamente l'upgrade automatico del pool di nodi, in modo da eseguire l'upgrade dei nodi rimanenti nel pool di nodi che eseguono la versione precedente.

Scopri come annullare l'upgrade di un node pool.

Riprendi un upgrade di sovraccarico

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

Eseguire il rollback di un upgrade di sovraccarico

Se un pool di nodi non viene aggiornato completamente, puoi eseguire il rollback per ripristinarlo allo stato precedente. Non puoi eseguire il rollback dei pool di nodi dopo che è stato eseguito l'upgrade. I nodi per i quali non è stato avviato un upgrade non sono interessati. Scopri come eseguire il rollback di un pool di nodi pool.

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/verdi sono una strategia di upgrade alternativa alla strategia di upgrade per picchi predefinita. Con gli upgrade blue-green, GKE crea innanzitutto un nuovo insieme di risorse di nodi ("verdi") con la nuova configurazione dei nodi prima di svuotare i workload sulle risorse originali ("blu"). GKE conserva le risorse "blu", se necessario, per il rollback dei carichi di lavoro fino al termine del tempo di attesa. 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. Se necessario, puoi eseguire il rollback di un upgrade in corso, poiché l'ambiente originale viene mantenuto durante l'upgrade. Tuttavia, questa strategia di upgrade richiede anche un maggiore utilizzo di risorse. Poiché l'ambiente originale viene replicato, il pool di nodi utilizza il doppio del numero di risorse durante l'upgrade.

Scegliere gli upgrade blu/verde per il tuo ambiente

Se hai workload di produzione ad alta disponibilità di cui devi essere in grado di eseguire il rollback rapidamente nel caso in cui il carico di lavoro non tolleri l'upgrade e un aumento temporaneo dei costi è accettabile, ti consigliamo di scegliere gli upgrade blue-green per i tuoi pool di nodi.

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

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

Quando GKE utilizza gli upgrade blu/verde

Per i nodi GKE, esistono diversi tipi di modifiche alla configurazione che richiedono la loro ricreazione. Se abilitato, GKE utilizza gli upgrade blue-green quando si verificano i seguenti tipi di modifiche:

Gli upgrade di Surge verranno utilizzati per qualsiasi altra funzionalità che richieda la ricostituzione dei nodi. Per scoprire di più, consulta Quando vengono utilizzati gli upgrade di sovraccarico.

Fasi degli upgrade blu/verde

Con gli upgrade blu/verdi, 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: crea il pool verde

In questa fase, viene creato un nuovo insieme di gruppi di istanze gestite (MIG), noto 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à controllata prima di iniziare il provisioning delle nuove risorse green.

In questa fase, il gestore della scalabilità automatica dei cluster interromperà lo scale up o lo scale down dei gruppi di istanze gestite originali, noti come pool blu. Il pool verde può essere aumentato solo in questa fase.

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

Fase 2: contrassegna il pool blu

In questa fase, tutti i nodi originali del pool blu (MIG esistenti) verranno messi in isolamento (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, se necessario, puoi annullare l'upgrade. Quando annulli un upgrade blu/verde, l'upgrade viene messo in pausa nella fase corrente. Dopo averlo annullato, puoi ripristinarlo o eseguire il rollback. In questa fase, il rollback annullerà il cordone del pool blu ed eliminerà il pool verde.

Fase 3: svuota la piscina blu

In questa fase, i nodi originali del pool blu (MIG esistenti) verranno ritirati in batch. Quando Kubernetes svuota un nodo, le richieste di espulsione vengono inviate a tutti i pod in esecuzione sul nodo. I pod verranno riprogrammati. I pod con violazioni di PodDisruptionBudget o terminationGracePeriodSeconds lunghi durante lo svuotamento verranno eliminati nella fase Elimina pool blu quando viene eliminato il nodo. 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 come valore decimale compreso tra 0 e 1, inclusi. GKE arrotonda per difetto alla percentuale di nodi più vicina, fino 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 node pool.

Inoltre, puoi controllare per quanto tempo ogni scolo del lotto viene inumidito con BATCH_SOAK_DURATION. Questa durata è definita in secondi, con un valore predefinito di zero secondi.

In questa fase, se necessario, puoi ancora annullare l'upgrade. Quando annulli un upgrade blu/verde, l'upgrade viene messo in pausa nella fase corrente. Dopo averlo annullato, puoi ripristinarlo o eseguire il rollback. In questa fase, il rollback interromperà lo svuotamento del pool blu e rimuoverà il cordone di sicurezza. I workload possono quindi essere riprogrammati nel pool blu (non garantito) e il pool verde verrà eliminato.

Fase 4: immergi il pool di nodi

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

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

La durata totale del tempo di attesa è la somma di NODE_POOL_SOAK_DURATION, più BATCH_SOAK_DURATION moltiplicato per il numero di batch, che viene determinato da BATCH_NODE_COUNT o BATCH_PERCENT.

In questa fase, puoi completare l'upgrade e saltare il tempo di attesa rimanente completando l'upgrade. Verrà avviata immediatamente la procedura di rimozione dei nodi del pool blu.

Se necessario, puoi comunque annullare l'upgrade. Quando annulli un upgrade blu/verde, l'upgrade viene messo in pausa nella fase corrente. Dopo averlo annullato, puoi ripristinarlo o eseguire il rollback.

In questa fase, il gestore della scalabilità automatica del cluster ora può eseguire lo scale up o lo scale down del pool verde come normale.

Fase 5: elimina il pool blu

Al termine del tempo di attesa, 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'espulsione, ma tenta di eliminare i pod. A differenza dell'espulsione, l'eliminazione non rispetta i PDB ed elimina forzatamente i pod. L'eliminazione limita il valore di terminationGracePeriodSeconds di un pod a non più di 60 minuti. Dopo questo ultimo tentativo di eliminazione dei pod rimanenti, i nodi del pool blu vengono eliminati dal pool di nodi.

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

Come funziona il gestore della scalabilità automatica dei cluster con gli upgrade blue/green

Durante le fasi di un upgrade blue-green, il pool "blu" originale non viene scalato verso l'alto o verso il basso. Quando viene creato il nuovo pool "verde", può essere eseguito il ridimensionamento solo fino alla fase di assorbimento del pool di nodi, dove può essere eseguito il ridimensionamento verso l'alto o verso il basso. Se viene ripristinato un upgrade, il pool "blu" originale potrebbe essere sottoposto a scale up durante questa procedura se è necessaria una maggiore capacità.

Controllare un upgrade blu/verde in corso

Con gli upgrade blu/verdi, durante l'esecuzione di un upgrade puoi utilizzare i comandi per esercitare il controllo. In questo modo, hai un elevato livello di controllo sul processo nel caso in cui, ad esempio, dovessi stabilire che è necessario eseguire il rollback dei carichi di lavoro alla vecchia configurazione del nodo.

Annullare (mettere in pausa) un upgrade blu/verde

Quando annulli un upgrade blue-green, lo metti in pausa nella fase corrente. Questo comando può essere utilizzato in tutte le fasi tranne nella fase Elimina pool blu. In caso di annullamento, 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 un upgrade del pool di nodi.

Dopo l'annullamento di un upgrade, puoi scegliere uno dei due percorsi possibili: riprendere o ripristinare.

Riprendi un upgrade blu/verde

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

Se riprendi, la procedura di upgrade continuerà nella fase intermedia in cui è stata messa in pausa. Per scoprire come riprendere un upgrade del pool di nodi, consulta Ripristinare un pool di nodi pool.

Eseguire il rollback di un upgrade blu/verde

Se hai stabilito che l'upgrade non deve essere eseguito e vuoi ripristinare lo stato originale del pool di nodi, puoi eseguire il rollback. Per scoprire come eseguire il rollback di un upgrade del pool di nodi, consulta Eseguire il rollback di un upgrade del pool di nodi.

Con il flusso di lavoro di rollback, il processo viene invertito per riportare il pool di nodi allo stato originale. Il pool blu verrà rimosso dal cordone di sicurezza in modo che i carichi di lavoro possano essere riprogrammati. Durante questa procedura, il gestore della scalabilità automatica dei cluster potrebbe eseguire 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.

Completare un upgrade blu/verde

Durante la fase di assorbimento, puoi completare un upgrade se hai stabilito che il carico di lavoro non richiede ulteriore convalida sulla configurazione del nuovo nodo e i vecchi nodi possono essere rimossi. Il completamento di un upgrade consente di saltare il resto della fase di assorbimento e di passare alla fase di eliminazione del pool blu.

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

Passaggi successivi