Quel était le marché lors du lancement de Kubernetes ?

Xing Yang : Lorsque Kubernetes a été lancé, le marché de l’orchestration de conteneurs était encore en pleine émergence. Docker venait également d’être introduit et était devenu un outil populaire pour la création d’images. Kubernetes est un système d’orchestration de conteneurs qui facilite le déploiement d’images Docker sur des systèmes distribués, ce qui en fait un choix prisé, évoluant vers le système d’orchestration de conteneurs de facto d’aujourd’hui.

Comment vous êtes-vous impliquée dans ce domaine ?

Yang : J’ai commencé par contribuer au projet VolumeSnapshot dans le SIG Storage de Kubernetes en 2017, en collaborant étroitement avec Jing Xu de Google. Nous avons d’abord tenté d’introduire l’API VolumeSnapshot et le contrôleur dans le code de base de Kubernetes, mais cela a été rejeté par le SIG Architecture.

Ils nous ont demandé d’utiliser des CRD à la place, car Kubernetes devait être véritablement modulaire, extensible et maintenable avec un noyau minimal. Nous avons donc mis en œuvre la fonctionnalité VolumeSnapshot en dehors de l’arbre sous Kubernetes CSI. Cela a été la première fonctionnalité essentielle du SIG Storage mise en œuvre sous forme de CRD. Nous avons partagé notre expérience lors d’une présentation principale à KubeCon China en 2019 : Les CRD, ce ne sont plus des éléments de seconde classe !

Nous avons collaboré avec d’autres membres de la communauté pour faire passer la fonctionnalité VolumeSnapshot de l’état Alpha à Beta, et elle est finalement devenue généralement disponible dans la version 1.20 de Kubernetes. Je suis devenue mainteneuse dans le SIG Storage de Kubernetes.

Comment avez-vous réalisé que Kubernetes était en position de leader sur le marché ?

Yang : Kubernetes a été introduit par Google en juin 2014, puis a été donné à la Linux Foundation et est devenu le projet phare de la Cloud Native Computing Foundation (CNCF). D’autres grands fournisseurs de cloud public, tels qu’AWS et Azure, ont commencé à proposer des distributions Kubernetes sur leurs plateformes en 2017, les rendant généralement disponibles en 2018. Lorsque les principaux fournisseurs de cloud ont intégré des distributions Kubernetes, j’ai compris que Kubernetes prenait de l’ampleur dans le cloud et avait atteint une adoption en entreprise.

Quelle a été votre approche concernant les données et le stockage dans Kubernetes ?

Yang : À ses débuts, Kubernetes était destiné uniquement aux charges de travail sans état. À cette époque, les applications conteneurisées étaient considérées comme éphémères et sans état, et donc n’avaient pas besoin de persister des données.

Cependant, cela a changé de manière significative. Des charges de travail avec état ont commencé à s’exécuter sur Kubernetes. Des revendications de volumes persistants, des volumes persistants et des classes de stockage ont été introduits pour provisionner des volumes de données pour les applications fonctionnant sur Kubernetes. L’API StatefulSet a également été introduite pour exécuter des charges de travail avec état dans Kubernetes. De plus en plus de charges de travail avec état s’exécutent sur Kubernetes aujourd’hui.

Quels problèmes avez-vous rencontrés en matière de données et de stockage avec Kubernetes ?

Yang : Lorsque j’ai commencé à m’impliquer dans Kubernetes, la CSI venait d’être introduite. Elle visait à concevoir des interfaces communes permettant à un fournisseur de stockage d’écrire un plugin et de le faire fonctionner dans divers systèmes d’orchestration, y compris Docker, Mesos, Kubernetes et Cloud Foundry à l’époque.

Le premier ensemble d’interfaces CSI était très basique, incluant la création, la suppression, l’attachement, le détachement, le montage et le démontage de volumes. Cependant, pour prendre en charge les charges de travail avec état, des fonctionnalités plus avancées étaient nécessaires. Par exemple, la capture d’instantanés de volumes, le clonage, l’expansion de volumes et la topologie n’étaient pas prises en charge au début dans la CSI.

Quelles modifications étaient nécessaires ?

Yang : Des fonctionnalités plus avancées étaient nécessaires pour que la CSI puisse mieux prendre en charge les charges de travail avec état s’exécutant sur Kubernetes.

La capture d’instantanés de volumes a été introduite dans la CSI pour permettre aux volumes persistants d’être instantanés et utilisés comme moyen de restaurer des données en cas de perte ou de corruption de données. Le clonage de volumes a également été ajouté à la CSI, permettant de copier les données stockées dans un volume persistant pour créer un nouveau volume à partir de celui-ci.

La topologie de la CSI est également une fonctionnalité très importante pour les charges de travail de bases de données distribuées. Elle permet à Kubernetes d’effectuer une planification intelligente afin que le volume soit provisionné dynamiquement à l’endroit le plus approprié pour exécuter le pod. Ainsi, vous pouvez déployer et faire évoluer les charges de travail à travers des domaines de défaillance pour assurer une haute disponibilité et une tolérance aux pannes.

L’expansion de volume de la CSI est une autre fonctionnalité essentielle pour les charges de travail avec état. Elle permet d’augmenter la taille du volume si votre application nécessite plus d’espace pour écrire des données.

Il existe également la fonctionnalité de suivi de capacité de la CSI qui permet au planificateur Kubernetes de prendre en compte la capacité lors de la planification.

Il reste également des lacunes en matière de protection des données dans Kubernetes. Bien qu’il existe des éléments de base tels que les instantanés de volumes pouvant être utilisés pour les sauvegardes et les restaurations, davantage de mesures sont nécessaires pour protéger les charges de travail avec état en cas de catastrophe. Nous avons formé un groupe de travail sur la protection des données au début de 2020, visant à promouvoir le soutien à la protection des données dans Kubernetes.

Comment vous êtes-vous impliquée dans les opérateurs Kubernetes ?

Yang : Avec l’introduction de fonctionnalités de stockage plus avancées, Kubernetes est devenu une plateforme plus mature pour fournir du stockage aux charges de travail avec état, les bases de données étant l’un des types de charges de travail les plus importants.

En tant que co-présidente du CNCF TAG Storage, j’ai eu l’opportunité de collaborer avec la communauté Data on Kubernetes sur un livre blanc concernant l’exécution de bases de données dans Kubernetes. Comme discuté dans le livre blanc, les opérateurs sont l’un des modèles les plus importants utilisés lors de l’exécution de données dans Kubernetes.

Qu’est-ce qui a contribué au succès des opérateurs pour les données et le stockage ?

Yang : Les opérateurs tirent parti des CRD, qui sont flexibles et extensibles. De nombreuses bases de données traditionnelles n’ont pas été conçues à l’origine pour Kubernetes, mais avec les opérateurs, une logique métier complexe peut être encapsulée sous ces CRD. Pour les utilisateurs, il est facile de demander un cluster de bases de données en définissant une ressource personnalisée (CR). La logique de contrôle des opérateurs s’appuie sur la nature déclarative de Kubernetes et réconcilie l’état réel de la base de données avec l’état souhaité défini dans la CR, essayant continuellement de combler l’écart et de maintenir la base de données en fonctionnement.

Les opérateurs aident à automatiser les opérations de jour deux telles que la sauvegarde et la restauration, la migration, la mise à niveau, etc. Ils facilitent le portage des applications entre différents clouds ou le support des clouds hybrides. De plus, le CNCF dispose d’un écosystème riche avec de nombreux outils disponibles. Par exemple, Prometheus pour la surveillance, Cert Manager pour l’authentification, Fluentd pour le traitement des journaux, Argo CD pour la livraison continue déclarative, et bien d’autres. Les opérateurs peuvent utiliser ces outils tiers pour améliorer les capacités des clusters de bases de données fonctionnant dans Kubernetes.

Comment cela a-t-il soutenu des approches plus cloud-native ? Quelles en ont été les conséquences ?

Yang : Dans un environnement cloud-native, un pod Kubernetes exécutant une application de base de données peut être tué en raison d’une erreur de mémoire ou de CPU, ou redémarré si un nœud Kubernetes tombe en panne. Le stockage éphémère est étroitement lié au cycle de vie d’un pod, donc il disparaît avec le pod si vous utilisez un stockage local. Si vous utilisez un stockage externe, un autre problème se pose, à savoir la latence supplémentaire.

Les opérateurs peuvent aider à atténuer ces problèmes en fournissant une haute disponibilité, permettant aux applications de fonctionner de manière distribuée, automatisant le déploiement, fournissant une surveillance, gérant le cycle de vie des bases de données et permettant aux bases de données de fonctionner correctement dans un environnement Kubernetes.

Kubernetes a maintenant 10 ans. Quelle est votre vision aujourd’hui ?

Yang : Beaucoup de choses se sont produites au cours des 10 années qui ont suivi la naissance de Kubernetes. De nombreuses fonctionnalités ont été intégrées à Kubernetes pour prendre en charge les charges de travail de données, et Kubernetes devient de plus en plus mature. Kubernetes dispose d’APIs déclaratives. Il est flexible et extensible. Il offre un moyen d’abstraire l’infrastructure sous-jacente. Les opérateurs ont été une carte maîtresse pour étendre les cas d’utilisation de Kubernetes. Ils sont la clé qui permet aux bases de données de fonctionner dans Kubernetes.

Quels problèmes persistent autour de Kubernetes en matière de données et de stockage ?

Yang : Les opérations de jour deux restent un défi lors de l’exécution de données sur Kubernetes, mais cela peut être atténué en utilisant des opérateurs. Kubernetes est trop complexe, il faut beaucoup de temps pour se familiariser, et il nécessite un effort considérable pour gérer les charges de travail de données sur Kubernetes, ce qui complique l’intégration avec l’environnement existant.

De plus, pour les opérateurs, un manque de standardisation demeure un problème. L’exécution de charges de travail avec état dans un environnement multi-cluster reste également un défi, car Kubernetes a été conçu à l’origine pour fonctionner dans un seul cluster.

Avez-vous d’autres anecdotes ou informations à partager ?

Yang : Kubernetes a parcouru un long chemin depuis sa création il y a 10 ans. L’avenir s’annonce prometteur pour Kubernetes dans la prochaine décennie et au-delà.