Groupes de nœuds gérés

Les groupes de nœuds gérés Amazon EKS automatisent l'approvisionnement et la gestion du cycle de vie des nœuds (instances Amazon EC2) pour les clusters Amazon EKS Kubernetes.

Avec les groupes de nœuds gérés Amazon EKS, vous n'avez pas besoin d'approvisionner ou d'enregistrer séparément les instances Amazon EC2 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 qui est géré pour vous par Amazon EKS. Chaque ressource, y compris les instances et les groupes Auto Scaling, sont gérées par votre compte AWS. Chaque groupe de nœuds s'exécute dans plusieurs zones de disponibilité que vous définissez.

Vous pouvez ajouter un groupe de nœuds gérés à des clusters nouveaux ou existants à l'aide de la console Amazon EKS, eksctl, la AWS CLI l'API AWS ou des outils Infrastructure as 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 la découverte automatique par le Kubernetes Cluster Autoscaler. Vous pouvez utiliser le groupe de nœuds pour appliquer des labels Kubernetes aux nœuds et les mettre à jour à tout moment.

L'utilisation de groupes de nœuds gérés Amazon EKS n'entraîne aucun coût supplémentaire. Vous ne payez que les ressources AWS que vous approvisionnez. Celles-ci comprennent les instances Amazon EC2, les volumes Amazon EBS, les heures de cluster Amazon EKS et toute autre infrastructure AWS. 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émarrer avec Amazon EKS : AWS Management Console et 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.

Concepts des groupes de nœuds gérés

• Les groupes de nœuds gérés Amazon EKS créent et gèrent des instances Amazon EC2 automatiquement.

• Chaque nœud géré est approvisionné dans le cadre d'un groupe Amazon EC2 Auto Scaling qui est géré pour vous par Amazon EKS. En outre, chaque ressource, y compris les instances Amazon EC2 et les groupes Auto Scaling, est exécutée dans votre compte AWS.

• 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 balise les ressources d'un groupe de nœuds gérés de manière à ce qu'elles soient configurées pour utiliser le Cluster Autoscaler de Kubernetes.

  Important

  Si vous exécutez sur plusieurs zones de disponibilité une application avec état qui est basée sur des volumes Amazon EBS et qui utilise Kubernetes Autoscaling, 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 arguments kubelet supplémentaires et utiliser une AMI personnalisée. Pour de plus amples informations, veuillez consulter Personnalisation des 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, 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 pour les CVE 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 plus d'informations, consultez Mise à jour d'un groupe de nœuds gérés.

• 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éé avec eksctl ou des modèles AWS CloudFormation vendus par Amazon EKS à partir du 26 mars 2020, ce paramètre a déjà la valeur 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 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.ecr.s3

  Pour d'autres services et points de terminaison couramment utilisés, veuillez consulter la rubrique Exigences relatives aux clusters privés.

• Les groupes de nœuds gérés ne peuvent pas être déployés sur AWS Outposts ou dans les Local Zones AWS Wavelength ou AWS.

• 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 2 optimisée pour Amazon EKS standard pour certaines applications et un autre avec la variante GPU pour les applications qui nécessitent le support GPU.

• Si votre groupe de nœuds gérés rencontre un échec de vérification de l'état des instances Amazon EC2, 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 Pods dans le 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 rubrique Utilisation de hooks de cycle de vie du Guide de l'utilisateur 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 d'interruption Pod que vous avez définis pour vos Pods. Pour de plus amples informations, veuillez consulter Comportement de mise à jour des nœuds gérés.

• L'utilisation de groupes de nœuds gérés par Amazon EKS est disponible sans coûts supplémentaires. Vous ne payez que les ressources AWS que vous allouez.

• 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 Chiffrement par défaut dans le Guide de l'utilisateur Amazon EC2 pour les instances Linux.

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 soit uniquement des instances à la demande, soit uniquement des instances Amazon EC2 Spot. Vous pouvez programmer 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 des instances Amazon EC2 à la demande.

À la demande

Avec les instances à la demande, vous payez la capacité de calcul à la seconde, sans engagement à long terme.

Comment ça marche

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és 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 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 une capacité Amazon EC2 de réserve qui offre des réductions importantes par rapport aux prix des instances à la demande. Les instances Amazon EC2 Spot peuvent être résiliées avec un avis de résiliation de deux minutes lorsque EC2 a besoin de récupérer la capacité. Pour plus d'informations, veuillez consulter Instances Spot dans le Guide de l'utilisateur Amazon EC2 pour instances Linux. Vous pouvez configurer un groupe de nœuds gérés avec des instances Amazon EC2 Spot pour optimiser les coûts des nœuds de calcul fonctionnant dans votre cluster Amazon EKS.

Comment ça marche

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és configure un groupe Amazon EC2 Auto Scaling en votre nom en appliquant les bonnes pratiques Spot suivantes :

• La stratégie d'allocation de capacité Spot est définie sur capacity-optimized de manière à garantir que vos nœuds Spot soient alloués dans des groupes de capacité Spot optimaux. 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 la capacité Amazon EC2 Spot est activé pour qu'Amazon EKS puisse purger et rééquilibrer vos nœuds Spot proprement, afin de réduire les perturbations des applications lorsqu'un nœud Spot présente un risque élevé d'interruption. Pour plus d'informations, consultez Rééquilibrage de la capacité Amazon EC2 Auto Scaling dans le Guide de l'utilisateur 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 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.

Considérations relatives à la sélection d'un type de capacité

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 d'entraînement par lots et de machine learning, des ETL de big data tels qu'Apache Spark, des applications de traitement des files d'attente et des points de terminaison d'API sans état. Étant donné que Spot est une capacité Amazon EC2 de réserve, 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 vCPU et de huit GiB de mémoire, utilisez des instances c3.xlarge, c4.xlarge, c5.xlarge, c5d.xlarge, c5a.xlarge, c5n.xlarge ou d'autres types d'instances 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 vCPU et de 8 GiB de mémoire, nous vous recommandons de créer un groupe de nœuds gérés avec des instances c3.xlarge, c4.xlarge, c5.xlarge, c5d.xlarge, c5a.xlarge, c5n.xlarge ou d'autres types d'instance similaires, et un deuxième groupe de nœuds gérés avec des instances 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 Personnalisation des nœuds gérés avec des modèles de lancement.