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:

Cosa NON viene ripristinato

I seguenti componenti non vengono ripristinati:

Prerequisiti

Prima di poter ripristinare un cluster, devono essere soddisfatte tutte le seguenti condizioni:

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:

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:

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 <insight-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

Comportamento relativo allo stato di

La tabella seguente descrive il significato di ogni stato di Insight e il relativo effetto sul rollback:

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

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.

Gruppi di nodi gestiti (MNG)

È necessario ripristinare i gruppi di nodi gestiti alla versione precedente prima di ripristinare il piano di controllo. Usa l'UpdateNodegroupVersionAPI:

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 (maxUnavailableormaxUnavailablePercentage) 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

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.

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": []
    }
}

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:

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-updateDa utilizzare per tenere traccia dell'avanzamento complessivo del rollback. Per ulteriori informazioni, consulta Cluster Rollback EKS Auto Mode.

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:

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:

Risorse correlate