10 ans de Kubernetes : « un système à toute épreuve grâce au stockage »

Le milieu de l’année 2024 marque le 10e anniversaire de Kubernetes, la plateforme d’orchestration de containers leader sur le marché. À cette occasion, la rédaction part à la rencontre des personnes qui ont contribué à son développement. Parmi elles, Michelle Au, ingénieure chez Google, a plus particulièrement travaillé sur les capacités de stockage et de protection des données. Interview.

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

Michelle Au : En 2014, les containers commençaient tout juste à susciter l’intérêt des entreprises qui y voyaient un nouveau moyen de virtualiser les applications. Pour franchir le pas, ces entreprises avaient néanmoins besoin d’un outil qui leur permette d’orchestrer l’exécution de leurs applications. Il existait déjà plusieurs projets : Mesosphere, Docker Swarm, Cloud Foundry, Nomad. Aucun ne prédominait vraiment. Kubernetes est arrivé et il s’est imposé comme la référence dans le domaine.

Comment vous êtes-vous impliqué dans le stockage pour Kubernetes ?

Michelle Au : En 2017, j’ai rejoint l’équipe Kubernetes chez Google et j’ai commencé à travailler sur des projets dans le cadre de la SIG [Special Interest Group, N.D.R.] dédiée aux questions de stockage. Je ne connaissais Kubernetes que de nom, mais j’étais enthousiaste à l’idée de participer à un projet Open source qui était en train de refaçonner la manière d’exécuter des applications.

L’enjeu à ce moment-là était qu’exécuter des applications capables de maintenir leur état et leurs données d’un nœud d’exécution à l’autre ne fonctionnait qu’à toute petite échelle. Le support des différentes infrastructures de stockage, la gestion des états lors des interruptions de service, la configuration de règles liées au stockage, la maintenance du stockage n’étaient pas clairement définis. De fait, exécuter des containers dits persistants passait par quantité de processus conçus au cas par cas.

C’était un problème pour la tolérance aux pannes. Il fallait que les applications interrompues à cause d’un incident soient capables de reprendre le fil de leur exécution sur un autre serveur.

L’un de mes premiers projets consistait donc à ajouter la prise en charge du stockage local. Lorsque j’ai commencé à me renseigner sur Kubernetes, les points forts qui m’ont immédiatement sauté aux yeux étaient son API déclarative, son concept de réconciliation qui permet de comparer l’état en cours d’une application avec son état attendu, la portabilité des flux d’exécution entre les environnements et l’importance accordée à la standardisation des bonnes pratiques de déploiement.

Ces concepts m’ont fait comprendre qu’il y avait, en matière de stockage, un problème plus large de prise en compte de la localisation des données. J’ai donc décidé d’aborder le problème en introduisant la notion de topologie de stockage dans le planificateur Kubernetes. Cela a simplifié le processus de provisionnement d’applications dites stateful, c’est-à-dire à base de containers persistants, pour qu’elles soient tolérantes aux pannes sur plusieurs infrastructures, qu’elles s’exécutent en cloud ou sur site.

Nous avons ensuite travaillé sur la prise en charge des snapshots, qui étaient une lacune majeure de Kubernetes, alors qu’ils sont essentiels dans tout processus de reprise après sinistre. Leur mise en œuvre s’est avérée étonnamment difficile, car les fournisseurs de solutions de stockage avaient tous des sémantiques légèrement différentes, qui nous empêchaient de trouver un consensus pour gérer la cohérence d’une application.

Comment êtes-vous passée de la prise en charge du stockage au développement des opérateurs ?

« Avec l’avènement des ressources personnalisées, beaucoup d’applications stateful avaient un certain nombre de processus opérationnels qui ne pouvaient pas être facilement abstraits dans le cœur de Kubernetes. »

Michelle Au : En tant que membre de l’équipe GKE (Google Kubernetes Engine), j’ai travaillé en étroite collaboration avec des clients et des partenaires. J’ai également rejoint la communauté Data on Kubernetes en tant que représentant de GKE afin de mieux comprendre les problèmes auxquels les utilisateurs étaient confrontés.

Il est apparu qu’avec l’avènement des ressources personnalisées, beaucoup d’applications stateful avaient un certain nombre de processus opérationnels qui ne pouvaient pas être facilement abstraits dans le cœur de Kubernetes : la configuration de la haute disponibilité, de la réplication, la gestion des processus d’interruption, la gestion des mises à jour.

Nous avons donc développé un système d’API déclaratives qui s’adaptent au cas d’utilisation spécifique de chacun : les opérateurs. Ils sont en mesure d’orchestrer cette complexité pour les utilisateurs finaux. Les API déclaratives rendent possibles des modèles de type GitOps ou config-as-code. De fait, les opérateurs pour les applications stateful facilitent l’automatisation du provisionnement, des mises à niveau et d’autres opérations de maintenance, et ont l’avantage supplémentaire d’être compatibles avec la façon dont les entreprises gèrent toutes leurs autres charges de travail Kubernetes.

Kubernetes a maintenant 10 ans. Quel bilan tirez-vous ?

Michelle Au : Kubernetes a parcouru un long chemin, quand on songe qu’il semblait au départ impossible d’exécuter une base de données sur des containers, alors que nous exécutons aujourd’hui des bases de données de plusieurs Po dessus. Qui plus est, avec des mises à niveau continues, toutes automatisées.

Il faut aussi saluer les efforts qui ont été faits ces dernières années sur le perfectionnement de la fiabilité, de la stabilité. Grâce à eux, Kubernetes est devenu une plateforme stable pour exécuter les applications les plus exigeantes.

« Un autre enjeu est la croissance de l’IA, un domaine dans lequel les modèles de données et les besoins techniques sont très différents de ceux des bases de données traditionnelles. »

Enfin, les environnements multicloud ou hybrides sont une réalité. Et malgré les exigences très complexes concernant la portabilité entre différents environnements que ces scénarios d’usage supposent, nous ne pouvons que nous féliciter de constater que les abstractions du stockage que nous avons développées fonctionnent toujours.

Il s’agit donc d’un bilan très positif. Il reste cependant des enjeux techniques. La découverte automatique de l’infrastructure sous-jacente, par exemple, puisqu’il existe de très nombreux fournisseurs et qu’il reste difficile pour les utilisateurs de prendre en compte toutes les options possibles dans leurs applications. À mon sens, les travaux de la communauté Data on Kubernetes peuvent apporter une aide essentielle dans ce domaine.

Un autre enjeu est la croissance de l’IA, un domaine dans lequel les modèles de données et les besoins techniques sont très différents de ceux des bases de données traditionnelles. Ne serait-ce que parce que l’IA utilise du stockage objet ou du stockage de fichiers au lieu du stockage en mode bloc. Ces enjeux guident nos développements actuels.