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 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 un cluster vers une version précédente de Kubernetes

Avec la restauration de la version d'Amazon EKS, vous pouvez rétablir la version mineure précédente du plan de contrôle Kubernetes de votre cluster 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 entre applications, une utilisation obsolète de l'API ou un comportement inattendu, vous pouvez revenir en arrière pour restaurer votre cluster à un état de fonctionnement connu.

Lors d'une restauration, Amazon EKS rétablit la version précédente du serveur 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é

Les composants suivants sont annulés :

Qu'est-ce qui n'est PAS annulé

Les composants suivants ne sont pas annulés :

Conditions préalables

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

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

Résumé

Voici le résumé de haut niveau du processus de restauration du cluster Amazon EKS :

Étape 1 : Passez en revue les informations relatives à la préparation à la restauration

Amazon EKS évalue automatiquement votre cluster par rapport à un ensemble de contrôles ponctuels de préparation à la restauration et détecte tout problème grâce à des informations sur les clusters classées dans cette 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é de 7 jours.

Affichage des informations sur la 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 informations détaillées sur un point de vue spécifique :

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

Des informations rafraîchissantes

Amazon EKS actualise les informations toutes les 24 heures. Vous pouvez déclencher manuellement une actualisation après avoir résolu les problèmes en cliquant sur le bouton Actualiser dans la console Amazon EKS ou en utilisant l'interface de ligne de commande :

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

Comportement relatif à l'état

Le tableau suivant décrit la signification de chaque statut d'aperçu et son effet sur la restauration :

Les informations dont le statut est ERROR ou INCONNU bloquent la restauration. Les informations dont le statut PASSE ou ALERTE ne vous empêchent pas de revenir en arrière.

Contrôles de préparation à la restauration

Amazon EKS effectue une série de vérifications dans le cadre des informations relatives à la préparation à la restauration. Ces contrôles évaluent la compatibilité d'utilisation de l'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 des modules complémentaires. Pour les clusters exécutant le mode EKS Auto, des contrôles supplémentaires évaluent les budgets d' NodePool interruption, les annotations à ne pas perturber et les configurations. PodDisruptionBudget

Utilisation de l'indicateur --force

Si les informations sur la préparation à la restauration affichent le statut ERROR et que vous souhaitez continuer sans résoudre les problèmes, vous pouvez utiliser l'--forceindicateur 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 contrôles d'informations. Il ne contourne pas les validations préalables telles que la fenêtre de 7 jours, la vérification de la version de création ou la vérification d'annulation séquentielle. Pour les clusters en mode automatique, --force n'annule pas les contrôles d'interruption. NodePool les budgets de perturbation, les PDB et les annotations « ne pas perturber » sont toujours respectés.

Étape 2 : Préparer les nœuds de travail

Avant d'annuler le plan de contrôle, assurez-vous que vos nœuds de travail sont compatibles avec la version cible. La politique d'asymétrie 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 la restauration, Amazon EKS annule automatiquement les nœuds en 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 les paramètres de mise à jour (maxUnavailableoumaxUnavailablePercentage) et la stratégie de mise à jour (Rolling ou Force) que vous avez 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 de la version de kubelet avec le statut ERROR.

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

Solution : si vos pods Fargate exécutent la même version de Kubernetes que le plan de contrôle, supprimez-les avant de lancer la restauration. Ensuite, annulez votre plan de contrôle. Tous les pods restants sont lancés avec la version restaurée lorsque vous les redéployez.

Vous pouvez également l'utiliser --force pour contourner le contrôle d'aperçu. Cependant, le fait de procéder à une violation de l'asymétrie de la version de Kubelet peut entraîner un comportement inattendu pour vos charges de travail Fargate jusqu'à ce que ces modules soient remplacés.

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

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

Annulez un cluster à l'aide de AWS Console

La restauration 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.

Annulez un cluster à l'aide de 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 : Surveiller 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 l' AWS interface de ligne de commande.

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 est conservé ACTIVE pendant l'annulation des nœuds et passe à UPDATING uniquement lorsque la restauration du plan de contrôle commence. Utilisez-le describe-update pour suivre la progression globale de la restauration. Pour de plus amples informations, veuillez consulter Rétrograder les clusters en mode automatique EKS.

Lorsqu'un Successful statut est affiché, la restauration est terminée.

Considérations et mises en garde

Les informations sont disponibles au meilleur moment et au meilleur moment

Les informations du cluster sont évaluées au moment où la restauration est déclenchée. Si vous apportez des modifications à votre cluster après vérification des informations, mais avant la fin de la restauration (par exemple, création de 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.

préservation des données etcd

Amazon EKS conserve les données etcd lors de la restauration. Les ressources incompatibles contournées à l'aide de l'--forceindicateur restent conservées et ne sont pas collectées à la poubelle.

Frais de support é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 à être soumis à 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 de support étendu reprendront.

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

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

CloudFormation comportement de restauration de la pile

Si une mise à jour de la CloudFormation pile AWS échoue et déclenche une restauration de la 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 la version du cluster. La restauration de version doit être explicitement initiée via l'UpdateClusterVersionAPI, l'interface de ligne de commande ou la console.

Annulation et modules complémentaires

Amazon EKS n'annule pas automatiquement les versions complémentaires lors de la restauration d'une 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 :

Ressources connexes