**Aidez à améliorer cette page** Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. Pour contribuer à ce guide de l'utilisateur, cliquez sur le GitHub lien **Modifier cette page sur** qui se trouve dans le volet droit de chaque page. Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Gérer les ressources de calcul à l’aide de nœuds Un nœud Kubernetes est une machine qui exécute des applications conteneurisées. Chaque nœud dispose des composants suivants : + ** [Exécution du conteneur](https://kubernetes.io/docs/setup/production-environment/container-runtimes/) ** : logiciel chargé d’exécuter les conteneurs. + ** [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) ** : s’assure que les conteneurs sont en bon état et fonctionnent correctement dans leur pod associé. + ** [kube-proxy](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-proxy/)** : gère les règles réseau qui permettent la communication avec vos pods. Pour plus d'informations, consultez [Nœuds](https://kubernetes.io/docs/concepts/architecture/nodes/) dans la documentation Kubernetes. Votre cluster Amazon EKS peut planifier des pods sur n’importe quelle combinaison de [nœuds gérés du mode automatique EKS](automode.md), de [nœuds autogérés](worker.md), de [groupes de nœuds gérés par Amazon EKS](managed-node-groups.md), d’[AWS Fargate](fargate.md) et de [nœuds hybrides Amazon EKS](hybrid-nodes-overview.md). Pour en savoir plus sur les nœuds déployés dans votre cluster, consultez [Consultez les ressources Kubernetes dans le AWS Management Console](view-kubernetes-resources.md). **Note** À l’exception des nœuds hybrides, les nœuds doivent se trouver dans le même VPC que les sous-réseaux que vous avez sélectionnés lors de la création du cluster. Cependant, les nœuds ne doivent pas nécessairement se trouver dans les mêmes sous-réseaux. ## Comparaison des options de calcul Le tableau suivant fournit plusieurs critères à évaluer pour décider quelles options répondent le mieux à vos besoins. Les nœuds autogérés constituent une autre option qui répond à tous les critères énumérés, mais ils nécessitent beaucoup plus de maintenance manuelle. Pour de plus amples informations, consultez [Gérer vous-même les nœuds grâce aux nœuds autogérés](worker.md). **Note** Bottlerocket présente quelques différences spécifiques par rapport aux informations générales de ce tableau. Pour plus d'informations, consultez la [documentation](https://github.com/bottlerocket-os/bottlerocket/blob/develop/README.md) de Bottlerocket sur GitHub. | Critères | Groupes de nœuds gérés EKS | Mode automatique EKS | Nœuds hybrides Amazon EKS | | --- | --- | --- | --- | | Peut être déployé dans [AWS Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html) | Non | Non | Non | | Possibilité d'être déployé dans une [zone locale AWS](local-zones.md) | Oui | Non | Non | | Possibilité d'exécuter des conteneurs qui nécessitent Windows | Oui | Non | Non | | Possibilité d'exécuter des conteneurs qui nécessitent Linux | Oui | Oui | Oui | | Possibilité d'exécuter des applications nécessitant la puce Inferentia | [Oui](inferentia-support.md) : nœuds Amazon Linux uniquement | Oui | Non | | Possibilité d'exécuter des applications nécessitant un GPU | [Oui](eks-optimized-ami.md#gpu-ami) : nœuds Amazon Linux uniquement | Oui | Oui | | Possibilité d'exécuter des applications nécessitant des processeurs Arm | [Oui](eks-optimized-ami.md#arm-ami) | Oui | Oui | | Possibilité d'exécuter AWS [Bottlerocket](https://aws.amazon.com/bottlerocket/) | Oui | Oui | Non | | Les pods partagent le processeur, la mémoire, le stockage et les ressources réseau avec d’autres pods. | Oui | Oui | Oui | | Doit déployer et gérer des instances Amazon EC2 | Oui | Non : En savoir plus sur les [instances gérées EC2](automode-learn-instances.md) | Oui : les machines physiques ou virtuelles sur site sont gérées par vos soins à l’aide des outils de votre choix. | | Doit sécuriser, entretenir et corriger le système d'exploitation des instances Amazon EC2 | Oui | Non | Oui : vous gérez vous-même le système d’exploitation qui fonctionne sur vos machines physiques ou virtuelles à l’aide des outils de votre choix. | | Peut fournir des arguments bootstrap lors du déploiement d’un nœud, tels que des arguments [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) supplémentaires. | Oui : utilisation de `eksctl` ou d’un [modèle de lancement](launch-templates.md) avec une AMI personnalisée. | Non : [Utilisez un `NodeClass` pour configurer les nœuds](create-node-class.md) | Oui : Vous pouvez personnaliser les arguments de démarrage avec nodeadm. Consultez [Référence des nœuds hybrides `nodeadm`](hybrid-nodes-nodeadm.md). | | Possibilité d’affecter des adresses IP à des pods à partir d’un bloc d’adresse CIDR différent de l’adresse IP affectée au nœud. | Oui : utilisation d'un modèle de lancement avec une AMI personnalisée. Pour de plus amples informations, consultez [Personnaliser les nœuds gérés à l’aide de modèles de lancement](launch-templates.md). | Non | Oui : consultez [Configurer CNI pour les nœuds hybrides](hybrid-nodes-cni.md). | | Possibilité d'accéder au nœud via SSH | Oui | Non : [Découvrez comment résoudre les problèmes liés aux nœuds](auto-troubleshoot.md) | Oui | | Possibilité de déployer votre propre AMI personnalisée sur les nœuds | Oui : utilisation d'un [modèle de lancement](launch-templates.md) | Non | Oui | | Possibilité de déployer votre propre CNI personnalisée sur les nœuds | Oui : utilisation d'un [modèle de lancement](launch-templates.md) avec une AMI personnalisée | Non | Oui | | Vous devez mettre à jour l'AMI du nœud par vous-même | [Oui](update-managed-node-group.md) : si vous avez déployé une AMI optimisée pour Amazon EKS, vous êtes averti dans la console Amazon EKS lorsque les mises à jour sont disponibles. Vous pouvez effectuer la mise à jour en un clic dans la console. Si vous avez déployé une AMI personnalisée, vous n’êtes pas averti dans la console Amazon EKS lorsque des mises à jour sont disponibles. Vous devez effectuer la mise à jour par vous-même. | Non | Oui, le système d’exploitation qui fonctionne sur vos machines physiques ou virtuelles est géré par vous-même à l’aide des outils de votre choix. Consultez [Préparer le système d’exploitation pour les nœuds hybrides](hybrid-nodes-os.md). | | Vous devez mettre à jour la version du nœud Kubernetes par vous-même | [Oui](update-managed-node-group.md) : si vous avez déployé une AMI optimisée pour Amazon EKS, vous êtes averti dans la console Amazon EKS lorsque les mises à jour sont disponibles. Vous pouvez effectuer la mise à jour en un clic dans la console. Si vous avez déployé une AMI personnalisée, vous n’êtes pas averti dans la console Amazon EKS lorsque des mises à jour sont disponibles. Vous devez effectuer la mise à jour par vous-même. | Non | Oui : Le système d’exploitation qui fonctionne sur vos machines physiques ou virtuelles est géré par vous-même à l’aide des outils de votre choix ou de `nodeadm`. Consultez [Mettre à niveau les nœuds hybrides pour votre cluster](hybrid-nodes-upgrade.md). | | Possibilité d’utiliser le stockage Amazon EBS avec des pods | [Oui](ebs-csi.md) | Oui, en tant que fonctionnalité intégrée. Découvrez comment [créer une classe de stockage.](create-storage-class.md) | Non | | Possibilité d’utiliser le stockage Amazon EFS avec des pods | [Oui](efs-csi.md) | Oui | Non | | Possibilité d’utiliser le stockage Amazon FSx pour Lustre avec des pods | [Oui](fsx-csi.md) | Oui | Non | | Possibilité d'utiliser le Network Load Balancer pour les services | [Oui](network-load-balancing.md) | Oui | Oui : Vous devez utiliser le type de cible `ip`. | | Les pods peuvent s'exécuter dans un sous-réseau public | Oui | Oui | Non : les modules s’exécutent dans un environnement sur site. | | Possibilité d’affecter différents groupes de sécurité VPC à des pods individuels | [Oui](security-groups-for-pods.md) : nœuds Linux uniquement | Non | Non | | Possibilité d'exécuter des ensembles de démons Kubernetes | Oui | Oui | Oui | | Prend en charge `HostPort` et `HostNetwork` dans le manifeste du pod | Oui | Oui | Oui | | AWS : disponibilité dans les régions | [Toutes les régions prises en charge par Amazon EKS](https://docs.aws.amazon.com/general/latest/gr/eks.html) | [Toutes les régions prises en charge par Amazon EKS](https://docs.aws.amazon.com/general/latest/gr/eks.html) | [Toutes les régions prises en charge par Amazon EKS](https://docs.aws.amazon.com/general/latest/gr/eks.html), à l’exception des régions AWS GovCloud (États-Unis) et de la Chine. | | Possibilité d'exécuter des conteneurs sur des hôtes dédiés Amazon EC2 | Oui | Non | Non | | Tarification | Coût de l’instance Amazon EC2 qui exécute plusieurs pods. Pour plus d’informations, consultez [Tarification Amazon EC2](https://aws.amazon.com/ec2/pricing/). | Lorsque le mode automatique EKS est activé dans votre cluster, vous payez des frais distincts, en plus des frais standard liés aux instances EC2, pour les instances lancées à l’aide de la capacité de calcul du mode automatique. Le montant varie en fonction du type d’instance lancé et de la région AWS où se trouve votre cluster. Pour plus d’informations, consultez les [tarifs Amazon EKS](https://aws.amazon.com/eks/pricing/). | Coût horaire des nœuds hybrides vCPU. Pour plus d’informations, consultez les [tarifs Amazon EKS](https://aws.amazon.com/eks/pricing/). | # 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*. # Gérer vous-même les nœuds grâce aux nœuds autogérés Un cluster contient un ou plusieurs nœuds Amazon EC2 sur lesquels les pods sont planifiés. Les nœuds Amazon EKS s'exécutent dans votre compte AWS et se connectent au plan de contrôle de votre cluster via le point de terminaison de serveur de l'API du cluster. Vous êtes facturé pour ceux-ci en fonction des tarifs Amazon EC2. Pour plus d’informations, consultez [Tarification Amazon EC2](https://aws.amazon.com/ec2/pricing/). Un cluster peut contenir plusieurs groupes de nœuds. Chaque groupe de nœuds contient un ou plusieurs nœuds déployés dans un [groupe Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/AutoScalingGroup.html). Le type d’instance des nœuds au sein du groupe peut varier, par exemple lorsque vous utilisez la [sélection de type d’instance basée sur les attributs](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-fleet-attribute-based-instance-type-selection.html) avec [Karpenter](https://karpenter.sh/). Toutes les instances d'un groupe de nœuds doivent utiliser le [rôle IAM du nœud Amazon EKS](create-node-role.md). Amazon EKS fournit des images Amazon Machine Image (AMI) spécialisées appelées « AMI optimisées pour Amazon EKS ». Les AMI sont configurées pour fonctionner avec Amazon EKS. Leurs composants incluent `containerd`, `kubelet` et l'authentificateur IAM AWS. Les AMI contiennent également un [script d’amorçage](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh) spécialisé qui leur permet de détecter et de se connecter automatiquement au plan de contrôle de votre cluster. Si vous limitez l'accès au point de terminaison public de votre cluster à l'aide de blocs CIDR, nous vous recommandons d'activer également l'accès au point de terminaison privé. Cela permet aux nœuds de communiquer avec le cluster. Sans l'activation du point de terminaison privé, les blocs CIDR que vous spécifiez pour l'accès public doivent inclure les sources de sortie de votre VPC. Pour de plus amples informations, consultez [Point de terminaison du serveur d’API du cluster](cluster-endpoint.md). Pour ajouter des nœuds autogérés à votre cluster Amazon EKS, consultez les rubriques qui suivent. Si vous lancez manuellement des nœuds autogérés, balisez chaque nœud avec la balise suivante en vous assurant que `` correspond à votre cluster. Pour de plus amples informations, veuillez consulter [Ajout et suppression de balises sur une ressource individuelle](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags). Si vous suivez les étapes des guides qui suivent, l'identification requise est ajoutée au nœud pour vous. | Clé | Valeur | | --- | --- | | `kubernetes.io/cluster/` | `owned` | **Important** Les balises du service de métadonnées d’instance (IMDS) Amazon EC2 ne sont pas compatibles avec les nœuds Amazon EKS. Lorsque les balises de métadonnées d’instance sont activées, l’utilisation de barres obliques (« / ») dans les valeurs des balises est interdite. Cette limitation peut entraîner des échecs de lancement d’instances, en particulier lorsque vous utilisez des outils de gestion de nœuds tels que Karpenter ou Cluster Autoscaler, car ces services dépendent de balises contenant des barres obliques pour fonctionner correctement. Pour plus d'informations sur les nœuds à partir d'une perspective Kubernetes générale, consultez [Nœuds](https://kubernetes.io/docs/concepts/architecture/nodes/) dans la documentation Kubernetes. **Topics** + [Créer des nœuds Amazon Linux autogérés](launch-workers.md) + [Créer des nœuds Bottlerocket autogérés](launch-node-bottlerocket.md) + [Créer des nœuds Microsoft Windows autogérés](launch-windows-workers.md) + [Créer des nœuds Ubuntu Linux autogérés](launch-node-ubuntu.md) + [Mettez à jour les nœuds autogérés de votre cluster](update-workers.md) # Créer des nœuds Amazon Linux autogérés Cette rubrique décrit comment lancer des groupes Auto Scaling de nœuds Linux qui s'enregistrent auprès de votre cluster Amazon EKS. Une fois que les nœuds ont rejoint le cluster, vous pouvez y déployer des applications Kubernetes. Vous pouvez également lancer des nœuds Amazon Linux autogérés avec `eksctl` ou le AWS Management Console. Si vous devez lancer des nœuds sur AWS Outposts, consultez. [Créez des nœuds Amazon Linux sur AWS Outposts](eks-outposts-self-managed-nodes.md) + Un cluster Amazon EKS existant. Pour en déployer un, consultez [Création d’un cluster Amazon EKS](create-cluster.md). Si vous avez des sous-réseaux dans la AWS région où AWS Outposts, AWS Wavelength ou Local AWS Zones est activé, ces sous-réseaux ne doivent pas avoir été transmis lorsque vous avez créé votre cluster. + Un rôle IAM existant pour les nœuds à utiliser. Pour en créer un, consultez [Rôle IAM de nœud Amazon EKS](create-node-role.md). Si ce rôle ne comporte aucune des politiques pour le VPC CNI, le rôle distinct suivant est nécessaire pour les pods VPC CNI. + (Facultatif, mais recommandé) Le plug-in CNI Amazon VPC pour le module complémentaire Kubernetes est configuré avec son propre rôle IAM auquel est associée la politique IAM nécessaire. Pour de plus amples informations, veuillez consulter [Configuration du plug-in Amazon VPC CNI pour utiliser IRSA](cni-iam-role.md). + Connaissance des considérations répertoriées dans la section [Choisissez un type d'instance de EC2 nœud Amazon optimal](choosing-instance-type.md). Selon le type d'instance que vous choisissez, il peut y avoir des prérequis supplémentaires pour votre cluster et votre VPC. Vous pouvez lancer des nœuds Linux autogérés à l’aide de l’une des méthodes suivantes : + [`eksctl`](#eksctl_create_managed_amazon_linux) + [AWS Management Console](#console_create_managed_amazon_linux) ## `eksctl` **Lancer des nœuds Linux autogérés à l’aide de `eksctl` ** 1. Installez la version `0.215.0` ou une version ultérieure de l'outil de ligne de `eksctl` commande installé sur votre appareil ou AWS CloudShell. Pour installer ou mettre à jour `eksctl`, veuillez consulter [Installation](https://eksctl.io/installation) dans la documentation de `eksctl`. 1. (Facultatif) Si la politique d’IAM gérée **AmazonEKS\$1CNI\$1Policy** est associée à votre [rôle IAM de nœud Amazon EKS](create-node-role.md), nous vous recommandons de l’attribuer à un rôle IAM que vous associez au compte de service Kubernetes `aws-node` à la place. Pour de plus amples informations, veuillez consulter [Configuration du plug-in Amazon VPC CNI pour utiliser IRSA](cni-iam-role.md). 1. La commande suivante crée un groupe de nœuds dans un cluster existant. Remplacer *al-nodes* avec un nom pour votre groupe de nœuds. Le nom du groupe de nœuds ne peut pas dépasser 63 caractères. Il doit commencer par une lettre ou un chiffre, mais peut également inclure des tirets et des traits de soulignement pour les autres caractères. Remplacez *my-cluster* par le nom de votre cluster. Un nom ne peut contenir que des caractères alphanumériques (sensibles à la casse) et des traits d'union. Il doit commencer par un caractère alphanumérique et ne peut pas dépasser 100 caractères. Le nom doit être unique dans la AWS région et le AWS compte dans lesquels vous créez le cluster. Remplacez les valeurs de *example value* restantes par vos propres valeurs. Par défaut, les nœuds sont créés avec la même version de Kubernetes que le plan de contrôle. Avant de choisir une valeur pour`--node-type`, consultez l'article [Choisissez un type d'instance de EC2 nœud Amazon optimal](choosing-instance-type.md). *my-key*Remplacez-le par le nom de votre paire de EC2 clés Amazon ou de votre clé publique. Cette clé est utilisée pour SSH dans vos nœuds après leur lancement. Si vous ne possédez pas encore de paire de EC2 clés Amazon, vous pouvez en créer une dans le AWS Management Console. Pour plus d'informations, consultez les [paires de EC2 clés Amazon](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) dans le *guide de EC2 l'utilisateur Amazon*. Créez votre groupe de nœuds avec la commande suivante. **Important** Si vous souhaitez déployer un groupe de nœuds sur des sous-réseaux AWS Outposts, Wavelength ou Local Zone, vous devez prendre en compte d'autres considérations : Les sous-réseaux ne doivent pas avoir été renseignés lors de la création du cluster. Vous devez créer le groupe de nœuds avec un fichier config qui spécifie les sous-réseaux et ` [volumeType](https://eksctl.io/usage/schema/#nodeGroups-volumeType): gp2`. Pour plus d'informations, consultez [Créer un nodegroup à partir d'un fichier config](https://eksctl.io/usage/nodegroups/#creating-a-nodegroup-from-a-config-file) et [Schéma du fichier Config](https://eksctl.io/usage/schema/) dans la documentation `eksctl`. ``` eksctl create nodegroup \ --cluster my-cluster \ --name al-nodes \ --node-type t3.medium \ --nodes 3 \ --nodes-min 1 \ --nodes-max 4 \ --ssh-access \ --managed=false \ --ssh-public-key my-key ``` Pour déployer un groupe de nœuds qui : + peut attribuer un nombre d’adresses IP aux pods nettement supérieur à celui de la configuration par défaut, consultez [Attribution de davantage d’adresses IP aux nœuds Amazon EKS avec des préfixes](cni-increase-ip-addresses.md). + peut attribuer des adresses `IPv4` aux pods à partir d’un bloc CIDR différent de celui de l’instance, consultez [Déploiement de pods dans des sous-réseaux alternatifs avec réseau personnalisé](cni-custom-network.md). + peut attribuer des adresses `IPv6` aux pods et aux services, consultez [En savoir plus sur IPv6 les adresses des clusters, des pods et des services](cni-ipv6.md). + ne dispose pas d’un accès Internet sortant, consultez [Déployer des clusters privés avec un accès Internet limité](private-clusters.md). Pour obtenir la liste complète de toutes les options disponibles et des valeurs par défaut, saisissez la commande suivante. ``` eksctl create nodegroup --help ``` Si les nœuds ne parviennent pas à rejoindre le cluster, consultez la section [Les nœuds ne parviennent pas à joindre le cluster](troubleshooting.md#worker-node-fail) du chapitre Dépannage. L'exemple qui suit illustre un résultat. Plusieurs lignes sont affichées pendant la création des nœuds. L'une des dernières lignes de sortie est similaire à la ligne d'exemple suivante. ``` [✔] created 1 nodegroup(s) in cluster "my-cluster" ``` 1. (Facultatif) Déployez un [exemple d'application](sample-deployment.md) pour tester votre cluster et les nœuds Linux. 1. Nous recommandons de bloquer l’accès des pods à IMDS si les conditions suivantes sont remplies : + Vous prévoyez d’attribuer des rôles IAM à tous vos comptes de service Kubernetes, afin que les pods ne disposent que des permissions strictement nécessaires. + Aucun pod du cluster n'a besoin d'accéder au service de métadonnées d' EC2 instance Amazon (IMDS) pour d'autres raisons, telles que la récupération de la région actuelle AWS . Pour plus d'informations, consultez [Restreindre l'accès au profil d'instance affecté au composant master](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node). ## AWS Management Console **Étape 1 : lancer les nœuds Linux autogérés à l’aide de la AWS Management Console ** 1. Téléchargez la dernière version du AWS CloudFormation modèle. ``` curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2025-11-26/amazon-eks-nodegroup.yaml ``` 1. Attendez que le statut de votre cluster s'affiche soit `ACTIVE`. Si vous lancez vos nœuds avant que le cluster soit actif, les nœuds ne s'enregistrent pas avec le cluster et vous devrez les relancer. 1. Ouvrez la [AWS CloudFormation console](https://console.aws.amazon.com/cloudformation/). 1. Choisissez **Create stack (Créer une pile)**, puis sélectionnez **Avec de nouvelles ressources (standard)**. 1. Pour **Spécifier un modèle**, sélectionnez ** Upload a template file (Télécharger un fichier de modèle)**, puis sélectionnez **Choose file (Choisir un fichier)**. 1. Sélectionnez le fichier `amazon-eks-nodegroup.yaml` que vous avez téléchargé. 1. Sélectionnez **Suivant**. 1. Dans la page **Specify stack details** (Spécifier les détails de la pile), saisissez les paramètres suivants, puis choisissez **Next** (Suivant) : + **Nom de pile** : Choisissez un nom de pile pour votre AWS CloudFormation pile. Par exemple, vous pouvez l'appeler *my-cluster-nodes*. Un nom ne peut contenir que des caractères alphanumériques (sensibles à la casse) et des traits d'union. Il doit commencer par un caractère alphanumérique et ne peut pas dépasser 100 caractères. Le nom doit être unique dans la AWS région et le AWS compte dans lesquels vous créez le cluster. + **ClusterName**: Entrez le nom que vous avez utilisé lors de la création de votre cluster Amazon EKS. Ce nom doit être identique au nom du cluster, sinon vos nœuds ne pourront pas rejoindre le cluster. + **ClusterControlPlaneSecurityGroup**: Choisissez la **SecurityGroups**valeur à partir de la AWS CloudFormation sortie que vous avez générée lors de la création de votre [VPC](creating-a-vpc.md). Les étapes suivantes montrent une opération permettant de récupérer le groupe applicable. 1. Ouvrez la [console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters). 1. Choisissez le nom du cluster. 1. Choisissez l'onglet **Networking (Mise en réseau)**. 1. Utilisez la valeur **Groupes de sécurité supplémentaires** comme référence lorsque vous effectuez une sélection **ClusterControlPlaneSecurityGroup**dans la liste déroulante. + **ApiServerEndpoint**: Entrez le point de terminaison du serveur API pour votre cluster EKS. Cela se trouve dans la section Détails de la console EKS Cluster + **CertificateAuthorityData**: Entrez les données de l'autorité de certification codées en base64, qui se trouvent également dans la section Détails de la console EKS Cluster. + **ServiceCidr**: Entrez la plage CIDR utilisée pour attribuer des adresses IP aux services Kubernetes au sein du cluster. Cela se trouve dans l'onglet réseau de la console EKS Cluster. + **AuthenticationMode**: Sélectionnez le mode d'authentification utilisé dans le cluster EKS en consultant l'onglet d'accès dans la console du cluster EKS. + **NodeGroupName**: Entrez le nom de votre groupe de nœuds. Ce nom peut être utilisé ultérieurement pour identifier le groupe de nœuds autoscaling qui est créé pour vos nœuds. Le nom du groupe de nœuds ne peut pas dépasser 63 caractères. Il doit commencer par une lettre ou un chiffre, mais peut également inclure des tirets et des traits de soulignement pour les autres caractères. + **NodeAutoScalingGroupMinSize**: Entrez le nombre minimum de nœuds que votre groupe Auto Scaling de nœuds peut atteindre. + **NodeAutoScalingGroupDesiredCapacity**: Entrez le nombre de nœuds que vous souhaitez atteindre lors de la création de votre pile. + **NodeAutoScalingGroupMaxSize**: Entrez le nombre maximum de nœuds que votre groupe Auto Scaling de nœuds peut atteindre. + **NodeInstanceType**: Choisissez un type d'instance pour vos nœuds. Pour de plus amples informations, veuillez consulter [Choix du type d’instance Amazon EC2 optimal pour les nœuds](choosing-instance-type.md). + **NodeImageIdSSMParam**: prérempli avec le paramètre Amazon EC2 Systems Manager d'une récente AMI Amazon Linux 2023 optimisée pour Amazon EKS pour une version variable de Kubernetes. Pour utiliser une autre version mineure de Kubernetes prise en charge avec Amazon EKS, remplacez *1.XX* par une autre [version prise en charge](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html). Nous vous recommandons de spécifier la même version de Kubernetes que celle de votre cluster. Vous pouvez également le remplacer *amazon-linux-2023* par un autre type d'AMI. Pour de plus amples informations, veuillez consulter [Récupérez l'AMI Amazon Linux recommandée IDs](retrieve-ami-id.md). **Note** Le nœud Amazon EKS AMIs est basé sur Amazon Linux. Vous pouvez suivre les événements liés à la sécurité ou à la confidentialité d'[Amazon Linux 2023 dans le centre de sécurité](https://alas.aws.amazon.com/alas2023.html) Amazon Linux ou vous abonner au [flux RSS](https://alas.aws.amazon.com/AL2023/alas.rss) associé. Les événements de sécurité et de confidentialité incluent une présentation du problème, les packages concernés et la manière de mettre à jour vos instances pour résoudre le problème. + **NodeImageId**: (Facultatif) Si vous utilisez votre propre AMI personnalisée (au lieu d'une AMI optimisée pour Amazon EKS), entrez un ID d'AMI de nœud pour votre AWS région. Si vous spécifiez une valeur ici, elle remplace toutes les valeurs du **NodeImageIdSSMParam**champ. + **NodeVolumeSize**: Spécifiez une taille de volume racine pour vos nœuds, en GiB. + **NodeVolumeType**: Spécifiez un type de volume racine pour vos nœuds. + **KeyName**: Entrez le nom d'une paire de clés Amazon EC2 SSH que vous pourrez utiliser pour vous connecter via SSH à vos nœuds après leur lancement. Si vous ne possédez pas encore de paire de EC2 clés Amazon, vous pouvez en créer une dans le AWS Management Console. Pour plus d'informations, consultez les [paires de EC2 clés Amazon](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) dans le *guide de EC2 l'utilisateur Amazon*. + **VpcId**: Entrez l'ID du [VPC](creating-a-vpc.md) que vous avez créé. + **Sous-réseaux** : choisissez les sous-réseaux que vous avez créés pour votre VPC. Si vous avez créé votre Amazon VPC en suivant les étapes décrites dans [Créer un Amazon VPC pour votre cluster Amazon EKS](creating-a-vpc.md), spécifiez uniquement les sous-réseaux privés au sein de l’Amazon VPC dans lesquels vos nœuds doivent être lancés. Vous pouvez consulter les sous-réseaux privés en ouvrant le lien de chaque sous-réseau depuis l'onglet **Networking** (Mise en réseau) de votre cluster. **Important** Si certains sous-réseaux sont des sous-réseaux publics, leur paramètre d'attribution automatique d'adresse IP publique doit être activé. Si le paramètre n'est pas activé pour le sous-réseau public, aucun nœud que vous déployez sur ce sous-réseau public ne se verra attribuer d'adresse IP publique et ne pourra pas communiquer avec le cluster ou d'autres AWS services. Si le sous-réseau a été déployé avant le 26 mars 2020 en utilisant l'un des modèles de [AWS CloudFormation VPC Amazon EKS](creating-a-vpc.md) ou `eksctl` en utilisant, l'attribution automatique d'adresses IP publiques est désactivée pour les sous-réseaux publics. Pour plus d'informations sur la façon d'activer l'attribution d'adresses IP publiques pour un sous-réseau, consultez la section [Modification de l'attribut d' IPv4 adressage public de votre sous-réseau](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip). Si le nœud est déployé sur un sous-réseau privé, il est capable de communiquer avec le cluster et d'autres AWS services via une passerelle NAT. Si les sous-réseaux n’ont pas d’accès Internet, assurez-vous de prendre connaissance des considérations et des étapes supplémentaires décrites dans [Déployer des clusters privés avec un accès Internet limité](private-clusters.md). Si vous sélectionnez AWS les sous-réseaux Outposts, Wavelength ou Local Zone, les sous-réseaux ne doivent pas avoir été transmis lors de la création du cluster. 1. Sélectionnez les choix que vous souhaitez sur la page **Configure stack options** (Configurer les options de la pile), puis choisissez **Next** (Suivant). 1. Cochez la case à gauche de **J'accuse réception AWS CloudFormation susceptible de créer des ressources IAM**. , puis choisissez **Create stack**. 1. Lorsque la création de votre pile est terminée, sélectionnez la pile dans la console et choisissez **Outputs** (Sorties). Si vous utilisez le mode `EKS API and ConfigMap` d'authentification `EKS API` ou, il s'agit de la dernière étape. 1. Si vous utilisez le mode `ConfigMap` d'authentification, enregistrez le **NodeInstanceRole**pour le groupe de nœuds créé. **Étape 2 : autoriser les nœuds à rejoindre votre cluster** **Note** Les deux étapes suivantes ne sont nécessaires que si le mode d'authentification Configmap est utilisé dans le cluster EKS. En outre, si vous avez lancé des nœuds au sein d'un VPC privé sans accès Internet sortant, veillez à autoriser les nœuds à rejoindre votre cluster depuis le VPC. 1. Vérifiez si vous avez déjà appliqué le `ConfigMap` `aws-auth`. ``` kubectl describe configmap -n kube-system aws-auth ``` 1. Si vous voyez un `ConfigMap` `aws-auth`, mettez-le à jour si nécessaire. 1. Ouvrez le `ConfigMap` pour le modifier. ``` kubectl edit -n kube-system configmap/aws-auth ``` 1. Ajoutez une nouvelle entrée `mapRoles` si nécessaire. Définissez la `rolearn` valeur sur la **NodeInstanceRole**valeur que vous avez enregistrée lors de la procédure précédente. ``` [...] data: mapRoles: | - rolearn: username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes [...] ``` 1. Enregistrez le fichier et quittez votre éditeur de texte. 1. Si vous avez reçu un message d'erreur indiquant « `Error from server (NotFound): configmaps "aws-auth" not found` », appliquez le stock `ConfigMap`. 1. Téléchargez la mappe de configuration. ``` curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm.yaml ``` 1. Dans le `aws-auth-cm.yaml` fichier, définissez la `rolearn` valeur sur celle **NodeInstanceRole**que vous avez enregistrée lors de la procédure précédente. Pour ce faire, utilisez un éditeur de texte ou remplacez *my-node-instance-role* et exécutez la commande suivante : ``` sed -i.bak -e 's||my-node-instance-role|' aws-auth-cm.yaml ``` 1. Appliquez la configuration. L'exécution de cette commande peut prendre quelques minutes. ``` kubectl apply -f aws-auth-cm.yaml ``` 1. Observez le statut de vos nœuds et attendez qu'ils obtiennent le statut `Ready`. ``` kubectl get nodes --watch ``` Saisissez `Ctrl`\$1`C` pour revenir à une invite de shell. **Note** Si vous recevez d'autres erreurs concernant les types d'autorisations ou de ressources, consultez [Accès non autorisé ou refusé (`kubectl`)](troubleshooting.md#unauthorized) dans la rubrique relative à la résolution des problèmes. Si les nœuds ne parviennent pas à rejoindre le cluster, consultez la section [Les nœuds ne parviennent pas à joindre le cluster](troubleshooting.md#worker-node-fail) du chapitre Dépannage. 1. (Nœuds GPU uniquement) Si vous avez choisi un type d'instance GPU et l'AMI accélérée optimisée pour Amazon EKS, vous devez appliquer le [plug-in d'appareil NVIDIA pour Kubernetes](https://github.com/NVIDIA/k8s-device-plugin) en tant que tel DaemonSet sur votre cluster. *vX.X.X*Remplacez-le par la s-device-plugin version [Nvidia/K8](https://github.com/NVIDIA/k8s-device-plugin/releases) de votre choix avant d'exécuter la commande suivante. ``` kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/vX.X.X/deployments/static/nvidia-device-plugin.yml ``` **Étape 3 : actions supplémentaires** 1. (Facultatif) Déployez un [exemple d'application](sample-deployment.md) pour tester votre cluster et les nœuds Linux. 1. (Facultatif) Si la politique IAM gérée par **Amazoneks\$1CNI\$1Policy** (si vous avez `IPv4` un cluster) ou celle (que vous avez [créée vous-même](cni-iam-role.md#cni-iam-role-create-ipv6-policy) si vous avez un `IPv6` cluster) est attachée *AmazonEKS\$1CNI\$1IPv6\$1Policy* au rôle IAM de votre [nœud Amazon EKS, nous vous recommandons de l'attribuer à un rôle IAM](create-node-role.md) que vous associez plutôt au compte de service Kubernetes. `aws-node` Pour de plus amples informations, veuillez consulter [Configuration du plug-in Amazon VPC CNI pour utiliser IRSA](cni-iam-role.md). 1. Nous recommandons de bloquer l’accès des pods à IMDS si les conditions suivantes sont remplies : + Vous prévoyez d’attribuer des rôles IAM à tous vos comptes de service Kubernetes, afin que les pods ne disposent que des permissions strictement nécessaires. + Aucun pod du cluster n'a besoin d'accéder au service de métadonnées d' EC2 instance Amazon (IMDS) pour d'autres raisons, telles que la récupération de la région actuelle AWS . Pour plus d'informations, consultez [Restreindre l'accès au profil d'instance affecté au composant master](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node). # Créer des nœuds Bottlerocket autogérés **Note** Les groupes de nœuds gérés peuvent offrir certains avantages pour votre cas d'utilisation. Pour de plus amples informations, veuillez consulter [Simplifiez le cycle de vie des nœuds avec des groupes de nœuds gérés](managed-node-groups.md). Cette rubrique décrit comment lancer des groupes Auto Scaling de nœuds [Bottlerocket](https://aws.amazon.com/bottlerocket/) qui s’enregistrent auprès de votre cluster Amazon EKS. Bottlerocket est un système d'exploitation open source basé sur Linux AWS que vous pouvez utiliser pour exécuter des conteneurs sur des machines virtuelles ou des hôtes bare metal. Une fois que les nœuds ont rejoint le cluster, vous pouvez y déployer des applications Kubernetes. Pour plus d'informations sur Bottlerocket, consultez la section [Utilisation d'une AMI Bottlerocket avec Amazon EKS](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-EKS.md) activé GitHub et la prise en charge des [AMI personnalisées](https://eksctl.io/usage/custom-ami-support/) dans la documentation. `eksctl` Pour plus d'informations sur les mises à niveau sur place, consultez [Bottlerocket](https://github.com/bottlerocket-os/bottlerocket-update-operator) Update Operator on. GitHub **Important** Les nœuds Amazon EKS sont des instances Amazon EC2 standard pour lesquelles vous êtes facturé en fonction du tarif normal pour les instances Amazon EC2. Pour plus d’informations, consultez [Tarification Amazon EC2](https://aws.amazon.com/ec2/pricing/). Vous pouvez lancer des nœuds Bottlerocket dans des clusters étendus Amazon EKS sur AWS Outposts, mais vous ne pouvez pas les lancer dans des clusters locaux sur Outposts. AWS Pour de plus amples informations, veuillez consulter [Déployez Amazon EKS sur site avec AWS Outposts](eks-outposts.md). Vous pouvez déployer sur des instances Amazon EC2 avec des processeurs `x86` ou Arm. Cependant, vous ne pouvez pas déployer sur des instances équipées de puces Inferentia. Bottlerocket est compatible avec. AWS CloudFormation Cependant, aucun CloudFormation modèle officiel ne peut être copié pour déployer des nœuds Bottlerocket pour Amazon EKS. Les images Bottlerocket ne sont pas fournies avec un serveur SSH ou un shell. Vous pouvez utiliser des méthodes out-of-band d'accès pour autoriser SSH à activer le conteneur d'administration et pour passer certaines étapes de configuration d'amorçage avec les données utilisateur. Pour plus d'informations, consultez ces sections dans le [README.md de bottlerocket](https://github.com/bottlerocket-os/bottlerocket) sur GitHub : [Exploration](https://github.com/bottlerocket-os/bottlerocket#exploration) [Conteneur d'administration](https://github.com/bottlerocket-os/bottlerocket#admin-container) [Paramètres Kubernetes](https://github.com/bottlerocket-os/bottlerocket#kubernetes-settings) Cette procédure nécessite `eksctl` version `0.215.0` ou ultérieure. Vous pouvez vérifier votre version avec la commande suivante : ``` eksctl version ``` Pour obtenir des instructions sur l’installation ou la mise à niveau d’`eksctl`, consultez [Installation](https://eksctl.io/installation) dans la documentation `eksctl`. REMARQUE : cette procédure ne fonctionne que pour les clusters créés avec `eksctl`. 1. Copiez les contenus suivants sur votre appareil. Remplacez *my-cluster* par le nom de votre cluster. Un nom ne peut contenir que des caractères alphanumériques (sensibles à la casse) et des traits d'union. Il doit commencer par un caractère alphanumérique et ne peut pas dépasser 100 caractères. Le nom doit être unique dans la AWS région et le AWS compte dans lesquels vous créez le cluster. Remplacer *ng-bottlerocket* avec un nom pour votre groupe de nœuds. Le nom du groupe de nœuds ne peut pas dépasser 63 caractères. Il doit commencer par une lettre ou un chiffre, mais peut également inclure des tirets et des traits de soulignement pour les autres caractères. Pour effectuer un déploiement sur des instances Arm, remplacez *m5.large* par un type d'instance Arm. Remplacez *my-ec2-keypair-name* par le nom d'une paire de clés SSH Amazon EC2 que vous pouvez utiliser pour vous connecter à l'aide de SSH dans vos nœuds après leur lancement. Si vous ne possédez pas déjà une paire de clés Amazon EC2, vous pouvez en créer une dans l’ AWS Management Console. Pour plus d'informations, veuillez consulter la rubrique [Paires de clés Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) dans le *Guide de l'utilisateur Amazon EC2*. Remplacez toutes les valeurs d’exemple restantes par vos propres valeurs. Une fois les remplacements effectués, exécutez la commande modifiée pour créer le fichier `bottlerocket.yaml`. Si vous spécifiez un type d'instance Arm Amazon EC2, consultez les points à prendre en compte dans Arm [Amazon Linux optimisé pour Amazon EKS AMIs](eks-optimized-ami.md#arm-ami) avant le déploiement. Pour obtenir des instructions sur le déploiement à l'aide d'une AMI personnalisée, consultez les sections [Building Bottlerocket](https://github.com/bottlerocket-os/bottlerocket/blob/develop/BUILDING.md) on et GitHub Custom [AMI support](https://eksctl.io/usage/custom-ami-support/) dans la documentation. `eksctl` Pour déployer un groupe de nœuds gérés, déployez une AMI personnalisée à l'aide d'un modèle de lancement. Pour de plus amples informations, veuillez consulter [Personnaliser les nœuds gérés à l’aide de modèles de lancement](launch-templates.md). **Important** Pour déployer un groupe de nœuds sur des sous-réseaux AWS Outposts, AWS Wavelength ou AWS Local Zone, ne transmettez pas les sous-réseaux Outposts AWS , AWS Wavelength ou AWS Local Zone lorsque vous créez le cluster. Vous devez spécifier les sous-réseaux dans l'exemple suivant. Pour plus d'informations, consultez [Créer un nodegroup à partir d'un fichier de configuration](https://eksctl.io/usage/nodegroups/#creating-a-nodegroup-from-a-config-file) et [Schéma du fichier de configuration](https://eksctl.io/usage/schema/) dans la documentation `eksctl`. Remplacez *region-code* par la AWS région dans laquelle se trouve votre cluster. ``` cat >bottlerocket.yaml < Cette rubrique décrit comment lancer des groupes Auto Scaling de nœuds Windows qui s'enregistrent auprès de votre cluster Amazon EKS. Une fois que les nœuds ont rejoint le cluster, vous pouvez y déployer des applications Kubernetes. **Important** Les nœuds Amazon EKS sont des instances Amazon EC2 standard pour lesquelles vous êtes facturé en fonction du tarif normal pour les instances Amazon EC2. Pour plus d’informations, consultez [Tarification Amazon EC2](https://aws.amazon.com/ec2/pricing/). Vous pouvez lancer des nœuds Windows dans des clusters étendus Amazon EKS sur AWS Outposts, mais vous ne pouvez pas les lancer dans des clusters locaux sur AWS Outposts. Pour de plus amples informations, veuillez consulter [Déployez Amazon EKS sur site avec AWS Outposts](eks-outposts.md). Activer la prise en charge de Windows pour votre cluster avec. Nous vous recommandons de passer en revue les considérations importantes avant de lancer un groupe de nœuds Windows. Pour de plus amples informations, veuillez consulter [Activer la prise en charge de Windows](windows-support.md#enable-windows-support). Vous pouvez lancer des nœuds Windows autogérés à l’aide de l’une des méthodes suivantes : + [`eksctl`](#eksctl_create_windows_nodes) + [AWS Management Console](#console_create_windows_nodes) ## `eksctl` **Lancer des nœuds Windows autogérés à l’aide de `eksctl`** Cette procédure exige que vous installiez `eksctl` et que votre version `eksctl` soit au moins la version `0.215.0`. Vous pouvez vérifier votre version à l'aide de la commande suivante. ``` eksctl version ``` Pour les instructions d'installation ou de mise à niveau de `eksctl`, consultez la rubrique [Installation](https://eksctl.io/installation) dans la documentation `eksctl`. **Note** Cette procédure fonctionne uniquement pour les clusters créés avec `eksctl`. 1. (Facultatif) Si la politique IAM gérée par **Amazoneks\$1CNI\$1Policy** (si vous avez `IPv4` un cluster) ou celle (que vous avez [créée vous-même](cni-iam-role.md#cni-iam-role-create-ipv6-policy) si vous avez un `IPv6` cluster) est attachée *AmazonEKS\$1CNI\$1IPv6\$1Policy* au rôle IAM de votre [nœud Amazon EKS, nous vous recommandons de l'attribuer à un rôle IAM](create-node-role.md) que vous associez plutôt au compte de service Kubernetes. `aws-node` Pour de plus amples informations, veuillez consulter [Configuration du plug-in Amazon VPC CNI pour utiliser IRSA](cni-iam-role.md). 1. Cette procédure part du principe que vous disposez d'un cluster existant. Si vous ne disposez pas encore d’un cluster Amazon EKS et d’un groupe de nœuds Amazon Linux auquel ajouter un groupe de nœuds Windows, nous vous recommandons de suivre [Démarrage avec Amazon EKS – `eksctl`](getting-started-eksctl.md). Ce guide fournit une démonstration complète pour créer un cluster Amazon EKS avec des nœuds Amazon Linux. Créez votre groupe de nœuds avec la commande suivante. Remplacez *region-code* par la AWS région dans laquelle se trouve votre cluster. Remplacez *my-cluster* par le nom de votre cluster. Un nom ne peut contenir que des caractères alphanumériques (sensibles à la casse) et des traits d'union. Il doit commencer par un caractère alphanumérique et ne peut pas dépasser 100 caractères. Le nom doit être unique dans la AWS région et le AWS compte dans lesquels vous créez le cluster. Remplacer *ng-windows* avec un nom pour votre groupe de nœuds. Le nom du groupe de nœuds ne peut pas dépasser 63 caractères. Il doit commencer par une lettre ou un chiffre, mais peut également inclure des tirets et des traits de soulignement pour les autres caractères. Vous pouvez *2019* remplacer par `2022` pour utiliser Windows Server 2022 ou `2025` Windows Server 2025. Remplacez le reste des valeurs d’exemple par vos propres valeurs. **Important** Pour déployer un groupe de nœuds sur des sous-réseaux AWS Outposts, AWS Wavelength ou AWS Local Zone, ne transmettez pas les sous-réseaux Outposts AWS , Wavelength ou Local Zone lorsque vous créez le cluster. Créez le groupe de nœuds avec un fichier de configuration, en spécifiant les AWS sous-réseaux Outposts, Wavelength ou Local Zone. Pour plus d'informations, consultez [Créer un nodegroup à partir d'un fichier config](https://eksctl.io/usage/nodegroups/#creating-a-nodegroup-from-a-config-file) et [Schéma du fichier Config](https://eksctl.io/usage/schema/) dans la documentation `eksctl`. ``` eksctl create nodegroup \ --region region-code \ --cluster my-cluster \ --name ng-windows \ --node-type t2.large \ --nodes 3 \ --nodes-min 1 \ --nodes-max 4 \ --managed=false \ --node-ami-family WindowsServer2019FullContainer ``` **Note** Si les nœuds ne parviennent pas à rejoindre le cluster, reportez-vous à [Les nœuds ne parviennent pas à joindre le cluster](troubleshooting.md#worker-node-fail) dans le guide de dépannage. Pour voir les options disponibles pour les commandes `eksctl`, saisissez la commande suivante. ``` eksctl command -help ``` L'exemple qui suit illustre un résultat. Plusieurs lignes sont affichées pendant la création des nœuds. L'une des dernières lignes de sortie est similaire à la ligne d'exemple suivante. ``` [✔] created 1 nodegroup(s) in cluster "my-cluster" ``` 1. (Facultatif) Déployez un [exemple d'application](sample-deployment.md) pour tester votre cluster et les nœuds Windows. 1. Nous recommandons de bloquer l’accès des pods à IMDS si les conditions suivantes sont remplies : + Vous prévoyez d’attribuer des rôles IAM à tous vos comptes de service Kubernetes, afin que les pods ne disposent que des permissions strictement nécessaires. + Aucun pod du cluster n'a besoin d'accéder au service de métadonnées d'instance Amazon EC2 (IMDS) pour d'autres raisons, telles que la récupération de la région actuelle. AWS Pour plus d'informations, consultez [Restreindre l'accès au profil d'instance affecté au composant master](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node). ## AWS Management Console **Conditions préalables** + Un cluster Amazon EKS existant et un groupe de nœuds Linux. Si vous ne disposez pas de ces ressources, nous vous recommandons de les créer à l’aide de l’un de nos guides dans [Mise en route avec Amazon EKS](getting-started.md). Ces guides décrivent comment créer un cluster Amazon EKS avec des nœuds Linux. + Un VPC et un groupe de sécurité existants qui remplissent les conditions requises pour un cluster Amazon EKS. Pour plus d’informations, consultez [Afficher les exigences réseau Amazon EKS pour les VPC et les sous-réseaux](network-reqs.md) et [Voir les exigences relatives aux groupes de sécurité Amazon EKS pour les clusters](sec-group-reqs.md). Les guides disponibles dans [Mise en route avec Amazon EKS](getting-started.md) créent un VPC qui répond aux exigences. Vous pouvez également suivre les instructions de [Créer un Amazon VPC pour votre cluster Amazon EKS](creating-a-vpc.md) pour en créer un manuellement. + Un cluster Amazon EKS existant qui utilise un VPC et un groupe de sécurité qui remplit les conditions requises pour un cluster Amazon EKS. Pour de plus amples informations, veuillez consulter [Création d’un cluster Amazon EKS](create-cluster.md). Si vous avez des sous-réseaux dans la AWS région où AWS Outposts, AWS Wavelength ou Local AWS Zones est activé, ces sous-réseaux ne doivent pas avoir été transmis lorsque vous avez créé le cluster. **Étape 1 : lancer des nœuds Windows autogérés à l’aide de la AWS Management Console ** 1. Attendez que le statut de votre cluster s'affiche soit `ACTIVE`. Si vous lancez vos nœuds avant que le cluster soit actif, les nœuds ne s'enregistrent pas avec le cluster et vous devez les relancer. 1. Ouvrez la [console AWS CloudFormation ](https://console.aws.amazon.com/cloudformation/). 1. Sélectionnez **Créer la pile**. 1. Dans **Spécifier le modèle**, sélectionnez **URL Amazon S3**. 1. Copiez l'URL suivante et collez-la dans l'**URL Amazon S3**. ``` https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2023-02-09/amazon-eks-windows-nodegroup.yaml ``` 1. Sélectionnez **Next** (Suivant) deux fois. 1. Sur la page **Création rapide d'une pile**, saisissez les paramètres suivants en conséquence : + **Nom de pile** : Choisissez un nom de pile pour votre AWS CloudFormation pile. Par exemple, vous pouvez l'appeler `my-cluster-nodes`. + **ClusterName**: Entrez le nom que vous avez utilisé lors de la création de votre cluster Amazon EKS. **Important** Ce nom doit correspondre exactement au nom que vous avez utilisé dans [Étape 1 : créer votre cluster Amazon EKS](getting-started-console.md#eks-create-cluster). Sinon, vos nœuds ne pourront pas rejoindre le cluster. + **ClusterControlPlaneSecurityGroup**: Choisissez le groupe de sécurité dans la AWS CloudFormation sortie que vous avez générée lors de la création de votre [VPC](creating-a-vpc.md). Les étapes suivantes montrent une méthode permettant de récupérer le groupe applicable. 1. Ouvrez la [console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters). 1. Choisissez le nom du cluster. 1. Choisissez l'onglet **Networking (Mise en réseau)**. 1. Utilisez la valeur **Groupes de sécurité supplémentaires** comme référence lorsque vous effectuez une sélection **ClusterControlPlaneSecurityGroup**dans la liste déroulante. + **NodeGroupName**: Entrez le nom de votre groupe de nœuds. Ce nom peut être utilisé ultérieurement pour identifier le groupe de nœuds autoscaling qui est créé pour vos nœuds. Le nom du groupe de nœuds ne peut pas dépasser 63 caractères. Il doit commencer par une lettre ou un chiffre, mais peut également inclure des tirets et des traits de soulignement pour les autres caractères. + **NodeAutoScalingGroupMinSize**: Entrez le nombre minimum de nœuds que votre groupe Auto Scaling de nœuds peut atteindre. + **NodeAutoScalingGroupDesiredCapacity**: Entrez le nombre de nœuds que vous souhaitez atteindre lors de la création de votre pile. + **NodeAutoScalingGroupMaxSize**: Entrez le nombre maximum de nœuds que votre groupe Auto Scaling de nœuds peut atteindre. + **NodeInstanceType**: Choisissez un type d'instance pour vos nœuds. Pour de plus amples informations, veuillez consulter [Choix du type d’instance Amazon EC2 optimal pour les nœuds](choosing-instance-type.md). **Note** [Les types d'instances pris en charge pour la dernière version du [plugin Amazon VPC CNI pour Kubernetes sont répertoriés dans vpc\$1ip\$1resource\$1limit.go](https://github.com/aws/amazon-vpc-cni-k8s) on.](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/pkg/vpc/vpc_ip_resource_limit.go) GitHub Vous devrez peut-être mettre à jour votre version de CNI pour utiliser les derniers types d'instances pris en charge. Pour de plus amples informations, veuillez consulter [Attribuer IPs à des pods avec l'Amazon VPC CNI](managing-vpc-cni.md). + **NodeImageIdSSMParam**: prérempli avec le paramètre Amazon EC2 Systems Manager de l'ID AMI Windows Core optimisé pour Amazon EKS actuellement recommandé. Pour utiliser la version complète de Windows, remplacez *Core* par `Full`. + **NodeImageId**: (Facultatif) Si vous utilisez votre propre AMI personnalisée (au lieu d'une AMI optimisée pour Amazon EKS), entrez un ID d'AMI de nœud pour votre AWS région. Si vous spécifiez une valeur pour ce champ, elle remplace toutes les valeurs du **NodeImageIdSSMParam**champ. + **NodeVolumeSize**: Spécifiez une taille de volume racine pour vos nœuds, en GiB. + **KeyName**: Entrez le nom d'une paire de clés SSH Amazon EC2 que vous pourrez utiliser pour vous connecter via SSH à vos nœuds après leur lancement. Si vous ne possédez pas déjà une paire de clés Amazon EC2, vous pouvez en créer une dans l’ AWS Management Console. Pour plus d'informations, veuillez consulter la rubrique [Paires de clés Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-key-pairs.html) dans le *Guide de l'utilisateur Amazon EC2*. **Note** Si vous ne fournissez pas de paire de clés ici, la AWS CloudFormation pile ne sera pas créée. + **BootstrapArguments**: Spécifiez tous les arguments facultatifs à transmettre au script bootstrap du nœud, tels que des `kubelet` arguments supplémentaires en utilisant`-KubeletExtraArgs`. + **Désactiver IMDSv1** : par défaut, chaque nœud prend en charge les versions 1 du service de métadonnées d'instance (IMDSv1) et IMDSv2. Vous pouvez désactiver IMDSv1. Pour empêcher l'utilisation des futurs nœuds et pods du groupe de nœuds MDSv1, définissez **Disable IMDSv1** sur **true**. Pour de plus amples informations au sujet d'IMDS, consultez [Configuration du service des métadonnées d'instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html). + **VpcId**: Sélectionnez l'ID du [VPC](creating-a-vpc.md) que vous avez créé. + **NodeSecurityGroups**: Sélectionnez le groupe de sécurité créé pour votre groupe de nœuds Linux lorsque vous avez créé votre [VPC](creating-a-vpc.md). Si vos nœuds Linux sont associés à plusieurs groupes de sécurité, spécifiez-les tous. C'est le cas, par exemple, si le groupe de nœuds Linux a été créé avec `eksctl`. + **Sous-réseaux** : choisissez les sous-réseaux que vous avez créés. Si vous avez créé votre VPC en suivant les étapes décrites dans [Créer un Amazon VPC pour votre cluster Amazon EKS](creating-a-vpc.md), spécifiez uniquement les sous-réseaux privés au sein du VPC dans lesquels vos nœuds doivent être lancés. **Important** Si certains sous-réseaux sont des sous-réseaux publics, leur paramètre d'attribution automatique d'adresse IP publique doit être activé. Si le paramètre n'est pas activé pour le sous-réseau public, aucun nœud que vous déployez sur ce sous-réseau public ne se verra attribuer d'adresse IP publique et ne pourra pas communiquer avec le cluster ou d'autres AWS services. Si le sous-réseau a été déployé avant le 26 mars 2020 en utilisant l'un des modèles de [AWS CloudFormation VPC Amazon EKS](creating-a-vpc.md) ou `eksctl` en utilisant, l'attribution automatique d'adresses IP publiques est désactivée pour les sous-réseaux publics. Pour plus d'informations sur la façon d'activer l'attribution d'adresses IP publiques pour un sous-réseau, consultez la section [Modification de l'attribut d' IPv4 adressage public de votre sous-réseau](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip). Si le nœud est déployé sur un sous-réseau privé, il est capable de communiquer avec le cluster et d'autres AWS services via une passerelle NAT. Si les sous-réseaux n’ont pas accès à Internet, veuillez vous assurer de prendre connaissance des considérations et des étapes supplémentaires décrites dans [Déployer des clusters privés avec un accès Internet limité](private-clusters.md). Si vous sélectionnez AWS les sous-réseaux Outposts, Wavelength ou Local Zone, les sous-réseaux ne doivent pas avoir été transmis lors de la création du cluster. 1. Confirmez que la pile peut créer des ressources IAM, puis choisissez **Create stack (Créer une pile)**. 1. Lorsque la création de votre pile est terminée, sélectionnez la pile dans la console et choisissez **Outputs** (Sorties). 1. Enregistrez le **NodeInstanceRole**pour le groupe de nœuds créé. Vous en aurez besoin lors de la configuration de vos nœuds Windows Amazon EKS. **Étape 2 : autoriser les nœuds à rejoindre votre cluster** 1. Vérifiez si vous avez déjà appliqué le `ConfigMap` `aws-auth`. ``` kubectl describe configmap -n kube-system aws-auth ``` 1. Si vous voyez un `ConfigMap` `aws-auth`, mettez-le à jour si nécessaire. 1. Ouvrez le `ConfigMap` pour le modifier. ``` kubectl edit -n kube-system configmap/aws-auth ``` 1. Ajoutez de nouvelles entrées `mapRoles` selon vos besoins. Définissez les `rolearn` valeurs selon les **NodeInstanceRole**valeurs que vous avez enregistrées dans les procédures précédentes. ``` [...] data: mapRoles: | - rolearn: username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes - rolearn: username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes - eks:kube-proxy-windows [...] ``` 1. Enregistrez le fichier et quittez votre éditeur de texte. 1. Si vous avez reçu un message d'erreur indiquant « `Error from server (NotFound): configmaps "aws-auth" not found` », appliquez le stock `ConfigMap`. 1. Téléchargez la mappe de configuration. ``` curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm-windows.yaml ``` 1. Dans le `aws-auth-cm-windows.yaml` fichier, définissez les `rolearn` valeurs en fonction des **NodeInstanceRole**valeurs applicables que vous avez enregistrées dans les procédures précédentes. Vous pouvez effectuer cette opération à l’aide d’un éditeur de texte ou en remplaçant les valeurs d’exemple et en exécutant la commande suivante : ``` sed -i.bak -e 's||my-node-linux-instance-role|' \ -e 's||my-node-windows-instance-role|' aws-auth-cm-windows.yaml ``` **Important** Ne modifiez aucune autre ligne de ce fichier. Veuillez ne pas utiliser le même rôle IAM pour les nœuds Windows et Linux. 1. Appliquez la configuration. L'exécution de cette commande peut prendre quelques minutes. ``` kubectl apply -f aws-auth-cm-windows.yaml ``` 1. Observez le statut de vos nœuds et attendez qu'ils obtiennent le statut `Ready`. ``` kubectl get nodes --watch ``` Saisissez `Ctrl`\$1`C` pour revenir à une invite de shell. **Note** Si vous recevez d'autres erreurs concernant les types d'autorisations ou de ressources, consultez [Accès non autorisé ou refusé (`kubectl`)](troubleshooting.md#unauthorized) dans la rubrique relative à la résolution des problèmes. Si les nœuds ne parviennent pas à rejoindre le cluster, consultez la section [Les nœuds ne parviennent pas à joindre le cluster](troubleshooting.md#worker-node-fail) du chapitre Dépannage. **Étape 3 : actions supplémentaires** 1. (Facultatif) Déployez un [exemple d'application](sample-deployment.md) pour tester votre cluster et les nœuds Windows. 1. (Facultatif) Si la politique IAM gérée par **Amazoneks\$1CNI\$1Policy** (si vous avez `IPv4` un cluster) ou celle (que vous avez [créée vous-même](cni-iam-role.md#cni-iam-role-create-ipv6-policy) si vous avez un `IPv6` cluster) est attachée *AmazonEKS\$1CNI\$1IPv6\$1Policy* au rôle IAM de votre [nœud Amazon EKS, nous vous recommandons de l'attribuer à un rôle IAM](create-node-role.md) que vous associez plutôt au compte de service Kubernetes. `aws-node` Pour de plus amples informations, veuillez consulter [Configuration du plug-in Amazon VPC CNI pour utiliser IRSA](cni-iam-role.md). 1. Nous recommandons de bloquer l’accès des pods à IMDS si les conditions suivantes sont remplies : + Vous prévoyez d’attribuer des rôles IAM à tous vos comptes de service Kubernetes, afin que les pods ne disposent que des permissions strictement nécessaires. + Aucun pod du cluster n'a besoin d'accéder au service de métadonnées d'instance Amazon EC2 (IMDS) pour d'autres raisons, telles que la récupération de la région actuelle. AWS Pour plus d'informations, consultez [Restreindre l'accès au profil d'instance affecté au composant master](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node). # Créer des nœuds Ubuntu Linux autogérés **Note** Les groupes de nœuds gérés peuvent offrir certains avantages pour votre cas d'utilisation. Pour de plus amples informations, veuillez consulter [Simplifiez le cycle de vie des nœuds avec des groupes de nœuds gérés](managed-node-groups.md). Cette rubrique décrit comment lancer des groupes Auto Scaling de nœuds [Ubuntu sur Amazon Elastic Kubernetes Service (EKS)](https://cloud-images.ubuntu.com/aws-eks/) ou [Ubuntu Pro sur Amazon Elastic Kubernetes Service (EKS)](https://ubuntu.com/blog/ubuntu-pro-for-eks-is-now-generally-available) qui s’enregistrent auprès de votre cluster Amazon EKS. Ubuntu et Ubuntu Pro pour EKS sont basés sur le LTS officiel Ubuntu Minimal, incluent le AWS noyau personnalisé développé conjointement avec AWS EKS et spécialement conçu pour EKS. Ubuntu Pro renforce la sécurité en prenant en charge les périodes de support étendu EKS, le livepatch du noyau, la conformité FIPS et la possibilité d’exécuter un nombre illimité de conteneurs Pro. Une fois les nœuds intégrés au cluster, vous pouvez y déployer des applications conteneurisées. Pour plus d’informations, consultez la documentation relative à [Ubuntu sur AWS](https://documentation.ubuntu.com/aws/en/latest/) et [Prise en charge des AMI personnalisées](https://eksctl.io/usage/custom-ami-support/) dans la documentation `eksctl`. **Important** Les nœuds Amazon EKS sont des instances Amazon EC2 standard pour lesquelles vous êtes facturé en fonction du tarif normal pour les instances Amazon EC2. Pour plus d’informations, consultez [Tarification Amazon EC2](https://aws.amazon.com/ec2/pricing/). Vous pouvez lancer des nœuds Ubuntu dans des clusters étendus Amazon EKS sur AWS Outposts, mais vous ne pouvez pas les lancer dans des clusters locaux sur AWS Outposts. Pour de plus amples informations, veuillez consulter [Déployez Amazon EKS sur site avec AWS Outposts](eks-outposts.md). Vous pouvez déployer sur des instances Amazon EC2 avec des processeurs `x86` ou Arm. Cependant, les instances équipées de puces Inferentia peuvent nécessiter l’installation préalable du [Kit SDK de Neuron](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/). Cette procédure nécessite `eksctl` version `0.215.0` ou ultérieure. Vous pouvez vérifier votre version avec la commande suivante : ``` eksctl version ``` Pour obtenir des instructions sur l’installation ou la mise à niveau d’`eksctl`, consultez [Installation](https://eksctl.io/installation) dans la documentation `eksctl`. REMARQUE : cette procédure ne fonctionne que pour les clusters créés avec `eksctl`. 1. Copiez les contenus suivants sur votre appareil. Remplacez `my-cluster` par le nom de votre cluster. Un nom ne peut contenir que des caractères alphanumériques (sensibles à la casse) et des traits d'union. Il doit commencer par une lettre et ne peut pas dépasser 100 caractères. Remplacer `ng-ubuntu` avec un nom pour votre groupe de nœuds. Le nom du groupe de nœuds ne peut pas dépasser 63 caractères. Il doit commencer par une lettre ou un chiffre, mais peut également inclure des tirets et des traits de soulignement pour les autres caractères. Pour effectuer un déploiement sur des instances Arm, remplacez `m5.large` par un type d'instance Arm. Remplacez `my-ec2-keypair-name` par le nom d'une paire de clés SSH Amazon EC2 que vous pouvez utiliser pour vous connecter à l'aide de SSH dans vos nœuds après leur lancement. Si vous ne possédez pas déjà une paire de clés Amazon EC2, vous pouvez en créer une dans l’ AWS Management Console. Pour plus d’informations, consultez [Paires de clés Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) dans le Guide de l’utilisateur Amazon EC2. Remplacez toutes les valeurs d’exemple restantes par vos propres valeurs. Une fois les remplacements effectués, exécutez la commande modifiée pour créer le fichier `ubuntu.yaml`. **Important** Pour déployer un groupe de nœuds sur des sous-réseaux AWS Outposts, AWS Wavelength ou AWS Local Zone, ne transmettez pas les sous-réseaux Outposts AWS , AWS Wavelength ou AWS Local Zone lorsque vous créez le cluster. Vous devez spécifier les sous-réseaux dans l'exemple suivant. Pour plus d'informations, consultez [Créer un nodegroup à partir d'un fichier de configuration](https://eksctl.io/usage/nodegroups/#creating-a-nodegroup-from-a-config-file) et [Schéma du fichier de configuration](https://eksctl.io/usage/schema/) dans la documentation `eksctl`. Remplacez *region-code* par la AWS région dans laquelle se trouve votre cluster. ``` cat >ubuntu.yaml < Quand une nouvelle AMI optimisée pour Amazon EKS est publiée, pensez à remplacer les nœuds autogérés au sein de votre groupe par cette nouvelle AMI. De même, si vous avez mis à jour la version Kubernetes pour votre cluster Amazon EKS, mettez à jour les nœuds afin qu'ils utilisent la même version de Kubernetes. **Important** Cette rubrique couvre les mises à jour des nœuds pour les groupes de nœuds autogérés. Si vous utilisez des [groupes de nœuds gérés](managed-node-groups.md), consultez [Mettre à jour un groupe de nœuds gérés pour votre cluster](update-managed-node-group.md). Deux méthodes de base permettent de mettre à jour les groupes de nœuds autogérés dans vos clusters afin d'utiliser une nouvelle AMI : ** [Migrer des applications vers un nouveau groupe de nœuds](migrate-stack.md) ** Créez un nouveau groupe de nœuds et migrez vos pods vers ce groupe. La migration vers un nouveau groupe de nœuds est plus élégante que la simple mise à jour de l’ID AMI dans une pile AWS CloudFormation existante. En effet, le processus de migration [rejette](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) l’ancien groupe de nœuds en tant que `NoSchedule` et vide les nœuds une fois qu’une nouvelle pile est prête à accepter la charge de travail Pod existante. ** [Mettre à jour une pile de nœuds AWS CloudFormation](update-stack.md) ** Mettez à jour la pile AWS CloudFormation d’un groupe de nœuds existant afin d’utiliser la nouvelle AMI. Cette méthode n’est pas prise en charge pour les groupes de nœuds créés avec `eksctl`. # Migrer des applications vers un nouveau groupe de nœuds Cette rubrique vous explique comment créer un groupe de nœuds, migrer avec élégance vos applications existantes vers ce nouveau groupe, puis supprimer l'ancien groupe de nœuds de votre cluster. Vous pouvez migrer vers un nouveau groupe de nœuds à l'aide de`eksctl` ou de AWS Management Console. + [`eksctl`](#eksctl_migrate_apps) + [AWS Management Console et AWS CLI](#console_migrate_apps) ## `eksctl` **Pour migrer vos applications vers un nouveau groupe de nœuds avec `eksctl`** Pour plus d’informations sur l’utilisation d’eksctl pour la migration, consultez la section [Nœuds non gérés](https://eksctl.io/usage/nodegroup-unmanaged/) dans la documentation `eksctl`. Cette procédure nécessite `eksctl` version `0.215.0` ou ultérieure. Vous pouvez vérifier votre version avec la commande suivante : ``` eksctl version ``` Pour les instructions d'installation ou de mise à niveau de `eksctl`, consultez la rubrique [Installation](https://eksctl.io/installation) dans la documentation `eksctl`. **Note** Cette procédure fonctionne uniquement pour les clusters et les groupes de nœuds créés avec `eksctl`. 1. Récupérez le nom de vos groupes de nœuds existants, en remplaçant *my-cluster* par le nom de votre cluster. ``` eksctl get nodegroups --cluster=my-cluster ``` L'exemple qui suit illustre un résultat. ``` CLUSTER NODEGROUP CREATED MIN SIZE MAX SIZE DESIRED CAPACITY INSTANCE TYPE IMAGE ID default standard-nodes 2019-05-01T22:26:58Z 1 4 3 t3.medium ami-05a71d034119ffc12 ``` 1. Lancez un nouveau groupe de nœuds avec `eksctl` à l'aide de la commande suivante. Dans la commande, remplacez chaque *example value* par vos propres valeurs. Le numéro de version ne peut pas être postérieur à la version Kubernetes pour votre plan de contrôle. De même, il ne peut pas être antérieur de plus de deux versions mineures à la version Kubernetes de votre plan de contrôle. Nous vous recommandons d'utiliser la même version que votre plan de contrôle. Nous recommandons de bloquer l’accès des pods à IMDS si les conditions suivantes sont remplies : + Vous prévoyez d’attribuer des rôles IAM à tous vos comptes de service Kubernetes, afin que les pods ne disposent que des permissions strictement nécessaires. + Aucun pod du cluster n'a besoin d'accéder au service de métadonnées d'instance Amazon EC2 (IMDS) pour d'autres raisons, telles que la récupération de la région actuelle. AWS Pour plus d'informations, consultez [Restreindre l'accès au profil d'instance affecté au composant master](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node). Pour bloquer l’accès des pods à IMDS, ajoutez l’option `--disable-pod-imds` à la commande suivante. **Note** Pour plus d'indicateurs disponibles et leurs descriptions, consultez https://eksctl.io/. ``` eksctl create nodegroup \ --cluster my-cluster \ --version 1.35 \ --name standard-nodes-new \ --node-type t3.medium \ --nodes 3 \ --nodes-min 1 \ --nodes-max 4 \ --managed=false ``` 1. Lorsque la commande précédente se termine, vérifiez que tous vos nœuds ont atteint l'état `Ready` à l'aide de la commande suivante : ``` kubectl get nodes ``` 1. Supprimez le groupe de nœuds d'origine avec la commande suivante. Dans la commande, remplacez chaque *example value* par les noms de votre cluster et de votre groupe de nœuds : ``` eksctl delete nodegroup --cluster my-cluster --name standard-nodes-old ``` ## AWS Management Console et AWS CLI **Migrez vos applications vers un nouveau groupe de nœuds à l'aide de la AWS CLI AWS Management Console et** 1. Lancez un nouveau groupe de nœuds en suivant les étapes décrites dans [Créer des nœuds Amazon Linux autogérés](launch-workers.md). 1. Lorsque la création de votre pile est terminée, sélectionnez la pile dans la console et choisissez **Outputs** (Sorties). 1. Enregistrez le **NodeInstanceRole**pour le groupe de nœuds créé. Vous en aurez besoin pour ajouter les nouveaux nœuds Amazon EKS à votre cluster. **Note** Si vous avez attachés des stratégies IAM supplémentaires au rôle IAM de votre ancien groupe de nœuds, attachez ces mêmes stratégies au rôle IAM de votre nouveau groupe de nœuds pour maintenir cette fonctionnalité sur le nouveau groupe. Cela s'applique si vous avez ajouté des autorisations pour le Kubernetes [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler), par exemple. 1. Mettez à jour les groupes de sécurité pour les deux groupes de nœuds afin qu'ils puissent communiquer entre eux. Pour de plus amples informations, veuillez consulter [Voir les exigences relatives aux groupes de sécurité Amazon EKS pour les clusters](sec-group-reqs.md). 1. Enregistrez le groupe de sécurité IDs pour les deux groupes de nœuds. Ceci est affiché sous forme de **NodeSecurityGroup**valeur dans les sorties de la AWS CloudFormation pile. Vous pouvez utiliser les commandes AWS CLI suivantes pour obtenir le groupe IDs de sécurité à partir des noms de pile. Dans ces commandes, `oldNodes` il s'agit du nom de la AWS CloudFormation pile de votre ancienne pile de nœuds et `newNodes` du nom de la pile vers laquelle vous effectuez la migration. Remplacez chaque *example value* par vos propres valeurs. ``` oldNodes="old_node_CFN_stack_name" newNodes="new_node_CFN_stack_name" oldSecGroup=$(aws cloudformation describe-stack-resources --stack-name $oldNodes \ --query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \ --output text) newSecGroup=$(aws cloudformation describe-stack-resources --stack-name $newNodes \ --query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \ --output text) ``` 1. Ajoutez des règles d'entrée pour chaque groupe de sécurité des nœuds afin d'accepter le trafic de l'autre. Les commandes AWS CLI suivantes ajoutent des règles entrantes à chaque groupe de sécurité qui autorisent tout le trafic sur tous les protocoles en provenance de l'autre groupe de sécurité. Cette configuration permet aux pods au sein de chaque groupe de nœuds peuvent ainsi communiquer entre eux pendant que vous migrez la charge de travail vers le nouveau groupe. ``` aws ec2 authorize-security-group-ingress --group-id $oldSecGroup \ --source-group $newSecGroup --protocol -1 aws ec2 authorize-security-group-ingress --group-id $newSecGroup \ --source-group $oldSecGroup --protocol -1 ``` 1. Modifiez la configmap `aws-auth` afin de mapper le nouveau rôle d'instance des nœuds dans RBAC. ``` kubectl edit configmap -n kube-system aws-auth ``` Ajoutez une nouvelle entrée `mapRoles` pour le nouveau groupe de nœuds. ``` apiVersion: v1 data: mapRoles: | - rolearn: ARN of instance role (not instance profile) username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes> - rolearn: arn:aws: iam::111122223333:role/nodes-1-16-NodeInstanceRole-U11V27W93CX5 username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes ``` Remplacez l'*ARN of instance role (not instance profile)*extrait par la **NodeInstanceRole**valeur que vous avez enregistrée lors d'une étape [précédente](#node-instance-role-step). Ensuite, enregistrez et fermez le fichier pour appliquer le configmap mise à jour. 1. Vérifiez le statut de vos nœuds et attendez que vos nouveaux nœuds rejoignent votre cluster et affichent le statut `Ready`. ``` kubectl get nodes --watch ``` 1. (Facultatif) Si vous utilisez l’outil [Cluster Autoscaler de Kubernetes](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler), réduisez verticalement le déploiement à zéro (0) réplicas afin d’éviter tout conflit entre les actions de mise à l’échelle. ``` kubectl scale deployments/cluster-autoscaler --replicas=0 -n kube-system ``` 1. Utilisez la commande suivante pour rejeter chacun des nœuds que vous souhaitez supprimer avec `NoSchedule`. Ceci afin que les nouveaux pods ne soient pas planifiés ou replanifiés sur les nœuds que vous remplacez. Pour plus d’informations, consultez [Rejets et tolérances](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) dans la documentation de Kubernetes. ``` kubectl taint nodes node_name key=value:NoSchedule ``` Si vous mettez à niveau vos nœuds vers une nouvelle version de Kubernetes, vous pouvez identifier et rejeter tous les nœuds d’une version Kubernetes donnée (dans ce cas, `1.33`) avec le snippet de code suivant. Le numéro de version ne peut pas être postérieur à la version Kubernetes de votre plan de contrôle. Il ne peut pas non plus être antérieur de plus de deux versions mineures à la version Kubernetes de votre plan de contrôle. Nous vous recommandons d'utiliser la même version que votre plan de contrôle. ``` K8S_VERSION=1.33 nodes=$(kubectl get nodes -o jsonpath="{.items[?(@.status.nodeInfo.kubeletVersion==\"v$K8S_VERSION\")].metadata.name}") for node in ${nodes[@]} do echo "Tainting $node" kubectl taint nodes $node key=value:NoSchedule done ``` 1. Déterminez le fournisseur DNS de votre cluster. ``` kubectl get deployments -l k8s-app=kube-dns -n kube-system ``` L'exemple qui suit illustre un résultat. Ce cluster utilise CoreDNS pour la résolution DNS, mais votre cluster peut renvoyer la valeur `kube-dns` à la place) : ``` NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE coredns 1 1 1 1 31m ``` 1. Si votre déploiement actuel exécute moins de deux réplicas, dimensionnez le déploiement à deux réplicas. Remplacez *coredns* par `kubedns` si la sortie de votre commande a plutôt renvoyé cette valeur. ``` kubectl scale deployments/coredns --replicas=2 -n kube-system ``` 1. Drainez chacun des nœuds que vous souhaitez supprimer de votre cluster à l'aide de la commande suivante : ``` kubectl drain node_name --ignore-daemonsets --delete-local-data ``` Si vous mettez à niveau vos nœuds vers une nouvelle version de Kubernetes, identifiez et videz tous les nœuds d'une version particulière de Kubernetes (dans ce cas,*1.33*) à l'aide de l'extrait de code suivant. ``` K8S_VERSION=1.33 nodes=$(kubectl get nodes -o jsonpath="{.items[?(@.status.nodeInfo.kubeletVersion==\"v$K8S_VERSION\")].metadata.name}") for node in ${nodes[@]} do echo "Draining $node" kubectl drain $node --ignore-daemonsets --delete-local-data done ``` 1. Une fois que vos anciens nœuds ont été purgés, révoquez les règles d'entrée du groupe de sécurité que vous avez autorisées précédemment. Supprimez ensuite la AWS CloudFormation pile pour mettre fin aux instances. **Note** Si vous avez associé des politiques IAM supplémentaires à votre ancien rôle IAM de groupe de nœuds, par exemple en ajoutant des autorisations pour le [Kubernetes Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler), détachez-les du rôle avant de supprimer votre stack. AWS CloudFormation 1. Révoquez les règles entrantes que vous aviez créées précédemment pour les groupes de sécurité de vos nœuds. Dans ces commandes, `oldNodes` il s'agit du nom de la AWS CloudFormation pile de votre ancienne pile de nœuds et `newNodes` du nom de la pile vers laquelle vous effectuez la migration. ``` oldNodes="old_node_CFN_stack_name" newNodes="new_node_CFN_stack_name" oldSecGroup=$(aws cloudformation describe-stack-resources --stack-name $oldNodes \ --query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \ --output text) newSecGroup=$(aws cloudformation describe-stack-resources --stack-name $newNodes \ --query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \ --output text) aws ec2 revoke-security-group-ingress --group-id $oldSecGroup \ --source-group $newSecGroup --protocol -1 aws ec2 revoke-security-group-ingress --group-id $newSecGroup \ --source-group $oldSecGroup --protocol -1 ``` 1. Ouvrez la [AWS CloudFormation console](https://console.aws.amazon.com/cloudformation/). 1. Sélectionnez votre ancienne pile de nœuds. 1. Sélectionnez **Delete (Supprimer)**. 1. Dans la boîte de dialogue de confirmation **Delete stack (Supprimer la pile)**, choisissez **Delete stack (Supprimer la pile)**. 1. Modifiez la configmap `aws-auth` afin de supprimer l'ancien rôle d'instance des nœuds dans RBAC. ``` kubectl edit configmap -n kube-system aws-auth ``` Supprimez l'entrée `mapRoles` de l'ancien groupe de nœuds. ``` apiVersion: v1 data: mapRoles: | - rolearn: arn:aws: iam::111122223333:role/nodes-1-16-NodeInstanceRole-W70725MZQFF8 username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes - rolearn: arn:aws: iam::111122223333:role/nodes-1-15-NodeInstanceRole-U11V27W93CX5 username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes> ``` Enregistrez et fermez le fichier afin d'appliquer la configmap mise à jour. 1. (Facultatif) Si vous utilisez le composant [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler) de Kubernetes, dimensionnez le déploiement à un réplica. **Note** Vous devez également labeliser votre nouveau groupe Auto Scaling de façon appropriée (par exemple `k8s.io/cluster-autoscaler/enabled,k8s.io/cluster-autoscaler/my-cluster`) et mettre à jour la commande de votre déploiement Cluster Autoscaler afin qu'elle pointe vers le groupe Auto Scaling nouvellement labelisé. Pour plus d'informations, consultez [Cluster Autoscaler activé. AWS](https://github.com/kubernetes/autoscaler/tree/cluster-autoscaler-release-1.3/cluster-autoscaler/cloudprovider/aws) ``` kubectl scale deployments/cluster-autoscaler --replicas=1 -n kube-system ``` 1. (Facultatif) Vérifiez que vous utilisez la dernière version du [plug-in CNI Amazon VPC pour Kubernetes](https://github.com/aws/amazon-vpc-cni-k8s). Vous devrez peut-être mettre à jour votre version de CNI pour utiliser les derniers types d'instances pris en charge. Pour de plus amples informations, veuillez consulter [Attribuer IPs à des pods avec l'Amazon VPC CNI](managing-vpc-cni.md). 1. Si votre cluster utilise `kube-dns` pour la résolution DNS (voir [[migrate-determine-dns-step]](#migrate-determine-dns-step)), réduisez horizontalement le déploiement `kube-dns` à un réplica. ``` kubectl scale deployments/kube-dns --replicas=1 -n kube-system ``` # Mettre à jour une pile de AWS CloudFormation nœuds Cette rubrique décrit comment mettre à jour une pile de nœuds AWS CloudFormation autogérés existante avec une nouvelle AMI. Vous pouvez utiliser cette procédure pour mettre à jour vos nœuds vers une nouvelle version de Kubernetes suite à une mise à jour du cluster. Sinon, vous pouvez effectuer une mise à jour vers la dernière AMI optimisée pour Amazon EKS pour une version Kubernetes existante. **Important** Cette rubrique couvre les mises à jour des nœuds pour les groupes de nœuds autogérés. Pour plus d’informations sur l’utilisation de [Simplifier le cycle de vie des nœuds avec des groupes de nœuds gérés](managed-node-groups.md), consultez [Mettre à jour un groupe de nœuds gérés pour votre cluster](update-managed-node-group.md). Le dernier AWS CloudFormation modèle de nœud Amazon EKS par défaut est configuré pour lancer une instance avec la nouvelle AMI dans votre cluster avant de supprimer l'ancienne, une par une. Cette configuration garantit que vous disposez toujours du nombre souhaité d’instances actives de votre groupe Auto Scaling dans votre cluster pendant la mise à jour propagée. **Note** Cette méthode n’est pas prise en charge pour les groupes de nœuds créés avec `eksctl`. Si vous avez créé votre cluster ou votre groupe de nœuds avec `eksctl`, consultez [Migrer des applications vers un nouveau groupe de nœuds](migrate-stack.md). 1. Déterminez le fournisseur DNS de votre cluster. ``` kubectl get deployments -l k8s-app=kube-dns -n kube-system ``` L'exemple qui suit illustre un résultat. Ce cluster utilise CoreDNS pour la résolution DNS, mais votre cluster peut renvoyer `kube-dns` à la place. Votre sortie peut être différente selon la version de `kubectl` que vous utilisez. ``` NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE coredns 1 1 1 1 31m ``` 1. Si votre déploiement actuel exécute moins de deux réplicas, dimensionnez le déploiement à deux réplicas. Remplacez *coredns* par `kube-dns` si la sortie de votre commande a plutôt renvoyé cette valeur. ``` kubectl scale deployments/coredns --replicas=2 -n kube-system ``` 1. (Facultatif) Si vous utilisez l’outil [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) de Kubernetes, réduisez verticalement le déploiement à zéro (0) réplicas afin d’éviter tout conflit entre les actions de mise à l’échelle. ``` kubectl scale deployments/cluster-autoscaler --replicas=0 -n kube-system ``` 1. Déterminez le type d’instance et le nombre d’instances souhaité pour votre groupe de nœuds actuel. Vous entrez ces valeurs ultérieurement lorsque vous mettez à jour le AWS CloudFormation modèle du groupe. 1. Ouvrez la console Amazon EC2 à l'adresse. https://console.aws.amazon.com/ec2/ 1. Dans le panneau de navigation de gauche, sélectionnez **Launch Configurations** (Configurations du lancement) et notez le type d'instance pour votre configuration actuelle de lancement des nœuds. 1. Dans le panneau de navigation de gauche, sélectionnez **Auto Scaling Groups** (Groupes Auto Scaling) et notez le nombre d'instances **souhaité** pour le groupe Auto Scaling actuel des nœuds. 1. Ouvrez la [AWS CloudFormation console](https://console.aws.amazon.com/cloudformation/). 1. Sélectionnez votre pile de groupe de nœuds, puis choisissez **Update** (Mettre à jour). 1. Sélectionnez **Replace current template (Remplacer le modèle actuel)** et sélectionnez **Amazon S3 URL (URL Amazon S3)**. 1. Pour **l'URL Amazon S3**, collez l'URL suivante dans la zone de texte pour vous assurer que vous utilisez la dernière version du AWS CloudFormation modèle de nœud. Ensuite, sélectionnez **Next** (Suivant) : ``` https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2022-12-23/amazon-eks-nodegroup.yaml ``` 1. Sur la page **Specify stack details** (Spécifier les détails de la pile), renseignez les paramètres suivants, puis choisissez **Next** (Suivant) : + **NodeAutoScalingGroupDesiredCapacity**— Entrez le nombre d'instances souhaité que vous avez enregistré lors d'une [étape précédente](#existing-worker-settings-step). Ou saisissez le nouveau nombre de nœuds souhaité pour la mise à l'échelle lorsque votre pile sera mise à jour. + **NodeAutoScalingGroupMaxSize**— Entrez le nombre maximum de nœuds auxquels votre groupe Auto Scaling de nœuds peut s'étendre. Cette valeur doit être supérieure d'au moins un nœud à votre capacité souhaitée. Ceci afin de pouvoir effectuer une mise à jour continue de vos nœuds sans réduire votre nombre de nœuds pendant la mise à jour. + **NodeInstanceType**— Choisissez le type d'instance que vous avez enregistré à l'[étape précédente](#existing-worker-settings-step). Vous pouvez également choisir un type d'instance différent pour vos nœuds. Avant de choisir un autre type d’instance, consultez [Choisir un type d’instance de nœud Amazon EC2 optimal](choosing-instance-type.md). Chaque type d'instance Amazon EC2 prend en charge un nombre maximal d'interfaces réseau Elastic (interface réseau) et chaque interface réseau prend en charge un nombre maximal d'adresses IP. Étant donné que chaque composant master et chaque pod se voit attribuer sa propre adresse IP, il est important de choisir un type d’instance qui prendra en charge le nombre maximal de pods que vous voulez exécuter sur chaque nœud Amazon EC2. Pour une liste du nombre d'interfaces réseau et d'adresses IP pris en charge par les types d'instances, consultez [adresses IP par interface réseau et par type d'instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#AvailableIpPerENI). Par exemple, le type d’instance `m5.large` prend en charge un maximum de 30 adresses IP pour le composant master et les pods. **Note** Les types d'instances pris en charge pour la dernière version du [plugin CNI d'Amazon VPC pour Kubernetes](https://github.com/aws/amazon-vpc-cni-k8s) sont indiqués dans [vpc\$1ip\$1resource\$1limit.go](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/pkg/vpc/vpc_ip_resource_limit.go) sur GitHub. Vous devrez peut-être mettre à jour votre plug-in CNI Amazon VPC pour la version Kubernetes afin d’utiliser les derniers types d’instance pris en charge. Pour de plus amples informations, veuillez consulter [Attribuer IPs à des pods avec l'Amazon VPC CNI](managing-vpc-cni.md). **Important** Certains types d'instances peuvent ne pas être disponibles dans toutes les AWS régions. + **NodeImageIdSSMParam**— Le paramètre Amazon EC2 Systems Manager de l'ID AMI vers lequel vous souhaitez effectuer la mise à jour. La valeur suivante utilise la dernière AMI optimisée Amazon EKS pour la version `1.35` de Kubernetes. ``` /aws/service/eks/optimized-ami/1.35/amazon-linux-2/recommended/image_id ``` Vous pouvez le *1.35* remplacer par une [version de plateforme](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html) identique. Ou bien, elle doit être antérieure d'une version au maximum à la version Kubernetes exécutée sur votre plan de contrôle. Nous vous recommandons de conserver vos nœuds dans la même version que votre plan de contrôle. Vous pouvez également le remplacer *amazon-linux-2* par un autre type d'AMI. Pour de plus amples informations, veuillez consulter [Récupérez l'AMI Amazon Linux recommandée IDs](retrieve-ami-id.md). **Note** L'utilisation du paramètre Amazon EC2 Systems Manager vous permet de mettre à jour vos nœuds à l'avenir sans avoir à rechercher et spécifier un ID d'AMI. Si votre AWS CloudFormation stack utilise cette valeur, toute mise à jour de stack lance toujours la dernière AMI optimisée Amazon EKS recommandée pour la version de Kubernetes que vous avez spécifiée. C’est le cas même si vous ne modifiez aucune valeur dans le modèle. + **NodeImageId**— Pour utiliser votre propre AMI personnalisée, entrez l'ID de l'AMI à utiliser. **Important** Cette valeur remplace toute valeur spécifiée pour **NodeImageIdSSMParam**. Si vous souhaitez utiliser la **NodeImageIdSSMParam**valeur, assurez-vous que la valeur pour **NodeImageId**est vide. + **Désactiver IMDSv1** : par défaut, chaque nœud prend en charge les versions 1 du service de métadonnées d'instance (IMDSv1) et IMDSv2. Vous pouvez toutefois le désactiver IMDSv1. Sélectionnez **true** si vous ne souhaitez pas que les nœuds ou les pods planifiés dans le groupe de nœuds soient utilisés IMDSv1. Pour de plus amples informations au sujet d'IMDS, consultez [Configuration du service des métadonnées d'instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html). Si vous avez implémenté des rôles IAM pour les comptes de service, attribuez les autorisations nécessaires directement à tous les pods nécessitant un accès aux AWS services. Ainsi, aucun pod de votre cluster n'a besoin d'accéder à l'IMDS pour d'autres raisons, telles que la récupération de la région actuelle AWS . Ensuite, vous pouvez également désactiver l'accès IMDSv2 aux pods qui n'utilisent pas le réseau hôte. Pour plus d'informations, consultez [Restreindre l'accès au profil d'instance affecté au composant master](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node). 1. (Facultatif) Sur la page **Options (Options)**, étiquetez les ressources de votre pile. Choisissez **Suivant**. 1. Sur la page **Review** (Vérification), vérifiez vos informations, acceptez que la pile puisse créer des ressources IAM, puis choisissez **Update stack** (Mettre à jour la pile). **Note** La mise à jour de chaque nœud du cluster prend plusieurs minutes. Attendez que la mise à jour de tous les nœuds soit terminée avant d'effectuer les étapes suivantes. 1. Si le fournisseur DNS de votre cluster est `kube-dns`, réduisez horizontalement le déploiement `kube-dns` à une réplica. ``` kubectl scale deployments/kube-dns --replicas=1 -n kube-system ``` 1. (Facultatif) Si vous utilisez le composant [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) de Kubernetes, redimensionnez le déploiement à la quantité souhaitée de réplicas. ``` kubectl scale deployments/cluster-autoscaler --replicas=1 -n kube-system ``` 1. (Facultatif) Vérifiez que vous utilisez la dernière version du [plug-in CNI Amazon VPC pour Kubernetes](https://github.com/aws/amazon-vpc-cni-k8s). Vous devrez peut-être mettre à jour votre plug-in CNI Amazon VPC pour la version Kubernetes afin d’utiliser les derniers types d’instance pris en charge. Pour de plus amples informations, veuillez consulter [Attribuer IPs à des pods avec l'Amazon VPC CNI](managing-vpc-cni.md). # Simplifiez la gestion des calculs avec AWS Fargate Cette rubrique porte sur l’utilisation d’Amazon EKS pour exécuter les pods Kubernetes sur AWS Fargate. Fargate est une technologie qui fournit une capacité de calcul à la demande et de taille appropriée pour les [conteneurs](https://aws.amazon.com/what-are-containers). Avec Fargate, il n’est pas nécessaire d’allouer, de configurer ou de mettre à l’échelle des groupes de machines virtuelles pour exécuter les conteneurs. Vous n’avez plus à choisir les types de serveurs, à décider quand vos clusters de nœuds doivent être mis à l’échelle, ni à optimiser les packs de clusters. Vous pouvez contrôler les pods qui démarrent sur Fargate et la manière dont ils s’exécutent avec des [profils Fargate](fargate-profile.md). Les profils Fargate sont définis dans le cadre de votre cluster Amazon EKS. Amazon EKS intègre Kubernetes à Fargate à l’aide des contrôleurs créés par AWS en utilisant le modèle extensible en amont fourni par Kubernetes. Ces contrôleurs font partie du plan de contrôle Kubernetes géré par Amazon EKS et sont responsables de la planification des pods Kubernetes natifs sur Fargate. Les contrôleurs Fargate comprennent un nouveau planificateur qui s'exécute parallèlement au planificateur Kubernetes par défaut, en plus de plusieurs contrôleurs d'admission mutants et validants. Lorsque vous démarrez un pod qui répond aux critères d’exécution sur Fargate, les contrôleurs Fargate qui fonctionnent dans le cluster reconnaissent, mettent à jour et planifient le pod sur Fargate. Cette rubrique décrit les différents composants des pods qui s’exécutent sur Fargate, et appelle à des considérations particulières pour l’utilisation de Fargate avec Amazon EKS. ## Considérations relatives à AWS Fargate Voici quelques éléments à prendre en compte pour l'utilisation de Fargate sur Amazon EKS. + Chaque pod fonctionnant sur Fargate a sa propre limite de calcul. Les nœuds ne partagent pas le noyau sous-jacent, les ressources CPU, les ressources mémoire ou l’interface réseau Elastic avec un autre pod. + Les Network Load Balancers et les Application Load Balancers (ALB) peuvent être utilisés avec Fargate avec des cibles IP uniquement. Pour plus d’informations, consultez [Créer un équilibreur de charge de réseau](network-load-balancing.md#network-load-balancer) et [Routage du trafic des applications et du trafic HTTP avec des équilibreurs de charge Application Load Balancer](alb-ingress.md). + Les services exposés de Fargate s'exécutent uniquement en mode IP de type cible, et non en mode IP de nœud. La manière recommandée de vérifier la connectivité entre un service s'exécutant sur un nœud géré et un service s'exécutant sur Fargate est de se connecter via le nom du service. + Les pods doivent correspondre à un profil Fargate au moment où ils sont programmés pour fonctionner sur Fargate. Les pods qui ne correspondent pas à un profil Fargate peuvent être bloqués comme `Pending`. Si un profil Fargate correspondant existe, vous pouvez supprimer les pods en attente que vous avez créés pour les reprogrammer sur Fargate. + Les DaemonSets ne sont pas pris en charge sur Fargate. Si votre application nécessite un démon, reconfigurez ce démon pour qu’il s’exécute en tant que conteneur secondaire dans vos pods. + Les conteneurs privilégiés ne sont pas pris en charge sur Fargate. + Les pods fonctionnant sur Fargate ne peuvent pas spécifier `HostPort` ou `HostNetwork` dans le manifeste du pod. + La limite logicielle par défaut `nofile` et `nproc` est de 1 024 et la limite matérielle est de 65 535 pour les pods Fargate. + Les GPU ne sont actuellement pas disponibles sur Fargate. + Les pods qui fonctionnent sur Fargate ne sont pris en charge que sur des sous-réseaux privés (avec un accès aux services AWS par passerelle NAT, mais sans route directe vers une passerelle Internet). Le VPC de votre cluster doit donc disposer de sous-réseaux privés. Pour les clusters sans accès Internet sortant, veuillez consulter [Déployer des clusters privés avec un accès Internet limité](private-clusters.md). + Vous pouvez utiliser la fonctionnalité [Ajuster les ressources des pods avec Vertical Pod Autoscaler](vertical-pod-autoscaler.md) pour définir la taille initiale correcte du processeur et de la mémoire pour vos pods Fargate, puis utiliser la fonctionnalité [Mettre à l’échelle les déploiements de pods avec Horizontal Pod Autoscaler](horizontal-pod-autoscaler.md) pour mettre à l’échelle ces pods. Si vous souhaitez que le Vertical Pod Autoscaler redéploie automatiquement les pods vers Fargate avec des combinaisons de CPU et de mémoire plus importantes, définissez le mode de Vertical Pod Autoscale sur `Auto` ou `Recreate` pour garantir une fonctionnalité correcte. Pour plus d'informations, consultez la documentation [Vertical Pod Autoscaler (VPA)](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#quick-start) sur GitHub. + La résolution DNS et les noms d'hôte DNS doivent être activés pour votre VPC. Pour plus d'informations, consultez [Affichage et mise à jour de la prise en charge de DNS pour votre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating). + Amazon EKS Fargate ajoute une défense approfondie aux applications Kubernetes en isolant chaque pod au sein d'une machine virtuelle (VM). Cette frontière VM empêche l'accès aux ressources basées sur l'hôte utilisées par d'autres pods en cas de fuite du conteneur, qui est une méthode courante d'attaque des applications conteneurisées et d'accès aux ressources en dehors du conteneur. L’utilisation d’Amazon EKS ne modifie pas vos responsabilités dans le cadre du [modèle de responsabilité partagée](security.md). Vous devez examiner attentivement la configuration des contrôles de sécurité et de gouvernance du cluster. Le moyen le plus sûr d'isoler une application est toujours de l'exécuter dans un cluster séparé. + Les profils Fargate prennent en charge la spécification de sous-réseaux à partir de blocs CIDR secondaires de VPC. Vous pouvez spécifier un bloc CIDR secondaire. En effet, le nombre d’adresses IP disponibles dans un sous-réseau est limité. Par conséquent, il existe également un nombre limité de pods qui peuvent être créés dans le cluster. En utilisant différents sous-réseaux pour les pods, vous pouvez augmenter le nombre d’adresses IP disponibles. Pour plus d'informations, consultez [Ajout de blocs d'adresse CIDR IPv4 à un VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html#vpc-resize). + Le service de métadonnées d’instance Amazon EC2 (IMDS) n’est pas disponible pour les pods qui sont déployés sur des nœuds Fargate. Si vous avez des pods déployés sur Fargate qui nécessitent des informations d’identification IAM, attribuez-les à vos pods à l’aide des [rôles IAM pour les comptes de service](iam-roles-for-service-accounts.md). Si vos pods ont besoin d’accéder à d’autres informations disponibles via IMDS, vous devez coder ces informations en dur dans la spécification de votre pod. Cela inclut la région AWS ou la zone de disponibilité dans laquelle un pod est déployé. + Vous ne pouvez pas déployer de pods Fargate sur AWS Outposts, AWS Wavelength ou AWS Local Zones. + Amazon EKS doit régulièrement appliquer des correctifs aux pods Fargate pour assurer leur sécurité. Les tentatives de mises à jour sont réalisées de manière à réduire les potentielles répercussions ; toutefois, il arrive que des pods doivent être supprimés si leur expulsion a échoué. Certaines actions peuvent être prises pour minimiser les perturbations. Pour de plus amples informations, consultez [Définir des actions pour les événements de correction du système d’exploitation AWS Fargate](fargate-pod-patching.md). + Le [pluginAmazon VPC CNI pour Amazon EKS](https://github.com/aws/amazon-vpc-cni-plugins) est installé sur des nœuds Fargate. Vous ne pouvez pas utiliser les [plugins Alternate CNI pour les clusters Amazon EKS](alternate-cni-plugins.md) avec des nœuds Fargate. + Un Pod fonctionnant sur Fargate monte automatiquement un système de fichiers Amazon EFS, sans nécessiter d’étapes manuelles d’installation de pilotes. Vous ne pouvez pas utiliser l’approvisionnement dynamique des volumes persistants avec les nœuds Fargate, mais vous pouvez utiliser l’approvisionnement statique. + Amazon EKS ne prend pas en charge Fargate Spot. + Vous ne pouvez pas monter des volumes Amazon EBS sur des pods Fargate. + Vous pouvez exécuter le contrôleur Amazon EBS CSI sur les nœuds Fargate, mais le DaemonSet du nœud Amazon EBS CSI ne peut fonctionner que sur les instances Amazon EC2. + Une fois qu’une [tâche Kubernetes](https://kubernetes.io/docs/concepts/workloads/controllers/job/) est marquée `Completed` ou `Failed`, les pods créés par la tâche continuent généralement d’exister. Ce comportement vous permet de consulter vos journaux et vos résultats, mais avec Fargate, vous devrez payer des frais si vous ne nettoyez pas le travail après coup. Pour supprimer automatiquement les pods associés après l’exécution ou l’échec d’une tâche, vous pouvez spécifier une durée à l’aide du contrôleur TTL (time-to-live). L’exemple suivant montre comment spécifier `.spec.ttlSecondsAfterFinished` dans votre manifeste de tâche. ``` apiVersion: batch/v1 kind: Job metadata: name: busybox spec: template: spec: containers: - name: busybox image: busybox command: ["/bin/sh", "-c", "sleep 10"] restartPolicy: Never ttlSecondsAfterFinished: 60 # <-- TTL controller ``` ## Tableau de comparaison de Fargate | Critères | AWS Fargate | | --- | --- | | Peut être déployé dans [AWS Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html) | Non | | Possibilité d'être déployé dans une [zone locale AWS](local-zones.md) | Non | | Possibilité d'exécuter des conteneurs qui nécessitent Windows | Non | | Possibilité d'exécuter des conteneurs qui nécessitent Linux | Oui | | Possibilité d'exécuter des applications nécessitant la puce Inferentia | Non | | Possibilité d'exécuter des applications nécessitant un GPU | Non | | Possibilité d'exécuter des applications nécessitant des processeurs Arm | Non | | Possibilité d'exécuter AWS [Bottlerocket](https://aws.amazon.com/bottlerocket/) | Non | | Les pods partagent un environnement d’exécution du noyau avec d’autres pods | Non : chaque pod a un noyau dédié | | Les pods partagent le processeur, la mémoire, le stockage et les ressources réseau avec d’autres pods. | Non : chaque pod dispose de ressources dédiées et peut être dimensionné indépendamment pour optimiser l’utilisation des ressources. | | Les pods peuvent utiliser plus de matériel et de mémoire que demandé dans les spécifications des pods | Non : le pod peut toutefois être redéployé à l’aide d’une plus grande configuration de vCPU et de mémoire. | | Doit déployer et gérer des instances Amazon EC2 | Non | | Doit sécuriser, entretenir et corriger le système d'exploitation des instances Amazon EC2 | Non | | Peut fournir des arguments bootstrap lors du déploiement d’un nœud, tels que des arguments [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) supplémentaires. | Non | | Possibilité d’affecter des adresses IP à des pods à partir d’un bloc d’adresse CIDR différent de l’adresse IP affectée au nœud. | Non | | Possibilité d'accéder au nœud via SSH | Non : il n’y a pas de système d’exploitation hôte de nœud auquel se connecter par SSH. | | Possibilité de déployer votre propre AMI personnalisée sur les nœuds | Non | | Possibilité de déployer votre propre CNI personnalisée sur les nœuds | Non | | Vous devez mettre à jour l'AMI du nœud par vous-même | Non | | Vous devez mettre à jour la version du nœud Kubernetes par vous-même | Non : vous ne gérez pas les nœuds. | | Possibilité d’utiliser le stockage Amazon EBS avec des pods | Non | | Possibilité d’utiliser le stockage Amazon EFS avec des pods | [Oui](efs-csi.md) | | Possibilité d’utiliser le stockage Amazon FSx pour Lustre avec des pods | Non | | Possibilité d'utiliser le Network Load Balancer pour les services | Oui, lors de l’utilisation de la fonction [Créer un Network Load Balancer](network-load-balancing.md#network-load-balancer) | | Les pods peuvent s'exécuter dans un sous-réseau public | Non | | Possibilité d’affecter différents groupes de sécurité VPC à des pods individuels | Oui | | Possibilité d'exécuter des ensembles de démons Kubernetes | Non | | Prend en charge `HostPort` et `HostNetwork` dans le manifeste du pod | Non | | AWS : disponibilité dans les régions | [Quelques régions prises en charge par Amazon EKS](https://docs.aws.amazon.com/general/latest/gr/eks.html) | | Possibilité d'exécuter des conteneurs sur des hôtes dédiés Amazon EC2 | Non | | Tarification | Coût d'une mémoire Fargate individuelle et d'une configuration CPU. Chaque pod a son propre coût. Pour plus d'informations, consultez [Tarification de AWS Fargate](https://aws.amazon.com/fargate/pricing/). | # Commencez à utiliser AWS Fargate pour votre cluster Cette rubrique explique comment commencer à exécuter des pods sur AWS Fargate avec votre cluster Amazon EKS. Si vous limitez l'accès au point de terminaison public de votre cluster à l'aide de blocs CIDR, nous vous recommandons d'activer également l'accès au point de terminaison privé. De cette manière, les pods Fargate peuvent communiquer avec le cluster. Sans l'activation du point de terminaison privé, les blocs CIDR que vous spécifiez pour l'accès public doivent inclure les sources de sortie de votre VPC. Pour de plus amples informations, veuillez consulter [Point de terminaison du serveur d’API du cluster](cluster-endpoint.md). **Prérequis** Un cluster existant. Si vous ne disposez pas déjà d’un cluster Amazon EKS, consultez [Mise en route avec Amazon EKS](getting-started.md). ## Étape 1 : s’assurer que les nœuds existants peuvent communiquer avec les pods Fargate Si vous travaillez avec un nouveau cluster sans nœuds ou un cluster comportant uniquement des groupes de nœuds gérés (voir [Simplifiez le cycle de vie des nœuds avec des groupes de nœuds gérés](managed-node-groups.md)), vous pouvez passer à [Étape 2 : créer un rôle d’exécution Fargate Pod](#fargate-sg-pod-execution-role). Supposons que vous travaillez avec un cluster existant ayant déjà des nœuds associés. Assurez-vous que les pods sur ces nœuds peuvent communiquer librement avec les pods qui s’exécutent sur Fargate. Les pods qui s’exécutent sur Fargate sont automatiquement configurés pour utiliser le groupe de sécurité du cluster auquel ils sont associés. Assurez-vous que tous les nœuds existants dans votre cluster peuvent envoyer et recevoir du trafic vers et depuis le groupe de sécurité du cluster. Les groupes de nœuds gérés sont automatiquement configurés pour utiliser également le groupe de sécurité du cluster. Vous n’avez donc pas besoin de les modifier ou de vérifier leur compatibilité (voir [Simplifiez le cycle de vie des nœuds avec des groupes de nœuds gérés](managed-node-groups.md)). Pour les groupes de nœuds existants créés avec `eksctl` ou avec les AWS CloudFormation modèles gérés par Amazon EKS, vous pouvez ajouter le groupe de sécurité du cluster aux nœuds manuellement. Vous pouvez également modifier le modèle de lancement du groupe Auto Scaling pour le groupe de nœuds, afin d'attacher le groupe de sécurité du cluster aux instances. Pour plus d’informations, consultez [Modification des groupes de sécurité d’une instance](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#SG_Changing_Group_Membership) dans le *Guide de l’utilisateur VPC Amazon*. Vous pouvez rechercher un groupe de sécurité pour votre cluster dans la AWS Management Console section **Mise en réseau** du cluster. Vous pouvez également le faire à l'aide de la commande AWS CLI suivante. Lorsque vous utilisez cette commande, remplacez `` par le nom de votre cluster. ``` aws eks describe-cluster --name --query cluster.resourcesVpcConfig.clusterSecurityGroupId ``` ## Étape 2 : créer un rôle d’exécution Fargate Pod Lorsque votre cluster crée des pods sur AWS Fargate, les composants qui s'exécutent sur l'infrastructure Fargate doivent effectuer des appels en votre nom. AWS APIs Pour ce faire, le rôle d’exécution de pod Amazon EKS fournit les autorisations IAM. Pour créer un rôle d'exécution AWS Fargate Pod, consultez. [Rôle IAM d’exécution de pod Amazon EKS](pod-execution-role.md) **Note** Si vous avez créé votre cluster avec `eksctl` à l’aide de l’option `--fargate`, votre cluster comporte déjà un rôle d’exécution de pod que vous pouvez trouver dans la console IAM en utilisant `eksctl-my-cluster-FargatePodExecutionRole-ABCDEFGHIJKL`. De même, si vous utilisez `eksctl` pour créer vos profils Fargate, `eksctl` créera votre rôle d’exécution de pod si celui-ci n’existe pas déjà. ## Étape 3 : créer un profil Fargate pour votre cluster Avant de pouvoir planifier des pods s’exécutant sur Fargate dans votre cluster, vous devez définir un profil Fargate qui spécifie quels pods utilisent Fargate lorsqu’ils sont lancés. Pour de plus amples informations, veuillez consulter [Définissez quels pods utilisent AWS Fargate lors de leur lancement](fargate-profile.md). **Note** Si vous avez créé votre cluster avec `eksctl` à l’aide de l’option `--fargate`, un profil Fargate est déjà créé pour votre cluster avec des sélecteurs pour tous les pods dans les espaces de noms `kube-system` et `default`. Utilisez la procédure suivante pour créer des profils Fargate pour tout autre espace de noms que vous souhaitez utiliser avec Fargate. Vous pouvez créer un profil Fargate en utilisant l’un des outils suivants : + [`eksctl`](#eksctl_fargate_profile_create) + [AWS Management Console](#console_fargate_profile_create) ### `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`. **Pour créer un profil Fargate avec `eksctl` ** Créez votre profil Fargate avec la commande `eksctl` suivante, en remplaçant chaque `` par vos propres valeurs. Vous devez spécifier un espace de noms. Cependant, l’option `--labels` n’est pas obligatoire. ``` eksctl create fargateprofile \ --cluster \ --name \ --namespace \ --labels ``` Vous pouvez utiliser certains caractères génériques pour les étiquettes `` et ``. Pour de plus amples informations, veuillez consulter [Caractères génériques du profil Fargate](fargate-profile.md#fargate-profile-wildcards). ### AWS Management Console **Pour créer un profil Fargate avec AWS Management Console ** 1. Ouvrez la [console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters). 1. Choisissez le cluster pour lequel vous voulez créer un profil Fargate. 1. Choisissez l'onglet **Calcul**. 1. Sous **Fargate profiles** (Profils Fargate), choisissez **Add Fargate profile** (Ajouter un profil Fargate). 1. Sur la page **Configure Fargate profile (Configurer le profil Fargate)**, procédez comme suit : 1. Dans **Nom**, saisissez un nom pour votre profil Fargate. Le nom doit être unique. 1. Pour le **rôle d’exécution du pod**, choisissez le rôle d’exécution du pod à utiliser avec votre profil Fargate. Seuls les rôles IAM avec le principal de service `eks-fargate-pods.amazonaws.com` sont affichés. Si vous ne voyez aucun rôle répertorié ici, vous devez en créer un. Pour de plus amples informations, veuillez consulter [Rôle IAM d’exécution de pod Amazon EKS](pod-execution-role.md). 1. Modifiez les **sous-réseaux** sélectionnés selon vos besoins. **Note** Seuls les sous-réseaux privés sont pris en charge pour les pods qui s’exécutent sur Fargate. 1. Dans **Identifications**, vous pouvez éventuellement étiqueter votre profil Fargate. Ces balises ne se propagent pas aux autres ressources qui sont associées au profil, comme les pods. 1. Choisissez **Suivant**. 1. Sur la page **Configurer la sélection de pod**, procédez comme suit : 1. Pour **l’espace de noms**, saisissez un espace de noms correspondant aux pods. + Vous pouvez utiliser des espaces de noms spécifiques pour les faire correspondre, tels que `kube-system` ou `default`. + Vous pouvez utiliser certains caractères génériques (par exemple, `prod-*`) pour faire correspondre plusieurs espaces de noms (par exemple, `prod-deployment` et `prod-test`). Pour de plus amples informations, veuillez consulter [Caractères génériques du profil Fargate](fargate-profile.md#fargate-profile-wildcards). 1. (Facultatif) Ajoutez des labels Kubernetes au sélecteur. Ajoutez-les spécifiquement à celui auquel les pods de l’espace de noms spécifié doivent correspondre. + Vous pouvez ajouter la balise `infrastructure: fargate` au sélecteur afin que seuls les pods de l’espace de noms spécifié qui possèdent également la balise Kubernetes `infrastructure: fargate` correspondent au sélecteur. + Vous pouvez utiliser certains caractères génériques (par exemple, `key?: value?`) pour faire correspondre plusieurs espaces de noms (par exemple, `keya: valuea` et `keyb: valueb`). Pour de plus amples informations, veuillez consulter [Caractères génériques du profil Fargate](fargate-profile.md#fargate-profile-wildcards). 1. Choisissez **Suivant**. 1. Sur la page **Vérifier et créer**, vérifiez les informations de votre profil Fargate et choisissez **Créer**. ## Étape 4 : mettre à jour CoreDNS Par défaut, CoreDNS est configuré pour s'exécuter sur l' EC2 infrastructure Amazon sur des clusters Amazon EKS. Si vous souhaitez *uniquement* exécuter vos pods sur Fargate dans votre cluster, effectuez les étapes suivantes. **Note** Si vous avez créé votre cluster à l'aide de `eksctl` en utilisant l'option `--fargate`, vous pouvez passer directement à [Étapes suivantes](#fargate-gs-next-steps). 1. Créez un profil Fargate pour CoreDNS à l’aide de la commande suivante. Remplacez-le `` par le nom de votre cluster, `<111122223333>` par votre identifiant de compte, `` par le nom de votre rôle d'exécution de Pod et `<000000000000000c>` par le nom IDs de vos sous-réseaux privés. `<000000000000000a>` `<000000000000000b>` Si vous ne disposez pas d’un rôle d’exécution Pod, vous devez d’abord en créer un (voir [Étape 2 : créer un rôle d’exécution Fargate Pod](#fargate-sg-pod-execution-role)). **Important** L’ARN de rôle ne peut pas inclure un [chemin d’accès](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-friendly-names) autre que `/`. Par exemple, si le nom de votre rôle est `development/apps/AmazonEKSFargatePodExecutionRole`, vous devez le remplacer par `AmazonEKSFargatePodExecutionRole` lorsque vous spécifiez l'ARN du rôle. Le format de l'ARN de rôle doit être ` arn:aws: iam::<111122223333>:role/`. ``` aws eks create-fargate-profile \ --fargate-profile-name coredns \ --cluster-name \ --pod-execution-role-arn arn:aws: iam::<111122223333>:role/ \ --selectors namespace=kube-system,labels={k8s-app=kube-dns} \ --subnets subnet-<000000000000000a> subnet-<000000000000000b> subnet-<000000000000000c> ``` 1. Déclenchez le déploiement du déploiement `coredns`. ``` kubectl rollout restart -n kube-system deployment coredns ``` ## Étapes suivantes + Vous pouvez commencer à migrer vos applications existantes pour les exécuter sur Fargate avec le flux suivant. 1. [Créer un profil Fargate](fargate-profile.md#create-fargate-profile) qui correspond à l’espace de noms Kubernetes et aux étiquettes Kubernetes de votre application. 1. Supprimez et recréez tous les pods existants afin qu’ils soient planifiés sur Fargate. Modifiez le `` et `` pour mettre à jour vos pods spécifiques. ``` kubectl rollout restart -n deployment ``` + Déployez [Routage du trafic des applications et du trafic HTTP avec des équilibreurs de charge Application Load Balancer](alb-ingress.md) pour autoriser les objets d’entrée pour vos pods fonctionnant sur Fargate. + Vous pouvez utiliser le [Ajuster les ressources des pods avec Vertical Pod Autoscaler](vertical-pod-autoscaler.md) pour définir la taille initiale correcte du processeur et de la mémoire pour vos pods Fargate, puis utiliser le [Déployez des pods à l’échelle avec Horizontal Pod Autoscaler](horizontal-pod-autoscaler.md) pour faire évoluer ces pods. Si vous souhaitez que Vertical Pod Autoscaler redéploie automatiquement les pods vers Fargate avec des combinaisons de CPU et de mémoire plus élevées, définissez le mode de Vertical Pod Autoscaler sur `Auto` ou `Recreate`. Ceci permet de garantir une fonctionnalité correcte. Pour plus d'informations, consultez la documentation [Vertical Pod Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#quick-start) sur GitHub. + Vous pouvez configurer le collecteur [AWS Distro pour OpenTelemetry](https://aws.amazon.com/otel) (ADOT) pour la surveillance des applications en suivant [ces instructions](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-EKS-otel.html). # Définissez quels pods utilisent AWS Fargate lors de leur lancement Avant de planifier des pods sur Fargate dans votre cluster, vous devez définir au moins un profil Fargate qui spécifie quels pods utilisent Fargate lors de leur lancement. En tant qu’administrateur, vous pouvez utiliser un profil Fargate pour déclarer quels pods s’exécutent sur Fargate. Vous pouvez faire cela via les sélecteurs du profil. Vous pouvez ajouter jusqu'à cinq sélecteurs à chaque profil. Chaque sélecteur doit contenir un espace de noms. Le sélecteur peut également inclure des étiquettes. Le champ de label se compose de plusieurs paires clé-valeur facultatives. Les pods qui correspondent à un sélecteur sont programmés sur Fargate. Les pods sont associés à l'aide d'un espace de noms et des étiquettes spécifiées dans le sélecteur. Si un sélecteur d’espace de noms est défini sans étiquettes, Amazon EKS tente de planifier tous les pods qui s’exécutent dans cet espace de noms sur Fargate à l’aide du profil. Si un pod à planifier correspond à l’un des sélecteurs du profil Fargate, ce pod est planifié sur Fargate. Si un pod correspond à plusieurs profils Fargate, vous pouvez spécifier le profil utilisé par le pod en ajoutant le label Kubernetes suivant à la spécification du pod : `eks.amazonaws.com/fargate-profile: my-fargate-profile`. Le Pod doit correspondre à un sélecteur dans ce profil pour être planifié sur Fargate. Les règles d’affinité/anti-affinité Kubernetes ne s’appliquent pas et ne sont pas nécessaires avec les pods Amazon EKS Fargate. Lorsque vous créez un profil Fargate, vous devez spécifier un rôle d’exécution de pod. Ce rôle d'exécution concerne les composants Amazon EKS qui s'exécutent sur l'infrastructure Fargate utilisant le profil. Il est ajouté au [contrôle d’accès basé sur les rôles](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) (RBAC) Kubernetes du cluster pour l’autorisation. Ainsi, le `kubelet` qui est exécuté sur l'infrastructure Fargate peut s'enregistrer dans votre cluster Amazon EKS et apparaître dans votre cluster comme un nœud. Le rôle d’exécution du pod fournit également des autorisations IAM à l’infrastructure Fargate pour permettre un accès en lecture aux référentiels d’images Amazon ECR. Pour de plus amples informations, consultez [Rôle IAM d’exécution de pod Amazon EKS](pod-execution-role.md). Les profils Fargate ne peuvent pas être modifiés. Toutefois, vous pouvez créer un nouveau profil mis à jour pour remplacer un profil existant, puis supprimer l'original. **Note** Tous les pods qui s’exécutent à l’aide d’un profil Fargate sont arrêtés et placés en attente lorsque le profil est supprimé. Si tous les profils Fargate d'un cluster ont l'état `DELETING`, vous devez attendre que ce profil Fargate soit définitivement supprimé avant de pouvoir créer d'autres profils dans ce cluster. **Note** Fargate ne prend actuellement pas en charge Kubernetes [TopologySpreadConstraints](https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/). Amazon EKS et Fargate répartissent les pods entre chacun des sous-réseaux définis dans le profil Fargate. Cependant, vous risquez de vous retrouver avec une répartition inégale. Si vous avez besoin d'une répartition uniforme, utilisez deux profils Fargate. Une répartition uniforme est importante dans les scénarios où vous souhaitez déployer deux réplicas sans aucune durée d’indisponibilité. Nous vous recommandons de n'avoir qu'un seul sous-réseau pour chaque profil. ## Composants de profil Fargate Les composants suivants sont contenus dans un profil Fargate. **Rôle d'exécution du pod** Lorsque votre cluster crée des pods sur AWS Fargate, le `kubelet` qui s’exécute sur l’infrastructure Fargate doit effectuer des appels vers les API AWS en votre nom. Par exemple, il doit effectuer des appels pour extraire des images de conteneur à partir d'Amazon ECR. Pour ce faire, le rôle d’exécution de pod Amazon EKS fournit les autorisations IAM. Lorsque vous créez un profil Fargate, vous devez spécifier un rôle d’exécution de pods à utiliser avec vos pods. Ce rôle est ajouté au [contrôle d’accès basé sur les rôles](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) (RBAC) Kubernetes du cluster à des fins d’autorisation. Ainsi, le `kubelet` exécuté sur l’infrastructure Fargate peut s’enregistrer dans votre cluster Amazon EKS et apparaître dans votre cluster comme un nœud. Pour de plus amples informations, consultez [Rôle IAM d’exécution de pod Amazon EKS](pod-execution-role.md). **Sous-réseaux** Les ID des sous-réseaux poury lancer des pods utilisent ce profil. Pour l’instant, les pods fonctionnant sur Fargate n’ont pas d’adresse IP publique. Par conséquent, seuls les sous-réseaux privés sans route directe vers une passerelle Internet sont acceptés pour ce paramètre. **Sélecteurs** Les sélecteurs à faire correspondre pour que les pods utilisent ce profil Fargate. Vous pouvez spécifier jusqu'à cinq sélecteurs dans un profil Fargate. Les sélecteurs intègrent les composants suivants : + **Espace de noms** : vous devez spécifier un espace de noms pour un sélecteur. Le sélecteur ne correspond qu’aux pods créés dans cet espace de noms. Vous pouvez toutefois créer plusieurs sélecteurs pour cibler plusieurs espaces de noms. + **Labels** : vous pouvez éventuellement spécifier des labels Kubernetes à faire correspondre pour le sélecteur. Le sélecteur ne correspond qu’aux pods qui possèdent tous les labels spécifiés dans le sélecteur. ## Caractères génériques du profil Fargate En plus des caractères autorisés par Kubernetes, vous pouvez utiliser `*` et `?` dans les critères de sélection pour les espaces de noms, les clés d’étiquette et les valeurs d’étiquette : + `*` représente aucun, un ou plusieurs caractères. Par exemple, `prod*` peut représenter `prod` et `prod-metrics`. + `?` représente un caractère unique (par exemple, `value?` peut représenter `valuea`). Cependant, il ne peut pas représenter `value` et `value-a`, parce que `?` ne peut représenter qu'un seul et unique caractère. Ces caractères génériques peuvent être utilisés dans n'importe quelle position et en combinaison (par exemple, `prod*`, `*dev` et `frontend*?`). Les autres caractères génériques et formes de correspondance de modèles, tels que les expressions régulières, ne sont pas pris en charge. S’il existe plusieurs profils correspondants pour l’espace de noms et les étiquettes dans la spécification du pod, Fargate sélectionne le profil avec un tri alphanumérique par nom de profil. Par exemple, si les deux profils A (avec le nom `beta-workload`) et le profil B (avec le nom `prod-workload`) ont des sélecteurs correspondants pour les pods à lancer, Fargate choisit le profil A (`beta-workload`) pour les pods. Les pods ont des étiquettes avec le profil A sur les pods (par exemple, `eks.amazonaws.com/fargate-profile=beta-workload`). Si vous souhaitez migrer des pods Fargate existants vers de nouveaux profils qui utilisent des caractères génériques, vous pouvez procéder de deux manières : + Créez un nouveau profil avec les sélecteurs correspondants, puis supprimez les anciens profils. Les pods étiquetés avec d'anciens profils sont reprogrammés vers de nouveaux profils correspondants. + Si vous souhaitez migrer des charges de travail mais que vous ne savez pas quelles étiquettes Fargate figurent sur chaque pod Fargate, vous pouvez utiliser la méthode suivante. Créez un nouveau profil avec un nom qui trie d'abord par ordre alphanumérique parmi les profils du même cluster. Recyclez ensuite les pods Fargate qui doivent être migrés vers de nouveaux profils. ## Créer un profil Fargate Cette section décrit comment créer un profil Fargate. Vous devez également avoir créé un rôle d’exécution de pod à utiliser pour votre profil Fargate. Pour de plus amples informations, consultez [Rôle IAM d’exécution de pod Amazon EKS](pod-execution-role.md). Les pods qui s’exécutent sur Fargate ne sont pris en charge que sur les sous-réseaux privés avec accès [NAT Gateway](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) aux services AWS, mais pas sur une route directe vers une passerelle Internet. Le VPC de votre cluster doit donc disposer de sous-réseaux privés. Vous pouvez créer un profil avec les éléments suivants : + [`eksctl`](#eksctl_create_a_fargate_profile) + [AWS Management Console](#console_create_a_fargate_profile) ## `eksctl` **Pour créer un profil Fargate avec `eksctl` ** Créez votre profil Fargate à l’aide de la commande `eksctl` suivante, en remplaçant chaque valeur d’exemple par vos propres valeurs. Vous devez spécifier un espace de noms. Cependant, l’option `--labels` n’est pas obligatoire. ``` eksctl create fargateprofile \ --cluster my-cluster \ --name my-fargate-profile \ --namespace my-kubernetes-namespace \ --labels key=value ``` Vous pouvez utiliser certains caractères génériques pour les étiquettes `my-kubernetes-namespace` et `key=value`. Pour de plus amples informations, consultez [Caractères génériques du profil Fargate](#fargate-profile-wildcards). ## AWS Management Console **Pour créer un profil Fargate avec AWS Management Console ** 1. Ouvrez la [console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters). 1. Choisissez le cluster pour lequel vous voulez créer un profil Fargate. 1. Choisissez l'onglet **Calcul**. 1. Sous **Fargate profiles** (Profils Fargate), choisissez **Add Fargate profile** (Ajouter un profil Fargate). 1. Sur la page **Configure Fargate profile (Configurer le profil Fargate)**, procédez comme suit : 1. Pour **Nom**, saisissez un nom unique pour votre profil Fargate, tel que `my-profile`. 1. Pour le **rôle d’exécution du pod**, choisissez le rôle d’exécution du pod à utiliser avec votre profil Fargate. Seuls les rôles IAM avec le principal de service `eks-fargate-pods.amazonaws.com` sont affichés. Si vous ne voyez aucun rôle répertorié ici, vous devez en créer un. Pour de plus amples informations, consultez [Rôle IAM d’exécution de pod Amazon EKS](pod-execution-role.md). 1. Modifiez les **sous-réseaux** sélectionnés selon vos besoins. **Note** Seuls les sous-réseaux privés sont pris en charge pour les pods qui s’exécutent sur Fargate. 1. Dans **Identifications**, vous pouvez éventuellement étiqueter votre profil Fargate. Ces balises ne se propagent pas aux autres ressources qui sont associées au profil, comme les pods. 1. Choisissez **Suivant**. 1. Sur la page **Configurer la sélection de pod**, procédez comme suit : 1. Pour **l’espace de noms**, saisissez un espace de noms correspondant aux pods. + Vous pouvez utiliser des espaces de noms spécifiques pour les faire correspondre, tels que `kube-system` ou `default`. + Vous pouvez utiliser certains caractères génériques (par exemple, `prod-*`) pour faire correspondre plusieurs espaces de noms (par exemple, `prod-deployment` et `prod-test`). Pour de plus amples informations, consultez [Caractères génériques du profil Fargate](#fargate-profile-wildcards). 1. (Facultatif) Ajoutez des labels Kubernetes au sélecteur. Ajoutez-les spécifiquement à celui auquel les pods de l’espace de noms spécifié doivent correspondre. + Vous pouvez ajouter la balise `infrastructure: fargate` au sélecteur afin que seuls les pods de l’espace de noms spécifié qui possèdent également la balise Kubernetes `infrastructure: fargate` correspondent au sélecteur. + Vous pouvez utiliser certains caractères génériques (par exemple, `key?: value?`) pour faire correspondre plusieurs espaces de noms (par exemple, `keya: valuea` et `keyb: valueb`). Pour de plus amples informations, consultez [Caractères génériques du profil Fargate](#fargate-profile-wildcards). 1. Choisissez **Suivant**. 1. Sur la page **Vérifier et créer**, vérifiez les informations de votre profil Fargate et choisissez **Créer**. # Supprimer un profil Fargate Cette rubrique décrit comment supprimer un profil Fargate. Lorsque vous supprimez un profil Fargate, tous les pods qui étaient programmés sur Fargate avec ce profil sont supprimés. Si ces pods correspondent à un autre profil Fargate, ils sont programmés sur Fargate avec ce profil. S’ils ne correspondent plus à aucun profil Fargate, ils ne sont pas planifiés sur Fargate et peuvent rester en attente. Un seul profil Fargate d'un cluster peut avoir le statut `DELETING` à la fois. Vous devez attendre que la suppression d'un profil Fargate soit terminée pour pouvoir supprimer un autre profil de ce cluster. Vous pouvez supprimer un profil à l’aide de l’un des outils suivants : + [`eksctl`](#eksctl_delete_a_fargate_profile) + [AWS Management Console](#console_delete_a_fargate_profile) + [AWS CLI](#awscli_delete_a_fargate_profile) ## `eksctl` **Supprimer un profil Fargate avec `eksctl`** Utilisez la commande suivante pour supprimer un profil d'un cluster. Remplacez la *valeur d’exemple* par vos propres valeurs. ``` eksctl delete fargateprofile --name my-profile --cluster my-cluster ``` ## AWS Management Console **Supprimer un profil Fargate avec AWS Management Console** 1. Ouvrez la [console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters). 1. Dans le volet de navigation de gauche, choisissez **Clusters**. Dans la liste des clusters, sélectionnez celui dont vous souhaitez supprimer le profil Fargate. 1. Choisissez l'onglet **Calcul**. 1. Sélectionnez le profil Fargate à supprimer, puis l'option **Delete** (Supprimer). 1. Sur la page **Delete Fargate profile** (Supprimer le profil Fargate), saisissez le nom du profil, puis sélectionnez **Delete** (Supprimer). ## AWS CLI **Supprimer un profil Fargate avec l’interface CLI AWS** Utilisez la commande suivante pour supprimer un profil d'un cluster. Remplacez la *valeur d’exemple* par vos propres valeurs. ``` aws eks delete-fargate-profile --fargate-profile-name my-profile --cluster-name my-cluster ``` # Comprendre les détails de configuration des pods Fargate Cette section décrit certains des détails de configuration uniques des pods pour l’exécution de pods Kubernetes sur AWS Fargate. ## CPU et mémoire d'un pod Avec Kubernetes, vous pouvez définir des demandes, un nombre minimal de ressources vCPU et mémoire qui sont allouées à chaque conteneur dans un pod. Les pods sont planifiés par Kubernetes pour garantir qu’au moins les ressources demandées pour chaque pod sont disponibles sur la ressource de calcul. Pour plus d'informations, consultez [Gestion des ressources de calcul des conteneurs](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/) dans la documentation Kubernetes. **Note** Étant donné qu’Amazon EKS Fargate n’exécute qu’un seul pod par nœud, le scénario d’expulsion des pods en cas de ressources insuffisantes ne se produit pas. Tous les pods Amazon EKS Fargate s’exécutent avec une priorité garantie, de sorte que le CPU et la mémoire demandés doivent être égaux à la limite pour tous les conteneurs. Pour plus d'informations, consultez [Configurer la qualité de service pour les pods](https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/) dans la documentation Kubernetes. Lorsque les pods sont planifiés sur Fargate, les réservations de vCPU et de mémoire dans la spécification du pod déterminent la quantité de CPU et de mémoire à allouer au pod. + La demande maximale de tous les conteneurs Init est utilisée pour déterminer les besoins en vCPU et en mémoire de la demande Init. + Les demandes de tous les conteneurs à longue durée d'exécution sont additionnées pour déterminer les besoins en vCPU et en mémoire de la demande à longue durée d'exécution. + La plus grande des deux valeurs ci-dessus est choisie pour la demande de vCPU et la demande de mémoire à utiliser pour votre pod. + Fargate ajoute 256 Mo à la réservation de mémoire de chaque pod pour les composants Kubernetes requis (`kubelet`, `kube-proxy`, et `containerd`). Fargate arrondit à la configuration informatique suivante qui correspond le mieux à la somme des demandes de vCPU et de mémoire afin de garantir que les pods disposent toujours des ressources nécessaires à leur fonctionnement. Si vous ne spécifiez pas de combinaison vCPU et mémoire, la plus petite combinaison disponible est utilisée (0,25 vCPU et 0,5 Go de mémoire). Le tableau suivant répertorie les combinaisons de vCPU et de mémoire qui sont disponibles pour les pods fonctionnant sur Fargate. | Valeur vCPU | Valeur de mémoire | | --- | --- | | 0,25 vCPU | 0,5 Go, 1 Go, 2 Go | | 0,5 vCPU | 1 Go, 2 Go, 3 Go, 4 Go | | 1 vCPU | 2 Go, 3 Go, 4 Go, 5 Go, 6 Go, 7 Go, 8 Go | | 2 vCPU | Entre 4 Go et 16 Go par incrément de 1 Go | | 4 vCPU | Entre 8 Go et 30 Go par incrément de 1 Go | | 8 vCPU | Entre 16 Go et 60 Go par incréments de 4 Go | | 16 vCPU | Entre 32 Go et 120 Go par incréments de 8 Go | La mémoire supplémentaire réservée aux composants Kubernetes peut entraîner l'approvisionnement d'une tâche Fargate avec plus de vCPU que demandé. Par exemple, une demande pour 1 vCPU et 8 Go de mémoire verra 256 Mo ajoutés à sa demande de mémoire, et approvisionnera une tâche Fargate avec 2 vCPU et 9 Go de mémoire, puisqu'aucune tâche avec 1 vCPU et 9 Go de mémoire n'est disponible. Il n’existe pas de corrélation entre la taille du pod fonctionnant sur Fargate et la taille du nœud signalée par Kubernetes avec `kubectl get nodes`. La taille du nœud signalée est souvent supérieure à la capacité du pod. Vous pouvez vérifier la capacité du pod avec la commande suivante. Remplacez *default* par l’espace de noms de votre pod et *pod-name* par le nom de votre pod. ``` kubectl describe pod --namespace default pod-name ``` L'exemple qui suit illustre un résultat. ``` [...] annotations: CapacityProvisioned: 0.25vCPU 0.5GB [...] ``` L’annotation `CapacityProvisioned` représente la capacité du pod appliquée et détermine le coût de votre pod fonctionnant sur Fargate. Pour plus d'informations sur la tarification de ces configurations de calcul, reportez-vous à [Tarification AWS](https://aws.amazon.com/fargate/pricing/). ## Stockage Fargate Un Pod fonctionnant sur Fargate monte automatiquement un système de fichiers Amazon EFS, sans nécessiter d’étapes manuelles d’installation de pilotes. Vous ne pouvez pas utiliser l’approvisionnement dynamique des volumes persistants avec les nœuds Fargate, mais vous pouvez utiliser l’approvisionnement statique. Pour plus d'informations, voir [Pilote CSI Amazon EFS](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/docs/README.md) sur GitHub. Une fois provisionné, chaque pod exécuté sur Fargate reçoit par défaut un espace de stockage éphémère de 20 GiB. Ce type de stockage est supprimé après l’arrêt du pod. Lorsque de nouveaux pods sont lancés sur Fargate, le chiffrement du volume de stockage éphémère est activé par défaut. Le stockage éphémère des pods est chiffré avec un algorithme de chiffrement AES-256 utilisant des clés gérées par AWS Fargate. **Note** La capacité de stockage par défaut pour les pods Amazon EKS exécutés sur Fargate est inférieure à 20 GiB. En effet, une partie de l’espace est utilisée par le module `kubelet` et d’autres modules Kubernetes chargés dans le pod. Vous pouvez augmenter la capacité totale de stockage éphémère jusqu'à un maximum de 175 GiB. Pour configurer la taille avec Kubernetes, spécifiez les demandes de ressources `ephemeral-storage` pour chaque conteneur dans un pod. Lorsque Kubernetes planifie les pods, il s’assure que la somme des demandes de ressources pour chaque pod est inférieure à la capacité de la tâche Fargate. Pour plus d’informations, consultez la section [Gestion des ressources pour les pods et les conteneurs](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/) dans la documentation Kubernetes. Amazon EKS Fargate alloue une capacité de stockage éphémère supérieure à celle demandée aux fins de l'utilisation du système. Par exemple, une demande de 100 GiB allouera à une tâche Fargate une capacité de stockage éphémère de 115 GiB. # Définir des actions pour les événements de correction du système d’exploitation AWS Fargate Amazon EKS doit régulièrement appliquer des correctifs au système d’exploitation pour les nœuds AWS Fargate afin d’assurer leur sécurité. Dans le cadre du processus d'application des correctifs, nous recyclons les nœuds pour installer les correctifs du système d'exploitation. Les tentatives de mises à jour sont réalisées de manière à avoir des répercussions minimales sur vos services. Toutefois, si les pods ne sont pas expulsés avec succès, ils doivent parfois être supprimés. Voici les actions que vous pouvez effectuer pour minimiser les perturbations potentielles : + Définissez des budgets de perturbation de pods (PDB) appropriés pour contrôler le nombre de pods simultanément hors service. + Créez des règles Amazon EventBridge pour réagir aux expulsions ayant échoué avant la suppression des pods. + Redémarrez manuellement vos pods concernés avant la date d’expulsion indiquée dans la notification que vous avez reçue. + Créez une configuration de notification dans Notifications d'utilisateur AWS. Amazon EKS travaille en étroite collaboration avec la communauté Kubernetes pour corriger les bugs et appliquer les correctifs de sécurité le plus rapidement possible. Tous les pods Fargate démarrent sur la version la plus récente du correctif Kubernetes, disponible auprès d’Amazon EKS pour la version Kubernetes de votre cluster. Si un pod présente une ancienne version de correctif, Amazon EKS peut le recycler pour le mettre à jour à la dernière version. Cela garantit que vos pods comprennent les dernières mises à jour de sécurité. De cette façon, en cas de problème critique inhérent aux [vulnérabilités et expositions courantes](https://cve.mitre.org/) (CVE), vous êtes tenu à jour pour réduire les risques de sécurité. Lorsque le système d’exploitation AWS Fargate est mis à jour, Amazon EKS vous envoie une notification indiquant les ressources concernées et la date des prochaines expulsions de pods. Si la date d’expulsion indiquée ne vous convient pas, vous avez la possibilité de redémarrer manuellement vos pods concernés avant la date d’expulsion indiquée dans la notification. Tous les pods créés avant le moment où vous recevez la notification sont susceptibles d’être expulsés. Consultez la [documentation Kubernetes](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_rollout/kubectl_rollout_restart) pour obtenir des instructions supplémentaires sur la manière de redémarrer manuellement vos pods. Pour limiter le nombre de pods hors service simultanément lors du recyclage des pods, vous pouvez définir des budgets de perturbation des pods (PDB). Vous pouvez utiliser les PDB pour définir une disponibilité minimale en fonction des exigences de chacune de vos applications, tout en autorisant les mises à jour. La disponibilité minimale de votre PDB doit être inférieure à 100 %. Pour plus d’informations, consultez la section [Spécification d’un budget de perturbation pour votre application](https://kubernetes.io/docs/tasks/run-application/configure-pdb/) dans la documentation Kubernetes. Amazon EKS utilise l’[API d’expulsion](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/#eviction-api) pour vider le pod en toute sécurité tout en respectant les PDB que vous avez définis pour l’application. Les pods sont expulsés par zone de disponibilité pour minimiser les répercussions. Si l’expulsion réussit, le nouveau pod reçoit le dernier correctif et aucune autre action n’est requise. Lorsque l’expulsion d’un pod échoue, Amazon EKS envoie un événement à votre compte avec des informations sur les pods dont l’expulsion a échoué. Vous pouvez agir en fonction du message avant l'heure de fin prévue. Le temps spécifique varie en fonction de l'urgence du correctif. Le moment venu, Amazon EKS tente à nouveau d’expulser les pods. Toutefois, si l'expulsion échoue lors de cette tentative, un nouvel événement n'est pas envoyé. Si l’expulsion échoue à nouveau, vos pods existants sont supprimés périodiquement afin que les nouveaux pods puissent comporter le dernier correctif. Vous trouverez ci-dessous un exemple d’événement reçu lorsque l’expulsion d’un pod échoue. Il contient des informations sur le cluster, le nom du pod, l’espace de noms du pod, le profil Fargate et l’heure de fin planifiée. ``` { "version": "0", "id": "12345678-90ab-cdef-0123-4567890abcde", "detail-type": "EKS Fargate Pod Scheduled Termination", "source": "aws.eks", "account": "111122223333", "time": "2021-06-27T12:52:44Z", "region": "region-code", "resources": [ "default/my-database-deployment" ], "detail": { "clusterName": "my-cluster", "fargateProfileName": "my-fargate-profile", "podName": "my-pod-name", "podNamespace": "default", "evictErrorMessage": "Cannot evict pod as it would violate the pod's disruption budget", "scheduledTerminationTime": "2021-06-30T12:52:44.832Z[UTC]" } } ``` En outre, si plusieurs PDB sont associés à un pod, un événement d’échec d’expulsion peut survenir. Cet événement renvoie le message d'erreur suivant. ``` "evictErrorMessage": "This pod has multiple PodDisruptionBudget, which the eviction subresource does not support", ``` Vous pouvez créer une action souhaitée en fonction de cet événement. Par exemple, vous pouvez ajuster votre budget de perturbation de pod (PDB) pour contrôler l’expulsion des pods. Plus précisément, imaginions que vous utilisiez un PDB qui spécifie le pourcentage cible de pods disponibles. Avant que la résiliation de vos pods soit forcée lors d’une mise à niveau, vous pouvez ajuster le PDB à un pourcentage différent de pods. Pour recevoir cet événement, vous devez créer une règle Amazon EventBridge dans le compte AWS et la région AWS auxquels le cluster appartient. La règle doit utiliser le **modèle personnalisé** suivant. Pour plus d'informations, veuillez consulter [Création d'une règle Amazon EventBridge qui réagit aux événements](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-create-rule.html) dans le *Guide de l'utilisateur Amazon EventBridge*. ``` { "source": ["aws.eks"], "detail-type": ["EKS Fargate Pod Scheduled Termination"] } ``` Une cible appropriée peut être définie pour que l'événement le capture. Pour obtenir une liste complète des cibles disponibles, consultez [Cibles Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-targets.html) dans le *Guide de l'utilisateur Amazon EventBridge*. Vous pouvez également créer une configuration de notification dans Notifications d'utilisateurs AWS. Lorsque vous utilisez le AWS Management Console pour créer la notification, sous **Règles d’événement**, choisissez **Elastic Kubernetes Service (EKS)** comme **nom de service AWS** et **EKS Fargate Pod Scheduled Termination** comme **Type d’événement**. Pour plus d'informations, consultez la section [Prise en main des notifications d'utilisateur AWS](https://docs.aws.amazon.com/notifications/latest/userguide/getting-started.html) dans le Guide de l'utilisateur des notifications d'utilisateur AWS. Consultez la [FAQ : Avis d’expulsion de pod Fargate](https://repost.aws/knowledge-center/fargate-pod-eviction-notice) dans *re:Post AWS* pour connaître les questions fréquemment posées concernant les expulsions de pod EKS. # Collectez l' AWS application Fargate et les statistiques d'utilisation Vous pouvez collecter des métriques du système et des métriques CloudWatch d'utilisation pour AWS Fargate. ## Métriques d'application Pour les applications exécutées sur Amazon EKS et AWS Fargate, vous pouvez utiliser Distro OpenTelemetry for ( AWS ADOT). ADOT vous permet de collecter des métriques du système et de les envoyer aux tableaux de bord de CloudWatch Container Insights. Pour démarrer avec ADOT pour les applications exécutées sur Fargate, [consultez la section CloudWatch Utilisation de Container Insights AWS with Distro OpenTelemetry](https://aws-otel.github.io/docs/getting-started/container-insights) dans la documentation ADOT. ## Métriques d’utilisation Vous pouvez utiliser les statistiques CloudWatch d'utilisation pour obtenir une visibilité sur l'utilisation des ressources par votre compte. Utilisez ces indicateurs pour visualiser l'utilisation actuelle de vos services sur CloudWatch des graphiques et des tableaux de bord. AWS Les métriques d'utilisation de Fargate correspondent aux AWS quotas de service. Vous pouvez configurer des alarmes qui vous alertent lorsque votre utilisation approche un quota de service. Pour de plus amples informations sur les Service Quotas pour Fargate, consultez [Afficher et gérer les quotas de service Amazon EKS et Fargate](service-quotas.md). AWS Fargate publie les métriques suivantes dans l'espace de noms. ` AWS/Usage` | Métrique | Description | | --- | --- | | `ResourceCount` | Nombre total des ressources spécifiées exécutées sur votre compte. La ressource est définie par les dimensions associées à la métrique. | Les dimensions suivantes sont utilisées pour affiner les métriques d'utilisation publiées par AWS Fargate. | Dimension | Description | | --- | --- | | `Service` | Nom du AWS service contenant la ressource. Pour les métriques AWS d'utilisation de Fargate, la valeur de cette dimension est. `Fargate` | | `Type` | Le type d’entité qui fait l’objet du rapport. Actuellement, la seule valeur valide pour les métriques d' AWS utilisation de Fargate est. `Resource` | | `Resource` | Le type de ressource en cours d’exécution. Actuellement, AWS Fargate renvoie des informations sur votre utilisation de Fargate On-Demand. La valeur de ressource pour l'utilisation de Fargate On-Demand est `OnDemand`. [NOTE] ==== L’utilisation de Fargate On-Demand combine les pods Amazon EKS utilisant Fargate, les tâches Amazon ECS utilisant le type de lancement Fargate et les tâches Amazon ECS utilisant le fournisseur de capacité `FARGATE`. ==== | | `Class` | Classe de ressource suivie. Actuellement, AWS Fargate n'utilise pas la dimension de classe. | ### Création d'une CloudWatch alarme pour surveiller les métriques d'utilisation des ressources de Fargate AWS Fargate CloudWatch fournit des métriques d'utilisation qui correspondent aux quotas de service pour AWS l'utilisation des ressources Fargate On-Demand. Dans la console Service Quotas, vous pouvez visualiser votre utilisation sur un graphique. Vous pouvez également configurer des alarmes qui vous alertent lorsque votre utilisation approche d'un quota de service. Pour de plus amples informations, veuillez consulter [Collectez l' AWS application Fargate et les statistiques d'utilisation](#monitoring-fargate-usage). Suivez les étapes ci-dessous pour créer une CloudWatch alarme basée sur les métriques d'utilisation des ressources de Fargate. 1. Ouvrez la console Service Quotas à l'adresse https://console.aws.amazon.com/servicequotas/. 1. Dans le volet de navigation de gauche, sélectionnez ** AWS services**. 1. Dans la liste des ** AWS services**, recherchez et sélectionnez ** AWS Fargate.** 1. Dans la liste **Quotas de service**, sélectionnez le quota d'utilisation Fargate pour lequel vous souhaitez créer une alarme. 1. Dans la section CloudWatch Alarmes Amazon, choisissez **Create**. 1. Pour **Alarm threshold** (Seuil d'alarme), choisissez le pourcentage de la valeur de quota appliquée que vous souhaitez définir comme valeur d'alarme. 1. Pour **Nom de l'alarme**, saisissez un nom pour l'alarme, puis choisissez **Créer**. # Démarrez la journalisation AWS Fargate pour votre cluster Amazon EKS on Fargate propose un routeur de journal intégré basé sur Fluent Bit. Cela signifie que vous n’exécutez pas explicitement un conteneur Fluent Bit comme sidecar, mais qu’Amazon l’exécute pour vous. Tout ce que vous avez à faire est de configurer le routeur de journaux. La configuration se fait par le biais d'un `ConfigMap` qui doit répondre aux critères suivants : + Nommé `aws-logging` + Créé dans un espace de noms dédié appelé `aws-observability` + Ne doit pas dépasser 5 300 caractères. Une fois que vous avez créé le `ConfigMap`, Amazon EKS on Fargate le détecte automatiquement et configure le routeur de journaux avec lui. Fargate utilise une version de AWS pour Fluent Bit, une distribution compatible en amont de Fluent Bit gérée par AWS. Pour plus d'informations, consultez [AWS for Fluent Bit](https://github.com/aws/aws-for-fluent-bit) sur GitHub. Le routeur de journaux vous permet d'utiliser la diversité des services sur AWSpour l'analyse des journaux et le stockage. Vous pouvez diffuser les journaux depuis Fargate directement vers Amazon CloudWatch, Amazon OpenSearch Service. Vous pouvez également diffuser les journaux vers des destinations telles qu’[Amazon S3](https://aws.amazon.com/s3/), [Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/) et des outils partenaires via [Amazon Data Firehose](https://aws.amazon.com/kinesis/data-firehose/). + Un profil Fargate existant qui spécifie un espace de noms Kubernetes existant dans lequel vous déployez des pods Fargate. Pour de plus amples informations, consultez [Étape 3 : créer un profil Fargate pour votre cluster](fargate-getting-started.md#fargate-gs-create-profile). + Un rôle d’exécution de pod Fargate existant. Pour de plus amples informations, consultez [Étape 2 : créer un rôle d’exécution Fargate Pod](fargate-getting-started.md#fargate-sg-pod-execution-role). ## Configuration du routeur de journaux **Important** Pour que les journaux soient publiés avec succès, il doit y avoir un accès réseau depuis le VPC dans lequel se trouve votre cluster vers la destination des journaux. Cela concerne principalement les utilisateurs qui personnalisent les règles de sortie pour leur VPC. Pour un exemple d’utilisation de CloudWatch, consultez la section [Utilisation des journaux CloudWatch avec les points de terminaison d’un VPC d’interface](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch-logs-and-interface-VPC.html) dans le *Guide de l’utilisateur Amazon CloudWatch Logs*. Dans les étapes suivantes, remplacez chaque *valeur d’exemple* par vos propres valeurs. 1. Créez un espace de noms Kubernetes dédié nommé `aws-observability`. 1. Enregistrez le contenu suivant dans un fichier nommé `aws-observability-namespace.yaml` sur votre ordinateur. La valeur pour `name` doit être `aws-observability` et le label `aws-observability: enabled` est obligatoire. ``` kind: Namespace apiVersion: v1 metadata: name: aws-observability labels: aws-observability: enabled ``` 1. Créez l'espace de noms. ``` kubectl apply -f aws-observability-namespace.yaml ``` 1. Créez un `ConfigMap` avec une valeur de données `Fluent Conf` pour envoyer les journaux des conteneurs vers une destination. Fluent Conf est Fluent Bit, qui est un langage de configuration de processeur de journaux rapide et léger, utilisé pour acheminer les journaux des conteneurs vers une destination de journalisation de votre choix. Pour plus d'informations, consultez [Fichier de configuration](https://docs.fluentbit.io/manual/administration/configuring-fluent-bit/classic-mode/configuration-file) dans la documentation Fluent Bit. **Important** Dans une `Fluent Conf` type, les principales sections incluses sont `Service`, `Input`, `Filter` et `Output`. Le routeur de journaux Fargate n'accepte cependant que : Les sections `Filter` et `Output`. Une section `Parser`. Si vous fournissez d'autres sections, elles seront rejetées. Le routeur de journal Fargate gère les sections `Service` et `Input`. Il comporte la section `Input` suivante, qui ne peut pas être modifiée et n’est pas nécessaire dans votre `ConfigMap`. Cependant, vous pouvez en tirer des informations, telles que la limite de la mémoire tampon et la balise appliquée pour les journaux. ``` [INPUT] Name tail Buffer_Max_Size 66KB DB /var/log/flb_kube.db Mem_Buf_Limit 45MB Path /var/log/containers/*.log Read_From_Head On Refresh_Interval 10 Rotate_Wait 30 Skip_Long_Lines On Tag kube.* ``` Lors de la création du `ConfigMap`, prenez en compte les règles suivantes que Fargate utilise pour valider les champs : + `[FILTER]`, `[OUTPUT]` et `[PARSER]` sont censés être spécifiés sous chaque clé correspondante. Par exemple, `[FILTER]` doit être inférieur à `filters.conf`. Vous pouvez avoir un ou plusieurs `[FILTER]` sous `filters.conf`. `[OUTPUT]` et `[PARSER]` doivent également être sous leurs clés correspondantes. En spécifiant plusieurs sections `[OUTPUT]`, vous pouvez acheminer vos journaux vers différentes destinations en même temps. + Fargate valide les clés requises de chaque section. `Name` et `match` sont nécessaires pour chaque `[FILTER]` et `[OUTPUT]`. `Name` et `format` sont nécessaires pour chaque `[PARSER]`. Ces noms sont sensibles à la casse. + Les variables d’environnement telles que `${ENV_VAR}` ne sont pas autorisées dans le `ConfigMap`. + L'indentation doit être la même pour la directive ou la paire clé-valeur dans chaque `filters.conf`, `output.conf` et `parsers.conf`. Les paires clé-valeur doivent être indentées plus que les directives. + Fargate valide par rapport aux filtres pris en charge suivants : `grep`, `parser`, `record_modifier`, `rewrite_tag`, `throttle`, `nest`, `modify` et `kubernetes`. + Fargate valide par rapport à la sortie prise en charge suivante : `es`, `firehose`, `kinesis_firehose`, `cloudwatch`, `cloudwatch_logs` et `kinesis`. + Au moins un plug-in `Output` doit être fourni dans le `ConfigMap` pour activer la journalisation. `Filter` et `Parser` ne sont pas nécessaires pour activer la journalisation. Vous pouvez également exécuter Fluent Bit sur Amazon EC2 en utilisant la configuration souhaitée pour résoudre les problèmes qui surviennent lors de la validation. Créez votre `ConfigMap` en utilisant l'un des exemples suivants. **Important** La journalisation Amazon EKS Fargate ne prend pas en charge la configuration dynamique d’un `ConfigMap`. Les modifications apportées à un `ConfigMap` sont appliquées uniquement aux nouveaux pods. Les modifications ne sont pas appliquées aux pods existants. Créez un `ConfigMap` en utilisant l'exemple pour votre destination de journal désirée. **Note** Vous pouvez également utiliser Amazon Kinesis Data Streams comme destination du journal. Si vous utilisez Kinesis Data Streams, assurez-vous que l'autorisation `kinesis:PutRecords` a été accordée au rôle d'exécution du pod. Pour plus d’informations, consultez [Permissions](https://docs.fluentbit.io/manual/pipeline/outputs/kinesis#permissions) d’Amazon Kinesis Data Streams dans le *Manuel officiel Fluent Bit*. **Example** ------ #### [ CloudWatch ] Vous disposez de deux options de sortie lorsque vous utilisez CloudWatch : + [Un plugin de sortie écrit en C](https://docs.fluentbit.io/manual/v/1.5/pipeline/outputs/cloudwatch) + [Un plugin de sortie écrit en Golang](https://github.com/aws/amazon-cloudwatch-logs-for-fluent-bit) L'exemple suivant explique comment utiliser le plugin `cloudwatch_logs` pour envoyer des journaux à CloudWatch. 1. Enregistrez le contenu suivant dans un fichier nommé `aws-logging-cloudwatch-configmap.yaml`. Remplacez *region-code* par la région AWS dans laquelle votre cluster se situe. Les paramètres sous `[OUTPUT]` sont requises. ``` kind: ConfigMap apiVersion: v1 metadata: name: aws-logging namespace: aws-observability data: flb_log_cw: "false" # Set to true to ship Fluent Bit process logs to CloudWatch. filters.conf: | [FILTER] Name parser Match * Key_name log Parser crio [FILTER] Name kubernetes Match kube.* Merge_Log On Keep_Log Off Buffer_Size 0 Kube_Meta_Cache_TTL 300s output.conf: | [OUTPUT] Name cloudwatch_logs Match kube.* region region-code log_group_name my-logs log_stream_prefix from-fluent-bit- log_retention_days 60 auto_create_group true parsers.conf: | [PARSER] Name crio Format Regex Regex ^(?