Pular para o conteúdo
Iniciar um projeto

Artigo

Kubeflow + Argo CD: MLOps GitOps no Kubernetes

Mapa de arquitetura para Kubeflow Pipelines, Trainer, KServe e Kueue com GitOps Argo CD: layout Git, sync waves, gates de promoção, serving canary, FinOps GPU e checklist de rollout

  • 7 min de leitura
Nesta página

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

Kubeflow e Argo CD GitOps MLOps no Kubernetes

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

Estágio do ciclo de vida Ferramenta Papel
Orquestração de pipelinesKubeflow Pipelines 2.xDAG de passos containerizados; runs rastreados
Treino distribuídoKubeflow Trainer (TrainJob)PyTorch / JAX / XGBoost / DeepSpeed jobs
Fila de GPUKueue (+ optional Volcano)Fair share, gang scheduling, quotas
Serving de modelosKServeInferenceService autoscaled; splits canary
AutoscalingKEDA + HPAScale event-driven, incluindo scale-to-zero
Entrega & rollbackArgo CDGit como fonte da verdade dos manifests
ObservabilidadePrometheus / Grafana / drift toolsSinais de infra + qualidade do modelo

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
Regra rígida. Binários grandes (datasets, checkpoints, pesos ONNX/SafeTensors) nunca vão para o Git. Armazene-os em S3/GCS/MinIO/PVC. O Git guarda o ponteiro (storageUri, digest, tags) e o YAML Kubernetes que o Argo CD aplica.

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 TenthMatrix (tenthmatrix.com).

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 TenthMatrix.
  • 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 TenthMatrix.

Mais artigos técnicos