Informazioni sugli aggiornamenti di Surge

Questo documento fornisce una breve panoramica degli aggiornamenti in sequenza standard, per poi approfondire gli aggiornamenti per picchi, che sono un tipo speciale di aggiornamento in sequenza. Rispetto agli aggiornamenti in sequenza standard, gli aggiornamenti di picco ti consentono di configurare la velocità dell'aggiornamento. Gli aggiornamenti di picco ti consentono inoltre di esercitare un certo controllo sull'entità dell'interruzione dei carichi di lavoro causata dagli aggiornamenti.

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

Come funzionano gli aggiornamenti incrementali 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 quindi non attivano un aggiornamento progressivo. 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 prevede solitamente la terminazione dei nodi esistenti e il lancio 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": prima viene terminato un nodo e poi viene lanciato un nuovo nodo aggiornato. In questo modo, le interruzioni vengono ridotte al minimo perché in un determinato momento viene terminato e sostituito un solo nodo.

Di seguito sono riportati i passaggi eseguiti da GKE su AWS durante un aggiornamento in sequenza standard:

  1. 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.
  2. Sposta i pod attivi dal nodo messo in isolamento ad altri nodi disponibili all'interno del cluster. Se altri nodi dispongono di capacità sufficiente, ospitano i pod espulsi. In caso contrario, il gestore della scalabilità automatica del cluster, che rimane attivo durante un aggiornamento progressivo standard, avvia uno scale up e esegue il provisioning di nodi aggiuntivi per garantire la capacità sufficiente per pianificare i pod espulsi. Per informazioni sulle misure adottate per proteggere i carichi di lavoro durante questa procedura, consulta Protezione dei carichi di lavoro durante il ridimensionamento.
  3. Termina il nodo in isolamento.
  4. Sostituisce il nodo isolato 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 puoi 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, fino a quando non sono stati aggiornati tutti i nodi del pool.

Come funzionano gli aggiornamenti per i picchi di domanda

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, ti consentono di aggiornare più nodi contemporaneamente. Gli aggiornamenti di picco sono quindi più rapidi rispetto agli aggiornamenti graduali standard. Tuttavia, l'aggiornamento di più nodi contemporaneamente può interrompere i carichi di lavoro. Per ridurre il problema, gli aggiornamenti per picchi offrono opzioni per regolare il livello di interruzione dei carichi di lavoro.

Un altro modo in cui gli aggiornamenti di picco possono differire dagli aggiornamenti incrementali standard è il modo in cui vengono sostituiti i nodi. Gli aggiornamenti incrementali standard sostituiscono i nodi utilizzando una strategia di "termina prima di creare". A seconda delle impostazioni scelte, gli aggiornamenti per picchi 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 incrementali standard, motivo per cui è in evidenza nel seguente elenco di azioni intraprese da GKE su AWS durante un aggiornamento di picco:

  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 li assegna a un nuovo gruppo di scalabilità automatica (ASG) AWS.
  2. Comportamento del gestore della scalabilità automatica dei cluster: all'inizio dell'aggiornamento per l'aumento improvviso, 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 viene disattivato. In questo modo, tutte le operazioni di ridimensionamento hanno come target solo il nuovo gruppo.
  3. Sostituzioni dei nodi: a seconda dei parametri di aggiornamento dell'ondata, 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. Genera nuovi nodi nel nuovo gruppo di istanze Amazon prima di terminare quelli vecchi nel gruppo di istanze Amazon originale, allo scopo 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 nel nuovo ASG.
  4. Aggiustamenti delle dimensioni del pool di nodi: durante l'aggiornamento, la dimensione del pool di nodi (ovvero la somma dei nodi nel vecchio e nel nuovo gruppo di istanze elastiche) potrebbe variare al di sopra o al di sotto del numero originale di nodi presenti nel pool di nodi prima dell'inizio dell'aggiornamento. Nello specifico, GKE su AWS mira a mantenere il numero totale di nodi compreso nell'intervallo da (original_count - max-unavailable-update) a (original_count + max-surge-update). Alla fine, i nodi nel vecchio gruppo di istanze autoscalabili (original_count) vengono sostituiti con i nodi aggiornati nel nuovo gruppo di istanze autoscalabili. Il gestore della scalabilità automatica del cluster potrebbe lanciare altri nodi nel nuovo ASG 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 il processo

Per comprendere meglio il funzionamento degli aggiornamenti delle tariffe di picco, considera il seguente esempio. Supponiamo che tu abbia un pool di nodi con 5 nodi ed esegua 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 fornisci una nuova versione del 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 di picco e GKE su AWS esegue le seguenti azioni:

  1. Crea 2 nodi aggiuntivi perché il valore di max-surge-update è pari 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 una volta che i nuovi nodi sono operativi. GKE su AWS arresta fino a 3 nodi (il valore combinato di max-surge-update e max-unavailable-update), ma garantisce che al massimo un solo nodo non sia disponibile in qualsiasi momento (a causa del valore max-unavailable-update pari a 1).
  4. Ripeti questi passaggi finché tutti i nodi del 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 per i picchi di traffico

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

  • Le istanze aggiuntive create nell'ambito di questo passaggio di picco 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 max-unavailable-update è impostato su 0, le interruzioni dei carichi di lavoro possono comunque verificarsi man mano che 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

Sebbene gli aggiornamenti in sequenza standard utilizzino spesso un approccio "termina prima di creare", gli aggiornamenti per picchi introducono una maggiore flessibilità. A seconda della configurazione, gli aggiornamenti per picchi possono seguire una strategia di "creazione prima dell'interruzione", una strategia di "interruzione prima della creazione" o una combinazione di entrambe. Questa sezione descrive 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 sulla potenziale interruzione dei carichi di lavoro:

Nome Descrizione Configurazione
Impostazione Bilanciata (predefinita) Equilibrato, più lento, ma meno invasivo. maxSurge=1, maxUnavailable=0
Aggiornamenti rapidi senza risorse aggiuntive Risorse rapide, senza picchi, più impattanti. maxSurge=0, maxUnavailable=20
Aggiornamenti rapidi meno invasivi Veloce, con risorse di picco e meno disgregante. maxSurge=20, maxUnavailable=0

Ognuna delle impostazioni nella tabella è descritta nelle sezioni seguenti.

Impostazione Bilanciata (predefinita)

Il modo più semplice per utilizzare gli aggiornamenti di picco è 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, seguendo un approccio "crea prima di terminare". Rispetto all'aggiornamento in sequenza standard senza picco, che è equivalente a (max-surge-update=0, max-unavailable-update=1), questo metodo è meno disruptive, 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 mentre è attivo, 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 contemporaneamente 20 nodi senza aggiungere nodi di picco. Questo metodo di aggiornamento segue un approccio "termina prima di creare". Poiché durante il processo non vengono introdotti nodi di picco aggiuntivi, questo metodo è anche il più conveniente, in quanto evita le spese extra associate ai nodi temporanei.

Aggiornamenti rapidi meno invasivi

Se i tuoi carichi di lavoro sono sensibili alle interruzioni, puoi aumentare la velocità dell'upgrade con le seguenti impostazioni: max-surge-update=20 e max-unavailable-update=0. Questa configurazione aggiorna 20 nodi in parallelo in un modo "crea prima di terminare".

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 determinato 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, solo un pod di questi carichi di lavoro può essere espulso alla volta, limitando il parallelismo dell'intero aggiornamento.

Ricorda che l'avvio di più nodi di picco all'inizio del processo di aggiornamento può portare a un aumento temporaneo dei costi, soprattutto se confrontato con le configurazioni che non aggiungono nodi aggiuntivi o ne aggiungono meno durante gli aggiornamenti.

Passaggi successivi

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