**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.
# Activer le mode automatique EKS sur les clusters EKS existants
Vous pouvez activer le mode automatique EKS sur les clusters EKS existants.
**AWS prend en charge les migrations suivantes :**
+ Migration de Karpenter vers les nœuds du mode automatique EKS. Pour de plus amples informations, consultez [Migration de Karpenter vers le mode automatique EKS à l’aide de kubectl](auto-migrate-karpenter.md).
+ Migration des groupes de nœuds gérés par EKS vers des nœuds du mode automatique EKS. Pour de plus amples informations, consultez [Migration des groupes de nœuds gérés EKS vers le mode automatique EKS](auto-migrate-mng.md).
+ Migration d’EKS Fargate vers le mode automatique EKS. Pour de plus amples informations, consultez [Migration d’EKS Fargate vers le mode automatique EKS](auto-migrate-fargate.md).
**AWS ne prend pas en charge les migrations suivantes :**
+ Migration des volumes du contrôleur CSI EBS (à l’aide du module complémentaire Amazon EKS) vers le contrôleur CSI EBS en mode automatique EKS (géré par le mode automatique EKS). Les PVC créés avec l’un ne peuvent pas être montés par l’autre, car ils utilisent deux provisionneurs de volume Kubernetes différents.
+ Le [https://github.com/awslabs/eks-auto-mode-ebs-migration-tool](https://github.com/awslabs/eks-auto-mode-ebs-migration-tool)(projet AWS Labs) permet la migration entre la norme EBS CSI StorageClass (`ebs.csi.aws.com`) et EKS Auto EBS CSI StorageClass (`ebs.csi.eks.amazonaws.com`). Notez que la migration nécessite la suppression et la recréation des ressources PersistentVolumeClaim/PersistentVolume existantes. Il est donc essentiel de procéder à une validation dans un environnement hors production avant la mise en œuvre.
+ Migration des équilibreurs de charge de l’AWS Load Balancer Controller vers le mode automatique EKS
Vous pouvez installer l’AWS Load Balancer Controller sur un cluster du mode automatique Amazon EKS. Utilisez les options `IngressClass` ou `loadBalancerClass` pour associer les ressources de service et d’entrée au Load Balancer Controller ou au mode automatique EKS.
+ Migration de clusters EKS avec des CNI alternatifs ou d’autres configurations réseau non prises en charge
## Référence de migration
Utilisez la référence de migration suivante pour configurer les ressources Kubernetes afin qu’elles appartiennent soit à des contrôleurs autogérés, soit au mode automatique EKS.
| Capacité | Ressource | Champ | Autogéré | Mode automatique EKS |
| --- | --- | --- | --- | --- |
| Stockage en mode bloc | `StorageClass` | `provisioner` | `ebs.csi.aws.com` | `ebs.csi.eks.amazonaws.com` |
| Équilibrage de charge | `Service` | `loadBalancerClass` | `service.k8s.aws/nlb` | `eks.amazonaws.com/nlb` |
| Équilibrage de charge | `IngressClass` | `controller` | `ingress.k8s.aws/alb` | `eks.amazonaws.com/alb` |
| Équilibrage de charge | `IngressClassParams` | `apiversion` | `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` |
| Équilibrage de charge | `TargetGroupBinding` | `apiversion` | `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` |
| Calcul | `NodeClass` | `apiVersion` | `karpenter.sh/v1` | `eks.amazonaws.com/v1` |
## Migration de volumes EBS
Lors de la migration des charges de travail vers le mode automatique EKS, vous devez gérer la migration des volumes EBS en raison des différents provisionneurs de pilotes CSI :
+ Provisionneur du mode automatique EKS : `ebs.csi.eks.amazonaws.com`
+ Provisionneur CSI EBS open source : `ebs.csi.aws.com`
Pour migrer vos volumes persistants, procédez comme suit :
1. **Modifier la politique de conservation des volumes** : modifier la version `persistentVolumeReclaimPolicy` existante de la plate-forme (PV) vers `Retain` afin de garantir que le volume EBS sous-jacent ne soit pas supprimé.
1. **Supprimer le PV de Kubernetes** : supprimez l’ancienne ressource PV tout en préservant le volume EBS réel.
1. **Créez un nouveau PV avec provisionnement statique** : créez un nouveau PV qui fait référence au même volume EBS mais fonctionne avec le pilote CSI cible.
1. **Liaison à un nouveau PVC** : créez un nouveau PVC qui fait spécifiquement référence à votre PV en utilisant le champ `volumeName`.
### Considérations
+ Assurez-vous que vos applications sont arrêtées avant de commencer cette migration.
+ Sauvegardez vos données avant de commencer le processus de migration.
+ Ce processus doit être effectué pour chaque volume persistant.
+ La charge de travail doit être mise à jour pour utiliser le nouveau PVC.
## Migration des équilibreurs de charge
Vous ne pouvez pas transférer directement les équilibreurs de charge existants de l’AWS Load Balancer Controller autogéré vers le mode automatique EKS. Vous devez plutôt mettre en œuvre une stratégie de déploiement bleu/vert. Cela implique de conserver votre configuration d’équilibreur de charge existante tout en créant de nouveaux répartiteurs de charge sous le contrôleur géré.
Afin de minimiser les perturbations du service, nous recommandons une approche de transfert du trafic basée sur le DNS. Commencez par créer de nouveaux équilibreurs de charge à l’aide du mode automatique EKS tout en conservant votre configuration existante opérationnelle. Ensuite, utilisez le routage DNS (tel que Route 53) pour transférer progressivement le trafic des anciens équilibreurs de charge vers les nouveaux. Une fois le trafic migré avec succès et la nouvelle configuration vérifiée, vous pouvez mettre hors service les anciens équilibreurs de charge et le contrôleur autogéré.
# Activation du mode automatique EKS sur un cluster existant
Cette rubrique explique comment activer le mode automatique EKS sur des clusters Amazon EKS déjà existants. L’activation du mode automatique sur un cluster existant nécessite la mise à jour des autorisations IAM et la configuration des paramètres essentiels du mode automatique EKS. Une fois activé, vous pouvez commencer à migrer vos charges de calcul existantes afin de profiter des opérations simplifiées et de la gestion automatisée de l’infrastructure offertes par le mode automatique.
**Important**
Avant d’activer le mode automatique EKS, vérifiez que vous disposez de la version minimale requise de certains modules complémentaires Amazon EKS. Pour de plus amples informations, veuillez consulter [Versions requises des modules complémentaires](#auto-addons-required).
Avant de commencer, assurez-vous également de disposer d’un accès administrateur à votre cluster Amazon EKS et des autorisations nécessaires pour modifier les rôles IAM. Les étapes décrites dans cette rubrique vous expliquent comment activer le mode automatique à l'aide de la AWS CLI AWS Management Console ou de la CLI.
## AWS Management Console
Vous devez être connecté à la AWS console avec l'autorisation de gérer IAM, EKS et les EC2 ressources.
**Note**
Le rôle IAM d’un cluster EKS ne peut pas être modifié après la création du cluster. Le mode automatique EKS nécessite des autorisations supplémentaires pour ce rôle. Vous devez donc attacher des politiques supplémentaires au rôle actuel.
### Mise à jour du rôle IAM du cluster
1. Ouvrez la page de présentation de votre cluster dans la AWS Management Console.
1. Sous **ARN du rôle IAM du cluster**, sélectionnez **Afficher dans IAM**.
1. Dans la liste déroulante **Ajouter des autorisations**, sélectionnez **Attacher des politiques**.
1. Dans la boîte **Recherche**, trouvez et sélectionnez les politiques suivantes :
+ `AmazonEKSComputePolicy`
+ `AmazonEKSBlockStoragePolicy`
+ `AmazonEKSLoadBalancingPolicy`
+ `AmazonEKSNetworkingPolicy`
+ `AmazonEKSClusterPolicy`
1. Sélectionnez **Ajouter des autorisations**
1. Dans l’onglet **Relations d’approbation**, sélectionnez **Modifier la politique d’approbation**
1. Insérez la politique d’approbation du rôle IAM du cluster suivante, puis sélectionnez **Mettre à jour la politique**
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
### Activation du mode automatique EKS
1. Ouvrez la page de présentation de votre cluster dans la AWS Management Console.
1. Sous **Mode automatique EKS**, sélectionnez **Gérer**
1. Activez l’option **Mode automatique EKS**.
1. Dans le menu déroulant **Groupe de nœuds EKS**, sélectionnez les groupes de nœuds par défaut que vous souhaitez créer.
+ Pour plus d’informations, consultez la section sur les groupes de nœuds en mode automatique EKS. Pour de plus amples informations, veuillez consulter [Create a Node Pool for EKS Auto Mode](create-node-pool.md).
1. Si vous avez déjà créé un rôle IAM de nœud en mode automatique EKS sur ce AWS compte, sélectionnez-le dans le menu déroulant **Rôle de nœud IAM**. Si vous n’avez pas encore créé ce rôle, sélectionnez **Créer le rôle recommandé** et suivez les étapes indiquées.
## AWS CLI
### Conditions préalables
+ Le rôle IAM du cluster EKS existant doit inclure les autorisations suffisantes pour le mode automatique EKS, notamment les politiques suivantes :
+ `AmazonEKSComputePolicy`
+ `AmazonEKSBlockStoragePolicy`
+ `AmazonEKSLoadBalancingPolicy`
+ `AmazonEKSNetworkingPolicy`
+ `AmazonEKSClusterPolicy`
+ Le rôle IAM du cluster doit également comporter une politique d’approbation mise à jour incluant l’action `sts:TagSession`. Pour plus d’informations sur la création d’un rôle IAM de cluster, consultez [Création d'un cluster en mode automatique EKS à l'aide de la AWS CLI](automode-get-started-cli.md).
+ Assurez-vous que la CLI `aws` est installée, connectée et à jour. Vous devez être autorisé à gérer IAM, EKS et les EC2 ressources. Pour de plus amples informations, veuillez consulter [Configuration pour utiliser Amazon EKS](setting-up.md).
### Procédure
Utilisez les commandes suivantes pour activer le mode automatique EKS sur un cluster existant.
**Note**
Les capacités de calcul, de stockage bloc et d’équilibrage de charge doivent toutes être activées ou désactivées dans la même requête.
```
aws eks update-cluster-config \
--name $CLUSTER_NAME \
--compute-config enabled=true \
--kubernetes-network-config '{"elasticLoadBalancing":{"enabled": true}}' \
--storage-config '{"blockStorage":{"enabled": true}}'
```
## Versions requises des modules complémentaires
Si vous prévoyez d’activer le mode automatique EKS sur un cluster existant, il peut être nécessaire de mettre à jour certains modules complémentaires. Remarques :
+ Cela s’applique uniquement aux clusters existants en cours de transition vers le mode automatique EKS.
+ Les nouveaux clusters créés avec le mode automatique EKS déjà activé n’ont pas besoin de ces mises à jour.
Si l’un des modules complémentaires suivants est installé, assurez-vous qu’il possède au moins la version minimale spécifiée :
| Nom du module complémentaire | Version minimale requise |
| --- | --- |
| Plug-in CNI Amazon VPC pour Kubernetes | v1.19.0-eksbuild.1 |
| Kube-proxy | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/auto-enable-existing.html) |
| Pilote CSI Amazon EBS | v1.37.0-eksbuild.1 |
| Contrôleur d'instantané CSI | v8.1.0-eksbuild.2 |
| Agent d'identité du pod EKS | v1.3.4-eksbuild.1 |
Pour de plus amples informations, veuillez consulter [Mettre à jour un module complémentaire Amazon EKS](updating-an-add-on.md).
## Étapes suivantes
+ Pour migrer les charges de travail de gestion des groupes de nœuds, consultez [Migration des groupes de nœuds gérés EKS vers le mode automatique EKS](auto-migrate-mng.md).
+ Pour migrer depuis Karpenter autogéré, consultez [Migration de Karpenter vers le mode automatique EKS à l’aide de kubectl](auto-migrate-karpenter.md).
# 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 :
+ Karpenter v1.1 ou une version ultérieure installée sur votre cluster. Pour plus d’informations, consultez [Mise à niveau vers la version 1.1.0\$1](https://karpenter.sh/docs/upgrading/upgrade-guide/#upgrading-to-110) dans la documentation Karpenter.
+ `kubectl` installé et connecté à votre cluster. Pour de plus amples informations, veuillez consulter [Configuration pour utiliser Amazon EKS](setting-up.md).
Cette rubrique suppose que vous connaissez Karpenter et NodePools. Pour plus d’informations, consultez la [Documentation Karpenter](https://karpenter.sh/).
## É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](auto-enable-existing.md).
**Note**
Lors de l’activation du mode automatique EKS, n’activez pas le groupe de nœuds `general purpose` à ce stade de la transition. Ce groupe de nœuds n’est pas sélectif.
Pour de plus amples informations, veuillez consulter [Activer ou désactiver la fonction intégrée NodePools](set-builtin-node-pools.md).
## É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](create-node-class.md).
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 par`eks.amazonaws.com`. Pour de plus amples informations, veuillez consulter [Create a Node Pool for EKS Auto Mode](create-node-pool.md).
## É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
```
## É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](https://karpenter.sh/docs/getting-started/getting-started-with-karpenter/#create-a-cluster-and-add-karpenter).
# Migration des groupes de nœuds gérés EKS vers le mode automatique EKS
Lors de la transition de votre cluster Amazon EKS vers le mode automatique EKS, vous pouvez migrer en douceur vos charges de travail existantes à partir des groupes de nœuds gérés (Managed Node Groups, MNG) à l’aide de l’outil CLI eksctl. Ce processus garantit la disponibilité continue des applications, tout en permettant au mode automatique EKS d’optimiser vos ressources de calcul. La migration peut être effectuée avec un minimum d’interruptions pour vos applications en cours d’exécution.
Cette rubrique présente les étapes à suivre pour évacuer en toute sécurité les pods de vos groupes de nœuds gérés existants et permettre au mode automatique EKS de les replanifier automatiquement sur de nouvelles instances provisionnées. En suivant cette procédure, vous pourrez tirer parti de la consolidation intelligente des charges de travail en mode automatique EKS, tout en préservant la disponibilité de vos applications pendant toute la durée de la migration.
## Prérequis
+ Cluster avec le mode automatique EKS activé
+ CLI `eksctl` installée et connectée à votre cluster. Pour de plus amples informations, consultez [Configuration pour utiliser Amazon EKS](setting-up.md).
+ Karpenter non installé sur le cluster.
## Procédure
Utilisez la commande CLI `eksctl` suivante pour commencer à évacuer les pods des instances de groupes de nœuds gérés existants. Le mode automatique EKS créera automatiquement de nouveaux nœuds pour héberger les pods déplacés.
```
eksctl delete nodegroup --cluster= --name=
```
Vous devrez exécuter cette commande pour chaque groupe de nœuds géré de votre cluster.
Pour plus d’informations sur cette commande, consultez [Suppression et évacuation des groupes de nœuds](https://eksctl.io/usage/nodegroups/#deleting-and-draining-nodegroups) dans la documentation eksctl.
# 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
```