

 **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
<a name="migrate-auto"></a>

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, veuillez consulter [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, veuillez consulter [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, veuillez consulter [Migration d’EKS Fargate vers le mode automatique EKS](auto-migrate-fargate.md).

 ** AWS ne prend pas en charge les migrations suivantes :** 
+ Migration de volumes depuis le contrôleur EBS CSI (à l'aide du module complémentaire Amazon EKS) vers le contrôleur EBS CSI en mode automatique EKS (géré par EKS Auto Mode). PVCs créés avec l'un ne peuvent pas être montés par l'autre, car ils utilisent deux approvisionneurs de volumes 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 le standard EBS CSI StorageClass (`ebs.csi.aws.com`) et EKS Auto EBS StorageClass CSI (). `ebs.csi.eks.amazonaws.com` Notez que la migration nécessite de supprimer et de recréer PersistentVolumeClaim/PersistentVolume des ressources existantes. La validation dans un environnement hors production est donc essentielle avant la mise en œuvre.
+ Migration des équilibreurs de charge du AWS Load Balancer Controller vers le mode automatique EKS

  Vous pouvez installer le AWS Load Balancer Controller sur un cluster Amazon EKS Auto Mode. Utilisez les options `IngressClass` ou `loadBalancerClass` pour associer les ressources de service et d’entrée au contrôleur d’équilibreur de charge ou au mode automatique EKS. Pour obtenir des conseils prescriptifs, reportez-vous à [https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migrate-nginx-ingress-controller-eks-auto-mode.html](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migrate-nginx-ingress-controller-eks-auto-mode.html) 
+ Migration de clusters EKS avec des configurations réseau alternatives CNIs ou non prises en charge

## Référence de migration
<a name="migration-reference"></a>

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
<a name="_migrating_ebs_volumes"></a>

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
<a name="_considerations"></a>
+ 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
<a name="_migrating_load_balancers"></a>

Vous ne pouvez pas transférer directement les équilibreurs de charge existants du contrôleur d'équilibrage de AWS charge 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é.