Le Blog Amazon Web Services
Extension de l’API EKS: groupes de nœuds gérés
Dès nos premières conversations avec nos clients, notre vision a toujours été qu’Amazon Elastic Kubernetes Service (EKS) doit fournir la meilleure expérience Kubernetes géré dans le Cloud. Lorsque nous avons lancé Amazon EKS, notre première étape a été de fournir un “Control Plane” Kubernetes managé, mais nous n’avons jamais eu l’intention de nous arrêter là. Aujourd’hui, nous sommes ravis de vous montrer comment fonctionnent les groupes de nœuds gérés d’Amazon EKS.
Dans cet article, nous expliquerons pourquoi nous avons créé les groupes de nœuds gérés EKS, nous vous montrerons comment créer et gérer des nœuds pour vos clusters, ainsi que les prochaines étapes pour rendre encore plus facile l’exécution de Kubernetes sur le cloud AWS.
Vue d’ensemble
Les groupes de nœuds gérés facilitent l’ajout de nœuds (“Amazon EC2”) qui sont en charge d’offrir une capacité de calcul à vos clusters Kubernetes. Vous pouvez créer, mettre à jour, mettre à l’échelle ou mettre fin à des nœuds pour votre cluster Kubernetes avec une seule commande à l’aide de la console Amazon EKS, du CLI eksctl, de l’AWS CLI, de l’API AWS ou des outils d’Infrastructure as Code, notamment CloudFormation ou Terraform.
Chaque groupe de nœuds géré lance un Groupe Auto Scaling (ASG) pour votre cluster Kubernetes, qui peut s’étendre sur plusieurs zones de disponibilité. Amazon EKS orchestre alors les mises à jour et le drainage des nœuds avant les terminaisons de nœuds afin de garantir la haute disponibilité de vos applications.
Tous les nœuds fonctionnent avec les dernières AMI optimisées pour Amazon EKS de votre compte AWS. L’utilisation des groupes de nœuds gérés n’entraîne aucun coût supplémentaire. Vous ne payez que pour les ressources AWS, telles que les instances Amazon EC2 ou les volumes Amazon EBS, que vous avez provisionnés.
Avant d’entrer dans les détails du fonctionnement des groupes de nœuds gérés, voyons comment les groupes de nœuds gérés changent la façon dont vous exécutez vos clusters Amazon EKS.
L’API Amazon EKS étendue
Les groupes de nœuds gérés introduisent de nouveaux concepts dans l’API Amazon EKS :
Avant les groupes de nœuds gérés, comme indiqué à gauche ci-dessus, l’API Amazon EKS fournissait un Control Plane hautement disponible couvrant plusieurs zones de disponibilité, avec notamment la prise en charge de la journalisation et le support du least privileges (AWS IAM) au niveau du Pod. Une fois votre control plane créé, vous pouvez utiliser eksctl, AWS CloudFormation ou d’autres outils pour créer et gérer les instances EC2 de votre cluster. Nous avons donc étendu l’API Amazon EKS pour gérer de manière native le data plane Kubernetes, comme illustré à droite. Nous avons mis en avant les groupes de nœuds dans la console de gestion d’Amazon EKS, ce qui facilite la gestion et la visualisation de l’infrastructure utilisée pour exécuter votre cluster à un emplacement unique.
Pourquoi est-ce une étape importante?
Pour nous, cela pose les bases pour vous fournir un data plane managé de bout en bout, c’est-à-dire que nous pouvons nous occuper de tout, des correctifs de sécurité aux mises à jour de version de Kubernetes, en passant par la surveillance et les alertes. Nous nous rapprochons de notre vision qui consiste à fournir des clusters de production, en supprimant les activités non-différenciantes. Examinons de plus près l’API Amazon EKS.
Commandes de l’API Amazon EKS
Tout d’abord, examinons rapidement l’API de groupes de nœuds Amazon EKS du point de vue de l’AWS CLI. Pour simplifier les choses, nous montrons l’utilisation de la commande à un niveau conceptuel en omettant des paramètres supplémentaires, tels que --cluster-name que vous transmettriez à une commande lorsque vous l’appliquez réellement.
Afin de créer un groupes de nœuds managés, vous utiliseriez :
$ aws eks create-nodegroupVous ne pouvez créer pour votre cluster qu’un groupe de nœuds dont la version est égale à la version actuelle de Kubernetes pour le cluster. Tous les groupes de nœuds sont créés avec la dernière version AMI pour la version Kubernetes mineure du cluster. Au lancement, les nœuds gérés ne seront disponibles que pour les clusters Kubernetes à partir de la version 1.14 nouvellement créés (version 3 de la plate-forme). En outre, à l’heure où nous écrivons ce post, comme mentionné dans la documentation, il existe une limite sur le nombre groupes de nœuds gérés par cluster Amazon EKS. Nous conseillons à nos clients de tenir compte de ces limites lors de la construction de leur solution.
Pour voir les groupes de nœuds gérés s’exécutant sur un cluster, vous pouvez utiliser :
$ aws eks list-nodegroups
Pour plus de détails sur un groupe de nœuds managé spécifique, vous pouvez utiliser :
$ aws eks describe-nodegroup
Pour modifier la configuration d’un groupe de nœuds, telle que les paramètres de dimensionnement, vous pouvez utiliser :
$ aws eks update-nodegroup-config
Bien que les groupes de nœuds soient légers et généralement immutables, vous pouvez modifier trois paramètres :
- Ajouter et supprimer des labels Kubernetes. Tous les labels que vous modifiez directement via l’API Kubernetes ou via
kubectlne seront, pour l’instant, pas répercutées dans l’API EKS et ne seront pas associés dans les nouveaux nœuds lancés pour ce groupes de nœuds, - Ajouter ou supprimer des tags AWS. Les tags s’appliquent à l’objet node group de l’API EKS et peuvent être utilisées pour contrôler l’accès AWS IAM. Notez qu’au lancement, ces tags ne se propagent pas jusqu’aux ressources Amazon EC2 créées par le groupe de nœuds,
- Modifiez la taille de vos groupes de nœuds (nombre minimal, maximal et souhaité de nœuds).
La suppression d’un groupe de nœuds managé est effectuée via:
$ aws eks delete-nodegroup
La suppression des Pods des nœuds est automatiquement gérée lors de la suppression d’un groupe de nœuds ou de la mise à jour de sa version, ainsi que pour le rééquilibrage ASG / scale in. Il s’agit d’une grande amélioration par rapport à l’exécution de nœuds non gérés, pour lesquels vous deviez déployer des daemonsets ou des fonctions Lambda pour orchestrer la décommission « propre » des nœuds. Lors des mises à jour de version, Amazon EKS respectera la “pod disruption budget”, ce qui vous aidera à contrôler explicitement le cycle de vie des nœuds afin de maintenir vos pods critiques en vie jusqu’à ce qu’ils puissent être redistribués en toute sécurité.
Notez cependant que vous devez supprimer les groupes de nœuds attachés à un cluster avant de pouvoir supprimer le cluster lui-même, voir aussi la documentation relative aux groupes de nœuds gérés .
Procédure pas à pas dans la console Amazon EKS
Pour commencer, nous devrons créer un nouveau cluster Amazon EKS. Le premier écran de création du cluster avec la configuration générale du cluster, la sélection des groupes de sécurité / Amazon VPC, les paramètres de journalisation, etc. est inchangé et est donc ignoré ici. Toutefois, une fois votre cluster créé, vous devrez créer un rôle AWS IAM de nœud, conformément à la documentation EKS .
Une fois que le cluster Amazon EKS est actif, c’est-à-dire que le Control Plane est opérationnel, vous verrez l’écran de présentation du cluster, notez la liste de groupes de nœuds située sous la configuration générale du cluster:
Créons maintenant un groupe de nœuds avec les valeurs par défaut en cliquant sur le bouton Add node group :
Dans cette première étape, vous indiquez le nom du groupes de nœuds: ng0. Dans notre cas, spécifiez le rôle à utiliser pour le groupe de nœuds, c’est-à-dire le rôle AWS IAM que vous avez créé précédemment.
L’étape suivante consiste à définir la configuration des nœuds et le comportement de mise à l’échelle :
Lorsque vous spécifiez la configuration des nœuds comme indiqué ci-dessus, vous pouvez sélectionner l’AMI (avec ou sans prise en charge de GPU), la capacité de type On-demand ou Spot, le type d’instance, la taille de disque de l’Amazon EBS attaché pour chaque nœud du groupe de nœuds et enfin la scalabilité souhaitée :
Sélectionner les sous-réseaux pour le groupe de nœud.
En dehors de la configuration de la mise à l’échelle, des tags et des labels, le groupe de nœuds ne peut pas être modifié une fois qu’il a été créé. Avant de cliquer sur le bouton, vous avez la possibilité d’examiner le groupe de nœuds et de modifier les paramètres suivants :
Après une minute environ, les instances Amazon EC2 sont configurées et rejoignent votre cluster en tant que nœuds. Vous verrez ainsi ceci dans l’écran de vue d’ensemble du cluster :
Regardons si nous voyons également les nœuds dans Kubernetes :
En effet, nous avons les deux nœuds, appartenant au groupe de nœuds ng0, disponibles et prêts à nous permettre de déployer nos pods.
Ajoutons maintenant un autre groupe de nœuds appelé ng1. Nous attribuons des labels Kubernetes aux nœuds et appliquons une configuration de mise à l’échelle différente :
Notez au bas de la capture d’écran ci-dessus, que nous affectons le label nodegroup=managed aux nœuds du groupe de nœuds ng1.
Et maintenant, la configuration de mise à l’échelle avec une taille initiale (et minimale) d’un nœud:
Encore une fois, après quelques minutes, nous voyons le nouveau groupe de nœuds ng1,en plus du groupe initial ng0, dans la vue d’ensemble, prêt pour les applications :
Si vous le souhaitez, vous pouvez afficher les détails d’un groupe de nœuds, affiché ici ng1, et modifier ses labels Kubernetes :
Enfin et surtout, nous voyons tous les nœuds que nous avons créés, d’abord, puis filtrons par label (qui montre l’un des nœuds de ng1 sur lequel nous avons appliqué un label) :
À ce stade, vous pouvez ajouter d’autres groupes de nœuds, modifier les labels et la configuration de mise à l’échelle des groupes de nœuds ou supprimer ceux existants.
Maintenant que nous avons vu des groupes de nœuds gérés en action, intéressons-nous à un certain nombre d’autres fonctionnalités pertinentes relatives à l’API étendue et à ses fonctionnalités.
Autres considérations importantes
L’API EKS et eksctl
Depuis la version 0.10.1 de eksctl vous pouvez également bénéficier de la nouvelle API de groupe de nœuds et de gérer vos clusters Amazon EKS de manière déclarative, à partir de la ligne de commande. Au moment du lancement des groupes de nœuds gérés, le comportement par défaut de eksctl est identique à celui que vous avez déjà connu. Pour utiliser les groupes de nœuds gérés, vous devez spécifier le --managed paramètre comme suit :
Dans ce contexte, il est important de garder à l’esprit que eksctl est une CLI. Ainsi, elle fournit des fonctionnalités utiles que vous ne pouvez pas utiliser sans l’exécuter. Les nœuds gérés étant un système hébergé, nous surveillons constamment les nœuds et pouvons agir à tout moment pour répondre à des problématiques tels que le rééquilibrage AZ.
Lors du lancement de l’API EKS des nœuds gérés, la couverture des fonctionnalités par rapport à l’ eksctl sera la suivante:
| Fonctionnalité | API EKS | eksctl |
| Sélection de la zone de disponibilité | x | x |
| Mise à l’échelle des configurations | x | x |
| Configuration des tailles de volume | x | x |
| Prise en charge de l’accès SSH | x | x |
| Configuration réseau privée | x | x |
| Support for Amazon Linux 2 AMIs | x | x |
| Prise en charge d’Ubuntu | x | |
| Prise en charge de Windows | x | |
| Personnalisation fine (kubelet, volumes) | x |
Mise à jour de la version du nœud
Vous pouvez mettre à jour un groupe de nœuds managé vers la dernière version AMI optimisée pour Amazon EKS pour le type AMI que vous utilisez. Remarque: il s’agit d’un appel d’API distinct de la mise à jour de la configuration du groupe de nœuds.
Si votre groupe de nœuds correspond à la même version de Kubernetes que le Control Plane, vous pouvez effectuer la mise à jour vers la dernière version AMI pour cette version Kubernetes du type d’AMI que vous utilisez.
Si votre groupe de nœuds exécute une version Kubernetes plus ancienne que le cluster, vous pouvez mettre à jour le groupe de nœuds vers la dernière version AMI correspondant à la version Kubernetes du groupe de nœuds ou vers la dernière version AMI correspondant à la version Kubernetes du control plane.
Notez que les mises à jour de version nécessitent des redémarrages de nœuds, Amzon EKS tente de « vider »/ »drainer » les nœuds en premier et respecte “les pod disruption budget” que vous avez défini par défaut.
Les groupes de nœuds ne peuvent pas avoir plus d’une version de Kubernetes de retard par rapport au cluster. Cela signifie que tous vos groupes de nœuds doivent exécuter la même version de Kubernetes que le cluster avant de mettre à jour le cluster vers une nouvelle version de Kubernetes. Vous ne pouvez pas restaurer un groupe de nœuds vers une version antérieure de Kubernetes.
Healthcheck et observabilité
Nous vérifions automatiquement la configuration de votre groupe de nœuds et signalons tout problème via l’API et la console d’Amazon EKS. Cela inclut des informations sur les ressources requises supprimées, inaccessibles ou indisponibles (telles que Ec2LaunchTemplateNotFound et InsufficientFreeAddresses), les problèmes rencontrés lors des mises à jour (par exemple PodEvictionFailure et PodDeletionFailure), limites (par exemple, InstanceLimitExceeded), ainsi que des échecs de création et de suppression (tels que NodeCreationFailure). Dans la console d’Amazon EKS, vous remarquerez que tous les groupes de nœuds ayant des problèmes d’intégrité signalés seront marqués DEGRADED et vous pourrez voir plus de détails dans l’onglet Intégrité du groupe de nœuds.
Les fonctionnalités de journalisation Amazon EKS bien connues sont disponibles pour le Control Plane. Pour les journaux et les métriques du Data Plane, vous disposez de nombreuses options, en fonction du cas d’utilisation : de l’accès SSH direct au niveau du nœud au Routeur de logs open source en passant par Amazon CloudWatch Container Insights. Notez que tous les agents que vous installez ne sont pas gérés par AWS au moment du lancement.
En outre, un certain nombre d’événements au niveau du groupe de nœuds, tels que créer, mettre à jour et supprimer, sont enregistrés dans AWS CloudTrail. Notez que, même si nous effectuons un « drain » sur la terminaison de nœud et la suppression de groupe de nœuds, les événements respectifs ne sont pour l’instant pas disponibles via AWS CloudTrail.
Prochaines étapes
Nous continuerons à ajouter de nouvelles fonctionnalités et à améliorer la couverture des groupes de nœuds, en fonction de vos commentaires, notamment la prise en charge de types d’AMI supplémentaires Windows. Dites-nous quelles sont vos priorités et partagez-les si quelque chose ne fonctionne pas comme prévu. Faites-nous part de vos commentaires ici ou via un problème sur notre feuille de route AWS Containers sur GitHub .
Traduit en Francais et mis à jour par Guillaume Fediere, Solutions Architect chez AWS. Article Source rédigé par Raghav Tripathi, Michael Hausenblas, and Nathan Taber.