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à.

Ripristina il cluster alla 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 di API obsolete o comportamenti imprevisti, puoi eseguire il rollback per ripristinare il cluster a un buono stato noto.

Durante un rollback, Amazon EKS riporta il server dell'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

Cosa NON viene ripristinato

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 Questi includono: il cluster è stato creato alla versione corrente, sono trascorsi più di 7 giorni dall'aggiornamento, il cluster è già stato nuovamente aggiornato a una versione più recente o una funzionalità EKS non compatibile con le versioni precedenti è stata abilitata al limite della versione corrente.

Riepilogo

Il riepilogo di alto livello del processo di rollback del cluster Amazon EKS è il seguente:

Fase 1: Rivedi le informazioni sulla preparazione al rollback

Amazon EKS valuta automaticamente il cluster rispetto a una serie di controlli di preparazione al rollback point-in-time e individua eventuali problemi tramite Cluster Insights all'interno della categoria. ROLLBACK_READINESS Queste informazioni vengono visualizzate dopo aver eseguito un upgrade e rimangono disponibili durante la finestra di idoneità al rollback di 7 giorni.

Visualizzazione delle informazioni 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 un'analisi specifica:

aws eks describe-insight \
  --cluster-name my-cluster \
  --region us-west-2 \
  --id <insight-id>

Approfondimenti rinfrescanti

EKS aggiorna le informazioni ogni 24 ore. Puoi attivare manualmente un aggiornamento dopo aver risolto i problemi utilizzando il pulsante Aggiorna nella console Amazon EKS o utilizzando la CLI:

aws eks start-insights-refresh \
  --cluster-name my-cluster \
  --region us-west-2

Il comportamento dello stato di Insight

Le informazioni con stato ERROR o UNKNOWN bloccano il rollback. Gli approfondimenti con stato PASSING o WARNING non impediscono il ripristino.

Controlli di idoneità al rollback

Amazon EKS esegue una serie di controlli come parte delle informazioni sulla preparazione al rollback. Questi controlli valutano la compatibilità dell'utilizzo dell'API (incluso il rilevamento delle modifiche a livello di campo), lo stato del cluster, l'asimmetria della versione di kubelet, l'inclinazione della versione kube-proxy e la compatibilità delle versioni aggiuntive. Per i cluster che utilizzano EKS Auto Mode, controlli aggiuntivi valutano i budget relativi alle interruzioni, le annotazioni e le configurazioni da non interrompere. NodePool PodDisruptionBudget

Usare il flag --force

Se rollback readiness insights mostra lo stato di ERRORE e desideri procedere senza risolvere i problemi, puoi utilizzare il --force flag per ignorare tutti i controlli di analisi:

aws eks update-cluster-version \
  --name my-cluster \
  --kubernetes-version 1.30 \
  --force \
  --region us-west-2

Il --force flag aggira 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 sequenziale del rollback. Per i cluster in modalità automatica, non sostituisce i controlli di interruzione. --force NodePool i budget relativi alle interruzioni, i PDB e le annotazioni da non interrompere vengono comunque rispettati.

Fase 2: Preparare i 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 della versione 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 si avvia il rollback, 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 (maxUnavailableomaxUnavailablePercentage) e la strategia di aggiornamento (Rolling o Force).

Self-managed nodi e nodi ibridi

L'utente è responsabile del ripristino dei nodi autogestiti e dei nodi ibridi. Aggiorna le AMI o le configurazioni del nodo 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 la versione kubelet skew insight con lo stato ERROR.

EKS non può ripristinare automaticamente i pod Fargate su una versione precedente di Kubelet.

Soluzione alternativa: se i pod Fargate eseguono la stessa versione di Kubernetes del piano di controllo, eliminali prima di iniziare il rollback. Quindi ripristina il piano di controllo. Tutti i pod rimanenti vengono avviati con la versione ripristinata quando li ridistribuisci.

In alternativa, utilizzatelo --force per bypassare il controllo approfondito. Tuttavia, procedere con una violazione dell'inclinazione della versione di Kubelet potrebbe comportare un comportamento imprevisto per i carichi di lavoro Fargate fino alla sostituzione di tali pod.

Fase 3: Eseguire il rollback del piano di controllo del cluster

Puoi avviare un rollback utilizzando la AWS console, la AWS CLI o l'API EKS.

Cluster di rollback utilizzando il 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.

Cluster di rollback utilizzando il 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 la AWS CLI.

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 invariato ACTIVE durante il rollback dei nodi e cambia UPDATING solo quando inizia il rollback del piano di controllo. Utilizzato describe-update 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 si ottengono al massimo e sono puntuali

Le informazioni sul cluster vengono valutate nel momento in cui viene attivato il rollback. Se apporti modifiche al cluster dopo aver verificato gli approfondimenti ma prima del completamento del rollback (ad esempio, creando risorse utilizzando nuove API), tali modifiche non vengono acquisite dal controllo di analisi iniziale e potrebbero causare problemi una volta completato il rollback.

ecc. conservazione dei dati

EKS conserva i dati etcd durante il rollback. Le risorse incompatibili aggirate utilizzando il --force flag rimangono persistenti e non vengono raccolte.

Costi di assistenza estesi

Se passi 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 si esegue l'aggiornamento dalla 1.30 (supporto esteso) alla 1.31 (supporto standard) e poi si torna alla 1.30, riprenderanno i costi del supporto esteso.

Modello di responsabilità condivisa per il rollback

EKS ripristina il piano di controllo Kubernetes alla versione desiderata. Come parte del modello di responsabilità condivisa, sei responsabile della verifica della compatibilità dell'applicazione con la versione precedente:

CloudFormation comportamento di rollback dello stack

Se un aggiornamento CloudFormation dello stack fallisce e attiva un rollback dello stack, il ripristino a una versione precedente del modello che specifica una versione precedente di Kubernetes non attiva un rollback della versione cluster. Il rollback della versione deve essere avviato in modo esplicito tramite l'API UpdateClusterVersion , la CLI o la console.

Rollback e componenti aggiuntivi

EKS non esegue automaticamente il rollback delle versioni aggiuntive durante il rollback di una versione cluster. È necessario gestire le versioni aggiuntive separatamente.

Prima di ripristinare il piano di controllo:

aws eks update-addon \
  --cluster-name my-cluster \
  --addon-name vpc-cni \
  --addon-version v1.12.0-eksbuild.2 \
  --region us-west-2

+. Una volta completato il rollback del piano di controllo, verifica che tutti i componenti aggiuntivi funzionino correttamente.

Risorse correlate