**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.
# Migrer des applications vers un nouveau groupe de nœuds
Cette rubrique vous explique comment créer un groupe de nœuds, migrer avec élégance vos applications existantes vers ce nouveau groupe, puis supprimer l'ancien groupe de nœuds de votre cluster. Vous pouvez migrer vers un nouveau groupe de nœuds à l'aide de`eksctl` ou de AWS Management Console.
+ [`eksctl`](#eksctl_migrate_apps)
+ [AWS Management Console et AWS CLI](#console_migrate_apps)
## `eksctl`
**Pour migrer vos applications vers un nouveau groupe de nœuds avec `eksctl`**
Pour plus d’informations sur l’utilisation d’eksctl pour la migration, consultez la section [Nœuds non gérés](https://eksctl.io/usage/nodegroup-unmanaged/) dans la documentation `eksctl`.
Cette procédure nécessite `eksctl` version `0.215.0` ou ultérieure. Vous pouvez vérifier votre version avec la commande suivante :
```
eksctl version
```
Pour les instructions d'installation ou de mise à niveau de `eksctl`, consultez la rubrique [Installation](https://eksctl.io/installation) dans la documentation `eksctl`.
**Note**
Cette procédure fonctionne uniquement pour les clusters et les groupes de nœuds créés avec `eksctl`.
1. Récupérez le nom de vos groupes de nœuds existants, en remplaçant *my-cluster* par le nom de votre cluster.
```
eksctl get nodegroups --cluster=my-cluster
```
L'exemple qui suit illustre un résultat.
```
CLUSTER NODEGROUP CREATED MIN SIZE MAX SIZE DESIRED CAPACITY INSTANCE TYPE IMAGE ID
default standard-nodes 2019-05-01T22:26:58Z 1 4 3 t3.medium ami-05a71d034119ffc12
```
1. Lancez un nouveau groupe de nœuds avec `eksctl` à l'aide de la commande suivante. Dans la commande, remplacez chaque *example value* par vos propres valeurs. Le numéro de version ne peut pas être postérieur à la version Kubernetes pour votre plan de contrôle. De même, il ne peut pas être antérieur de plus de deux versions mineures à la version Kubernetes de votre plan de contrôle. Nous vous recommandons d'utiliser la même version que votre plan de contrôle.
Nous recommandons de bloquer l’accès des pods à IMDS si les conditions suivantes sont remplies :
+ Vous prévoyez d’attribuer des rôles IAM à tous vos comptes de service Kubernetes, afin que les pods ne disposent que des permissions strictement nécessaires.
+ Aucun pod du cluster n'a besoin d'accéder au service de métadonnées d'instance Amazon EC2 (IMDS) pour d'autres raisons, telles que la récupération de la région actuelle. AWS
Pour plus d'informations, consultez [Restreindre l'accès au profil d'instance affecté au composant master](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node).
Pour bloquer l’accès des pods à IMDS, ajoutez l’option `--disable-pod-imds` à la commande suivante.
**Note**
Pour plus d'indicateurs disponibles et leurs descriptions, consultez https://eksctl.io/.
```
eksctl create nodegroup \
--cluster my-cluster \
--version 1.35 \
--name standard-nodes-new \
--node-type t3.medium \
--nodes 3 \
--nodes-min 1 \
--nodes-max 4 \
--managed=false
```
1. Lorsque la commande précédente se termine, vérifiez que tous vos nœuds ont atteint l'état `Ready` à l'aide de la commande suivante :
```
kubectl get nodes
```
1. Supprimez le groupe de nœuds d'origine avec la commande suivante. Dans la commande, remplacez chaque *example value* par les noms de votre cluster et de votre groupe de nœuds :
```
eksctl delete nodegroup --cluster my-cluster --name standard-nodes-old
```
## AWS Management Console et AWS CLI
**Migrez vos applications vers un nouveau groupe de nœuds à l'aide de la AWS CLI AWS Management Console et**
1. Lancez un nouveau groupe de nœuds en suivant les étapes décrites dans [Créer des nœuds Amazon Linux autogérés](launch-workers.md).
1. Lorsque la création de votre pile est terminée, sélectionnez la pile dans la console et choisissez **Outputs** (Sorties).
1. Enregistrez le **NodeInstanceRole**pour le groupe de nœuds créé. Vous en aurez besoin pour ajouter les nouveaux nœuds Amazon EKS à votre cluster.
**Note**
Si vous avez attachés des stratégies IAM supplémentaires au rôle IAM de votre ancien groupe de nœuds, attachez ces mêmes stratégies au rôle IAM de votre nouveau groupe de nœuds pour maintenir cette fonctionnalité sur le nouveau groupe. Cela s'applique si vous avez ajouté des autorisations pour le Kubernetes [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler), par exemple.
1. Mettez à jour les groupes de sécurité pour les deux groupes de nœuds afin qu'ils puissent communiquer entre eux. Pour de plus amples informations, veuillez consulter [Voir les exigences relatives aux groupes de sécurité Amazon EKS pour les clusters](sec-group-reqs.md).
1. Enregistrez le groupe de sécurité IDs pour les deux groupes de nœuds. Ceci est affiché sous forme de **NodeSecurityGroup**valeur dans les sorties de la AWS CloudFormation pile.
Vous pouvez utiliser les commandes AWS CLI suivantes pour obtenir le groupe IDs de sécurité à partir des noms de pile. Dans ces commandes, `oldNodes` il s'agit du nom de la AWS CloudFormation pile de votre ancienne pile de nœuds et `newNodes` du nom de la pile vers laquelle vous effectuez la migration. Remplacez chaque *example value* par vos propres valeurs.
```
oldNodes="old_node_CFN_stack_name"
newNodes="new_node_CFN_stack_name"
oldSecGroup=$(aws cloudformation describe-stack-resources --stack-name $oldNodes \
--query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \
--output text)
newSecGroup=$(aws cloudformation describe-stack-resources --stack-name $newNodes \
--query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \
--output text)
```
1. Ajoutez des règles d'entrée pour chaque groupe de sécurité des nœuds afin d'accepter le trafic de l'autre.
Les commandes AWS CLI suivantes ajoutent des règles entrantes à chaque groupe de sécurité qui autorisent tout le trafic sur tous les protocoles en provenance de l'autre groupe de sécurité. Cette configuration permet aux pods au sein de chaque groupe de nœuds peuvent ainsi communiquer entre eux pendant que vous migrez la charge de travail vers le nouveau groupe.
```
aws ec2 authorize-security-group-ingress --group-id $oldSecGroup \
--source-group $newSecGroup --protocol -1
aws ec2 authorize-security-group-ingress --group-id $newSecGroup \
--source-group $oldSecGroup --protocol -1
```
1. Modifiez la configmap `aws-auth` afin de mapper le nouveau rôle d'instance des nœuds dans RBAC.
```
kubectl edit configmap -n kube-system aws-auth
```
Ajoutez une nouvelle entrée `mapRoles` pour le nouveau groupe de nœuds.
```
apiVersion: v1
data:
mapRoles: |
- rolearn: ARN of instance role (not instance profile)
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:bootstrappers
- system:nodes>
- rolearn: arn:aws: iam::111122223333:role/nodes-1-16-NodeInstanceRole-U11V27W93CX5
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:bootstrappers
- system:nodes
```
Remplacez l'*ARN of instance role (not instance profile)*extrait par la **NodeInstanceRole**valeur que vous avez enregistrée lors d'une étape [précédente](#node-instance-role-step). Ensuite, enregistrez et fermez le fichier pour appliquer le configmap mise à jour.
1. Vérifiez le statut de vos nœuds et attendez que vos nouveaux nœuds rejoignent votre cluster et affichent le statut `Ready`.
```
kubectl get nodes --watch
```
1. (Facultatif) Si vous utilisez l’outil [Cluster Autoscaler de Kubernetes](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler), réduisez verticalement le déploiement à zéro (0) réplicas afin d’éviter tout conflit entre les actions de mise à l’échelle.
```
kubectl scale deployments/cluster-autoscaler --replicas=0 -n kube-system
```
1. Utilisez la commande suivante pour rejeter chacun des nœuds que vous souhaitez supprimer avec `NoSchedule`. Ceci afin que les nouveaux pods ne soient pas planifiés ou replanifiés sur les nœuds que vous remplacez. Pour plus d’informations, consultez [Rejets et tolérances](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) dans la documentation de Kubernetes.
```
kubectl taint nodes node_name key=value:NoSchedule
```
Si vous mettez à niveau vos nœuds vers une nouvelle version de Kubernetes, vous pouvez identifier et rejeter tous les nœuds d’une version Kubernetes donnée (dans ce cas, `1.33`) avec le snippet de code suivant. Le numéro de version ne peut pas être postérieur à la version Kubernetes de votre plan de contrôle. Il ne peut pas non plus être antérieur de plus de deux versions mineures à la version Kubernetes de votre plan de contrôle. Nous vous recommandons d'utiliser la même version que votre plan de contrôle.
```
K8S_VERSION=1.33
nodes=$(kubectl get nodes -o jsonpath="{.items[?(@.status.nodeInfo.kubeletVersion==\"v$K8S_VERSION\")].metadata.name}")
for node in ${nodes[@]}
do
echo "Tainting $node"
kubectl taint nodes $node key=value:NoSchedule
done
```
1. Déterminez le fournisseur DNS de votre cluster.
```
kubectl get deployments -l k8s-app=kube-dns -n kube-system
```
L'exemple qui suit illustre un résultat. Ce cluster utilise CoreDNS pour la résolution DNS, mais votre cluster peut renvoyer la valeur `kube-dns` à la place) :
```
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
coredns 1 1 1 1 31m
```
1. Si votre déploiement actuel exécute moins de deux réplicas, dimensionnez le déploiement à deux réplicas. Remplacez *coredns* par `kubedns` si la sortie de votre commande a plutôt renvoyé cette valeur.
```
kubectl scale deployments/coredns --replicas=2 -n kube-system
```
1. Drainez chacun des nœuds que vous souhaitez supprimer de votre cluster à l'aide de la commande suivante :
```
kubectl drain node_name --ignore-daemonsets --delete-local-data
```
Si vous mettez à niveau vos nœuds vers une nouvelle version de Kubernetes, identifiez et videz tous les nœuds d'une version particulière de Kubernetes (dans ce cas,*1.33*) à l'aide de l'extrait de code suivant.
```
K8S_VERSION=1.33
nodes=$(kubectl get nodes -o jsonpath="{.items[?(@.status.nodeInfo.kubeletVersion==\"v$K8S_VERSION\")].metadata.name}")
for node in ${nodes[@]}
do
echo "Draining $node"
kubectl drain $node --ignore-daemonsets --delete-local-data
done
```
1. Une fois que vos anciens nœuds ont été purgés, révoquez les règles d'entrée du groupe de sécurité que vous avez autorisées précédemment. Supprimez ensuite la AWS CloudFormation pile pour mettre fin aux instances.
**Note**
Si vous avez associé des politiques IAM supplémentaires à votre ancien rôle IAM de groupe de nœuds, par exemple en ajoutant des autorisations pour le [Kubernetes Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler), détachez-les du rôle avant de supprimer votre stack. AWS CloudFormation
1. Révoquez les règles entrantes que vous aviez créées précédemment pour les groupes de sécurité de vos nœuds. Dans ces commandes, `oldNodes` il s'agit du nom de la AWS CloudFormation pile de votre ancienne pile de nœuds et `newNodes` du nom de la pile vers laquelle vous effectuez la migration.
```
oldNodes="old_node_CFN_stack_name"
newNodes="new_node_CFN_stack_name"
oldSecGroup=$(aws cloudformation describe-stack-resources --stack-name $oldNodes \
--query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \
--output text)
newSecGroup=$(aws cloudformation describe-stack-resources --stack-name $newNodes \
--query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \
--output text)
aws ec2 revoke-security-group-ingress --group-id $oldSecGroup \
--source-group $newSecGroup --protocol -1
aws ec2 revoke-security-group-ingress --group-id $newSecGroup \
--source-group $oldSecGroup --protocol -1
```
1. Ouvrez la [AWS CloudFormation console](https://console.aws.amazon.com/cloudformation/).
1. Sélectionnez votre ancienne pile de nœuds.
1. Sélectionnez **Delete (Supprimer)**.
1. Dans la boîte de dialogue de confirmation **Delete stack (Supprimer la pile)**, choisissez **Delete stack (Supprimer la pile)**.
1. Modifiez la configmap `aws-auth` afin de supprimer l'ancien rôle d'instance des nœuds dans RBAC.
```
kubectl edit configmap -n kube-system aws-auth
```
Supprimez l'entrée `mapRoles` de l'ancien groupe de nœuds.
```
apiVersion: v1
data:
mapRoles: |
- rolearn: arn:aws: iam::111122223333:role/nodes-1-16-NodeInstanceRole-W70725MZQFF8
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:bootstrappers
- system:nodes
- rolearn: arn:aws: iam::111122223333:role/nodes-1-15-NodeInstanceRole-U11V27W93CX5
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:bootstrappers
- system:nodes>
```
Enregistrez et fermez le fichier afin d'appliquer la configmap mise à jour.
1. (Facultatif) Si vous utilisez le composant [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler) de Kubernetes, dimensionnez le déploiement à un réplica.
**Note**
Vous devez également labeliser votre nouveau groupe Auto Scaling de façon appropriée (par exemple `k8s.io/cluster-autoscaler/enabled,k8s.io/cluster-autoscaler/my-cluster`) et mettre à jour la commande de votre déploiement Cluster Autoscaler afin qu'elle pointe vers le groupe Auto Scaling nouvellement labelisé. Pour plus d'informations, consultez [Cluster Autoscaler activé. AWS](https://github.com/kubernetes/autoscaler/tree/cluster-autoscaler-release-1.3/cluster-autoscaler/cloudprovider/aws)
```
kubectl scale deployments/cluster-autoscaler --replicas=1 -n kube-system
```
1. (Facultatif) Vérifiez que vous utilisez la dernière version du [plug-in CNI Amazon VPC pour Kubernetes](https://github.com/aws/amazon-vpc-cni-k8s). Vous devrez peut-être mettre à jour votre version de CNI pour utiliser les derniers types d'instances pris en charge. Pour de plus amples informations, veuillez consulter [Attribuer IPs à des pods avec l'Amazon VPC CNI](managing-vpc-cni.md).
1. Si votre cluster utilise `kube-dns` pour la résolution DNS (voir [[migrate-determine-dns-step]](#migrate-determine-dns-step)), réduisez horizontalement le déploiement `kube-dns` à un réplica.
```
kubectl scale deployments/kube-dns --replicas=1 -n kube-system
```