IBM Cloud Object Storage et les containers en environnement Kubernetes

Share this post:

Introduction : volumes persistants pour les containers en environnement Kubernetes

La technologie de containers et leur orchestration par Kubernetes s’impose aujourd’hui comme un standard pour des plates-formes de développement agile d’applications « Cloud-ready », par exemple grâce à l’environnement Redhat OpenShift promu par IBM.

Contrairement à un environnement traditionnel de machines virtuelles, les containers sont beaucoup plus légers au niveau de l’exécution et non persistants. C’est-à-dire qu’ils n’utilisent pas un stockage de type disque virtuel ou même volumes « Raw » affecté à l’environnement d’exécution. Une fois l’instance du container effacée, le stockage propre au container sur lequel il a travaillé disparait avec lui.

Cela ne pose pas de problème si les accès au stockage sont réalisés au travers de systèmes externes au container, par exemple en mode client/serveur de type base de données, mais c’est une limitation si le container doit écrire sur un stockage persistant de type fichier tout comme le ferait une VM ou même une machine physique.

Cette persistance est en particulier nécessaire si les données sont à préserver ou à partager avec d’autres containers instanciés en parallèle ou ultérieurement.

Il est donc nécessaire de mettre en place une technique de persistance sur des systèmes de stockage, principalement en mode fichier, car les containers, tout comme les machines virtuelles utilisent principalement une interface système de fichier (identique à celle d’un système Linux) pour écrire et lire des données dans l’instance. L’approvisionnement de volumes en mode « bloc » est aussi possible suivant les besoins.

Une interface s’est imposée très récemment pour cela et s’appelle CSI (Container Storage Interface). Cette interface permet la création de volumes persistants sous le contrôle de l’orchestrateur Kubernetes et d’une fonction de Persistant Volume Claim (PVC) avec affectation aux containers qui en ont besoin.

Cette interface a été adoptée par la plupart des fournisseurs de systèmes de stockage disque ou fichiers qui offraient déjà des interfaces pour des environnements physiques ou virtualisés existants.

Rappel sur les accès applicatifs directs au stockage objet

Contrairement au stockage fichier ou bloc traditionnel, l’accès au stockage objet n’a besoin d’aucune interface vers le système de fichier ou le système d’exploitation. En effet, les primitives d’accès au stockage sont directement utilisées par le code des applications avec les opérations simples du standard S3 (PUT, GET, LIST, POST).

Ainsi, un container qui est instancié avec une application utilisant ces primitives a juste besoin d’une interface réseau pour accéder au stockage objet persistant (via les protocoles http ou mieux https si on souhaite une communication sécurisée).

Le stockage objet est donc parfaitement adapté aux applications de nouvelle génération, tout en restant utilisable et pertinent pour des environnements plus traditionnels (partage de fichiers, archivage, sauvegarde, GED, analytique/intelligence artificielle, vidéo, …)

La persistance des données stockées est assurée par un stockage objet externe, et les accès à ce stockage entre plusieurs containers est possible sous réserve que les droits d’accès soient correctement définis (paire « Keyid / SecretKeyid » du protocole S3).

Le stockage objet n’est donc pas obligatoirement accédé via une couche d’interface au stockage persistant de type bloc ou fichier. Toutefois, l’usage du stockage objet tendant à s’universaliser, y compris pour les accès en mode fichier, des interfaces plus classiques peuvent être envisagées pour les containers.

Accès via une interface S3FS (mode Fuse)

Une technique déjà disponible et répandue dans l’environnement ouvert des containers est l’interface Open Source S3FS (voir le site pour plus de détails sur les environnements supportés). Elle permet de stocker de manière persistante des fichiers sur un stockage objet.

Le schéma suivant illustre le principe générique d’accès à un système de stockage objet COS à partir de l’interface s3fs :

A noter : ce principe s’applique à tous les environnements système supportés par Linux et MAC OS, y compris des environnements physiques et virtualisés.

En environnement container, il est utilisé de la même manière, mais sous le contrôle et l’orchestration de Kubernetes :

Le container utilise le stockage objet mis à disposition par l’orchestrateur Kubernetes, exactement comme le ferait un environnement système virtualisé ou physique. Le container voit et utilise le stockage objet comme un système de fichiers additionnel aux espaces de fichiers non persistant créés à l’instanciation du container. Les applications peuvent écrire leurs données en mode fichier traditionnel sans savoir qu’il s’agit d’un stockage objet à la cible.

D’autres applications dans d’autres containers peuvent éventuellement partager le même espace ou d’autres espace de stockage objet suivant les droits d’accès affectés à ces containers.

Accès avec CSI ou OBC/OB ?

L’interface CSI est aujourd’hui normalisée et implémentée pour le stockage persistant sur de nombreux supports traditionnels « bloc » ou « fichiers ». La liste des « Production Drivers » est référencée sur le site.

Respectueux des standards du marché et de leur adoption, IBM garanti naturellement la conformité de sa gamme de systèmes de stockage bloc et fichier avec ce standard (IBM FlashSystem 9100, IBM Storwize, IBM San Volume Controller, IBM A9000/A9000R et IBM Spectrum Scale).

Du fait de la nature particulière du stockage objet, la question de l’adoption de cette interface pour le stockage objet fait encore débat fin 2019. Elle est alimentée par l’émergence d’interfaces différentes au sein de la communauté Open Source Kubernetes tel que la méthode Object Bucket Claim/Object Bucket (OBC/OB).

OBC/OB est une méthode similaire au mécanisme Persistent Volume Claim/Persistent Volume du driver CSI pour le stockage bloc et fichiers, mais plus adaptée aux particularités du stockage objet.

Pour supporter la méthode OBC/OB, il est nécessaire de disposer du support « Object Storage Provisioner » qui est un service fonctionnant sur K8s/OpenShift.

Ce support est en cours de développement et prévu d’être supporté en 2020.Plus d’informations sur le développement d’OBC/OB peuvent être trouvée sur le site.

Conclusion

L’environnement de développement Open Source Kubernetes et les technologies de containers associées (Docker ou CRI-O) sont en évolution rapide. L’interface CSI est maintenant largement adoptée pour le stockage « bloc » ou fichier et disponible sur la plupart des systèmes de stockage traditionnels.

Fin 2019 pour le stockage objet, l’adoption d’un nouveau standard d’interface pour le stockage persistant est encore un sujet de débat. Il devrait être clarifié durant l’année 2020 à l’issue de travaux communautaires autour des différentes options qui sont aujourd’hui offertes. Il est donc important de rester attentif aux évolutions rapides qui interviendront très prochainement sur ce sujet.

En savoir plus sur IBM Cloud Object Storage.