10 ans de Kubernetes : « le système vit actuellement son adolescence »

Kubernetes la plateforme d'orchestration de containers, leader sur le marché, a 10 ans ! Peut-on dire qu’il s’agit à présent d’une solution mâture ? Patrick McFadin, responsable des relations avec les développeurs chez DataStax, répond par la négative : Kubernetes en serait plutôt au stade de l’adolescence, et même d’une adolescence rebelle. Selon lui, il reste à résoudre de nombreux problèmes d’inefficacité dans ses moyens d’administration.

Nous marquons la première décennie de Kubernetes par une série d'entretiens avec des ingénieurs qui ont contribué à développer Kubernetes et à résoudre ses enjeux du stockage et de la protection des données.

Patrick McFadin travaille chez DataStax, un spécialiste des bases de données NoSQL fortement impliqué dans le développement de Kubernetes. Interview.

À quoi ressemblait le marché lorsque Kubernetes a été lancé ?

Patrick McFadin : Lorsque Kubernetes est arrivé, il y avait plusieurs acteurs autour de l'orchestration de containers. Il y avait Docker Swarm et Apache Mesos, qui étaient conçus pour exécuter de grandes charges de travail analytiques. Kubernetes est arrivé avec un titre de gloire : il venait de Google. Et avec une promesse : résoudre la problématique de la gestion d'une grande infrastructure. Ces deux caractéristiques ont mis le public dans de bonnes dispositions pour croire en cette nouvelle solution.

Comment avez-vous été amené à travailler sur l'infrastructure de données autour de Kubernetes ?

Patrick McFadin : Travailler sur une grande base de données distribuée m'a placé au cœur des défis opérationnels pour les utilisateurs. Vous pouvez gérer une poignée de serveurs sans beaucoup d'outils, mais cela ne suffit plus lorsque vous dépassez 10, 100 ou 1 000 nœuds.

Mesos convenait parfaitement à Apache Cassandra et c'est la raison pour laquelle j'ai commencé à travailler sur ce projet. Je travaillais également sur Apache Spark, qui s'intégrait bien à Mesos. Quant à Kubernetes, il était à l’époque surtout connu en tant que gestionnaire de containers pour les applications frontales, de sorte que dans la communauté des infrastructures centrales, il n'avait pas d’impact important.

Puis, lors d'une conférence organisée en 2017 par Mesosphere, une société qui fournissait une version entreprise de Mesos, le PDG et cofondateur Ben Hindman a annoncé la prise en charge de Mesos par Kubernetes. Ce fut une sorte de révélation. Je me suis tourné vers la personne à côté de moi et j'ai dit : « Kubernetes vient de gagner la bataille des orchestrateurs de containers ». Cela a pris un certain temps, certes, mais je pense que c'est l'un des principaux tournants dans la carrière de Kubernetes.

Je suis donc passé de Mesos à Kubernetes. Et au départ, cela s’est mal passé. Le stockage des données était le principal problème. Mesos était bien meilleur pour gérer les ressources de stockage. Kubernetes proposait de configurer le stockage après tout le reste. Mais lorsque le fonctionnement de votre base de données est intrinsèquement lié à un stockage de haute qualité, ne pouvoir configurer le stockage qu’à coups d’ajustements a postériori est juste horrible. En réalité, éviter d’utiliser Kubernetes pour les applications liées aux bases de données a été la meilleure approche pendant longtemps.

Pouvez-vous détailler les problèmes que vous avez rencontrés ?

Patrick McFadin : Le provisionnement et la qualité. Au départ, Kubernetes traitait le stockage comme quelque chose d’éphémère, ce qui signifie que, dès que le container était supprimé, tout votre stockage disparaissait. Ce n'est pas bon pour les bases de données. Il existait quelques astuces pour maintenir les données d'un redémarrage à l'autre, mais aucune n'était intégrée à Kubernetes. S'agissant de volumes de containers, les performances laissaient beaucoup à désirer. Dans l'ensemble, de nombreux problèmes ont empêché les utilisateurs sérieux de se lancer.

La première chose à faire était de modifier la façon dont le stockage était géré. Kubernetes a fini par introduire le StatefulSet, ce qui a complètement changé la façon dont le stockage était provisionné. Cela a donné corps à tout ce dont un serveur « à état » [qui repart à chaque fois avec ses données précédemment enregistrées, NDR] avait besoin, typiquement tout ce qu’il fallait à un serveur de base de données.

Le grand changement suivant a été l'ajout d'opérateurs. Comme les serveurs étaient ajoutés à un système qui contrôlait le provisionnement, il fallait un moyen de communiquer aux serveurs des commandes telles que « start » et « stop ». Les opérateurs ont créé la couche de traduction entre Kubernetes et les services qu’on lui rajoutait.

Vous avez vous-mêmes été impliqué dans le développement de ces opérateurs. Comment cela s’est-il passé ?

Patrick McFadin : Au sein de la communauté Data on Kubernetes, nous avons beaucoup travaillé pour faire de ce concept un projet auquel les gens étaient prêts à adhérer. Lorsque nous avons commencé, nous avons reçu des commentaires disant : « Mettre mes données sur Kubernetes ? Vous êtes fou ? » Mais nous avons aussi vu beaucoup de développeurs dire : « Je veux tout en un seul endroit, alors faites en sorte que ça marche ».

Au fil du temps, cet effort communautaire a porté ses fruits. Je pense que 2022 a été le point de basculement où nous avons vu une majorité d’utilisateurs prêts à exécuter leurs bases de données sur Kubernetes. Cela s'explique par les efforts déployés pour créer des opérateurs de qualité.

Les opérateurs ont à la fois résolu un énorme problème et ils étaient simples à mettre en place. De nombreuses personnes ont créé leurs propres opérateurs - c'était comme si un nouvel opérateur pour les projets sortait tous les deux week-ends. C'était très bien, mais cela signifiait qu'il y avait beaucoup d’inertie avec des projets soit abandonnés, soit qui ne collaboraient pas assez. Tout le monde voulait être celui qui développerait tel opérateur ! Nous nous sommes retrouvés à un moment avec des tas de projets qui faisaient tous la même chose, de manière très légèrement différente.

Nous l'avons vu dans la communauté Apache Cassandra. Je pense qu'il y avait environ 12 opérateurs différents en simultané à un moment donné. Ils étaient tous bons dans des domaines spécifiques. Mais comme personne ne collaborait, il devenait impossible d’améliorer. Il a fallu un certain temps pour que la communauté se réunisse et se mette d'accord sur ce que nous voulions, sur ce sur quoi nous voulions travailler et sur la manière de le faire ensemble. Lorsque cela a commencé, je pense que cela a fait une énorme différence.

Quelles en ont été les principaux apports des opérateurs ?

Patrick McFadin : Je pense qu’ils ont favorisé l'approche cloud-native des applications, car ils ont permis d’exécuter des applications de manière cohérente avec l’infrastructure qui les portait à tel ou tel endroit.

Lorsque vous avez des microservices et des containers, vous voulez être en mesure d'évoluer et de déplacer les choses où vous en avez besoin. Si vous pouvez faire de même pour votre base de données, c’est encore mieux, cela simplifie les choses. Et si vous pouvez commencer par des tests qui démontrent que cela va fonctionner, vous passez bien plus facilement à la production.

C'est le sempiternel argument de la gravité des données. Nous avons vu les données se déplacer vers le stockage autour de la virtualisation. Et nous avons vu plus de données se déplacer vers le cloud avec les applications. Il fallait donc aussi voir les données se déplacer vers le cloud-native avec les containers.

Kubernetes a maintenant 10 ans. Qu'en pensez-vous ?

Patrick McFadin : Beaucoup de gens pensent que Kubernetes est terminé et que les choses vont désormais évoluer gentiment. Ce n'est pas mon cas. Je pense que nous sommes dans la phase de l'adolescence turbulente, que beaucoup de choses doivent encore être mises au point.

Certes, c'est un système stable, sur lequel vous pouvez compter. DataStax a construit son service Cassandra, Astra DB, sur Kubernetes. Je pense que c'est le meilleur soutien que nous pouvons lui apporter.

Cependant, il demeure des problèmes d’inefficacité. Il faut encore beaucoup d'efforts manuels pour réussir un déploiement Kubernetes. Et puis, s’il est facile d’étendre un cluster Kubernetes, il est beaucoup plus compliqué de réduire sa taille ! À tel point que c'est rarement le cas. L’intelligence artificielle générative va certainement être mise en œuvre à un moment ou l’autre pour adresser cette problématique au travers d’outils d’l'AIOps. On attend toujours de pouvoir expliquer ce que l'on veut du point de vue de l'application et que l'infrastructure émerge comme par magie.