Strategie di upgrade dei nodi

Questa pagina 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:

  • Upgrade di picco:i nodi vengono sottoposti a upgrade in una finestra mobile. Puoi controllare quanti nodi possono essere sottoposti ad upgrade contemporaneamente e quanto gli upgrade influiscono sui carichi di lavoro.
  • Upgrade blu/verde: i nodi esistenti vengono mantenuti disponibili per il rollback mentre i carichi di lavoro vengono convalidati nella nuova configurazione dei nodi.

GKE sceglie le seguenti strategie per questi scenari specifici:

  • Nei cluster Autopilot, GKE utilizza gli upgrade inattivi. Per ulteriori informazioni, consulta la sezione Upgrade rapidi della pagina Upgrade dei cluster Autopilot.
  • Per i nodi con avvio flessibile, basati su Dynamic Workload Scheduler, 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.

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

Con entrambe le strategie, puoi configurare le impostazioni di upgrade per ottimizzare il processo in base alle esigenze del tuo ambiente. Per saperne di più, consulta Configurare la strategia di upgrade scelta. Assicurati che per la strategia che scegli, 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 Garantire le risorse per gli upgrade dei nodi.

Upgrade di incremento

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 controllati funzionano anche con il gestore della scalabilità automatica dei cluster per impedire modifiche ai nodi in fase di upgrade.

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 con 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 picco quando si verificano i seguenti tipi di modifiche:

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

Informazioni sulle impostazioni dell'upgrade di incremento

Utilizza le impostazioni di upgrade inattivo per selezionare il giusto equilibrio tra velocità e interruzione per il tuo pool di nodi durante la manutenzione del cluster. Puoi modificare il numero di nodi che GKE tenta di eseguire l'upgrade contemporaneamente modificando i parametri di upgrade inattivo in pool di nodiool 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 rimuovere quello 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 possa creare nodi di picco, il tuo 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 un nodo esistente non disponibile per ricrearlo

Imposta maxUnavailable per scegliere il numero massimo di nodi che possono essere non 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 per un massimo di 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, 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 in sequenza con questo pool di nodi, in una finestra temporale, GKE crea due nodi sottoposti ad 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 il processo di upgrade, il pool di nodi includerà da quattro a sette nodi.

Considerazioni per le impostazioni dell'upgrade di incremento

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

Regola le impostazioni di aggiornamento delle ondate per bilanciare velocità e interruzioni

La tabella seguente descrive quattro profili di upgrade diversi 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
Veloce, senza risorse di picco, più dirompente maxSurge=0 maxUnavailable=20 Pool di nodi di grandi dimensioni dopo l'esecuzione dei job
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 picco è utilizzare la configurazione predefinita, maxSurge=1;maxUnavailable=0. Con questa configurazione, gli upgrade procedono lentamente, con l'aggiunta di un solo nodo di picco alla volta, il che significa che viene eseguito l'upgrade di un solo nodo alla volta. I pod possono essere riavviati immediatamente sul nuovo nodo di picco. Questa configurazione richiede solo che le risorse creino temporaneamente un nuovo nodo.

Risorse rapide e senza picchi

Se hai un pool di nodi di grandi dimensioni e il tuo carico di lavoro non è sensibile alle interruzioni (ad esempio, un job batch che è stato eseguito fino al completamento), utilizza la seguente configurazione per massimizzare la velocità senza utilizzare risorse aggiuntive: maxSurge=0;maxUnavailable=20. Questa configurazione non attiva nodi di picco aggiuntivi e consente 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 rapidi, mentre un upgrade è in corso 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 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 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 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 a quella di picco 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 eliminare i 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 rodaggio 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.

Scegliere gli upgrade blu/verde per il tuo ambiente

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

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

  • se vuoi un lancio 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 è accettabile un aumento temporaneo dei costi dovuto a un maggiore utilizzo delle risorse.

Quando GKE utilizza gli upgrade blu/verde

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

Gli upgrade di picco verranno utilizzati per qualsiasi altra funzionalità che richieda la ricreazione dei nodi. Per saperne di più, consulta Quando vengono utilizzati gli upgrade con sovrapprezzo.

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 corrente. Una volta annullato, puoi riprenderlo 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 (i 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 corrente. Una volta annullato, puoi riprenderlo o eseguire il rollback. In questa fase, il rollback rimuoverà il cordon dal pool blu ed eliminerà il pool verde.

Fase 3: svuota la piscina 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 hanno violazioni di PodDisruptionBudget o terminationGracePeriodSeconds lunghi 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 Immersione del pool di nodi.

Inoltre, puoi controllare la durata di immersione 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 corrente. Una volta annullato, puoi riprenderlo o eseguire il rollback. In questa fase, il rollback interromperà lo svuotamento del pool blu e rimuoverà il cordon dal pool blu. I workload possono quindi essere ripianificati nel pool blu (non garantito) e il pool verde verrà 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 periodo di attesa raggiunge i 7 giorni (604.800 secondi), inizia immediatamente la fase di eliminazione del pool blu.

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, verrà immediatamente avviato 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 riprenderlo 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 sospesa. 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 aggiornamento 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 sottoposto a scale up durante questo processo se è necessaria ulteriore capacità.

Controllare un upgrade blu/verde in corso

Con gli upgrade blu/verde, mentre un upgrade è in corso 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.

Annullare (mettere in pausa) un upgrade blu/verde

Quando annulli un upgrade blu/verde, metti in pausa l'upgrade 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 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.

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

Eseguire 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 dell'upgrade di un pool di nodi, consulta Eseguire il rollback dell'upgrade 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à rimosso in modo che i workload possano essere riprogrammati. Durante questo processo, il gestore della scalabilità automatica dei cluster potrebbe fare lo scale up del pool blu in base alle necessità. 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 scoprire di più su come utilizzare il comando complete, consulta Completare un upgrade blu/verde del node pool.

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

Gli upgrade di breve durata sono una strategia di upgrade dei nodi da utilizzare esclusivamente con nodi con avvio flessibile e 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 temporanei, consulta Informazioni sulla disponibilità delle 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 flex-start. Questa strategia non ha impostazioni di configurazione.

Quando GKE utilizza upgrade di breve durata

GKE imposta automaticamente i nodi flex-start in modo che utilizzino upgrade di breve durata. I nodi che utilizzano solo il provisioning in coda, ma vengono eseguiti su cluster con 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 inattivi. Oltre agli upgrade dei nodi (modifiche alla versione), GKE utilizza upgrade di breve durata per altri tipi di aggiornamenti dei nodi, in modo simile a come vengono utilizzati gli upgrade inattivi. Per ulteriori informazioni, consulta Quando vengono utilizzati gli upgrade dinamici.

Passaggi successivi