**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.
# Simplifiez le cycle de vie des nœuds avec des groupes de nœuds gérés
Les groupes de nœuds gérés par Amazon EKS automatisent le provisionnement et la gestion du cycle de vie des nœuds ( EC2 instances Amazon) pour les clusters Amazon EKS Kubernetes.
Avec les groupes de nœuds gérés par Amazon EKS, vous n'avez pas besoin de configurer ou d'enregistrer séparément les EC2 instances Amazon qui fournissent la capacité de calcul pour exécuter vos applications Kubernetes. Vous pouvez créer, mettre à jour ou résilier les nœuds pour votre cluster en une seule opération. Les mises à jour et les résiliations de nœuds purgent automatiquement les nœuds afin de garantir la disponibilité de vos applications.
Chaque nœud géré est approvisionné dans le cadre d'un groupe Amazon EC2 Auto Scaling géré pour vous par Amazon EKS. Toutes les ressources, y compris les instances et les groupes Auto Scaling, s'exécutent au sein de votre AWS compte. Chaque groupe de nœuds s'exécute dans plusieurs zones de disponibilité que vous définissez.
Les groupes de nœuds gérés peuvent également tirer parti, en option, de la fonctionnalité de réparation automatique des nœuds, qui surveille en permanence leur état. Il réagit automatiquement aux problèmes détectés et remplace les nœuds lorsque cela est possible. Cela contribue à la disponibilité globale du cluster avec un minimum d’intervention manuelle. Pour de plus amples informations, veuillez consulter [Détectez les problèmes de santé des nœuds et activez la réparation automatique des nœuds](node-health.md).
Vous pouvez ajouter un groupe de nœuds gérés à des clusters nouveaux ou existants à l'aide de la console, de la AWS CLI`eksctl`, de l' AWS API ou de l'infrastructure Amazon EKS en tant qu'outils de code, notamment AWS CloudFormation. Les nœuds lancés dans le cadre d’un groupe de nœuds gérés sont automatiquement marqués pour être détectés automatiquement par l’outil [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) de Kubernetes. Vous pouvez utiliser le groupe de nœuds pour appliquer des labels Kubernetes aux nœuds et les mettre à jour à tout moment.
L'utilisation des groupes de nœuds gérés par Amazon EKS n'entraîne aucun coût supplémentaire. Vous ne payez que pour les AWS ressources que vous fournissez. Il s'agit notamment EC2 des instances Amazon, des volumes Amazon EBS, des heures de cluster Amazon EKS et de toute autre AWS infrastructure. Aucun frais minimum ni aucun engagement initial ne s'appliquent.
Pour démarrer avec un nouveau cluster Amazon EKS et un groupe de nœuds gérés, consultez [Démarrez avec Amazon EKS AWS Management Console et la AWS CLI](getting-started-console.md).
Pour ajouter un groupe de nœuds gérés à un cluster existant, consultez [Création d’un groupe de nœuds gérés pour votre cluster](create-managed-node-group.md).
## Concepts des groupes de nœuds gérés
+ Les groupes de nœuds gérés par Amazon EKS créent et gèrent EC2 des instances Amazon pour vous.
+ Chaque nœud géré est approvisionné dans le cadre d'un groupe Amazon EC2 Auto Scaling géré pour vous par Amazon EKS. De plus, toutes les ressources, y compris les EC2 instances Amazon et les groupes Auto Scaling, sont exécutées au sein de votre AWS compte.
+ Le groupe Auto Scaling d'un groupe de nœuds gérés couvre chaque sous-réseau que vous spécifiez lorsque vous créez le groupe.
+ Amazon EKS étiquette les ressources du groupe de nœuds gérés afin qu’elles soient configurées pour utiliser l’outil [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) de Kubernetes.
**Important**
Si vous exécutez une application avec état sur plusieurs zones de disponibilité, prise en charge par des volumes Amazon EBS et utilisant l’outil [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) de Kubernetes, vous devez configurer plusieurs groupes de nœuds, chacun limité à une seule zone de disponibilité. En outre, vous devez activer la fonction `--balance-similar-node-groups`.
+ Vous pouvez utiliser un modèle de lancement personnalisé pour un plus grand niveau de flexibilité et de personnalisation lors du déploiement de nœuds gérés. Par exemple, vous pouvez spécifier des arguments `kubelet` supplémentaires et utiliser une AMI personnalisée. Pour de plus amples informations, veuillez consulter [Personnaliser les nœuds gérés à l’aide de modèles de lancement](launch-templates.md). Si vous n’utilisez pas de modèle de lancement personnalisé lors de la première création d’un groupe de nœuds gérés, un modèle de lancement est généré automatiquement. Ne modifiez pas manuellement ce modèle généré automatiquement, sinon des erreurs se produiront.
+ Amazon EKS suit le modèle de responsabilité partagée CVEs et les correctifs de sécurité sur les groupes de nœuds gérés. Lorsque les nœuds gérés exécutent une AMI optimisée pour Amazon EKS, cette dernière est chargée de créer des versions corrigées de l'AMI lorsque des bogues ou des problèmes sont signalés. Nous pouvons publier un correctif. Cependant, vous êtes responsable du déploiement de ces versions corrigées de l’AMI sur vos groupes de nœuds gérés. Lorsque les nœuds gérés exécutent une AMI personnalisée, vous êtes responsable de la création de versions corrigées de l’AMI lorsque des bogues ou des problèmes sont signalés, puis du déploiement de l’AMI. Pour de plus amples informations, veuillez consulter [Mettre à jour un groupe de nœuds gérés pour votre cluster](update-managed-node-group.md).
+ Les groupes de nœuds gérés par Amazon EKS peuvent être lancés dans des sous-réseaux publics et privés. Si vous lancez un groupe de nœuds gérés dans un sous-réseau public à partir du 22 avril 2020, `MapPublicIpOnLaunch` du sous-réseau doit avoir la valeur true pour que les instances puissent rejoindre un cluster. Si le sous-réseau public a été créé à l'aide `eksctl` des [AWS CloudFormation modèles Amazon EKS vendus](creating-a-vpc.md) le 26 mars 2020 ou après cette date, ce paramètre est déjà défini sur true. Si les sous-réseaux publics ont été créés avant le 26 mars 2020, vous devez modifier le paramètre manuellement. Pour plus d'informations, 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).
+ Lorsque vous déployez un groupe de nœuds gérés dans des sous-réseaux privés, vous devez vous assurer qu'il peut accéder à Amazon ECR pour extraire des images de conteneurs. Vous pouvez procéder en connectant une passerelle NAT à la table de routage du sous-réseau ou en ajoutant les [points de terminaison d'un VPC AWS PrivateLink ](https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html#ecr-setting-up-vpc-create) suivants :
+ Interface de point de terminaison de l'API Amazon ECR : `com.amazonaws.region-code.ecr.api`
+ Interface de point de terminaison de l'API de registre Docker Amazon ECR : `com.amazonaws.region-code.ecr.dkr`
+ Point de terminaison de la passerelle Amazon S3 : `com.amazonaws.region-code.s3`
Pour d'autres services et points de terminaison couramment utilisés, veuillez consulter la rubrique [Déployer des clusters privés avec un accès Internet limité](private-clusters.md).
+ Les groupes de nœuds gérés ne peuvent pas être déployés sur [AWS Outposts](eks-outposts.md) ou dans [AWS Wavelength](https://docs.aws.amazon.com/wavelength/). Des groupes de nœuds gérés peuvent être créés sur les [zones locales AWS](https://aws.amazon.com/about-aws/global-infrastructure/localzones/). Pour de plus amples informations, veuillez consulter [Lancer des clusters EKS à faible latence avec AWS Local Zones](local-zones.md).
+ Vous pouvez créer plusieurs groupes de nœuds gérés au sein d'un même cluster. Par exemple, vous pouvez créer un groupe de nœuds avec l’AMI Amazon Linux optimisée Amazon EKS standard pour certaines charges de travail et un autre avec la variante GPU pour les charges de travail qui nécessitent la prise en charge GPU.
+ Si votre groupe de nœuds gérés rencontre un échec de [vérification de l'état d'une EC2 instance Amazon](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-system-instance-status-check.html), Amazon EKS renvoie un code d'erreur pour vous aider à diagnostiquer le problème. Pour de plus amples informations, veuillez consulter [Codes d'erreurs liées aux groupes de nœuds gérés](troubleshooting.md#troubleshoot-managed-node-groups).
+ Amazon EKS ajoute des labels Kubernetes aux instances de groupes de nœuds gérés. Ces labels fournis par Amazon EKS ont le préfixe `eks.amazonaws.com`.
+ Amazon EKS purge automatiquement les nœuds à l'aide de l'API Kubernetes lors des résiliations ou des mises à jour.
+ Les budgets de perturbation des pods ne sont pas respectés lors de l’arrêt d’un nœud avec `AZRebalance` ou de la réduction du nombre de nœuds souhaité. Ces actions tentent d’expulser les pods du nœud. Mais si l’opération prend plus de 15 minutes, le nœud est arrêté, que tous les pods du nœud aient été arrêtés ou non. Pour prolonger le délai d'arrêt du nœud, ajoutez un hook de cycle de vie au groupe Auto Scaling. Pour plus d'informations, consultez la section [Ajouter des hooks de cycle](https://docs.aws.amazon.com/autoscaling/ec2/userguide/adding-lifecycle-hooks.html) de vie dans le *guide de l'utilisateur d'Amazon EC2 Auto Scaling*.
+ Pour exécuter correctement le processus de vidange après avoir reçu une notification d'interruption ponctuelle ou une notification de rééquilibrage des capacités, `CapacityRebalance` doit être réglé sur `true`.
+ La mise à jour des groupes de nœuds gérés respecte les budgets de perturbation des pods que vous avez définis pour vos pods. Pour de plus amples informations, veuillez consulter [Comprendre chaque phase des mises à jour des nœuds](managed-node-update-behavior.md).
+ L'utilisation de groupes de nœuds gérés par Amazon EKS est disponible sans coûts supplémentaires. Vous ne payez que pour les AWS ressources que vous fournissez.
+ Si vous souhaitez chiffrer les volumes Amazon EBS pour vos nœuds, vous pouvez déployer les nœuds à l'aide d'un modèle de lancement. Pour déployer des nœuds gérés avec des volumes Amazon EBS chiffrés sans utiliser de modèle de lancement, chiffrez tous les nouveaux volumes Amazon EBS créés dans votre compte. Pour plus d'informations, consultez la section [Chiffrement par défaut](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html#encryption-by-default) dans le *guide de EC2 l'utilisateur Amazon*.
## Types de capacité des groupes de nœuds gérés
Lorsque vous créez un groupe de nœuds gérés, vous pouvez choisir le type de capacité à la demande ou Spot. Amazon EKS déploie un groupe de nœuds gérés avec un groupe Amazon EC2 Auto Scaling qui contient uniquement des instances On-Demand ou uniquement des instances Amazon EC2 Spot. Vous pouvez planifier des pods pour des applications tolérantes aux pannes dans des groupes de nœuds gérés Spot, et des applications intolérantes aux pannes dans des groupes de nœuds à la demande au sein d’un même cluster Kubernetes. Par défaut, un groupe de nœuds gérés déploie les EC2 instances Amazon On-Demand.
### À la demande
Avec les instances à la demande, vous payez la capacité de calcul à la seconde, sans engagement à long terme.
Par défaut, si vous ne spécifiez pas de **Type de capacité**, le groupe de nœuds gérés est alloué avec des instances à la demande. Un groupe de nœuds géré configure un groupe Amazon EC2 Auto Scaling en votre nom avec les paramètres suivants appliqués :
+ La stratégie d'allocation pour fournir la capacité à la demande est définie sur `prioritized`. Les groupes de nœuds gérés utilisent l'ordre des types d'instance transmis dans l'API pour déterminer le type d'instance à utiliser en premier lors de la fourniture de la capacité à la demande. Par exemple, vous pouvez spécifier trois types d'instances dans l'ordre suivant : `c5.large`, `c4.large` et `c3.large`. Lorsque vos instances à la demande sont lancées, le groupe de nœuds gérés fournit la capacité à la demande en commençant par `c5.large`, puis `c4.large` et enfin `c3.large`. Pour plus d'informations, consultez le [groupe Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/asg-purchase-options.html#asg-allocation-strategies) dans le *guide de l'utilisateur Amazon EC2 Auto Scaling*.
+ Amazon EKS ajoute le label Kubernetes suivant à tous les nœuds de votre groupe de nœuds gérés qui spécifie le type de capacité : `eks.amazonaws.com/capacityType: ON_DEMAND` Vous pouvez utiliser ce label pour programmer des applications à état ou intolérantes aux pannes sur des nœuds à la demande.
### Spot
Les instances Amazon EC2 Spot sont des EC2 capacités inutilisées d'Amazon qui offrent des remises importantes par rapport aux prix à la demande. Les instances Amazon EC2 Spot peuvent être interrompues moyennant un préavis de deux minutes lorsqu'il est EC2 nécessaire de rétablir leur capacité. Pour plus d'informations, consultez la section [Instances Spot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html) dans le *guide de EC2 l'utilisateur Amazon*. Vous pouvez configurer un groupe de nœuds gérés avec des instances Amazon EC2 Spot afin d'optimiser les coûts des nœuds de calcul exécutés dans votre cluster Amazon EKS.
Pour utiliser des instances Spot dans un groupe de nœuds gérés, créez un groupe de nœuds gérés en définissant le type de capacité comme `spot`. Un groupe de nœuds géré configure un groupe Amazon EC2 Auto Scaling en votre nom en appliquant les meilleures pratiques Spot suivantes :
+ Pour garantir que vos nœuds Spot sont alloués dans les groupes de capacité Spot optimaux, la stratégie d’allocation est définie sur l’une des options suivantes :
+ `price-capacity-optimized` (PCO) : lors de la création de nouveaux groupes de nœuds dans un cluster avec la version Kubernetes `1.28` ou supérieure, la stratégie d’allocation est définie sur `price-capacity-optimized`. Cependant, la stratégie d’allocation ne sera pas modifiée pour les groupes de nœuds déjà créés avec `capacity-optimized` avant que les groupes de nœuds gérés par Amazon EKS ne commencent à prendre en charge le PCO.
+ `capacity-optimized` (CO) : lors de la création de nouveaux groupes de nœuds dans un cluster avec la version Kubernetes `1.27` ou une version antérieure, la stratégie d’allocation est définie sur `capacity-optimized`.
Pour augmenter le nombre de groupes de capacité Spot disponibles pour l'allocation de capacité, configurez un groupe de nœuds gérés pour utiliser plusieurs types d'instances.
+ Le rééquilibrage de capacité Amazon EC2 Spot est activé afin qu'Amazon EKS puisse drainer et rééquilibrer en douceur vos nœuds Spot afin de minimiser les perturbations des applications lorsqu'un nœud Spot présente un risque élevé d'interruption. Pour plus d'informations, consultez [Amazon EC2 Auto Scaling Capacity Rebalancing](https://docs.aws.amazon.com/autoscaling/ec2/userguide/capacity-rebalance.html) dans le *guide de l'utilisateur d'Amazon EC2 Auto Scaling*.
+ Lorsqu'un nœud Spot reçoit une recommandation de rééquilibrage, Amazon EKS tente automatiquement de lancer un nouveau nœud Spot de remplacement.
+ Si un avis d'interruption de deux minutes arrive avant que le nœud Spot de remplacement ne soit dans l'état `Ready`, Amazon EKS commence à purger le nœud Spot qui a reçu la recommandation de rééquilibrage. Amazon EKS vide le nœud dans la mesure du possible. Par conséquent, rien ne garantit qu’Amazon EKS attendra que le nœud de remplacement rejoigne le cluster avant de vider le nœud existant.
+ Lorsqu'un nœud Spot de remplacement est démarré et est dans l'état `Ready` sur Kubernetes, Amazon EKS cloisonne et purge le nœud Spot qui a reçu la recommandation de rééquilibrage. Le cloisonnement du nœud Spot garantit que le contrôleur de service n’envoie pas de nouvelles demandes à ce nœud Spot. Il le supprime également de sa liste de nœuds Spot sains et actifs. La purge du nœud Spot garantit que les pods en cours d’exécution sont expulsés proprement.
+ Amazon EKS ajoute le label Kubernetes suivant à tous les nœuds de votre groupe de nœuds gérés qui spécifie le type de capacité : `eks.amazonaws.com/capacityType: SPOT` Vous pouvez utiliser ce label pour programmer des applications tolérantes aux pannes sur les nœuds Spot.
**Important**
EC2 émet un [avis d'interruption Spot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-instance-termination-notices.html) deux minutes avant de mettre fin à votre instance Spot. Cependant, les nœuds Pods on Spot peuvent ne pas bénéficier de la fenêtre complète de 2 minutes pour un arrêt progressif. Lorsque l'avis est EC2 émis, Amazon EKS ne commence à expulser les Pods qu'après un certain délai. Les expulsions se produisent de manière séquentielle pour protéger le serveur d'API Kubernetes. Ainsi, lors de plusieurs réclamations simultanées de Spot, certains Pods peuvent recevoir des notifications d'expulsion différées. Les pods peuvent être fermés de force sans recevoir de signaux de terminaison, en particulier sur les nœuds à forte densité de pods, lors de réclamations simultanées ou lors de l'utilisation de longues périodes de grâce de terminaison. Pour les charges de travail Spot, nous recommandons de concevoir des applications tolérantes aux interruptions, d'utiliser des délais de résiliation de 30 secondes ou moins, d'éviter les longs hooks Prestop et de surveiller les indicateurs d'éviction des Pod pour comprendre les délais de grâce réels dans vos clusters. Pour les charges de travail nécessitant une résiliation progressive garantie, nous recommandons plutôt d'utiliser la capacité à la demande.
Lorsque vous décidez de déployer un groupe de nœuds avec une capacité à la demande ou Spot, vous devez tenir compte des conditions suivantes :
+ Les instances Spot conviennent bien aux applications sans état, tolérantes aux pannes et flexibles. Il s'agit notamment des charges de travail de formation par lots et de machine learning, des mégadonnées ETLs telles qu'Apache Spark, des applications de traitement des files d'attente et des points de terminaison d'API sans état. Spot étant une EC2 capacité inutilisée d'Amazon, qui peut changer au fil du temps, nous vous recommandons d'utiliser la capacité Spot pour les charges de travail tolérantes aux interruptions. Plus précisément, la capacité Spot convient aux charges de travail qui peuvent tolérer des périodes où la capacité requise n’est pas disponible.
+ Nous vous recommandons d'utiliser la capacité à la demande pour les applications qui sont intolérantes aux pannes. Cela inclut les outils de gestion de cluster tels que les outils de surveillance et d'exploitation, les déploiements qui nécessitent `StatefulSets`, et les applications avec état, telles que les bases de données.
+ Pour maximiser la disponibilité de vos applications en utilisant les instances Spot, nous vous recommandons de configurer un groupe de nœuds gérés Spot pour utiliser plusieurs types d'instances. Nous vous recommandons d'appliquer les règles suivantes lorsque vous utilisez plusieurs types d'instance :
+ Dans un groupe de nœuds gérés, si vous utilisez [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md), nous vous recommandons d’utiliser un ensemble flexible de types d’instances avec la même quantité de ressources vCPU et de mémoire. Ceci afin de garantir que les nœuds de votre cluster soient mis à l'échelle comme prévu. Par exemple, si vous avez besoin de quatre V CPUs et de huit GiB de mémoire, utilisez`c3.xlarge`,,`c4.xlarge`,`c5.xlarge`, `c5d.xlarge` `c5a.xlarge``c5n.xlarge`, ou d'autres types d'instance similaires.
+ Pour améliorer la disponibilité des applications, nous recommandons de déployer plusieurs groupes de nœuds gérés Spot. Pour cela, chaque groupe doit utiliser un ensemble flexible de types d'instances qui disposent des mêmes ressources vCPU et mémoire. Par exemple, si vous avez besoin de 4 V CPUs et 8 GiB de mémoire, nous vous recommandons de créer un groupe de nœuds gérés avec`c3.xlarge`,,`c4.xlarge`,`c5.xlarge`, `c5d.xlarge` `c5a.xlarge``c5n.xlarge`, ou d'autres types d'instances similaires, et un second groupe de nœuds gérés avec`m3.xlarge`,,, `m4.xlarge` `m5.xlarge` `m5d.xlarge``m5a.xlarge`, `m5n.xlarge` ou d'autres types d'instances similaires.
+ Lorsque vous déployez votre groupe de nœuds avec le type de capacité Spot qui utilise un modèle de lancement personnalisé, utilisez l’API pour transmettre plusieurs types d’instances. Ne transmettez pas un seul type d’instance via le modèle de lancement. Pour plus d'informations sur le déploiement d'un groupe de nœuds à l'aide d'un modèle de lancement, consultez [Personnaliser les nœuds gérés à l’aide de modèles de lancement](launch-templates.md).
# Création d’un groupe de nœuds gérés pour votre cluster
Cette rubrique explique comment lancer des groupes de nœuds gérés Amazon EKS composés de nœuds qui s'enregistrent dans votre cluster Amazon EKS. Une fois que les nœuds ont rejoint le cluster, vous pouvez y déployer des applications Kubernetes.
Si vous créez un groupe de nœuds gérés par Amazon EKS pour la première fois, nous vous recommandons plutôt de suivre l’un des guides dans [Mise en route avec Amazon EKS](getting-started.md). Ces guides fournissent des procédures détaillées pour créer un cluster Amazon EKS avec des nœuds.
**Important**
Les nœuds Amazon EKS sont des instances Amazon EC2 standard. La facturation s’applique selon les tarifs normaux d’Amazon EC2. Pour plus d’informations, consultez [Tarification Amazon EC2](https://aws.amazon.com/ec2/pricing/).
Vous ne pouvez pas créer de nœuds gérés dans une AWS région où AWS Outposts ou AWS Wavelength sont activés. Vous pouvez créer des nœuds autogérés à la place. Pour plus d’informations, consultez [Créer des nœuds Amazon Linux autogérés](launch-workers.md), [Créer des nœuds Microsoft Windows autogérés](launch-windows-workers.md) et [Créer des nœuds Bottlerocket autogérés](launch-node-bottlerocket.md). Vous pouvez également créer un groupe de nœuds Amazon Linux autogéré sur un Outpost. Pour de plus amples informations, veuillez consulter [Créez des nœuds Amazon Linux sur AWS Outposts](eks-outposts-self-managed-nodes.md).
Si vous ne [spécifiez pas un ID d’AMI](launch-templates.md#launch-template-custom-ami) pour le fichier `bootstrap.sh` inclus dans Linux ou Bottlerocket optimisé pour Amazon EKS, les groupes de nœuds gérés imposent un nombre maximal à la valeur de `maxPods`. Pour les instances de moins de 30 VCPUs, le nombre maximum est de`110`. Pour les instances avec une tension supérieure à 30 VCPUs, le nombre maximum passe à`250`. Cette application remplace les autres `maxPods` configurations, notamment`maxPodsExpression`. Pour plus d'informations sur le `maxPods` mode de détermination et sur la manière de le personnaliser, consultez[Comment est déterminé MaxPods](choosing-instance-type.md#max-pods-precedence).
+ Un cluster Amazon EKS existant. Pour en déployer un, consultez [Création d’un cluster Amazon EKS](create-cluster.md).
+ 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 [Choisissez un type d’instance de nœud Amazon EC2 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.
+ Pour ajouter un groupe de nœuds gérés Windows, vous devez d’abord activer la prise en charge Windows pour votre cluster. Pour de plus amples informations, veuillez consulter [Déployer des nœuds Windows sur des clusters EKS](windows-support.md).
Vous pouvez créer un groupe de nœuds gérés avec l’une des options suivantes :
+ [`eksctl`](#eksctl_create_managed_nodegroup)
+ [AWS Management Console](#console_create_managed_nodegroup)
## `eksctl`
**Création d’un groupe de nœuds gérés avec 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`.
1. (Facultatif) Si la politique IAM gérée **AmazonEKS\$1CNI\$1Policy** est attachée à votre [rôle IAM de nœud Amazon EKS](create-node-role.md), nous recommandons de l’attribuer plutôt à un rôle IAM associé au compte de service `aws-node` Kubernetes. Pour de plus amples informations, veuillez consulter [Configuration du plug-in Amazon VPC CNI pour utiliser IRSA](cni-iam-role.md).
1. Créez un groupe de nœuds gérés avec ou sans modèle de lancement personnalisé. La spécification manuelle d'un modèle de lancement permet une plus grande personnalisation d'un groupe de nœuds. Par exemple, cela peut permettre de déployer une AMI personnalisée ou de fournir des arguments au script `boostrap.sh` dans une AMI optimisée par Amazon EKS. 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
```
Dans la commande suivante, remplacez *my-cluster* par le nom de votre cluster et remplacez *my-mng* par le nom de 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.
**Important**
Si vous n’utilisez pas de modèle de lancement personnalisé lors de la création initiale d’un groupe de nœuds gérés, n’en utilisez pas plus tard pour ce groupe de nœuds. Si vous n’avez pas spécifié de modèle de lancement personnalisé, le système génère automatiquement un modèle de lancement qu’il n’est pas recommandé de modifier manuellement. La modification manuelle de ce modèle de lancement généré automatiquement peut entraîner des erreurs.
**Sans modèle de lancement**
`eksctl` crée un modèle de lancement Amazon EC2 par défaut dans votre compte et déploie le groupe de nœuds à l'aide d'un modèle de lancement qu'il crée en fonction des options que vous spécifiez. Avant de spécifier une valeur pour `--node-type`, consultez [Choix du type d’instance Amazon EC2 optimal pour les nœuds](choosing-instance-type.md).
Remplacez *ami-family* par un mot clé autorisé. Pour plus d'informations, consultez [Définition de la famille AMI de nœuds](https://eksctl.io/usage/custom-ami-support/#setting-the-node-ami-family) dans la documentation `eksctl`. Remplacez *my-key* par le nom de votre paire de clés Amazon EC2 ou de votre clé publique. Cette clé est utilisée pour SSH dans vos nœuds après leur lancement.
**Note**
Pour Windows, cette commande n’active pas SSH. Elle associe votre key pair Amazon EC2 à l'instance et vous permet d'accéder à l'instance.
Si vous n’avez pas encore de paire de clés Amazon EC2, vous pouvez en créer une dans AWS Management Console. Pour plus d’informations Linux, consultez [Paires de clés Amazon EC2 et instances Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) dans le *Guide de l’utilisateur Amazon EC2*. Pour plus d’informations Windows, consultez [Paires de clés Amazon EC2 et instances Windows](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-key-pairs.html) dans le *Guide de l’utilisateur Amazon EC2*.
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).
Si vous souhaitez bloquer l’accès des pods à IMDS, ajoutez l’option `--disable-pod-imds` à la commande suivante.
```
eksctl create nodegroup \
--cluster my-cluster \
--region region-code \
--name my-mng \
--node-ami-family ami-family \
--node-type m5.large \
--nodes 3 \
--nodes-min 2 \
--nodes-max 4 \
--ssh-access \
--ssh-public-key my-key
```
Vos instances peuvent éventuellement attribuer un nombre significativement plus élevé d’adresses IP aux pods, attribuer des adresses IP aux pods à partir d’un bloc CIDR différent de celui de l’instance, et être déployées dans un cluster sans accès Internet. Pour plus d'informations, consultez [Attribution de davantage d’adresses IP aux nœuds Amazon EKS avec des préfixes](cni-increase-ip-addresses.md), [Déploiement de pods dans des sous-réseaux alternatifs avec réseau personnalisé](cni-custom-network.md) et [Déployer des clusters privés avec un accès Internet limité](private-clusters.md) pour connaître les options supplémentaires à ajouter à la commande précédente.
Les groupes de nœuds gérés calculent et appliquent une valeur unique pour le nombre maximum de pods qui peuvent fonctionner sur chaque nœud de votre groupe de nœuds, en fonction du type d’instance. Si vous créez un groupe de nœuds avec différents types d’instances, la plus petite valeur calculée sur tous les types d’instances est appliquée comme nombre maximal de pods pouvant fonctionner sur chaque type d’instance du groupe de nœuds. Les groupes de nœuds gérés calculent cette valeur à l’aide du script référencé dans .
**Avec un modèle de lancement**
Le modèle de lancement doit déjà exister et satisfaire aux exigences précisées dans [Principes de configuration du modèle de lancement](launch-templates.md#launch-template-basics). 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).
Si vous souhaitez bloquer l’accès des pods à IMDS, spécifiez les paramètres nécessaires dans le modèle de lancement.
1. Copiez les contenus suivants sur votre appareil. Remplacez les valeurs d'exemple, puis exécutez la commande modifiée pour créer le `eks-nodegroup.yaml` fichier. Plusieurs paramètres que vous spécifiez lors d'un déploiement sans modèle de lancement sont déplacés dans le modèle de lancement. Si vous ne spécifiez pas de `version`, la version par défaut du modèle est utilisée.
```
cat >eks-nodegroup.yaml <
**Création d’un groupe de nœuds gérés à l’aide de la AWS Management Console **
1. Attendez que le statut de votre cluster s'affiche soit `ACTIVE`. Vous ne pouvez pas créer un groupe de nœuds gérés pour un cluster qui n’est pas déjà `ACTIVE`.
1. Ouvrez la [console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Choisissez le nom du cluster dans lequel vous souhaitez créer un groupe de nœuds gérés.
1. Sélectionner l'onglet **Calcul**.
1. Choisissez **Ajouter un groupe de nœuds**.
1. Sur la page **Configurer un groupe de nœuds**, définissez les paramètres en conséquence, puis choisissez **Next (Suivant)**.
+ **Nom** : saisissez un nom unique pour votre groupe de nœuds gérés. 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.
+ **Rôle IAM de nœud** : choisissez le rôle d'instance de nœud à utiliser avec votre groupe de nœuds. Pour de plus amples informations, veuillez consulter [Rôle IAM de nœud Amazon EKS](create-node-role.md).
**Important**
Vous ne pouvez pas utiliser le même rôle que celui utilisé pour créer des clusters.
Nous vous recommandons d’utiliser un rôle qui n’est pas actuellement utilisé par un groupe de nœuds autogérés. Sinon, vous prévoyez de l'utiliser avec un nouveau groupe de nœuds autogérés. Pour de plus amples informations, veuillez consulter [Supprimer un groupe de nœuds gérés de votre cluster](delete-managed-node-group.md).
+ **Utiliser le modèle de lancement** : (facultatif) choisissez si vous souhaitez utiliser un modèle de lancement existant. Sélectionnez un **Nom de modèle de lancement**. Sélectionnez ensuite une **Version du modèle de lancement**. Si vous ne sélectionnez pas de version, Amazon EKS utilise la version par défaut du modèle. Les modèles de lancement permettent de personnaliser davantage votre groupe de nœuds, par exemple en vous permettant de déployer une AMI personnalisée, d’attribuer un nombre nettement plus élevé d’adresses IP aux pods, d’attribuer aux pods des adresses IP provenant d’un bloc CIDR différent de celui de l’instance et de déployer des nœuds dans un cluster sans accès Internet sortant. Pour plus d’informations, consultez [Attribution de davantage d’adresses IP aux nœuds Amazon EKS avec des préfixes](cni-increase-ip-addresses.md), [Déploiement de pods dans des sous-réseaux alternatifs avec réseau personnalisé](cni-custom-network.md) et [Déployer des clusters privés avec un accès Internet limité](private-clusters.md).
Le modèle de lancement doit satisfaire aux exigences présentées dans [Personnalisation des nœuds gérés avec des modèles de lancement](launch-templates.md). Si vous n’utilisez pas votre propre modèle de lancement, l’API Amazon EKS crée un modèle de lancement Amazon EC2 par défaut dans votre compte et déploie le groupe de nœuds en utilisant ce modèle par défaut.
Si vous implémentez [des rôles IAM pour les comptes de service](iam-roles-for-service-accounts.md), si vous attribuez les autorisations nécessaires directement à chaque pod nécessitant un accès aux AWS services, et si aucun pod de votre cluster n'a besoin d'accéder à IMDS pour d'autres raisons, telles que la récupération de la AWS région actuelle, vous pouvez également désactiver l'accès à IMDS pour les pods qui n'utilisent pas le réseau hôte dans un modèle de lancement. 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).
+ **Labels Kubernetes** : (facultatif) vous pouvez choisir d'appliquer des labels Kubernetes aux nœuds de votre groupe de nœuds gérés.
+ **Rejets Kubernetes** : (facultatif) vous pouvez choisir d’appliquer des rejets Kubernetes aux nœuds de votre groupe de nœuds gérés. Les options disponibles dans le menu **Effet** sont ` NoSchedule `, ` NoExecute `, et ` PreferNoSchedule `. Pour de plus amples informations, veuillez consulter [Recette : empêcher la planification de pods sur des nœuds spécifiques](node-taints-managed-node-groups.md).
+ **Identifications** : (facultatif) vous pouvez choisir d'identifier votre groupe de nœuds gérés Amazon EKS. Ces balises ne se propagent pas aux autres ressources du groupe de nœuds, comme les groupes Auto Scaling ou les instances. Pour de plus amples informations, veuillez consulter [Organiser les ressources Amazon EKS à l’aide de balises](eks-using-tags.md).
1. Sur la page **Définir la configuration de calcul et de mise à l'échelle**, définissez les paramètres en conséquence, puis choisissez **Next (Suivant)**.
+ **Type d’AMI** : sélectionnez un type d’AMI. Si vous déployez des instances Arm, assurez-vous de prendre en compte les points à prendre en compte dans [Arm Amazon Linux optimisé pour Amazon EKS AMIs](eks-optimized-ami.md#arm-ami) avant le déploiement.
Si vous avez spécifié un modèle de lancement à l’étape précédente et que vous y avez indiqué une AMI, vous ne pouvez pas sélectionner une autre valeur. La valeur du modèle s'affiche. L’AMI spécifiée dans le modèle doit satisfaire aux exigences décrites dans [Spécification d’une AMI](launch-templates.md#launch-template-custom-ami).
+ **Type de capacité** : sélectionnez un type de capacité. Pour plus d'informations sur le choix d'un type de capacité, consultez [Types de capacité des groupes de nœuds gérés](managed-node-groups.md#managed-node-group-capacity-types). Vous ne pouvez pas combiner différents types de capacités au sein d’un même groupe de nœuds. Si vous souhaitez utiliser les deux types de capacités, créez des groupes de nœuds distincts, chacun avec son propre type de capacité et d'instance. Consultez la section [Réserver GPUs pour les groupes de nœuds gérés](https://docs.aws.amazon.com/eks/latest/userguide/capacity-blocks-mng.html) pour obtenir des informations sur le provisionnement et le dimensionnement des nœuds de travail accélérés par GPU.
+ **Types d'instance** : par défaut, un ou plusieurs types d'instances sont spécifiés. Pour supprimer un type d'instance par défaut, sélectionnez la croix (`X`) sur le côté droit du type d'instance. Choisissez les types d'instances à utiliser dans votre groupe de nœuds gérés. Pour de plus amples informations, veuillez consulter [Choix du type d’instance Amazon EC2 optimal pour les nœuds](choosing-instance-type.md).
La console affiche un ensemble de types d'instances couramment utilisés. Si vous devez créer un groupe de nœuds gérés avec un type d'instance qui n'est pas affiché`eksctl`, utilisez la AWS CLI ou un SDK pour créer le groupe de nœuds. AWS CloudFormation Si vous avez spécifié un modèle de lancement à l’étape précédente, vous ne pouvez pas sélectionner une valeur, car le type d’instance doit être spécifié dans le modèle de lancement. La valeur du modèle de lancement s'affiche. Si vous avez sélectionné **Spot** pour le **type de capacité**, nous vous recommandons de spécifier plusieurs types d'instances pour améliorer la disponibilité.
+ **Taille du disque** : saisissez la taille du disque (en Gio) à utiliser pour le volume racine du nœud.
Si vous avez spécifié un modèle de lancement à la page précédente, vous ne pouvez pas sélectionner une valeur, car elle doit être spécifiée dans le modèle de lancement.
+ **Taille souhaitée** : spécifiez le nombre actuel de nœuds que le groupe de nœuds gérés doit conserver au lancement.
**Note**
Amazon EKS n’augmente ni ne réduit pas automatiquement votre groupe de nœuds. Cependant, vous pouvez configurer l’outil Cluster Autoscaler de Kubernetes pour effectuer cette mise à l’échelle. Pour plus d'informations, consultez [Cluster Autoscaler activé. AWS](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md)
+ **Taille minimale** : spécifiez le nombre minimal de nœuds vers lequel le groupe de nœuds gérés peut être mis à l'échelle.
+ **Taille maximale** : spécifiez le nombre maximal de nœuds vers lequel le groupe de nœuds gérés peut être mis à niveau.
+ **Configuration des mises à jour du groupe** : (facultatif) vous pouvez sélectionner le nombre ou le pourcentage de nœuds à mettre à jour en parallèle. Ces nœuds seront indisponibles pendant la mise à jour. Pour **Maximum non disponible**, sélectionnez l'une des options suivantes et spécifiez une **valeur** :
+ **Nombre** : sélectionnez et spécifiez le nombre de nœuds de votre groupe de nœuds pouvant être mis à jour en parallèle.
+ **Pourcentage** : sélectionnez et spécifiez le pourcentage de nœuds de votre groupe de nœuds pouvant être mis à jour en parallèle. Cela est pratique si votre groupe de nœuds contient de nombreux nœuds.
+ **Configuration de la réparation automatique des nœuds** : (facultatif) Si vous cochez la case **Activer la réparation automatique des nœuds**, Amazon EKS remplacera automatiquement les nœuds lorsque des problèmes seront détectés. Pour de plus amples informations, veuillez consulter [Détectez les problèmes de santé des nœuds et activez la réparation automatique des nœuds](node-health.md).
1. Sur la page **Spécifier les détails**, définissez les paramètres en conséquence, puis choisissez **Next (Suivant)**.
+ **Sous-réseaux** : choisissez les sous-réseaux dans lesquels vous souhaitez lancer vos nœuds gérés.
**Important**
Si vous exécutez une application avec état sur plusieurs zones de disponibilité, prise en charge par des volumes Amazon EBS et utilisant l’outil [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) de Kubernetes, vous devez configurer plusieurs groupes de nœuds, chacun limité à une seule zone de disponibilité. En outre, vous devez activer la fonction `--balance-similar-node-groups`.
**Important**
Si vous choisissez un sous-réseau public et que seul le point de terminaison du serveur d'API publique est activé, le paramètre `MapPublicIPOnLaunch` du sous-réseau doit avoir la valeur `true` pour que les instances rejoignent un cluster. Si le sous-réseau a été créé à l'aide `eksctl` des [AWS CloudFormation modèles vendus par Amazon EKS](creating-a-vpc.md) le 26 mars 2020 ou après cette date, ce paramètre est déjà défini sur. `true` Si les sous-réseaux ont été créés avec les AWS CloudFormation modèles `eksctl` ou avant le 26 mars 2020, vous devez modifier le paramètre manuellement. Pour plus d'informations, 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 vous utilisez un modèle de lancement et spécifiez plusieurs interfaces réseau, Amazon EC2 n’attribuera pas automatiquement d’adresse `IPv4` publique, même si `MapPublicIpOnLaunch` est défini sur `true`. Pour que les nœuds puissent rejoindre le cluster dans ce scénario, vous devez soit activer le point de terminaison privé du serveur d’API du cluster, soit lancer les nœuds dans un sous-réseau privé avec un accès Internet sortant via une méthode alternative, comme une passerelle NAT. Pour plus d’informations, consultez [Adressage IP des instances Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html) dans le *Guide de l’utilisateur Amazon EC2*.
+ **Configurez l'accès SSH aux nœuds** (facultatif). L'activation de SSH vous permet de vous connecter à vos instances et de recueillir des informations de diagnostic en cas de problème. Nous vous recommandons vivement d'activer l'accès à distance lorsque vous créez un groupe de nœuds. Vous ne pouvez pas activer l’accès à distance après la création du groupe de nœuds.
Si vous avez choisi d’utiliser un modèle de lancement, cette option n’est pas affichée. Pour autoriser l'accès à distance pour vos noeuds, spécifiez une paire de clés dans le modèle de lancement et assurez-vous que le port approprié est ouvert aux nœuds des groupes de sécurité que vous spécifiez dans le modèle de lancement. Pour de plus amples informations, veuillez consulter [Utilisation des groupes de sécurité](launch-templates.md#launch-template-security-groups).
**Note**
Pour Windows, cette commande n’active pas SSH. Elle associe votre key pair Amazon EC2 à l'instance et vous permet d’accéder à l’instance.
+ Pour **Paire de clés SSH** (facultatif), choisissez une clé SSH Amazon EC2 à utiliser. Pour plus d’informations Linux, consultez [Paires de clés Amazon EC2 et instances Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) dans le *Guide de l’utilisateur Amazon EC2*. Pour plus d’informations Windows, consultez [Paires de clés Amazon EC2 et instances Windows](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-key-pairs.html) dans le *Guide de l’utilisateur Amazon EC2*. Si vous avez choisi d’utiliser un modèle de lancement, vous ne pouvez pas en sélectionner un. Lorsqu'une clé SSH Amazon EC2 est fournie à des groupes de nœuds utilisant Bottlerocket AMIs, le conteneur administratif est également activé. Pour plus d'informations, consultez [Conteneur d'administration](https://github.com/bottlerocket-os/bottlerocket#admin-container) sur GitHub.
+ Pour **Autoriser l'accès à distance SSH depuis**, si vous souhaitez limiter l'accès à des instances spécifiques, sélectionnez les groupes de sécurité associés à ces instances. Si vous ne sélectionnez pas de groupes de sécurité spécifiques, alors l’accès SSH est autorisé depuis n’importe où sur Internet (`0.0.0.0/0`).
1. Sur la page **Review and create (Vérifier et créer)**, vérifiez la configuration de votre groupe de nœuds gérés et choisissez **Create (Créer)**.
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. Observez le statut de vos nœuds et attendez qu'ils obtiennent le statut `Ready`.
```
kubectl get nodes --watch
```
1. (Nœuds GPU uniquement) Si vous avez choisi un type d'instance GPU et une 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) 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
```
## Installation des modules complémentaires Kubernetes
Maintenant que vous disposez d’un cluster Amazon EKS opérationnel avec des nœuds, vous pouvez commencer à installer des modules complémentaires Kubernetes et à déployer des applications sur votre cluster. Les rubriques suivantes de la documentation vous aideront à étendre les fonctionnalités de votre cluster.
+ Le [principal IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) qui a créé le cluster est le seul principal qui peut effectuer des appels vers le serveur API Kubernetes avec `kubectl` ou le AWS Management Console. Si vous souhaitez que d'autres principaux IAM aient accès à votre cluster, vous devez les ajouter. Pour plus d’informations, consultez [Accorder aux utilisateurs et aux rôles IAM l'accès à Kubernetes APIs](grant-k8s-access.md) et [Autorisations requises](view-kubernetes-resources.md#view-kubernetes-resources-permissions).
+ 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).
+ Configurez l’outil [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) de Kubernetes pour ajuster automatiquement le nombre de nœuds dans vos groupes de nœuds.
+ Déployez un [exemple d'application](sample-deployment.md) sur votre cluster.
+ [Organisez et surveillez les ressources du cluster](eks-managing.md) à l’aide d’outils importants pour gérer votre cluster.
# Mettre à jour un groupe de nœuds gérés pour votre cluster
Lorsque vous lancez une mise à jour d’un groupe de nœuds gérés, Amazon EKS met automatiquement à jour vos nœuds pour vous, en suivant les étapes décrites dans la section [Comprendre chaque phase des mises à jour des nœuds](managed-node-update-behavior.md). Si vous utilisez une AMI optimisée pour Amazon EKS, Amazon EKS applique automatiquement les derniers correctifs de sécurité et les dernières mises à jour du système d’exploitation à vos nœuds dans le cadre de la dernière version publiée de l’AMI.
Il existe plusieurs scénarios dans lesquels il est utile de mettre à jour la version ou la configuration de votre groupe de nœuds gérés Amazon EKS :
+ Vous avez mis à jour la version de Kubernetes de votre cluster Amazon EKS et vous souhaitez mettre à jour vos nœuds pour utiliser la même version de Kubernetes.
+ Une nouvelle version d'AMI est disponible pour votre groupe de nœuds gérés. Pour plus d'informations sur les versions d'AMI, consultez ces sections :
+ [Récupérer les informations sur la version Amazon Linux AMI](eks-linux-ami-versions.md)
+ [Créez des nœuds avec Bottlerocket optimisé AMIs](eks-optimized-ami-bottlerocket.md)
+ [Récupérez les informations relatives à la version des AMI Windows](eks-ami-versions-windows.md)
+ Vous souhaitez ajuster le nombre minimum, maximum ou souhaité d'instances dans votre groupe de nœuds gérés.
+ Vous voulez ajouter ou supprimer les labels Kubernetes des instances de votre groupe de nœuds gérés.
+ Vous souhaitez ajouter ou supprimer des AWS balises dans votre groupe de nœuds gérés.
+ Vous devez déployer une nouvelle version d'un modèle de lancement avec des modifications de configuration, telles qu'une AMI personnalisée mise à jour.
+ Vous avez déployé une version `1.9.0` ou une version ultérieure du module complémentaire Amazon VPC CNI, activé le module complémentaire pour la délégation de préfixes et souhaitez que les nouvelles instances de AWS Nitro System dans un groupe de nœuds prennent en charge un nombre considérablement accru de pods. Pour de plus amples informations, veuillez consulter [Attribution de davantage d’adresses IP aux nœuds Amazon EKS avec des préfixes](cni-increase-ip-addresses.md).
+ Vous avez activé la délégation de préfixes IP pour les nœuds Windows et vous souhaitez que les nouvelles instances AWS Nitro System d'un groupe de nœuds prennent en charge un nombre considérablement accru de pods. Pour de plus amples informations, veuillez consulter [Attribution de davantage d’adresses IP aux nœuds Amazon EKS avec des préfixes](cni-increase-ip-addresses.md).
S’il existe une version AMI plus récente pour la version Kubernetes de votre groupe de nœuds gérés, vous pouvez mettre à jour la version de votre groupe de nœuds afin d’utiliser la version AMI plus récente. De même, si votre cluster exécute une version de Kubernetes plus récente que celle de votre groupe de nœuds, vous pouvez mettre à jour le groupe de nœuds afin d’utiliser la dernière version AMI pour correspondre à la version Kubernetes de votre cluster.
Lorsqu’un nœud d’un groupe de nœuds gérés est résilié en raison d’une opération de mise à l’échelle ou d’une mise à jour, les pods de ce nœud sont d’abord vidés. Pour de plus amples informations, veuillez consulter [Comprendre chaque phase des mises à jour des nœuds](managed-node-update-behavior.md).
## Mise à jour d'une version de groupe de nœuds
Vous pouvez mettre à jour la version d’un groupe de nœuds à l’aide de l’une des méthodes suivantes :
+ [`eksctl`](#eksctl_update_managed_nodegroup)
+ [AWS Management Console](#console_update_managed_nodegroup)
La version vers laquelle vous effectuez la mise à jour ne peut pas être supérieure à la version du plan de contrôle.
## `eksctl`
**Mettre à jour un groupe de nœuds gérés à l’aide de `eksctl` **
Mettez à jour un groupe de nœuds gérés vers la dernière version AMI de la même version Kubernetes actuellement déployée sur les nœuds à l’aide de la commande suivante. Remplacez chaque *example value* par vos propres valeurs.
```
eksctl upgrade nodegroup \
--name=node-group-name \
--cluster=my-cluster \
--region=region-code
```
**Note**
Si vous mettez à niveau un groupe de nœuds déployé avec un modèle de lancement vers une nouvelle version du modèle de lancement, ajoutez `--launch-template-version version-number ` à la commande précédente. Le modèle de lancement doit répondre aux exigences décrites dans [Personnaliser les nœuds gérés avec des modèles de lancement](launch-templates.md). Si le modèle de lancement inclut une AMI personnalisée, celle-ci doit répondre aux exigences décrites dans [Spécifier une AMI](launch-templates.md#launch-template-custom-ami). Lorsque vous mettez à niveau votre groupe de nœuds vers une version plus récente de votre modèle de lancement, chaque nœud est recyclé pour correspondre à la nouvelle configuration de la version du modèle de lancement spécifiée.
Il n’est pas possible de mettre à niveau directement un groupe de nœuds déployé sans modèle de lancement vers une nouvelle version du modèle de lancement. À la place, vous devez déployer un nouveau groupe de nœuds en utilisant le modèle de lancement pour mettre à jour le groupe de nœuds vers une nouvelle version du modèle de lancement.
Vous pouvez mettre à niveau un groupe de nœuds vers la même version que la version Kubernetes du plan de contrôle. Par exemple, si vous disposez d’un cluster exécutant Kubernetes `1.35`, vous pouvez mettre à niveau les nœuds exécutant actuellement Kubernetes `1.34` vers la version `1.35` à l’aide de la commande suivante.
```
eksctl upgrade nodegroup \
--name=node-group-name \
--cluster=my-cluster \
--region=region-code \
--kubernetes-version=1.35
```
## AWS Management Console
**Mettre à jour un groupe de nœuds gérés à l’aide de la AWS Management Console **
1. Ouvrez la [console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Choisissez le cluster qui contient le groupe de nœuds à mettre à jour.
1. Si une mise à jour est disponible pour au moins un groupe de nœuds, une boîte de dialogue apparaît en haut de la page pour vous en informer. Si vous sélectionnez l’onglet **Calcul**, vous verrez **Mettre à jour maintenant** dans la colonne **Version de l’AMI** du tableau **Groupes de nœuds** pour le groupe de nœuds qui dispose d’une mise à jour disponible. Pour mettre à jour le groupe de nœuds, sélectionnez **Update now** (Mettre à jour maintenant).
Vous ne verrez pas de notification pour les groupes de nœuds qui ont été déployés avec une AMI personnalisée. Si vos nœuds sont déployés avec une AMI personnalisée, effectuez les étapes suivantes pour déployer une nouvelle AMI personnalisée mise à jour.
1. Créez une version de votre AMI.
1. Créez une version de modèle de lancement avec le nouvel ID d'AMI.
1. Mettez à niveau les nœuds vers la nouvelle version du modèle de lancement.
1. Dans la boîte de dialogue **Update node group version** (Mettre à jour la version du groupe de nœuds), activez ou désactivez les options suivantes :
+ **Update node group version** (Mettre à jour la version du groupe de nœuds) : cette option n'est pas disponible si vous avez déployé une AMI personnalisée ou que votre AMI optimisée pour Amazon EKS correspond actuellement à la dernière version de votre cluster.
+ **Change launch template version** (Modifier la version du modèle de lancement) : cette option n'est pas disponible si le groupe de nœuds est déployé sans modèle de lancement personnalisé. Vous pouvez uniquement mettre à jour la version du modèle de lancement pour un groupe de nœuds qui a été déployé avec un modèle de lancement personnalisé. Sélectionnez la **Version du modèle de lancement** vers laquelle vous souhaitez mettre à jour le groupe de nœuds. Si votre groupe de nœuds est configuré avec une AMI personnalisée, la version que vous sélectionnez doit également spécifier une AMI. Lorsque vous passez à une version plus récente de votre modèle de lancement, chaque nœud est recyclé pour correspondre à la nouvelle configuration de la version du modèle de lancement spécifiée.
1. Pour **Update strategy** (Politique de mise à jour), sélectionnez l'une des options suivantes :
+ **Mise à jour propagée** : cette option respecte les budgets de perturbation des pods pour votre cluster. Les mises à jour échouent s’il existe un problème de budget de perturbation des pods qui empêche Amazon EKS de vider correctement les pods qui s’exécutent sur ce groupe de nœuds.
+ **Forcer la mise à jour** : cette option ne respecte pas les budgets de perturbation des pods. Les mises à jour ont lieu indépendamment des problèmes de budget de perturbation des pods en forçant le redémarrage des nœuds.
1. Choisissez **Mettre à jour**.
## Modification de la configuration d'un groupe de nœuds
Vous pouvez modifier une partie de la configuration d'un groupe de nœuds gérés.
1. Ouvrez la [console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Choisissez le cluster qui contient le groupe de nœuds à modifier.
1. Sélectionnez l'onglet **Compute** (Calcul).
1. Sélectionnez le groupe de nœuds à modifier, puis choisissez **Edit** (Modifier).
1. (Facultatif) Sur la page **Edit node group** (Modifier le groupe de nœuds), effectuez les opérations suivantes :
1. Modifiez la **Node group scaling configuration** (Configuration de mise à l'échelle du groupe de nœuds).
+ **Taille souhaitée** : spécifiez le nombre actuel de nœuds que le groupe de nœuds gérés doit conserver au lancement.
+ **Taille minimale** : spécifiez le nombre minimal de nœuds vers lequel le groupe de nœuds gérés peut être mis à l'échelle.
+ **Taille maximale** : spécifiez le nombre maximal de nœuds vers lequel le groupe de nœuds gérés peut être mis à niveau. Pour connaître le nombre maximal de noeuds pris en charge dans un groupe de nœuds, consultez [Afficher et gérer les quotas de service Amazon EKS et Fargate](service-quotas.md).
1. (Facultatif) Ajoutez ou supprimez des **étiquettes Kubernetes** aux nœuds de votre groupe de nœuds. Les labels affichés ici sont uniquement ceux que vous avez appliqués avec Amazon EKS. D’autres étiquettes peuvent exister sur vos nœuds et ne pas être affichées ici.
1. (Facultatif) Ajoutez ou supprimez des **rejets Kubernetes** aux nœuds de votre groupe de nœuds. Les taints ajoutés peuvent avoir l'effet de ` NoSchedule `, ` NoExecute ` ou ` PreferNoSchedule `. Pour de plus amples informations, veuillez consulter [Recette : empêcher la planification de pods sur des nœuds spécifiques](node-taints-managed-node-groups.md).
1. (Facultatif) Ajoutez ou supprimez des **Tags** (Balises) de la ressource de votre groupe de nœuds. Ces identifications ne sont appliquées qu'au groupe de nœuds Amazon EKS. Ils ne se propagent pas à d’autres ressources, telles que les sous-réseaux ou les instances Amazon EC2 du groupe de nœuds.
1. (Facultatif) Modifiez la **Configuration des mises à jour du groupe**. Sélectionnez **Number (Nombre)** ou **Percentage (Pourcentage)**.
+ **Nombre** : sélectionnez et spécifiez le nombre de nœuds de votre groupe de nœuds pouvant être mis à jour en parallèle. Ces nœuds ne seront pas disponibles pendant la mise à jour.
+ **Pourcentage** : sélectionnez et spécifiez le pourcentage de nœuds de votre groupe de nœuds pouvant être mis à jour en parallèle. Ces nœuds ne seront pas disponibles pendant la mise à jour. Ceci est utile si vous avez beaucoup de nœuds dans votre groupe de nœuds.
1. Une fois vos modifications terminées, sélectionnez **Enregistrer les modifications**.
**Important**
Lors de la mise à jour de la configuration du groupe de nœuds, la modification du [https://docs.aws.amazon.com/eks/latest/APIReference/API_NodegroupScalingConfig.html](https://docs.aws.amazon.com/eks/latest/APIReference/API_NodegroupScalingConfig.html)ne respecte pas les budgets d'interruption du pod (PDBs). Contrairement au processus de [mise à jour des groupes de nœuds](managed-node-update-behavior.md) (qui draine les nœuds et les respecte PDBs pendant la phase de mise à niveau), la mise à jour de la configuration de dimensionnement entraîne la fermeture immédiate des nœuds via un appel de réduction automatique du groupe Auto Scaling (ASG). Cela se produit sans réfléchir PDBs, quelle que soit la taille de la cible à laquelle vous réduisez la taille. Cela signifie que lorsque vous réduisez le nombre `desiredSize` d'un groupe de nœuds géré par Amazon EKS, les pods sont expulsés dès que les nœuds sont fermés, sans en honorer aucun. PDBs
# Comprendre chaque phase des mises à jour des nœuds
La stratégie de mise à jour des composants master d'Amazon EKS comporte quatre phases différentes décrites dans les sections suivantes.
## Phase de configuration
La phase de configuration comporte les étapes suivantes :
1. Une nouvelle version du modèle de lancement Amazon EC2 est créée pour le groupe Auto Scaling associé à votre groupe de nœuds. La nouvelle version du modèle de lancement utilise l'AMI cible ou une version personnalisée du modèle de lancement pour la mise à jour.
1. Le groupe Auto Scaling est mis à jour pour utiliser la dernière version du modèle de lancement.
1. La quantité maximale de nœuds à mettre à niveau en parallèle est déterminée à l'aide de la propriété `updateConfig` pour le groupe de nœuds. Le maximum indisponible a un quota de 100 nœuds. La valeur par défaut est de un nœud. Pour plus d’informations, consultez la propriété [updateConfig](https://docs.aws.amazon.com/eks/latest/APIReference/API_UpdateNodegroupConfig.html#API_UpdateNodegroupConfig_RequestSyntax) dans la *référence API Amazon EKS*.
## Phase d'augmentation d'échelle
Lors de la mise à niveau des nœuds d'un groupe de nœuds gérés, les nœuds mis à niveau sont lancés dans la même zone de disponibilité que ceux qui sont mis à niveau. Pour garantir ce placement, nous utilisons le rééquilibrage de la zone de disponibilité d’Amazon EC2. Pour plus d'informations, consultez [Rééquilibrage de la zone de disponibilité](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#AutoScalingBehavior.InstanceUsage) dans le *Guide de l'utilisateur Amazon EC2 Auto Scaling*. Pour répondre à cette exigence, il est possible que nous lancions jusqu’à deux instances par zone de disponibilité dans votre groupe de nœuds gérés.
La phase d'augmentation d'échelle comporte les étapes suivantes :
1. Il augmente la taille maximale et la taille souhaitée du groupe Auto Scaling en fonction de la plus grande des deux valeurs suivantes :
+ Jusqu’à deux fois le nombre de zones de disponibilité dans lesquelles le groupe Auto Scaling est déployé.
+ Le maximum indisponible de la mise à niveau.
Par exemple, si votre groupe de nœuds a cinq zones de disponibilité et que `maxUnavailable` est égal à un, le processus de mise à niveau peut lancer un maximum de 10 nœuds. Cependant, lorsque `maxUnavailable` est égale à 20 (ou supérieure à 10), le processus lance 20 nouveaux nœuds.
1. Après la mise à l'échelle du groupe Auto Scaling, elle vérifie si les nœuds utilisant la dernière configuration sont présents dans le groupe de nœuds. Cette étape ne réussit que si elle répond à ces critères :
+ Au moins un nouveau nœud est lancé dans chaque zone de disponibilité où le nœud existe.
+ Chaque nouveau nœud doit être dans l'état `Ready`.
+ Les nouveaux nœuds doivent avoir des étiquettes Amazon EKS appliquées.
Il s'agit des étiquettes Amazon EKS appliquées sur les composants master d'un groupe de nœuds réguliers :
+ `eks.amazonaws.com/nodegroup-image=$amiName`
+ `eks.amazonaws.com/nodegroup=$nodeGroupName`
Il s'agit des étiquettes appliquées par Amazon EKS sur les composants master dans un modèle de lancement personnalisé ou un groupe de composants AMI :
+ `eks.amazonaws.com/nodegroup-image=$amiName`
+ `eks.amazonaws.com/nodegroup=$nodeGroupName`
+ `eks.amazonaws.com/sourceLaunchTemplateId=$launchTemplateId`
+ `eks.amazonaws.com/sourceLaunchTemplateVersion=$launchTemplateVersion`
1. Il marque les nœuds comme non planifiables afin d’éviter la planification de nouveaux pods. Il étiquette également les nœuds avec `node.kubernetes.io/exclude-from-external-load-balancers=true` afin de supprimer les anciens nœuds des équilibreurs de charge avant de les terminer.
Les raisons suivantes sont connues pour provoquer une erreur `NodeCreationFailure` dans cette phase :
**Capacité insuffisante dans la zone de disponibilité**
Il est possible que la zone de disponibilité n'ait pas la capacité des types d'instance demandés. Il est recommandé de configurer plusieurs types d’instances lors de la création d’un groupe de nœuds gérés.
**Limites d’instance EC2 sur votre compte**
Vous pouvez être amené à augmenter le nombre d'instances Amazon EC2 que votre compte peut exécuter simultanément en utilisant Service Quotas. Pour plus d'informations, consultez [EC2 Service Quotas](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html) dans le *Guide de l'utilisateur Amazon Elastic Compute Cloud pour les instances Linux*.
**Données utilisateur personnalisées**
Les données utilisateur personnalisées peuvent parfois interrompre le processus d'amorçage. Ce scénario peut conduire à ce que le `kubelet` ne démarre pas sur le nœud ou que les nœuds n'obtiennent pas les étiquettes Amazon EKS attendues. Pour de plus amples informations, consultez [Spécification d'une AMI](launch-templates.md#launch-template-custom-ami).
**Toute modification qui rend un nœud défectueux ou pas prêt**
La pression du disque sur le nœud, la pression de la mémoire et des conditions similaires peuvent empêcher un nœud de passer à l'état `Ready`.
**Chaque nœud démarre le plus rapidement en 15 minutes**
Si un nœud prend plus de 15 minutes pour démarrer et rejoindre le cluster, cela entraînera l’expiration de la mise à niveau. Il s’agit de la durée totale nécessaire au démarrage d’un nouveau nœud, mesurée à partir du moment où un nouveau nœud est requis jusqu’à son intégration au cluster. Lors de la mise à niveau d’un groupe de nœuds gérés, le compteur de temps démarre dès que la taille du groupe Auto Scaling augmente.
## Phase de mise à niveau
La phase de mise à niveau se déroule de deux manières différentes, selon la *stratégie de mise à jour*. Il existe deux stratégies de mise à jour : **par défaut** et **minimale**.
Nous vous recommandons d’utiliser la stratégie par défaut. Il crée de nouveaux nœuds avant de mettre fin aux anciens, afin que la capacité disponible soit maintenue pendant la phase de mise à niveau. Cette stratégie minimale est utile lorsque les ressources ou les coûts sont limités, par exemple avec des accélérateurs matériels tels que des GPU. Il met fin aux anciens nœuds avant d’en créer de nouveaux, afin que la capacité totale ne dépasse jamais la quantité que vous avez configurée.
La stratégie de mise à jour *par défaut* comprend les étapes suivantes :
1. Il augmente le nombre de nœuds (nombre souhaité) dans le groupe Auto Scaling, ce qui entraîne la création de nœuds supplémentaires par le groupe de nœuds.
1. Un nœud est sélectionné aléatoirement pour mise à niveau, jusqu'au maximum indisponible configuré pour le groupe de nœuds.
1. Il vide les pods du nœud. Si les pods ne quittent pas le nœud dans les 15 minutes et qu’il n’y a pas d’indicateur de force, la phase de mise à niveau échoue avec une erreur `PodEvictionFailure`. Pour ce scénario, vous pouvez appliquer l’indicateur de force avec la demande `update-nodegroup-version` de suppression des pods.
1. Il isole le nœud après chaque expulsion de pod et attend 60 secondes. Cela permet au contrôleur de services de ne pas envoyer de nouvelles requêtes à ce nœud et de le supprimer de sa liste de nœuds actifs.
1. Une demande d'arrêt est envoyée au groupe Auto Scaling pour le nœud isolé.
1. Les étapes de mise à niveau précédentes sont répétées jusqu'à ce que le groupe de nœuds ne comporte plus aucun nœud déployé avec la version antérieure du modèle de lancement.
La stratégie de mise à jour *minimale* comprend les étapes suivantes :
1. Il isole tous les nœuds du groupe de nœuds au début, afin que le contrôleur de service n’envoie aucune nouvelle requête à ces nœuds.
1. Un nœud est sélectionné aléatoirement pour mise à niveau, jusqu'au maximum indisponible configuré pour le groupe de nœuds.
1. Il vide les pods des nœuds sélectionnés. Si les pods ne quittent pas le nœud dans les 15 minutes et qu’il n’y a pas d’indicateur de force, la phase de mise à niveau échoue avec une erreur `PodEvictionFailure`. Pour ce scénario, vous pouvez appliquer l’indicateur de force avec la demande `update-nodegroup-version` de suppression des pods.
1. Une fois que chaque pod a été évincé et a attendu 60 secondes, il envoie une demande de résiliation au groupe Auto Scaling pour les nœuds sélectionnés. Le groupe Auto Scaling crée de nouveaux nœuds (en nombre égal à celui des nœuds sélectionnés) pour remplacer la capacité manquante.
1. Les étapes de mise à niveau précédentes sont répétées jusqu'à ce que le groupe de nœuds ne comporte plus aucun nœud déployé avec la version antérieure du modèle de lancement.
### Erreurs `PodEvictionFailure` lors de la phase de mise à niveau
Les raisons suivantes sont connues pour provoquer une erreur `PodEvictionFailure` dans cette phase :
**PDB agressif**
Un PDB agressif est défini sur le pod ou plusieurs PDB pointent vers le même pod.
**Déploiement tolérant tous les rejets**
Une fois que tous les pods ont été évacués, le nœud devrait être vide, car il a été [rejeté](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) lors des étapes précédentes. Toutefois, si le déploiement tolère toutes les rejets, il est plus probable que le nœud ne soit pas vide, ce qui entraîne l’échec de l’éviction du pod.
## Phase de réduction d'échelle
La phase de réduction d'échelle diminue la taille maximale et la taille souhaitée du groupe Auto Scaling d'une unité pour revenir aux valeurs avant le début de la mise à jour.
Si le flux de mise à jour détermine que le Cluster Autoscaler augmente le groupe de nœuds pendant la phase de réduction d'échelle du flux de travail, il se termine immédiatement sans ramener le groupe de nœuds à sa taille d'origine.
# Personnaliser les nœuds gérés à l’aide de modèles de lancement
Pour un niveau de personnalisation maximal, vous pouvez déployer des nœuds gérés avec votre propre modèle de lancement en suivant les étapes décrites sur cette page. L'utilisation d'un modèle de lancement permet des fonctionnalités telles que la fourniture d'arguments d'amorçage lors du déploiement d'un nœud (par exemple, des arguments [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) supplémentaires), l'attribution d'adresses IP aux pods à partir d'un bloc CIDR différent de l'adresse IP attribuée au nœud, le déploiement de votre propre AMI personnalisée sur les nœuds ou le déploiement de votre propre CNI personnalisé sur les nœuds.
Si vous fournissez votre propre modèle de lancement lors de la création en premier lieu d'un groupe de nœuds gérés, vous bénéficierez également d'une plus grande flexibilité par la suite. Pourvu que vous déployiez un groupe de nœuds gérés avec votre propre modèle de lancement, vous pouvez le mettre à jour de façon itérative avec une version différente du même modèle de lancement. Lorsque vous mettez à jour votre groupe de nœuds vers une version différente de votre modèle de lancement, tous les nœuds du groupe sont recyclés pour correspondre à la nouvelle configuration de la version spécifiée du modèle de lancement.
Les groupes de nœuds gérés sont toujours déployés avec un modèle de lancement à utiliser avec le groupe Amazon EC2 Auto Scaling. Si vous ne fournissez pas de modèle de lancement, l’API Amazon EKS en crée automatiquement un avec les valeurs par défaut de votre compte. Cependant, il est déconseillé de modifier les modèles de lancement générés automatiquement. De plus, les groupes de nœuds existants qui n’utilisent pas de modèle de lancement personnalisé ne peuvent pas être mis à jour directement. Vous devez plutôt créer un nouveau groupe de nœuds avec un modèle de lancement personnalisé à cet effet.
## Concepts de base de la configuration d'un modèle de lancement
Vous pouvez créer un modèle de lancement Amazon EC2 Auto Scaling à l'aide de AWS Management Console la AWS CLI ou d' AWS un SDK. Pour plus d'informations, consultez [Création d'un modèle de lancement pour un groupe Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-launch-template.html) dans le *Guide de l'utilisateur Amazon EC2 Auto Scaling*. Certains des paramètres d'un modèle de lancement sont similaires aux paramètres utilisés pour la configuration des nœuds gérés. Lors du déploiement ou de la mise à jour d'un groupe de nœuds avec un modèle de lancement, certains paramètres doivent être spécifiés soit dans la configuration du groupe de nœuds, soit dans le modèle de lancement. Veuillez ne pas spécifier un paramètre aux deux endroits. Si un paramètre existe là où il ne devrait pas, les opérations telles que la création ou la mise à jour d’un groupe de nœuds échoueront.
Le tableau suivant répertorie les paramètres interdits dans un modèle de lancement. Il répertorie également les paramètres similaires, s'il en existe, qui sont requis dans la configuration du groupe de nœuds géré. Les paramètres répertoriés sont les paramètres qui apparaissent dans la console. Ils peuvent avoir des noms similaires mais différents dans la AWS CLI et le SDK.
| Modèle de lancement – Interdit | Configuration d'un groupe de nœuds Amazon EKS |
| --- | --- |
| **Sous-réseau** sous **Interfaces réseau** (**Ajouter une interface réseau**) | **Sous-réseaux** sous **Configuration réseau du groupe de nœuds** sur la page **Spécifier le réseau** |
| **Profil d'instance IAM** sous **Détails avancés** | **Rôle IAM de nœud** sous **Configuration du groupe de nœuds** sur la page **Configurer le groupe de nœuds** |
| **Comportement d'arrêt** et **Arrêt – Comportement de mise en veille prolongée** sous **Détails avancés**. Conservez le paramètre par défaut **Ne pas inclure dans le modèle de lancement** dans le modèle de lancement pour les deux paramètres. | Pas d'équivalent. Amazon EKS doit contrôler le cycle de vie de l'instance et non pas le groupe Auto Scaling. |
Le tableau suivant répertorie les paramètres interdits dans une configuration de groupe de nœuds gérée. Il répertorie également les paramètres similaires, s'il en existe, qui sont requis dans un modèle de lancement. Les paramètres répertoriés sont les paramètres qui apparaissent dans la console. Ils peuvent porter des noms similaires dans la AWS CLI et le SDK.
| Configuration du groupe de nœuds Amazon EKS : Interdite | Modèle de lancement |
| --- | --- |
| (Seulement si vous avez spécifié une AMI personnalisée dans un modèle de lancement) **AMI type** (Type d'AMI) sous **Node Group compute configuration** (Configuration du calcul du groupe de nœuds) sur la page **Set compute and scaling configuration** (Définir la configuration de calcul et de mise à l'échelle) : la console affiche **Specified in launch template** (Spécifié dans le modèle de lancement) et l'ID d'AMI spécifié. Si **Images d’application et de système d’exploitation (Amazon Machine Image)** n’a pas été spécifié dans le modèle de lancement, vous pouvez sélectionner une AMI dans la configuration du groupe de nœuds. | **Images d'applications et de systèmes d'exploitation (Amazon Machine Image)** sous **Contenu du modèle de lancement** : vous devez spécifier un ID dans l'un des cas suivants : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/launch-templates.html) |
| **Taille du disque** sous **Configuration de calcul du groupe de nœuds** sur la page **Définir la configuration de calcul et de mise à l'échelle** : la console affiche **Spécifié dans le modèle de lancement**. | **Taille** sous **Stockage (volumes)** (**Ajouter un nouveau volume**). Vous devez le spécifier dans le modèle de lancement. |
| **Paire de clés SSH** sous **Configuration du groupe de nœuds** sur la page **Spécifier le réseau** : la console affiche la clé spécifiée dans le modèle de lancement ou **Non spécifié dans le modèle de lancement**. | **Nom de la paire de clés** sous **Paire de clés (connexion)**. |
| Vous ne pouvez pas spécifier de groupes de sécurité source autorisés à accéder à distance lorsque vous utilisez un modèle de lancement. | **Groupes de sécurité** sous **Paramètres réseau** pour l'instance ou **Groupes de sécurité** sous **Interfaces réseau** (**Ajouter une interface réseau**), mais pas les deux. Pour de plus amples informations, veuillez consulter [Utilisation des groupes de sécurité](#launch-template-security-groups). |
**Note**
Si vous déployez un groupe de nœuds à l'aide d'un modèle de lancement, spécifiez zéro ou un **type d'instance** sous **Contenu du modèle de lancement** dans un modèle de lancement. Vous pouvez également spécifier de 0 à 20 types d'instance sous **types d'instance** sur la page **Définir la configuration de calcul et de mise à l'échelle** dans la console. Vous pouvez également le faire à l'aide d'autres outils qui utilisent l'API Amazon EKS. Si vous spécifiez un type d’instance dans un modèle de lancement et que vous utilisez ce modèle pour déployer votre groupe de nœuds, vous ne pouvez spécifier aucun type d’instance dans la console ou à l’aide d’autres outils qui utilisent l’API Amazon EKS. Si vous ne spécifiez pas de type d’instance dans un modèle de lancement, dans la console ou à l’aide d’autres outils utilisant l’API Amazon EKS, le type d’instance `t3.medium` est utilisé. Si votre groupe de nœuds utilise le type de capacité Spot, nous vous recommandons de spécifier plusieurs types d'instance à l'aide de la console. Pour de plus amples informations, veuillez consulter [Types de capacité des groupes de nœuds gérés](managed-node-groups.md#managed-node-group-capacity-types).
Si les conteneurs que vous déployez dans le groupe de nœuds utilisent le service de métadonnées d'instance version 2, veillez à définir `2` comme **limite de saut de réponse des métadonnées** dans votre modèle de lancement. Pour plus d'informations, consultez [Métadonnées d'instance et données utilisateur](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html) dans le *Guide de l'utilisateur Amazon EC2*.
Les modèles de lancement ne prennent pas en charge la fonctionnalité `InstanceRequirements` qui permet une sélection flexible du type d’instance.
## Étiquetage des instances Amazon EC2
Vous pouvez utiliser le paramètre `TagSpecification` d'un modèle de lancement pour spécifier les identifications à appliquer aux instances Amazon EC2 dans votre groupe de nœuds. L'entité IAM qui appelle le `CreateNodegroup` ou `UpdateNodegroupVersion` APIs doit disposer des autorisations pour `ec2:RunInstances` et`ec2:CreateTags`, et les balises doivent être ajoutées au modèle de lancement.
## Utilisation des groupes de sécurité
Vous pouvez utiliser un modèle de lancement pour spécifier des [groupes de sécurité](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html) Amazon EC2 à appliquer aux instances de votre groupe de nœuds. Vous pouvez le faire soit dans le paramètre des groupes de sécurité au niveau de l'instance, soit dans le cadre des paramètres de configuration de l'interface réseau. Cependant, vous ne pouvez pas créer un modèle de lancement qui spécifie à la fois le niveau d’instance et les groupes de sécurité de l’interface réseau. Prenez en compte les conditions suivantes qui s'appliquent à l'utilisation de groupes de sécurité personnalisés avec des groupes de nœuds gérés :
+ Lorsque vous utilisez le AWS Management Console, Amazon EKS n'autorise que les modèles de lancement dotés d'une seule spécification d'interface réseau.
+ Par défaut, Amazon EKS applique le [groupe de sécurité](sec-group-reqs.md) du cluster aux instances de votre groupe de nœuds pour faciliter la communication entre les nœuds et le plan de contrôle. Si vous spécifiez des groupes de sécurité personnalisés dans le modèle de lancement à l’aide de l’une des options mentionnées précédemment, Amazon EKS n’ajoute pas le groupe de sécurité du cluster. Vous devez donc vous assurer que les règles d'entrée et de sortie de vos groupes de sécurité permettent la communication avec le point de terminaison de votre cluster. Si vos règles de groupe de sécurité sont incorrectes, les composants master ne peuvent pas rejoindre le cluster. Pour plus d'informations sur les règles de groupe de sécurité, consultez [Voir les exigences relatives aux groupes de sécurité Amazon EKS pour les clusters](sec-group-reqs.md).
+ Si vous avez besoin d'un accès SSH aux instances de votre groupe de nœuds, incluez un groupe de sécurité qui autorise cet accès.
## Données utilisateur Amazon EC2
Le modèle de lancement comprend une section pour les données utilisateur personnalisées. Vous pouvez définir les paramètres de configuration de votre groupe de nœuds dans cette section sans créer manuellement une personnalisation individuelle AMIs. Pour plus d'informations sur les paramètres disponibles pour Bottlerocket, consultez la section [Utilisation des données utilisateur](https://github.com/bottlerocket-os/bottlerocket#using-user-data) sur. GitHub
Vous pouvez fournir des données d'utilisateur Amazon EC2 dans votre modèle de lancement en utilisant `cloud-init` lors du lancement de vos instances. Pour plus d’informations, consultez la [documentation cloud-init](https://cloudinit.readthedocs.io/en/latest/index.html). Vos données utilisateur peuvent être utilisées pour effectuer des opérations de configuration courantes. Elles comprennent :
+ [Inclusion d'utilisateurs ou de groupes](https://cloudinit.readthedocs.io/en/latest/topics/examples.html#including-users-and-groups)
+ [Installations de packages](https://cloudinit.readthedocs.io/en/latest/topics/examples.html#install-arbitrary-packages)
Les données utilisateur Amazon EC2 figurant dans les modèles de lancement utilisés avec des groupes de nœuds gérés doivent être au format d'archive en [plusieurs parties MIME pour Amazon Linux AMIs et au format](https://cloudinit.readthedocs.io/en/latest/topics/format.html#mime-multi-part-archive) TOML pour Bottlerocket. AMIs En effet, vos données utilisateur sont fusionnées avec les données utilisateur d'Amazon EKS requises pour que les nœuds puissent rejoindre le cluster. Ne spécifiez aucune commande dans vos données utilisateur qui démarre ou modifie `kubelet`. Ceci est effectué dans le cadre des données utilisateur fusionnées par Amazon EKS. Certains paramètres `kubelet`, tels que la définition des étiquettes sur les nœuds, peuvent être configurés directement via l'API des groupes de nœuds gérés.
**Note**
Pour plus d'informations sur la personnalisation avancée de `kubelet`, y compris son démarrage manuel ou le passage de paramètres de configuration personnalisés, consultez [Spécification d'une AMI](#launch-template-custom-ami). Si un ID d’AMI personnalisé est spécifié dans un modèle de lancement, Amazon EKS ne fusionne pas les données utilisateur.
Les détails suivants fournissent plus d'informations sur la section des données utilisateur.
**Données utilisateur Amazon Linux 2**
Vous pouvez combiner plusieurs blocs de données utilisateur dans un seul fichier MIME multi-part. Par exemple, vous pouvez combiner un boothook cloud qui configure le démon Docker avec un script shell de données utilisateur qui installe un package personnalisé. Un fichier MIME multi-part est constitué des composants suivants :
+ La déclaration de type de contenu et de limite de partie : `Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="`
+ La déclaration de version MIME : `MIME-Version: 1.0`
+ Un ou plusieurs blocs de données qui contiennent les composants suivants :
+ La limite de début qui signale le début d'un bloc de données utilisateur : `--==MYBOUNDARY==`
+ La déclaration de type de contenu du bloc : `Content-Type: text/cloud-config; charset="us-ascii"`. Pour plus d'informations sur les types de contenus, consultez la [documentation sur Cloud-Init](https://cloudinit.readthedocs.io/en/latest/topics/format.html).
+ Le contenu des données utilisateur (par exemple, une liste de commandes shell ou de directives `cloud-init`).
+ La limite de fin qui signale la fin du fichier MIME multi-part : `--==MYBOUNDARY==--`
Voici un exemple de fichier MIME multi-part que vous pouvez utiliser pour créer le vôtre.
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="
--==MYBOUNDARY==
Content-Type: text/x-shellscript; charset="us-ascii"
#!/bin/bash
echo "Running custom user data script"
--==MYBOUNDARY==--
```
**Données utilisateur Amazon Linux 2023**
Amazon Linux 2023 (AL2023) introduit un nouveau processus d'initialisation des nœuds `nodeadm` qui utilise un schéma de configuration YAML. Si vous utilisez des groupes de nœuds autogérés ou une AMI avec un modèle de lancement, vous devez désormais fournir explicitement des métadonnées de cluster supplémentaires lors de la création d’un nouveau groupe de nœuds. Un [exemple](https://awslabs.github.io/amazon-eks-ami/nodeadm/) des paramètres minimum requis est présenté ci-dessous, où `apiServerEndpoint`, `certificateAuthority` et le service `cidr` sont désormais obligatoires :
```
---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: my-cluster
apiServerEndpoint: https://example.com
certificateAuthority: Y2VydGlmaWNhdGVBdXRob3JpdHk=
cidr: 10.100.0.0/16
```
Vous définirez généralement cette configuration dans vos données utilisateur, soit telle quelle, soit intégrée dans un document MIME multipart :
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="BOUNDARY"
--BOUNDARY
Content-Type: application/node.eks.aws
---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig spec: [...]
--BOUNDARY--
```
Dans AL2, les métadonnées de ces paramètres ont été découvertes à partir de l'appel d'`DescribeCluster`API Amazon EKS. Avec AL2023, ce comportement a changé car l'appel d'API supplémentaire risque d'être limité lors de la mise à l'échelle de nœuds à grande échelle. Cette modification ne vous affecte pas si vous utilisez des groupes de nœuds gérés sans modèle de lancement, ou si vous utilisez Karpenter. Pour plus d’informations sur `certificateAuthority` et le service `cidr`, consultez [https://docs.aws.amazon.com/eks/latest/APIReference/API_DescribeCluster.html](https://docs.aws.amazon.com/eks/latest/APIReference/API_DescribeCluster.html) dans la *Référence de l’API Amazon EKS*.
Voici un exemple complet de données AL2023 utilisateur qui combine un script shell pour personnaliser le nœud (comme l'installation de packages ou la pré-mise en cache des images de conteneur) avec la configuration requise. `nodeadm` Cet exemple présente des personnalisations courantes, notamment : \$1 L’installation de paquets système supplémentaires \$1 La mise en cache préalable des images de conteneur pour améliorer le temps de démarrage des pods \$1 La configuration du proxy HTTP \$1 La configuration des métriques `kubelet` pour l’étiquetage des nœuds
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="BOUNDARY"
--BOUNDARY
Content-Type: text/x-shellscript; charset="us-ascii"
#!/bin/bash
set -o errexit
set -o pipefail
set -o nounset
# Install additional packages
yum install -y htop jq iptables-services
# Pre-cache commonly used container images
nohup docker pull public.ecr.aws/eks-distro/kubernetes/pause:3.2 &
# Configure HTTP proxy if needed
cat > /etc/profile.d/http-proxy.sh << 'EOF'
export HTTP_PROXY="http://proxy.example.com:3128"
export HTTPS_PROXY="http://proxy.example.com:3128"
export NO_PROXY="localhost,127.0.0.1,169.254.169.254,.internal"
EOF
--BOUNDARY
Content-Type: application/node.eks.aws
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: my-cluster
apiServerEndpoint: https://example.com
certificateAuthority: Y2VydGlmaWNhdGVBdXRob3JpdHk=
cidr: 10.100.0.0/16
kubelet:
config:
clusterDNS:
- 10.100.0.10
flags:
- --node-labels=app=my-app,environment=production
--BOUNDARY--
```
**Données utilisateur Bottlerocket**
Bottlerocket structure les données utilisateur au format TOML. Vous pouvez fournir des données utilisateur qui seront fusionnées avec les données utilisateur fournies par Amazon EKS. Par exemple, vous pouvez fournir des paramètres `kubelet` supplémentaires.
```
[settings.kubernetes.system-reserved]
cpu = "10m"
memory = "100Mi"
ephemeral-storage= "1Gi"
```
Pour plus d'informations sur les paramètres pris en charge, consultez la [documentation Bottlerocket](https://github.com/bottlerocket-os/bottlerocket). Vous pouvez configurer des étiquettes de nœuds et des [rejets](node-taints-managed-node-groups.md) dans vos données utilisateur. Cependant, nous vous recommandons de les configurer plutôt dans votre groupe de nœuds. Amazon EKS applique ces configurations lorsque vous le faites.
Lorsque les données utilisateur sont fusionnées, la mise en forme n’est pas conservée, mais le contenu reste le même. La configuration que vous fournissez dans vos données utilisateur remplace tous les paramètres qui sont configurés par Amazon EKS. Ainsi, si vous définissez `settings.kubernetes.max-pods` ou `settings.kubernetes.cluster-dns-ip`, ces valeurs dans vos données utilisateur sont appliquées aux nœuds.
Amazon EKS ne prend pas en charge tous les TOML valides. Voici une liste des formats connus non pris en charge :
+ Guillemets dans les clés entre guillemets : `'quoted "value"' = "value"`
+ Guillemets échappés dans les valeurs : `str = "I’m a string. \"You can quote me\""`
+ Flottants et entiers mélangés : `numbers = [ 0.1, 0.2, 0.5, 1, 2, 5 ]`
+ Types mixtes dans les tableaux : `contributors = ["[foo@example.com](mailto:foo@example.com)", { name = "Baz", email = "[baz@example.com](mailto:baz@example.com)" }]`
+ En-têtes entre parenthèses avec clés entre guillemets : `[foo."bar.baz"]`
**Données utilisateur Windows**
Les données utilisateur Windows utilisent des PowerShell commandes. Lorsque vous créez un groupe de nœuds gérés, vos données utilisateur personnalisées sont combinées avec les données utilisateur gérées par Amazon EKS. Vos PowerShell commandes viennent en premier, suivies des commandes de gestion des données utilisateur, le tout dans une seule `` balise.
Lors de la création de groupes de nœuds Windows, Amazon EKS met à jour le `aws-auth` `ConfigMap` pour permettre aux nœuds Linux de rejoindre le cluster. Le service ne configure pas automatiquement les autorisations pour Windows AMIs. Si vous utilisez des nœuds Windows, vous devrez gérer l’accès via l’API d’entrée d’accès ou en mettant à jour directement le `aws-auth` `ConfigMap`. Pour de plus amples informations, veuillez consulter [Déployer des nœuds Windows sur des clusters EKS](windows-support.md).
Lorsque aucun ID d’AMI n’est spécifié dans le modèle de lancement, n’utilisez pas le script Windows Amazon EKS Bootstrap dans les données utilisateur pour configurer Amazon EKS.
Voici un exemple de données utilisateur.
```
Write-Host "Running custom user data script"
```
## Spécification d'une AMI
Si vous avez l'une des conditions suivantes, spécifiez un ID d'AMI dans le champ `ImageId` de votre modèle de lancement. Sélectionnez votre besoin d'informations supplémentaires.
### Fournissez des données utilisateur pour transmettre des arguments au `bootstrap.sh` fichier inclus dans une Linux/Bottlerocket AMI optimisée pour Amazon EKS
L'amorçage est un terme utilisé pour décrire l'ajout de commandes pouvant être exécutées au démarrage d'une instance. Par exemple, la mise en place initiale permet d’utiliser des arguments [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) supplémentaires. Vous pouvez transmettre les arguments au script `bootstrap.sh` en utilisant `eksctl` sans spécifier de modèle de lancement. Vous pouvez également le faire en spécifiant les informations dans la section des données utilisateur d'un modèle de lancement.
**eksctl sans spécifier de modèle de lancement**
Créez un fichier nommé *my-nodegroup.yaml* avec les contenus suivants. Remplacez chaque *example value* par vos propres valeurs. Les arguments `--apiserver-endpoint`, `--b64-cluster-ca` et `--dns-cluster-ip` sont facultatifs. Cependant, leur définition permet au script `bootstrap.sh` d'éviter de passer un appel `describeCluster`. Ceci est utile dans les configurations de clusters privés ou les clusters où vous effectuez fréquemment des opérations de mise à l’échelle et de réduction des nœuds. Pour plus d'informations sur le `bootstrap.sh` script, consultez le fichier [bootstrap.sh](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh) sur GitHub.
+ Le seul argument requis est le nom du cluster (*my-cluster*).
+ Pour récupérer un ID d’AMI optimisé pour `ami-1234567890abcdef0 `, consultez les sections suivantes :
+ [Récupérez l'AMI Amazon Linux recommandée IDs](retrieve-ami-id.md)
+ [Récupérez l'AMI Bottlerocket recommandée IDs](retrieve-ami-id-bottlerocket.md)
+ [Récupérez l'AMI Microsoft Windows recommandée IDs](retrieve-windows-ami-id.md)
+ Pour récupérer le *certificate-authority* de votre cluster, exécutez la commande suivante.
```
aws eks describe-cluster --query "cluster.certificateAuthority.data" --output text --name my-cluster --region region-code
```
+ Pour récupérer le *api-server-endpoint* de votre cluster, exécutez la commande suivante.
```
aws eks describe-cluster --query "cluster.endpoint" --output text --name my-cluster --region region-code
```
+ La valeur de `--dns-cluster-ip` est votre CIDR de service avec `.10` à la fin. Pour récupérer le *service-cidr* de votre cluster, exécutez la commande suivante. Par exemple, si la valeur renvoyée est `ipv4 10.100.0.0/16`, votre valeur est *10.100.0.10*.
```
aws eks describe-cluster --query "cluster.kubernetesNetworkConfig.serviceIpv4Cidr" --output text --name my-cluster --region region-code
```
+ Cet exemple fournit un argument `kubelet` supplémentaire pour définir une valeur `max-pods` personnalisée à l'aide du script `bootstrap.sh` inclus dans l'AMI optimisée pour Amazon EKS. 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 obtenir de l'aide sur la sélection de *my-max-pods-value*, consultez . Pour plus d'informations sur le mode `maxPods` de détermination lors de l'utilisation de groupes de nœuds gérés, consultez[Comment est déterminé MaxPods](choosing-instance-type.md#max-pods-precedence).
```
---
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: my-cluster
region: region-code
managedNodeGroups:
- name: my-nodegroup
ami: ami-1234567890abcdef0
instanceType: m5.large
privateNetworking: true
disableIMDSv1: true
labels: { x86-al2-specified-mng }
overrideBootstrapCommand: |
#!/bin/bash
/etc/eks/bootstrap.sh my-cluster \
--b64-cluster-ca certificate-authority \
--apiserver-endpoint api-server-endpoint \
--dns-cluster-ip service-cidr.10 \
--kubelet-extra-args '--max-pods=my-max-pods-value' \
--use-max-pods false
```
Pour chaque option de fichier `eksctl` `config` disponible, consultez [Schéma de fichier de configuration](https://eksctl.io/usage/schema/) dans la documentation `eksctl`. L'utilitaire `eksctl` crée toujours un modèle de lancement pour vous et remplit ses données utilisateur avec les données que vous fournissez dans le fichier `config`.
Créez un groupe de nœuds avec la commande suivante.
```
eksctl create nodegroup --config-file=my-nodegroup.yaml
```
**Données utilisateur dans un modèle de lancement**
Spécifiez les informations suivantes dans la section des données utilisateur de votre modèle de lancement. Remplacez chaque *example value* par vos propres valeurs. Les arguments `--apiserver-endpoint`, `--b64-cluster-ca` et `--dns-cluster-ip` sont facultatifs. Cependant, leur définition permet au script `bootstrap.sh` d'éviter de passer un appel `describeCluster`. Ceci est utile dans les configurations de clusters privés ou les clusters où vous effectuez fréquemment des opérations de mise à l’échelle et de réduction des nœuds. Pour plus d'informations sur le `bootstrap.sh` script, consultez le fichier [bootstrap.sh](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh) sur GitHub.
+ Le seul argument requis est le nom du cluster (*my-cluster*).
+ Pour récupérer le *certificate-authority* de votre cluster, exécutez la commande suivante.
```
aws eks describe-cluster --query "cluster.certificateAuthority.data" --output text --name my-cluster --region region-code
```
+ Pour récupérer le *api-server-endpoint* de votre cluster, exécutez la commande suivante.
```
aws eks describe-cluster --query "cluster.endpoint" --output text --name my-cluster --region region-code
```
+ La valeur de `--dns-cluster-ip` est votre CIDR de service avec `.10` à la fin. Pour récupérer le *service-cidr* de votre cluster, exécutez la commande suivante. Par exemple, si la valeur renvoyée est `ipv4 10.100.0.0/16`, votre valeur est *10.100.0.10*.
```
aws eks describe-cluster --query "cluster.kubernetesNetworkConfig.serviceIpv4Cidr" --output text --name my-cluster --region region-code
```
+ Cet exemple fournit un argument `kubelet` supplémentaire pour définir une valeur `max-pods` personnalisée à l'aide du script `bootstrap.sh` inclus dans l'AMI optimisée pour Amazon EKS. Pour obtenir de l'aide sur la sélection de *my-max-pods-value*, consultez . Pour plus d'informations sur le mode `maxPods` de détermination lors de l'utilisation de groupes de nœuds gérés, consultez[Comment est déterminé MaxPods](choosing-instance-type.md#max-pods-precedence).
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="
--==MYBOUNDARY==
Content-Type: text/x-shellscript; charset="us-ascii"
#!/bin/bash
set -ex
/etc/eks/bootstrap.sh my-cluster \
--b64-cluster-ca certificate-authority \
--apiserver-endpoint api-server-endpoint \
--dns-cluster-ip service-cidr.10 \
--kubelet-extra-args '--max-pods=my-max-pods-value' \
--use-max-pods false
--==MYBOUNDARY==--
```
### Fournissez des données utilisateur pour transmettre des arguments au fichier `Start-EKSBootstrap.ps1` inclus dans une AMI Windows optimisée pour Amazon EKS
L'amorçage est un terme utilisé pour décrire l'ajout de commandes pouvant être exécutées au démarrage d'une instance. Vous pouvez transmettre les arguments au script `Start-EKSBootstrap.ps1` en utilisant `eksctl` sans spécifier de modèle de lancement. Vous pouvez également le faire en spécifiant les informations dans la section des données utilisateur d'un modèle de lancement.
Si vous voulez spécifier un ID d’AMI Windows personnalisé, tenez compte des considérations suivantes :
+ Vous devez utiliser un modèle de lancement et fournir les commandes d'amorçage requises dans la section des données utilisateur. Pour récupérer l'ID Windows souhaité, vous pouvez utiliser le tableau de la section [Créer des nœuds avec Windows optimisé AMIs](eks-optimized-windows-ami.md).
+ Il existe plusieurs limites et conditions. Par exemple, vous devez ajouter des éléments `eks:kube-proxy-windows` à votre carte de configuration AWS IAM Authenticator. Pour de plus amples informations, veuillez consulter [Limites et conditions lors de la spécification d'un ID d'AMI](#mng-ami-id-conditions).
Spécifiez les informations suivantes dans la section des données utilisateur de votre modèle de lancement. Remplacez chaque *example value* par vos propres valeurs. Les arguments `-APIServerEndpoint`, `-Base64ClusterCA` et `-DNSClusterIP` sont facultatifs. Cependant, leur définition permet au script `Start-EKSBootstrap.ps1` d'éviter de passer un appel `describeCluster`.
+ Le seul argument requis est le nom du cluster (*my-cluster*).
+ Pour récupérer le *certificate-authority* de votre cluster, exécutez la commande suivante.
```
aws eks describe-cluster --query "cluster.certificateAuthority.data" --output text --name my-cluster --region region-code
```
+ Pour récupérer le *api-server-endpoint* de votre cluster, exécutez la commande suivante.
```
aws eks describe-cluster --query "cluster.endpoint" --output text --name my-cluster --region region-code
```
+ La valeur de `--dns-cluster-ip` est votre CIDR de service avec `.10` à la fin. Pour récupérer le *service-cidr* de votre cluster, exécutez la commande suivante. Par exemple, si la valeur renvoyée est `ipv4 10.100.0.0/16`, votre valeur est *10.100.0.10*.
```
aws eks describe-cluster --query "cluster.kubernetesNetworkConfig.serviceIpv4Cidr" --output text --name my-cluster --region region-code
```
+ Pour des arguments supplémentaires, consultez [Paramètres de configuration du script d'amorçage](eks-optimized-windows-ami.md#bootstrap-script-configuration-parameters).
**Note**
Si vous utilisez un CIDR de service personnalisé, vous devez le spécifier à l’aide du paramètre `-ServiceCIDR`. Sinon, la résolution DNS pour les pods dans le cluster échouera.
```
[string]$EKSBootstrapScriptFile = "$env:ProgramFiles\Amazon\EKS\Start-EKSBootstrap.ps1"
& $EKSBootstrapScriptFile -EKSClusterName my-cluster `
-Base64ClusterCA certificate-authority `
-APIServerEndpoint api-server-endpoint `
-DNSClusterIP service-cidr.10
```
### Exécution d'une AMI personnalisée en raison d'exigences spécifiques en matière de sécurité, de conformité ou de politique interne.
Pour plus d’informations, consultez [Amazon Machine Images (AMI)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) dans le *Guide de l’utilisateur Amazon EC2*. La spécification de création d’AMI Amazon EKS contient des ressources et des scripts de configuration pour créer une AMI Amazon EKS personnalisée basée sur Amazon Linux. Pour plus d'informations, consultez [Spécifications de création d'AMI Amazon EKS](https://github.com/awslabs/amazon-eks-ami/) sur GitHub. Pour créer une AMIs installation personnalisée avec d'autres systèmes d'exploitation, consultez [Amazon EKS Sample Custom AMIs](https://github.com/aws-samples/amazon-eks-custom-amis) on GitHub.
Vous ne pouvez pas utiliser de références de paramètres dynamiques pour les AMI IDs dans les modèles de lancement utilisés avec les groupes de nœuds gérés.
**Important**
Lorsque vous spécifiez une AMI, Amazon EKS ne valide pas la version de Kubernetes intégrée à votre AMI par rapport à la version du plan de contrôle de votre cluster. Il vous incombe de vous assurer que la version Kubernetes de votre AMI personnalisée est conforme à la politique de distorsion des versions de [Kubernetes](https://kubernetes.io/releases/version-skew-policy) :
La `kubelet` version de vos nœuds ne doit pas être plus récente que la version de votre cluster
La `kubelet` version sur vos nœuds doit être égale ou supérieure à 3 versions mineures par rapport à la version de votre cluster (pour la version de Kubernetes `1.28` ou supérieure), ou jusqu'à 2 versions mineures par rapport à la version de votre cluster (pour la version de Kubernetes ou inférieure) `1.27`
La création de groupes de nœuds gérés présentant des violations de distorsion de version peut entraîner :
Les nœuds ne parviennent pas à rejoindre le cluster
Comportement non défini ou incompatibilités d'API
Instabilité du cluster ou défaillances de charge de travail
Lorsque vous spécifiez une AMI, Amazon EKS ne fusionne aucune donnée utilisateur. C’est à vous qu’il incombe de fournir les commandes `bootstrap` requises pour que les nœuds rejoignent le cluster. Si vos nœuds ne parviennent pas à joindre le cluster, les actions `CreateNodegroup` et `UpdateNodegroupVersion` Amazon EKS échouent également.
## Limites et conditions lors de la spécification d'un ID d'AMI
Voici les limites et les conditions impliquées dans la spécification d'un ID d'AMI avec des groupes de nœuds gérés :
+ Vous devez créer un groupe de nœuds pour passer de la spécification d'un ID d'AMI dans un modèle de lancement à la non-spécification d'un ID d'AMI.
+ Vous n’êtes pas notifié dans la console lorsqu’une version plus récente de l’AMI est disponible. Pour mettre à jour votre groupe de nœuds vers une version d'AMI plus récente, vous devez créer une nouvelle version de votre modèle de lancement avec un ID d'AMI mis à jour. Vous devez ensuite mettre à jour le groupe de nœuds avec la nouvelle version du modèle de lancement.
+ Les champs suivants ne peuvent pas être définis dans l’API si vous spécifiez un ID d’AMI :
+ `amiType`
+ `releaseVersion`
+ `version`
+ Tous les `taints` définis dans l'API sont appliqués de manière asynchrone si vous spécifiez un identifiant d'AMI. Pour appliquer des rejets avant l'ajout d'un nœud au cluster, vous devez les transférer à `kubelet` dans vos données utilisateur à l'aide de l'indicateur de ligne de commande `--register-with-taints`. Pour plus d'informations, consultez [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) dans la documentation Kubernetes.
+ Lorsque vous spécifiez un ID AMI personnalisé pour les groupes de nœuds gérés par Windows, ajoutez-le `eks:kube-proxy-windows` à votre carte de configuration AWS IAM Authenticator. Cela est nécessaire pour le bon fonctionnement du DNS.
1. Ouvrez la carte de configuration de l'authentificateur AWS IAM pour la modifier.
```
kubectl edit -n kube-system cm aws-auth
```
1. Ajoutez cette entrée à la liste `groups` sous chaque `rolearn` associé aux nœuds Windows. Votre carte de configuration doit ressembler à [aws-auth-cm-windows.yaml.](https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm-windows.yaml)
```
- eks:kube-proxy-windows
```
1. Enregistrez le fichier et quittez votre éditeur de texte.
+ Pour toute AMI utilisant un modèle de lancement personnalisé, la valeur par défaut `HttpPutResponseHopLimit` pour les groupes de nœuds gérés est définie sur `2`.
# Supprimer un groupe de nœuds gérés de votre cluster
Cette rubrique explique comment supprimer un groupe de nœuds gérés Amazon EKS. Lorsque vous supprimez un groupe de nœuds gérés, Amazon EKS définit d'abord 0 pour les tailles minimale, maximale et souhaitée de votre groupe Auto Scaling. Cela entraîne ensuite une réduction d'échelle de votre groupe de nœuds.
Avant de mettre fin à chaque instance, Amazon EKS envoie un signal pour vider ce nœud. Pendant le processus de vidange, Kubernetes effectue les opérations suivantes pour chaque pod du nœud : exécute tous les hooks de `preStop` cycle de vie configurés, envoie `SIGTERM` des signaux aux conteneurs, puis attend l'`terminationGracePeriodSeconds`arrêt progressif. Si le nœud n'a pas été vidé au bout de 5 minutes, Amazon EKS permet à Auto Scaling de poursuivre la mise hors service forcée de l'instance. Une fois que toutes les instances ont été mises hors service, le groupe Auto Scaling est supprimé.
**Important**
Si vous supprimez un groupe de nœuds gérés qui utilise un rôle IAM de nœud qui n’est utilisé par aucun autre groupe de nœuds gérés dans le cluster, le rôle est supprimé de la `ConfigMap` `aws-auth`. Si l'un des groupes de nœuds autogérés dans le cluster utilisent le même rôle IAM de nœud, le statut des nœuds autogérés devient `NotReady`. De plus, le fonctionnement du cluster est également perturbé. Pour ajouter un mappage pour le rôle que vous utilisez uniquement pour les groupes de nœuds autogérés, consultez [Créer des entrées d’accès](creating-access-entries.md), si la version de plateforme de votre cluster est au moins égale à la version minimale indiquée dans la section Conditions préalables de l’article [Accorder aux utilisateurs IAM l’accès à Kubernetes avec des entrées d’accès EKS](access-entries.md). Si la version de votre plateforme est antérieure à la version minimale requise pour les entrées d’accès, vous pouvez rajouter l’entrée dans le fichier `aws-auth` `ConfigMap`. Pour plus d'informations, entrez `eksctl create iamidentitymapping --help` dans votre terminal.
Vous pouvez supprimer un groupe de nœuds gérés à l’aide de la commande suivante :
+ [`eksctl`](#eksctl-delete-managed-nodegroup)
+ [AWS Management Console](#console-delete-managed-nodegroup)
+ [AWS CLI](#awscli-delete-managed-nodegroup)
## `eksctl`
**Supprimer un groupe de nœuds gérés avec `eksctl`**
Entrez la commande suivante. Remplacez chaque `` par vos propres valeurs.
```
eksctl delete nodegroup \
--cluster \
--name \
--region
```
Pour plus d'options, consultez la section [Supprimer et vider des groupes de nœuds](https://eksctl.io/usage/nodegroups/#deleting-and-draining-nodegroups) dans la documentation `eksctl`.
## AWS Management Console
**Supprimer un groupe de nœuds gérés avec AWS Management Console **
1. Ouvrez la [console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Sur la page **Clusters**, choisissez le cluster qui contient le groupe de nœuds à supprimer.
1. Sur la page du cluster sélectionné, choisissez l'onglet **Compute**.
1. Dans la section **Node Groups** (Groupes de nœuds), choisissez le groupe de nœuds à supprimer. Ensuite, choisissez **Supprimer**.
1. Dans la boîte de dialogue de confirmation de la **suppression du groupe de nœuds**, entrez le nom du groupe de nœuds. Ensuite, choisissez **Supprimer**.
## AWS CLI
**Supprimer un groupe de nœuds gérés à l'aide de la AWS CLI**
1. Entrez la commande suivante. Remplacez chaque `` par vos propres valeurs.
```
aws eks delete-nodegroup \
--cluster-name \
--nodegroup-name \
--region
```
1. S'il `cli_pager=` est défini dans la configuration de la CLI, utilisez les touches fléchées de votre clavier pour faire défiler la sortie de réponse. Appuyez sur la touche `q` lorsque vous avez terminé.
Pour plus d'options, consultez la ` [delete-nodegroup](https://docs.aws.amazon.com/cli/latest/reference/eks/delete-nodegroup.html) ` commande dans le manuel de *référence des commandes de la AWS CLI*.