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. Puoi anche eseguire l'upgrade utilizzando una capacità fissa per gli ambienti con risorse limitate.
  • Upgrade blu/verde: i nodi esistenti rimangono disponibili per il rollback mentre i workload 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 dei 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 surge. 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 tuo pool di nodi Standard, puoi selezionare il processo con il giusto equilibrio tra velocità, interruzione dei workload, mitigazione del rischio e ottimizzazione dei costi. Per saperne di più sulla 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 Configurare 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 ulteriori informazioni sulle considerazioni relative alle risorse, consulta Garantisci le risorse per gli upgrade dei nodi. Quando esegui l'upgrade in un ambiente con risorse limitate, consulta Esegui l'upgrade in un ambiente con risorse limitate.

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

Poiché le istanze di 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 come i job di inferenza o addestramento 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 sovraccarico sono la strategia di upgrade predefinita e sono ideali 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 surge funzionano anche con il gestore della scalabilità automatica dei cluster per impedire modifiche ai nodi di cui è in corso l'upgrade.

Quando scegliere gli upgrade di surge 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 aumento temporaneo sono ideali 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.
  • Se esegui gli upgrade in un ambiente con risorse limitate.

Quando GKE utilizza gli upgrade con capacità aggiuntiva

Se è attivato, 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 con capacità aggiuntiva, poiché non richiedono la ricreazione dei nodi.

Informazioni sulle impostazioni dell'upgrade di incremento

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 dell'upgrade con capacità aggiuntiva è 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. Sono disponibili le seguenti opzioni:

maxSurge: GKE crea un nuovo nodo surge 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. L'utilizzo di nodi di picco aumenta la probabilità che i workload in esecuzione sul nodo esistente possano essere migrati immediatamente a un nuovo nodo. Il valore predefinito per il campo maxSurge è 1. Per eseguire l'upgrade di un nodo, GKE esegue questi 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 possa creare nodi di sovraccarico, il tuo progetto deve disporre delle risorse per creare temporaneamente nodi aggiuntivi. Se non hai capacità aggiuntiva e il campo maxUnavailable è impostato su zero, 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 su un valore maggiore di zero per eseguire l'upgrade utilizzando la capacità fissa. Il campo maxUnavailable specifica il numero massimo di nodi che possono non essere disponibili contemporaneamente durante un upgrade, per zona. Il valore predefinito è zero.

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, tenendo presenti le seguenti considerazioni:
    • Le impostazioni PodDisruptionBudget e GracefulTerminationPeriod vengono rispettate per un massimo di un'ora. Dopo un'ora, i pod rimanenti vengono rimossi forzatamente in modo che l'upgrade possa procedere.
    • Se nessun altro nodo ha capacità, i workload in esecuzione sul nodo esistente potrebbero dover attendere l'upgrade del nodo esistente. Quando questi workload sono in attesa, i pod sono in stato di attesa.
  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.

Per preservare la capacità esistente quando esegui gli upgrade di versione in un ambiente con risorse limitate, imposta il campo maxUnavailable su un valore maggiore di zero. Ad esempio, puoi impostare maxSurge=0 e maxUnavailable=1. Per GPU e TPU, consulta le indicazioni aggiuntive in Esegui l'upgrade in un ambiente con risorse limitate.

Quando esegui un upgrade della versione sui pool di nodi CPU, se il campo maxUnavailable è impostato su un valore maggiore di zero, GKE riutilizza la stessa istanza Compute Engine, che mantiene la capacità esistente del nodo.

Per tutti gli altri aggiornamenti e upgrade dei pool di nodi, quando GKE ricrea il nodo esistente utilizzando maxUnavailable, 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.

Ad esempio, GKE non riutilizza l'istanza Compute Engine esistente, ma la elimina e la ricrea nei seguenti scenari:

  • Aggiornamenti del node pool diversi dagli upgrade della versione (ad esempio modifiche al tipo di macchina, al tipo di disco o alle dimensioni del disco).
  • Upgrade delle versioni dei pool di nodi che contengono GPU o TPU.
  • Aggiornamenti delle versioni dei node pool che utilizzano VM spot o VM preemptible.
  • Rollback di un upgrade di sovraccarico incompleto.
  • Riparazioni automatiche dei nodi.

Esempio di utilizzo delle impostazioni maxSurge e maxUnavailable

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

Durante un upgrade con capacità aggiuntiva con questo pool di nodi, in una finestra mobile, GKE crea due nuovi nodi con capacità aggiuntiva (maxSurge=2) e rimuove immediatamente un nodo esistente (maxUnavailable=1). Una volta pronti i due nodi con capacità aggiuntiva, GKE rimuove altri due nodi esistenti, causando l'interruzione di un massimo di tre nodi esistenti alla volta e mantenendo il pool di nodi tra 29 e 32 nodi.

Per gli upgrade che supportano il riutilizzo della capacità esistente del nodo, il nodo di cui viene eseguito l'upgrade utilizzando il budget maxUnavailable=1 viene aggiornato in loco riutilizzando l'istanza esistente. Se non è disponibile capacità aggiuntiva per creare i due nodi di sovraccarico, GKE procede comunque con l'upgrade eseguendo l'upgrade di un nodo esistente alla volta.

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
Ambienti bilanciati con risorse limitate, senza risorse di picco maxSurge=0 maxUnavailable=1 Pool di nodi con risorse limitate
Risorse rapide, senza burst, più disruptive maxSurge=0 maxUnavailable=100 Pool di nodi di grandi dimensioni dopo l'esecuzione dei job fino al completamento
Veloce, con il maggior numero di risorse di picco e meno interruzioni maxSurge=100 maxUnavailable=0 Node pool di grandi dimensioni

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 un solo nodo di sovraccarico aggiunto alla volta, il che significa che viene eseguito l'upgrade di un solo nodo alla volta. I pod possono riavviarsi immediatamente sul nuovo nodo di surge. 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ù workload in esecuzione nel pool di nodi, è possibile evincere un solo pod di questi workload alla volta, limitando il parallelismo dell'intero upgrade. Questa configurazione richiede le risorse per creare temporaneamente 100 nuovi nodi.

Ambienti bilanciati con risorse limitate

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

Controlla 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.

Annulla (metti in pausa) un upgrade con aumento temporaneo

Puoi annullare un upgrade con aumento temporaneo 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 eseguire 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 che non hanno avviato l'upgrade non vengono aggiornati.
  • I nodi che hanno già completato l'upgrade 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 per il pool di nodi sono abilitati gli upgrade automatici, è 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. Verrà eseguito l'upgrade di tutti i nodi rimanenti che non erano stati aggiornati nell'operazione originale. Scopri come riprendere l'upgrade di un node pool.

Esegui 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 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 Esegui il downgrade dei node pool.

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 dei nodi (nodi "verdi") con la nuova configurazione dei nodi prima di rimuovere i workload dalle risorse originali (nodi "blu"). GKE conserva le risorse "blu", se necessario, per eseguire 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. Tuttavia, questa strategia di upgrade 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 dove è necessaria una terminazione controllata 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 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ò 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 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 isolati (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 messo in pausa nella fase corrente. Dopo averlo annullato, puoi riprenderlo o eseguire il rollback. In questa fase, il rollback annulla l'isolamento del pool blu ed elimina il pool verde.

Fase 3: svuota la vasca 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 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 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 per quanto tempo ogni svuotamento in batch rimane in attesa 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 corrente. Dopo averlo annullato, puoi riprenderlo 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 sblocca. 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 workload dopo che i nodi del pool blu sono stati svuotati.

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

La durata totale della fase di soak è la somma di NODE_POOL_SOAK_DURATION, più BATCH_SOAK_DURATION moltiplicato per il numero di batch, che è determinato da BATCH_NODE_COUNT o BATCH_PERCENT.

In questa fase, puoi completare l'upgrade e saltare il tempo di soak 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 corrente. 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 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 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 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 fatto lo scale up solo fino alla fase di pool di nodi pool, in cui può essere fatto lo scale up o lo scale down. Se viene eseguito il rollback di un upgrade, il pool "blu" originale potrebbe fare lo scale up durante questo processo 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. Una volta 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 node pool.

Dopo l'annullamento di un upgrade, puoi scegliere una delle due opzioni seguenti: riprendi o esegui il 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 è 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 Esegui il rollback di un pool di nodi 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à riattivato in modo che i workload possano essere ripianificati. Durante questo processo, il gestore della scalabilità automatica dei cluster potrebbe fare lo scale up del pool blu, se necessario. 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 Esecuzione del downgrade dei node pool.

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 soak e procede alla fase di eliminazione del pool blu.

Per saperne di più su come utilizzare il comando complete, consulta Completa 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 blu-verde con scalabilità automatica, GKE non svuota i nodi con workload contrassegnati come non sicuri per l'eviction per un massimo di sette giorni dopo l'isolamento dei nodi.

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, consulta Configura gli upgrade blu/verde con scalabilità automatica.

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

Se hai workload che richiedono il tempo massimo prima dell'espulsione, ma non devono essere ripianificati il più rapidamente possibile, ti consigliamo di scegliere gli upgrade blu-verde con scalabilità automatica per i tuoi node pool.

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 abbiano la garanzia di una riprogrammazione immediata o di un 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 i periodi 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:

  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 per un massimo di 1 ora e le impostazioni terminationGracePeriodSeconds per un massimo di 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 un valore sufficientemente alto in modo che il gestore della scalabilità automatica dei cluster possa fare lo scale up del pool verde quando GKE ripianifica i workload dal pool blu al pool verde. GKE non rispetta i parametri --min-nodes o --total-min-nodes quando esegue lo scale down 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 pool di nodi con provisioning automatico.

Configurazione del pod

  • Per assicurarti che i pod non vengano espulsi durante la pausa prima dello svuotamento del 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 rimossi potrebbero essere pianificati per i nodi di questi altri pool di nodi.

Limitazioni degli upgrade blu/verde con scalabilità automatica

  • Puoi annullare e riprendere gli upgrade blu-verde con scalabilità automatica, ma non puoi eseguire il rollback dell'upgrade annullato.
  • Quando il pool blu viene bloccato e svuotato, i pod possono diventare temporaneamente non pianificabili se il gestore della scalabilità automatica dei cluster non può fare lo scale up del pool verde a causa di quote e limiti o della 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 dei cluster esegue le seguenti operazioni:

  • Durante la fase in cui GKE attende lo svuotamento del pool blu, il pool blu non fa lo scale up e il gestore della scalabilità automatica dei cluster fa lo scale down solo 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 fa lo scale up del pool verde da zero nodi o lo scale down all'impostazione --min-nodes, come richiesto in tutte le fasi della strategia di upgrade.

Upgrade di breve durata (solo per l'avvio flessibile e il provisioning in coda)

Gli upgrade di breve durata sono una strategia di upgrade dei nodi da utilizzare esclusivamente con i nodi che utilizzano Flex-start VM e 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 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.
  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 avvio flessibile. Questa strategia non ha impostazioni di configurazione.

Quando GKE utilizza upgrade di breve durata

GKE imposta automaticamente i nodi che utilizzano le Flex-start VM per applicare upgrade di breve durata. Anche 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 gli 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 capacità aggiuntiva.

Passaggi successivi