Kubeflow + Argo CD：Kubernetes 上的 GitOps MLOps

本文为长篇参考。五分钟速览请见配套博客。

1. 引言：MLOps 需要两个控制平面

Kubernetes 上的机器学习常以两种可预测方式失败。团队要么把训练当成一堆没有 lineage 的临时 Jobs，要么把 serving 当成一次性 kubectl apply、毫无审计轨迹。Kubeflow 与 Argo CD 分别解决该问题的两端。

Kubeflow 是 ML 控制平面：pipelines、分布式训练、实验跟踪、model registry 与 KServe。Argo CD 是交付控制平面：基于拉取的 GitOps，使集群状态与 Git 一致——包括 Kubeflow 平台本身以及每个生产 InferenceService。

本文面向平台与 MLOps 工程师，是一份实用架构指南。假定您熟悉 Kubernetes，并已了解基础 GitOps（参见我们此前的Argo CD & Flux 持续交付文章）。这里聚焦两套系统如何在 2026 年共同支撑 ML 工作负载。

2. 2026 Kubernetes MLOps 地图

部分 pipeline 后端底层仍会出现 Argo Workflows，但编写应基于 Kubeflow Pipelines IR / v2，Kubernetes 资源持续交付应基于 Argo CD——不要把「Argo Workflows」与「Argo CD」混为一谈。

3. 清晰权属：Kubeflow 做什么 vs Argo CD 做什么

3.1 Kubeflow 负责

• 编写并运行训练 / ETL / 评估 DAG
• GPU 作业生命周期与实验元数据
• 在 Model Registry 中注册模型版本与 lineage
• 定义模型如何可能被 serving（runtime、资源）——常通过生成的 manifests

3.2 Argo CD 负责

• 安装与升级 Kubeflow 组件（GitOps 平台）
• 同步 pipeline 定义以及触发训练的 CronWorkflows
• 跨环境晋升 InferenceService 变更
• 通过 Git 历史实现即时、可审计回滚

4. 推荐 Git 布局

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)

将 platform 与 application 同步分开。数据科学家对 ml-apps 提 PR；平台工程师拥有 ml-platform。使用 Argo CD Projects + RBAC，避免错误的 pipeline PR 改写 Kubeflow 控制平面。

5. 用 Argo CD 管理 Kubeflow

手动安装 Kubeflow 很脆弱：大量 CRD、顺序约束与升级路径。将平台视为 Argo CD Application（或 ApplicationSet），并具备：

• Sync waves — 证书、存储、MySQL/Postgres（或托管 DB）、MinIO/S3 凭证，然后是 KFP / Trainer / KServe
• Health checks — 在同步依赖应用前等待 CRD 与 webhooks 就绪
• 生产环境托管服务 — 当超出一体机演示规模时，用 Cloud SQL/RDS 与 S3 替换集群内 MySQL/MinIO

Application 示意（仅作说明）：

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 作为 GitOps 资源

借助 Kubeflow Pipelines v2 / Kubernetes 原生 API，编译后的 pipelines 可作为集群资源管理。流程变为：

1. 用 Python 编写 pipeline（KFP SDK）
2. 编译为 YAML
3. 提交到 ml-apps/pipelines/...
4. Argo CD 同步；通过 UI、API 或同样存于 Git 的 CronWorkflow 触发 runs

始终为步骤设置CPU、内存与 GPU 限制。无界训练步骤对多租户集群的冲击会快于任何糟糕模型。

7. 模型晋升：registry → Git → Argo CD

这是关键交接：

1. 训练 run 结束；评估指标达到阈值。
2. Model Registry 记录带 URI + 元数据（accuracy、fairness、signer）的新版本。
3. 自动化（或人工）打开 PR，更新 serving overlay 中的 storageUri（以及镜像标签 / runtime）。
4. 合并后，Argo CD 滚动发布 KServe。优先金丝雀：将 canaryTrafficPercent 设为 10%，观察错误率与延迟后再晋升。

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

回滚不是仪表盘上的一次点击——而是对该 URI 变更执行 git revert。Argo CD 将集群愈合到先前期望状态。

8. GPU、配额与 FinOps

• 使用 Kueue，让 TrainJobs 等待公平 GPU 容量，而不是失败或超额订阅。
• 在可能时为训练与延迟敏感推理分离 node pools。
• 按 pipeline run 跟踪成本（GPU-seconds × 费率）。GitOps 并不取消 FinOps——它让支出可归因到某次 commit 与某个模型版本。
• 对 NVIDIA 上的 MIG / time-slicing，在平台仓库中记录分区策略，使 Argo CD 管理的 DevicePlugin 配置保持一致。

9. 安全与多租户

• Kubeflow Profiles 隔离团队；将其映射到 Argo CD Projects。
• 将云凭证存入 Sealed Secrets / External Secrets——切勿把明文 ConfigMaps 放进 Git。
• 要求 registry 元数据门控（如 fairness_score、sign_off_user），晋升机器人才能打开生产 PR。
• 网络策略：训练作业不应需要无限制出站；serving pods 仅需模型存储与客户端。

10. 超越 pod 指标的可观测性

针对 GPU 利用率的 Prometheus 必要但不充分。接入：

• Pipeline 失败告警（run 状态，而非仅 Deployment CrashLoop）
• Serving SLO：延迟、错误率、饱和度
• 可开工单或重新触发训练 CronWorkflow 的数据/模型漂移监控

漂移触发时，修复路径仍应是 GitOps：新 run → 新 URI → PR → Argo CD sync——而不是在节点上手动覆盖。

11. 上线清单

1. 安装 Argo CD；创建 ml-platform 与 ml-apps 项目。
2. 用 sync waves 以 GitOps 安装 Kubeflow；验证 KFP UI 与 KServe CRD。
3. 搭建 object storage + Model Registry；记录 URI 约定。
4. 接入一条黄金路径 pipeline（train → evaluate → register）。
5. 在 Argo CD 下先加入带 staging overlay 的 InferenceService。
6. 启用金丝雀晋升；演练 git revert。
7. 在多团队上线前加入 Kueue 配额与 GPU FinOps 仪表盘。

12. 反模式

• 为「方便」把 4 GB 权重文件提交到 Git LFS
• 允许 notebook 对生产 InferenceServices 执行 kubectl apply
• 单个 Argo CD Application 混入平台与全部团队 pipelines（爆炸半径）
• 训练步骤没有资源限制
• 混淆 Argo Workflows（执行）与 Argo CD（期望状态同步）
• 跳过 staging——从笔记本实验直接晋升到生产流量

13. 何时不该使用此技术栈

在工作站上运行单个私有 LLM 的中小企业（参见我们的AI SME Packages）第一天不需要 Kubeflow + Argo CD。当你有多个模型、并发 GPU 用户、受监管的变更控制，或多个必须保持一致的环境时，再引入该架构。

14. 结论

Kubeflow 与 Argo CD 互补。Kubeflow 让 ML 工作在 Kubernetes 上可运行、可复现。Argo CD 让 ML 基础设施与模型 serving声明式、可审计、可回退。制胜模式很简单：产物在 object storage，指针与 YAML 在 Git，训练在 Kubeflow，交付与回滚在 Argo CD。

配套博客是可分享的摘要；本文是平台设计评审的参考。

由 Workstation 发布（workstation.co.uk）。

本文 SEO 快照

• SEO 标题： Kubeflow + Argo CD：Kubernetes 上的 GitOps MLOps
• Meta description： 如何将 Kubeflow Pipelines、Model Registry 与 KServe 与 Argo CD GitOps 结合，实现 Kubernetes 上可训练、可审计、可安全回滚的 ML。
• 主要关键词： Kubeflow Argo CD, GitOps MLOps, KServe InferenceService, Kubeflow Pipelines GitOps, ML on Kubernetes
• Twitter / X： Kubeflow 负责训练。Argo CD 负责交付。模型留在 object storage；Git 保存 URI。Workstation 完整 GitOps MLOps 指南。
• LinkedIn： 我们发布了关于配对 Kubeflow 与 Argo CD 的深度解析：platform vs apps 的 Git 布局、晋升门控、金丝雀 serving、GPU 配额，以及通过 git revert 回滚。来自 Workstation 工程团队。