Simplifiez le cycle de vie des nœuds avec des groupes de nœuds gérés - Amazon EKS
Concepts des groupes de nœuds gérésTypes de capacité des groupes de nœuds gérés

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.

Vous souhaitez contribuer à ce guide de l'utilisateur ? Faites défiler cette page vers le bas et sélectionnez Modifier cette page sur GitHub. Vos contributions contribueront à améliorer notre guide de l'utilisateur pour tous.

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Simplifiez le cycle de vie des nœuds avec des groupes de nœuds gérés

Les groupes de nœuds EKS gérés par Amazon automatisent le provisionnement et la gestion du cycle de vie des nœuds (EC2instances Amazon) pour Amazon EKS Kubernetes clusters.

Avec les groupes de nœuds EKS gérés par Amazon, 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 votre Kubernetes applications. 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 AmazonEKS. 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 éventuellement tirer parti de la réparation automatique des nœuds, qui surveille en permanence l'état de santé des nœuds. Il réagit automatiquement aux problèmes détectés et remplace les nœuds lorsque cela est possible. Cela permet une disponibilité globale du cluster avec une intervention manuelle minimale. Pour de plus amples informations, veuillez consulter Activez la réparation automatique des nœuds et étudiez les problèmes de santé des nœuds.

Vous pouvez ajouter un groupe de nœuds gérés à des clusters nouveaux ou existants à l'aide de la EKS console Amazon,, eksctl AWS CLI AWS API, ou de l'infrastructure 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é sont automatiquement étiquetés pour être découverts automatiquement par Kubernetes Autoscaler de cluster. Vous pouvez utiliser le groupe de nœuds pour postuler Kubernetes étiquettes pour les nœuds et mettez-les à jour à tout moment.

L'utilisation des groupes de nœuds EKS gérés par Amazon 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, EBS des volumes Amazon, des heures de EKS cluster Amazon et de toute autre AWS infrastructure. Aucun frais minimum ni aucun engagement initial ne s'appliquent.

Pour démarrer avec un nouveau EKS cluster Amazon et un nouveau groupe de nœuds gérés, consultezCommencez à utiliser AmazonEKS, AWS Management Console et AWS CLI.

Pour ajouter un groupe de nœuds gérés à un cluster existant, consultez Créez 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 EKS gérés par Amazon 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 AmazonEKS. De plus, toutes les ressources, y compris les EC2 instances Amazon et les groupes Auto Scaling, s'exécutent 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 des groupes de nœuds gérés afin qu'elles soient configurées pour utiliser Kubernetes Autoscaler de cluster.

    Important

    Si vous exécutez une application dynamique dans plusieurs zones de disponibilité qui est soutenue par des EBS volumes Amazon et que vous utilisez le Kubernetes Cluster Autoscaler, vous devez configurer plusieurs groupes de nœuds, chacun étant 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 kubelet arguments supplémentaires et utiliser un paramètre personnaliséAMI. Pour de plus amples informations, veuillez consulter Personnalisez les nœuds gérés avec des 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, il existe un modèle de lancement 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 version EKS optimisée pour AmazonAMI, Amazon EKS est chargé de créer des versions corrigées 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 AMI versions corrigées sur vos groupes de nœuds gérés. Lorsque les nœuds gérés exécutent une personnalisationAMI, vous êtes chargé de créer des versions corrigées du AMI lorsque des bogues ou des problèmes sont signalés, puis de déployer leAMI. 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 EKS gérés par Amazon 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 vended 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 Modification de l'attribut d'adressage IPv4 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 le faire en connectant une NAT passerelle à la table de routage du sous-réseau ou en ajoutant les points de AWS PrivateLink VPCterminaison suivants :

    • Interface Amazon ECR API Endpoint — com.amazonaws.region-code.ecr.api

    • Interface de point de API terminaison du registre Amazon ECR Docker — 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éployez 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 Wavelength AWS . Les groupes de nœuds gérés peuvent être créés dans les Zones AWS Locales. Pour de plus amples informations, veuillez consulter Lancez des EKS clusters à faible latence avec les Zones AWS Locales.

  • 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 le standard Amazon Linux EKS optimisé pour Amazon AMI pour certaines charges de travail et un autre avec la GPU variante pour les charges de travail nécessitant GPU un support.

  • 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 Kubernetes étiquettes pour les instances de groupes de nœuds gérés. Ces étiquettes EKS fournies par Amazon sont préfixées pareks.amazonaws.com.

  • Amazon draine EKS automatiquement les nœuds à l'aide du Kubernetes APIlors de résiliations ou de mises à jour.

  • Les budgets d'interruption des pods ne sont pas respectés lorsqu'il s'agit de mettre fin à un nœud AZRebalance ou de réduire le nombre de nœuds souhaité. Ces actions visent à expulser Pods sur le nœud. Mais si cela prend plus de 15 minutes, le nœud est arrêté, que tous Pods sur le nœud sont terminés. 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 Pod les budgets d'interruption que vous définissez pour votre Pods. Pour plus d'informations, consultezComprenez chaque phase des mises à jour des nœuds.

  • L'utilisation des groupes de nœuds EKS gérés par Amazon n'entraîne aucun coût supplémentaire. Vous ne payez que pour les AWS ressources que vous fournissez.

  • Si vous souhaitez chiffrer les EBS volumes Amazon 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 EBS volumes Amazon chiffrés sans utiliser de modèle de lancement, chiffrez tous les nouveaux EBS volumes Amazon 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 Pods pour les applications tolérantes aux pannes destinées aux groupes de nœuds gérés par Spot, et pour les applications intolérantes aux pannes destinées aux groupes de nœuds à la demande au sein d'un même Kubernetes grappe. 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'instances transmis API pour déterminer le type d'instance à utiliser en premier lors de l'utilisation 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 ce qui suit Kubernetes étiquette pour 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 EKS cluster Amazon.

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 Kubernetes version 1.28 ou supérieure, la stratégie d'allocation est définie surprice-capacity-optimized. Toutefois, 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 EKS gérés par Amazon ne commencent à être pris en chargePCO.

    • capacity-optimized(CO) — Lors de la création de nouveaux groupes de nœuds dans un cluster avec Kubernetes version 1.27 ou inférieure, la stratégie d'allocation est définie surcapacity-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 tente EKS 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 en Ready état, Amazon EKS commence à vider 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 amorcé et qu'il est à l'état activé Ready Kubernetes, Amazon EKS déconnecte et vide le nœud Spot qui a reçu la recommandation de rééquilibrage. Le fait de boucler le nœud Spot garantit que le contrôleur de service n'envoie aucune nouvelle demande à ce nœud Spot. Il le supprime également de sa liste de nœuds Spot sains et actifs. Le drainage du nœud Spot garantit le fonctionnement Pods sont expulsés gracieusement.

  • Amazon EKS ajoute ce qui suit Kubernetes étiquette pour 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.

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 sans étatAPI. Le 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 pendant lesquelles 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 :

    • Au sein d'un groupe de nœuds gérés, si vous utilisez le Cluster Autoscaler, nous vous recommandons d'utiliser un ensemble flexible de types d'instances avec la même quantité de ressources v CPU 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 vCPUs ou huit GiB de mémoire, utilisez,c3.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 dotés des mêmes ressources en v CPU et en mémoire. Par exemple, si vous avez besoin de 4 vCPUs ou 8 Go 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 le API pour transmettre plusieurs types d'instances. Ne transmettez pas un seul type d'instance dans 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 Personnalisez les nœuds gérés avec des modèles de lancement.

📝 Modifiez cette page sur GitHub