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 Activation de la réparation automatique des nœuds et examen des problèmes d’état de ces derniers.

Vous pouvez ajouter un groupe de nœuds gérés à des clusters nouveaux ou existants à l'aide de la console, de la AWS CLIeksctl, 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 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.

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.

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 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 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. 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.

• 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 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.

• 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 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é.

• Les groupes de nœuds gérés ne peuvent pas être déployés sur AWS Outposts ou dans AWS Wavelength. Des groupes de nœuds gérés peuvent être créés sur les zones locales AWS. Pour de plus amples informations, veuillez consulter Lancer des clusters EKS à faible latence avec AWS Local Zones.

• 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, 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.

• 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 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.

• 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 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 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 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 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 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, 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, utilisezc3.xlarge,,c4.xlarge,c5.xlarge, c5d.xlarge c5a.xlargec5n.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 avecc3.xlarge,,c4.xlarge,c5.xlarge, c5d.xlarge c5a.xlargec5n.xlarge, ou d'autres types d'instances similaires, et un second groupe de nœuds gérés avecm3.xlarge,,, m4.xlarge m5.xlarge m5d.xlargem5a.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.