Kubernetes fête ses 10 ans ! À la mi-2024, la plateforme de gestion de conteneurs, leader sur le marché, célébrera son dixième anniversaire.
Jan Safranek, ingénieur logiciel principal chez Red Hat, a été témoin de l’effervescence qui a vu l’émergence de Docker, puis de Kubernetes, alors que les entreprises et les développeurs cherchaient des solutions pour assurer un stockage persistant.
Safranek a participé à l’introduction des PetSets et des StatefulSets, qui ont aidé à résoudre ce problème en gérant le déploiement et l’évolutivité des pods de conteneurs. Il a également contribué au développement des pilotes CSI (Container Storage Interface) et des Operators, qui fournissent des extensions logicielles pour gérer les applications et leurs composants.
Pour célébrer cette première décennie de Kubernetes, nous avons réalisé une série d’interviews avec des ingénieurs qui ont contribué à son développement et à la résolution des défis liés au stockage et à la protection des données, notamment à travers l’utilisation des Kubernetes Operators, tout en nous projetant vers un avenir marqué par des charges de travail en intelligence artificielle (IA).
Quel était le marché lors du lancement de Kubernetes ?
Jan Safranek : À l’époque, le monde était dominé par des serveurs physiques ou des machines virtuelles lourdes. Les conteneurs Docker ont rapidement gagné en popularité, mais il n’existait pas d’outils pour les gérer. Kubernetes a introduit un concept totalement nouveau pour exécuter des applications sous forme de morceaux légers et isolés.
Comment avez-vous été impliqué dans l’infrastructure de données autour de Kubernetes ?
Safranek : Cela a été assez simple pour moi. Je travaillais sur des outils de gestion de stockage Linux chez Red Hat et j’ai vu qu’une nouvelle équipe se formait pour aider avec Kubernetes. Je ne connaissais pas grand-chose à ce sujet, mais cela avait l’air intéressant, alors j’ai postulé.
Quand avez-vous réalisé que Kubernetes était en position de leader sur le marché ?
Safranek : C’était lors de ma première KubeCon à Seattle en 2016. Avant cela, j’avais rencontré d’autres ingénieurs qui faisaient des choses intéressantes. Mais là-bas, j’ai rencontré de vraies entreprises qui faisaient fonctionner des parties essentielles de leur infrastructure sur Kubernetes.
Comment avez-vous abordé les données et le stockage dans Kubernetes ?
Safranek : À mon arrivée dans l’équipe Kubernetes, il était déjà évident que, même si les conteneurs étaient éphémères, il fallait quelque chose de persistant dans l’ensemble. Les API de base étaient déjà présentes, même avec les premiers plugins de volume, mais personne ne savait vraiment comment les utiliser. Les PetSets ont été introduits, puis renommés StatefulSets, mais il reste encore des défis pour exécuter des applications lourdes basées sur des données sur Kubernetes.
Quels problèmes ont d’abord émergé autour des données et du stockage avec Kubernetes ?
Safranek : J’ai commencé à explorer ce qui existait déjà dans Kubernetes et comment l’utiliser. J’ai ajouté quelques exemples et tests de bout en bout pour me familiariser avec le code et le processus global. À l’époque, c’était assez simple. Je me souviens que les avancées étaient si rapides qu’il était difficile de garder mes demandes de tirage à jour.
Les premiers problèmes réels à résoudre concernaient l’exécution d’applications à état, ce qui a été résolu par les PetSets/StatefulSets, et la consommation de données à partir de systèmes de stockage externes à Kubernetes. Nous avons d’abord commencé avec du code intégré pour le stockage basé sur le cloud et quelques plugins génériques pour le stockage traditionnel comme NFS et iSCSI.
Qu’est-ce qui devait changer ?
Safranek : Avec l’adoption croissante, nous avons rapidement réalisé qu’il nous fallait un code plus robuste. Nos contrôleurs initiaux étaient très fragiles, donc nous avons dû tout réécrire pour garantir un comportement stable et cohérent. Il reste encore des améliorations à apporter, car tous ont survécu pendant des années avec seulement quelques corrections mineures.
De plus, à mesure que de plus en plus de fournisseurs de stockage souhaitaient intégrer leurs systèmes de stockage à Kubernetes, nous avons compris qu’il nous fallait une interface d’extension générique pour les plugins de volume. Nous avons d’abord proposé les FlexVolumes, qui étaient très difficiles à utiliser, mais nous avons appris et créé le CSI, qui est aujourd’hui l’interface de stockage principale de Kubernetes. Elle a connu un immense succès, avec au moins 130 pilotes qui se sont inscrits volontairement, sans compter ceux que nous ne connaissons pas.
Avec l’adoption de Kubernetes pour des infrastructures critiques, il est devenu essentiel de s’assurer que nous ne brisions rien. Il est désormais beaucoup plus difficile d’introduire une nouvelle fonctionnalité ou de modifier une existante, car de nombreuses revues et approbations sont nécessaires pour garantir la stabilité de nos versions.
Comment avez-vous été impliqué dans les Kubernetes Operators ?
Safranek : Red Hat a été l’un des premiers à adopter les Operators. Les débuts ont été assez animés. Personnellement, j’ai commencé avec quelques mauvais exemples, mais j’ai rapidement appris à écrire de bons Operators. Cela vient avec la pratique, comme tout dans le développement logiciel. De plus, il y a aujourd’hui plus de documentation que jamais.
Qu’est-ce qui a fait le succès des Operators pour les données et le stockage ?
Safranek : J’ai une expérience mitigée à ce sujet. De nombreux Operators ne sont pas meilleurs que les Helm charts [qui décrivent un ensemble de ressources Kubernetes liées]. Cependant, les bons ont aidé les entreprises à atténuer leurs difficultés avec des applications nécessitant des données persistantes. Il est toujours difficile d’exécuter correctement une application à état, en couvrant tous les cas particuliers.
Comment cela a-t-il soutenu des approches plus cloud-native ? Quelles en ont été les conséquences ?
Safranek : Comme je l’ai mentionné, il est plus facile pour les équipes DevOps de s’appuyer sur un Operator tiers pour gérer leur base de données ou d’autres charges de travail à état, leur permettant ainsi de se concentrer sur l’assemblage de ces éléments en une application performante qui fait fonctionner leur entreprise.
Kubernetes a maintenant 10 ans. Quelle est votre opinion aujourd’hui ?
Safranek : Eh bien, cela a été un parcours. Des débuts où chacun pouvait réécrire n’importe quoi à un logiciel extrêmement stable qui fait fonctionner une partie essentielle de notre monde, à un élément d’infrastructure devenu plutôt banal.
Quels problèmes persistent autour de Kubernetes en matière de données et de stockage ?
Safranek : Tous les conteneurs sont par nature éphémères et peuvent avoir une durée de vie courte. Kubernetes peut essayer de les faire fonctionner longtemps, mais lorsqu’il doit les supprimer, il le fera. Kubernetes propose certaines API, comme le PodDisruptionBudget, pour maintenir le nombre nécessaire de conteneurs en fonctionnement, mais toutes les applications à état doivent s’attendre à des interruptions. C’est un concept nouveau et il est encore difficile de le gérer correctement.
Avez-vous d’autres anecdotes ou informations à partager ?
Safranek : La meilleure chose à propos de mon travail sur Kubernetes, c’est que j’ai rencontré des personnes très intelligentes, j’ai beaucoup appris et je continue d’apprendre.
