Il prodotto descritto in questa documentazione, GKE su AWS, è ora in modalità di manutenzione e verrà ritirato il 17 marzo 2027.

Questa pagina è stata tradotta dall'API Cloud Translation.

Informazioni sugli aggiornamenti di sovraccarico

Questo documento fornisce una breve panoramica degli aggiornamenti in sequenza standard e poi descrive in dettaglio gli aggiornamenti di picco, che sono un tipo speciale di aggiornamento in sequenza. Rispetto agli aggiornamenti in sequenza standard, gli aggiornamenti rapidi ti consentono di configurare la velocità dell'aggiornamento. Gli aggiornamenti di picco ti consentono anche di esercitare un certo controllo sull'impatto degli aggiornamenti sui tuoi workload.

Per informazioni su come attivare e configurare gli aggiornamenti rapidi per GKE su AWS, vedi Configurare gli aggiornamenti rapidi dei node pool.

Come funzionano gli aggiornamenti standard continui

Alcuni aggiornamenti di un pool di nodi, ad esempio quando modifichi le annotazioni di un pool di nodi, non richiedono il riavvio dei nodi e quindi non attivano 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 di un pool di nodi in GKE su AWS in genere comporta l'arresto 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 di creare": un nodo viene terminato prima e poi viene avviato un nuovo nodo aggiornato. Ciò riduce al minimo le interruzioni perché in un determinato momento viene terminato e sostituito un solo nodo.

Ecco i passaggi eseguiti da GKE su AWS durante un aggiornamento in sequenza standard:

Seleziona un nodo dal pool di nodi e lo contrassegna come non disponibile per assicurarsi che non vengano avviati nuovi pod. Questa azione è chiamata isolamento.
Sposta i pod attivi dal nodo isolato 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 del cluster, che rimane attivo durante un aggiornamento in sequenza standard, avvia uno scale up e esegue il provisioning di nodi aggiuntivi per garantire una capacità sufficiente a pianificare i pod eliminati. Per informazioni sulle misure adottate per proteggere i carichi di lavoro durante questo processo, consulta Protezione dei carichi di lavoro durante il ridimensionamento.
Termina il nodo non pianificato.
Sostituisce il nodo isolato con uno nuovo con le impostazioni aggiornate.
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 di quel pool.
Continua l'aggiornamento, nodo per nodo, finché tutti i nodi del pool non sono stati aggiornati.

Come funzionano gli aggiornamenti dei picchi

In GKE su AWS, il metodo di aggiornamento in sequenza standard aggiorna i nodi uno alla volta. Gli aggiornamenti di picco, che sono una forma di aggiornamento in sequenza, consentono di aggiornare più nodi contemporaneamente. Gli aggiornamenti di sovraccarico sono quindi più veloci degli aggiornamenti rolling standard. Tuttavia, l'aggiornamento simultaneo di più nodi può interrompere i workload. Per ridurre 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 picco possono differire dagli aggiornamenti rolling standard è il modo in cui vengono sostituiti i nodi. Gli aggiornamenti continui standard sostituiscono i nodi utilizzando una strategia di "termina prima di creare". A seconda delle impostazioni scelte, gli aggiornamenti di picco possono utilizzare una strategia "crea prima di terminare", una strategia "termina prima di creare" 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 standard, motivo per cui figura in primo piano nel seguente elenco di azioni che GKE su AWS esegue durante un aggiornamento di picco:

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 (ASG) AWS.
Comportamento del gestore della scalabilità automatica dei cluster: all'inizio dell'aggiornamento controllato, il gestore della scalabilità automatica dei cluster viene attivato per il nuovo gruppo di scalabilità automatica. Il gestore della scalabilità automatica dei cluster per il gruppo di scalabilità automatica originale è disattivato. In questo modo tutte le operazioni di scalabilità hanno come target solo il nuovo gruppo.
Sostituzione dei nodi: a seconda dei parametri di aggiornamento del picco, vengono utilizzate diverse strategie per la sostituzione dei nodi:
- "create before terminate": questa strategia viene attivata quando il parametro max-surge-update è impostato su un valore maggiore di zero. Crea 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": this method is triggered when the max-surge-update parameter is set to zero and the max-unavailable-update parameter has a value greater than zero. I nodi del gruppo di istanze gestite originale vengono terminati per primi, seguiti dalla creazione di nuovi nel nuovo gruppo di istanze gestite.
Modifiche alle dimensioni del node pool: durante l'aggiornamento, le dimensioni del pool di nodi (ovvero la somma dei nodi nel gruppo di scalabilità automatica precedente e in quello nuovo) potrebbero variare al di sopra o al di sotto del conteggio originale dei nodi presenti nel pool di nodi prima dell'inizio dell'aggiornamento. Nello specifico, GKE su AWS mira a mantenere il numero totale di nodi nell'intervallo compreso tra (original_count - max-unavailable-update) e (original_count + max-surge-update). Alla fine, i nodi nel vecchio ASG (original_count) vengono sostituiti con nodi aggiornati nel nuovo ASG. Il gestore della scalabilità automatica dei cluster potrebbe avviare più nodi nel nuovo gruppo di scalabilità automatica se rileva che i pod non possono essere pianificati, ma rimane entro i limiti definiti da min-nodes e max-nodes.

Un esempio per illustrare la procedura

Per comprendere meglio come funzionano gli aggiornamenti dei picchi, considera il seguente esempio. Supponiamo di avere un pool di nodi con 5 nodi ed esegui il seguente 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 pool di nodi (ovvero stai modificando la versione di GKE in esecuzione sui nodi del pool di nodi).

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

Crea due nodi aggiuntivi perché il valore di max-surge-update è 2.
Assegna questi due nodi aggiuntivi a un nuovo gruppo di scalabilità automatica AWS.
Rimuove i nodi dal gruppo di scalabilità automatica originale una volta che questi nuovi nodi sono operativi. GKE su AWS riduce fino a 3 nodi (il valore combinato di max-surge-update e max-unavailable-update), ma garantisce che al massimo un solo nodo diventi non disponibile in qualsiasi momento (a causa del valore max-unavailable-update pari a 1).
Ripeti questi passaggi finché tutti i nodi nel pool di nodi non sono 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 gli aggiornamenti dei picchi

Prima di eseguire un aggiornamento dei prezzi dinamici, tieni presente quanto segue:

Le istanze aggiuntive create nell'ambito di questo passaggio di picco possono potenzialmente superare il limite della quota di istanze AWS. Se non disponi di quota sufficiente e non è possibile eseguire il provisioning di queste istanze aggiuntive, l'aggiornamento potrebbe non riuscire.
Se max-unavailable-update è impostato su 0, le interruzioni dei carichi di lavoro possono comunque verificarsi quando i pod vengono rimossi e riprogrammati 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.

Scegliere le impostazioni di picco giuste per le tue esigenze

Mentre gli aggiornamenti in sequenza standard spesso utilizzano un approccio "termina prima di creare", gli aggiornamenti di picco introducono maggiore flessibilità. A seconda della configurazione, gli aggiornamenti di picco possono seguire una strategia "crea prima di terminare", una strategia "termina prima di creare" o una combinazione di entrambe. Questa sezione descrive diverse configurazioni per aiutarti a selezionare l'approccio migliore per i tuoi workload.

La tabella seguente mostra tre impostazioni di esempio ed evidenzia il loro impatto sulla velocità dell'aggiornamento e sulla potenziale interruzione dei tuoi carichi di lavoro:

Nome	Descrizione	Configurazione
Impostazione bilanciata (predefinita)	Bilanciato, più lento ma meno di disturbo.	maxSurge=1, maxUnavailable=0
Aggiornamenti rapidi senza risorse aggiuntive	Risorse rapide, senza picchi, più disruptive.	maxSurge=0, maxUnavailable=20
Aggiornamenti rapidi e meno invasivi	Veloce, con la maggior parte delle risorse di picco e meno interruzioni.	maxSurge=20, maxUnavailable=0

Ogni impostazione nella tabella è descritta nelle sezioni seguenti.

Impostazione bilanciata (predefinita)

Il modo più semplice per utilizzare gli aggiornamenti dei picchi è con la configurazione predefinita di max-surge-update=1 e max-unavailable-update=0. Questa configurazione aggiunge solo un nodo di sovraccarico al pool di nodi durante l'aggiornamento e viene aggiornato un solo nodo alla volta, seguendo un approccio "crea prima di terminare". Rispetto all'aggiornamento in sequenza standard senza incremento, che equivale a (max-surge-update=0, max-unavailable-update=1), questo metodo è meno distruttivo, accelera i riavvii dei pod durante gli aggiornamenti ed è più conservativo nella sua progressione.

È 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 durante il periodo di attività, aumentando leggermente la spesa complessiva 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 di aggiornamento più rapido. La configurazione di max-surge-update=0 e max-unavailable-update=20 consente di ottenere questo risultato. Con questa configurazione, è possibile aggiornare 20 nodi contemporaneamente senza aggiungere nodi di picco. Questo metodo di aggiornamento segue un approccio di tipo "termina prima di creare". Poiché non vengono introdotti nodi di picco aggiuntivi durante il processo, questo metodo è anche il più conveniente, in quanto evita le spese extra associate ai nodi temporanei.

Aggiornamenti rapidi e meno invasivi

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à "crea prima di terminare".

Tuttavia, la velocità complessiva dell'aggiornamento può essere limitata se hai configurato PodDisruptionBudgets (PDB) per i tuoi carichi di lavoro. Ciò avviene perché il PDB limita il numero di pod che possono essere svuotati in un dato momento. Sebbene le configurazioni dei PDB possano variare, se crei un PDB con maxUnavailable uguale a 1 per uno o più carichi di lavoro in esecuzione nel pool di nodi, può essere rimosso 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 aggiuntivi o ne aggiungono meno durante gli aggiornamenti.

Passaggi successivi