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 d’EKS Fargate vers le mode automatique EKS

Cette rubrique décrit en détail le processus de migration des charges de travail d’EKS Fargate 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 EKS Fargate et EKS Auto Mode 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 sous le mode automatique EKS avant de désactiver complètement EKS Fargate. 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.

Comparaison entre le mode automatique d'Amazon EKS et EKS avec AWS Fargate

Amazon EKS with AWS Fargate reste une option pour les clients qui souhaitent exécuter EKS, mais le mode automatique Amazon EKS est l'approche recommandée pour l'avenir. Le mode automatique EKS est entièrement conforme à Kubernetes, et prend en charge tous les éléments natifs de Kubernetes ainsi que les outils de plateforme tels qu’Istio, que Fargate ne prend pas en charge. Le mode automatique EKS prend également en charge toutes les options d’exécution EC2, y compris les instances GPU et Spot, permettant ainsi aux clients de bénéficier des remises EC2 négociées et d’autres mécanismes d’optimisation des coûts. Ces fonctionnalités ne sont pas disponibles avec EKS associé à Fargate.

De plus, le mode automatique EKS permet d’obtenir le même modèle d’isolation que Fargate, en utilisant les capacités natives de planification de Kubernetes pour garantir que chaque instance EC2 exécute un seul conteneur d’application. En adoptant le mode automatique d'Amazon EKS, les clients peuvent profiter de tous les avantages liés à l'exécution de Kubernetes sur AWS une plateforme entièrement conforme à Kubernetes qui offre la flexibilité nécessaire pour tirer parti de l'ensemble des options d'achat et d'EC2 tout en conservant la facilité d'utilisation et l'abstraction de la gestion de l'infrastructure proposées par Fargate.

Obtenir une isolation semblable à celle de Fargate en mode automatique EKS

Pour répliquer le modèle d'isolation des pods de Fargate dans lequel chaque pod s'exécute sur sa propre instance dédiée, vous pouvez utiliser les contraintes de propagation de la topologie Kubernetes. Voici l'approche recommandée pour contrôler la distribution des pods entre les nœuds :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: isolated-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: isolated-app
  template:
    metadata:
      labels:
        app: isolated-app
      annotations:
        eks.amazonaws.com/compute-type: ec2
    spec:
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: kubernetes.io/hostname
        whenUnsatisfiable: DoNotSchedule
        labelSelector:
          matchLabels:
            app: isolated-app
        minDomains: 1
      containers:
      - name: app
        image: nginx
        ports:
        - containerPort: 80

Dans cette configuration :

Le mode automatique d'EKS provisionne automatiquement les nouvelles instances EC2 selon les besoins pour satisfaire cette contrainte, en fournissant le même modèle d'isolation que Fargate tout en vous donnant accès à la gamme complète des types d'instances EC2 et des options d'achat.

Vous pouvez également utiliser les règles d'anti-affinité des pods pour une isolation plus stricte :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: isolated-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: isolated-app
  template:
    metadata:
      labels:
        app: isolated-app
      annotations:
        eks.amazonaws.com/compute-type: ec2
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - isolated-app
            topologyKey: kubernetes.io/hostname
      containers:
      - name: app
        image: nginx
        ports:
        - containerPort: 80

La podAntiAffinity règle requiredDuringSchedulingIgnoredDuringExecution garantit qu'aucun module portant l'étiquette ne app: isolated-app peut être planifié sur le même nœud. Cette approche fournit des garanties d'isolation strictes similaires à celles de Fargate.

Conditions préalables

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

Étape 1 : vérifier le cluster Fargate

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

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

Pour migrer une charge de travail de Fargate vers le mode automatique EKS, appliquez l’annotation eks.amazonaws.com/compute-type: ec2. Cela garantit que la charge de travail ne sera pas planifiée par Fargate, malgré le profil Fargate, et qu'elle sera absorbée par le mode automatique EKS. NodePool 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 : supprimer le profil Fargate d’origine

Une fois que toutes les charges de travail ont été migrées, vous pouvez supprimer le profil fargate d’origine. Remplacez <fargate profile name> par le nom de votre profil Fargate :

aws eks delete-fargate-profile --cluster-name eks-fargate-demo-cluster --fargate-profile-name <fargate profile name>

Étape 6 : réduire verticalement CoreDNS

Comme le mode automatique EKS prend en charge CoreDNS, vous devez réduire le déploiement coredns à 0 :

kubectl scale deployment coredns -n kube-system —-replicas=0