**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 :
+ `maxSkew: 1`garantit que la différence de nombre de pods entre deux nœuds est d'au plus 1, en répartissant efficacement un pod par nœud
+ `topologyKey: kubernetes.io/hostname`définit le nœud en tant que domaine topologique
+ `whenUnsatisfiable: DoNotSchedule`empêche la planification si la contrainte ne peut pas être respectée
+ `minDomains: 1`s'assure qu'au moins un domaine (nœud) existe avant la planification
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
+ Mis en place un cluster avec Fargate. Pour de plus amples informations, veuillez consulter [Commencez à utiliser AWS Fargate pour votre cluster](fargate-getting-started.md).
+ Installé et connecté `kubectl` à votre cluster. Pour de plus amples informations, veuillez consulter [Configuration pour utiliser Amazon EKS](setting-up.md).
## É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 25m v1.30.8-eks-2d5f260
fargate-ip-192-168-98-196.ec2.internal Ready 24m v1.30.8-eks-2d5f260
```
1. 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
```
1. 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
```
1. Appliquez le déploiement :
```
kubectl apply -f deployment_fargate.yaml
```
```
deployment.apps/nginx-deployment created
```
1. 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
```
1. 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 31s v1.30.8-eks-2d5f260 192.168.111.43 Amazon Linux 2 5.10.234-225.910.amzn2.x86_64 containerd://1.7.25
fargate-ip-192-168-117-130.ec2.internal Ready 36s v1.30.8-eks-2d5f260 192.168.117.130 Amazon Linux 2 5.10.234-225.910.amzn2.x86_64 containerd://1.7.25
fargate-ip-192-168-74-140.ec2.internal Ready 36s v1.30.8-eks-2d5f260 192.168.74.140 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](auto-enable-existing.md).
1. 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](create-node-pool.md).
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
```
1. 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
```
1. 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
nginx-deployment-97967b68d-mbcgj 1/1 Running 0 2m37s 192.168.43.241 i-0845aafcb51630ffb
nginx-deployment-97967b68d-qpd8x 1/1 Running 0 2m35s 192.168.43.242 i-0845aafcb51630ffb
```
1. 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 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 ** par le nom de votre profil Fargate :
```
aws eks delete-fargate-profile --cluster-name eks-fargate-demo-cluster --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
```