GitOps 解決方案深度解析：Argo CD、Flux 與 Terraform 的定位

本文整理了關於 Argo CD 和 Flux CD 的比較、Argo CD 的安裝計畫，以及 GitOps 理念在網路設備管理和與 Terraform 整合方面的應用。

一、Argo CD 與 Flux CD 比較

Argo CD 和 Flux 都是 Kubernetes 社群中優秀的 **GitOps Agent**，它們都實作了「拉取式 (Pull-Based)」部署模式。以下是它們的差異：

特性	Argo CD (CNCF 畢業專案)	Flux (CNCF 畢業專案)
設計理念/結構	Application Controller 集中管理：專注於應用程式級別的部署和狀態同步。	分散式工具集：由多個專注於不同功能的專門控制器組成（更模組化）。
部署模型	應用程式為中心 (App-centric)：每個部署定義為一個 Application 資源。	功能為中心 (Feature-centric)：使用 HelmRelease 或 Kustomization 資源來定義部署。
主要介面	優秀的 Web UI：提供功能豐富、視覺化強大的介面。	CLI 為主：主要透過 flux cli 進行管理。
多叢集支援	集中式管理：單一 Argo CD 實例可管理多個外部 K8s 叢集。	分散式管理：通常建議在每個目標叢集上安裝一個 Flux 實例。

選擇建議： Argo CD 更「操作友好」且「集中」；Flux 更「Kubernetes 原生」且「模組化」。

二、Argo CD 導入與測試計畫

以下為採用 Argo CD 的三階段安裝與驗證計畫：

階段一：準備與規劃 (Pre-Installation)

• **P1 - K8s 環境檢查：** 確認叢集版本和權限。
• **P2 - Git 儲存庫準備：** 建立配置 YAML 檔的 Git 儲存庫（如：git@github.com/org/k8s-manifests.git）。
• **P3 - 測試應用程式配置：** 在 Repo 中準備簡單的 YAML 檔案（如：k8s-manifests/guestbook/）。

階段二：安裝與核心配置

# 1. 安裝 Argo CD

kubectl create namespace argocd

kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

# 2. 取得初始密碼

kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{'.data.password'}" | base64 -d; echo

# 3. 啟動 Port Forward 測試存取

kubectl port-forward svc/argocd-server -n argocd 8080:443

階段三：功能驗證與測試

測試項目	目的	預期結果
T1.3 手動同步	驗證部署功能	應用程式狀態變為 Synced 和 Healthy。
T2.2 手動漂移修復	驗證持續協調 (Self-Heal)	手動修改 K8s 資源後，Argo CD 自動偵測並將其修正回 Git 定義的狀態。
T2.3 版本回溯	驗證回溯機制	Git 回溯 Commit 後，Argo CD 自動將 K8s 狀態回溯到舊版本。

三、Argo CD 的部署位置

答案：Argo CD 是安裝在 Kubernetes (K8s) 叢集內部的。

它作為一個控制迴路在叢集內部運行，持續：

• 監控 Git 儲存庫的期望狀態 (Desired State)。
• 透過 K8s API 讀取叢集的實際狀態 (Live State)。
• 執行協調，確保兩者一致（GitOps 拉取式模式）。

四、Argo CD 的狀態偵測機制

答案：Argo CD 部署後，不會主動偵測現有 K8s 的所有 YAML。它只會根據您給它的配置去工作。

Argo CD 的工作流程是以「**應用程式定義**」為中心：

1. 您必須建立一個 Application 資源，明確指向一個 Git Repo/Path。
2. Argo CD 才會開始：讀取 Git (期望狀態) → **查詢 K8s API (實際狀態)** → **比較**並判斷是否需要同步。

所有未被 Argo CD 定義和管理的資源，將不會受到 GitOps 流程的影響。

五、k8s-manifests/guestbook 的意義

這是一個範例路徑結構，結合了兩個概念：

• k8s-manifests/： 業界常用的資料夾名稱，用於存放 **Kubernetes Manifests**（K8s 資源定義的 YAML 檔）。
• guestbook： 指一個特定的應用程式名稱（通常是 K8s 範例應用程式）。

在 Argo CD 中，這個路徑就是指定：「請將這個資料夾內的所有 YAML 檔案部署到目標叢集，並將這些資源歸類為 guestbook 應用程式。」

六、GitOps 理念與 Cisco 網路設備管理

答案：可以，但不能直接使用 Argo CD。

GitOps 的理念（以 Git 作為唯一事實來源、宣告式、自動協調）完全適用於網路設備，這被稱為 **NetDevOps**。

由於 Cisco 設備不使用 K8s YAML，您需要將 GitOps 理念與專門的 **網路自動化工具** 結合，作為 Argo CD 的替代執行器：

• 期望狀態： Git Repo 中的 **YAML/Jinja2 模版**。
• 執行代理： **Ansible** 或 **Terraform**。它們負責讀取模版、生成 Cisco CLI 命令，並透過 SSH/API **推送**到設備。
• 協調： Ansible 的冪等性 (Idempotency) 機制，確保只應用必要的更改。

七、Terraform 與 Argo CD 的比較與協作

兩者是互補而非競爭的關係，主要區別在於管理的**範圍**和**機制**：

關鍵差異

特性	Terraform	Argo CD
核心用途	**基礎設施的供應 (Provisioning)**	**應用程式的持續交付 (CD)**
管理範圍	VPC、RDS、S3、**K8s 叢集本身**	**K8s 內部的** Deployment、Service、ConfigMap 等
機制	CLI 驅動 (Push-Based)	控制器驅動 (Pull-Based)

最佳協作模式

在 End-to-End GitOps 中，兩者形成清晰的階層：

1. Terraform (IaC/Provisioning)： 負責建立 K8s 叢集、資料庫等底層**基礎設施 (Infrastructure)**，作為部署的「畫布」。
2. Argo CD (GitOps/Delivery)： 安裝在 K8s 叢集內，負責持續管理和部署**應用程式 (Application)** 資源到這個畫布上。

aa