**Contribuisci a migliorare questa pagina**
Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Per contribuire a questa guida per l'utente, scegli il GitHub link **Modifica questa pagina** nel riquadro destro di ogni pagina.
Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# 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](rollback-cluster.md)
## 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.
1. Indirizza i nodi verso la versione di rollback desiderata utilizzando un sistema, rispettando i controlli di interruzione configurati. Karpenter-based
1. 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](rollback-cluster.md) 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= -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 esempio`nodes: 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](https://docs.aws.amazon.com/eks/latest/userguide/create-node-pool.html) budget relativi alle interruzioni.](https://karpenter.sh/docs/concepts/disruption/#disruption-budgets)
### 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](https://docs.aws.amazon.com/prescriptive-guidance/latest/ha-resiliency-amazon-eks-apps/pdb.html) di Kubernetes.](https://kubernetes.io/docs/tasks/run-application/configure-pdb/)
### Do-not-disrupt annotazioni
L'`karpenter.sh/do-not-disrupt`annotazione 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.](https://karpenter.sh/docs/concepts/disruption/)
## 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 karpenter.sh/do-not-disrupt-
```
### Regola PodDisruptionBudgets
Se i PDB rallentano lo sfratto dei pod, modificali temporaneamente:
```
kubectl edit pdb -n
```
**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](https://repost.aws/articles/ARONpaMO8rQAqXM_BLmhyqWA/preventing-pod-and-node-disruption-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 \
--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 a`Cancelling`. `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` o`Failed`.
**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.
1. I nodi iniziano a tornare alla versione corrente del cluster.
1. Il piano di controllo rimane nella versione corrente (non è mai stato ripristinato).
1. 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](#automode-speed-up-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 utilizzando`CancelUpdate`, 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](rollback-cluster.md)
+ [Panoramica della modalità automatica EKS](https://docs.aws.amazon.com/eks/latest/userguide/automode.html)
+ [Crea un pool di nodi per EKS Auto Mode](https://docs.aws.amazon.com/eks/latest/userguide/create-node-pool.html)
+ [Aggiorna la versione Kubernetes di un cluster EKS Auto Mode](https://docs.aws.amazon.com/eks/latest/userguide/auto-upgrade.html)
+ [Prevenzione delle interruzioni di pod e nodi in Amazon EKS Auto Mode](https://repost.aws/articles/ARONpaMO8rQAqXM_BLmhyqWA/preventing-pod-and-node-disruption-in-amazon-eks-auto-mode)
+ [Risolvi i problemi relativi alla modalità EKS Auto](https://docs.aws.amazon.com/eks/latest/userguide/auto-troubleshoot.html)
+ [Documentazione sulle interruzioni di Karpenter](https://karpenter.sh/docs/concepts/disruption/)
+ [Kubernetes PodDisruptionBudgets](https://kubernetes.io/docs/tasks/run-application/configure-pdb/)