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 工程團隊。