Kubernetes et Machine Learning

Tu as probablement déjà entendu parler de Kubernetes : c'est un outil extrêmement populaire dans le Cloud et qui est devenu, en quelques années, la référence en terme de déploiement d'applications dans le Cloud. Mais pourquoi (et surtout comment) Kubernetes est devenu la solution incontournable ? Et surtout, pour un Data Scientist, quel est le rapport avec Kubernetes et le Machine Learning ?

C'est quoi Kubernetes ?

Kubernetes est un projet qui a été à l'origine développé chez Google. Initialement, cela fait plus de 15 ans que Google utilise en interne son propre orchestrateur de conteneurs, qui à l'époque s'appelait Borg. Les besoins de Google en terme de gestion de conteneurs était clair : délivrer quotidiennement des centaines de milliers de conteneurs au sein de leur infrastructure globale. Borg, écrit en Go, était donc leur propre solution.

Au final des années, les besoins d'orchestration de conteneurs se sont ressenties au sein d'autres entreprises. Bien qu'il y avait Docker Swarm, l'orchestrateur de conteneurs développé par les créateurs de Docker, ce dernier ne remplissait pas globalement sa mission. Il fallut attendre 2014 pour que Google développe son propre orchestrateur en se basant sur sa forte expérience de gestion des conteneurs acquise avec Borg. Rendu open-source et légué à la CNCF, Kubernetes est aujourd'hui la référence incontournable et détrône les autres solutions telles que AWS ECS ou Docker Swarm.

À lire aussi : découvrez notre formation MLOps

Pour bien comprendre la très forte popularité de Kubernetes, il nous faut bien comprendre son fonctionnement et son écosystème.

L'écosystème Kubernetes

Tout d'abord, l'écosystème est un point central lorsque l'on parle d'un projet open-source. Outre ses nombreuses mises à jours et améliorations, le système de configuration de Kubernetes est très flexible et permet à tout moment de mettre à jour des applications en continu sans perturber leur fonctionnement. Ensuite, Kubernetes est présent dans la plupart des fournisseurs Cloud, aussi bien chez Google que AWS, Azure ou encore Digital Ocean. Enfin, de nombreuses applications de références et des templates sont disponibles pour déployer très rapidement des solutions puissantes.

Cluster Kubernetes

Avant toute chose, il faut bien évidemment présente le cluster Kubernetes dans son ensemble. Il s'agit de l'environnement constitué de serveurs physiques sur lesquels se base Kubernetes. Par l'intermédiaire de commandes systèmes, nous pouvons agir sur les différents objets du cluster par des opérations de lecture (get), de création (create), de mise à jour (patch) ou de suppression (delete). Ces 4 opérations, qui rappellent fortement les opérations CRUD, sont essentielles sous K8s (pour Kubernetes). Et c'est justement kubectl qui va nous permettre d'interagir avec l'ensemble du cluster en communiquant avec l'API de K8s appelée API Objects.

Par exemple, kubectl get signifie que l'on souhaite voir/lister des informations sur une ou plusieurs ressources, alors que kubectl patch permettra de mettre à jour lesdites ressources.

Objets K8s

Une des difficultés de K8s est qu'il y a beaucoup d'objets qui peuvent être difficiles à appréhender. Tout d'abord, commençons par les trois objets élémentaires.

Un Node (noeud) est un serveur/une machine virtuelle du cluster K8s qui exécute des conteneurs. Très souvent, ce n'est pas à nous de gérer les serveurs dans les Clouds publics. En revanche, nous devons plusieurs paramètres, dont la taille du cluster (nombres de noeuds), les ressources allouées à chaque noeud et les interfaces réseaux.

Un Pod est un objet central sous K8s. Il s'agit d'une isolation logique d'un ou de plusieurs conteneurs au sein d'un seul noeud. Un pod peut contenir un ou plusieurs conteneurs. Par exemple, supposons qu'une entreprise propose un environnement isolé contenant une application et une base de données pour chaque client, alors un pod serait attribué à chaque client et chaque pod contiendrait deux conteneurs : l'application et la base de données.

Ce sont notamment les pods qui vont être crées lorsqu'il y aura des montées en charge ou lorsque de nouvelles applications seront développées et déployées avec K8s.

Un Volume est un système de gestion de fichier qui peut être partagé entre les pods. C'est notamment utile lorsque des conteneurs, exécutés sur des pods différents (et potentiellement des noeuds différents), souhaitent partager des données sous forme de fichiers. Attention tout de même, la notion de volume sous K8s n'est pas persistante : le volume et les données seront détruits si le pod associé est supprimé. Pour cela, on utilise plutôt des PersistentVolume, bien qu'il ne soit tout de même pas conseillé d'y stocker des données de types relationnelles ou sensibles.

Pour récapituler :

un noeud est un serveur/VM du cluster.
un pod est un groupe d'un ou plusieurs conteneurs dans les noeuds.
un volume est un système de fichiers rattaché à un ou plusieurs pods.

Mais alors, à quoi sert Kubernetes en Machine Learning ?

Kubernetes pour entraîner des modèles

En général, entraîner des modèles de Machine Learning nécessite de la puissance de calcul. Qu'il s'agisse d'un algorithme d'Ensemble Learning comme XGBoost ou d'un réseau de neurones TensorFlow, l'entraînement prend du temps pour plusieurs raisons.

Les hyper-paramètres d'un modèle de Machine Learning sont optimisés par des méthodes de recherche par grille ou d'optimisation bayésienne.
Pour obtenir des scores cohérents et réalistes, on utilise des méthodes de validation croisée qui nécessitent d'entraîner de nombreuses fois un même modèle sur des ré-échantillonnage d'un jeu de données.
Pour terminer, il est souvent obligatoire de devoir auditer le comportement du modèle avec des résultats attendus à l'aide de méthodes de validation de modèles et d'interprétabilité.

Autrement dit, avec toutes ces étapes, entraîner un modèle de Machine Learning type XGBoost pourrait prendre plusieurs heures sur son ordinateur. Or, avec Kubernetes, nous avons à la fois la possibilité d'obtenir des serveurs beaucoup plus puissants, mais aussi la capacité à paralléliser cette étape en profitant de tous les noeuds d'un cluster.

JupyterHub est un projet développé par l'équipe Jupyter, qui permet de créer des serveurs Jupyter Notebook à la demande, chaque serveur ayant ses propres ressources (nombre de processeurs, mémoire, carte graphique) et son environnement. Il est donc possible, par exemple, d'avoir accès à de la puissance de calcul avec un environnement Spark déjà installé, ce qui permet par exemple, pour un Data Scientist, de manipuler des données volumineuses directement depuis le cluster.

Kubernetes est particulièrement efficace ici, car il va proposer de la puissance de calcul à des utilisateurs, des environnements spécifiques et une capacité à monter en charge : si plusieurs Data Scientists ont besoin de serveurs Jupyter avec beaucoup de ressources, Kubernetes sera capable d'ajouter de nouveaux serveurs pour répondre à la demande.

Kubernetes pour exposer des modèles

Une fois le modèle entraîné, se pose la question de son exposition, ou plutôt des questions.

Comment proposer mon modèle de Machine Learning sous forme de service ?
Comment garantir la haute disponibilité de mon service en cas de panne partielle ?
Comment être scalable en s'adaptant automatiquement à la charge ?

En temps normal, ces problèmes sont difficiles à solutionner, car il nécessite tout une équipe qui dispose à la fois des compétences techniques et du temps pour pouvoir mettre en place des solutions et surveiller les systèmes.

Kubernetes est dès le départ conçu pour s'abstraire de toutes ces tâches techniques, nécessaires mais à faible valeur ajoutée, pour se concentrer sur la partie applicative, qui représente une forte valeur ajoutée pour l'entreprise. Ainsi,

Kubernetes utilise des Services qui permettent d'exposer des applications (API, agents, etc) accessible à l'intérieur du cluster ou en dehors (avec l'aide d'un équilibreur de charge par exemple).
Kubernetes utilise des Deployments et des ReplicaSets pour définir, sous forme de configuration, un état désiré du service avec un nombre de réplica déterminé, garantissant ainsi la haute disponibilité de l'application, voir même sa montée en charge.

Un modèle de Machine Learning peut être encapsulé sous forme d'une API (avec Flask ou FastAPI par exemple), ce qui permet de le considérer comme une application à part entière. Ainsi, il est possible d'utiliser des Services et des Deployments sur une API qui exécute un modèle de Machine Learning, permettant ainsi de répondre aux questions citées plus haut.

Pour un Data Scientist, le déploiement est beaucoup plus rapide, car il doit uniquement construire l'API et la configuration de celle-ci sans avoir besoin de gérer l'infrastructure sous-jacente qui l'exécute.

À lire aussi : découvrez notre formation MLOps

En ayant la capacité d'une part d'entraîner des modèles, et d'autre part de les exposer, il n'y a qu'un pas pour intégrer et automatiser ces deux parties sous forme de pipeline.

Kubernetes pour l'approche MLOps

Ce que nous avons abordé jusqu'ici s'intègre en réalité dans la mouvance MLOps, qui cherche à appliquer les bonnes pratiques du DevOps au Machine Learning. Autrement dit, on cherche à garantir une efficacité opérationnelle maximale de nos pipelines ML tout en automatisant les processus d'entraînement et d'exposition.

Récemment, une nouvelle plateforme a fait son apparition : Kubeflow. Le grande force de cette plateforme, c'est de permettre au Data Scientists et Machine Learning Engineers de créer des projets MLOps basés sur Kubernetes.

Kubeflow s'exécute et opère sur un cluster Kubernetes. Il vient avec de nombreux composants que l'on peut choisir d'installer ou non, et donc chacun a un rôle précis.

Le plus populaire et le plus utilisé est Kubeflow Pipelines, qui permet de construire, exécuter et administrer des pipelines ML automatisés. Dans les pipelines, chaque étape exécute un script Python dans un pod particulier : cela nous offre la flexibilité de paramétrer les ressources (CPU, mémoire, GPU) à chaque étape du pipeline. Par exemple, supposons que l'entraînement d'un modèle nécessite un GPU, alors il sera possible d'allouer un GPU à l'étape d'entraînement, sans en avoir besoin lors des étapes précédentes pour la transformation des données par exemple.
Le composant Notebook Servers permet de créer des serveurs Jupyter à la demande pour chaque utilisateur, avec des ressources spécifiques et des dépendances déjà installées. Cela permet, par exemple, de provisionner un serveur Jupyter avec Spark déjà installé pour un utilisateur, et un autre serveur Jupyter avec TensorFlow et un GPU pour un autre.
Le composant KFServing est utilisé pour exposer des modèles de Machine Learning, qu'ils soient construits sur une API de Scikit-Learn, TensorFlow, PyTorch ou encore XGBoost. La principale force de ce composant est qu'il gère lui-même toutes les tâches techniques comme la montée en charge, la haute disponibilité ou la propagation des mises à jour.
Le composant Katib, utilisé pour optimiser les hyper-paramètres des modèles de Machine Learning en profitant de la puissance de calcul et du caractère distribué de Kubernetes.

An architectural overview of Kubeflow on Kubernetes

Conclusion

Comme nous venons de la voir, Kubernetes est un allié de poids pour les Data Scientists et les Machine Learning pour élaborer des pipelines ML vers un niveau de production. De plus en plus d'entreprises disposent de clusters Kubernetes qu'elles utilisent déjà en tant que plateforme de conteneurs pour exposer des services : il est donc très intéressant, pour les équipes Data, de se greffer à ces clusters existants pour décharger la partie infrastructure et se concentrer sur les pipelines ML.

De nouveaux outils voient également le jour, car la maturité autour du MLOps et des plateformes comme Kubernetes commencent à évoluer, permettant ainsi d'imbriquer ensemble des compétences diversifiées.