Kubeflow : définition, composants et exemple de pipeline

Kubeflow part d'une idée simple : si Kubernetes est devenu le standard pour exécuter des applications en conteneurs, il peut aussi devenir le socle commun des traitements de machine learning. Préparation des données, entraînement, évaluation et serving deviennent des charges de travail Kubernetes comme les autres, planifiées sur un cluster partagé.

Le projet a été annoncé par Google en décembre 2017. À l'origine, il visait surtout à simplifier l'exécution d'entraînements TensorFlow sur Kubernetes, avant de s'ouvrir à tous les frameworks et de s'étendre à l'ensemble du cycle de vie des modèles. Il a rejoint la Cloud Native Computing Foundation comme projet en incubation en 2023, puis a atteint le statut de projet gradué en 2026.

Kubeflow n'est pas un outil unique mais un ensemble de composants, utilisables ensemble ou séparément. Il s'adresse aux équipes plateforme et MLOps qui veulent offrir un environnement de machine learning commun sur leur propre infrastructure. Pour une équipe réduite, un outil plus léger comme MLflow, centré sur le suivi des expériences, est souvent un meilleur point de départ.

À retenir : Kubeflow ne remplace pas Kubernetes, il le spécialise. Chaque notebook, étape de pipeline, essai d'hyperparamètres ou modèle servi tourne dans des pods du cluster.

Le périmètre de Kubeflow a évolué au fil des années. Voici les briques que l'on rencontre le plus souvent.

• Kubeflow Pipelines (KFP) : le moteur de pipelines. Un pipeline est un graphe d'étapes, chacune exécutée dans son propre conteneur, avec suivi des artefacts, des métriques et mise en cache des étapes inchangées. C'est le composant le plus utilisé, souvent installé seul.
• Kubeflow Notebooks : des environnements de développement (Jupyter, VS Code, RStudio) lancés dans des pods, avec les ressources du cluster.
• Katib : l'optimisation automatique des hyperparamètres et la recherche d'architecture, avec plusieurs stratégies dont l'optimisation bayésienne.
• Kubeflow Trainer : l'entraînement distribué de modèles PyTorch, TensorFlow, XGBoost ou JAX sur plusieurs nœuds et GPU, y compris pour le fine-tuning de LLM. Il succède au Training Operator.
• KServe : le serving de modèles. Né dans Kubeflow sous le nom de KFServing, il est désormais un projet CNCF indépendant, toujours intégré à la plateforme. Notre article sur KServe détaille son fonctionnement.
• Model Registry : un registre des modèles et de leurs versions, composant plus récent que celui de MLflow.
• Tableau de bord central et profils : l'interface web commune et la gestion multi-utilisateurs, chaque utilisateur ou équipe disposant de son espace de noms Kubernetes.

Le pipeline suivant prépare un jeu de données, entraîne un modèle puis enregistre sa métrique de précision. Chaque fonction décorée par @dsl.component s'exécute dans son propre conteneur, avec les paquets indiqués. Il utilise la version 2 du SDK (paquet kfp).

import kfp
from kfp import compiler, dsl


@dsl.component(base_image="python:3.11", packages_to_install=["pandas", "scikit-learn"])
def prepare_data(dataset: dsl.Output[dsl.Dataset]):
    from sklearn.datasets import load_breast_cancer

    df = load_breast_cancer(as_frame=True).frame
    df.to_csv(dataset.path, index=False)


@dsl.component(base_image="python:3.11", packages_to_install=["pandas", "scikit-learn", "joblib"])
def train(
    dataset: dsl.Input[dsl.Dataset],
    n_estimators: int,
    model: dsl.Output[dsl.Model],
    metrics: dsl.Output[dsl.Metrics],
):
    import joblib
    import pandas as pd
    from sklearn.ensemble import RandomForestClassifier
    from sklearn.model_selection import train_test_split

    df = pd.read_csv(dataset.path)
    X, y = df.drop(columns="target"), df["target"]
    X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2, random_state=42)

    clf = RandomForestClassifier(n_estimators=n_estimators, random_state=42).fit(X_train, y_train)
    metrics.log_metric("accuracy", float(clf.score(X_test, y_test)))
    joblib.dump(clf, model.path)


@dsl.pipeline(name="detection-tumeurs")
def training_pipeline(n_estimators: int = 200):
    data_task = prepare_data()
    train_task = train(dataset=data_task.outputs["dataset"], n_estimators=n_estimators)
    train_task.set_cpu_limit("2").set_memory_limit("4G")


# Compilation en YAML, puis soumission au serveur Kubeflow Pipelines
compiler.Compiler().compile(training_pipeline, package_path="training_pipeline.yaml")

client = kfp.Client(host="http://localhost:8080")
client.create_run_from_pipeline_package(
    "training_pipeline.yaml",
    arguments={"n_estimators": 300},
    experiment_name="detection-tumeurs",
)

Plusieurs mécanismes apparaissent dans ce court exemple. Les entrées et sorties typées (Dataset, Model, Metrics) indiquent à Kubeflow quels artefacts transmettre d'une étape à l'autre : il les stocke dans un stockage objet et les relie dans son interface. Les dépendances entre étapes se déduisent de ces échanges, sans avoir à les déclarer. Les limites de ressources se fixent étape par étape, ce qui permet d'attribuer un GPU uniquement à l'entraînement. Enfin, le fichier YAML compilé est portable : il peut être versionné, soumis à un autre cluster ou exécuté par un service managé compatible.

Pour accéder au serveur en local, on expose son interface depuis le cluster :

kubectl port-forward -n kubeflow svc/ml-pipeline-ui 8080:80

En pratique, l'étape d'entraînement peut aussi enregistrer ses paramètres et son modèle dans un serveur MLflow : Kubeflow exécute, MLflow garde la mémoire des expériences.

La principale objection à Kubeflow n'est pas fonctionnelle, elle est opérationnelle. La plateforme complète réunit une dizaine de composants, chacun avec ses contrôleurs, ses ressources personnalisées et ses mises à jour, auxquels s'ajoutent un service mesh (Istio), un système d'authentification et un stockage d'artefacts. Aligner les versions de l'ensemble avec celle du cluster Kubernetes demande un effort continu.

Plusieurs stratégies permettent de limiter cette charge :

• N'installer que le nécessaire : Kubeflow Pipelines seul, ou KServe seul, couvre souvent le besoin principal sans la plateforme complète.
• S'appuyer sur une distribution : des éditeurs et fournisseurs cloud proposent des versions packagées, testées et maintenues.
• Déléguer l'exécution : un service managé comme Vertex AI Pipelines exécute des pipelines écrits avec le SDK kfp sans cluster à administrer.
• Gérer la plateforme comme du code : versionner les manifestes et les déployer selon une approche GitOps rend les mises à jour reproductibles.

Notre article Kubernetes et Machine Learning revient sur les raisons qui font de Kubernetes le socle de ces plateformes, et sur les compétences qu'il exige.

La fiche MLflow compare les deux outils critère par critère. Le tableau ci-dessous adopte un autre angle : dans une plateforme qui utilise les deux, qui fait quoi à chaque étape du cycle de vie ?

Cette répartition est fréquente parce qu'elle exploite le point fort de chacun : la puissance d'exécution de Kubeflow sur Kubernetes, et la simplicité de suivi et de versionnement de MLflow. Une équipe peut aussi démarrer avec MLflow seul, puis ajouter Kubeflow lorsque le volume de traitements justifie une plateforme sur cluster.