Aidez à améliorer cette page

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Pour contribuer à ce guide de l'utilisateur, cliquez sur le GitHub lien Modifier cette page sur qui se trouve dans le volet droit de chaque page.

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Restaurer le cluster à la version précédente de Kubernetes

Avec la restauration de la version Amazon EKS, vous pouvez rétablir le plan de contrôle Kubernetes de votre cluster vers la version mineure précédente après avoir effectué une mise à niveau sur place. Si vous rencontrez des problèmes après la mise à niveau, tels que des incompatibilités d'applications, une utilisation obsolète des API ou un comportement inattendu, vous pouvez revenir en arrière pour restaurer votre cluster dans un état connu comme bon.

Lors d'une restauration, Amazon EKS rétablit la version précédente du serveur d'API Kubernetes et des composants du plan de contrôle tout en préservant toutes les données etcd, les charges de travail des clients et les volumes persistants.

Qu'est-ce qui est annulé ?

Ce qui n'est PAS annulé

Conditions préalables

Avant de pouvoir annuler un cluster, toutes les conditions suivantes doivent être remplies :

Outre les exigences précédentes, certaines conditions rendent le retour en arrière impossible, même avec le --force drapeau. Cela inclut : le cluster a été créé avec la version actuelle, plus de 7 jours se sont écoulés depuis la mise à niveau, le cluster a déjà été à nouveau mis à niveau vers une version plus récente ou une fonctionnalité EKS rétroincompatible a été activée à la limite de version actuelle.

Résumé

Le résumé général du processus de restauration du cluster Amazon EKS est le suivant :

Étape 1 : Passez en revue les informations sur le niveau de préparation au rollback

Amazon EKS évalue automatiquement votre cluster par rapport à un ensemble de vérifications ponctuelles de l'état de préparation à la restauration et identifie les éventuels problèmes grâce aux informations du cluster répertoriées dans la catégorie. ROLLBACK_READINESS Ces informations apparaissent une fois que vous avez effectué une mise à niveau et restent disponibles pendant la période d'éligibilité à la rétrogradation de 7 jours.

Consulter les informations sur le niveau de préparation à la restauration

AWS Console :

AWS CLI :

aws eks list-insights \
  --cluster-name my-cluster \
  --region us-west-2 \
  --filter '{"categories": ["ROLLBACK_READINESS"]}'

Pour obtenir des détails sur un aperçu spécifique :

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

Des informations rafraîchissantes

EKS actualise les informations toutes les 24 heures. Vous pouvez déclencher manuellement une actualisation après avoir résolu les problèmes à l'aide du bouton Actualiser de la console Amazon EKS ou à l'aide de la CLI :

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

Insight, statut, comportement

Les informations dont le statut est ERROR ou UNKNOWN bloquent l'annulation. Les informations présentant le statut PASSING ou WARNING ne vous empêchent pas de revenir en arrière.

Contrôles de préparation à l'annulation

Amazon EKS effectue une série de vérifications dans le cadre des informations relatives à l'état de préparation au rollback. Ces vérifications évaluent la compatibilité de l'utilisation des API (y compris la détection des modifications au niveau des champs), l'état du cluster, l'asymétrie de version de Kubelet, l'asymétrie de version de Kube-proxy et la compatibilité des versions complémentaires. Pour les clusters exécutant le mode automatique EKS, des contrôles supplémentaires évaluent les budgets d' NodePool interruption, les annotations de non-interruption et les configurations. PodDisruptionBudget

Utilisation de l'indicateur --force

Si les informations relatives à l'état de préparation à la restauration indiquent un état d'ERREUR et que vous souhaitez poursuivre sans résoudre les problèmes, vous pouvez utiliser le --force drapeau pour contourner toutes les vérifications d'informations :

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

Le --force drapeau contourne uniquement les vérifications d'aperçu. Il ne contourne pas les validations préalables telles que le délai de 7 jours, le contrôle de la version de création ou le contrôle de restauration séquentiel. Pour les clusters en mode automatique, --force ne remplace pas les contrôles d'interruption. NodePool les budgets d'interruption, les PDB et les annotations « ne pas perturber » sont toujours respectés.

Étape 2 : Préparation des nœuds de travail

Avant de restaurer le plan de contrôle, assurez-vous que vos nœuds de travail sont compatibles avec la version cible. La politique de distorsion des versions de Kubernetes exige que les nœuds de travail ne puissent pas exécuter une version plus récente que le plan de contrôle.

Mode automatique EKS

Aucune action requise. Lorsque vous lancez le rollback, EKS annule automatiquement les nœuds du mode automatique situés avant le plan de contrôle. Pour de plus amples informations, veuillez consulter Rétrograder les clusters en mode automatique EKS.

Groupes de nœuds gérés (MNG)

Vous devez rétablir la version précédente de vos groupes de nœuds gérés avant de restaurer le plan de contrôle. Utilisez l'UpdateNodegroupVersionAPI :

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

La mise à jour du groupe de nœuds respecte vos paramètres de mise à jour (maxUnavailableoumaxUnavailablePercentage) et votre stratégie de mise à jour (Rolling ou Force) configurés.

Self-managed nœuds et nœuds hybrides

Vous êtes responsable de la restauration des nœuds autogérés et des nœuds hybrides. Mettez à jour les AMI ou les configurations de votre nœud pour utiliser la version précédente de Kubernetes avant de restaurer le plan de contrôle.

Fargate

La restauration de version n'est pas prise en charge pour les nœuds de travail Fargate. Vous pouvez annuler le plan de contrôle d'un cluster qui utilise Fargate, mais les pods Fargate exécutant la même version de Kubernetes que le plan de contrôle déclenchent l'aperçu biaisé de la version de Kubelet avec le statut ERROR.

EKS ne peut pas restaurer automatiquement les pods Fargate vers une ancienne version de Kubelet.

Solution : si des pods Fargate exécutent la même version de Kubernetes que le plan de contrôle, supprimez ces pods avant de lancer la restauration. Réduisez ensuite votre plan de contrôle. Tous les pods restants sont lancés avec la version annulée lorsque vous les redéployez.

Vous pouvez également l'utiliser --force pour contourner la vérification des informations. Cependant, le fait de poursuivre une violation de distorsion de version de Kubelet peut entraîner un comportement inattendu de vos charges de travail Fargate jusqu'à ce que ces pods soient remplacés.

Étape 3 : annuler le plan de contrôle du cluster

Vous pouvez lancer une restauration à l'aide de la AWS console, de la AWS CLI ou de l'API EKS.

Cluster de restauration à l'aide du AWS Console

L'annulation prend plusieurs minutes. Pour les clusters en mode automatique, la phase de restauration des nœuds peut prendre plus de temps. Pour de plus amples informations, veuillez consulter Rétrograder les clusters en mode automatique EKS.

Cluster de restauration à l'aide du AWS INTERFACE DE LIGNE DE COMMANDE (CLI)

Utilisez la update-cluster-version commande existante avec la version précédente (N-1) de Kubernetes :

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

Exemple de réponse :

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

Étape 4 : suivre la progression de la restauration

Vous pouvez surveiller l'état de la restauration de votre cluster à l'aide de la console Amazon EKS ou de 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 :

Transitions de statut

Pour les clusters standard (sans mode automatique) :

InProgress → Successful
InProgress → Failed

Pour les clusters en mode automatique, l'état du cluster reste actif ACTIVE lorsque les nœuds sont en cours de restauration et ne change UPDATING qu'au début de la restauration du plan de contrôle. describe-updateÀ utiliser pour suivre la progression globale de l'annulation. Pour de plus amples informations, veuillez consulter Rétrograder les clusters en mode automatique EKS.

Lorsqu'un Successful statut est affiché, l'annulation est terminée.

Considérations et avertissements

Les informations sont le fruit du meilleur effort et à un moment précis

Les informations du cluster sont évaluées au moment où le rollback est déclenché. Si vous apportez des modifications à votre cluster après avoir vérifié les informations mais avant la fin de la restauration (par exemple, en créant des ressources à l'aide de nouvelles API), ces modifications ne sont pas prises en compte lors de la vérification initiale des informations et peuvent entraîner des problèmes une fois la restauration terminée.

conservation des données etcd

EKS préserve les données etcd pendant le rollback. Les ressources incompatibles contournées à l'aide de l'--forceindicateur restent persistantes et ne sont pas collectées.

Frais d'assistance étendus

Si vous revenez d'une version bénéficiant d'un support standard à une version bénéficiant d'un support étendu, votre cluster commence à encourir des frais de support étendu. Par exemple, si vous passez de la version 1.30 (support étendu) à la version 1.31 (support standard), puis que vous revenez à la version 1.30, les frais d'assistance prolongée reprennent.

Modèle de responsabilité partagée pour le rollback

EKS rétablit le plan de contrôle Kubernetes vers la version souhaitée. Dans le cadre du modèle de responsabilité partagée, vous êtes chargé de vérifier la compatibilité de l'application avec la version précédente :

CloudFormation comportement de restauration de la pile

Si une mise à jour de CloudFormation pile échoue et déclenche une annulation de pile, le retour à une version de modèle précédente qui spécifie une version inférieure de Kubernetes ne déclenche pas de restauration de version de cluster. La restauration de version doit être explicitement initiée via l' UpdateClusterVersion API, la CLI ou la console.

Annulation et modules complémentaires

EKS n'annule pas automatiquement les versions des modules complémentaires lors d'une restauration de version de cluster. Vous devez gérer les versions complémentaires séparément.

Avant de revenir en arrière sur le plan de contrôle :

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

+. Une fois la restauration du plan de contrôle terminée, vérifiez que tous les modules complémentaires fonctionnent correctement.

Ressources connexes