前言：為什麼需要 ArgoCD？
我先前寫了一系列關於在 Kubernetes 上使用 Jenkins 建構 CI/CD 管線的文章，涵蓋了 Django 和 Java Web 應用程式兩個藍圖專案。整條管線從開發者的本地電腦開始，經過 Pull Request 合併到主分支，流程都在 Jenkins 平台上清楚定義。不過說實話，這只完成了持續整合（CI）的部分。
至於持續交付/部署（CD），在那個系列裡基本上是半手動處理的——工作負載的 manifest（Pod、StatefulSet、Deployment 等）雖然在 Jenkins Pipeline 裡做了參數化，但最終還是靠 kubectl 從 Pipeline 裡觸發部署。這種做法被稱為「Push-based CD」，也就是由 CI/CD 工具主動把 manifest 推送到 K8S 叢集裡。
Jenkins + ArgoCD 端對端 GitOps CI/CD 流水線架構
Push-based vs Pull-based CD
Push-based 最大的問題在於：你必須把 K8S 的憑證暴露給 CI/CD 工具，讓它有權限去修改叢集。這在安全性上是一個不小的風險。
另一種做法是「Pull-based CD」，由 ArgoCD（或其他 GitOps 工具）主動輪詢版本控制系統（VCS）來偵測變更，再自動同步到叢集。這樣 K8S 憑證就不需要外洩給任何外部工具了。
下面用表格整理兩種方式的比較：
| 比較項目 | Push-based CD | Pull-based CD（GitOps） |
|---|---|---|
| 觸發方式 | CI/CD 工具主動推送到 K8S | ArgoCD 輪詢 VCS 或透過 Webhook 觸發 |
| K8S 憑證暴露 | 必須提供給 CI/CD 工具 | 僅 ArgoCD 內部持有 |
| 版本控制 | manifest 散落在 Pipeline 腳本中 | Git 是唯一真相來源（Single Source of Truth） |
| 擴展性 | 叢集和服務數量增加時管理困難 | 宣告式管理，適合大規模環境 |
| 回溯能力 | 需要額外實作 | Git 歷史紀錄天然支援 |
為什麼要導入 ArgoCD？
說白了，這個系列要做的事就是用 ArgoCD 把 CD 階段自動化。你可能會問：之前的 Pipeline 不是跑得好好的嗎？兩個理由：
- 規模問題：如果你只管 2 個叢集、20 個應用，手動管 manifest 還行。但在微服務（甚至奈米服務）的時代，事情會快速膨脹。某家電商公司的 Grafana 儀表板顯示他們有超過 350 個 K8S 叢集和 14,000 個微服務。就算你的規模沒這麼誇張，純手動管理在企業環境裡也是不可接受的。
- 版本控制需求：原生 K8S 物件目前有 60 多種類型，乘以命名空間和叢集數量，任何企業裡都會達到數千規模。再加上你不是一個人在戰鬥——想像五個人在沒有版本控制的情況下管理這些物件，那畫面會有多混亂。
系列文章規劃
為了讓內容容易消化，這個系列分成三篇：
| 篇次 | 主題 |
|---|---|
| 第一篇 | ArgoCD 使用場景論證 + K8S 上的安裝與設定 |
| 第二篇 | Java 專案搭配 Jenkins 和 ArgoCD 在 K8S 上的部署實戰 |
| 第三篇 | ArgoCD 整合 HashiCorp Vault 的秘密管理 |
注意：這系列不是從零開始的 step-by-step 教學，你需要具備 DevOps、Linux 容器、Kubernetes、Git、Jenkins 和 ArgoCD 的基礎知識。
安裝 ArgoCD
官方文件對安裝步驟描述得很清楚。Argo 提供四種安裝選項，依據高可用性（HA）和權限層級的不同組合：
| 安裝選項 | HA | 命名空間層級權限 | 適用場景 |
|---|---|---|---|
| 選項 A | 是 | 是 | 大型企業（建議） |
| 選項 B | 是 | 否 | 中型環境 / 單叢集 |
| 選項 C | 否 | 是 | 開發測試環境 |
| 選項 D | 否 | 否 | 個人學習 / PoC |
大型企業的最佳實踐是把 Argo 安裝在獨立的叢集中，並啟用 HA。原因很簡單——ArgoCD 是所有 CD 操作的中心，不能因為共同託管的應用故障而受到影響。同時也應該用命名空間層級的權限來遵循最小權限原則。
在我的環境中只有一個叢集，所以選擇了 HA + 非命名空間層級的安裝。安裝指令就是簡單的 kubectl apply：
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/ha/install.yaml成功執行後，你會看到一長串元件清單，包含多個 StatefulSet 和 Deployment。建議花點時間看一下這些工作負載物件，更能理解整個系統的運作方式。
ArgoCD 架構概覽
管理 ArgoCD：Web UI vs CLI
管理 ArgoCD 有兩種方式：Web UI 和 CLI。我個人覺得 Argo 的 Web UI 做得相當不錯，除了一些特殊需求之外，對日常管理來說已經綽綽有餘。
核心概念：Application 與 Project
Application
這是 ArgoCD 最基本的建構單元。每一個你要部署的東西，在 Argo 的視角都是一個 Application。安裝後它會建立一個同名的 Custom Resource Definition（CRD），你可以透過 Web UI、CLI 或直接操作 K8S 資源來管理。
Project
Project 的作用是把 Application 分組管理。每次安裝都會附帶一個 default Project，通常直接用就好。如果你有更細緻的權限需求——例如限制特定的 Source Repository 或 Target Cluster——可以建立額外的 Project。
GitOps 的核心心態：Single Source of Truth
導入 ArgoCD 後，最重要的觀念轉變是：Git 是 K8S 物件修改的唯一來源。換句話說，你必須停止直接用 kubectl 或其他工具來修改正在運行的應用程式。所有變更都要透過 Git commit 來完成。
Reconciliation Loop（協調循環）
那 ArgoCD 怎麼知道 Git 上有變更呢？如果 VCS 的變更和 K8S 的反映之間有明顯延遲，事情就會變得難以管理。這裡有兩個解決方案：
| 同步方式 | 機制 | 優缺點 |
|---|---|---|
| Reconciliation Timeout | 在 argocd-cm ConfigMap 設定輪詢間隔 |
設定簡單，但即使設為 1 秒仍有延遲 |
| Webhook | VCS 平台（如 GitHub）在 commit 時主動通知 ArgoCD | 即時觸發，更普遍的選擇 |
我個人選擇 GitHub Webhook。設定完成後，對特定分支的任何 commit 都會立即觸發 ArgoCD 進行同步，幾乎零延遲。
健康檢查機制
ArgoCD 對每個 K8S 物件都有預設的健康檢查邏輯，狀態包括：
| 狀態 | 說明 |
|---|---|
| Healthy | 物件正常運作 |
| Progressing | 正在變更中 |
| Degraded | 效能下降或部分異常 |
| Missing | 物件不存在 |
| Unknown | 無法判定狀態 |
但有些 K8S 物件的預設健康檢查並不完善。例如 Nginx Ingress 就和 Argo 的預設邏輯不相容，會錯誤觸發「不健康」狀態，導致誤報通知（想像半夜三點被 Slack 叫醒的痛苦）。
解決方案是用 Lua 腳本撰寫自訂健康檢查，然後加入 argocd-cm ConfigMap 中。以 Ingress 為例，你需要建立一個自訂腳本來正確回報其健康狀態。
小結
這篇文章涵蓋了 ArgoCD 的基本概念和安裝設定。重點回顧：
- Push-based CD 有 K8S 憑證暴露的風險，Pull-based（GitOps）更安全
- ArgoCD 的 Application 和 Project 是兩個核心資源
- Git 必須是唯一的真相來源
- Webhook 比 Reconciliation Timeout 更適合即時同步
- 自訂健康檢查可避免誤報通知
下一篇我會實際展示 Java 專案如何透過 Jenkins + ArgoCD 完成端對端的 GitOps 部署。敬請期待！
發佈留言