**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.
# Mettez à jour les nœuds autogérés de votre cluster
Quand une nouvelle AMI optimisée pour Amazon EKS est publiée, pensez à remplacer les nœuds autogérés au sein de votre groupe par cette nouvelle AMI. De même, si vous avez mis à jour la version Kubernetes pour votre cluster Amazon EKS, mettez à jour les nœuds afin qu'ils utilisent la même version de Kubernetes.
**Important**
Cette rubrique couvre les mises à jour des nœuds pour les groupes de nœuds autogérés. Si vous utilisez des [groupes de nœuds gérés](managed-node-groups.md), consultez [Mettre à jour un groupe de nœuds gérés pour votre cluster](update-managed-node-group.md).
Deux méthodes de base permettent de mettre à jour les groupes de nœuds autogérés dans vos clusters afin d'utiliser une nouvelle AMI :
** [Migrer des applications vers un nouveau groupe de nœuds](migrate-stack.md) **
Créez un nouveau groupe de nœuds et migrez vos pods vers ce groupe. La migration vers un nouveau groupe de nœuds est plus élégante que la simple mise à jour de l’ID AMI dans une pile AWS CloudFormation existante. En effet, le processus de migration [rejette](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) l’ancien groupe de nœuds en tant que `NoSchedule` et vide les nœuds une fois qu’une nouvelle pile est prête à accepter la charge de travail Pod existante.
** [Mettre à jour une pile de nœuds AWS CloudFormation](update-stack.md) **
Mettez à jour la pile AWS CloudFormation d’un groupe de nœuds existant afin d’utiliser la nouvelle AMI. Cette méthode n’est pas prise en charge pour les groupes de nœuds créés avec `eksctl`.
# 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
```
# Mettre à jour une pile de AWS CloudFormation nœuds
Cette rubrique décrit comment mettre à jour une pile de nœuds AWS CloudFormation autogérés existante avec une nouvelle AMI. Vous pouvez utiliser cette procédure pour mettre à jour vos nœuds vers une nouvelle version de Kubernetes suite à une mise à jour du cluster. Sinon, vous pouvez effectuer une mise à jour vers la dernière AMI optimisée pour Amazon EKS pour une version Kubernetes existante.
**Important**
Cette rubrique couvre les mises à jour des nœuds pour les groupes de nœuds autogérés. Pour plus d’informations sur l’utilisation de [Simplifier le cycle de vie des nœuds avec des groupes de nœuds gérés](managed-node-groups.md), consultez [Mettre à jour un groupe de nœuds gérés pour votre cluster](update-managed-node-group.md).
Le dernier AWS CloudFormation modèle de nœud Amazon EKS par défaut est configuré pour lancer une instance avec la nouvelle AMI dans votre cluster avant de supprimer l'ancienne, une par une. Cette configuration garantit que vous disposez toujours du nombre souhaité d’instances actives de votre groupe Auto Scaling dans votre cluster pendant la mise à jour propagée.
**Note**
Cette méthode n’est pas prise en charge pour les groupes de nœuds créés avec `eksctl`. Si vous avez créé votre cluster ou votre groupe de nœuds avec `eksctl`, consultez [Migrer des applications vers un nouveau groupe de nœuds](migrate-stack.md).
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 `kube-dns` à la place. Votre sortie peut être différente selon la version de `kubectl` que vous utilisez.
```
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 `kube-dns` si la sortie de votre commande a plutôt renvoyé cette valeur.
```
kubectl scale deployments/coredns --replicas=2 -n kube-system
```
1. (Facultatif) Si vous utilisez l’outil [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) de Kubernetes, 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. Déterminez le type d’instance et le nombre d’instances souhaité pour votre groupe de nœuds actuel. Vous entrez ces valeurs ultérieurement lorsque vous mettez à jour le AWS CloudFormation modèle du groupe.
1. Ouvrez la console Amazon EC2 à l'adresse. https://console.aws.amazon.com/ec2/
1. Dans le panneau de navigation de gauche, sélectionnez **Launch Configurations** (Configurations du lancement) et notez le type d'instance pour votre configuration actuelle de lancement des nœuds.
1. Dans le panneau de navigation de gauche, sélectionnez **Auto Scaling Groups** (Groupes Auto Scaling) et notez le nombre d'instances **souhaité** pour le groupe Auto Scaling actuel des nœuds.
1. Ouvrez la [AWS CloudFormation console](https://console.aws.amazon.com/cloudformation/).
1. Sélectionnez votre pile de groupe de nœuds, puis choisissez **Update** (Mettre à jour).
1. Sélectionnez **Replace current template (Remplacer le modèle actuel)** et sélectionnez **Amazon S3 URL (URL Amazon S3)**.
1. Pour **l'URL Amazon S3**, collez l'URL suivante dans la zone de texte pour vous assurer que vous utilisez la dernière version du AWS CloudFormation modèle de nœud. Ensuite, sélectionnez **Next** (Suivant) :
```
https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2022-12-23/amazon-eks-nodegroup.yaml
```
1. Sur la page **Specify stack details** (Spécifier les détails de la pile), renseignez les paramètres suivants, puis choisissez **Next** (Suivant) :
+ **NodeAutoScalingGroupDesiredCapacity**— Entrez le nombre d'instances souhaité que vous avez enregistré lors d'une [étape précédente](#existing-worker-settings-step). Ou saisissez le nouveau nombre de nœuds souhaité pour la mise à l'échelle lorsque votre pile sera mise à jour.
+ **NodeAutoScalingGroupMaxSize**— Entrez le nombre maximum de nœuds auxquels votre groupe Auto Scaling de nœuds peut s'étendre. Cette valeur doit être supérieure d'au moins un nœud à votre capacité souhaitée. Ceci afin de pouvoir effectuer une mise à jour continue de vos nœuds sans réduire votre nombre de nœuds pendant la mise à jour.
+ **NodeInstanceType**— Choisissez le type d'instance que vous avez enregistré à l'[étape précédente](#existing-worker-settings-step). Vous pouvez également choisir un type d'instance différent pour vos nœuds. Avant de choisir un autre type d’instance, consultez [Choisir un type d’instance de nœud Amazon EC2 optimal](choosing-instance-type.md). Chaque type d'instance Amazon EC2 prend en charge un nombre maximal d'interfaces réseau Elastic (interface réseau) et chaque interface réseau prend en charge un nombre maximal d'adresses IP. Étant donné que chaque composant master et chaque pod se voit attribuer sa propre adresse IP, il est important de choisir un type d’instance qui prendra en charge le nombre maximal de pods que vous voulez exécuter sur chaque nœud Amazon EC2. Pour une liste du nombre d'interfaces réseau et d'adresses IP pris en charge par les types d'instances, consultez [adresses IP par interface réseau et par type d'instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#AvailableIpPerENI). Par exemple, le type d’instance `m5.large` prend en charge un maximum de 30 adresses IP pour le composant master et les pods.
**Note**
Les types d'instances pris en charge pour la dernière version du [plugin CNI d'Amazon VPC pour Kubernetes](https://github.com/aws/amazon-vpc-cni-k8s) sont indiqués dans [vpc\$1ip\$1resource\$1limit.go](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/pkg/vpc/vpc_ip_resource_limit.go) sur GitHub. Vous devrez peut-être mettre à jour votre plug-in CNI Amazon VPC pour la version Kubernetes afin d’utiliser les derniers types d’instance pris en charge. Pour de plus amples informations, veuillez consulter [Attribuer IPs à des pods avec l'Amazon VPC CNI](managing-vpc-cni.md).
**Important**
Certains types d'instances peuvent ne pas être disponibles dans toutes les AWS régions.
+ **NodeImageIdSSMParam**— Le paramètre Amazon EC2 Systems Manager de l'ID AMI vers lequel vous souhaitez effectuer la mise à jour. La valeur suivante utilise la dernière AMI optimisée Amazon EKS pour la version `1.35` de Kubernetes.
```
/aws/service/eks/optimized-ami/1.35/amazon-linux-2/recommended/image_id
```
Vous pouvez le *1.35* remplacer par une [version de plateforme](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html) identique. Ou bien, elle doit être antérieure d'une version au maximum à la version Kubernetes exécutée sur votre plan de contrôle. Nous vous recommandons de conserver vos nœuds dans la même version que votre plan de contrôle. Vous pouvez également le remplacer *amazon-linux-2* par un autre type d'AMI. Pour de plus amples informations, veuillez consulter [Récupérez l'AMI Amazon Linux recommandée IDs](retrieve-ami-id.md).
**Note**
L'utilisation du paramètre Amazon EC2 Systems Manager vous permet de mettre à jour vos nœuds à l'avenir sans avoir à rechercher et spécifier un ID d'AMI. Si votre AWS CloudFormation stack utilise cette valeur, toute mise à jour de stack lance toujours la dernière AMI optimisée Amazon EKS recommandée pour la version de Kubernetes que vous avez spécifiée. C’est le cas même si vous ne modifiez aucune valeur dans le modèle.
+ **NodeImageId**— Pour utiliser votre propre AMI personnalisée, entrez l'ID de l'AMI à utiliser.
**Important**
Cette valeur remplace toute valeur spécifiée pour **NodeImageIdSSMParam**. Si vous souhaitez utiliser la **NodeImageIdSSMParam**valeur, assurez-vous que la valeur pour **NodeImageId**est vide.
+ **Désactiver IMDSv1** : par défaut, chaque nœud prend en charge les versions 1 du service de métadonnées d'instance (IMDSv1) et IMDSv2. Vous pouvez toutefois le désactiver IMDSv1. Sélectionnez **true** si vous ne souhaitez pas que les nœuds ou les pods planifiés dans le groupe de nœuds soient utilisés IMDSv1. Pour de plus amples informations au sujet d'IMDS, consultez [Configuration du service des métadonnées d'instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html). Si vous avez implémenté des rôles IAM pour les comptes de service, attribuez les autorisations nécessaires directement à tous les pods nécessitant un accès aux AWS services. Ainsi, aucun pod de votre cluster n'a besoin d'accéder à l'IMDS pour d'autres raisons, telles que la récupération de la région actuelle AWS . Ensuite, vous pouvez également désactiver l'accès IMDSv2 aux pods qui n'utilisent pas le réseau hôte. 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).
1. (Facultatif) Sur la page **Options (Options)**, étiquetez les ressources de votre pile. Choisissez **Suivant**.
1. Sur la page **Review** (Vérification), vérifiez vos informations, acceptez que la pile puisse créer des ressources IAM, puis choisissez **Update stack** (Mettre à jour la pile).
**Note**
La mise à jour de chaque nœud du cluster prend plusieurs minutes. Attendez que la mise à jour de tous les nœuds soit terminée avant d'effectuer les étapes suivantes.
1. Si le fournisseur DNS de votre cluster est `kube-dns`, réduisez horizontalement le déploiement `kube-dns` à une réplica.
```
kubectl scale deployments/kube-dns --replicas=1 -n kube-system
```
1. (Facultatif) Si vous utilisez le composant [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) de Kubernetes, redimensionnez le déploiement à la quantité souhaitée de réplicas.
```
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 plug-in CNI Amazon VPC pour la version Kubernetes afin d’utiliser les derniers types d’instance pris en charge. Pour de plus amples informations, veuillez consulter [Attribuer IPs à des pods avec l'Amazon VPC CNI](managing-vpc-cni.md).