Strategie di upgrade dei nodi

Questo documento descrive 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 Standard:

  • Upgrade di sovraccarico: i nodi vengono sottoposti a upgrade in una finestra mobile. Puoi controllare il numero di nodi di cui è possibile eseguire l'upgrade contemporaneamente e il livello di interruzione degli upgrade per i workload.
  • Upgrade blu/verde: i nodi esistenti vengono mantenuti disponibili per il rollback mentre i carichi di lavoro vengono convalidati nella nuova configurazione dei nodi.
  • Upgrade blu/verde con scalabilità automatica (anteprima): i workload possono essere eseguiti più a lungo, riducendo al minimo i costi derivanti da nodi inattivi o sottoutilizzati.

GKE sceglie le seguenti strategie per questi scenari specifici:

  • Nei cluster Autopilot, GKE utilizza gli upgrade inattivi. Per maggiori informazioni, consulta la sezione Upgrade rapidi del documento sugli upgrade dei cluster Autopilot.
  • Per i pool di nodi gestiti da Autopilot nei cluster Standard, GKE utilizza gli upgrade inattivi. Non puoi selezionare una strategia diversa o modificare la configurazione.
  • Per i nodi che utilizzano VM con inizio flessibile, GKE utilizza upgrade di breve durata. L'avvio flessibile con provisioning in coda supporta nuovi flag che fanno parte del lancio dell'anteprima dell'avvio flessibile. L'inizio flessibile è basato su Dynamic Workload Scheduler.

Scegliendo una strategia di upgrade per il tuo pool di nodi Standard, puoi selezionare il processo con il giusto equilibrio tra velocità, interruzione dei workload, mitigazione dei rischi e ottimizzazione dei costi. Per ulteriori informazioni su quale strategia di upgrade dei nodi è adatta al tuo ambiente, consulta quanto segue:

Con ciascuna di queste 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, tu disponga di quota, disponibilità di risorse o capacità di prenotazione sufficienti per eseguire l'upgrade dei nodi utilizzando quella strategia. Per ulteriori informazioni, vedi Garantisci le risorse per gli upgrade dei nodi.

Upgrade di sovraccarico

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

Gli upgrade controllati funzionano anche con il gestore della scalabilità automatica dei cluster per impedire modifiche ai nodi che vengono sottoposti ad upgrade.

Quando scegliere gli upgrade di picco per il tuo ambiente

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

Gli upgrade di picco sono ottimali per i seguenti scenari:

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

Quando GKE utilizza gli upgrade inattivi

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

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

Informazioni sulle impostazioni dell'upgrade di sovraccarico

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

Il comportamento dell'upgrade in blocco è determinato dalle impostazioni maxSurge e maxUnavailable, che determinano il numero di nodi da aggiornare 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 aggiuntivi di picco 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 essere migrati immediatamente a un nuovo nodo. 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. Esegui il drain del nodo esistente, rispettando PodDisruptionBudget e GracefulTerminationPeriod per un massimo di un'ora. Dopo un'ora, i pod rimanenti vengono rimossi forzatamente per consentire l'avanzamento dell'upgrade.
  5. Elimina il nodo esistente.

Affinché GKE crei nodi di sovraccarico, il progetto deve disporre delle risorse per creare temporaneamente nodi aggiuntivi. Se non hai capacità aggiuntiva, GKE non avvierà l'upgrade di un nodo finché le risorse non saranno disponibili. Per ulteriori informazioni, consulta Risorse per gli upgrade in caso di picchi.

maxUnavailable: GKE rende un nodo esistente non disponibile per ricrearlo

Imposta maxUnavailable per scegliere il numero massimo di nodi che possono non essere disponibili contemporaneamente 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à. Per eseguire l'upgrade di un nodo, GKE esegue i seguenti passaggi:

  1. Contrassegna il nodo esistente.
  2. Esegui il drain del nodo esistente, rispettando le impostazioni di PodDisruptionBudget e GracefulTerminationPeriod fino a un'ora. Dopo un'ora, i pod rimanenti vengono rimossi forzatamente per consentire l'avanzamento dell'upgrade.
  3. Ricrea il nodo esistente con la nuova configurazione.
  4. Attendi che il nodo esistente sia pronto.
  5. Rimuovi il cordone dal 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, in caso di capacità limitata, rischi di perdere la capacità esistente. Pertanto, se il tuo ambiente ha risorse limitate, utilizza questa impostazione solo se utilizzi nodi riservati. Per saperne di più, consulta 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 di sovraccarico con questo pool di nodi, in una finestra temporale, GKE crea due nodi di cui è stato eseguito l'upgrade e interrompe al massimo un nodo esistente alla volta. GKE disattiva al massimo tre nodi esistenti dopo che i nodi aggiornati sono pronti. Durante la procedura di upgrade, il pool di nodi includerà da quattro a sette nodi.

Considerazioni sulle impostazioni dell'upgrade di sovraccarico

Tieni presente le seguenti informazioni prima di configurare le impostazioni dell'upgrade di sovraccarico:

Ottimizzare le impostazioni degli upgrade di sovraccarico 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 di disturbo maxSurge=1 maxUnavailable=0 La maggior parte dei carichi di lavoro
Risorse veloci, senza picchi, più dirompenti maxSurge=0 maxUnavailable=20 Pool di nodi di grandi dimensioni dopo l'esecuzione dei job fino al completamento
Rapido, con il maggior numero di risorse di picco e meno interruzioni maxSurge=20 maxUnavailable=0 Pool di nodi di grandi dimensioni
Più lento, dirompente, nessuna risorsa di picco maxSurge=0 maxUnavailable=1 Pool di nodi con vincoli di risorse con prenotazione

Bilanciato (impostazione predefinita)

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

Risorse rapide e senza costi aggiuntivi

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 l'upgrade di 20 nodi contemporaneamente.

Veloce e meno invasivo

Se il tuo workload è sensibile alle interruzioni e hai già configurato PodDisruptionBudgets (PDB) e non utilizzi externalTrafficPolicy: Local, che non funziona con lo svuotamento parallelo dei nodi, 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 sul pool di nodi, allora solo un pod di questi carichi di lavoro può essere rimosso alla volta, limitando il parallelismo dell'intero upgrade. Questa configurazione richiede alle risorse di creare temporaneamente 20 nuovi nodi.

Lento, ma senza risorse di picco

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

Controllare un upgrade di sovraccarico in corso

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

Annullare (mettere in pausa) un upgrade di sovraccarico

Puoi annullare un upgrade della tariffa dinamica in corso in qualsiasi momento durante la procedura di upgrade. L'annullamento mette in pausa l'upgrade, impedendo a GKE di eseguire l'upgrade dei nuovi nodi, ma non esegue automaticamente il rollback dell'upgrade dei nodi già sottoposti all'upgrade. Dopo aver annullato un upgrade, puoi riprenderlo o eseguirne il rollback.

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

  • I nodi che hanno avviato l'upgrade lo completano.
  • I nodi per cui l'upgrade non è stato avviato non vengono aggiornati.
  • I nodi per cui l'upgrade è già stato completato correttamente non sono interessati e non 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 gli upgrade automatici sono abilitati per il pool di nodi, è possibile pianificare nuovamente l'upgrade automatico del pool di nodi, che eseguirà l'upgrade dei nodi rimanenti nel pool di nodi che eseguono la versione precedente.

Scopri come annullare l'upgrade di un node pool.

Riprendere un upgrade di sovraccarico

Se l'upgrade di un pool di nodi è stato annullato ed è stato eseguito solo parzialmente, puoi riprendere l'upgrade per completare la procedura per ilpool di nodil. Verrà eseguito l'upgrade di tutti i nodi rimanenti che non sono stati aggiornati nell'operazione originale. Scopri come riprendere l'upgrade di un node pool.

Eseguire il rollback di un upgrade di sovraccarico

Se un pool di nodi viene aggiornato parzialmente, puoi eseguirne il rollback per ripristinare lo stato precedente. Non puoi eseguire il rollback dei node pool dopo che è stato eseguito l'upgrade. I nodi per cui non è stato avviato un upgrade non sono interessati. Scopri come eseguire il rollback dell'upgrade di un node 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/verde sono una strategia di upgrade alternativa alla strategia di upgrade di sovraccarico predefinita. Con gli upgrade blu/verde, GKE crea prima un nuovo insieme di risorse nodo ("nodi verdi") con la nuova configurazione dei nodi prima di eseguire l'espulsione di qualsiasi workload sulle risorse originali ("nodi blu"). GKE conserva le risorse "blu", se necessario, per il rollback dei workload fino al raggiungimento del tempo di assorbimento. Puoi regolare il ritmo degli upgrade e il tempo di assorbimento 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. Questa strategia di upgrade, tuttavia, richiede anche più risorse. Poiché l'ambiente originale viene replicato, il pool di nodi utilizza il doppio delle risorse durante l'upgrade.

Quando scegliere gli upgrade blu/verde per il tuo ambiente

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

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

  • se vuoi un rollout graduale in cui la mitigazione del rischio è più importante, in cui è necessario un arresto controllato superiore a 60 minuti.
  • se i tuoi workload sono meno tolleranti alle interruzioni.
  • se un aumento temporaneo dei costi dovuto a un maggiore utilizzo delle risorse è accettabile.

Gli upgrade blu/verde continuano fino al completamento se superano una finestra di manutenzione. Per saperne di più, consulta Come funzionano le strategie di upgrade dei nodi con le finestre di manutenzione.

Quando GKE utilizza gli upgrade blu/verde

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

Gli upgrade di sovraccarico vengono utilizzati per tutti gli altri aggiornamenti che richiedono la ricreazione dei nodi. Per ulteriori informazioni, consulta la sezione Quando vengono utilizzati gli upgrade improvvisi.

Fasi degli upgrade blu/verde

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

Questa sezione spiega le fasi del processo di upgrade. Puoi utilizzare le impostazioni di upgrade per ottimizzare il funzionamento delle fasi e i comandi per controllare la procedura 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 di nuove risorse verdi.

In questa fase, il gestore della scalabilità automatica dei cluster dei MIG originali, noto come pool blu, interromperà lo scale up o lo scale down. Il pool verde può essere scalato solo in questa fase.

In questa fase, puoi annullare l'upgrade se necessario. Quando annulli un upgrade blu/verde, l'upgrade viene sospeso nella fase attuale. Una volta annullato, puoi riattivarlo o eseguire il rollback. In questa fase, il rollback eliminerà il pool verde.

Fase 2: Cordon Blue Pool

In questa fase, tutti i nodi originali nel pool blu (MIG esistenti) verranno contrassegnati come non pianificabili. I workload esistenti continueranno a essere eseguiti, ma i nuovi workload non verranno pianificati sui nodi esistenti.

In questa fase, puoi annullare l'upgrade se necessario. Quando annulli un upgrade blu/verde, l'upgrade viene sospeso nella fase attuale. Una volta annullato, puoi riattivarlo o eseguire il rollback. In questa fase, il rollback rimuoverà il cordone dal pool blu ed eliminerà il pool verde.

Fase 3: svuota la piscina blu

In questa fase, i nodi originali nel pool blu (MIG esistenti) verranno svuotati in batch. Quando Kubernetes svuota un nodo, vengono inviate richieste di espulsione a tutti i pod in esecuzione sul nodo. I pod verranno ripianificati. I pod che hanno violazioni del PodDisruptionBudget o un terminationGracePeriodSeconds lungo 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 come numero decimale compreso tra 0 e 1, inclusi. GKE arrotonda per difetto alla percentuale più vicina di nodi, 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 ignora questa fase e passa alla fase Node pool di soak.

Inoltre, puoi controllare la durata di ammollo di ogni lotto di scarico con BATCH_SOAK_DURATION. Questa durata è definita in secondi e il valore predefinito è zero secondi.

In questa fase, puoi ancora annullare l'upgrade se necessario. Quando annulli un upgrade blu/verde, l'upgrade viene messo in pausa nella fase attuale. Una volta annullato, puoi riattivarlo o eseguire il rollback. Se il batch precedente è già stato svuotato e riprendi l'upgrade, il batch successivo di nodi potrebbe essere elaborato immediatamente senza rispettare il BATCH_SOAK_DURATION per quel batch. Il rollback in questa fase interrompe lo svuotamento del pool blu e lo ripristina. I workload possono quindi essere riprogrammati nel pool blu (non garantito) e il pool verde viene svuotato ed eliminato.

Fase 4: pool di nodi di test

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

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

La durata totale dell'ammollo è la somma di NODE_POOL_SOAK_DURATION, più BATCH_SOAK_DURATION moltiplicato per il numero di lotti, che è determinato da BATCH_NODE_COUNT o BATCH_PERCENT.

In questa fase, puoi completare l'upgrade e saltare il periodo di attesa rimanente completando l'upgrade. In questo modo, inizierà immediatamente il processo 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 attuale. Una volta annullato, puoi riattivarlo o eseguire il rollback.

In questa fase, il gestore della scalabilità automatica dei cluster può ora aumentare o ridurre le dimensioni del pool verde come di consueto.

Fase 5: elimina il pool blu

Al termine del periodo di ammollo, 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 e tenta invece di eliminare i pod. A differenza dell'espulsione, l'eliminazione non rispetta i PDB ed elimina forzatamente i pod. L'eliminazione limita la durata di un pod terminationGracePeriodSeconds a un massimo 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 tuo 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 viene scalato. Quando viene creato il nuovo pool "verde", può essere scalato solo fino alla fase del pool di nodi di test, in cui può essere scalato verso l'alto o verso il basso. Se viene eseguito il rollback di un upgrade, il pool "blu" originale potrebbe essere sottoposto a scale up durante questa procedura se è necessaria ulteriore capacità.

Controllare un upgrade blu/verde in corso

Con gli upgrade blu/verde, mentre è in corso un upgrade puoi utilizzare i comandi per controllarlo. In questo modo hai un elevato livello di controllo sul processo nel caso in cui, ad esempio, determini che i tuoi carichi di lavoro devono essere ripristinati alla vecchia configurazione dei nodi.

Annulla (metti in pausa) un upgrade blu/verde

Quando annulli un upgrade blu/verde, metti in pausa l'upgrade nella fase attuale. Questo comando può essere utilizzato in tutte le fasi, ad eccezione della fase di eliminazione del 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 l'upgrade di un node pool.

Dopo l'annullamento di un upgrade, puoi scegliere uno dei due percorsi da seguire: riprendere o rollback.

Riprendi un upgrade blu/verde

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

Se riprendi, la procedura di upgrade continuerà dalla fase intermedia in cui era stata messa in pausa. Per scoprire come riprendere l'upgrade di un pool di nodi, consulta Riprendere l'upgrade di un node pool.

Esegui il rollback di un upgrade blu/verde

Se hai stabilito che l'upgrade non deve andare avanti e vuoi ripristinare lo stato originale del pool di nodi, 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 node pool.

Con il flusso di lavoro di rollback, il processo si inverte per riportare il pool di nodi allo stato originale. Il pool blu verrà rimosso in modo che i workload possano essere riprogrammati. Durante questo processo, il gestore della scalabilità automatica dei cluster potrebbe eseguire lo scale up del pool blu in base alle esigenze. La piscina verde verrà svuotata ed eliminata.

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 test, puoi completare un upgrade se hai stabilito che il carico di lavoro non richiede ulteriore convalida nella nuova configurazione dei nodi e che i nodi precedenti possono essere rimossi. Il completamento di un upgrade salta il resto della fase di test e passa alla fase di eliminazione del pool blu.

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

Upgrade blu/verde con scalabilità automatica

Gli upgrade blue-green con scalabilità automatica sono un tipo diverso di strategia di upgrade che massimizza il tempo prima che i workload che non tollerano interruzioni vengano eliminati, riducendo al minimo i costi. Questa strategia deriva dagli upgrade blu/verde standard. Tuttavia, con gli upgrade blu/verde con scalabilità automatica, GKE non svuota i nodi con carichi di lavoro contrassegnati come non sicuri da espellere fino a sette giorni dopo che i nodi sono stati isolati.

La sezione seguente spiega quando scegliere questa strategia, in che modo l'implementazione degli upgrade blu/verde di questa strategia è diversa dagli upgrade blu/verde standard e quali best practice seguire quando utilizzi questa strategia.

Per utilizzare gli upgrade blu/verde con scalabilità automatica, vedi Configurare gli upgrade blu/verde con scalabilità automatica.

Quando scegliere gli upgrade blue-green con scalabilità automatica per il tuo ambiente

Se hai carichi di lavoro che richiedono il massimo tempo prima dell'espulsione, ma non devono essere riprogrammati il più rapidamente possibile, ti consigliamo di scegliere upgrade blue-green con scalabilità automatica per i tuoi pool di nodi.

Gli upgrade blu/verde con scalabilità automatica funzionano bene se si applicano i seguenti scenari:

  • Hai carichi di lavoro batch che devono essere eseguiti fino al completamento.
  • Vuoi ridurre al minimo i costi rispetto agli upgrade blu/verde standard riducendo al minimo la quantità di nodi inattivi o sottoutilizzati.
  • Non hai bisogno dei pod per garantire la riprogrammazione immediata o il rollback immediato alla configurazione precedente dei nodi.

Scegli gli upgrade blu/verde standard se devi ridurre al minimo il tempo necessario per riprogrammare i workload sui nuovi nodi e la possibilità di eseguire il rollback alla configurazione dei nodi precedente.

Gli upgrade blu/verde con scalabilità automatica, come gli upgrade blu/verde standard, continuano fino al completamento se superano un periodo di manutenzione. Per saperne di più, consulta Come funzionano le strategie di upgrade dei nodi con le finestre di manutenzione.

Fasi degli upgrade blu/verde con scalabilità automatica

Quando GKE esegue l'upgrade dei node pool con upgrade blu/verde con scalabilità automatica, le fasi differiscono dagli upgrade blu/verde standard. Per le fasi della strategia di upgrade standard, consulta le fasi degli upgrade blu/verde.

Quando è abilitata la policy di upgrade blue-green con scalabilità automatica, GKE esegue questi passaggi durante un'operazione:

  1. GKE crea il pool verde. Tuttavia, il pool verde inizia con zero nodi. Quando GKE espelle i pod dal pool blu in una fase successiva, il gestore della scalabilità automatica del cluster aumenta le dimensioni del pool verde per eseguire questi pod.
  2. GKE isola il pool blu.

  3. GKE attende per un periodo di tempo, che puoi configurare da zero a sette giorni (con un valore predefinito di tre giorni). Durante questo periodo, GKE esegue le seguenti operazioni:

  4. GKE svuota il pool blu, svuotando i nodi rimanenti del pool blu fino a 20 alla volta in parallelo. GKE rispetta le impostazioni di PodDisruptionBudget fino a 1 ora e le impostazioni di terminationGracePeriodSeconds fino a 24 ore.

  5. GKE ignora la fase Node pool di soak.

  6. GKE elimina il pool blu.

Best practice per gli upgrade blu/verde con scalabilità automatica

Le sezioni seguenti forniscono best practice per il cluster, il pool di nodi e i pod per ridurre al minimo l'interruzione del workload durante gli upgrade blue-green con scalabilità automatica.

Configurazione del cluster e del pool di nodi

  • GKE rispetta i limiti di scalabilità automatica durante lo scale up del pool verde. Imposta i parametri --max-nodes o --total-max-nodes su valori sufficientemente elevati in modo che il gestore della scalabilità automatica dei cluster possa scalare il pool verde quando GKE ripianifica i workload dal pool blu al pool verde. GKE non rispetta i parametri --min-nodes o --total-min-nodes durante la riduzione del pool blu.
  • Configura il profilo di scalabilità automatica optimize-utilization se vuoi che GKE ridimensioni i nodi sottoutilizzati nel pool blu in modo più aggressivo. Per saperne di più, consulta Profili di scalabilità automatica.
  • Non aggiornare i node pool creati con il provisioning automatico dei nodi per utilizzare gli upgrade blu/verde con scalabilità automatica. Inoltre, non configurare il cluster in modo che utilizzi gli upgrade blu/verde con scalabilità automatica per i nuovi node pool con provisioning automatico.

Configurazione del pod

  • Per assicurarti che i pod non vengano eliminati durante la pausa prima di svuotare il pool blu, aggiungi l'annotazione "cluster-autoscaler.kubernetes.io/safe-to-evict": "false" a questi pod. Questa annotazione impedisce al gestore della scalabilità automatica dei cluster di rimuovere il pod se il nodo del pod è sottoutilizzato.
  • Come per gli upgrade blu/verde standard, per assicurarti che i pod rimossi dai nodi nel pool blu vengano ripianificati solo sui nodi nel pool verde, aggiungi un selettore di nodi per l'etichetta cloud.google.com/gke-nodepool:NODE_POOL_NAME al tuo workload. Se ometti questa etichetta e hai altri node pool nel tuo cluster, i pod eliminati potrebbero essere pianificati per i nodi in questi altri node pool.

Limitazioni degli upgrade blu/verde con scalabilità automatica

  • Puoi annullare e riprendere gli upgrade blue-green con scalabilità automatica; tuttavia, non puoi eseguire il rollback dell'upgrade annullato.
  • Quando il pool blu viene isolato e svuotato, i pod possono diventare temporaneamente non pianificabili se il gestore della scalabilità automatica dei cluster non riesce a scalare il pool verde a causa di quote e limiti o disponibilità delle risorse, perché il pool verde viene creato con zero nodi.
  • Puoi eseguire l'upgrade dei node pool con upgrade blue-green con scalabilità automatica solo se il control plane del cluster esegue la versione 1.34.0-gke.2201000 o successive e se è abilitato il gestore della scalabilità automatica del cluster.

Quando GKE utilizza gli upgrade blu/verde con scalabilità automatica

GKE utilizza gli upgrade blu/verde con scalabilità automatica per gli stessi tipi di modifiche degli upgrade blu/verde standard. Per saperne di più sui tipi di modifiche per cui GKE utilizza la strategia di upgrade blu/verde standard, consulta Quando GKE utilizza gli upgrade blu/verde.

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

Per configurare gli upgrade blue-green con scalabilità automatica, devi anche configurare il gestore della scalabilità automatica del cluster.

Se utilizzi gli upgrade blu/verde con scalabilità automatica, il gestore della scalabilità automatica del cluster esegue le seguenti operazioni:

  • Durante la fase in cui GKE attende lo svuotamento del pool blu, il pool blu non viene scalato verso l'alto e viene scalato verso il basso dal gestore della scalabilità automatica dei cluster solo quando i nodi diventano sottoutilizzati. Cluster Autoscaler può fare lo scale down del pool blu a zero, senza rispettare i parametri --min-nodes o --total-min-nodes. In tutte le altre fasi, il gestore della scalabilità automatica dei cluster non esegue lo scale up o lo scale down del pool blu.
  • Il gestore della scalabilità automatica dei cluster esegue lo scale up del pool verde da zero nodi o lo scale down fino all'impostazione --min-nodes, in base alle esigenze in tutte le fasi della strategia di upgrade.

Upgrade di breve durata (solo provisioning con avvio flessibile e in coda)

Gli upgrade di breve durata sono una strategia di upgrade dei nodi da utilizzare esclusivamente con i nodi che utilizzano VM con inizio flessibile e con i nodi che utilizzano il provisioning in coda (con 1.32.2-gke.1652000 o versioni successive), entrambi basati su Dynamic Workload Scheduler. Per ulteriori informazioni sui nodi che utilizzano upgrade di breve durata, consulta Informazioni sull'ottenibilità della GPU con Dynamic Workload Scheduler.

GKE utilizza la strategia di upgrade di breve durata per i node pool Standard e i gruppi di nodi nei cluster Autopilot.

Con questa strategia, GKE esegue l'upgrade di questi nodi di runtime limitati senza interrompere i workload esistenti. La strategia funziona nel seguente modo:

  1. I nodi esistenti vengono eseguiti fino a quando non vengono prerilasciati.
  2. I nuovi nodi utilizzano la nuova configurazione dei nodi.
  3. In un massimo di sette giorni, i nodi passano dall'esecuzione della configurazione esistente all'esecuzione della nuova configurazione.

GKE configura automaticamente questa strategia per i nodi che utilizzano VM con inizio flessibile. Questa strategia non ha impostazioni di configurazione.

Quando GKE utilizza upgrade di breve durata

GKE imposta automaticamente i nodi che utilizzano VM con inizio flessibile per applicare upgrade di breve durata. I nodi che utilizzano solo il provisioning in coda, ma vengono eseguiti su cluster su GKE versione 1.32.2-gke.1652000 o successive, utilizzano anche upgrade di breve durata.

Per i node pool Standard e i gruppi di nodi nei cluster Autopilot che utilizzano upgrade di breve durata, GKE utilizza questa strategia nelle situazioni in cui altrimenti verrebbero utilizzati gli upgrade di sovraccarico. Oltre agli upgrade dei nodi (modifiche della versione), GKE utilizza upgrade di breve durata per altri tipi di aggiornamenti dei nodi, in modo simile a come vengono utilizzati gli upgrade di sovraccarico. Per saperne di più, consulta Quando vengono utilizzati gli upgrade con picco.

Passaggi successivi