Migration d’EKS Fargate vers le mode automatique EKS - Amazon EKS
Comparaison entre le mode automatique d'Amazon EKS et EKS avec AWS FargateConditions préalablesÉ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Étape 4 : migrer progressivement les charges de travailÉtape 5 : supprimer le profil Fargate d’origineÉtape 6 : réduire verticalement CoreDNS

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 d'EKS prend également entièrement en charge toutes les options EC2 d'achat d'exécution, y compris les instances GPU et Spot, ce qui permet aux clients de bénéficier de EC2 remises négociées et d'autres mécanismes d'économie. Ces fonctionnalités ne sont pas disponibles lors de l'utilisation d'EKS avec Fargate.

En outre, le mode automatique d'EKS permet aux clients d'obtenir le même modèle d'isolation que Fargate, en utilisant les fonctionnalités de planification standard de Kubernetes pour garantir que EC2 chaque instance exécute un seul conteneur d'applications. 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 tout en conservant la facilité d'utilisation EC2 et l'abstraction de la gestion de l'infrastructure proposées par Fargate.

Conditions préalables

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

Étape 1 : vérifier le cluster Fargate

  1. Vérifiez si le cluster EKS avec Fargate est en cours d’exécution :

    kubectl get node
    NAME STATUS ROLES AGE VERSION
fargate-ip-192-168-92-52.ec2.internal Ready <none> 25m v1.30.8-eks-2d5f260
fargate-ip-192-168-98-196.ec2.internal Ready <none> 24m v1.30.8-eks-2d5f260

  2. Vérifiez les pods en cours d’exécution :

    kubectl get pod -A
    NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system coredns-6659cb98f6-gxpjz 1/1 Running 0 26m
kube-system coredns-6659cb98f6-gzzsx 1/1 Running 0 26m

  3. Créez un déploiement dans un fichier appelé deployment_fargate.yaml :

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
      annotations:
        eks.amazonaws.com/compute-type: fargate
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

  4. Appliquez le déploiement :

    kubectl apply -f deployment_fargate.yaml
    deployment.apps/nginx-deployment created

  5. Vérifiez les pods et les déploiements :

    kubectl get pod,deploy
    NAME                                    READY   STATUS    RESTARTS   AGE
pod/nginx-deployment-5c7479459b-6trtm   1/1     Running   0          61s
pod/nginx-deployment-5c7479459b-g8ssb   1/1     Running   0          61s
pod/nginx-deployment-5c7479459b-mq4mf   1/1     Running   0          61s

NAME                               READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/nginx-deployment   3/3     3            3           61s

  6. Vérifiez le nœud :

    kubectl get node -owide
    NAME                                    STATUS  ROLES  AGE VERSION             INTERNAL-IP     EXTERNAL-IP OS-IMAGE       KERNEL-VERSION                  CONTAINER-RUNTIME
fargate-ip-192-168-111-43.ec2.internal  Ready   <none> 31s v1.30.8-eks-2d5f260 192.168.111.43  <none>      Amazon Linux 2 5.10.234-225.910.amzn2.x86_64  containerd://1.7.25
fargate-ip-192-168-117-130.ec2.internal Ready   <none> 36s v1.30.8-eks-2d5f260 192.168.117.130 <none>      Amazon Linux 2 5.10.234-225.910.amzn2.x86_64  containerd://1.7.25
fargate-ip-192-168-74-140.ec2.internal  Ready   <none> 36s v1.30.8-eks-2d5f260 192.168.74.140  <none>      Amazon Linux 2 5.10.234-225.910.amzn2.x86_64  containerd://1.7.25

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

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

  2. Vérifiez le groupe de nœuds :

    kubectl get nodepool
    NAME              NODECLASS   NODES   READY   AGE
general-purpose   default     1       True    6m58s
system            default     0       True    3d14h

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

  1. Modifiez vos déploiements (par exemple le fichier deployment_fargate.yaml) afin de changer le type de calcul en ec2 :

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
      annotations:
        eks.amazonaws.com/compute-type: ec2
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

  2. Appliquez le déploiement. Cette modification permet de planifier la charge de travail sur les nouveaux nœuds du mode automatique EKS :

    kubectl apply -f deployment_fargate.yaml

  3. Vérifiez que le déploiement est en cours d’exécution dans le cluster du mode automatique EKS :

    kubectl get pod -o wide
    NAME                               READY   STATUS    RESTARTS   AGE     IP               NODE                  NOMINATED NODE   READINESS GATES
nginx-deployment-97967b68d-ffxxh   1/1     Running   0          3m31s   192.168.43.240   i-0845aafcb51630ffb   <none>           <none>
nginx-deployment-97967b68d-mbcgj   1/1     Running   0          2m37s   192.168.43.241   i-0845aafcb51630ffb   <none>           <none>
nginx-deployment-97967b68d-qpd8x   1/1     Running   0          2m35s   192.168.43.242   i-0845aafcb51630ffb   <none>           <none>

  4. Vérifiez qu’aucun nœud Fargate n’est en cours d’exécution et que le déploiement s’exécute sur les nœuds gérés en mode automatique EKS :

    kubectl get node -owide
    NAME                STATUS ROLES  AGE   VERSION             INTERNAL-IP     EXTERNAL-IP OS-IMAGE                                         KERNEL-VERSION CONTAINER-RUNTIME
i-0845aafcb51630ffb Ready  <none> 3m30s v1.30.8-eks-3c20087 192.168.41.125  3.81.118.95 Bottlerocket (EKS Auto) 2025.3.14 (aws-k8s-1.30) 6.1.129        containerd://1.7.25+bottlerocket

É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