Kubeflow + Argo CD: MLOps GitOps en Kubernetes

Esta es la referencia extensa. Para un resumen de cinco minutos, consulte el blog companion.

1. Introducción: el MLOps necesita dos planos de control

El machine learning en Kubernetes falla de dos formas predecibles. Los equipos tratan el entrenamiento como un conjunto de Jobs ad hoc sin linaje, o el serving como un kubectl apply puntual sin pista de auditoría. Kubeflow y Argo CD abordan mitades opuestas de ese problema.

Kubeflow es el plano de control ML: pipelines, entrenamiento distribuido, seguimiento de experimentos, model registry y KServe. Argo CD es el plano de control de entrega: GitOps pull-based para que el estado del clúster coincida con Git — incluida la plataforma Kubeflow y cada InferenceService de producción.

Este artículo es una guía de arquitectura práctica para ingenieros de plataforma y MLOps. Asume familiaridad con Kubernetes y que ya entiende GitOps básico (vea nuestro artículo sobre entrega continua con Argo CD & Flux). Aquí nos centramos en cómo encajan los dos sistemas para cargas ML en 2026.

2. El mapa MLOps de Kubernetes 2026

Argo Workflows sigue apareciendo bajo el capó en algunos backends de pipelines, pero debe pensar en Kubeflow Pipelines IR / v2 para authoring y en Argo CD para la entrega continua de recursos Kubernetes — no confunda «Argo Workflows» con «Argo CD».

3. Propiedad clara: qué hace Kubeflow vs qué hace Argo CD

3.1 Kubeflow posee

• Authoring y ejecución de DAGs de entrenamiento / ETL / evaluación
• Ciclo de vida de jobs GPU y metadatos de experimentos
• Registro de versiones de modelo y linaje en el Model Registry
• Definir cómo un modelo podría servirse (runtime, recursos) — a menudo vía manifests generados

3.2 Argo CD posee

• Instalar y actualizar componentes Kubeflow (plataforma GitOps)
• Sincronizar definiciones de pipelines y CronWorkflows que inician entrenamiento
• Promover cambios de InferenceService entre entornos
• Rollback instantáneo y auditable vía historial Git

4. Diseño Git recomendado

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)

Mantenga separados los syncs de platform y application. Los data scientists abren PRs contra ml-apps; los ingenieros de plataforma poseen ml-platform. Use Argo CD Projects + RBAC para que un PR de pipeline defectuoso no pueda reescribir el plano de control de Kubeflow.

5. Gestionar Kubeflow con Argo CD

Las instalaciones manuales de Kubeflow son frágiles: muchos CRDs, restricciones de orden y rutas de actualización. Trate la plataforma como una Application Argo CD (o ApplicationSet) con:

• Sync waves — certificados, almacenamiento, MySQL/Postgres (o DB gestionada), credenciales MinIO/S3, luego KFP / Trainer / KServe
• Health checks — esperar CRDs y webhooks antes de sincronizar apps dependientes
• Servicios gestionados en producción — reemplazar MySQL/MinIO in-cluster por Cloud SQL/RDS y S3 cuando supere la demo todo-en-uno

Esbozo de Application (ilustrativo):

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 como recursos GitOps

Con Kubeflow Pipelines v2 / APIs nativas de Kubernetes, los pipelines compilados pueden gestionarse como recursos del clúster. El flujo queda:

1. Author el pipeline en Python (KFP SDK)
2. Compilar a YAML
3. Commit en ml-apps/pipelines/...
4. Argo CD sincroniza; los runs se disparan vía UI, API o CronWorkflow también almacenado en Git

Defina siempre límites de CPU, memoria y GPU en los pasos. Pasos de entrenamiento sin límite perturbarán clústeres multi-tenant más rápido que cualquier modelo malo.

7. Promoción de modelo: registry → Git → Argo CD

Este es el hand-off crítico:

1. El run de entrenamiento termina; las métricas de evaluación cumplen umbrales.
2. El Model Registry registra una nueva versión con URI + metadatos (accuracy, fairness, signer).
3. La automatización (o un humano) abre un PR que actualiza storageUri (y tag de imagen / runtime) en el overlay de serving.
4. Tras el merge, Argo CD despliega KServe. Prefiera canary: fije canaryTrafficPercent en 10 %, observe tasa de error y latencia, luego promueva.

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

El rollback no es un clic en un dashboard — es un git revert de ese cambio de URI. Argo CD restaura el clúster al estado deseado anterior.

8. GPUs, cuotas y FinOps

• Use Kueue para que los TrainJobs esperen capacidad GPU justa en lugar de fallar o sobresuscribir.
• Separe node pools para entrenamiento vs inferencia sensible a latencia cuando sea posible.
• Rastree el coste por run de pipeline (GPU-seconds × tarifa). GitOps no elimina FinOps — hace el gasto atribuible a un commit y una versión de modelo.
• Para MIG / time-slicing en NVIDIA, documente la estrategia de partición en el repo de plataforma para que las configs DevicePlugin gestionadas por Argo CD se mantengan consistentes.

9. Seguridad y multi-tenancy

• Los Kubeflow Profiles aíslan equipos; asígnelos a Argo CD Projects.
• Guarde credenciales cloud en Sealed Secrets / External Secrets — nunca ConfigMaps en claro en Git.
• Exija puertas de metadatos del registry (p. ej. fairness_score, sign_off_user) antes de que un bot de promoción pueda abrir un PR de prod.
• Network policies: los jobs de entrenamiento no deberían necesitar egress sin restricción; los pods de serving solo necesitan almacenamiento de modelos y clientes.

10. Observabilidad más allá de métricas de pods

Prometheus sobre utilización GPU es necesario pero no suficiente. Conecte:

• Alertas de fallo de pipeline (estado del run, no solo Deployment CrashLoop)
• SLO de serving: latencia, tasa de error, saturación
• Monitores de drift de datos/modelo que puedan abrir un ticket o re-disparar un CronWorkflow de entrenamiento

Cuando el drift se dispara, el camino de remediación debe seguir siendo GitOps: nuevo run → nuevo URI → PR → sync Argo CD — no una sobrescritura manual en el nodo.

11. Checklist de despliegue

1. Instalar Argo CD; crear proyectos ml-platform y ml-apps.
2. Instalar Kubeflow con GitOps y sync waves; verificar UI KFP y CRDs KServe.
3. Levantar object storage + Model Registry; documentar convenciones de URI.
4. Incorporar un pipeline golden path (train → evaluate → register).
5. Añadir un InferenceService bajo Argo CD con overlay staging primero.
6. Habilitar promoción canary; practicar un ejercicio git revert.
7. Añadir cuotas Kueue y dashboards GPU FinOps antes del rollout multi-equipo.

12. Anti-patrones

• Commitear archivos de pesos de 4 GB a Git LFS «por comodidad»
• Dejar que los notebooks hagan kubectl apply de InferenceServices de producción
• Una sola Application Argo CD que mezcla plataforma y todos los pipelines de equipo (blast radius)
• Sin límites de recursos en pasos de entrenamiento
• Confundir Argo Workflows (ejecución) con Argo CD (sync de estado deseado)
• Saltar staging — promover directo de un experimento en laptop al tráfico prod

13. Cuándo no usar este stack

Las pymes que ejecutan un único LLM privado en una workstation (vea nuestros AI SME Packages) no necesitan Kubeflow + Argo CD el primer día. Introduzca esta arquitectura cuando tenga varios modelos, usuarios GPU concurrentes, control de cambios regulado, o varios entornos que deban permanecer idénticos.

14. Conclusión

Kubeflow y Argo CD son complementarios. Kubeflow hace el trabajo ML ejecutable y reproducible en Kubernetes. Argo CD hace la infraestructura ML y el serving de modelos declarativos, auditables y reversibles. El patrón ganador es simple: artefactos en object storage, punteros y YAML en Git, entrenamiento en Kubeflow, entrega y rollback en Argo CD.

El blog companion es el resumen compartible; este artículo es la referencia para revisiones de diseño de plataforma.

Publicado por Workstation (workstation.co.uk).

Instantánea SEO de este artículo

• Título SEO: Kubeflow + Argo CD: MLOps GitOps en Kubernetes
• Meta description: Cómo combinar Kubeflow Pipelines, Model Registry y KServe con GitOps Argo CD para ML entrenable, auditable y seguro ante rollback en Kubernetes.
• Palabras clave principales: Kubeflow Argo CD, GitOps MLOps, KServe InferenceService, Kubeflow Pipelines GitOps, ML on Kubernetes
• Twitter / X: Kubeflow entrena. Argo CD entrega. Los modelos permanecen en object storage; Git guarda los URI. Guía completa GitOps MLOps de Workstation.
• LinkedIn: Publicamos un análisis profundo sobre emparejar Kubeflow y Argo CD: diseño Git platform vs apps, puertas de promoción, serving canary, cuotas GPU y rollback vía git revert. De ingeniería Workstation.