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.

Rétrograder les clusters en mode automatique EKS

Lorsque vous lancez une restauration de version sur un cluster exécutant le mode automatique EKS, Amazon EKS gère automatiquement la restauration des nœuds de travail en mode automatique avant de revenir au plan de contrôle. Cette page explique comment fonctionne la restauration des nœuds en mode automatique, comment l'accélérer et comment l'annuler si nécessaire.

Pour obtenir des informations générales sur la restauration des versions, notamment les conditions requises, les vérifications analytiques et le processus de restauration global, consultez. Restaurer le cluster à la version précédente de Kubernetes

Comment fonctionne le rollback en mode automatique

Le mode automatique d'EKS utilise un Karpenter-based système pour gérer l'infrastructure des nœuds de travail, y compris les mises à niveau et les annulations des versions de Kubernetes. Lorsque vous appelez UpdateClusterVersion avec la version précédente (N-1) sur un cluster dont le mode automatique est activé, EKS exécute la séquence suivante :

Le plan de contrôle reste sur la version actuelle (la plus récente) et continue de traiter le trafic normalement pendant que les nœuds sont en train de revenir en arrière. La politique de distorsion des versions de Kubernetes permet aux nœuds d'exécuter jusqu'à trois versions mineures antérieures au serveur kube-apiserver. Cet état intermédiaire est donc valide.

État du cluster lors de la restauration

L'état du cluster est conservé ACTIVE pendant la phase de restauration du nœud. Utilisez ListUpdates ou DescribeUpdate pour déterminer si une annulation est en cours. Dans la console Amazon EKS, accédez à votre cluster et ouvrez l'onglet Historique des mises à jour pour consulter l'état de l'ID de mise à jour associé à l'annulation.

Pour suivre la progression de chaque nœud lors de la restauration, vérifiez la version Kubernetes de vos nœuds en mode automatique :

kubectl get nodes -l karpenter.sh/nodepool=<nodepool-name> -o wide

Contrôles des perturbations

La restauration en mode automatique respecte tous les contrôles d'interruption existants. Ces contrôles déterminent la rapidité avec laquelle les nœuds peuvent être remplacés et peuvent affecter de manière significative la durée du rollback.

NodePool Budgets liés aux perturbations

NodePool les budgets d'interruption contrôlent le nombre de nœuds pouvant être perturbés simultanément. Lors de la restauration, Karpenter respecte ces budgets lorsqu'il déplace des nœuds vers la version précédente.

Exemple NodePool d'un budget d'interruption qui permet de remplacer 10 % des nœuds à la fois :

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  disruption:
    budgets:
      - nodes: "10%"
        reasons:
          - Drifted

Pour plus d'informations sur la configuration des budgets d' NodePool interruption, voir Créer un pool de nœuds pour le mode automatique EKS et les budgets d'interruption Karpenter.

PodDisruptionBudgets

Les Kubernetes PodDisruptionBudgets sont honorés lors du remplacement des nœuds. Si un PDB empêche l'expulsion du pod, la perturbation du nœud est retardée jusqu'au. TerminationGracePeriod

Pour plus d'informations, consultez Protéger les charges de travail critiques avec un PDB et la documentation Kubernetes PDB.

Do-not-disrupt annotations

L'karpenter.sh/do-not-disruptannotation peut être définie sur des nœuds ou des pods :

Sur les nœuds : bloque indéfiniment les perturbations des nœuds. Cela déclenche un message d'erreur et doit être supprimé avant que la restauration ne puisse se poursuivre sur ce nœud.

Sur les pods : retarde la perturbation des nœuds jusqu'à TerminationGracePeriod. Cela déclenche un avertissement mais ne bloque pas définitivement le rollback.

Pour plus d'informations sur le comportement de Karpenter en cas d'interruption, consultez la documentation relative aux perturbations de Karpenter.

Accélération de la rétrogradation

Si la restauration prend plus de temps que prévu, vous pouvez ajuster les contrôles d'interruption pendant que la restauration est en cours.

Augmentez les budgets consacrés aux NodePool perturbations

Modifiez la NodePool ressource pour autoriser davantage de remplacements de nœuds simultanés :

kubectl edit nodepool default

Modifiez le budget à une valeur plus élevée :

spec:
  disruption:
    budgets:
      - nodes: "50%"
        reasons:
          - Drifted

Supprimer les annotations « Ne pas perturber » des nœuds

Répertoriez les nœuds contenant l'annotation et supprimez-la :

# List nodes with the annotation
kubectl get nodes -o json | jq '.items[] | select(.metadata.annotations["karpenter.sh/do-not-disrupt"] == "true") | .metadata.name'

# Remove from a specific node
kubectl annotate node <node-name> karpenter.sh/do-not-disrupt-

Ajuster PodDisruptionBudgets

Si les PDB ralentissent l'expulsion des pods, ajustez-les temporairement :

kubectl edit pdb <pdb-name> -n <namespace>

Pour plus d'informations sur la gestion des contrôles des interruptions, consultez Prévention de la perturbation des pods et des nœuds en mode automatique Amazon EKS.

Annulation d'un rollback

Un rollback n'est annulable que lorsque les nœuds sont en cours de restauration. Vous pouvez l'utiliser CancelUpdate pendant cette phase pour arrêter l'opération.

aws eks cancel-update \
  --name my-cluster \
  --update-id <update-id> \
  --region us-west-2

Annuler le comportement

Après annulation

En cas d'annulation réussie, les nœuds dérivent vers la version actuelle du cluster, comme d'habitude. La mise à jour passe de Cancelling àCancelled.

Après l'annulation, vous pouvez immédiatement :

Quand l'annulation n'est pas possible

L'annulation échoue si la restauration du nœud est déjà terminée et que la restauration du plan de contrôle a commencé, ou si la mise à jour est déjà terminée avec le statut Successful ou Failed le statut.

Expiration du délai d'annulation

La restauration des nœuds en mode automatique a un délai d'expiration configurable contrôlé par le timeoutMinutes paramètre in. rollbackConfig Le délai d'expiration par défaut est de 720 minutes (12 heures). Vous pouvez définir une valeur comprise entre 120 minutes (2 heures) et 10080 minutes (7 jours). Le délai d'expiration est une propriété limitée au minimum, ce qui signifie qu'il se produit au plus tôt à l'heure que vous spécifiez, mais qu'il peut survenir peu de temps après.

aws eks update-cluster-version \
  --name my-cluster \
  --kubernetes-version 1.30 \
  --rollback-config timeoutMinutes=1440 \
  --region us-west-2

Si tous les nœuds n'ont pas terminé la restauration dans le délai spécifié :

Après un certain délai, vous pouvez réessayer la rétrogradation si vous êtes toujours dans le délai d'éligibilité de 7 jours à compter de la mise à niveau initiale. En pratique, si la restauration du nœud expire au jour 7, la période d'éligibilité à la restauration a probablement également expiré, car les deux sont de 7 jours.

Pour éviter les délais impartis, consultez les informations relatives à l'état de préparation à l'annulation avant de lancer la restauration. Ces informations mettent en garde contre les budgets d'interruption ou les annotations susceptibles de ralentir le processus de restauration des nœuds.

L'indicateur --force et le mode automatique

L'--forceindicateur activé contourne UpdateClusterVersion uniquement les vérifications d'informations sur le cluster. Cela n'a aucun effet sur le comportement d'interruption des nœuds en mode automatique.

Même avec --force :

Le seul moyen d'accélérer la restauration des nœuds est d'ajuster les contrôles des perturbations eux-mêmes. Consultez Accélération de la rétrogradation pour plus de détails.

Conflits de temporisation IaC

Infrastructure-as-Code les outils ont des limites de délai qui peuvent entrer en conflit avec la durée de restauration en mode automatique. CloudFormation autorise jusqu'à 36 heures par ressource. Si l'opération expire, CloudFormation traitez-la comme une opération non opérationnelle, ce qui peut laisser le cluster dans un état de dérive où le modèle ne reflète pas la version réelle du cluster. La restauration de version doit être explicitement initiée. Terraform Enterprise/Cloud a un délai d'expiration d'environ 24 heures, bien que les délais côté client puissent varier en fonction de l'expiration des informations d'identification et d'autres facteurs.

Pour aligner la durée de l'annulation sur celle de votre outil iAC, utilisez le timeoutMinutes paramètre in rollbackConfig pour définir un délai d'expiration approprié. Si le délai d'expiration de votre outil IaC est dépassé, utilisez directement l' CancelUpdate API pour reprendre le contrôle. Si vos budgets d'interruption sont restreints, envisagez de lancer la restauration directement par le biais de la CLI ou de l'API au lieu d'IaC.

Mises à jour du système lors de la restauration des nœuds

Pendant que les nœuds du mode automatique sont en train de revenir en arrière, EKS continue de garantir la sécurité et la disponibilité du plan de contrôle.

Customer-triggered les mises à jour (telles que UpdateClusterVersion ou UpdateClusterConfig) sont bloquées pendant que la restauration du nœud est en cours. Si vous devez effectuer une mise à jour prioritaire, annulez d'abord l'annulation en utilisantCancelUpdate, puis effectuez votre mise à jour, puis relancez la restauration si la fenêtre d'éligibilité est toujours en cours.

Ressources connexes