10 ans de Kubernetes : « le plus compliqué à faire, c’était le 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, Saad Ali, ingénieur logiciel chez Google, est considéré comme le concepteur même du système. Il raconte ici les premiers enjeux en matière de stockage et de protection des données, son implication dans le développement des pilotes CSI et comment il a résolu le problème du stockage persistant dans un environnement élastique. Interview.

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

Saad Ali : Lorsque Kubernetes a été lancé, les développeurs et les fournisseurs de solutions d’infrastructure étaient très intéressés par les containers, mais ils ne savaient pas par où commencer. Docker avait posé les bases sur les stations de travail des développeurs et tout le monde se demandait comment étendre le principe technique à une plus grande échelle.

Il y avait en particulier une incertitude en ce qui concerne la manière de stocker les données de manière persistante, c’est-à-dire la capacité à charger ou sauvegarder des fichiers dans un volume qui reste accessible quand le même container est exécuté sur une machine différente. Les spécialistes du secteur étaient prêts à investir beaucoup d’argent dans le développement d’une solution, mais personne n’était sûr de la direction technique à prendre.

Les premiers à s’être lancés ont développé des plugins de type « In-Tree » pour accéder à des volumes en mode bloc et/ou fichiers. Ces plugins étaient intrinsèquement liés au code maître de Kubernetes. C’est-à-dire qu’à chaque fois que le code maître était mis à jour, il fallait réadapter le plug-in. C’était invraisemblable.

Quel était plus exactement le problème de stockage qu’il fallait résoudre ?

Saad Ali : L’ambition de Kubernetes était de rendre les charges de travail en containers élastiques, c’est-à-dire de répliquer les containers sur autant de nœuds de calcul que nécessaires pour suivre les pics d’activité, ou déplacer les charges de travail de machine en machine selon l’endroit où il faut les exécuter.

Dès la version 1.0, il était prévu que Kubernetes, via des plugins, puisse accéder à une unité de stockage locale, qu’il pouvait formater et monter, soit en mode bloc, soit en mode fichier, pour que ses pods de containers puissent charger et sauvegarder leurs données dessus. Au fur et à mesure que les pods se déplaçaient d’un nœud à l’autre, leurs volumes étaient démontés à un endroit et d’autres volumes étaient remontés ailleurs pour qu’ils puissent continuer à sauvegarder leurs données.

« Il était crucial d’implémenter dans Kubernetes un système de stockage qui n’a plus besoin d’être ancré au nœud sur lequel les containers sont provisionnés. »

Mais, pour assurer la continuité des données, encore fallait-il que ce soit toujours la même unité de stockage au départ comme à l’arrivée. Pour y parvenir, il fallait que l’unité de stockage montée dans Kubernetes ne corresponde plus forcément aux disques durs du serveur qui exécute les pods de containers. Cela devait pouvoir être une unité de stockage externe, utilisable à distance par plusieurs serveurs. C’était la clé pour rendre les applications qui ont besoin d’une continuité des données (« avec état », ou « stateful ») aussi élastiques que les applicatifs d’appoint (« stateless »).

Au-delà de l’aspect physique de l’emplacement du stockage, il était crucial d’implémenter dans Kubernetes un système de stockage qui n’a plus besoin d’être ancré au nœud sur lequel les containers sont provisionnés. Cela devait permettre au cluster de containers de s’autoguérir, sans intervention humaine, en cas d’incident. Il fallait pouvoir déployer des containers qui savaient automatiquement retrouver leur stockage. Il ne fallait pas être dans la situation ou un humain déploie des containers à un endroit, puis configure manuellement cet endroit pour lui indiquer où se trouve le stockage des données.

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

Saad Ali : J’ai commencé à m’intéresser à l’aspect stockage de Kubernetes au fil des corrections de bugs. Il y avait en particulier un problème dit de « Race conditions » qui signifie que la donnée d’un container n’est plus cohérente parce qu’elle a été modifiée par autre chose au mauvais moment. Ce problème existait depuis la version 1.0. J’ai fini par introduire dans Kubernetes 1.3 une vaste réarchitecture de la pile de cycle de vie des volumes. J’ai extrait la logique d’attachement/détachement du kubelet à un volume pour la déplacer dans un contrôleur central, ce qui réduisait les risques de Race conditions.

À partir de là, je suis devenu co-responsable de l’atelier – un SIG, ou Special Interest Group – dédié aux fonctions de stockage. Et l’un de mes principaux domaines de recherche au cours des années suivantes a été de trouver comment rendre le stockage Kubernetes plus extensible. C’est ainsi que j’ai participé à la mise au point du dispositif CSI, ou Container Storage Interface, qui allait porter les pilotes de stockage dans Kubernetes.

Comment les pilotes CSI se sont-ils imposés ?

Saad Ali : Lorsque nous avons commencé à développer CSI, je suis allé à une conférence à San Francisco pour en parler à la communauté. Lors de ma présentation, l’un des spectateurs a demandé : « qu’est-ce qui rend cet effort différent de tous les efforts de la communauté OpenStack pour standardiser le stockage ? Qu’est-ce qui vous fait penser que cette fois-ci ce sera la bonne ? »

« Plus de fournisseurs développant pour Kubernetes ont rendu Kubernetes plus utile, ont augmenté l’adoption de celui-ci et ont conduit à plus de fournisseurs développant pour lui. »

J’ai compris à ce moment que ce n’est pas parce que nous avions planché sur quelque chose qui fonctionne que son succès serait garanti. Donc nous avons redoublé d’efforts pour impliquer la communauté des fournisseurs de stockage dans CSI, pour bâtir très méthodiquement une solution, en cadrant chaque étape l’une après l’autre. Nous nous sommes refusés à dire qu’il s’agirait d’une version 1.0 tant qu’il n’existerait pas un nombre significatif de pilotes CSI parfaitement fonctionnels sur le marché.

Cela a permis aux fournisseurs de stockage de se sentir suffisamment à l’aise pour investir dans la création de plugins. Et cela a conduit à un cercle vertueux : plus de fournisseurs développant pour Kubernetes ont rendu Kubernetes plus utile, ont augmenté l’adoption de celui-ci et ont conduit à plus de fournisseurs développant pour lui. C’est lorsque la liste des pilotes CSI a dépassé les 100 pilotes que j’ai compris que nous avions réalisé quelque chose de spécial.

Quelles ont été les difficultés techniques que vous avez dû surmonter ?

Saad Ali : La pile de stockage de Kubernetes est incroyablement compliquée. L’une des plus grandes difficultés de la pile de stockage est qu’elle doit gérer le compromis entre la récupération automatique et la perte ou la corruption des données. Aucune des deux n’est acceptable. Nous avons travaillé très, très dur pour identifier tous les scénarios défavorables et mettre au point des récupérations de données fluides même dans les cas extrêmes.

Il y a eu d’autres travaux. À l’origine, la pile de stockage Kubernetes supposait qu’un administrateur de stockage pré-provisionnerait un pool de volumes en mode bloc ou fichier de différentes tailles, pour que les opérateurs d’applications puissent les utiliser. Cela conduisait à une utilisation inefficace de la capacité de stockage disponible.

Au sein de l’atelier SIG Storage, nous avons introduit le concept de provisionnement dynamique, à partir de Kubernetes 1.6. Cela a changé la donne pour l’utilisation élastique du stockage en mode bloc ou fichier, en complétant les efforts d’automatisation du cycle de vie du volume de stockage. À partir de sa version 1.6, Kubernetes provisionne le stockage à la demande selon les besoins des charges de travail, élimine l’intervention humaine et permet une utilisation efficace de la capacité de stockage.

« Il est apparu que de nombreuses applications complexes avec état nécessitaient une orchestration plus minutieuse de leurs données. »

Les éléments constitutifs se mettaient en place : StorageClass, interfaces PersistentVolumeClaim (PVC) et PersistentVolume (PV), CSI, provisionnement dynamique… Nous allions petit à petit vers l’orchestration de primitives stateful (liées aux applications persistantes, avec état) de niveau toujours plus haut. Kubernetes proposait des StatefulSets comme blocs de construction pour les charges de travail avec état.

Mais il est apparu que de nombreuses applications complexes avec état nécessitaient une orchestration plus minutieuse de leurs données. Il fallait permettre des choses comme la réplication automatique selon les besoins de haute disponibilité, mais aussi le calcul constant d’une mise à l’échelle selon les pics d’activité, etc.

C’est là que les opérateurs Kubernetes sont entrés en jeu. Ils offrent un moyen simple d’étendre Kubernetes pour permettre des opérations adaptées aux applications. Citons la répartition automatique des données, le fait d’éviter que toutes les répliques ne deviennent indisponibles en même temps.

Les opérateurs ont favorisé des approches plus cloud-natives. La pile de stockage Kubernetes et les opérateurs Kubernetes permettent une utilisation véritablement élastique des ressources informatiques disponibles. Ils concrétisent un grand pool élastique de ressources de calcul, qui peut être utilisé par toutes vos charges de travail, à la demande, avec une mise à l’échelle sans intervention humaine, afin de maximiser la disponibilité et réduire les coûts.

« Si l’on parle de problèmes actuels de Kubernetes vis-à-vis du stockage de données, ce n’est peut-être plus un problème intrinsèque à Kubernetes qu’il faut résoudre. »

Quels sont les problèmes qui subsistent dans Kubernetes en ce qui concerne le stockage de données ?

Saad Ali : Kubernetes a grandement facilité le développement d’applications élastiques qui stockent des fichiers ou des données en mode bloc (cas des bases de données). Le problème est que le principe même de stocker des fichiers ou des bases de données reste compliqué pour de nombreux développeurs, qui ne veulent pas se préoccuper du fonctionnement de ces architectures. Ils ne veulent pas être impliqués dans la façon de stocker en SQL, dans les différences entre réplication asynchrone et réplication synchrone, des compromis à faire pour la redondance du stockage, etc.

Donc, si l’on parle de problèmes actuels de Kubernetes vis-à-vis du stockage de données, ce n’est peut-être plus un problème intrinsèque à Kubernetes qu’il faut résoudre. Nous devons trouver un moyen pour faciliter la redondance, les performances d’applications avec état, quel que soit le profil du développeur.