EKS : AWS étend et veut simplifier le support des versions de Kubernetes

Simplifier la gestion des versions de Kubernetes

Si le cycle de mise à jour du projet open source a ralenti sous l’influence des entreprises aux déploiements de plus en plus vastes, elles doivent désormais gérer une multiplicité de versions.

L’orchestrateur dépend d’un cycle de mise à jour trimestrielle : il faut donc compter sur trois mises à jour mineures par an, tandis que le patching d’une version est assuré pendant environ un an. « Comme vous le savez, les entreprises n’aiment pas mettre à jour leur système, à moins qu’elles soient obligées de le faire », constate Barry Cooks.

D’où l’annonce effectuée lors de son événement re:Invent 2023 d’un support étendu pour Elastic Kubernetes Service (EKS).

Actuellement, le control plane d’EKS peut prendre en charge quatre versions différentes de Kubernetes simultanément et permet d’assurer les mises à jour de sécurité, même quand certaines CVE n’ont pas encore été dévoilées, selon AWS.

Ce support étendu atteint désormais jusqu’à 26 mois maximum à partir de la version 1.23. Auparavant, AWS assurait un support de 14 mois.

Ce support couvre la fourniture de correctifs de sécurité pour le control plane Kubernetes d’EKS. AWS met également à disposition des patchs pour les modules VPC CNI, kube-proxy, Core DNS, les AMI EKS dédiées à Amazon Linux et Bottlerocket, ainsi que pour les nœuds EKS Fargate.

Il ne s’agit pas d’un service LTS (Long Term Support). « Je ne suis pas un adepte du principe des LTS, car cela vous oblige à effectuer un saut de génération. Nous n’allons pas forcer le client à adopter une version en particulier. Il aura accès au “menu” de toutes les versions à partir de la 1.23 », indique Barry Cooks.

Le précédent niveau de support devait « donner aux administrateurs suffisamment de temps pour effectuer une mise à jour par an, même s’ils doivent se renseigner auprès d’un éditeur d’une application et auprès des équipes internes ». L’offre étendue devrait donner un peu plus de flexibilité aux grands groupes.

« La plupart des administrateurs cherchent à maintenir une seule version de Kubernetes. Cependant, plus les déploiements sont importants, plus il est évident que c’est intenable », observe le vice-président Kubernetes chez AWS « Les équipes devOps peuvent avoir différents avis, différents comportements ».

Il est de plus en plus commun pour les équipes Ops de mettre en place une « Internal Developer Platform » (IDP), une sorte de PaaS permettant de donner accès à des services d’infrastructures et middlewares. « Les responsables des opérations essayent de contrôler sous le capot le comportement de la ou des distributions de Kubernetes ainsi que les versions disponibles », poursuit Barry Cooks.

« Ce que nous constatons, c’est que les Ops offrent un spectre de services à travers leur IDP. Par exemple, ils peuvent proposer du CaaS – les développeurs n’ont qu’à modifier quelques éléments de métadonnées que les Ops manipulent pour gérer les clusters et les pods EKS. D’autres utilisateurs sont des experts et souhaitent l’accès total à Kubernetes ».

« C’est très similaire au déploiement de systèmes d’exploitation. Beaucoup disent qu’ils veulent standardiser les déploiements sur la distribution d’un éditeur et sur une seule version pour ensuite “gérer la flotte”, mais la plupart du temps, il existe des exceptions à cela », nuance-t-il.

Dans cette veine, AWS bannit les fonctionnalités Alpha de ces distributions de Kubernetes. Il entend également réduire le temps de mise à jour de son control plane de 40 à 10 minutes en moyenne. En outre, sur sa feuille de route, AWS a prévu d’ajouter une fonction pour mettre à jour le plan de contrôle, les nœuds et les extensions d’EKS avec une seule commande. De même, il sera possible de générer un rapport sur la compatibilité des clusters déployés vers la prochaine mise à jour de Kubernetes. Ce rapport permettra de lister et de résoudre les éventuelles incompatibilités.

Enfin, AWS entend proposer une API s’appuyant sur certaines métadonnées des clusters pour vérifier programmatiquement les versions de Kubernetes.