Cluster Rollback EKS Auto Mode

Quando avvii un rollback di versione su un cluster che esegue EKS Auto Mode, Amazon EKS gestisce automaticamente il rollback dei nodi di lavoro in modalità automatica prima di ripristinare il piano di controllo. Questa pagina spiega come funziona il rollback dei nodi in modalità automatica, come velocizzarlo e come annullarlo se necessario.

Per informazioni generali sul rollback della versione, inclusi i prerequisiti, i controlli approfonditi e il processo di rollback complessivo, consulta. Ripristina il cluster alla versione precedente di Kubernetes

Come funziona il rollback in modalità automatica

EKS Auto Mode utilizza un Karpenter-based sistema per gestire l'infrastruttura dei nodi di lavoro, inclusi gli aggiornamenti e i rollback delle versioni di Kubernetes. Quando chiamate UpdateClusterVersion con la versione precedente (N-1) su un cluster con la modalità automatica abilitata, EKS esegue la seguente sequenza:

1. Convalida i prerequisiti e aggiorna le informazioni sulla preparazione al rollback.

2. Indirizza i nodi verso la versione di rollback desiderata utilizzando un sistema, rispettando i controlli di interruzione configurati. Karpenter-based

3. Dopo che tutti i nodi rientrano nella policy di distorsione della versione di Kubernetes per la versione di rollback desiderata, EKS ricontrolla le informazioni e procede con il rollback del piano di controllo.

Il piano di controllo rimane sulla versione corrente (più recente) e continua a servire il traffico normalmente mentre i nodi eseguono il rollback. La policy di inclinazione della versione di Kubernetes consente ai nodi di eseguire fino a tre versioni minori precedenti al kube-apiserver, quindi questo stato intermedio è valido.

Nota

Il rollback viene attivato utilizzando la stessa API e lo stesso processo descritti in. Ripristina il cluster alla versione precedente di Kubernetes Non esiste un'API separata per il rollback del nodo Auto Mode.

Nota

La fase di rollback del nodo (fase 2) può richiedere da pochi minuti a 7 giorni, a seconda dei controlli di interruzione. Se il rollback del nodo non viene completato entro il timeout configurato, l'aggiornamento viene contrassegnato come non riuscito.

Nota

Mentre è in corso un rollback, gli altri aggiornamenti del piano di controllo attivati dal cliente vengono bloccati. Per eseguire un aggiornamento diverso, annulla prima il rollback utilizzando l'API. CancelUpdate

Stato del cluster durante il rollback

Fase	Stato del cluster	Cosa sta succedendo
Ripristino del nodo in corso	ACTIVE	Karpenter sta sostituendo i nodi con l'AMI della versione precedente. Il piano di controllo è funzionante e serve il traffico nella versione attuale.
Control plane rollback	AGGIORNAMENTO IN CORSO	I componenti del server API e del piano di controllo vengono ripristinati alla versione precedente.
Rollback completato	ACTIVE	Cluster è completamente aggiornato alla versione precedente.

Lo stato del cluster rimane ACTIVE durante la fase di rollback del nodo. Usa ListUpdates o DescribeUpdate per determinare se è in corso un rollback. Nella console Amazon EKS, accedi al tuo cluster e apri la scheda Cronologia degli aggiornamenti per visualizzare lo stato dell'ID di aggiornamento associato al rollback.

Per monitorare l'avanzamento dei singoli nodi durante il rollback, controlla la versione Kubernetes dei tuoi nodi Auto Mode:

kubectl get nodes -l karpenter.sh/nodepool=<nodepool-name> -o wide

Controlli delle interruzioni

Il rollback in modalità automatica rispetta tutti i controlli di interruzione esistenti. Questi controlli determinano la velocità con cui i nodi possono essere sostituiti e potrebbero influire in modo significativo sulla durata del rollback.

NodePool Budget per le interruzioni

NodePool i budget per le interruzioni controllano quanti nodi possono essere interrotti contemporaneamente. Durante il rollback, Karpenter rispetta questi budget quando riporta i nodi alla versione precedente.

• Un budget di quattro drift blocca il rollback a tempo indeterminato. nodes: 0 Ciò attiva un'analisi ERROR.

• Un budget restrittivo (ad esempionodes: 1) rallenta il rollback ma consente l'avanzamento.

Esempio NodePool con un budget per le interruzioni che consente di sostituire il 10% dei nodi alla volta:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  disruption:
    budgets:
      - nodes: "10%"
        reasons:
          - Drifted

Per ulteriori informazioni sulla configurazione dei budget per le NodePool interruzioni, consulta Create a Node Pool for EKS Auto Mode e Karpenter per i budget relativi alle interruzioni.

PodDisruptionBudgets

Kubernetes viene premiata durante la sostituzione dei nodi. PodDisruptionBudgets Se un PDB impedisce lo sfratto dei pod, l'interruzione del nodo viene ritardata fino al. TerminationGracePeriod

• PDB con interruzione del nodo di ritardo. maxUnavailable: 0 Ciò attiva un'analisi di AVVISO.

• I PDB non bloccano in modo permanente il rollback ma possono rallentarlo in modo significativo.

Per ulteriori informazioni, consulta Proteggi i carichi di lavoro critici con un PDB e la documentazione PDB di Kubernetes.

Do-not-disrupt annotazioni

L'karpenter.sh/do-not-disruptannotazione può essere impostata su nodi o pod:

Sui nodi: blocca l'interruzione dei nodi a tempo indeterminato. Ciò attiva un'analisi ERROR e deve essere rimosso prima che il rollback possa procedere su quel nodo.

Sui pod: ritarda l'interruzione del nodo fino al. TerminationGracePeriod Ciò attiva un'analisi di AVVISO ma non blocca in modo permanente il rollback.

Per ulteriori informazioni sul comportamento delle interruzioni di Karpenter, consulta la documentazione relativa alle interruzioni di Karpenter.

Accelerazione del rollback

Se il rollback richiede più tempo del previsto, puoi modificare i controlli delle interruzioni mentre è in corso il rollback.

Aumenta i budget per le interruzioni NodePool

Modifica la NodePool risorsa per consentire più sostituzioni simultanee dei nodi:

kubectl edit nodepool default

Modifica il budget impostandolo su un valore più alto:

spec:
  disruption:
    budgets:
      - nodes: "50%"
        reasons:
          - Drifted

Rimuovi le annotazioni «non interrompere» dai nodi

Elenca i nodi con l'annotazione e rimuovila:

# List nodes with the annotation
kubectl get nodes -o json | jq '.items[] | select(.metadata.annotations["karpenter.sh/do-not-disrupt"] == "true") | .metadata.name'

# Remove from a specific node
kubectl annotate node <node-name> karpenter.sh/do-not-disrupt-

Regola PodDisruptionBudgets

Se i PDB rallentano lo sfratto dei pod, modificali temporaneamente:

kubectl edit pdb <pdb-name> -n <namespace>

avvertimento

La regolazione dei controlli delle interruzioni influisce sulle garanzie di disponibilità delle applicazioni. Assicuratevi di comprenderne l'impatto prima di apportare modifiche alla produzione.

Per ulteriori informazioni sulla gestione dei controlli delle interruzioni, consulta Prevenzione dell'interruzione di pod e nodi in Amazon EKS Auto Mode.

Annullamento di un rollback

Un rollback è in uno stato annullabile solo durante il rollback dei nodi. È possibile utilizzare CancelUpdate durante questa fase per interrompere l'operazione.

aws eks cancel-update \
  --name my-cluster \
  --update-id <update-id> \
  --region us-west-2

Annulla il comportamento

Aspetto	Comportamento
Quando annullabile	Solo durante il rollback dei nodi della modalità Auto (prima che inizi il rollback del piano di controllo)
Semantica	Best-effort fermare. Interrompe l'operazione di rollback del nodo.
Mid-disruption nodi	Se un nodo è a metà dell'interruzione al momento dell'annullamento, completa l'operazione corrente.
Post-cancellation stato	Aggiorna le transizioni da Cancelling a. Cancelled
Stato del cluster	Rimane ACTIVE dappertutto.

Dopo la cancellazione

In caso di annullamento riuscito, i nodi passano alla versione corrente del cluster come di consueto. L'aggiornamento passa da aCancelling. Cancelled

Dopo l'annullamento, puoi immediatamente:

• Riprova a eseguire il rollback (purché rientri nella finestra di idoneità di 7 giorni).

• Esegui un aggiornamento diverso del cluster.

• Lascia il cluster così com'è nella versione corrente.

Quando l'annullamento non è possibile

L'annullamento ha esito negativo se il rollback del nodo è già completo e il rollback del piano di controllo è iniziato o se l'aggiornamento è già stato completato con Successful oFailed.

Nota

CloudFormation e Terraform non supportano direttamente l'API. CancelUpdate Se è necessario annullare un rollback avviato tramite IAc, è necessario chiamare direttamente l'API.

Timeout di rollback

Il rollback del nodo Auto Mode ha un timeout configurabile controllato dal parametro in. timeoutMinutes rollbackConfig Il timeout predefinito è 720 minuti (12 ore). È possibile impostare un valore compreso tra 120 minuti (2 ore) e 10080 minuti (7 giorni). Il timeout è una proprietà con limite minimo, il che significa che non si verifica prima del tempo specificato, ma può verificarsi poco dopo.

aws eks update-cluster-version \
  --name my-cluster \
  --kubernetes-version 1.30 \
  --rollback-config timeoutMinutes=1440 \
  --region us-west-2

Se tutti i nodi non hanno completato il rollback entro il timeout specificato:

1. Il timeback scade.

2. I nodi iniziano a tornare alla versione corrente del cluster.

3. Il piano di controllo rimane nella versione corrente (non è mai stato ripristinato).

4. Lo stato di aggiornamento passa a. Failed

Dopo un timeout, puoi riprovare a eseguire il rollback se sei ancora entro il periodo di validità del rollback di 7 giorni dall'aggiornamento originale. In pratica, se il rollback del nodo scade al giorno 7, è probabile che anche la finestra di idoneità al rollback sia scaduta, poiché entrambi sono di 7 giorni.

Per evitare i timeout, consulta le informazioni sulla preparazione al rollback prima di iniziare il rollback. Questi approfondimenti segnalano eventuali interruzioni, budget o annotazioni che potrebbero rallentare il processo di rollback dei nodi.

Il flag --force e la modalità Auto

Il --force flag on ignora UpdateClusterVersion solo i controlli di analisi approfondita del cluster. Non ha alcun effetto sul comportamento di interruzione dei nodi in modalità automatica.

Anche con--force:

• NodePool i budget destinati alle interruzioni vengono comunque rispettati.

• PodDisruptionBudgets sono ancora onorati.

• Do-not-disrupt le annotazioni sono ancora rispettate.

• Il timeout di rollback del nodo di 7 giorni è ancora valido.

L'unico modo per accelerare il rollback dei nodi è modificare autonomamente i controlli di interruzione. Per informazioni dettagliate, vedi Accelerazione del rollback.

conflitti di timeout IAc

Infrastructure-as-Code gli strumenti presentano limitazioni di timeout che potrebbero entrare in conflitto con la durata del rollback in modalità automatica. CloudFormation consente fino a 36 ore per risorsa. Se l'operazione scade, la CloudFormation considera come un'operazione non operativa, il che può lasciare il cluster in uno stato diverso in cui il modello non riflette la versione effettiva del cluster. Il rollback della versione deve essere avviato in modo esplicito. Terraform Enterprise/Cloud ha un timeout di circa 24 ore, sebbene i timeout lato client possano variare a seconda della scadenza delle credenziali e di altri fattori.

Per allineare la durata del rollback con lo strumento IaC, utilizza il parametro in per impostare un timeout appropriato. timeoutMinutes rollbackConfig Se il tuo strumento IAc va in timeout, usa direttamente l' CancelUpdate API per riprendere il controllo. Se disponi di budget limitati per le interruzioni, valuta la possibilità di avviare il rollback direttamente tramite CLI o API anziché IAc.

Aggiornamenti di sistema durante il rollback del nodo

Mentre i nodi della modalità automatica vengono ripristinati, EKS continua a mantenere il piano di controllo sicuro e disponibile.

Customer-triggered gli aggiornamenti (come UpdateClusterVersion o UpdateClusterConfig) vengono bloccati mentre è in corso il rollback del nodo. Se devi eseguire un aggiornamento ad alta priorità, annulla prima il rollback utilizzandoCancelUpdate, quindi esegui l'aggiornamento e riavvia il rollback se è ancora all'interno della finestra di idoneità.

Risorse correlate

• Ripristina il cluster alla versione precedente di Kubernetes

• Panoramica della modalità automatica EKS

• Crea un pool di nodi per EKS Auto Mode

• Aggiorna la versione Kubernetes di un cluster EKS Auto Mode

• Prevenzione delle interruzioni di pod e nodi in Amazon EKS Auto Mode

• Risolvi i problemi relativi alla modalità EKS Auto

• Documentazione sulle interruzioni di Karpenter

• Kubernetes PodDisruptionBudgets