Sécurité, coût, monitoring : AWS se met à la page sur Kubernetes
En sus d’avoir annoncé une nouvelle politique de support pour Elastic Kubernetes Service (EKS), AWS a présenté un ensemble de fonctionnalités visant à simplifier les opérations de sa distribution de Kubernetes. Le fournisseur comble là un ensemble de blancs pointés du doigt par ses clients.
Dans le but de simplifier la gestion des accès et des autorisations dans EKS, AWS annonce la disponibilité prochaine de la fonction IAM Cluster Access Management.
« Actuellement, vous utilisez les API EKS pour créer un cluster, puis celles de Kubernetes pour gérer les accès », avance Liz Duke, Principal Specialist SA Containers, chez AWS, lors d’une session du salon re:Invent 2023 consacrée à l’orchestrateur. « Un seul jeu d’API suffira pour gérer les identifications et les autorisations. Il n’y aura plus besoin de passer par un fichier YAML déroutant ». Les services compatibles avec EKS, dont EMR profitera de l’accès à IAM Cluster Access Management.
Outre une meilleure gestion des accès, AWS mise sur un meilleur contrôle des flux réseau liés à Kubernetes. Traditionnellement, les clients d’AWS devaient intégrer un CNI tiers pour implémenter leurs politiques de gestion réseau dans leur cluster EKS. Désormais, cette gestion des règles est intégrée dans le module Amazon VPC CNI for Kubernetes. « Nous utilisons eBPF qui présente beaucoup d’avantages par rapport à des approches traditionnelles comme les tables IP », avance Liz Duke. « Cela permet de filtrer des paquets, mais aussi bloquer les communications entre certains pods afin d’implémenter une approche du moindre privilège ».
Une nécessaire optimisation des coûts
« Il y a également un défi d’efficience », signale Barry Cooks, vice-président Kubernetes chez AWS. « Les microservices sont géniaux jusqu’à ce que vous vous retrouviez à en gérer des milliers. Les développeurs estiment souvent qu’ils ont besoin de grande quantité de ressources CPU et ce n’est pas toujours le cas ».
Les microservices sont géniaux jusqu’à ce que vous vous retrouviez à en gérer des milliers. Les développeurs estiment souvent qu’ils ont besoin de grande quantité de ressources CPU et ce n’est pas toujours le cas ».
Barry CooksVice-président Kubernetes, AWS
Justement, côté data plane, les clients d’AWS ont accès à quatre options. Il y a d’abord les instances EC2 self-managed, à gérer et à mettre à jour manuellement. Puis, il y a les nœuds EKS managés. S’ils s’exécutent dans le compte d’un client AWS, le fournisseur gère le provisionnement des nœuds et leur cycle de vie. Ensuite, il y a Fargate, le service dit serverless avec lequel AWS gère la gestion des capacités du cluster provisionnées à l’avance, le patching, et certains aspects de l’infrastructure.
La quatrième option consiste à gérer les instances EC2 self-managed avec l’autoscaler Karpenter, un outil open source en cours de donation à la Cloud Native Computing Foundation (CNCF).
Son rôle est de sélectionner la meilleure instance en fonction de la spécification qui régit un pod. Karpenter peut aussi rassembler des pods sur des nœuds via une technique de bin packing.
Un certain nombre de clients, dont Anthropic, la société derrière le modèle d’IA générative Claude 2, exploitent déjà Karpenter. « Anthropic est à l’origine d’une grande quantité de charges de travail IA/ML. Lorsque ses ingénieurs déploient Karpenter au moment de s’appuyer sur de très gros jeux d’entraînement, ils réduisent leur usage de 40 % », vante Barry Cooks.
La donation du projet en bêta à la CNCF serait motivée par le fait que les clients d’AWS « aiment l’open source ». « Ils aiment l’idée qu’ils ont la liberté de déplacer des éléments et obtenir des activités opérationnelles similaires dans le cloud et sur site », ajoute-t-il.
Par ailleurs, AWS a rappelé un partenariat avec KubeCost, l’éditeur d’une solution open source de supervision et de gestion des coûts liés à Kubernetes.
AWS muscle CloudWatch pour tenter de rattraper Datadog, Splunk, New Relic et Dynatrace
Cette optimisation des ressources et donc des coûts va de pair avec la nécessité d’obtenir des données granulaires sur le comportement du control plane et du data plane Kubernetes.
Ainsi, AWS a présenté au début du mois de novembre une « observabilité améliorée » pour EKS à travers la mise à jour Amazon CloudWatch Container Insights. Avec celle-ci, l’agent CloudWatch permet de collecter et d’agréger davantage de logs, de métriques et d’événements sur le comportement des conteneurs orchestrés par EKS et du control plane. Il s’agit par exemple de détecter les fuites de mémoire dans les conteneurs, surveiller l’état de l’autoscaling, mais aussi mieux trier la consommation de ressources par cluster, nœud ou charge de travail.
Le modèle économique change pour l’occasion : le service n’est plus facturé à l’ingestion de métriques, mais sur la base du nombre d’observations (une unité de mesure combinant l’ingestion des logs et le stockage des métriques en fonction de la taille du déploiement et du nombre de composants).
Pour la version managée de Prometheus, un système de monitoring apprécié des adeptes de Kubernetes, AWS propose un moyen de collecter automatiquement et sans agent les métriques compatibles avec Prometheus liées à EKS. Ce « scraper » managé dépend du déploiement d’une interface Elastic Network (ENI) par sous-réseau (subnet) et utilise la configuration remote_write de Prometheus pour stocker les données de télémétrie dans l’espace alloué à Amazon Managed Prometheus à travers un point de terminaison VPC.
« Cela permet d’alléger les charges de travail sensibles à la performance, car vous évitez sans doute les situations avec lesquelles le framework de monitoring cause des problèmes », résume Barry Cooks.
De même, AWS a lancé la préversion de CloudWatch Application Signals qui automatise l’instrumentation des applications, des services et des dépendances s’exécutant sur des instances EKS, ECS et EC2. Pour l’heure, cette fonction n’est disponible que pour les applications Java, mais le fournisseur prévoit de prendre en charge d’autres langages et environnements de programmation (JavaScript, Kotlin, Python, C++, Ruby, PHP, Go, iOS, Android).
« CloudWatch Application Signals est une solution de collecte de traces, de supervision des SLI, SLO et des SLA clés en main, qui s’appuie sur OpenTelemetry », indique le vice-président responsable de Kubernetes chez AWS.
Un orchestrateur de plus en plus managé
« Kubernetes était réputé pour être compliqué, il le reste ».
Barry CooksVice-président Kubernetes, AWS
Selon Barry Cooks, les solutions managées dans l’écosystème Kubernetes auraient de plus en plus de succès auprès des entreprises. « Kubernetes était réputé pour être compliqué, il le reste. Il y a cinq ans, les gens étaient un peu réticents à céder le contrôle. Aujourd’hui, certains d’entre eux réclament que nous leur soulagions des aspects opérationnels les plus complexes », affirme-t-il.
C’est aussi conjoncturel. « Je pense que la conjoncture économique de l’année dernière a joué un rôle à cet égard. Les entreprises doivent repenser certains aspects des opérations IT », analyse-t-il. « L’essor de l’IA et du machine learning a également contribué à cette évolution, car l’entreprise a désormais une orientation stratégique à laquelle elle veut consacrer son temps ».
Beaucoup des fonctionnalités présentées par AWS existent déjà chez les concurrents et partenaires du fournisseur. Par exemple, les acteurs du monitoring, dont Datadog et Dynatrace tendent à automatiser l’observabilité des environnements Kubernetes.
Le responsable estime toutefois qu’il ne faut pas brider l’écosystème et l’effervescence de composants supplémentaires dans l’univers Kubernetes. « Cette flexibilité fait partie du succès de Kubernetes. Nous ne voulons pas perdre ce pouvoir, car les organisations ont toutes des charges de travail différentes que l’orchestrateur peut prendre en charge ».
Pour autant, en 2024, l’équipe Kubernetes d’AWS continuera de chercher à prendre à sa charge les aspects les plus complexes de l’orchestrateur. « Nous parlons aux clients des choses qu’ils doivent faire au quotidien et qu’ils souhaiteraient ne plus avoir à faire. Et si nous pouvons les soulager de ces tâches, nous le ferons », conclut Barry Cooks.
Pour approfondir sur Administration et supervision du Cloud
