**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 su che si trova 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à.
# Ripristina un cluster a una versione precedente di Kubernetes
Con il rollback della versione di Amazon EKS, puoi ripristinare il piano di controllo Kubernetes del cluster alla versione secondaria precedente dopo aver eseguito un aggiornamento sul posto. Se riscontri problemi dopo l'aggiornamento, come incompatibilità delle applicazioni, utilizzo obsoleto delle API o comportamenti imprevisti, puoi eseguire il rollback per ripristinare il cluster a un buono stato noto.
Durante un rollback, Amazon EKS ripristina il server API Kubernetes e i componenti del piano di controllo alla versione precedente preservando tutti i dati etcd, i carichi di lavoro dei clienti e i volumi persistenti.
## Cosa viene ripristinato
Viene eseguito il rollback dei seguenti componenti:
+ Versione del server API Kubernetes
+ I componenti del piano di controllo e le relative configurazioni
+ Versione della piattaforma (torna alla versione più recente della piattaforma per la precedente versione di Kubernetes)
+ **Nodi di lavoro EKS Auto Mode. ** Per i cluster che eseguono EKS Auto Mode, Amazon EKS gestisce automaticamente il rollback dei nodi di lavoro Auto Mode prima di ripristinare il piano di controllo. Per ulteriori informazioni, consulta [Cluster Rollback EKS Auto Mode](rollback-automode.md).
## Cosa NON viene ripristinato
I seguenti componenti non vengono ripristinati:
+ **dati ** etcd. Tutto lo stato, le risorse e le configurazioni del cluster vengono preservati.
+ **Carichi di lavoro ** dei clienti. I pod, le implementazioni e i servizi continuano a funzionare.
+ **Componenti aggiuntivi EKS. ** Add-on le versioni rimangono invariate. Li gestisci separatamente.
+ **Volumi e dati persistenti**. Tutti i dati dei clienti rimangono intatti.
+ **Self-managed nodi e nodi ** ibridi. Sei responsabile del ripristino di questi dati.
+ **Gruppi di nodi gestiti**. È necessario ripristinarli separatamente utilizzando l'`UpdateNodegroupVersion`API.
## Prerequisiti
Prima di poter ripristinare un cluster, devono essere soddisfatte tutte le seguenti condizioni:
| Requisito | Informazioni |
| --- | --- |
| **Finestra di 7 giorni ** | È necessario avviare il rollback entro 7 giorni dal completamento dell'aggiornamento. Dopo 7 giorni, il rollback non è più disponibile. |
| **Cluster aggiornato ** | Il cluster deve essere stato aggiornato alla versione corrente tramite un aggiornamento sul posto. I cluster creati nella versione corrente non possono essere ripristinati. |
| **Solo versione singola ** | È possibile eseguire il rollback solo di una versione secondaria (da N a N-1). Se hai eseguito l'aggiornamento dalla 1.31 alla 1.32 e poi alla 1.33, puoi ripristinare solo la versione 1.32, non la 1.31. |
| **Versione supportata ** | Il rollback della versione è disponibile per le versioni [ Amazon EKS ](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html#kubernetes-release-calendar) attualmente supportate. |
| **Politica di supporto estesa ** | Per tornare a una versione con supporto esteso, devi prima modificare la politica di aggiornamento del cluster in`EXTENDED`. |
| **Nessun aggiornamento automatico alla fine del supporto esteso ** | Se il cluster è stato aggiornato automaticamente al termine del supporto esteso, non puoi tornare alla versione precedente. Se il cluster è stato aggiornato automaticamente al termine del supporto standard, puoi eseguire il rollback ma devi prima modificare la politica di aggiornamento in. `EXTENDED` |
| **Stato del cluster ** | Lo `ACTIVE` stato del cluster deve essere attivo. Non è possibile avviare un rollback mentre è in corso un altro aggiornamento. |
| **Compatibilità delle funzionalità EKS ** | Se una funzionalità EKS abilitata sul cluster non è supportata nella versione precedente, la richiesta di rollback ha esito negativo. Questo controllo non può essere aggirato con. `--force` |
Oltre ai requisiti precedenti, alcune condizioni rendono impossibile il rollback anche con la bandiera. `--force` Queste condizioni includono quanto segue: il cluster è stato creato nella versione corrente, sono trascorsi più di 7 giorni dall'aggiornamento, il cluster è già stato aggiornato nuovamente a una versione più recente o una funzionalità EKS incompatibile con le versioni precedenti è stata abilitata al limite della versione corrente.
## Riepilogo
Di seguito è riportato il riepilogo di alto livello del processo di rollback del cluster Amazon EKS:
1. Rivedi le informazioni sulla preparazione al rollback per identificare eventuali problemi che potrebbero influire sul rollback.
1. Risolvi eventuali problemi di blocco (informazioni sullo stato dell'ERRORE) o usali `--force` per aggirare i controlli approfonditi.
1. Verifica che le tue applicazioni, i controller personalizzati e gli strumenti di terze parti siano compatibili con la versione precedente di Kubernetes.
1. Se i tuoi nodi di lavoro eseguono la stessa versione di Kubernetes del piano di controllo, ripristina prima i nodi di lavoro.
1. Se disponi di componenti aggiuntivi che eseguono versioni incompatibili con la versione precedente di Kubernetes, esegui il downgrade a una versione compatibile.
1. Avvia il rollback del piano di controllo.
1. Monitora l'avanzamento del rollback.
**Importante**
Per i cluster che eseguono EKS Auto Mode, il passaggio 4 viene gestito automaticamente. Quando avvii il rollback, Amazon EKS ripristina i nodi Auto Mode prima del piano di controllo. Per ulteriori informazioni, consulta [Cluster Rollback EKS Auto Mode](rollback-automode.md).
## Fase 1: Rivedi le informazioni sulla preparazione al rollback
Amazon EKS valuta automaticamente il cluster in base a una serie di controlli temporali di idoneità al rollback e individua eventuali problemi tramite le informazioni sui cluster incluse nella categoria. `ROLLBACK_READINESS` Queste informazioni vengono visualizzate dopo aver eseguito un aggiornamento e rimangono disponibili durante il periodo di idoneità al rollback di 7 giorni.
### Visualizzazione degli approfondimenti sulla preparazione al rollback
** AWS Console: **
1. Aprire la [Console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Selezionare il cluster.
1. Scegli la scheda **Approfondimenti sugli aggiornamenti**. Le informazioni sulla disponibilità al rollback vengono visualizzate qui dopo un aggiornamento.
1. Esamina eventuali approfondimenti con stato ERRORE o AVVISO.
** AWS CLI: **
```
aws eks list-insights \
--cluster-name my-cluster \
--region us-west-2 \
--filter '{"categories": ["ROLLBACK_READINESS"]}'
```
Per ottenere dettagli su una visione specifica:
```
aws eks describe-insight \
--cluster-name my-cluster \
--region us-west-2 \
--id
```
### Approfondimenti rinfrescanti
Amazon EKS aggiorna le informazioni ogni 24 ore. Puoi attivare manualmente un aggiornamento dopo aver risolto i problemi scegliendo il ** pulsante ** Aggiorna nella console Amazon EKS o utilizzando l'interfaccia a riga di comando:
```
aws eks start-insights-refresh \
--cluster-name my-cluster \
--region us-west-2
```
**Nota**
Amazon EKS aggiorna automaticamente le informazioni quando si avvia un rollback per assicurarsi che i controlli vengano eseguiti in base allo stato più recente del cluster.
### Comportamento relativo allo stato di
La tabella seguente descrive il significato di ogni stato di Insight e il relativo effetto sul rollback:
| Stato | Significato | Effetto sul rollback |
| --- | --- | --- |
| **PASSAGGIO ** | Nessun problema rilevato per questo controllo | Rollback consentito |
| **ATTENZIONE** | Potenziale problema rilevato, non bloccante | Rollback consentito (solo avviso) |
| **ERROR (ERRORE)** | È stato rilevato un problema di blocco | Rollback bloccato fino alla risoluzione o utilizzato `--force` per bypassare |
| **UNKNOWN** | Impossibile determinare lo stato | Rollback bloccato fino alla risoluzione o utilizzato `--force` per bypassare |
Gli approfondimenti con ** stato ** ERROR ** o ** UNKNOWN bloccano il rollback. Gli approfondimenti con stato PASSING o WARNING non impediscono il rollback.
### Controlli di idoneità al rollback
Amazon EKS esegue una serie di controlli nell'ambito delle informazioni sulla preparazione al rollback. Questi controlli valutano la compatibilità dell'utilizzo delle API (incluso il rilevamento delle modifiche a livello di campo), lo stato del cluster, l'inclinazione della versione di Kubelet, la distorsione della versione kube-proxy e la compatibilità delle versioni aggiuntive. Per i cluster che eseguono EKS Auto Mode, controlli aggiuntivi valutano i budget relativi alle interruzioni, le annotazioni relative alle interruzioni e le configurazioni. NodePool PodDisruptionBudget
### Usando il flag --force
Se le informazioni sulla preparazione al rollback mostrano lo stato ERROR e desideri procedere senza risolvere i problemi, puoi utilizzare il `--force` flag per bypassare tutti i controlli di approfondimento:
```
aws eks update-cluster-version \
--name my-cluster \
--kubernetes-version 1.30 \
--force \
--region us-west-2
```
**avvertimento**
L'utilizzo `--force` ignora tutti i controlli approfonditi (ERROR, WARNING, UNKNOWN) e procede direttamente con il rollback. Amazon EKS non può garantire la sicurezza del rollback quando i controlli approfonditi vengono ignorati. Ti assumi la piena responsabilità per eventuali problemi che dovessero insorgere.
La `--force` bandiera ignora solo i controlli approfonditi. Non ignora le convalide dei prerequisiti come la finestra di 7 giorni, il controllo della versione di creazione o il controllo di rollback sequenziale. Per i cluster in modalità automatica, non sovrascrive i controlli sulle interruzioni. `--force` NodePool i budget relativi alle interruzioni, i PDB e le annotazioni relative al divieto di interruzione delle attività vengono comunque rispettati.
## Fase 2: Preparazione dei nodi di lavoro
Prima di ripristinare il piano di controllo, assicurati che i nodi di lavoro siano compatibili con la versione di destinazione. La policy di distorsione delle versioni di Kubernetes richiede che i nodi di lavoro non possano eseguire una versione più recente del piano di controllo.
### Modalità automatica di EKS
Nessuna operazione necessaria. Quando avvii il rollback, Amazon EKS ripristina automaticamente i nodi Auto Mode prima del piano di controllo. Per ulteriori informazioni, consulta [Cluster Rollback EKS Auto Mode](rollback-automode.md).
### Gruppi di nodi gestiti (MNG)
È necessario ripristinare i gruppi di nodi gestiti alla versione precedente prima di ripristinare il piano di controllo. Usa l'`UpdateNodegroupVersion`API:
```
aws eks update-nodegroup-version \
--cluster-name my-cluster \
--nodegroup-name my-nodegroup \
--kubernetes-version 1.30 \
--region us-west-2
```
L'aggiornamento del gruppo di nodi rispetta le impostazioni di aggiornamento configurate (`maxUnavailable`or`maxUnavailablePercentage`) e la strategia di aggiornamento (Rolling o Force).
### Self-managed nodi e nodi ibridi
Sei responsabile del ripristino dei nodi autogestiti e dei nodi ibridi. Aggiorna le AMI o le configurazioni dei nodi per utilizzare la versione precedente di Kubernetes prima di ripristinare il piano di controllo.
### Fargate
Il rollback della versione non è supportato per i nodi di lavoro Fargate. È possibile ripristinare il piano di controllo di un cluster che utilizza Fargate, ma i pod Fargate che eseguono la stessa versione di Kubernetes del piano di controllo attivano lo skew insight della versione kubelet con lo stato ERROR.
Amazon EKS non è in grado di ripristinare automaticamente i pod Fargate a una versione precedente di Kubelet.
**Soluzione alternativa: ** se hai pod Fargate che eseguono la stessa versione di Kubernetes del piano di controllo, eliminali prima di avviare il rollback. Quindi ripristina il piano di controllo. Tutti i pod rimanenti vengono avviati con la versione ripristinata quando li ridistribuisci.
In alternativa, usala `--force` per bypassare l'insight check. Tuttavia, una violazione della distorsione della versione di Kubelet potrebbe causare un comportamento imprevisto dei carichi di lavoro di Fargate fino alla sostituzione dei pod.
## Fase 3: Ripristina il piano di controllo del cluster
È possibile avviare un rollback utilizzando la AWS console, la AWS CLI o l'API EKS.
### Eseguire il rollback di un cluster utilizzando AWS Console
1. Aprire la [Console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Selezionare il cluster.
1. Scegli il menu a ** discesa ** Azioni.
1. Scegli la versione del cluster ** Rollback. **
1. Consulta il riepilogo del rollback, inclusi eventuali avvisi di approfondimento.
1. Scegli la versione ** Rollback. **
Il completamento del rollback richiede alcuni minuti. Per i cluster in modalità automatica, la fase di rollback del nodo potrebbe richiedere più tempo. Per ulteriori informazioni, consulta [Cluster Rollback EKS Auto Mode](rollback-automode.md).
### Esegui il rollback di un cluster utilizzando AWS CLI
Usa il `update-cluster-version` comando esistente con la versione precedente (N-1) di Kubernetes:
```
aws eks update-cluster-version \
--name my-cluster \
--kubernetes-version 1.30 \
--region us-west-2
```
Risposta di esempio:
```
{
"update": {
"id": "e4091a28-ea14-48fd-a8c7-975aeb469e8a",
"status": "InProgress",
"type": "VersionRollback",
"params": [
{
"type": "Version",
"value": "1.30"
},
{
"type": "PlatformVersion",
"value": "eks.16"
}
],
"createdAt": "2026-05-12T16:56:01.082000-04:00",
"errors": []
}
}
```
**Nota**
Amazon EKS esegue un aggiornamento delle informazioni prima di eseguire il rollback se i dati di insight sono obsoleti.
## Fase 4: Monitora l'avanzamento del rollback
Puoi monitorare lo stato del rollback del cluster utilizzando la console Amazon EKS o l' AWS interfaccia a riga di comando.
** AWS CLI: **
```
aws eks describe-update \
--name my-cluster \
--region us-west-2 \
--update-id e4091a28-ea14-48fd-a8c7-975aeb469e8a
```
** AWS Console: **
1. Aprire la [Console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Selezionare il cluster.
1. Scegli la ** scheda Cronologia ** aggiornamenti.
1. Individua l'ID di aggiornamento associato al rollback per visualizzarne lo stato attuale.
### Transizioni di stato
Per i cluster standard (senza modalità automatica):
```
InProgress → Successful
InProgress → Failed
```
Per i cluster in modalità automatica, lo stato del cluster rimane attivo `ACTIVE` durante il rollback dei nodi e cambia `UPDATING` solo quando inizia il rollback del piano di controllo. `describe-update`Da utilizzare per tenere traccia dell'avanzamento complessivo del rollback. Per ulteriori informazioni, consulta [Cluster Rollback EKS Auto Mode](rollback-automode.md).
Quando viene visualizzato uno `Successful` stato, il rollback è completo.
## Considerazioni e avvertenze
### Gli approfondimenti sono la cosa migliore da fare e sono puntuali
Le informazioni sui cluster vengono valutate nel momento in cui viene attivato il rollback. Se apporti modifiche al cluster dopo aver controllato gli insight ma prima del completamento del rollback (ad esempio, creando risorse utilizzando nuove API), tali modifiche non vengono rilevate dal controllo di approfondimento iniziale e potrebbero causare problemi una volta completato il rollback.
### conservazione dei dati etcd
Amazon EKS conserva i dati etcd durante il rollback. Le risorse incompatibili bypassate utilizzando il `--force` flag rimangono persistenti e non vengono raccolte inutili.
### Costi di assistenza estesa
Se si esegue il rollback da una versione con supporto standard a una versione con supporto esteso, il cluster inizia a incorrere in costi di supporto esteso. Ad esempio, se esegui l'upgrade da 1.30 (supporto esteso) a 1.31 (supporto standard) e poi ritorni alla 1.30, i costi del supporto esteso riprendono.
### Modello di responsabilità condivisa per il rollback
Amazon EKS ripristina il piano di controllo di Kubernetes alla versione desiderata. Come parte del modello di responsabilità condivisa, sei responsabile della verifica della compatibilità delle applicazioni con la versione precedente:
+ Amazon EKS è responsabile del ripristino sicuro dei componenti del piano di controllo.
+ È tua responsabilità assicurarti che le tue applicazioni, configurazioni e dipendenze siano compatibili con la versione precedente.
+ È necessario esaminare eventuali incompatibilità tra le versioni, valutare l'esposizione del cluster e mitigare eventuali problemi.
### CloudFormation comportamento di rollback dello stack
Se un aggiornamento CloudFormation dello stack AWS fallisce e attiva un rollback dello stack, il ripristino a una versione precedente del modello che specifica una versione precedente di Kubernetes non attiva il rollback della versione del cluster. Il rollback della versione deve essere avviato esplicitamente tramite l'API, la CLI o la console. `UpdateClusterVersion`
## Rollback e componenti aggiuntivi
Amazon EKS non esegue automaticamente il rollback delle versioni aggiuntive durante il rollback di una versione del cluster. È necessario gestire le versioni aggiuntive separatamente.
Prima di ripristinare il piano di controllo:
1. Verifica la compatibilità del componente aggiuntivo con la versione di destinazione utilizzando le informazioni sulla disponibilità al rollback.
1. Se una versione aggiuntiva è incompatibile con la versione precedente di Kubernetes, esegui prima il downgrade:
```
aws eks update-addon \
--cluster-name my-cluster \
--addon-name vpc-cni \
--addon-version v1.22.4-eksbuild.3 \
--region us-west-2
```
1. Una volta completato il rollback del piano di controllo, verifica che tutti i componenti aggiuntivi funzionino correttamente.
**Nota**
Gli approfondimenti sulla preparazione al rollback controllano solo le versioni dei componenti aggiuntivi. EKS-managed Per i componenti aggiuntivi autogestiti, sei responsabile della convalida della compatibilità con la versione di destinazione prima del rollback.
## Risorse correlate
+ [Cluster Rollback EKS Auto Mode](rollback-automode.md)
+ [Aggiornamento del cluster esistente alla nuova versione di Kubernetes](update-cluster.md)
+ [Prepararsi agli aggiornamenti delle versioni di Kubernetes e risolvere i problemi di configurazione errata con gli approfondimenti sui cluster](cluster-insights.md)
+ [Comprendi il ciclo di vita della versione di Kubernetes su Amazon EKS ](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)
+ [Aggiorna un gruppo di nodi gestiti ](https://docs.aws.amazon.com/eks/latest/userguide/update-managed-node-group.html)
+ [Procedure consigliate per gli aggiornamenti dei cluster ](https://docs.aws.amazon.com/eks/latest/best-practices/cluster-upgrades.html)