**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. # 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).