Vous avez un modèle qui performe remarquablement bien sur vos données de validation. L’équipe data science est satisfaite, les métriques sont au vert. Maintenant vient la vraie question : comment fait-on tourner ce modèle de manière fiable pour des milliers de requêtes par seconde, avec la possibilité de le mettre à jour sans interruption de service ?

C’est là que Kubernetes et GitOps entrent en jeu.

Pourquoi Kubernetes pour le serving de modèles ?

Un modèle de ML en production a des besoins très spécifiques : ressources GPU ou CPU importantes, isolation des dépendances, capacité à scaler rapidement en cas de pic de charge, et facilité de mise à jour sans downtime. Kubernetes répond à ces exigences mieux que n’importe quelle autre plateforme.

Avec Kubernetes, chaque version de votre modèle est packagée dans un container Docker. Le Deployment gère les mises à jour progressives (rolling updates), les Health Checks vérifient que le modèle répond correctement, et le HorizontalPodAutoscaler adapte le nombre de réplicas à la charge réelle.

Packager le modèle : BentoML ou MLflow Serving

Avant de parler Kubernetes, il faut exposer le modèle via une API. Deux outils dominent le marché :

BentoML permet de définir un service de serving directement depuis votre code Python :

import bentoml
from bentoml.io import NumpyNdarray

iris_clf_runner = bentoml.sklearn.get("iris_classifier:latest").to_runner()

svc = bentoml.Service("iris_classifier", runners=[iris_clf_runner])

@svc.api(input=NumpyNdarray(), output=NumpyNdarray())
def predict(input_series: np.ndarray) -> np.ndarray:
    result = iris_clf_runner.predict.run(input_series)
    return result

MLflow Models offre une approche plus standard, compatible avec de nombreux frameworks. Les deux peuvent être containerisés et déployés sur Kubernetes.

La philosophie GitOps

GitOps, popularisé par Weaveworks et implémenté par des outils comme ArgoCD ou Flux, repose sur un principe simple : Git est la source de vérité de l’état de votre infrastructure. Chaque changement en production passe par un commit dans un dépôt Git. Cela apporte trois garanties fondamentales :

  • Auditabilité : qui a déployé quoi, quand, et pourquoi
  • Réversibilité : un git revert suffit à revenir en arrière
  • Synchronisation continue : l’état réel du cluster correspond toujours à l’état déclaré dans Git

Pour les déploiements de modèles ML, cette philosophie est particulièrement précieuse. Quand un modèle se dégrade en production, vous pouvez revenir immédiatement à la version précédente avec un simple rollback Git, sans intervention manuelle sur le cluster.

Architecture type avec ArgoCD

Voici une architecture concrète avec deux dépôts Git distincts :

Dépôt 1 Application (model-app) : contient le code du service de serving, le Dockerfile, et les scripts d’entraînement.

Dépôt 2 Configuration (model-infra) : contient les manifestes Kubernetes (Deployment, Service, HPA, ConfigMap).

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: fraud-detection
  namespace: ml-production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: fraud-detection
  template:
    spec:
      containers:
      - name: model-server
        image: registry.company.com/fraud-detection:v1.4.2
        resources:
          requests:
            memory: "2Gi"
            cpu: "500m"
          limits:
            memory: "4Gi"
            cpu: "2"
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 30

ArgoCD surveille en continu le dépôt de configuration et synchronise automatiquement le cluster Kubernetes avec l’état déclaré.

Déploiements Canary pour les modèles

Déployer un nouveau modèle à 100% du trafic en une seule fois est risqué. La stratégie canary consiste à router une faible portion du trafic (5%, 10%) vers la nouvelle version, d’observer les métriques, puis d’augmenter progressivement si tout va bien.

Avec Argo Rollouts (une extension de Kubernetes), vous pouvez définir cette stratégie déclarativement :

strategy:
  canary:
    steps:
    - setWeight: 10
    - pause: {duration: 10m}
    - setWeight: 30
    - pause: {duration: 10m}
    - setWeight: 100
    analysis:
      templates:
      - templateName: model-accuracy
      startingStep: 1

Si l’analyse détecte une dégradation des métriques (précision en dessous d’un seuil, latence en hausse), le rollout est automatiquement stoppé et le trafic revient entièrement à la version stable.

Gérer les ressources GPU

Pour les modèles nécessitant des GPU, Kubernetes s’appuie sur le plugin NVIDIA Device Plugin qui expose les GPU comme des ressources allouables :

resources:
  limits:
    nvidia.com/gpu: 1

Le cluster scheduler place alors les pods sur des nœuds disposant du matériel requis. Combinez cela avec des node pools dédiés au ML (auto-scaling activé, instances GPU onéreuses) pour optimiser les coûts : les pods ne consomment des GPU que lorsqu’ils traitent des requêtes.

Conclusion

La combinaison Kubernetes + GitOps transforme le déploiement de modèles ML en un processus industriel, reproductible et auditable. Ce n’est plus une opération manuelle risquée, c’est un workflow versionné que n’importe quel membre de l’équipe peut exécuter, inspecter, et si nécessaire, annuler en quelques secondes.