Reyan's Cloudy ThoughtsEKS Auto Mode : ce qu'il faut savoir avant de se lancer
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 les opérations de cluster, améliore les performances, la disponibilité et la sécurité des applications, et optimise continuellement les coûts de calcul.
Dans cet article, nous explorerons comment ce nouveau mode de gestion se compare aux autres méthodes de gestion des nœuds. Cela vous aidera à évaluer s’il est pertinent d’adopter cette fonctionnalité pour gérer votre cluster.
Mise à l’échelle dynamique du calcul avec Karpenter et Amazon EKS Auto Mode
L’orchestration de conteneurs avec Amazon EKS peut devenir complexe lorsque vous devez déployer et gérer un grand nombre de conteneurs tout en assurant la scalabilité et en optimisant les ressources et les coûts.
Vous pourriez également faire face à des défis liés à l’isolation des charges de travail entre les équipes et les nœuds. Par exemple, vous pourriez avoir besoin de dédier certains types d’instances à des charges de travail spécifiques.
Karpenter, un outil open-source initialement développé par AWS, répond à ces défis en vous permettant de personnaliser les politiques de mise à l’échelle et l’assignation des nœuds pour vos charges de travail Amazon EKS.
Cependant, l’utilisation de Karpenter introduit de nouveaux défis. Vous devez maintenant gérer le cycle de vie d’un nouveau composant et assurer sa maintenance, car il devient critique pour l’administration du cluster.
Pour déployer les contrôleurs Karpenter, nous recommandons généralement de les isoler des autres nœuds de charge de travail. Une méthode pourrait être de les déployer sur des instances EC2 dédiées ou même des nœuds Fargate. Cela assure l’assignation cohérente d’un contrôleur à une instance de calcul.
Architecture de cluster Amazon EKS avec instances EC2 sans Auto Mode
Source : AWS re:Invent 2024, Session : “Simplify Kubernetes workloads with Karpenter & Amazon Amazon EKS Auto Mode (KUB312)”
Avec Amazon EKS Auto Mode, nous passons à un modèle où le client n’est plus responsable de la gestion du cycle de vie du contrôleur Karpenter (ainsi que des contrôleurs Storage et Networking).
En pratique, cela signifie que lors du démarrage d’un cluster avec Amazon EKS Auto Mode avec uniquement le Control Plane déployé, vous n’avez besoin que d’initier un déploiement pour déployer des pods dans le cluster.
Les nœuds sont ensuite 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’assignation des pods à un pool de types d’instances, qui peut être configuré dans les paramètres.
Architecture de cluster Amazon EKS avec instances EC2 avec Auto-Mode
Source : AWS re:Invent 2024, Session : “Simplify Kubernetes workloads with Karpenter & Amazon Amazon EKS Auto Mode (KUB312)”
De plus, lors de la création d’un cluster EKS Auto Mode, deux types de Node Pools sont proposés en option : “system” et “general-purpose”.
Le Node Pool “system” vous permet de provisionner des instances pour déployer des add-ons personnalisés que vous souhaitez isoler des instances utilisées pour vos charges de travail.
Le Node Pool “general-purpose” simplifie l’expérience de démarrage et vous permet de déployer facilement des pods sur des instances on-demand à usage général.
Bien sûr, vous pouvez aller au-delà de ceux-ci pour créer vos propres Node Pools qui répondent à vos besoins spécifiques. Par exemple, vous pouvez définir des Node Pools qui privilégient les instances spot pour optimiser les coûts ou des instances GPU pour les charges de travail IA.
Pour préconfigurer les instances créées dans ces cas, vous utilisez un objet Node Class spécifique à EKS Auto Mode. Cela vous permet de définir les security groups, les IDs de sous-réseaux, la configuration du stockage, entre autres choses. Cependant, il est important de noter que vous ne pouvez pas spécifier un ID AMI.
C’est parce qu’une fonctionnalité clé d’Auto Mode est la gestion automatisée des mises à niveau du cluster, qui repose sur la mise à jour des AMIs utilisées par les nœuds du plan de données.
Ces nœuds fonctionnent avec une AMI imposée par AWS basée sur Bottlerocket par défaut (un OS spécifiquement conçu par AWS pour exécuter des conteneurs). Par conséquent, vous ne pouvez pas utiliser vos AMIs personnalisées dans ce cas.
Mises à niveau automatisées du cluster
Pour approfondir les détails de la fonctionnalité de mise à jour automatique du cluster, il est important de se rappeler que pour le Control Plane, vous avez toujours la possibilité de déclencher la mise à niveau du Control Plane. Ensuite, Amazon EKS vérifie uniquement les versions des contrôleurs managés et met à jour uniquement les contrôleurs qui ne sont pas à jour.
Source : AWS re:Invent 2024, Session : “Simplify Kubernetes workloads with Karpenter & Amazon Amazon EKS Auto Mode (KUB312)”
Pour les nœuds du Data Plane, le processus de mise à niveau peut être déclenché dans deux scénarios.
- Lorsque le Control Plane est mis à niveau vers une nouvelle version Kubernetes, les nœuds du Data Plane sont remplacés par une AMI qui correspond à la version Kubernetes du Control Plane
Source : AWS re:Invent 2024, Session : “Simplify Kubernetes workloads with Karpenter & Amazon Amazon EKS Auto Mode (KUB312)”
- Lorsqu’une nouvelle AMI est publiée et intègre les derniers correctifs de sécurité OS, les nœuds du plan de données sont remplacés par l’AMI mise à jour.
Source : AWS re:Invent 2024, Session : “Simplify Kubernetes workloads with Karpenter & Amazon Amazon EKS Auto Mode (KUB312)”
Ces processus respectent le cycle de vie des nœuds gérés par Karpenter et le budget de perturbation, que vous devrez définir soigneusement pour éviter les temps d’arrêt indésirables. 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 et considérations de coût
Concernant 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, qui est 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 assez différente. Il y a un coût supplémentaire appliqué aux instances EC2, qui varie en fonction du type d’instance lancé. Basé sur les types d’instances que j’ai vérifiés, j’ai trouvé des frais supplémentaires d’environ 12 %.
Il est essentiel de considérer ce facteur de coût lors de l’évaluation d’EKS Auto Mode. Si la réduction des coûts est une priorité absolue, d’autres options comme la gestion manuelle de l’autoscaling avec Karpenter pourraient être plus avantageuses. Cependant, si simplifier les opérations et réduire la charge opérationnelle sont des facteurs importants, les avantages d’EKS Auto Mode peuvent justifier le coût supplémentaire.
Dans cet exemple ci-dessus, nous voyons que pour trois instances de types différents, l’activation d’Auto Mode ajoute des frais supplémentaires de 125,62 $ par mois, ce qui fait un total de 1 172,44 $ pour les coûts du plan de données.
Source : Amazon EKS Pricing | Managed Kubernetes Service
Questions clés à se poser si EKS Auto Mode peut être considéré
Pour vous aider à choisir la meilleure option pour gérer votre cluster Amazon EKS avec des capacités d’auto-scaling des nœuds, j’ai écrit quelques questions qui peuvent être utiles pour vous demander si EKS Auto Mode convient à votre cas d’usage :
Simplifier les opérations de cluster et réduire la charge opérationnelle est-il une priorité ?
Si la gestion de composants clés comme Karpenter, AWS Load Balancer Controller ou EBS CSI consomme beaucoup de temps et d’efforts, EKS Auto Mode pourrait être une excellente option car il réduit la charge opérationnelle. Il devrait également justifier un coût supplémentaire pour les nœuds du plan de données.
À quel point la conformité aux politiques internes est-elle critique ?
Si votre organisation applique des exigences de conformité strictes telles que l’exécution d’instances avec des AMIs personnalisées ou l’installation d’agents et logiciels spécifiques (par exemple, outils de logging, monitoring ou sécurité), alors EKS Auto Mode pourrait ne pas être le bon choix. Il ne supporte que les AMIs fournies par AWS, spécifiquement basées sur Bottlerocket.
Ai-je besoin de capacités de configuration réseau avancées ?
EKS Auto Mode pourrait ne pas être le bon choix si votre cas d’usage nécessite par exemple :
- L’utilisation de CNI tiers au lieu d’AWS VPC CNI (Cilium, Calico..)
- L’assignation de plages CIDR personnalisées pour les pods distinctes des CIDR du VPC.
- L’exploitation de fonctionnalités avancées comme ENI/IP/Prefix warming ou Security Groups par Pod.
Est-ce que je veux bénéficier de mises à niveau automatiques du cluster, des nœuds et des contrôleurs managés ?
Si vous voulez réduire le temps passé à mettre à niveau vos composants de cluster, et que vous n’avez pas besoin d’un contrôle granulaire sur le processus de mise à niveau, alors EKS Auto Mode est un candidat solide
Basé sur ces questions, j’ai fait un récapitulatif avec un diagramme de prise de décision. Basé sur vos besoins, il vous guidera pour identifier si EKS Auto Mode est un bon choix en comparaison avec Amazon EKS avec instances EC2 gérées par Karpenter
Conclusion
Amazon EKS Auto Mode offre une solution puissante pour gérer les clusters Kubernetes avec des opérations simplifiées, une mise à l’échelle automatisée et une gestion facile des nœuds. Sa capacité à gérer le cycle de vie de composants clés comme Karpenter, les contrôleurs réseau et stockage, ainsi qu’à fournir des mises à niveau automatiques pour le cluster, les nœuds et les contrôleurs managés, en fait une option attractive pour les équipes cherchant à réduire la charge opérationnelle, améliorer les performances, la disponibilité, la sécurité des applications et optimiser les coûts de calcul.
Cependant, cette simplicité vient avec des compromis, comme une personnalisation limitée, un contrôle granulaire réduit et des coûts supplémentaires pour les nœuds du plan de données. Ces contraintes peuvent décourager les équipes avec des exigences de conformité strictes, ou des besoins de personnalisation avancés.