Strategie di upgrade dei nodi

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

  • Upgrade di sovraccarico: i nodi vengono sottoposti a upgrade in una finestra temporale continua. 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 workload vengono convalidati sulla 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 Flex-start VM, 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'avvio flessibile è basato su Dynamic Workload Scheduler.

Scegliendo una strategia di upgrade per il pool di nodi Standard, puoi selezionare il processo con il giusto equilibrio tra velocità, interruzione dei carichi di lavoro, mitigazione dei rischi e ottimizzazione dei costi. Per saperne di più su quale strategia di upgrade dei nodi è più 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 Configura la strategia di upgrade scelta. Assicurati di avere una quota, una disponibilità delle risorse o una capacità di prenotazione sufficienti per eseguire l'upgrade dei nodi utilizzando la strategia scelta. Per saperne di più, consulta Garantisci le risorse per gli upgrade dei nodi.

Upgrade distruttivi per i node pool che utilizzano acceleratori ed eseguono workload AI/ML

Poiché le istanze Compute Engine con acceleratori (GPU o TPU) non supportano la migrazione live, Compute Engine deve arrestare e ricreare i nodi durante la manutenzione dell'host. Questo processo può interrompere i workload, ad esempio i job di addestramento o inferenza AI/ML. Per ridurre al minimo le interruzioni, esegui contemporaneamente la manutenzione dell'host Compute Engine e gli upgrade dei nodi GKE. Per saperne di più, consulta Esegui la manutenzione dell'host per i nodi che eseguono carichi di lavoro di addestramento e inferenza.

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 inattesi 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 inattivi 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 con capacità aggiuntiva per i tuoi node pool.

Gli upgrade con picco di richiesta 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 con capacità aggiuntiva

Se abilitato, GKE utilizza gli upgrade con capacità aggiuntiva 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 con capacità aggiuntiva, poiché non richiedono la ricreazione dei nodi.

Informazioni sulle impostazioni di upgrade con capacità aggiuntiva

Utilizza le impostazioni di upgrade con capacità aggiuntiva per selezionare il giusto equilibrio tra velocità e interruzione per il pool di nodi durante la manutenzione del cluster utilizzando le impostazioni di capacità aggiuntiva. 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 di upgrade inatteso è 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 rimuovere quello esistente

Imposta maxSurge per scegliere il numero massimo di nodi aggiuntivi con 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 eseguire immediatamente la migrazione a un nuovo nodo. Il valore predefinito è uno. 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, tutti 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 saperne di più, consulta Risorse per gli upgrade in caso di picchi.

maxUnavailable: GKE rende non disponibile un nodo esistente 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 workload in esecuzione sul nodo esistente potrebbero dover attendere l'upgrade del nodo esistente, se non sono presenti altri nodi con capacità. Per eseguire l'upgrade di un nodo, GKE esegue i seguenti passaggi:

  1. Contrassegna il nodo esistente come non pianificabile.
  2. Esegui il drain del nodo esistente, rispettando le impostazioni di PodDisruptionBudget e GracefulTerminationPeriod per un massimo di un'ora. Dopo un'ora, tutti 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, rilascia temporaneamente la capacità del nodo se non proviene da una prenotazione. Ciò significa che, se la capacità è limitata, rischi di perdere quella esistente. Pertanto, se il tuo ambiente è vincolato dalle risorse, utilizza questa impostazione solo se utilizzi nodi riservati. Per saperne di più, consulta Esegui 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 inattivo: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 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 degli upgrade di sovraccarico

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

Ottimizza 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 invasivo maxSurge=1 maxUnavailable=0 La maggior parte dei carichi di lavoro
Risorse rapide, senza picchi, più disruptive maxSurge=0 maxUnavailable=100 Pool di nodi di grandi dimensioni dopo che i job devono essere eseguiti fino al completamento
Veloce, con il maggior numero di risorse di picco e meno interruzioni maxSurge=100 maxUnavailable=0 Node pool di grandi dimensioni
Più lento, dirompente, senza risorse di picco maxSurge=0 maxUnavailable=1 Pool di nodi con risorse limitate e 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 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 workload 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=100. Questa configurazione non attiva nodi di picco aggiuntivi e consente l'upgrade di 100 nodi contemporaneamente.

Rapido 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 gli svuotamenti dei nodi in parallelo, puoi aumentare la velocità dell'upgrade utilizzando maxSurge=100;maxUnavailable=0. Questa configurazione esegue l'upgrade di 100 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, solo un pod di questi carichi di lavoro può essere rimosso alla volta, limitando il parallelismo dell'intero upgrade. Questa configurazione richiede le risorse per creare temporaneamente 100 nuovi nodi.

Risorse lente, ma senza picchi

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 sul processo di upgrade, ti consigliamo di utilizzare gli upgrade blu/verde.

Annullare (mettere in pausa) un upgrade dinamico

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

Quando annulli un upgrade, GKE esegue le seguenti operazioni su 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 per i quali 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 l'upgrade di Surge

Se l'upgrade di un pool di nodi è stato annullato e lasciato parzialmente aggiornato, puoi riprendere l'upgrade per completare la procedura di upgrade delpool di nodil. In questo modo verrà eseguito l'upgrade di tutti i nodi rimanenti di cui non era stato eseguito l'upgrade nell'operazione originale. Scopri come riprendere l'upgrade di un node pool.

Eseguire il rollback di un upgrade di sovraccarico

Se l'upgrade di un pool di nodi viene eseguito parzialmente, puoi eseguire il rollback del pool di nodi per ripristinarne 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"). Se necessario, GKE conserva le risorse "blu" per il rollback dei workload fino al raggiungimento del tempo di soak. Puoi regolare il ritmo degli upgrade e il tempo di soak 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à di cui 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'implementazione graduale in cui la mitigazione del rischio è più importante e 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 un periodo 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 blu/verdi 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 saperne di più, consulta Quando vengono utilizzati gli upgrade dinamici.

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 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 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 messo in pausa nella fase corrente. Dopo averlo annullato, puoi riprenderlo o eseguire il rollback. In questa fase, il rollback eliminerà il pool verde.

Fase 2: contrassegna il pool blu come non pianificabile

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. Dopo averlo annullato, puoi riprenderlo o eseguire il rollback. In questa fase, il rollback rimuoverà il cordone dal pool blu ed eliminerà il pool verde.

Fase 3: svuota la vasca blu

In questa fase, i nodi originali nel pool blu (i gruppi di istanze gestite 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 presentano violazioni di PodDisruptionBudget o un valore 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 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 ignora questa fase e passa alla fase Node pool di soak.

Inoltre, puoi controllare la durata di ogni ciclo di scarico della batteria 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 valore 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 un'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 viene 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. Dopo averlo annullato, puoi riprenderlo o eseguire il rollback.

In questa fase, il gestore della scalabilità automatica dei cluster può fare lo scale up o lo scale down del pool verde come di consueto.

Fase 5: elimina il pool blu

Allo scadere del tempo di soak, 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 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 dapool di nodiol.

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 blu/verde

Durante le fasi di un upgrade blu/verde, il pool "blu" originale non viene scalato verso l'alto o verso il basso. 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 scalato durante questa procedura se è necessaria capacità aggiuntiva.

Controllare un upgrade blu/verde in corso

Con gli upgrade blu/verde, mentre è in corso un upgrade puoi utilizzare i comandi per esercitare il controllo sull'upgrade. In questo modo, hai un livello elevato di controllo sul processo nel caso in cui, ad esempio, stabilisci che i tuoi workload devono essere sottoposti a rollback alla configurazione del nodo precedente.

Annulla (metti in pausa) un upgrade blu/verde

Quando annulli un upgrade blu/verde, l'upgrade viene messo in pausa nella fase corrente. 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 inviata 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, il processo di upgrade continuerà dalla fase intermedia in cui era stato messo in pausa. Per scoprire come riprendere l'upgrade di un pool di nodi, consulta Riprendi l'upgrade di un node pool.

Esegui il rollback di un upgrade blu/verde

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

Con il workflow di rollback, il processo viene invertito per riportare il pool di nodi allo stato originale. Il pool blu verrà sbloccato in modo che i workload possano essere ripianificati al suo interno. Durante questo processo, il gestore della scalabilità automatica dei cluster può 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.

Completa un upgrade blu/verde

Durante la fase di test, puoi completare un upgrade se hai stabilito che il carico di lavoro non necessita di ulteriore convalida sulla nuova configurazione dei nodi e che i nodi precedenti possono essere rimossi. Il completamento di un upgrade salta il resto della fase di rodaggio e procede 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 blu-verde con scalabilità automatica sono un tipo diverso di strategia di upgrade che massimizza il tempo prima che i workload intolleranti alle interruzioni vengano rimossi, riducendo al minimo i costi. Questa strategia deriva dagli upgrade blu/verde standard. Tuttavia, con gli upgrade blue-green con scalabilità automatica, GKE non svuota i nodi con i workload 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 è necessario che i pod garantiscano la riprogrammazione immediata o il rollback immediato alla configurazione del nodo precedente.

Scegli gli upgrade blu-verde standard se devi ridurre al minimo il tempo necessario per ripianificare i workload su nuovi nodi e se hai bisogno della 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 sono diverse rispetto agli 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 esegue lo scale up del pool verde per eseguire questi pod.
  2. GKE isola il pool blu.

  3. GKE attende 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 PodDisruptionBudget fino a 1 ora e le impostazioni 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 di cluster e 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 orizzontalmente il pool verde quando GKE riprogramma 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 faccia lo scale down dei 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 garantire che i pod rimossi dai nodi nel pool blu vengano ripianificati solo sui nodi nel pool verde, aggiungi un nodeSelector per l'etichetta cloud.google.com/gke-nodepool:NODE_POOL_NAME al tuo workload. Se ometti questa etichetta e hai altri pool di nodi nel tuo cluster, i pod eliminati potrebbero essere pianificati per i nodi in questi altri pool di nodi.

Limitazioni degli upgrade blu/verde con scalabilità automatica

  • Puoi annullare e riprendere gli upgrade blue-green con scalabilità automatica; tuttavia, non puoi 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 pool di nodi con upgrade blue-green con scalabilità automatica solo se il control plane del cluster esegue la versione 1.34.0-gke.2201000 o successive ed è abilitato il gestore della scalabilità automatica dei 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 e viene ridotto solo dal gestore della scalabilità automatica del cluster quando i nodi diventano sottoutilizzati. Il gestore della scalabilità automatica dei cluster 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 avvio 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 saperne di più sui nodi che utilizzano upgrade di breve durata, consulta Informazioni sul consumo di GPU, TPU e H4D con la modalità di provisioning con avvio flessibile.

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

Con questa strategia, GKE esegue l'upgrade di questi nodi di runtime limitato 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.
  3. Nell'arco di 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 avvio flessibile. Questa strategia non ha impostazioni di configurazione.

Quando GKE utilizza gli upgrade di breve durata

GKE imposta automaticamente i nodi che utilizzano Flex-start VM 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 aggiornamenti 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 in situazioni in cui altrimenti verrebbero utilizzati gli upgrade con capacità aggiuntiva. 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 capacità aggiuntiva.

Passaggi successivi