Storage 32 : Kubernetes, le nouveau terrain de jeu du stockage

Les containers, une nouvelle forme de virtualisation

Les containers sont nés en 2004 sur le système Solaris de Sun, comme une technologie de virtualisation non pas d’une machine entière, mais juste de l’environnement d’exécution du système d’exploitation. L’idée était simplement d’économiser l’empreinte mémoire et les ressources processeur. Dans une machine virtuelle, il faut embarquer un système Linux ou Windows complet pour exécuter une application. Mais si l’application est développée avec des langages d’assez haut niveau (Java…), finalement, qu’importe le système sous-jacent. Et si l’OS importe peu, autant mettre le même dans chaque VM. Et quitte à mettre le même, autant n’en faire fonctionner qu’une seule copie par machine.

Au-delà des ressources matérielles économisées, les équipes IT y voient un intérêt : pouvoir redémarrer très rapidement une application quand elle plante. On la relance juste en container, sans avoir à recharger tout un OS.

La communauté Linux a décliné le concept en 2008, en intégrant dans le noyau 2.6.24 de son système une sorte d’hyperviseur de containers baptisé LXC. Cela fonctionne un peu comme du multitâche, mais mieux cloisonné : chaque application est persuadée d’être la seule à fonctionner en mémoire et elle pense que l’OS qui l’exécute lui est dédié. Seule restriction, toutes les écritures que cette application fait au niveau du système (fonctionnelles, logs, etc.) ne sont pas vraiment écrites sur le disque, pour ne pas interférer avec les autres applications exécutées depuis d’autres containers. Le problème des conflits d’écriture se pose en revanche sur les volumes de données. À la charge de la DSI de les éviter.

L’arrivée de Docker en 2013 a permis d’apporter un peu de méthodologie au concept, à commencer par le fait de packager les containers sur disque, avec des paramètres, pour avoir une image prête à l’emploi, qu’on peut lancer automatiquement quand le moment est opportun (pic d’activité…), sur n’importe quelle machine.

Une orientation DevOps éventuellement contre-productive

C’est à ce moment que les containers ont plus ou moins échappé aux équipes IT pour devenir un sujet de développeurs. Il y avait la perspective de déployer plus facilement en production des applications qui étaient régulièrement mises à jour par ailleurs, sur un stockage central. Et même d’aller plus simplement exécuter ces applications en dehors des serveurs du datacenter, en cloud, sans forcément demander l’autorisation à la DSI.

Cette dérive a été accentuée à partir de 2015 avec l’arrivée de Kubernetes, qui se charge, tout comme vSphere, de déployer les containers sur les serveurs. La raison d’être de Kubernetes est de repenser les applications en microservices : on les découpe en petits bouts fonctionnels individuellement plus simples à mettre à jour. Quand une fonction évolue, on met à jour seulement son container, sans risquer de casser le reste des fonctions. Pour que cela marche, encore faut-il que tous les containers d’une application soient exécutés au même endroit et c’est ce dont se charge Kubernetes avec son concept de « pod ».

Kubernetes est de fait devenu la solution qui prend en charge le fonctionnement de l’infrastructure sous-jacente pour les développeurs : il sait quels serveurs ont les ressources nécessaires pour les applications (puissance CPU, connectivité réseau, etc.). Il configure les clusters à la place des équipes IT en termes d’OS (un Linux avec Docker, donc), de CPU virtuels, de ports réseau et aussi de ressources de stockage.

À ce titre, Kubernetes a plutôt tendance à tout bloquer. Pour être certain qu’une application soit exécutable n’importe où, il ne faudrait pas qu’elle commence à charger ou enregistrer des fichiers sur un volume POSIX ou Windows, qui n’est accessible qu’au serveur sous-jacent. La bonne pratique pour les développeurs, celle des applications dites « web-native », est de ne plus lire ou écrire directement des données, mais de les modifier en envoyant des requêtes HTTP à un hôte situé ailleurs, en l’occurrence un service de stockage objet identifiable par son nom de domaine.

La nécessité de réhabiliter Kubernetes parmi les produits d’infrastructure

Seulement voilà. Les applications dont se servent les entreprises, surtout pour leurs besoins internes, ne sont pas que des sites web. Le décisionnel, l’ingénierie, la logistique ont besoin d’écrire des fichiers et de lire des bases SQL, si possible à la vitesse de SSD NVMe. Et ces applications comme ces données sont précieuses : il faut les restreindre à des sites géographiques, les sauvegarder, les restaurer. À cause des opportunités offertes par le cloud hybride, il n’est pas question de cantonner ces besoins aux machines virtuelles ; elles, elles ne se déplacent d’un datacenter A à un cloud B qu’à la condition de retrouver la même infrastructure sous-jacente.

La bonne nouvelle est que toutes les opérations de gestion de données réalisables sous VMware ou sur des serveurs physiques sont possibles avec Kubernetes. Il dispose à présent de pilotes appelés CSI qui lui apportent la faculté d’utiliser normalement des baies de disques, des SSD internes, des NAS, des SAN et même des volumes de fichiers virtualisés par un SDS. Encore faut-il savoir quels produits sont mieux adaptés au fonctionnement concurrentiel des containers, lesquels sont plus adaptés aux déploiements de pods d’appoint hors site, lesquels prennent en compte les bonnes pratiques de la sauvegarde dans le cas d’un container, d’un pod, ou d’un cluster.

Téléchargez gratuitement le numéro 32 du magazine Storage.