今日目標

• 理解傳統 Push-based CI/CD 在管理 Kubernetes 集群時面臨的安全與維運痛點。
• 掌握雲原生持續部署的黃金準則：GitOps 核心原則。
• 搞懂 Pull-based 機制與 GitOps 代表性工具：ArgoCD 的架構運作。
• 實戰操作：在 Minikube 安裝 ArgoCD，並體驗將 Git 倉庫中的 YAML 自動同步至集群的流暢流程。

痛點場景：傳統 Push-based CI/CD 的瓶頸

在傳統的 CI/CD 流程中（如 Jenkins、GitHub Actions、GitLab CI），我們通常採用 Push（推動）模型：

1. 開發者將程式碼 Push 到 GitHub。
2. CI 工具觸發測試並打包 Docker Image，推送到 Container Registry。
3. CD 流程在外部伺服器執行 kubectl apply，將新版本硬塞進 K8s 集群。

這種 Push 模型在規模變大時會暴露出嚴重的問題：

為了解決這些痛點，GitOps 應運而生。

什麼是 GitOps？

GitOps 是一種現代化的持續交付架構模式，其核心思想可以濃縮成一句話：

「Git 是系統宣告式期望狀態的唯一事實來源（Single Source of Truth）。」

GitOps 的四大核心原則

1. 宣告式描述（Declarative）：整個系統的所有基礎設施與應用配置（K8s YAMLs / Helm Charts）必須全部用宣告式檔案描述，並存放在 Git 倉庫中。
2. 版本控制與不可變（Versioned & Immutable）：所有變更都透過 Git Commit、Pull Request 進行 Code Review 與歷史稽核。
3. 自動拉取（Pull-based Agent）：在 K8s 集群內部運行一個專屬的控制器（Agent），由它主動去監聽 Git 倉庫的變更，而不是讓外部工具推進來。
4. 持續對齊與自我修復（Continuous Reconciliation）：控制器會不斷比對「Git 裡的期望狀態」與「集群內的實際狀態」。一旦發現有人手動修改或狀態偏離（Drift），自動將其修正還原！

GitOps 的代表神器：ArgoCD

ArgoCD 是目前 CNCF 中最受歡迎、功能最強大的宣告式 GitOps 持續交付工具。

ArgoCD 核心架構元件

實戰演練：在本地安裝與體驗 ArgoCD

步驟 1：在 Minikube 建立 ArgoCD

建立專屬命名空間並套用官方最新安裝清單：

# 建立 argocd 命名空間
kubectl create namespace argocd

# 套用 ArgoCD 官方安裝清單
kubectl apply -n argocd -f [https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml](https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml)

檢查 ArgoCD 元件是否全數啟動完成（約需 1 至 2 分鐘）：

kubectl get pods -n argocd

步驟 2：存取 ArgoCD Web UI 介面

取得 ArgoCD 的預設登入密碼（帳號為 admin，密碼存放於 Secret 中）：

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

使用端口轉發將 ArgoCD Web 服務映射到本地：

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

打開瀏覽器訪問 https://localhost:8080：

• 若瀏覽器出現「您的連線不是私人連線」警告，點擊「進階」➔「繼續前往」。
• 輸入帳號 admin 與剛剛解碼得到的密碼即可順利登入！

步驟 3：建立第一個 GitOps Application

我們可以直接透過 YAML 宣告一個 ArgoCD Application 物件，告訴它監控官方範例倉庫：

建立 argocd-demo-app.yaml：

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: guestbook-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: [https://github.com/argoproj/argocd-example-apps.git](https://github.com/argoproj/argocd-example-apps.git)
    targetRevision: HEAD
    path: guestbook # 監控該倉庫下的 guestbook 目錄
  destination:
    server: [https://kubernetes.default.svc](https://kubernetes.default.svc)
    namespace: default
  syncPolicy:
    automated:
      prune: true    # 若 Git 刪除檔案，集群內對應資源也自動刪除
      selfHeal: true # 若線上有人手動修改，自動強制覆蓋還原成 Git 狀態

套用配置：

kubectl apply -f argocd-demo-app.yaml

步驟 4：在 Web UI 觀察自動同步與拓撲圖

回到瀏覽器上的 ArgoCD 儀表板，你會看到神奇的畫面：

1. 儀表板上出現了名為 guestbook-app 的卡片。
2. 狀態顯示為 Synced（與 Git 完全同步） 且健康度為 Healthy。
3. 點擊卡片進入，ArgoCD 會以視覺化樹狀圖（Topology Tree）展示出 Deployment、Service、ReplicaSet 與 Pod 的完整關聯！

見證 Self-heal 自癒奇蹟：
如果你在終端機手動把 guestbook 的 Pod 副本數改掉（例如 kubectl scale deployment guestbook-ui --replicas=5），只要過幾秒鐘，ArgoCD 就會偵測到狀態漂移（OutOfSync），並自動把它縮回 Git 定義的原本副本數！

本日小結

今天我們解鎖了現代雲原生交付的最高準則 GitOps：

• 徹底理解了從危險的 Push 模型 轉向安全的 Pull 模型 的必要性。
• 掌握了 Git 作為「單一事實來源」與「狀態漂移自動修復」的核心機制。
• 在本地成功搭建了 ArgoCD，體驗了宣告式持續交付的便利。

完成了雲原生架構中運算、網路、儲存、維運監控、資安與 CI/CD 的全方位實戰後，當我們要把整個架構搬上真實的企業公有雲（AWS EKS / GCP GKE）時，該如何做架構選型與成本估算？

明天 Day 28，我們將進入公有雲實戰篇：「雲端託管 K8s 實戰：AWS EKS vs. GCP GKE 架構比較與架構選型」！