GitOps in Production: What Nobody Tells You About ArgoCD

Cover Image

原始來源與檔名：2026-06-26T093918+0800-GitOps in Production What Nobody Tells You About ArgoCD.md

SOURCE | 資訊源評估

NAPKIN | 餐巾纸

餐巾纸公式

安裝了 ArgoCD ≠ 實現了 GitOps ≠ Production Ready

在沒有定義好 Secrets 策略、資源同步順序、以及自動縮放衝突機制前，ArgoCD 只是一個會製造驚喜（災難）的 UI 工具，而非自動化救星。

一句话

ArgoCD 在 Production 環境的巨大鴻溝，在於它預設並不會幫你解決機密管理、依賴順序以及系統自動化變更（漂移）的管理問題，這些都需要精確的架構設計。

餐巾纸草图

[Git Repo] --(Sync)--> [ArgoCD] --(Deploy)--> [K8s Cluster]
                             |
                   [The Missing Middle]
                   1. External Secrets (ESO)
                   2. ignoreDifferences (HPA/KEDA)
                   3. Sync Waves (CRDs first)
                   4. App of Apps Pattern

ROUND 1: SKELETON | 骨架掃描

“这本书在说什么”

章节骨架

  1. 開場災難: 一個因漂移且未能自我修復導致的血案。
  2. App of Apps: 如何管理「管理 App 的 App」。
  3. Secrets 管理: ArgoCD 沒教你的機密處理方式 (ESO)。
  4. Drift vs 預期變更: 教會 ArgoCD 區分人為漂移與系統自動縮放。
  5. Sync Waves: 為什麼同步順序 (如 CRD 優先) 決定了部署的成敗。
  6. 多叢集架構與清單: Hub-and-spoke 模式與 Production 檢查表。

ROUND 2: DISSECTION | 血肉解剖

“凭什么这么说”

论证链

單一 App 教學無法應付 Production 複雜度 --> 導入 App of Apps 模式但容易踩到 Prune 陷阱 --> GitOps 不能儲存明文密碼，必須整合 ESO --> HPA/KEDA 會自動修改 Replica 等欄位，與 GitOps 產生衝突，必須配置 ignoreDifferences --> 資源之間有依賴性，預設的全同步會失敗，必須配置 Sync Waves --> 多叢集需要 ApplicationSets 才能規模化管理。

关键证据

  1. Prune 陷阱: 在 App of Apps 模式下，開啟 prune: true 代表若你在 Git 誤刪一個 YAML，ArgoCD 會毫無預警地刪除整個應用及其所有資源。
  2. HPA 衝突 (Scenario B): 如果 KEDA 因為流量將 Pod 縮放至 10 個，而 Git 上寫 3 個，若未設定 ignoreDifferences，ArgoCD 會強制將其降回 3 個，導致系統崩潰。
  3. 依賴失效: 如果 CRD (如 Prometheus ServiceMonitor) 和其 Instance 同時被同步，K8s API 會報錯。必須透過負波次 (如 Wave -3) 優先處理 CRD。

隐形假设与边界

ROUND 3: SOUL | 靈魂提取

“还能怎么用”

留白提問 (Guided Reflection)

跨域映射

DEEP READ | 精讀指引

[!IMPORTANT] 學習的本質需要「認知阻力」。請親自回到原文閱讀以下核心段落，感受原始論述的阻力，不要只依賴 AI 的總結。

  1. Secrets management — the problem ArgoCD doesn’t solve for you: 精讀這段關於 External Secrets Operator (ESO) 的整合方式。這是所有 GitOps 初學者最容易卡關的死穴。
  2. Drift vs intentional out-of-band changes: 深刻理解人為漂移與自動化控制器的差異，這段論述直接影響了系統在高峰期的存活率。
  3. The production readiness checklist: 把這段當作你的系統健檢清單。如果有一項沒做到，就不要宣稱你們達到了 Production-grade。

GitOps in Production: What Nobody Tells You About ArgoCD (Architectural Deep Dive)

前言/背景

文章指出一個殘酷的現實：許多團隊安裝了 ArgoCD 並能成功運行範例，就自以為達成了 GitOps。然而，從「能運作」到「Production-grade (生產級)」之間，存在著巨大的實踐鴻溝。本文透過解決 App 巢狀管理、機密處理、自動化衝突與資源部署順序等實戰問題，揭露了 ArgoCD 官方教學中沒有告訴你的核心架構決策。

章節詳細總結

The App of Apps Pattern (App of Apps 模式的必要性)

基礎教學通常示範單一 Application 對應單一 Helm Chart。但在生產環境中，你需要管理數十個應用程式與 Namespace。 App of Apps 模式解決了這個問題：建立一個「Root Application」，它監控 Git 倉庫中的一個目錄 (例如 apps/)，而這個目錄中包含了所有其他應用的 Application Manifests。

Secrets Management: ArgoCD 無法解決的難題

GitOps 的核心原則是一切都在 Git 中，但機密資訊 (Secrets) 絕對不能放進 Git。ArgoCD 原生並沒有解決這個問題。 生產環境的標準解法是整合 External Secrets Operator (ESO) 與雲端金鑰庫 (如 AWS Secrets Manager)。

Drift vs Intentional Out-of-band Changes (漂移與預期變更的衝突)

ArgoCD 會盡責地將叢集狀態與 Git 狀態對齊。如果開啟了 selfHeal: true，它會自動覆寫所有與 Git 不同的變更。但在真實世界中，有兩種狀況：

  1. Drift (漂移)：工程師凌晨手動將 Replicas 從 3 改為 10，這是不合規的，應該被覆寫。
  2. 預期變更：HPA (Horizontal Pod Autoscaler) 或 KEDA 根據流量將 Replicas 擴展到 10。 如果 ArgoCD 無法區分兩者，它會不斷把 HPA 擴展的 Pod 縮回 3，導致系統災難。

架構解法：在 Application Spec 中使用 ignoreDifferences 忽略特定欄位。

spec:
  ignoreDifferences:
    - group: apps
      kind: Deployment
      jsonPointers:
        - /spec/replicas

架構原則：如果某個控制器 (HPA/KEDA) 擁有了某個欄位的控制權，該欄位就必須進入 ignoreDifferences。

Sync Waves (同步波次：順序決定一切)

預設情況下，ArgoCD 會同時部署所有資源。這在具有依賴性的場景會導致失敗。例如：必須先有 Namespace 才能部署資源；必須先有 CRD 才能部署 CRD 的 Instance。 透過 Annotation 標註 argocd.argoproj.io/sync-wave，可以指示 ArgoCD 依照順序等待健康後再進行下一波。 實戰波次建議：

Multi-cluster Setups (多叢集與 ApplicationSets)

當需要管理多個叢集時，通常採用 Hub-and-spoke (軸輻式) 模式。由單一控制平面管理所有叢集。 但隨著叢集數量增加，撰寫大量的 Application YAML 變得不可維護。必須導入 ApplicationSets。 透過 ApplicationSet 的 generators，你只需要定義一份 Template，並在清單中加入新的 Cluster URL，ArgoCD 就會自動展開並部署該應用至所有目標叢集。 網路架構警告：控制平面必須具備穩定連線至所有受管叢集 API Server 的網路通道 (如 Transit Gateway)。早期網路設計的失誤會造成後續擴展的極大痛苦。

總結與結論