xDev Asia

Helm 套件管理器、GitOps 與 Argo CD、Kubernetes CI/CD 管線。部署策略：Rolling Update、Canary、Blue-Green。

1. Helm — Kubernetes 套件管理器

Helm 是 Kubernetes 的套件管理器。Chart 是可重複使用和參數化的 YAML 模板。

Helm Concepts:
  Chart     = Package (templates + default values)
  Release   = Installed instance of a chart in a cluster
  Repository = Collection of charts (ArtifactHub.io)
  Values    = Parameters to customize a chart

$ helm install my-nginx bitnami/nginx --set service.type=LoadBalancer
  └── Release: my-nginx
      ├── templates/deployment.yaml
      ├── templates/service.yaml
      └── values.yaml (overridden)

Helm 命令	功能
`helm install`	部署新 Chart（建立 Release）
`helm upgrade`	使用新 Chart/Values 更新 Release
`helm rollback`	回復到之前的版本
`helm list`	列出所有 Release
`helm uninstall`	刪除 Release
`helm template`	渲染模板而不部署

考試重點： Helm 將 Release 歷史記錄儲存在 Kubernetes Secrets 中（不是 ConfigMap）。這使 helm rollback 能夠運作。歷史記錄預設保留 10 個版本。

2. GitOps

GitOps 是以 Git 作為程式碼和基礎設施組態的唯一事實來源的運營框架。

GitOps Flow:
  Developer ──push──► Git Repo (desired state)
                          │
                    GitOps Operator (Argo CD / Flux)
                    - Watches Git repo
                    - Compares with cluster state
                    - Syncs if diff found
                          │
                       K8s Cluster (actual state)

GitOps 原則	含義
宣告式	系統狀態以 YAML 描述在 Git 中
版本化且不可變	Git 歷史記錄 = 稽核軌跡
自動拉取	Agent 拉取變更，不需要推送存取叢集
持續協調	漂移偵測——叢集與 Git 不同時自動修正

Argo CD

Argo CD 是最受歡迎的 Kubernetes GitOps 控制器（CNCF Incubating → Graduated 2022）。

考試重點： GitOps 使用 Pull-based 部署而非 Push。好處：叢集不需要對外暴露 API，CI 管線不需要 kubeconfig 憑證。

3. Kubernetes CI/CD

CI/CD Pipeline:
  Code Push
      │
  ┌───▼───┐  CI Phase (Build)
  │ Build  │── Unit tests ── Integration tests
  │ Image  │── Security scan (Trivy, Snyk)
  └───┬───┘── Push to Registry (ECR, GCR)
      │
  ┌───▼───┐  CD Phase (Deploy)
  │ Update │── Update Helm values / K8s manifest
  │ Manifest│── Push to GitOps repo
  └───┬───┘── Argo CD picks up and syncs
      │
  ┌───▼────────────────────┐
  │ Kubernetes Cluster     │
  │  Rolling Update        │
  └────────────────────────┘

4. 部署策略

策略	運作方式	停機時間	回滾	使用場景
Rolling Update	逐步替換 Pod（預設）	無	kubectl rollout undo	無狀態應用、漸進式
Recreate	終止所有 v1，然後部署 v2	有	重新部署 v1	有破壞性變更、簡單
Blue-Green	同時執行 v1（藍）+ v2（綠），切換流量	無	即時切回	關鍵應用、快速回滾
Canary	將小比例流量路由到新版本	無	重新導向流量	分階段發布、A/B 測試

Canary in Kubernetes (Ingress weight):
  ┌─────────────────────────────────┐
  │  Ingress (canary annotation)     │
  │  90% ──────► Deployment v1.0    │
  │  10% ──────► Deployment v1.1    │
  └─────────────────────────────────┘
  → Monitor v1.1 errors → promote to 100% or rollback

5. 速查表

考試問題	答案
Helm 將 Release 歷史儲存在哪裡？	Kubernetes Secrets
GitOps 的唯一事實來源？	Git Repository
GitOps 使用 Pull 還是 Push？	Pull-based（Agent 拉取）
無停機時間的部署？	Rolling 或 Blue-Green
以 5% 流量測試新版本？	Canary 部署
出問題時快速回滾？	Blue-Green（即時切換）

6. 練習題

Q1: 團隊希望先將新版應用部署給 10% 的使用者，監控錯誤，然後逐步增加流量。應使用哪種部署策略？

A) Recreate
B) Rolling Update
C) Blue-Green
D) Canary ✓

解析：Canary 部署將一小部分流量路由到新版本，讓團隊用真實流量驗證後再全面推出。如果新版本有錯誤，影響範圍最小化。

Q2: 以下哪項最能描述 GitOps 模型？

A) CI/CD 管線在測試通過後直接推送到 Kubernetes
B) Git Repository 是唯一事實來源；控制器持續協調叢集狀態與 Git ✓
C) 開發者從工作站手動執行 kubectl 命令
D) 基礎設施定義在關聯式資料庫中以保持一致性

解析：GitOps 使用 Pull-based 模型，控制器（Argo CD、Flux）監視 Git Repository 並確保叢集與 Git 中的宣告一致。這提供稽核軌跡、漂移偵測和安全部署。

Q3: Helm 將 Release 歷史儲存在哪裡以啟用回滾功能？

A) Helm 的本地檔案系統（~/.helm）
B) 目標 namespace 中的 ConfigMap
C) 目標 namespace 中的 Secret ✓
D) 獨立的 etcd 資料庫

解析：自 Helm v3 起，Release 中繼資料（歷史、值、Chart 資訊）以 Secret 形式儲存在 Release 的 namespace 中。這使 helm rollback 能讀取先前版本的資料，並允許多個使用者/系統管理同一 Release。