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.

Migration de Karpenter vers le mode automatique EKS à l’aide de kubectl

Cette rubrique décrit en détail le processus de migration des charges de travail de Karpenter vers le mode automatique Amazon EKS à l’aide de kubectl. La migration peut être effectuée progressivement, vous permettant de transférer les charges de travail à votre propre rythme, tout en préservant la stabilité du cluster et la disponibilité des applications pendant toute la transition.

L' step-by-stepapproche décrite ci-dessous vous permet d'exécuter Karpenter et le mode automatique d'EKS côte à côte pendant la période de migration. Cette stratégie de double exploitation garantit une transition fluide, car elle vous permet de valider le comportement des charges de travail en mode automatique EKS avant de désactiver complètement Karpenter. Vous pouvez migrer les applications individuellement ou par groupes, ce qui offre une flexibilité accrue pour répondre à vos exigences opérationnelles spécifiques et à votre tolérance au risque.

Conditions préalables

Avant de commencer la migration, assurez-vous d’avoir :

Cette rubrique suppose que vous connaissez Karpenter et NodePools. Pour plus d’informations, consultez la Documentation Karpenter.

Étape 1 : activer le mode automatique EKS sur le cluster

Activez le mode automatique EKS sur votre cluster existant à l'aide de la AWS CLI ou de la console de gestion. Pour de plus amples informations, veuillez consulter Activation du mode automatique EKS sur un cluster existant.

Étape 2 : Création d'un mode automatique EKS altéré NodePool

Créez un nouveau mode automatique NodePool pour EKS avec une teinte. Cela garantit que les pods existants ne seront pas automatiquement planifiés sur les nouveaux nœuds du mode automatique EKS. Ce groupe de nœuds utilise la NodeClass default intégrée au mode automatique EKS. Pour de plus amples informations, veuillez consulter Création d’une classe de nœuds pour Amazon EKS.

Exemple de groupe de nœuds avec balise de rejet :

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: eks-auto-mode
spec:
  template:
    spec:
      requirements:
        - key: "eks.amazonaws.com/instance-category"
          operator: In
          values: ["c", "m", "r"]
      nodeClassRef:
        group: eks.amazonaws.com
        kind: NodeClass
        name: default
      taints:
        - key: "eks-auto-mode"
          effect: "NoSchedule"

Mettez à jour les exigences du groupe de nœuds afin qu’elles correspondent à la configuration Karpenter d’origine à partir de laquelle vous effectuez la migration. Vous devez définir au moins une exigence.

Étape 3 : mettre à jour les charges de travail pour la migration

Identifiez et mettez à jour les charges de travail que vous souhaitez migrer vers le mode automatique EKS. Ajoutez des tolérances et des sélecteurs de nœuds à ces charges de travail :

apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      tolerations:
      - key: "eks-auto-mode"
        effect: "NoSchedule"
      nodeSelector:
        eks.amazonaws.com/compute-type: auto

Cette modification permet de planifier la charge de travail sur les nouveaux nœuds du mode automatique EKS.

Le mode automatique EKS utilise des étiquettes différentes de celles de Karpenter. Les étiquettes associées aux instances EC2 gérées commencent pareks.amazonaws.com. Pour de plus amples informations, veuillez consulter Create a Node Pool for EKS Auto Mode.

Étape 4 : migrer progressivement les charges de travail

Répétez l’étape 3 pour chaque charge de travail que vous souhaitez migrer. Cette méthode vous permet de déplacer les charges de travail individuellement ou par groupes, selon vos besoins et votre tolérance au risque.

Étape 5 : Retirez le Karpenter d'origine NodePool

Une fois que toutes les charges de travail ont été migrées, vous pouvez supprimer le Karpenter d'origine : NodePool

kubectl delete nodepool <original-nodepool-name>

Étape 6 : Supprimer les taches du mode automatique EKS NodePool (facultatif)

Si vous souhaitez que le mode automatique EKS devienne le mode par défaut pour les nouvelles charges de travail, vous pouvez supprimer les traces du mode automatique EKS : NodePool

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: eks-auto-mode
spec:
  template:
    spec:
      nodeClassRef:
        group: eks.amazonaws.com
        kind: NodeClass
        name: default
      # Remove the taints section

Étape 7 : supprimer les sélecteurs de nœuds des charges de travail (facultatif)

Si vous avez supprimé l'altération du mode automatique EKS NodePool, vous pouvez éventuellement supprimer les sélecteurs de nœuds de vos charges de travail, le mode automatique EKS étant désormais le mode par défaut :

apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      # Remove the nodeSelector section
      tolerations:
      - key: "eks-auto-mode"
        effect: "NoSchedule"

Étape 8 : désinstaller Karpenter de votre cluster

Les étapes de suppression de Karpenter dépendent de la méthode d’installation que vous avez utilisée. Pour plus d’informations, consultez les Instructions d’installation de Karpenter.