Temps de lecture : 9 minutes

En décembre dernier, lors du re:Invent 2024, AWS a annoncé un nouveau mode de gestion des clusters Amazon EKS : Amazon EKS Auto Mode. AWS promet que ce mode simplifie la gestion des clusters, améliore les performances, la disponibilité et la sécurité des applications, et permet l’optimisation de coûts en continu.

Dans cet article, nous allons voir comment ce nouveau mode de gestion se compare aux autres méthodes. Cela vous aidera à déterminer s’il est pertinent d’adopter cette fonctionnalité pour gérer vos clusters.

Scaling dynamique avec Karpenter et Amazon EKS Auto Mode

L’orchestration de conteneurs avec Amazon EKS peut s’avérer complexe au fur et à mesure qu’il faut déployer et gérer un grand nombre de conteneurs, tout en garantissant la mise à l’échelle et en optimisant les ressources et les coûts.

Vous pouvez également être confronté à des défis liés à l’isolation des workloads entre les équipes et les nœuds. Par exemple, vous pouvez avoir besoin de dédier certains types d’instances à des workloads spécifiques.

Karpenter, un outil open-source initialement développé par AWS, répond à ces problématiques, en permettant de personnaliser les stratégies de mise à l’échelle et les affectations de nœuds pour vos pods.

Cependant, l’utilisation de Karpenter pose de nouveaux challenges. Il faut désormais gérer le cycle de vie d’un nouveau composant et en assurer sa maintenance, car il devient essentiel pour l’administration du cluster.

Pour déployer les contrôleurs Karpenter, on recommande généralement de les isoler des autres nœuds. On peut par exemple les déployer sur des instances EC2 dédiées, ou bien même sur des nœuds Fargate. Cela permet de garantir que l’on aura toujours un contrôleur associé à un noeud.

Source: AWS re:Invent 2024, Session: “Simplify Kubernetes workloads with Karpenter & Amazon Amazon EKS Auto Mode (KUB312)

Avec Amazon EKS Auto Mode, le client n’est plus responsable de la gestion du cycle de vie des contrôleurs Karpenter (de même que pour les contrôleurs qui gèrent le stockage et l’exposition réseau). 

Concrètement, cela signifie que lorsqu’on démarre un cluster avec Amazon EKS Auto Mode avec seulement le Control Plane déployé, il suffit d’initier un déploiement pour déployer des pods dans le cluster. 

Les nœuds sont alors automatiquement déployés en fonction des Node Pools définis au préalable. Pour rappel, un Node Pool définit la stratégie d’affectation des pods à un pool de types d’instances EC2, qui peut être configuré via différents paramètres.

Source: AWS re:Invent 2024, Session: “Simplify Kubernetes workloads with Karpenter & Amazon EKS Auto Mode (KUB312)”

Ainsi, lors de la création d’un cluster EKS Auto Mode, deux types de Node Pools sont disponibles en tant qu’option : “system” et “general-purpose” :

• Le Node Pool “système” permet de provisionner des instances pour déployer des add-ons additionnels que l’on souhaite isoler des instances utilisées pour les workloads. 
• Le Node Pool “general-purpose” permet de simplifier la mise en marche d’un cluster EKS et de déployer facilement des pods sur des instances à la demande à usage général.

Vous pouvez aussi créer vos propres Node Pools pour répondre à des besoins spécifiques. Par exemple, définir des Node Pools qui donnent la priorité aux instances spot pour optimiser les coûts, ou bien à des instances GPU pour des workloads d’IA.

Pour préconfigurer ces instances, on a un objet Node Class spécifique à EKS Auto Mode. Cela permet de définir des Security Groups, des subnet IDs, le stockage, etc. Cependant, il est important de noter qu’on ne peut pas spécifier d’AMI ID. 

En effet, l’une des principales caractéristiques de l’Auto Mode est la gestion automatisée des mises à niveau du cluster, qui repose entre autres sur la mise à jour des AMIs utilisées par les nœuds du data plane. 

Ces nœuds s’exécutent avec une AMI imposée par AWS et basée par défaut sur Bottlerocket (un système d’exploitation spécialement conçu par AWS pour l’exécution de conteneurs). On ne peut donc pas utiliser de custom AMIs dans ce cas.

Source: AWS re:Invent 2024, Session: “Simplify Kubernetes workloads with Karpenter & Amazon EKS Auto Mode (KUB312)”

Mises à niveau automatique des clusters

Avant d’entrer dans le détail de la fonction de mise à jour automatisée des clusters, il est important de noter que vous avez toujours la possibilité de déclencher la mise à niveau du control plane.

Amazon EKS ensuite vérifie les versions des contrôleurs managés, et met à jour uniquement ceux qui ne le sont pas.

Source: AWS re:Invent 2024, Session: “Simplify Kubernetes workloads with Karpenter & Amazon EKS Auto Mode (KUB312)”

Pour les nœuds du data plane, le processus de mise à niveau peut se déclencher selon deux scénarios.

1- Lorsque le control plane est mis à niveau vers une nouvelle version de Kubernetes, les nœuds du data plane sont remplacés par une AMI qui correspond à la version de Kubernetes du control plane.

Source: AWS re:Invent 2024, Session: “Simplify Kubernetes workloads with Karpenter & Amazon EKS Auto Mode (KUB312)”

2- Lorsqu’une nouvelle AMI est publiée et qu’elle intègre les derniers patchs de sécurité, les nœuds du data plane sont remplacés par l’AMI mise à jour.

Source: AWS re:Invent 2024, Session: “Simplify Kubernetes workloads with Karpenter & Amazon EKS Auto Mode (KUB312)”

Ces mécanismes respectent le cycle de vie des nœuds gérés par Karpenter et les disruption budgets, qu’il faudra définir avec précaution pour éviter des interruptions de service non souhaitées. Il est également important de garder à l’esprit que si les nœuds ne sont pas mis à jour malgré les différents événements affectant les instances Karpenter, AWS force la mise à jour le 21 de chaque mois.

Tarification

En ce qui concerne les coûts du control plane, il n’y a pas de changement. Amazon EKS Auto Mode suit le même modèle de tarification, à savoir un prix fixe de 0,10 $/heure, ou 72 $/mois pour le support standard (0,60 $/heure pour le support étendu).

Cependant, pour le data plane, la tarification est différente. Un coût supplémentaire est appliqué aux instances EC2, qui varie en fonction du type d’instance lancée. Sur la base des types d’instances que j’ai vérifiés, j’ai constaté un surcoût d’environ 12 %.

Il est essentiel de prendre en compte ce coût supplémentaire lors de l’évaluation de Auto Mode. Si réduire les coûts est une priorité, d’autres options comme la gestion du scaling dynamique avec Karpenter directement géré peuvent être plus avantageuses. Cependant, si la simplification des opérations et la réduction de la charge opérationnelle sont des facteurs importants, EKS Auto Mode peut justifier le coût supplémentaire.

Source: AWS website, Amazon EKS Pricing | Managed Kubernetes Service 

Quelques questions à se poser avant d’envisager EKS Auto Mode 

Afin de choisir la meilleure option pour gérer votre cluster Amazon EKS avec les capacités de scaling dynamique des nœuds, voici quelques questions à se poser pour déterminer si EKS Auto Mode répond à votre contexte :

La simplification des opérations du cluster et la réduction de la charge opérationnelle sont-elles une priorité ?

Si la gestion des composants clés comme Karpenter, AWS Load Balancer Controller ou EBS CSI demande du temps et des efforts, EKS Auto Mode peut être une excellente option car il réduit la charge opérationnelle. Cela peut justifier le coût supplémentaire pour les nœuds du data plane.

Quelle est l’importance de la conformité aux politiques internes dans l’entreprise ?

Si votre entreprise applique des exigences de conformité strictes, comme l’exécution d’instances avec des AMIs custom ou l’installation d’agents et de logiciels spécifiques (par exemple, des outils de logging, de monitoring ou de sécurité), EKS Auto Mode n’est peut-être pas la solution à envisager. Il ne prend en charge que des AMIs fournies par AWS, spécifiquement basées sur Bottlerocket.

Est-ce que j’ai besoin de fonctionnalités avancées de configuration réseau ?

On ne conseille pas EKS Auto Mode si votre contexte nécessite par exemple :

• D’utiliser des CNIs tiers à la place du VPC CNI AWS (Cilium, Calico..)
• D’attribuer des plages CIDRs personnalisées pour des pods, distincts des CIDRs associés au VPC.
• D’exploiter des fonctionnalités avancées telles que le ENI/IP/Prefix warming ou Security Groups per Pod

Est-ce que je veux bénéficier des mises à niveau automatiques du clusters, des nœuds et des contrôleurs managés ?

Si vous souhaitez réduire le temps passé à mettre à jour les composants de votre cluster, et que vous n’avez pas besoin d’un contrôle granulaire sur le processus de mise à jour, alors EKS Auto Mode est une option à envisager.

Sur la base de ces questions, j’ai fait un récapitulatif avec un diagramme de décision. En fonction de vos besoins, il vous aidera à identifier si EKS Auto Mode est un bon choix par rapport à Amazon EKS avec des instances EC2 directement gérées avec Karpenter.

Conclusion

Amazon EKS Auto Mode offre une solution puissante pour gérer les clusters Kubernetes en simplifiant la gestion des opérations, ainsi que le scaling dynamique. Sa capacité à gérer le cycle de vie de composants clés tels que Karpenter, les contrôleurs de réseau et de stockage, ainsi qu’à fournir des mises à niveau automatiques pour le cluster, les nœuds et les contrôleurs gérés, en fait une option attractive pour les équipes qui cherchent à réduire les coûts opérationnels, à améliorer les performances, la disponibilité et la sécurité des applications, et à optimiser les coûts.

Cependant, cette simplicité s’accompagne de compromis, comme une personnalisation limitée, un contrôle granulaire réduit et des coûts supplémentaires pour les nœuds du data plane. Ces contraintes pourraient donc décourager les équipes ayant des exigences de conformité strictes ou bien des besoins de personnalisation avancés.

Sources

• Streamline Kubernetes cluster management with new Amazon EKS Auto Mode
• AWS re:Invent 2024 – Simplify Kubernetes workloads with Karpenter & Amazon EKS Auto Mode (KUB312)
• Amazon EKS Pricing | Managed Kubernetes Service