Kubeflow + Argo CD : MLOps GitOps sur Kubernetes

Ceci est la référence détaillée. Pour un survol en cinq minutes, consultez le blog companion.

1. Introduction : le MLOps a besoin de deux plans de contrôle

Le machine learning sur Kubernetes échoue de deux façons prévisibles. Les équipes traitent soit l’entraînement comme un ensemble de Jobs ad hoc sans lignage, soit le serving comme un kubectl apply ponctuel sans piste d’audit. Kubeflow et Argo CD traitent les deux moitiés opposées de ce problème.

Kubeflow est le plan de contrôle ML : pipelines, entraînement distribué, suivi d’expériences, model registry et KServe. Argo CD est le plan de contrôle de livraison : GitOps pull-based pour que l’état du cluster corresponde à Git — y compris la plateforme Kubeflow elle-même et chaque InferenceService de production.

Cet article est un guide d’architecture pratique pour les ingénieurs plateforme et MLOps. Il suppose une familiarité avec Kubernetes et que vous comprenez déjà les bases du GitOps (voir notre article Argo CD & Flux sur la livraison continue). Nous nous concentrons ici sur la façon dont les deux systèmes s’articulent pour les charges ML en 2026.

2. La carte MLOps Kubernetes 2026

Argo Workflows apparaît encore sous le capot pour certains backends de pipelines, mais vous devez raisonner en Kubeflow Pipelines IR / v2 pour l’authoring et en Argo CD pour la livraison continue des ressources Kubernetes — ne confondez pas « Argo Workflows » et « Argo CD ».

3. Propriété claire : ce que fait Kubeflow vs ce que fait Argo CD

3.1 Kubeflow possède

• Authoring et exécution des DAG d’entraînement / ETL / évaluation
• Cycle de vie des jobs GPU et métadonnées d’expériences
• Enregistrement des versions de modèles et du lignage dans le Model Registry
• Définition de la façon dont un modèle pourrait être servi (runtime, ressources) — souvent via des manifests générés

3.2 Argo CD possède

• Installation et mise à niveau des composants Kubeflow (plateforme GitOps)
• Sync des définitions de pipelines et des CronWorkflows qui démarrent l’entraînement
• Promotion des changements InferenceService entre environnements
• Rollback instantané et auditable via l’historique Git

4. Disposition Git recommandée

ml-platform/                 # Argo CD App: install Kubeflow once
  overlays/
    staging/
    production/
ml-apps/                     # Argo CD App-of-Apps or projects
  pipelines/
    fraud-detector/
  serving/
    fraud-detector/
      base/inferenceservice.yaml
      overlays/
        staging/
        production/
  components/                # reusable KFP components (OCI or YAML)

Gardez les syncs platform et application séparés. Les data scientists ouvrent des PR contre ml-apps ; les ingénieurs plateforme possèdent ml-platform. Utilisez Argo CD Projects + RBAC pour qu’une mauvaise PR de pipeline ne puisse pas réécrire le plan de contrôle Kubeflow.

5. Gérer Kubeflow avec Argo CD

Les installations manuelles de Kubeflow sont fragiles : nombreux CRDs, contraintes d’ordre et chemins de mise à niveau. Traitez la plateforme comme une Application Argo CD (ou ApplicationSet) avec :

• Sync waves — certificats, stockage, MySQL/Postgres (ou DB managée), credentials MinIO/S3, puis KFP / Trainer / KServe
• Health checks — attendre les CRDs et webhooks avant de synchroniser les apps dépendantes
• Services managés en production — remplacer MySQL/MinIO in-cluster par Cloud SQL/RDS et S3 lorsque vous dépassez la démo tout-en-un

Esquisse d’Application (illustrative) :

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: kubeflow-platform
  namespace: argocd
  annotations:
    argocd.argoproj.io/sync-wave: "0"
spec:
  project: ml-platform
  source:
    repoURL: https://git.example.com/org/ml-platform.git
    targetRevision: main
    path: overlays/production
  destination:
    server: https://kubernetes.default.svc
    namespace: kubeflow
  syncPolicy:
    automated:
      prune: false
      selfHeal: true
    syncOptions:
      - CreateNamespace=true
      - ServerSideApply=true

6. Pipelines comme ressources GitOps

Avec Kubeflow Pipelines v2 / APIs natives Kubernetes, les pipelines compilés peuvent être gérés comme des ressources cluster. Le workflow devient :

1. Authorer le pipeline en Python (KFP SDK)
2. Compiler en YAML
3. Committer dans ml-apps/pipelines/...
4. Argo CD synchronise ; les runs sont déclenchés via UI, API, ou CronWorkflow aussi stocké dans Git

Définissez toujours des limites CPU, mémoire et GPU sur les étapes. Des étapes d’entraînement sans borne perturberont les clusters multi-tenant plus vite que n’importe quel mauvais modèle.

7. Promotion de modèle : registry → Git → Argo CD

Voici le hand-off critique :

1. Le run d’entraînement se termine ; les métriques d’évaluation atteignent les seuils.
2. Le Model Registry enregistre une nouvelle version avec URI + métadonnées (accuracy, fairness, signer).
3. L’automatisation (ou un humain) ouvre une PR qui met à jour storageUri (et le tag d’image / runtime) dans l’overlay de serving.
4. Après merge, Argo CD déploie KServe. Préférez le canary : réglez canaryTrafficPercent à 10 %, surveillez le taux d’erreur et la latence, puis promotez.

apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
  name: fraud-detector
spec:
  predictor:
    model:
      modelFormat:
        name: sklearn
      storageUri: s3://models/fraud/v1.4.2/
      resources:
        requests:
          cpu: "1"
          memory: 2Gi
        limits:
          cpu: "2"
          memory: 4Gi

Le rollback n’est pas un clic dans un dashboard — c’est un git revert de ce changement d’URI. Argo CD rétablit le cluster à l’état désiré précédent.

8. GPUs, quotas et FinOps

• Utilisez Kueue pour que les TrainJobs attendent une capacité GPU équitable au lieu d’échouer ou de sursouscrire.
• Séparez les node pools pour l’entraînement vs l’inférence sensible à la latence lorsque c’est possible.
• Suivez le coût par run de pipeline (GPU-seconds × tarif). Le GitOps ne supprime pas le FinOps — il rend la dépense attribuable à un commit et à une version de modèle.
• Pour MIG / time-slicing sur NVIDIA, documentez la stratégie de partition dans le dépôt plateforme afin que les configs DevicePlugin gérées par Argo CD restent cohérentes.

9. Sécurité et multi-tenancy

• Les Kubeflow Profiles isolent les équipes ; mappez-les aux Argo CD Projects.
• Stockez les credentials cloud dans Sealed Secrets / External Secrets — jamais de ConfigMaps en clair dans Git.
• Exigez des gates de métadonnées registry (p. ex. fairness_score, sign_off_user) avant qu’un bot de promotion puisse ouvrir une PR prod.
• Network policies : les jobs d’entraînement ne devraient pas avoir besoin d’egress non restreint ; les pods de serving n’ont besoin que du stockage de modèles et des clients.

10. Observabilité au-delà des métriques de pods

Prometheus sur l’utilisation GPU est nécessaire mais pas suffisant. Branchez :

• Alertes d’échec de pipeline (statut de run, pas seulement Deployment CrashLoop)
• SLO de serving : latence, taux d’erreur, saturation
• Moniteurs de drift données/modèle qui peuvent ouvrir un ticket ou relancer un CronWorkflow d’entraînement

Quand le drift se déclenche, le chemin de remédiation doit rester GitOps : nouveau run → nouvel URI → PR → sync Argo CD — pas un écrasement manuel sur le nœud.

11. Checklist de déploiement

1. Installer Argo CD ; créer les projets ml-platform et ml-apps.
2. Installer Kubeflow en GitOps avec sync waves ; vérifier l’UI KFP et les CRDs KServe.
3. Mettre en place le object storage + Model Registry ; documenter les conventions d’URI.
4. Onboarder un pipeline golden path (train → evaluate → register).
5. Ajouter un InferenceService sous Argo CD avec d’abord l’overlay staging.
6. Activer la promotion canary ; pratiquer un exercice git revert.
7. Ajouter les quotas Kueue et les dashboards GPU FinOps avant le rollout multi-équipes.

12. Anti-patterns

• Committer des fichiers de poids de 4 Go dans Git LFS « pour la commodité »
• Laisser les notebooks faire kubectl apply sur les InferenceServices de production
• Une seule Application Argo CD qui mélange plateforme et tous les pipelines d’équipe (blast radius)
• Aucune limite de ressources sur les étapes d’entraînement
• Confondre Argo Workflows (exécution) avec Argo CD (sync d’état désiré)
• Sauter le staging — promouvoir directement d’une expérience laptop vers le trafic prod

13. Quand ne pas utiliser cette stack

Les PME qui exécutent un seul LLM privé sur une workstation (voir nos AI SME Packages) n’ont pas besoin de Kubeflow + Argo CD dès le premier jour. Introduisez cette architecture lorsque vous avez plusieurs modèles, des utilisateurs GPU concurrents, un contrôle de changement réglementé, ou plusieurs environnements qui doivent rester identiques.

14. Conclusion

Kubeflow et Argo CD sont complémentaires. Kubeflow rend le travail ML exécutable et reproductible sur Kubernetes. Argo CD rend l’infrastructure ML et le serving de modèles déclaratifs, auditables et réversibles. Le pattern gagnant est simple : artefacts en object storage, pointeurs et YAML dans Git, entraînement dans Kubeflow, livraison et rollback dans Argo CD.

Le blog companion est le résumé partageable ; cet article est la référence pour les revues de conception plateforme.

Publié par Workstation (workstation.co.uk).

Instantané SEO pour cet article

• Titre SEO : Kubeflow + Argo CD : MLOps GitOps sur Kubernetes
• Meta description : Comment combiner Kubeflow Pipelines, Model Registry et KServe avec le GitOps Argo CD pour un ML entraînable, auditable et sûr au rollback sur Kubernetes.
• Mots-clés principaux : Kubeflow Argo CD, GitOps MLOps, KServe InferenceService, Kubeflow Pipelines GitOps, ML on Kubernetes
• Twitter / X : Kubeflow entraîne. Argo CD livre. Les modèles restent en object storage ; Git détient les URI. Guide GitOps MLOps complet de Workstation.
• LinkedIn : Nous avons publié une analyse approfondie sur l’association Kubeflow et Argo CD : disposition Git platform vs apps, gates de promotion, serving canary, quotas GPU et rollback via git revert. De l’ingénierie Workstation.