Informazioni sugli aggiornamenti di Surge

Questo documento fornisce una breve panoramica degli aggiornamenti in sequenza standard e poi scende nel dettaglio sugli aggiornamenti di picco, che sono un tipo speciale di aggiornamento in sequenza. Rispetto agli aggiornamenti in sequenza standard, gli aggiornamenti Surge consentono di configurare la velocità dell'aggiornamento. Gli aggiornamenti di Surge ti consentono anche di controllare il modo in cui gli aggiornamenti dirompenti incidono sui tuoi carichi di lavoro.

Per informazioni su come abilitare e configurare gli aggiornamenti di picco per GKE su AWS, consulta Configurare gli aggiornamenti di incremento dei pool di nodi.

Come funzionano gli aggiornamenti in sequenza standard

Alcuni aggiornamenti a un pool di nodi, ad esempio quando modifichi le annotazioni di un pool di nodi, non richiedono il riavvio dei nodi e non comportano un aggiornamento in sequenza. Se GKE su AWS può applicare modifiche a un pool di nodi senza dover riavviare o ricreare le risorse, lo farà per evitare interruzioni.

Tuttavia, la maggior parte degli aggiornamenti a un pool di nodi in GKE su AWS di solito comporta la terminazione dei nodi esistenti e l'avvio di nuovi nodi con le impostazioni aggiornate. Il processo di terminazione dei nodi esistenti può interrompere i carichi di lavoro.

Per impostazione predefinita, GKE su AWS esegue aggiornamenti in sequenza standard. Questo metodo aggiorna i nodi uno alla volta e vengono sostituiti utilizzando un approccio "termina prima della creazione": viene prima terminato un nodo, quindi viene avviato un nuovo nodo aggiornato. Questo riduce al minimo le interruzioni perché solo un nodo viene terminato e sostituito in un determinato momento.

Ecco i passaggi che GKE su AWS esegue durante un aggiornamento in sequenza standard:

1. Seleziona un nodo dal pool di nodi e lo contrassegna come non disponibile per garantire che non vengano avviati nuovi pod. Questa azione è chiamata non pianificabile.
2. Sposta i pod attivi dal nodo contrassegnato come non pianificabile ad altri nodi disponibili all'interno del cluster. Se altri nodi hanno capacità sufficiente, possono ospitare i pod eliminati. In caso contrario, il gestore della scalabilità automatica dei cluster, che rimane attivo durante un aggiornamento in sequenza standard, avvia uno scale up e esegue il provisioning di nodi aggiuntivi per garantire che la capacità sia sufficiente per pianificare i pod rimossi. Per informazioni sulle misure adottate per proteggere i carichi di lavoro durante questo processo, consulta Protezione del carico di lavoro durante il ridimensionamento.
3. Termina il nodo contrassegnato.
4. Sostituisce il nodo non contrassegnato con uno nuovo con le impostazioni aggiornate.
5. Esegue un controllo di integrità sul nodo appena operativo. Se il pool di nodi non supera il controllo di integrità, viene contrassegnato con lo stato DEGRADED. Questo stato può essere visualizzato eseguendo il comando gcloud container aws node-pools describe. Quando un pool di nodi è contrassegnato come DEGRADED, i nuovi pod potrebbero non essere pianificati sui nodi all'interno del pool.
6. Continua l'aggiornamento, nodo per nodo, finché tutti i nodi nel pool non sono stati aggiornati.

Come funzionano gli aggiornamenti di Surge

In GKE su AWS, il metodo in sequenza standard aggiorna i nodi uno alla volta. Gli aggiornamenti Surge, una forma di aggiornamento in sequenza, consentono di aggiornare più nodi contemporaneamente. Gli aggiornamenti di Surge sono quindi più veloci di quelli in sequenza standard. Tuttavia, l'aggiornamento simultaneo di più nodi può interrompere i carichi di lavoro. Per mitigare questo problema, gli aggiornamenti di picco forniscono opzioni per modulare il livello di interruzione dei carichi di lavoro.

Un altro modo in cui gli aggiornamenti di incremento possono essere diversi da quelli in sequenza standard è il modo in cui vengono sostituiti i nodi. Gli aggiornamenti in sequenza standard sostituiscono i nodi utilizzando una strategia "Termina prima della creazione". A seconda delle impostazioni scelte, gli aggiornamenti surge possono utilizzare una strategia "Crea prima della fine", una strategia "Termina prima della creazione" o anche una combinazione di entrambe.

Il gestore della scalabilità automatica dei cluster svolge un ruolo più importante negli aggiornamenti di picco rispetto agli aggiornamenti in sequenza standard, motivo per cui è presente in una posizione di rilievo nel seguente elenco di azioni eseguite da GKE su AWS durante un aggiornamento di incremento:

1. Creazione di un nuovo gruppo di scalabilità automatica: GKE su AWS esegue il provisioning di nuovi nodi con le modifiche specificate dal comando di aggiornamento e assegna questi nuovi nodi a un nuovo gruppo di scalabilità automatica AWS (ASG).
2. Comportamento del gestore della scalabilità automatica dei cluster: all'avvio dell'aggiornamento del picco, il gestore della scalabilità automatica del cluster viene attivato per il nuovo gruppo di scalabilità automatica. Il gestore della scalabilità automatica del cluster per il gruppo di scalabilità automatica originale è disattivato. Ciò garantisce che le operazioni di scalabilità abbiano come target solo il nuovo gruppo.
3. Sostituzione dei nodi: a seconda dei parametri di aggiornamento del picco, vengono utilizzate diverse strategie per la sostituzione dei nodi:
   • "crea prima della terminazione": questa strategia viene attivata quando il parametro max-surge-update è impostato su un valore maggiore di zero. Genera nuovi nodi nel nuovo ASG prima di terminare quelli vecchi nell'ASG originale, con l'obiettivo di ridurre al minimo le interruzioni del servizio.
   • "terminate before create": questo metodo viene attivato quando il parametro max-surge-update è impostato su zero e il parametro max-unavailable-update ha un valore maggiore di zero. I nodi dell'ASG originale vengono terminati per primi, seguiti dalla creazione di nuovi nodi nel nuovo ASG.
4. Aggiustamenti delle dimensioni dei pool di nodi: durante l'aggiornamento, le dimensioni del pool di nodi (ovvero la somma dei nodi nel vecchio e nel nuovo ASG) potrebbero variare sopra o sotto il numero originale di nodi presenti nel pool prima dell'avvio dell'aggiornamento. In particolare, GKE su AWS mira a mantenere il conteggio totale dei nodi nell'intervallo compreso tra (original_count - max-unavailable-update) e (original_count + max-surge-update). Alla fine, i nodi nel precedente ASG (original_count) vengono sostituiti con nodi aggiornati nel nuovo ASG. Il gestore della scalabilità automatica dei cluster potrebbe avviare più nodi nel nuovo ASG se rileva che non è possibile pianificare i pod, ma rimane entro i limiti definiti da min-nodes e max-nodes.

Un esempio per illustrare il processo

Per comprendere meglio come funzionano gli aggiornamenti di Surge, considera l'esempio che segue. Supponi di avere un pool di nodi con 5 nodi e di eseguire questo comando:

  gcloud container aws node-pools update production-node-pool
      --cluster my-cluster \
      --location us-west1 \
      --max-surge-update 2 \
      --max-unavailable-update 1 \
      --node-version 1.27.6-gke.700

In questo esempio, max-surge-update è impostato su 2, max-unavailable-update è impostato su 1 e stai fornendo una nuova versione del pool di nodi (ovvero, cambierai la versione di GKE in esecuzione sui nodi nel pool di nodi).

L'esecuzione di questo comando attiva un aggiornamento di picco e GKE su AWS esegue le seguenti azioni:

1. Crea altri 2 nodi perché il valore di max-surge-update è uguale a 2.
2. Assegna questi due nodi aggiuntivi a un nuovo gruppo di scalabilità automatica AWS.
3. Rimuove i nodi dal gruppo di scalabilità automatica originale quando questi nuovi nodi sono operativi. GKE su AWS riduce fino a tre nodi (il valore combinato di max-surge-update e max-unavailable-update), ma garantisce che al massimo un solo nodo non sia più disponibile in qualsiasi momento (a causa del valore max-unavailable-update di 1).
4. Ripeti questi passaggi fino a quando tutti i nodi nel pool di nodi non saranno stati aggiornati alla nuova versione di GKE.

Durante questo aggiornamento, il pool di nodi contiene da 4 a 7 nodi operativi.

Aspetti da considerare prima di eseguire aggiornamenti di picco

Prima di eseguire un aggiornamento di picco, tieni presente quanto segue:

• Le istanze aggiuntive create come parte di questo passaggio di incremento possono potenzialmente superare il limite di quota delle istanze AWS. Se non disponi di quota sufficiente e non è possibile eseguire il provisioning di queste istanze aggiuntive, l'aggiornamento potrebbe non riuscire.
• Se il criterio max-unavailable-update è impostato su 0, potrebbero comunque verificarsi interruzioni dei carichi di lavoro man mano che i pod vengono rimossi e ripianificati sui nodi più recenti.
• Il numero massimo di nodi che possono essere aggiornati contemporaneamente è uguale alla somma di max-surge-update e max-unavailable-update ed è limitato a 20.

Scegli le impostazioni di picco adatte alle tue esigenze

Mentre gli aggiornamenti in sequenza standard utilizzano spesso un approccio "termina prima della creazione", gli aggiornamenti surge introducono una maggiore flessibilità. A seconda della configurazione, gli aggiornamenti di picco possono seguire una strategia di tipo "create before termina", una strategia di "terminazione prima della creazione" o una combinazione di entrambe. Questa sezione descrive le diverse configurazioni per aiutarti a selezionare l'approccio migliore per i tuoi carichi di lavoro.

La tabella seguente mostra tre impostazioni di esempio e ne evidenzia l'impatto sulla velocità dell'aggiornamento e sulle potenziali interruzioni dei carichi di lavoro:

Nome	Descrizione	Configurazione
Impostazione bilanciata (predefinita)	Bilanciata, più lenta ma meno invasiva.	maxSurge=1, maxavailable=0
Aggiornamenti rapidi senza risorse aggiuntive	Veloce, nessuna risorsa di picco, più dirompente.	maxSurge=0, maxFailed=20
Aggiornamenti rapidi meno improvvisi	Veloce, con la maggior parte delle risorse di picco e meno fastidiose.	maxSurge=20, maxavailable=0

Ciascuna delle impostazioni della tabella è descritta nelle sezioni seguenti.

Impostazione bilanciata (predefinita)

Il modo più diretto per utilizzare gli aggiornamenti di sovraccarico è con la configurazione predefinita di max-surge-update=1 e max-unavailable-update=0. Questa configurazione aggiunge un solo nodo di picco al pool di nodi durante l'aggiornamento e viene aggiornato un solo nodo alla volta, in seguito a un approccio di creazione prima della terminazione. Rispetto all'aggiornamento in sequenza non di picco standard, che equivale a (max-surge-update=0, max-unavailable-update=1), questo metodo è meno invasivo, accelera i riavvii dei pod durante gli aggiornamenti e risulta più conservativo nel relativo avanzamento.

È importante notare che l'adozione dell'impostazione bilanciata può comportare costi aggiuntivi a causa del nodo di picco temporaneo aggiunto durante l'aggiornamento. Questo nodo aggiuntivo comporta addebiti mentre è attivo, con un aumento leggermente delle spese complessive rispetto ai metodi senza nodi di picco.

Aggiornamenti rapidi senza risorse aggiuntive

Per i carichi di lavoro che possono tollerare interruzioni, potrebbe essere adatto un approccio più rapido all'aggiornamento. Puoi completare la configurazione di max-surge-update=0 e max-unavailable-update=20. Con questa configurazione, è possibile aggiornare 20 nodi contemporaneamente senza aggiungere nodi di picco. Questo metodo di aggiornamento segue un approccio "termina prima della creazione". Poiché durante il processo non vengono aggiunti nodi di picco aggiuntivi, questo metodo è anche il più conveniente, evitando spese aggiuntive associate ai nodi temporanei.

Aggiornamenti rapidi meno improvvisi

Se i tuoi carichi di lavoro sono sensibili alle interruzioni, puoi aumentare la velocità dell'aggiornamento con le seguenti impostazioni: max-surge-update=20 e max-unavailable-update=0. Questa configurazione aggiorna 20 nodi in parallelo in modalità di creazione prima della terminazione.

Tuttavia, la velocità complessiva dell'aggiornamento può essere limitata se hai configurato PodDisruptionBudgets (PDB) per i tuoi carichi di lavoro. Questo perché il PDB limita il numero di pod che possono essere svuotati in un dato momento. Anche se le configurazioni dei PDB possono variare, se crei un PDB con maxUnavailable uguale a 1 per uno o più carichi di lavoro in esecuzione sul pool di nodi, puoi rimuovere un solo pod di questi carichi di lavoro alla volta, limitando il parallelismo dell'intero aggiornamento.

Ricorda che l'avvio di più nodi di picco all'inizio del processo di aggiornamento può comportare un aumento temporaneo dei costi, soprattutto rispetto alle configurazioni che non aggiungono nodi o meno nodi durante gli aggiornamenti.

Passaggi successivi

Per informazioni su come abilitare e configurare gli aggiornamenti di picco per GKE su AWS, consulta Configurare gli aggiornamenti di incremento dei pool di nodi.