Kubernetes scelle le mariage entre big data et containers
Historiquement, les architectures d'application containérisées sont dites sans état (ou stateless). Ephémères, les data qu'elles contiennent sont qualifiées de non-persistantes dans le jargon des spécialistes. Stockées dans une sandbox pendant la durée d'exécution du container auquel elles sont associées, ces informations sont ensuite éliminées. Lancé par Google en 2014, l'orchestrateur de containers open source Kubernetes se limite au départ au mode stateless. Mais face au besoin exprimé alors par le marché en faveur du stateful, une étape est franchie en 2017 avec l'intégration d'une première solution : le contrôleur StatefulSets. Objectif affiché : assurer la persistance des données et des id réseau au niveau de l'unité la plus simple de l'architecture Kubernetes, à savoir le pod. Une brique qui se présente le plus souvent sous la forme d'un container unique ou de plusieurs containers partageant des ressources réseau et de stockage.
Introduits par Kubernetes en 2016 dans le sillage de leur implémentation par CoreOS, les operators contribuent à ouvrir de nouvelles perspectives en matière de gestion de la data au sein de l'orchestrateur. Leur vocation : permettre à des tiers d'équiper le framework d'extensions. Présentes dans de multiples domaines (identification, machine learning, monitoring, réseau...), un hub a été lancé pour les répertorier. "Avec les operators, nombre d'infrastructures ont été intégrées à Kubernetes autour du pilotage des données", souligne Romain Vrignaud, DevOps product specialist chez Google. Au chapitre des bases de données par exemple, on relève des opérateurs pour Elasticsearch, MongoDB, PostgreSQL ou encore Redis, et côté big data des opérateurs pour Apache Spark (en bêta), Apache Kafka ou Airflow.
"Les operators sollicitent directement les primitives de Kubernetes via son API en vue de piloter les serveurs de fichiers ou de données de façon distribuée", ajoute Bastien Legras, directeur technique de Google Cloud en France.
"L'interface CSI permet aux providers de systèmes de stockage de venir se brancher sur Kubernetes"
Reste la question du provisionning des disques et autres systèmes de stockage associés aux containers. "A l'origine les logiciels pilotes nécessaires à la gestion de ces ressources était codés dans le cœur de Kubernetes. Or de plus en plus de fournisseurs d'unités de stockage souhaitaient disposer de driver, ce qui contribuait à complexifier et à alourdir le développement de Kubernetes ", explique Romain Vrignaud. "C'est dans ce but que nous avons créé l'interface CSI ou Container Storage Interface. Elle permet aux providers de venir se brancher sur Kubernetes en évitant d'inclure leur code à l'édifice."
Un autre avantage de CSI est de disposer de volumes de stockage, basés sur des clouds publics ou privés, instanciés de manière dynamique. "Même si le pod auquel elle est rattachée crashe, CSI permet de conserver une partition de disque qui pourra immédiatement être ré-instanciée", insiste Aurore Malherbes, cofondatrice et CTO de Padok, société de services française spécialisée dans Kubernetes et filiale du groupe Theodo. Et Pierre-Henri Cumenge, cofondateur et CTO de Sicara, une autre filiale du Theodo (experte en big data), d'ajouter : "CSI permet par exemple d'intégrer à Kubernetes des volumes externes persistants gérés par Hadoop." Mais sur ce point, le CTO relativise : "L'adoption de Kubernetes pour le big data n'est pas pour demain. Les projets de data lake sont encore peu nombreux. Ceux que nous accompagnons sont en général lancés sur des clouds publics via des services managés de bases de données ou de systèmes de stockage."
APIsation de l'approche data
Pour l'heure, on compte une cinquantaine de drivers CSI disponibles. Ils sont proposés à la fois par des clouds publics (Google évidemment, mais aussi Alibaba, Amazon, DigitalOcean ou Microsoft), avec pour objectif de connecter Kubernetes à leur service de stockage respectif. Mais aussi par des fournisseurs de systèmes de stockage tels Hitachi Vantara, HPE, NetApp, Nutanix ou encore Pure Storage.
CSI s'inscrit dans la logique d'APIsation de Kubernetes. Aux côté de CSI, l'orchestrateur est aussi doté d'une interface d'exécution (CRI ou Container Runtime Interface) et d'une interface réseau (CNI pour Container Network Interface). La première lui permet de supporter plusieurs formats de containers, comme Docker ou CoreOS rkt. La seconde offre aux acteurs évoluant dans l'écosystème Kubernetes la possibilité de créer des plugins facilitant la configuration réseau du framework, en termes de VxLAN ou de règles de filtrage par exemple. Parmi les plus populaires d'entre eux, on compte Calico, Flannel ou WeaveNet.