**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.
# Gérer vous-même les nœuds grâce aux nœuds autogérés
Un cluster contient un ou plusieurs nœuds Amazon EC2 sur lesquels les pods sont planifiés. Les nœuds Amazon EKS s'exécutent dans votre compte AWS et se connectent au plan de contrôle de votre cluster via le point de terminaison de serveur de l'API du cluster. Vous êtes facturé pour ceux-ci en fonction des tarifs Amazon EC2. Pour plus d’informations, consultez [Tarification Amazon EC2](https://aws.amazon.com/ec2/pricing/).
Un cluster peut contenir plusieurs groupes de nœuds. Chaque groupe de nœuds contient un ou plusieurs nœuds déployés dans un [groupe Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/AutoScalingGroup.html). Le type d’instance des nœuds au sein du groupe peut varier, par exemple lorsque vous utilisez la [sélection de type d’instance basée sur les attributs](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-fleet-attribute-based-instance-type-selection.html) avec [Karpenter](https://karpenter.sh/). Toutes les instances d'un groupe de nœuds doivent utiliser le [rôle IAM du nœud Amazon EKS](create-node-role.md).
Amazon EKS fournit des images Amazon Machine Image (AMI) spécialisées appelées « AMI optimisées pour Amazon EKS ». Les AMI sont configurées pour fonctionner avec Amazon EKS. Leurs composants incluent `containerd`, `kubelet` et l'authentificateur IAM AWS. Les AMI contiennent également un [script d’amorçage](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh) spécialisé qui leur permet de détecter et de se connecter automatiquement au plan de contrôle de votre cluster.
Si vous limitez l'accès au point de terminaison public de votre cluster à l'aide de blocs CIDR, nous vous recommandons d'activer également l'accès au point de terminaison privé. Cela permet aux nœuds de communiquer avec le cluster. Sans l'activation du point de terminaison privé, les blocs CIDR que vous spécifiez pour l'accès public doivent inclure les sources de sortie de votre VPC. Pour de plus amples informations, consultez [Point de terminaison du serveur d’API du cluster](cluster-endpoint.md).
Pour ajouter des nœuds autogérés à votre cluster Amazon EKS, consultez les rubriques qui suivent. Si vous lancez manuellement des nœuds autogérés, balisez chaque nœud avec la balise suivante en vous assurant que `` correspond à votre cluster. Pour de plus amples informations, veuillez consulter [Ajout et suppression de balises sur une ressource individuelle](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags). Si vous suivez les étapes des guides qui suivent, l'identification requise est ajoutée au nœud pour vous.
| Clé | Valeur |
| --- | --- |
| `kubernetes.io/cluster/` | `owned` |
**Important**
Les balises du service de métadonnées d’instance (IMDS) Amazon EC2 ne sont pas compatibles avec les nœuds Amazon EKS. Lorsque les balises de métadonnées d’instance sont activées, l’utilisation de barres obliques (« / ») dans les valeurs des balises est interdite. Cette limitation peut entraîner des échecs de lancement d’instances, en particulier lorsque vous utilisez des outils de gestion de nœuds tels que Karpenter ou Cluster Autoscaler, car ces services dépendent de balises contenant des barres obliques pour fonctionner correctement.
Pour plus d'informations sur les nœuds à partir d'une perspective Kubernetes générale, consultez [Nœuds](https://kubernetes.io/docs/concepts/architecture/nodes/) dans la documentation Kubernetes.
**Topics**
+ [Créer des nœuds Amazon Linux autogérés](launch-workers.md)
+ [Créer des nœuds Bottlerocket autogérés](launch-node-bottlerocket.md)
+ [Créer des nœuds Microsoft Windows autogérés](launch-windows-workers.md)
+ [Créer des nœuds Ubuntu Linux autogérés](launch-node-ubuntu.md)
+ [Mettez à jour les nœuds autogérés de votre cluster](update-workers.md)
# Créer des nœuds Amazon Linux autogérés
Cette rubrique décrit comment lancer des groupes Auto Scaling de nœuds Linux qui s'enregistrent auprès de votre cluster Amazon EKS. Une fois que les nœuds ont rejoint le cluster, vous pouvez y déployer des applications Kubernetes. Vous pouvez également lancer des nœuds Amazon Linux autogérés avec `eksctl` ou le AWS Management Console. Si vous devez lancer des nœuds sur AWS Outposts, consultez. [Créez des nœuds Amazon Linux sur AWS Outposts](eks-outposts-self-managed-nodes.md)
+ Un cluster Amazon EKS existant. Pour en déployer un, consultez [Création d’un cluster Amazon EKS](create-cluster.md). Si vous avez des sous-réseaux dans la AWS région où AWS Outposts, AWS Wavelength ou Local AWS Zones est activé, ces sous-réseaux ne doivent pas avoir été transmis lorsque vous avez créé votre cluster.
+ Un rôle IAM existant pour les nœuds à utiliser. Pour en créer un, consultez [Rôle IAM de nœud Amazon EKS](create-node-role.md). Si ce rôle ne comporte aucune des politiques pour le VPC CNI, le rôle distinct suivant est nécessaire pour les pods VPC CNI.
+ (Facultatif, mais recommandé) Le plug-in CNI Amazon VPC pour le module complémentaire Kubernetes est configuré avec son propre rôle IAM auquel est associée la politique IAM nécessaire. Pour de plus amples informations, veuillez consulter [Configuration du plug-in Amazon VPC CNI pour utiliser IRSA](cni-iam-role.md).
+ Connaissance des considérations répertoriées dans la section [Choisissez un type d'instance de EC2 nœud Amazon optimal](choosing-instance-type.md). Selon le type d'instance que vous choisissez, il peut y avoir des prérequis supplémentaires pour votre cluster et votre VPC.
Vous pouvez lancer des nœuds Linux autogérés à l’aide de l’une des méthodes suivantes :
+ [`eksctl`](#eksctl_create_managed_amazon_linux)
+ [AWS Management Console](#console_create_managed_amazon_linux)
## `eksctl`
**Lancer des nœuds Linux autogérés à l’aide de `eksctl` **
1. Installez la version `0.215.0` ou une version ultérieure de l'outil de ligne de `eksctl` commande installé sur votre appareil ou AWS CloudShell. Pour installer ou mettre à jour `eksctl`, veuillez consulter [Installation](https://eksctl.io/installation) dans la documentation de `eksctl`.
1. (Facultatif) Si la politique d’IAM gérée **AmazonEKS\$1CNI\$1Policy** est associée à votre [rôle IAM de nœud Amazon EKS](create-node-role.md), nous vous recommandons de l’attribuer à un rôle IAM que vous associez au compte de service Kubernetes `aws-node` à la place. Pour de plus amples informations, veuillez consulter [Configuration du plug-in Amazon VPC CNI pour utiliser IRSA](cni-iam-role.md).
1. La commande suivante crée un groupe de nœuds dans un cluster existant. Remplacer *al-nodes* avec un nom pour votre groupe de nœuds. Le nom du groupe de nœuds ne peut pas dépasser 63 caractères. Il doit commencer par une lettre ou un chiffre, mais peut également inclure des tirets et des traits de soulignement pour les autres caractères. Remplacez *my-cluster* par le nom de votre cluster. Un nom ne peut contenir que des caractères alphanumériques (sensibles à la casse) et des traits d'union. Il doit commencer par un caractère alphanumérique et ne peut pas dépasser 100 caractères. Le nom doit être unique dans la AWS région et le AWS compte dans lesquels vous créez le cluster. Remplacez les valeurs de *example value* restantes par vos propres valeurs. Par défaut, les nœuds sont créés avec la même version de Kubernetes que le plan de contrôle.
Avant de choisir une valeur pour`--node-type`, consultez l'article [Choisissez un type d'instance de EC2 nœud Amazon optimal](choosing-instance-type.md).
*my-key*Remplacez-le par le nom de votre paire de EC2 clés Amazon ou de votre clé publique. Cette clé est utilisée pour SSH dans vos nœuds après leur lancement. Si vous ne possédez pas encore de paire de EC2 clés Amazon, vous pouvez en créer une dans le AWS Management Console. Pour plus d'informations, consultez les [paires de EC2 clés Amazon](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) dans le *guide de EC2 l'utilisateur Amazon*.
Créez votre groupe de nœuds avec la commande suivante.
**Important**
Si vous souhaitez déployer un groupe de nœuds sur des sous-réseaux AWS Outposts, Wavelength ou Local Zone, vous devez prendre en compte d'autres considérations :
Les sous-réseaux ne doivent pas avoir été renseignés lors de la création du cluster.
Vous devez créer le groupe de nœuds avec un fichier config qui spécifie les sous-réseaux et ` [volumeType](https://eksctl.io/usage/schema/#nodeGroups-volumeType): gp2`. Pour plus d'informations, consultez [Créer un nodegroup à partir d'un fichier config](https://eksctl.io/usage/nodegroups/#creating-a-nodegroup-from-a-config-file) et [Schéma du fichier Config](https://eksctl.io/usage/schema/) dans la documentation `eksctl`.
```
eksctl create nodegroup \
--cluster my-cluster \
--name al-nodes \
--node-type t3.medium \
--nodes 3 \
--nodes-min 1 \
--nodes-max 4 \
--ssh-access \
--managed=false \
--ssh-public-key my-key
```
Pour déployer un groupe de nœuds qui :
+ peut attribuer un nombre d’adresses IP aux pods nettement supérieur à celui de la configuration par défaut, consultez [Attribution de davantage d’adresses IP aux nœuds Amazon EKS avec des préfixes](cni-increase-ip-addresses.md).
+ peut attribuer des adresses `IPv4` aux pods à partir d’un bloc CIDR différent de celui de l’instance, consultez [Déploiement de pods dans des sous-réseaux alternatifs avec réseau personnalisé](cni-custom-network.md).
+ peut attribuer des adresses `IPv6` aux pods et aux services, consultez [En savoir plus sur IPv6 les adresses des clusters, des pods et des services](cni-ipv6.md).
+ ne dispose pas d’un accès Internet sortant, consultez [Déployer des clusters privés avec un accès Internet limité](private-clusters.md).
Pour obtenir la liste complète de toutes les options disponibles et des valeurs par défaut, saisissez la commande suivante.
```
eksctl create nodegroup --help
```
Si les nœuds ne parviennent pas à rejoindre le cluster, consultez la section [Les nœuds ne parviennent pas à joindre le cluster](troubleshooting.md#worker-node-fail) du chapitre Dépannage.
L'exemple qui suit illustre un résultat. Plusieurs lignes sont affichées pendant la création des nœuds. L'une des dernières lignes de sortie est similaire à la ligne d'exemple suivante.
```
[✔] created 1 nodegroup(s) in cluster "my-cluster"
```
1. (Facultatif) Déployez un [exemple d'application](sample-deployment.md) pour tester votre cluster et les nœuds Linux.
1. 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' EC2 instance Amazon (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).
## AWS Management Console
**Étape 1 : lancer les nœuds Linux autogérés à l’aide de la AWS Management Console **
1. Téléchargez la dernière version du AWS CloudFormation modèle.
```
curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2025-11-26/amazon-eks-nodegroup.yaml
```
1. Attendez que le statut de votre cluster s'affiche soit `ACTIVE`. Si vous lancez vos nœuds avant que le cluster soit actif, les nœuds ne s'enregistrent pas avec le cluster et vous devrez les relancer.
1. Ouvrez la [AWS CloudFormation console](https://console.aws.amazon.com/cloudformation/).
1. Choisissez **Create stack (Créer une pile)**, puis sélectionnez **Avec de nouvelles ressources (standard)**.
1. Pour **Spécifier un modèle**, sélectionnez ** Upload a template file (Télécharger un fichier de modèle)**, puis sélectionnez **Choose file (Choisir un fichier)**.
1. Sélectionnez le fichier `amazon-eks-nodegroup.yaml` que vous avez téléchargé.
1. Sélectionnez **Suivant**.
1. Dans la page **Specify stack details** (Spécifier les détails de la pile), saisissez les paramètres suivants, puis choisissez **Next** (Suivant) :
+ **Nom de pile** : Choisissez un nom de pile pour votre AWS CloudFormation pile. Par exemple, vous pouvez l'appeler *my-cluster-nodes*. Un nom ne peut contenir que des caractères alphanumériques (sensibles à la casse) et des traits d'union. Il doit commencer par un caractère alphanumérique et ne peut pas dépasser 100 caractères. Le nom doit être unique dans la AWS région et le AWS compte dans lesquels vous créez le cluster.
+ **ClusterName**: Entrez le nom que vous avez utilisé lors de la création de votre cluster Amazon EKS. Ce nom doit être identique au nom du cluster, sinon vos nœuds ne pourront pas rejoindre le cluster.
+ **ClusterControlPlaneSecurityGroup**: Choisissez la **SecurityGroups**valeur à partir de la AWS CloudFormation sortie que vous avez générée lors de la création de votre [VPC](creating-a-vpc.md).
Les étapes suivantes montrent une opération permettant de récupérer le groupe applicable.
1. Ouvrez la [console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Choisissez le nom du cluster.
1. Choisissez l'onglet **Networking (Mise en réseau)**.
1. Utilisez la valeur **Groupes de sécurité supplémentaires** comme référence lorsque vous effectuez une sélection **ClusterControlPlaneSecurityGroup**dans la liste déroulante.
+ **ApiServerEndpoint**: Entrez le point de terminaison du serveur API pour votre cluster EKS. Cela se trouve dans la section Détails de la console EKS Cluster
+ **CertificateAuthorityData**: Entrez les données de l'autorité de certification codées en base64, qui se trouvent également dans la section Détails de la console EKS Cluster.
+ **ServiceCidr**: Entrez la plage CIDR utilisée pour attribuer des adresses IP aux services Kubernetes au sein du cluster. Cela se trouve dans l'onglet réseau de la console EKS Cluster.
+ **AuthenticationMode**: Sélectionnez le mode d'authentification utilisé dans le cluster EKS en consultant l'onglet d'accès dans la console du cluster EKS.
+ **NodeGroupName**: Entrez le nom de votre groupe de nœuds. Ce nom peut être utilisé ultérieurement pour identifier le groupe de nœuds autoscaling qui est créé pour vos nœuds. Le nom du groupe de nœuds ne peut pas dépasser 63 caractères. Il doit commencer par une lettre ou un chiffre, mais peut également inclure des tirets et des traits de soulignement pour les autres caractères.
+ **NodeAutoScalingGroupMinSize**: Entrez le nombre minimum de nœuds que votre groupe Auto Scaling de nœuds peut atteindre.
+ **NodeAutoScalingGroupDesiredCapacity**: Entrez le nombre de nœuds que vous souhaitez atteindre lors de la création de votre pile.
+ **NodeAutoScalingGroupMaxSize**: Entrez le nombre maximum de nœuds que votre groupe Auto Scaling de nœuds peut atteindre.
+ **NodeInstanceType**: Choisissez un type d'instance pour vos nœuds. Pour de plus amples informations, veuillez consulter [Choix du type d’instance Amazon EC2 optimal pour les nœuds](choosing-instance-type.md).
+ **NodeImageIdSSMParam**: prérempli avec le paramètre Amazon EC2 Systems Manager d'une récente AMI Amazon Linux 2023 optimisée pour Amazon EKS pour une version variable de Kubernetes. Pour utiliser une autre version mineure de Kubernetes prise en charge avec Amazon EKS, remplacez *1.XX* par une autre [version prise en charge](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html). Nous vous recommandons de spécifier la même version de Kubernetes que celle de votre cluster.
Vous pouvez également le remplacer *amazon-linux-2023* 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**
Le nœud Amazon EKS AMIs est basé sur Amazon Linux. Vous pouvez suivre les événements liés à la sécurité ou à la confidentialité d'[Amazon Linux 2023 dans le centre de sécurité](https://alas.aws.amazon.com/alas2023.html) Amazon Linux ou vous abonner au [flux RSS](https://alas.aws.amazon.com/AL2023/alas.rss) associé. Les événements de sécurité et de confidentialité incluent une présentation du problème, les packages concernés et la manière de mettre à jour vos instances pour résoudre le problème.
+ **NodeImageId**: (Facultatif) Si vous utilisez votre propre AMI personnalisée (au lieu d'une AMI optimisée pour Amazon EKS), entrez un ID d'AMI de nœud pour votre AWS région. Si vous spécifiez une valeur ici, elle remplace toutes les valeurs du **NodeImageIdSSMParam**champ.
+ **NodeVolumeSize**: Spécifiez une taille de volume racine pour vos nœuds, en GiB.
+ **NodeVolumeType**: Spécifiez un type de volume racine pour vos nœuds.
+ **KeyName**: Entrez le nom d'une paire de clés Amazon EC2 SSH que vous pourrez utiliser pour vous connecter via SSH à vos nœuds après leur lancement. Si vous ne possédez pas encore de paire de EC2 clés Amazon, vous pouvez en créer une dans le AWS Management Console. Pour plus d'informations, consultez les [paires de EC2 clés Amazon](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) dans le *guide de EC2 l'utilisateur Amazon*.
+ **VpcId**: Entrez l'ID du [VPC](creating-a-vpc.md) que vous avez créé.
+ **Sous-réseaux** : choisissez les sous-réseaux que vous avez créés pour votre VPC. Si vous avez créé votre Amazon VPC en suivant les étapes décrites dans [Créer un Amazon VPC pour votre cluster Amazon EKS](creating-a-vpc.md), spécifiez uniquement les sous-réseaux privés au sein de l’Amazon VPC dans lesquels vos nœuds doivent être lancés. Vous pouvez consulter les sous-réseaux privés en ouvrant le lien de chaque sous-réseau depuis l'onglet **Networking** (Mise en réseau) de votre cluster.
**Important**
Si certains sous-réseaux sont des sous-réseaux publics, leur paramètre d'attribution automatique d'adresse IP publique doit être activé. Si le paramètre n'est pas activé pour le sous-réseau public, aucun nœud que vous déployez sur ce sous-réseau public ne se verra attribuer d'adresse IP publique et ne pourra pas communiquer avec le cluster ou d'autres AWS services. Si le sous-réseau a été déployé avant le 26 mars 2020 en utilisant l'un des modèles de [AWS CloudFormation VPC Amazon EKS](creating-a-vpc.md) ou `eksctl` en utilisant, l'attribution automatique d'adresses IP publiques est désactivée pour les sous-réseaux publics. Pour plus d'informations sur la façon d'activer l'attribution d'adresses IP publiques pour un sous-réseau, consultez la section [Modification de l'attribut d' IPv4 adressage public de votre sous-réseau](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip). Si le nœud est déployé sur un sous-réseau privé, il est capable de communiquer avec le cluster et d'autres AWS services via une passerelle NAT.
Si les sous-réseaux n’ont pas d’accès Internet, assurez-vous de prendre connaissance des considérations et des étapes supplémentaires décrites dans [Déployer des clusters privés avec un accès Internet limité](private-clusters.md).
Si vous sélectionnez AWS les sous-réseaux Outposts, Wavelength ou Local Zone, les sous-réseaux ne doivent pas avoir été transmis lors de la création du cluster.
1. Sélectionnez les choix que vous souhaitez sur la page **Configure stack options** (Configurer les options de la pile), puis choisissez **Next** (Suivant).
1. Cochez la case à gauche de **J'accuse réception AWS CloudFormation susceptible de créer des ressources IAM**. , puis choisissez **Create stack**.
1. Lorsque la création de votre pile est terminée, sélectionnez la pile dans la console et choisissez **Outputs** (Sorties). Si vous utilisez le mode `EKS API and ConfigMap` d'authentification `EKS API` ou, il s'agit de la dernière étape.
1. Si vous utilisez le mode `ConfigMap` d'authentification, enregistrez le **NodeInstanceRole**pour le groupe de nœuds créé.
**Étape 2 : autoriser les nœuds à rejoindre votre cluster**
**Note**
Les deux étapes suivantes ne sont nécessaires que si le mode d'authentification Configmap est utilisé dans le cluster EKS. En outre, si vous avez lancé des nœuds au sein d'un VPC privé sans accès Internet sortant, veillez à autoriser les nœuds à rejoindre votre cluster depuis le VPC.
1. Vérifiez si vous avez déjà appliqué le `ConfigMap` `aws-auth`.
```
kubectl describe configmap -n kube-system aws-auth
```
1. Si vous voyez un `ConfigMap` `aws-auth`, mettez-le à jour si nécessaire.
1. Ouvrez le `ConfigMap` pour le modifier.
```
kubectl edit -n kube-system configmap/aws-auth
```
1. Ajoutez une nouvelle entrée `mapRoles` si nécessaire. Définissez la `rolearn` valeur sur la **NodeInstanceRole**valeur que vous avez enregistrée lors de la procédure précédente.
```
[...]
data:
mapRoles: |
- rolearn:
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:bootstrappers
- system:nodes
[...]
```
1. Enregistrez le fichier et quittez votre éditeur de texte.
1. Si vous avez reçu un message d'erreur indiquant « `Error from server (NotFound): configmaps "aws-auth" not found` », appliquez le stock `ConfigMap`.
1. Téléchargez la mappe de configuration.
```
curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm.yaml
```
1. Dans le `aws-auth-cm.yaml` fichier, définissez la `rolearn` valeur sur celle **NodeInstanceRole**que vous avez enregistrée lors de la procédure précédente. Pour ce faire, utilisez un éditeur de texte ou remplacez *my-node-instance-role* et exécutez la commande suivante :
```
sed -i.bak -e 's||my-node-instance-role|' aws-auth-cm.yaml
```
1. Appliquez la configuration. L'exécution de cette commande peut prendre quelques minutes.
```
kubectl apply -f aws-auth-cm.yaml
```
1. Observez le statut de vos nœuds et attendez qu'ils obtiennent le statut `Ready`.
```
kubectl get nodes --watch
```
Saisissez `Ctrl`\$1`C` pour revenir à une invite de shell.
**Note**
Si vous recevez d'autres erreurs concernant les types d'autorisations ou de ressources, consultez [Accès non autorisé ou refusé (`kubectl`)](troubleshooting.md#unauthorized) dans la rubrique relative à la résolution des problèmes.
Si les nœuds ne parviennent pas à rejoindre le cluster, consultez la section [Les nœuds ne parviennent pas à joindre le cluster](troubleshooting.md#worker-node-fail) du chapitre Dépannage.
1. (Nœuds GPU uniquement) Si vous avez choisi un type d'instance GPU et l'AMI accélérée optimisée pour Amazon EKS, vous devez appliquer le [plug-in d'appareil NVIDIA pour Kubernetes](https://github.com/NVIDIA/k8s-device-plugin) en tant que tel DaemonSet sur votre cluster. *vX.X.X*Remplacez-le par la s-device-plugin version [Nvidia/K8](https://github.com/NVIDIA/k8s-device-plugin/releases) de votre choix avant d'exécuter la commande suivante.
```
kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/vX.X.X/deployments/static/nvidia-device-plugin.yml
```
**Étape 3 : actions supplémentaires**
1. (Facultatif) Déployez un [exemple d'application](sample-deployment.md) pour tester votre cluster et les nœuds Linux.
1. (Facultatif) Si la politique IAM gérée par **Amazoneks\$1CNI\$1Policy** (si vous avez `IPv4` un cluster) ou celle (que vous avez [créée vous-même](cni-iam-role.md#cni-iam-role-create-ipv6-policy) si vous avez un `IPv6` cluster) est attachée *AmazonEKS\$1CNI\$1IPv6\$1Policy* au rôle IAM de votre [nœud Amazon EKS, nous vous recommandons de l'attribuer à un rôle IAM](create-node-role.md) que vous associez plutôt au compte de service Kubernetes. `aws-node` Pour de plus amples informations, veuillez consulter [Configuration du plug-in Amazon VPC CNI pour utiliser IRSA](cni-iam-role.md).
1. 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' EC2 instance Amazon (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).
# Créer des nœuds Bottlerocket autogérés
**Note**
Les groupes de nœuds gérés peuvent offrir certains avantages pour votre cas d'utilisation. Pour de plus amples informations, veuillez consulter [Simplifiez le cycle de vie des nœuds avec des groupes de nœuds gérés](managed-node-groups.md).
Cette rubrique décrit comment lancer des groupes Auto Scaling de nœuds [Bottlerocket](https://aws.amazon.com/bottlerocket/) qui s’enregistrent auprès de votre cluster Amazon EKS. Bottlerocket est un système d'exploitation open source basé sur Linux AWS que vous pouvez utiliser pour exécuter des conteneurs sur des machines virtuelles ou des hôtes bare metal. Une fois que les nœuds ont rejoint le cluster, vous pouvez y déployer des applications Kubernetes. Pour plus d'informations sur Bottlerocket, consultez la section [Utilisation d'une AMI Bottlerocket avec Amazon EKS](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-EKS.md) activé GitHub et la prise en charge des [AMI personnalisées](https://eksctl.io/usage/custom-ami-support/) dans la documentation. `eksctl`
Pour plus d'informations sur les mises à niveau sur place, consultez [Bottlerocket](https://github.com/bottlerocket-os/bottlerocket-update-operator) Update Operator on. GitHub
**Important**
Les nœuds Amazon EKS sont des instances Amazon EC2 standard pour lesquelles vous êtes facturé en fonction du tarif normal pour les instances Amazon EC2. Pour plus d’informations, consultez [Tarification Amazon EC2](https://aws.amazon.com/ec2/pricing/).
Vous pouvez lancer des nœuds Bottlerocket dans des clusters étendus Amazon EKS sur AWS Outposts, mais vous ne pouvez pas les lancer dans des clusters locaux sur Outposts. AWS Pour de plus amples informations, veuillez consulter [Déployez Amazon EKS sur site avec AWS Outposts](eks-outposts.md).
Vous pouvez déployer sur des instances Amazon EC2 avec des processeurs `x86` ou Arm. Cependant, vous ne pouvez pas déployer sur des instances équipées de puces Inferentia.
Bottlerocket est compatible avec. AWS CloudFormation Cependant, aucun CloudFormation modèle officiel ne peut être copié pour déployer des nœuds Bottlerocket pour Amazon EKS.
Les images Bottlerocket ne sont pas fournies avec un serveur SSH ou un shell. Vous pouvez utiliser des méthodes out-of-band d'accès pour autoriser SSH à activer le conteneur d'administration et pour passer certaines étapes de configuration d'amorçage avec les données utilisateur. Pour plus d'informations, consultez ces sections dans le [README.md de bottlerocket](https://github.com/bottlerocket-os/bottlerocket) sur GitHub :
[Exploration](https://github.com/bottlerocket-os/bottlerocket#exploration)
[Conteneur d'administration](https://github.com/bottlerocket-os/bottlerocket#admin-container)
[Paramètres Kubernetes](https://github.com/bottlerocket-os/bottlerocket#kubernetes-settings)
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 obtenir des instructions sur l’installation ou la mise à niveau d’`eksctl`, consultez [Installation](https://eksctl.io/installation) dans la documentation `eksctl`. REMARQUE : cette procédure ne fonctionne que pour les clusters créés avec `eksctl`.
1. Copiez les contenus suivants sur votre appareil. Remplacez *my-cluster* par le nom de votre cluster. Un nom ne peut contenir que des caractères alphanumériques (sensibles à la casse) et des traits d'union. Il doit commencer par un caractère alphanumérique et ne peut pas dépasser 100 caractères. Le nom doit être unique dans la AWS région et le AWS compte dans lesquels vous créez le cluster. Remplacer *ng-bottlerocket* avec un nom pour votre groupe de nœuds. Le nom du groupe de nœuds ne peut pas dépasser 63 caractères. Il doit commencer par une lettre ou un chiffre, mais peut également inclure des tirets et des traits de soulignement pour les autres caractères. Pour effectuer un déploiement sur des instances Arm, remplacez *m5.large* par un type d'instance Arm. Remplacez *my-ec2-keypair-name* par le nom d'une paire de clés SSH Amazon EC2 que vous pouvez utiliser pour vous connecter à l'aide de SSH dans vos nœuds après leur lancement. Si vous ne possédez pas déjà une paire de clés Amazon EC2, vous pouvez en créer une dans l’ AWS Management Console. Pour plus d'informations, veuillez consulter la rubrique [Paires de clés Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) dans le *Guide de l'utilisateur Amazon EC2*. Remplacez toutes les valeurs d’exemple restantes par vos propres valeurs. Une fois les remplacements effectués, exécutez la commande modifiée pour créer le fichier `bottlerocket.yaml`.
Si vous spécifiez un type d'instance Arm Amazon EC2, consultez les points à prendre en compte dans Arm [Amazon Linux optimisé pour Amazon EKS AMIs](eks-optimized-ami.md#arm-ami) avant le déploiement. Pour obtenir des instructions sur le déploiement à l'aide d'une AMI personnalisée, consultez les sections [Building Bottlerocket](https://github.com/bottlerocket-os/bottlerocket/blob/develop/BUILDING.md) on et GitHub Custom [AMI support](https://eksctl.io/usage/custom-ami-support/) dans la documentation. `eksctl` Pour déployer un groupe de nœuds gérés, déployez une AMI personnalisée à l'aide d'un modèle de lancement. Pour de plus amples informations, veuillez consulter [Personnaliser les nœuds gérés à l’aide de modèles de lancement](launch-templates.md).
**Important**
Pour déployer un groupe de nœuds sur des sous-réseaux AWS Outposts, AWS Wavelength ou AWS Local Zone, ne transmettez pas les sous-réseaux Outposts AWS , AWS Wavelength ou AWS Local Zone lorsque vous créez le cluster. Vous devez spécifier les sous-réseaux dans l'exemple suivant. Pour plus d'informations, consultez [Créer un nodegroup à partir d'un fichier de configuration](https://eksctl.io/usage/nodegroups/#creating-a-nodegroup-from-a-config-file) et [Schéma du fichier de configuration](https://eksctl.io/usage/schema/) dans la documentation `eksctl`. Remplacez *region-code* par la AWS région dans laquelle se trouve votre cluster.
```
cat >bottlerocket.yaml <
Cette rubrique décrit comment lancer des groupes Auto Scaling de nœuds Windows qui s'enregistrent auprès de votre cluster Amazon EKS. Une fois que les nœuds ont rejoint le cluster, vous pouvez y déployer des applications Kubernetes.
**Important**
Les nœuds Amazon EKS sont des instances Amazon EC2 standard pour lesquelles vous êtes facturé en fonction du tarif normal pour les instances Amazon EC2. Pour plus d’informations, consultez [Tarification Amazon EC2](https://aws.amazon.com/ec2/pricing/).
Vous pouvez lancer des nœuds Windows dans des clusters étendus Amazon EKS sur AWS Outposts, mais vous ne pouvez pas les lancer dans des clusters locaux sur AWS Outposts. Pour de plus amples informations, veuillez consulter [Déployez Amazon EKS sur site avec AWS Outposts](eks-outposts.md).
Activer la prise en charge de Windows pour votre cluster avec. Nous vous recommandons de passer en revue les considérations importantes avant de lancer un groupe de nœuds Windows. Pour de plus amples informations, veuillez consulter [Activer la prise en charge de Windows](windows-support.md#enable-windows-support).
Vous pouvez lancer des nœuds Windows autogérés à l’aide de l’une des méthodes suivantes :
+ [`eksctl`](#eksctl_create_windows_nodes)
+ [AWS Management Console](#console_create_windows_nodes)
## `eksctl`
**Lancer des nœuds Windows autogérés à l’aide de `eksctl`**
Cette procédure exige que vous installiez `eksctl` et que votre version `eksctl` soit au moins la version `0.215.0`. Vous pouvez vérifier votre version à l'aide de 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 créés avec `eksctl`.
1. (Facultatif) Si la politique IAM gérée par **Amazoneks\$1CNI\$1Policy** (si vous avez `IPv4` un cluster) ou celle (que vous avez [créée vous-même](cni-iam-role.md#cni-iam-role-create-ipv6-policy) si vous avez un `IPv6` cluster) est attachée *AmazonEKS\$1CNI\$1IPv6\$1Policy* au rôle IAM de votre [nœud Amazon EKS, nous vous recommandons de l'attribuer à un rôle IAM](create-node-role.md) que vous associez plutôt au compte de service Kubernetes. `aws-node` Pour de plus amples informations, veuillez consulter [Configuration du plug-in Amazon VPC CNI pour utiliser IRSA](cni-iam-role.md).
1. Cette procédure part du principe que vous disposez d'un cluster existant. Si vous ne disposez pas encore d’un cluster Amazon EKS et d’un groupe de nœuds Amazon Linux auquel ajouter un groupe de nœuds Windows, nous vous recommandons de suivre [Démarrage avec Amazon EKS – `eksctl`](getting-started-eksctl.md). Ce guide fournit une démonstration complète pour créer un cluster Amazon EKS avec des nœuds Amazon Linux.
Créez votre groupe de nœuds avec la commande suivante. Remplacez *region-code* par la AWS région dans laquelle se trouve votre cluster. Remplacez *my-cluster* par le nom de votre cluster. Un nom ne peut contenir que des caractères alphanumériques (sensibles à la casse) et des traits d'union. Il doit commencer par un caractère alphanumérique et ne peut pas dépasser 100 caractères. Le nom doit être unique dans la AWS région et le AWS compte dans lesquels vous créez le cluster. Remplacer *ng-windows* avec un nom pour votre groupe de nœuds. Le nom du groupe de nœuds ne peut pas dépasser 63 caractères. Il doit commencer par une lettre ou un chiffre, mais peut également inclure des tirets et des traits de soulignement pour les autres caractères. Vous pouvez *2019* remplacer par `2022` pour utiliser Windows Server 2022 ou `2025` Windows Server 2025. Remplacez le reste des valeurs d’exemple par vos propres valeurs.
**Important**
Pour déployer un groupe de nœuds sur des sous-réseaux AWS Outposts, AWS Wavelength ou AWS Local Zone, ne transmettez pas les sous-réseaux Outposts AWS , Wavelength ou Local Zone lorsque vous créez le cluster. Créez le groupe de nœuds avec un fichier de configuration, en spécifiant les AWS sous-réseaux Outposts, Wavelength ou Local Zone. Pour plus d'informations, consultez [Créer un nodegroup à partir d'un fichier config](https://eksctl.io/usage/nodegroups/#creating-a-nodegroup-from-a-config-file) et [Schéma du fichier Config](https://eksctl.io/usage/schema/) dans la documentation `eksctl`.
```
eksctl create nodegroup \
--region region-code \
--cluster my-cluster \
--name ng-windows \
--node-type t2.large \
--nodes 3 \
--nodes-min 1 \
--nodes-max 4 \
--managed=false \
--node-ami-family WindowsServer2019FullContainer
```
**Note**
Si les nœuds ne parviennent pas à rejoindre le cluster, reportez-vous à [Les nœuds ne parviennent pas à joindre le cluster](troubleshooting.md#worker-node-fail) dans le guide de dépannage.
Pour voir les options disponibles pour les commandes `eksctl`, saisissez la commande suivante.
```
eksctl command -help
```
L'exemple qui suit illustre un résultat. Plusieurs lignes sont affichées pendant la création des nœuds. L'une des dernières lignes de sortie est similaire à la ligne d'exemple suivante.
```
[✔] created 1 nodegroup(s) in cluster "my-cluster"
```
1. (Facultatif) Déployez un [exemple d'application](sample-deployment.md) pour tester votre cluster et les nœuds Windows.
1. 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).
## AWS Management Console
**Conditions préalables**
+ Un cluster Amazon EKS existant et un groupe de nœuds Linux. Si vous ne disposez pas de ces ressources, nous vous recommandons de les créer à l’aide de l’un de nos guides dans [Mise en route avec Amazon EKS](getting-started.md). Ces guides décrivent comment créer un cluster Amazon EKS avec des nœuds Linux.
+ Un VPC et un groupe de sécurité existants qui remplissent les conditions requises pour un cluster Amazon EKS. Pour plus d’informations, consultez [Afficher les exigences réseau Amazon EKS pour les VPC et les sous-réseaux](network-reqs.md) et [Voir les exigences relatives aux groupes de sécurité Amazon EKS pour les clusters](sec-group-reqs.md). Les guides disponibles dans [Mise en route avec Amazon EKS](getting-started.md) créent un VPC qui répond aux exigences. Vous pouvez également suivre les instructions de [Créer un Amazon VPC pour votre cluster Amazon EKS](creating-a-vpc.md) pour en créer un manuellement.
+ Un cluster Amazon EKS existant qui utilise un VPC et un groupe de sécurité qui remplit les conditions requises pour un cluster Amazon EKS. Pour de plus amples informations, veuillez consulter [Création d’un cluster Amazon EKS](create-cluster.md). Si vous avez des sous-réseaux dans la AWS région où AWS Outposts, AWS Wavelength ou Local AWS Zones est activé, ces sous-réseaux ne doivent pas avoir été transmis lorsque vous avez créé le cluster.
**Étape 1 : lancer des nœuds Windows autogérés à l’aide de la AWS Management Console **
1. Attendez que le statut de votre cluster s'affiche soit `ACTIVE`. Si vous lancez vos nœuds avant que le cluster soit actif, les nœuds ne s'enregistrent pas avec le cluster et vous devez les relancer.
1. Ouvrez la [console AWS CloudFormation ](https://console.aws.amazon.com/cloudformation/).
1. Sélectionnez **Créer la pile**.
1. Dans **Spécifier le modèle**, sélectionnez **URL Amazon S3**.
1. Copiez l'URL suivante et collez-la dans l'**URL Amazon S3**.
```
https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2023-02-09/amazon-eks-windows-nodegroup.yaml
```
1. Sélectionnez **Next** (Suivant) deux fois.
1. Sur la page **Création rapide d'une pile**, saisissez les paramètres suivants en conséquence :
+ **Nom de pile** : Choisissez un nom de pile pour votre AWS CloudFormation pile. Par exemple, vous pouvez l'appeler `my-cluster-nodes`.
+ **ClusterName**: Entrez le nom que vous avez utilisé lors de la création de votre cluster Amazon EKS.
**Important**
Ce nom doit correspondre exactement au nom que vous avez utilisé dans [Étape 1 : créer votre cluster Amazon EKS](getting-started-console.md#eks-create-cluster). Sinon, vos nœuds ne pourront pas rejoindre le cluster.
+ **ClusterControlPlaneSecurityGroup**: Choisissez le groupe de sécurité dans la AWS CloudFormation sortie que vous avez générée lors de la création de votre [VPC](creating-a-vpc.md). Les étapes suivantes montrent une méthode permettant de récupérer le groupe applicable.
1. Ouvrez la [console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Choisissez le nom du cluster.
1. Choisissez l'onglet **Networking (Mise en réseau)**.
1. Utilisez la valeur **Groupes de sécurité supplémentaires** comme référence lorsque vous effectuez une sélection **ClusterControlPlaneSecurityGroup**dans la liste déroulante.
+ **NodeGroupName**: Entrez le nom de votre groupe de nœuds. Ce nom peut être utilisé ultérieurement pour identifier le groupe de nœuds autoscaling qui est créé pour vos nœuds. Le nom du groupe de nœuds ne peut pas dépasser 63 caractères. Il doit commencer par une lettre ou un chiffre, mais peut également inclure des tirets et des traits de soulignement pour les autres caractères.
+ **NodeAutoScalingGroupMinSize**: Entrez le nombre minimum de nœuds que votre groupe Auto Scaling de nœuds peut atteindre.
+ **NodeAutoScalingGroupDesiredCapacity**: Entrez le nombre de nœuds que vous souhaitez atteindre lors de la création de votre pile.
+ **NodeAutoScalingGroupMaxSize**: Entrez le nombre maximum de nœuds que votre groupe Auto Scaling de nœuds peut atteindre.
+ **NodeInstanceType**: Choisissez un type d'instance pour vos nœuds. Pour de plus amples informations, veuillez consulter [Choix du type d’instance Amazon EC2 optimal pour les nœuds](choosing-instance-type.md).
**Note**
[Les types d'instances pris en charge pour la dernière version du [plugin Amazon VPC CNI pour Kubernetes sont répertoriés dans vpc\$1ip\$1resource\$1limit.go](https://github.com/aws/amazon-vpc-cni-k8s) on.](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/pkg/vpc/vpc_ip_resource_limit.go) GitHub 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).
+ **NodeImageIdSSMParam**: prérempli avec le paramètre Amazon EC2 Systems Manager de l'ID AMI Windows Core optimisé pour Amazon EKS actuellement recommandé. Pour utiliser la version complète de Windows, remplacez *Core* par `Full`.
+ **NodeImageId**: (Facultatif) Si vous utilisez votre propre AMI personnalisée (au lieu d'une AMI optimisée pour Amazon EKS), entrez un ID d'AMI de nœud pour votre AWS région. Si vous spécifiez une valeur pour ce champ, elle remplace toutes les valeurs du **NodeImageIdSSMParam**champ.
+ **NodeVolumeSize**: Spécifiez une taille de volume racine pour vos nœuds, en GiB.
+ **KeyName**: Entrez le nom d'une paire de clés SSH Amazon EC2 que vous pourrez utiliser pour vous connecter via SSH à vos nœuds après leur lancement. Si vous ne possédez pas déjà une paire de clés Amazon EC2, vous pouvez en créer une dans l’ AWS Management Console. Pour plus d'informations, veuillez consulter la rubrique [Paires de clés Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-key-pairs.html) dans le *Guide de l'utilisateur Amazon EC2*.
**Note**
Si vous ne fournissez pas de paire de clés ici, la AWS CloudFormation pile ne sera pas créée.
+ **BootstrapArguments**: Spécifiez tous les arguments facultatifs à transmettre au script bootstrap du nœud, tels que des `kubelet` arguments supplémentaires en utilisant`-KubeletExtraArgs`.
+ **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 désactiver IMDSv1. Pour empêcher l'utilisation des futurs nœuds et pods du groupe de nœuds MDSv1, définissez **Disable IMDSv1** sur **true**. 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).
+ **VpcId**: Sélectionnez l'ID du [VPC](creating-a-vpc.md) que vous avez créé.
+ **NodeSecurityGroups**: Sélectionnez le groupe de sécurité créé pour votre groupe de nœuds Linux lorsque vous avez créé votre [VPC](creating-a-vpc.md). Si vos nœuds Linux sont associés à plusieurs groupes de sécurité, spécifiez-les tous. C'est le cas, par exemple, si le groupe de nœuds Linux a été créé avec `eksctl`.
+ **Sous-réseaux** : choisissez les sous-réseaux que vous avez créés. Si vous avez créé votre VPC en suivant les étapes décrites dans [Créer un Amazon VPC pour votre cluster Amazon EKS](creating-a-vpc.md), spécifiez uniquement les sous-réseaux privés au sein du VPC dans lesquels vos nœuds doivent être lancés.
**Important**
Si certains sous-réseaux sont des sous-réseaux publics, leur paramètre d'attribution automatique d'adresse IP publique doit être activé. Si le paramètre n'est pas activé pour le sous-réseau public, aucun nœud que vous déployez sur ce sous-réseau public ne se verra attribuer d'adresse IP publique et ne pourra pas communiquer avec le cluster ou d'autres AWS services. Si le sous-réseau a été déployé avant le 26 mars 2020 en utilisant l'un des modèles de [AWS CloudFormation VPC Amazon EKS](creating-a-vpc.md) ou `eksctl` en utilisant, l'attribution automatique d'adresses IP publiques est désactivée pour les sous-réseaux publics. Pour plus d'informations sur la façon d'activer l'attribution d'adresses IP publiques pour un sous-réseau, consultez la section [Modification de l'attribut d' IPv4 adressage public de votre sous-réseau](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip). Si le nœud est déployé sur un sous-réseau privé, il est capable de communiquer avec le cluster et d'autres AWS services via une passerelle NAT.
Si les sous-réseaux n’ont pas accès à Internet, veuillez vous assurer de prendre connaissance des considérations et des étapes supplémentaires décrites dans [Déployer des clusters privés avec un accès Internet limité](private-clusters.md).
Si vous sélectionnez AWS les sous-réseaux Outposts, Wavelength ou Local Zone, les sous-réseaux ne doivent pas avoir été transmis lors de la création du cluster.
1. Confirmez que la pile peut créer des ressources IAM, puis choisissez **Create stack (Créer une pile)**.
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 lors de la configuration de vos nœuds Windows Amazon EKS.
**Étape 2 : autoriser les nœuds à rejoindre votre cluster**
1. Vérifiez si vous avez déjà appliqué le `ConfigMap` `aws-auth`.
```
kubectl describe configmap -n kube-system aws-auth
```
1. Si vous voyez un `ConfigMap` `aws-auth`, mettez-le à jour si nécessaire.
1. Ouvrez le `ConfigMap` pour le modifier.
```
kubectl edit -n kube-system configmap/aws-auth
```
1. Ajoutez de nouvelles entrées `mapRoles` selon vos besoins. Définissez les `rolearn` valeurs selon les **NodeInstanceRole**valeurs que vous avez enregistrées dans les procédures précédentes.
```
[...]
data:
mapRoles: |
- rolearn:
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:bootstrappers
- system:nodes
- rolearn:
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:bootstrappers
- system:nodes
- eks:kube-proxy-windows
[...]
```
1. Enregistrez le fichier et quittez votre éditeur de texte.
1. Si vous avez reçu un message d'erreur indiquant « `Error from server (NotFound): configmaps "aws-auth" not found` », appliquez le stock `ConfigMap`.
1. Téléchargez la mappe de configuration.
```
curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm-windows.yaml
```
1. Dans le `aws-auth-cm-windows.yaml` fichier, définissez les `rolearn` valeurs en fonction des **NodeInstanceRole**valeurs applicables que vous avez enregistrées dans les procédures précédentes. Vous pouvez effectuer cette opération à l’aide d’un éditeur de texte ou en remplaçant les valeurs d’exemple et en exécutant la commande suivante :
```
sed -i.bak -e 's||my-node-linux-instance-role|' \
-e 's||my-node-windows-instance-role|' aws-auth-cm-windows.yaml
```
**Important**
Ne modifiez aucune autre ligne de ce fichier.
Veuillez ne pas utiliser le même rôle IAM pour les nœuds Windows et Linux.
1. Appliquez la configuration. L'exécution de cette commande peut prendre quelques minutes.
```
kubectl apply -f aws-auth-cm-windows.yaml
```
1. Observez le statut de vos nœuds et attendez qu'ils obtiennent le statut `Ready`.
```
kubectl get nodes --watch
```
Saisissez `Ctrl`\$1`C` pour revenir à une invite de shell.
**Note**
Si vous recevez d'autres erreurs concernant les types d'autorisations ou de ressources, consultez [Accès non autorisé ou refusé (`kubectl`)](troubleshooting.md#unauthorized) dans la rubrique relative à la résolution des problèmes.
Si les nœuds ne parviennent pas à rejoindre le cluster, consultez la section [Les nœuds ne parviennent pas à joindre le cluster](troubleshooting.md#worker-node-fail) du chapitre Dépannage.
**Étape 3 : actions supplémentaires**
1. (Facultatif) Déployez un [exemple d'application](sample-deployment.md) pour tester votre cluster et les nœuds Windows.
1. (Facultatif) Si la politique IAM gérée par **Amazoneks\$1CNI\$1Policy** (si vous avez `IPv4` un cluster) ou celle (que vous avez [créée vous-même](cni-iam-role.md#cni-iam-role-create-ipv6-policy) si vous avez un `IPv6` cluster) est attachée *AmazonEKS\$1CNI\$1IPv6\$1Policy* au rôle IAM de votre [nœud Amazon EKS, nous vous recommandons de l'attribuer à un rôle IAM](create-node-role.md) que vous associez plutôt au compte de service Kubernetes. `aws-node` Pour de plus amples informations, veuillez consulter [Configuration du plug-in Amazon VPC CNI pour utiliser IRSA](cni-iam-role.md).
1. 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).
# Créer des nœuds Ubuntu Linux autogérés
**Note**
Les groupes de nœuds gérés peuvent offrir certains avantages pour votre cas d'utilisation. Pour de plus amples informations, veuillez consulter [Simplifiez le cycle de vie des nœuds avec des groupes de nœuds gérés](managed-node-groups.md).
Cette rubrique décrit comment lancer des groupes Auto Scaling de nœuds [Ubuntu sur Amazon Elastic Kubernetes Service (EKS)](https://cloud-images.ubuntu.com/aws-eks/) ou [Ubuntu Pro sur Amazon Elastic Kubernetes Service (EKS)](https://ubuntu.com/blog/ubuntu-pro-for-eks-is-now-generally-available) qui s’enregistrent auprès de votre cluster Amazon EKS. Ubuntu et Ubuntu Pro pour EKS sont basés sur le LTS officiel Ubuntu Minimal, incluent le AWS noyau personnalisé développé conjointement avec AWS EKS et spécialement conçu pour EKS. Ubuntu Pro renforce la sécurité en prenant en charge les périodes de support étendu EKS, le livepatch du noyau, la conformité FIPS et la possibilité d’exécuter un nombre illimité de conteneurs Pro.
Une fois les nœuds intégrés au cluster, vous pouvez y déployer des applications conteneurisées. Pour plus d’informations, consultez la documentation relative à [Ubuntu sur AWS](https://documentation.ubuntu.com/aws/en/latest/) et [Prise en charge des AMI personnalisées](https://eksctl.io/usage/custom-ami-support/) dans la documentation `eksctl`.
**Important**
Les nœuds Amazon EKS sont des instances Amazon EC2 standard pour lesquelles vous êtes facturé en fonction du tarif normal pour les instances Amazon EC2. Pour plus d’informations, consultez [Tarification Amazon EC2](https://aws.amazon.com/ec2/pricing/).
Vous pouvez lancer des nœuds Ubuntu dans des clusters étendus Amazon EKS sur AWS Outposts, mais vous ne pouvez pas les lancer dans des clusters locaux sur AWS Outposts. Pour de plus amples informations, veuillez consulter [Déployez Amazon EKS sur site avec AWS Outposts](eks-outposts.md).
Vous pouvez déployer sur des instances Amazon EC2 avec des processeurs `x86` ou Arm. Cependant, les instances équipées de puces Inferentia peuvent nécessiter l’installation préalable du [Kit SDK de Neuron](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/).
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 obtenir des instructions sur l’installation ou la mise à niveau d’`eksctl`, consultez [Installation](https://eksctl.io/installation) dans la documentation `eksctl`. REMARQUE : cette procédure ne fonctionne que pour les clusters créés avec `eksctl`.
1. Copiez les contenus suivants sur votre appareil. Remplacez `my-cluster` par le nom de votre cluster. Un nom ne peut contenir que des caractères alphanumériques (sensibles à la casse) et des traits d'union. Il doit commencer par une lettre et ne peut pas dépasser 100 caractères. Remplacer `ng-ubuntu` avec un nom pour votre groupe de nœuds. Le nom du groupe de nœuds ne peut pas dépasser 63 caractères. Il doit commencer par une lettre ou un chiffre, mais peut également inclure des tirets et des traits de soulignement pour les autres caractères. Pour effectuer un déploiement sur des instances Arm, remplacez `m5.large` par un type d'instance Arm. Remplacez `my-ec2-keypair-name` par le nom d'une paire de clés SSH Amazon EC2 que vous pouvez utiliser pour vous connecter à l'aide de SSH dans vos nœuds après leur lancement. Si vous ne possédez pas déjà une paire de clés Amazon EC2, vous pouvez en créer une dans l’ AWS Management Console. Pour plus d’informations, consultez [Paires de clés Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) dans le Guide de l’utilisateur Amazon EC2. Remplacez toutes les valeurs d’exemple restantes par vos propres valeurs. Une fois les remplacements effectués, exécutez la commande modifiée pour créer le fichier `ubuntu.yaml`.
**Important**
Pour déployer un groupe de nœuds sur des sous-réseaux AWS Outposts, AWS Wavelength ou AWS Local Zone, ne transmettez pas les sous-réseaux Outposts AWS , AWS Wavelength ou AWS Local Zone lorsque vous créez le cluster. Vous devez spécifier les sous-réseaux dans l'exemple suivant. Pour plus d'informations, consultez [Créer un nodegroup à partir d'un fichier de configuration](https://eksctl.io/usage/nodegroups/#creating-a-nodegroup-from-a-config-file) et [Schéma du fichier de configuration](https://eksctl.io/usage/schema/) dans la documentation `eksctl`. Remplacez *region-code* par la AWS région dans laquelle se trouve votre cluster.
```
cat >ubuntu.yaml <
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).