Vers un renouveau du big data grâce à Kubernetes

Vers un renouveau du big data grâce à Kubernetes Adapter la containerisation logicielle aux exigences des mégadonnées implique pour l'orchestrateur open source de surmonter certains défis techniques. Le mouvement est en marche.

Rarement un projet open source aura pris une telle ampleur en si peu d'années. Initié en 2014 par Google, Kubernetes est devenu, grâce à une communauté particulièrement active, une infrastructure applicative incontournable dans la gestion de clusters de containers. Cédé par le groupe américain à la Cloud Native Computing Foundation (qui orchestre depuis ses développements), K8S pour les initiés a gagné haut la main la guerre des orchestrateurs face à aux solutions de Docker (Swarm) et de Mesosphere (Marathon).

L'un et l'autre ont plié face au raz-de-marée. En septembre 2017, Mesosphere annonçais le support de Kubernetes par son système d'exploitation orienté data center (DC/OS) aux côtés de celui de Marathon. Un mois plus tard, Docker prenait le même chemin en intégrant l'orchestrateur à sa propre plateforme de gestion de containers (Docker Enterprise Edition). Les géants du cloud, ont aussi entériné cette victoire par KO. Amazon, Microsoft, Alibaba, Google ou encore DigitalOcean ont tous lancé une offre de Kubernetes managé (ou Kubernetes as a service).

Dès lors, le projet open source qui demeure en grande partie porté par les équipes de Google s'attaque à un nouveau défi. Mettre sa technologie éprouvée de management de clusters de containers au service de l'exécution des pipelines de mégadonnées. Pour Janos Matyas, CTO  et cofondateur de Banzai Cloud, "l'avenir du big data passe par Kubernetes". Dans un récent billet de blog, l'expert estime que le mouvement est initié, pointant du doigt le support déjà effectif de Kubernetes par de nombreux logiciels de big data.

Des communautés mobilisées

Plusieurs infrastructures open source, que ce soit sur le front du big data avec Spark, Zeppelin et Kafka par exemple, ou de l'IA avec TensorFlow, intègrent d'ores et déjà des briques de base de Kubernetes. Comme l'ordonnanceur de tâches (ou scheduler), le service discovery ou encore l'algorithme de consensus Raft. Selon Janos Matyas, Kubernetes améliore la résilience des architectures. Alors qu'au sein des environnements big data classiques les services interopèrent via des adresses IP prédéfinies, K8s repense l'exposition de ces services (équilibrage de charge, réplication, prise en charge des DNS...).

"Il reste encore beaucoup de travail à faire pour parvenir à cette vision"

Responsable produits chez BlueData (un spécialiste américain du big data et de l'IA), Anant Chintamaneni est plus circonspect quant à l'évolution de l'orchestrateur. "En dépit de ces évolutions, il reste encore beaucoup de travail à réaliser pour parvenir à cette vision" selon lui. En décembre dernier, il estimait de 12 à 24 mois le temps nécessaire pour aboutir à une version de l'orchestrateur prête à l'emploi pour supporter des plateformes big data en production.

Anant Chintamaneni reconnait l'évolution du framework Spark dans la prise en charge des architectures Kubernetes de type stateless (ou sans état), mais regrette que le virage ne soit pas pris par d'autres.  L'expert rappelle que la majorité des applications big data multiservices requièrent à l'inverse une forme de stockage racine persistant (stateful) ou HDFS (Hadoop Distributed File System) pour stocker et analyser de grands volumes de données. "Or, Kubernetes ne supporte ni l'un ni l'autre pour le moment. Avec K8s, modifier les ressources de stockage utilisées sur le nœud d'un cluster implique que ce dernier soit temporairement supprimé. Ce qui n'est pas idéal pour les applications big data", analyse le spécialiste, tout en admettant que Kubernetes commence à évoluer dans ce sens, notamment via de nouvelles fonctionnalités pour piloter les volumes de stockage stateful.

Spark, Flink et MapR en première ligne

Mais depuis le début de l'année, le mouvement vers le stateful semble s'accélérer. Dans sa version 2.3 publiée en mars dernier, Apache Spark permet d'exécuter des charges de travail sur un cluster Kubernetes de version 1.7 ou supérieure. Annoncée le 25 mai dernier, Apache Flink 1.5 simplifie de son côté ses processus de déploiement sur Kubernetes. Une intégration qui sera encore renforcée dans la prochaine version, en vue d'automatiser à terme la containerisation de traitements big data sur des clusters Flink.

Les communautés open source ne sont pas les seules à s'activer. À l'occasion de la Strata Data Conference qui s'est tenue début mars, le distributeur de solutions Hadoop américain MapR a annoncé l'intégration de Kubernetes à son offre Data Fabric. Objectif affiché : permettre le déploiement d'applications containerisées en mode stateful. Data Fabric for Kubernetes vise, selon l'éditeur, à éliminer les limites inhérentes à l'utilisation des containers en permettant d'accéder "de façon simple et complète" aux données stockées sur un ou plusieurs clouds, ou encore au sein des systèmes d'informations hébergés en interne. Grâce à Data Fabric for Kubernetes, "les applications persistantes peuvent désormais être facilement déployées dans des containers en production, des pipelines d'apprentissage automatique et des configurations multi-tenants", argue le fournisseur californien. 

Quelques retours d'expérience commencent par ailleurs à émerger. A la même Strata Data Conference, l'e-commerçant chinois JD.com a expliqué comment il fait tourner Spark mais aussi les frameworks de machine learning Caffe et TensorFlow sur Kubernetes (voir la présentation). L'infrastructure déployée, qui comprend pour l'heure 300 nœuds, devrait être étendue à plus de mille à terme.