Kubeflow + Argo CD: MLOps GitOps no Kubernetes

Esta é a referência em formato longo. Para uma leitura rápida de cinco minutos, veja o blog companion.

1. Introdução: MLOps precisa de dois planos de controle

Machine learning no Kubernetes falha de duas formas previsíveis. As equipes tratam o treino como um conjunto de Jobs ad hoc sem linhagem, ou o serving como um kubectl apply pontual sem trilha de auditoria. Kubeflow e Argo CD resolvem metades opostas desse problema.

Kubeflow é o plano de controle ML: pipelines, treino distribuído, tracking de experimentos, model registry e KServe. Argo CD é o plano de controle de entrega: GitOps pull-based para o estado do cluster coincidir com o Git — incluindo a plataforma Kubeflow e cada InferenceService de produção.

Este artigo é um guia prático de arquitetura para engenheiros de plataforma e MLOps. Assume familiaridade com Kubernetes e que você já entende GitOps básico (veja nosso post sobre entrega contínua com Argo CD & Flux). Aqui focamos em como os dois sistemas se encaixam para cargas ML em 2026.

2. O mapa MLOps Kubernetes 2026

Argo Workflows ainda aparece por baixo do capô em alguns backends de pipeline, mas você deve pensar em Kubeflow Pipelines IR / v2 para authoring e em Argo CD para entrega contínua de recursos Kubernetes — não confunda “Argo Workflows” com “Argo CD”.

3. Propriedade clara: o que Kubeflow faz vs o que Argo CD faz

3.1 Kubeflow possui

• Authoring e execução de DAGs de treino / ETL / avaliação
• Ciclo de vida de jobs GPU e metadados de experimentos
• Registro de versões de modelo e linhagem no Model Registry
• Definir como um modelo poderia ser servido (runtime, recursos) — frequentemente via manifests gerados

3.2 Argo CD possui

• Instalar e atualizar componentes Kubeflow (plataforma GitOps)
• Sincronizar definições de pipelines e CronWorkflows que iniciam treino
• Promover mudanças de InferenceService entre ambientes
• Rollback instantâneo e auditável via histórico Git

4. Layout 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)

Mantenha syncs de platform e application separados. Data scientists abrem PRs contra ml-apps; engenheiros de plataforma possuem ml-platform. Use Argo CD Projects + RBAC para que um PR de pipeline ruim não possa reescrever o plano de controle Kubeflow.

5. Gerenciar Kubeflow com Argo CD

Instalações manuais de Kubeflow são frágeis: muitos CRDs, restrições de ordem e caminhos de upgrade. Trate a plataforma como uma Application Argo CD (ou ApplicationSet) com:

• Sync waves — certificados, storage, MySQL/Postgres (ou DB gerenciado), credenciais MinIO/S3, depois KFP / Trainer / KServe
• Health checks — aguardar CRDs e webhooks antes de sincronizar apps dependentes
• Serviços gerenciados em produção — substituir MySQL/MinIO in-cluster por Cloud SQL/RDS e S3 quando superar a demo all-in-one

Esboço 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

Com Kubeflow Pipelines v2 / APIs nativas do Kubernetes, pipelines compilados podem ser gerenciados como recursos do cluster. O fluxo fica:

1. Author o pipeline em Python (KFP SDK)
2. Compilar para YAML
3. Commit em ml-apps/pipelines/...
4. Argo CD sincroniza; runs são disparados via UI, API ou CronWorkflow também armazenado no Git

Sempre defina limites de CPU, memória e GPU nos passos. Passos de treino sem limite perturbarão clusters multi-tenant mais rápido do que qualquer modelo ruim.

7. Promoção de modelo: registry → Git → Argo CD

Este é o hand-off crítico:

1. O run de treino termina; métricas de avaliação atingem limiares.
2. O Model Registry registra uma nova versão com URI + metadados (accuracy, fairness, signer).
3. Automação (ou um humano) abre um PR que atualiza storageUri (e tag de imagem / runtime) no overlay de serving.
4. Após o merge, Argo CD faz o rollout do KServe. Prefira canary: defina canaryTrafficPercent em 10%, observe taxa de erro e latência, depois promova.

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

Rollback não é um clique no dashboard — é um git revert dessa mudança de URI. Argo CD restaura o cluster ao estado desejado anterior.

8. GPUs, quotas e FinOps

• Use Kueue para que TrainJobs aguardem capacidade GPU justa em vez de falhar ou sobrescrever.
• Separe node pools para treino vs inferência sensível à latência quando possível.
• Acompanhe o custo por run de pipeline (GPU-seconds × tarifa). GitOps não remove FinOps — torna o gasto atribuível a um commit e a uma versão de modelo.
• Para MIG / time-slicing em NVIDIA, documente a estratégia de partição no repo da plataforma para que configs DevicePlugin gerenciadas pelo Argo CD permaneçam consistentes.

9. Segurança e multi-tenancy

• Kubeflow Profiles isolam equipes; mapeie-os para Argo CD Projects.
• Armazene credenciais cloud em Sealed Secrets / External Secrets — nunca ConfigMaps em texto claro no Git.
• Exija gates de metadados do registry (p.ex. fairness_score, sign_off_user) antes que um bot de promoção possa abrir um PR de prod.
• Network policies: jobs de treino não devem precisar de egress irrestrito; pods de serving precisam apenas de storage de modelos e clientes.

10. Observabilidade além de métricas de pods

Prometheus sobre utilização de GPU é necessário, mas não suficiente. Conecte:

• Alertas de falha de pipeline (status do run, não só Deployment CrashLoop)
• SLO de serving: latência, taxa de erro, saturação
• Monitores de drift de dados/modelo que possam abrir um ticket ou re-disparar um CronWorkflow de treino

Quando o drift dispara, o caminho de remediação ainda deve ser GitOps: novo run → novo URI → PR → sync Argo CD — não uma sobrescrita manual no nó.

11. Checklist de rollout

1. Instalar Argo CD; criar projetos ml-platform e ml-apps.
2. Instalar Kubeflow com GitOps e sync waves; verificar UI KFP e CRDs KServe.
3. Subir object storage + Model Registry; documentar convenções de URI.
4. Onboardar um pipeline golden path (train → evaluate → register).
5. Adicionar um InferenceService sob Argo CD com overlay staging primeiro.
6. Habilitar promoção canary; praticar um drill de git revert.
7. Adicionar quotas Kueue e dashboards GPU FinOps antes do rollout multi-equipe.

12. Anti-padrões

• Commitar arquivos de pesos de 4 GB no Git LFS “por conveniência”
• Deixar notebooks fazerem kubectl apply de InferenceServices de produção
• Uma única Application Argo CD misturando plataforma e todos os pipelines de equipe (blast radius)
• Sem limites de recursos nos passos de treino
• Confundir Argo Workflows (execução) com Argo CD (sync de estado desejado)
• Pular staging — promover direto de um experimento no laptop para o tráfego prod

13. Quando não usar este stack

PMEs rodando um único LLM privado em uma workstation (veja nossos AI SME Packages) não precisam de Kubeflow + Argo CD no primeiro dia. Introduza esta arquitetura quando tiver vários modelos, usuários GPU concorrentes, controle de mudanças regulado, ou vários ambientes que devem permanecer idênticos.

14. Conclusão

Kubeflow e Argo CD são complementares. Kubeflow torna o trabalho ML executável e reproduzível no Kubernetes. Argo CD torna a infraestrutura ML e o serving de modelos declarativos, auditáveis e reversíveis. O padrão vencedor é simples: artefatos em object storage, ponteiros e YAML no Git, treino no Kubeflow, entrega e rollback no Argo CD.

O blog companion é o resumo compartilhável; este artigo é a referência para revisões de design de plataforma.

Publicado por Workstation (workstation.co.uk).

Instantâneo SEO deste artigo

• Título SEO: Kubeflow + Argo CD: MLOps GitOps no Kubernetes
• Meta description: Como combinar Kubeflow Pipelines, Model Registry e KServe com GitOps Argo CD para ML treinável, auditável e seguro no rollback no Kubernetes.
• Palavras-chave primárias: Kubeflow Argo CD, GitOps MLOps, KServe InferenceService, Kubeflow Pipelines GitOps, ML on Kubernetes
• Twitter / X: Kubeflow treina. Argo CD entrega. Modelos ficam em object storage; Git guarda URIs. Guia completo GitOps MLOps da Workstation.
• LinkedIn: Publicamos um deep dive sobre combinar Kubeflow e Argo CD: layout Git platform vs apps, gates de promoção, serving canary, quotas GPU e rollback via git revert. Da engenharia Workstation.