Kubernetes 持續交付：使用 ArgoCD 和 Flux 的 GitOps 管道

Kubernetes 上的持續交付已經遠遠超出了簡單的 kubectl apply 命令。現代團隊正在採用 GitOps，這是一種使用 Git 作為宣告性基礎設施和應用程式配置的單一事實來源的範例。透過將 GitOps 原則與 ArgoCD 和 Flux CD 等工具相結合，組織可以實現跨叢集和環境擴充套件的可靠、可稽核和自動化的部署管道。

本指南涵蓋了使用 GitOps 方法在 Kubernetes 上構建生產級持續交付管道的架構、設定和最佳實踐。

GitOps 原則

GitOps 基於四個核心原則，從根本上改變了團隊管理部署的方式：

• 宣告式配置 - 以宣告方式描述系統的整個所需狀態。對於 Kubernetes，這意味著儲存在 Git 中的 YAML 清單、Helm 圖表或 Kustomize 覆蓋。
• 版本控制 - Git 是唯一的事實來源。每個更改都會透過拉取請求，提供完整的審計跟蹤並透過恢復提交來實現輕鬆回滾。
• 自動對賬 - 叢集中執行的代理不斷將 Git 中的所需狀態與叢集中的實際狀態進行比較，並自動協調任何偏差。
• 持續觀察 - 系統持續監控 Git 儲存庫和叢集狀態，對差異發出警報並確保叢集始終與宣告的配置匹配。

這些原則消除了手動部署步驟，減少了人為錯誤，並提供一致的工作流程，無論叢集複雜程度如何。

ArgoCD 架構和設定

ArgoCD 是 Kubernetes 採用最廣泛的 GitOps 工具。它提供了強大的 Web UI、CLI 和 API，用於管理跨叢集的應用程式部署。

核心元件

ArgoCD 由幾個協同工作的關鍵元件組成：

• API伺服器 - 公開 gRPC/REST API 並提供 Web UI。處理身份驗證、RBAC 和外部整合。
• 儲存庫伺服器 - 克隆 Git 儲存庫並從 Helm 圖表、Kustomize 或純 YAML 生成 Kubernetes 清單。
• 應用控制器 - 持續監控正在執行的應用程式並將實時狀態與 Git 中的所需狀態進行比較。
• 雷迪斯 - 為儲存庫伺服器和應用程式控制器提供快取。

安裝

使用官方清單或 Helm 圖表將 ArgoCD 部署到您的叢集：

# Create namespace and install ArgoCD
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

# Or via Helm
helm repo add argo https://argoproj.github.io/argo-helm
helm install argocd argo/argo-cd \
  --namespace argocd \
  --create-namespace \
  --set server.service.type=LoadBalancer

定義應用程式

ArgoCD 使用 Application 自定義資源來定義要部署的內容和位置。這是一個典型的應用程式定義：

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-web-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/myorg/k8s-manifests.git
    targetRevision: main
    path: apps/my-web-app/overlays/production
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true
    retry:
      limit: 5
      backoff:
        duration: 5s
        factor: 2
        maxDuration: 3m

的 syncPolicy.automated 部分啟用自動同步。的 prune 選項刪除 Git 中不再定義的資源，而 selfHeal 恢復直接對叢集進行的手動更改。

Flux CD：另一種方法

Flux CD 採用了與 GitOps 不同的架構方法。 Flux 不是具有 UI 的集中式伺服器，而是作為一組 Kubernetes 控制器執行，每個控制器處理特定的問題。

助焊劑成分

• 源控制器 - 管理 Git 儲存庫、Helm 儲存庫和 OCI 工件源。
• 定製控制器 - 應用 Kustomize 覆蓋和普通 YAML 清單。
• 舵控制器 - 透過以下方式管理 Helm 圖表釋出 HelmRelease 自定義資源。
• 通知控制器 - 處理入站和出站事件，與 Slack、Teams 和 Webhook 提供商整合。
• 影象自動化控制器 - 掃描容器登錄檔並在新映像可用時更新清單。

通量自舉

# Bootstrap Flux on a cluster with a GitHub repository
flux bootstrap github \
  --owner=myorg \
  --repository=fleet-infra \
  --branch=main \
  --path=clusters/production \
  --personal

# Define a HelmRelease
apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: nginx-ingress
  namespace: ingress-system
spec:
  interval: 5m
  chart:
    spec:
      chart: ingress-nginx
      version: "4.x"
      sourceRef:
        kind: HelmRepository
        name: ingress-nginx
        namespace: flux-system
  values:
    controller:
      replicaCount: 3
      metrics:
        enabled: true

ArgoCD 與 Flux：何時選擇

當您需要豐富的 Web UI 來實現可見性、具有細粒度 RBAC 的多租戶以及集中式管理平面時，ArgoCD 是理想的選擇。 Flux 在喜歡輕量級、基於控制器的架構、需要影象自動化功能或希望與 Kubernetes API 生態系統進行更深入整合的環境中大放異彩。

GitOps 中的 Helm 圖表管理

Helm 圖表是 Kubernetes 應用程式事實上的打包格式。在 GitOps 工作流程中，跨環境管理 Helm 值需要仔細組織。

# Repository structure for multi-environment Helm management
k8s-manifests/
  base/
    my-app/
      Chart.yaml
      values.yaml          # Default values
      templates/
        deployment.yaml
        service.yaml
        ingress.yaml
  environments/
    dev/
      my-app/
        values.yaml        # Dev overrides
    staging/
      my-app/
        values.yaml        # Staging overrides
    production/
      my-app/
        values.yaml        # Production overrides

ArgoCD 和 Flux 都原生支援 Helm。 ArgoCD 透過其儲存庫伺服器在伺服器端渲染圖表，而 Flux 直接在其 Helm 控制器中使用 Helm SDK。

部署策略

選擇正確的部署策略可以最大限度地降低風險並確保零停機發布。

滾動更新

預設的 Kubernetes 策略。 Pod 逐漸被新版本替換。配置 maxSurge 和 maxUnavailable 來控制推出速度。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    spec:
      containers:
        - name: app
          image: myapp:v2.1.0
          readinessProbe:
            httpGet:
              path: /health
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 10

藍綠部署

執行兩個相同的環境（藍色和綠色）。將新版本部署到非活動環境，驗證它，然後切換流量。這透過切換回以前的環境來提供即時回滾。使用服務標籤選擇器或 Istio 流量管理來實施。

金絲雀部署

逐漸將一小部分流量路由到新版本，隨著信心的增長而增加百分比。 Flagger 和 Argo Rollouts 等工具透過基於指標的促銷自動化金絲雀分析。

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: my-app
spec:
  replicas: 5
  strategy:
    canary:
      steps:
        - setWeight: 10
        - pause: { duration: 5m }
        - setWeight: 30
        - pause: { duration: 5m }
        - setWeight: 60
        - pause: { duration: 5m }
      canaryService: my-app-canary
      stableService: my-app-stable
      trafficRouting:
        istio:
          virtualService:
            name: my-app-vsvc
            routes:
              - primary

自動回滾

GitOps 使回滾變得簡單：只需恢復 Git 提交即可。然而，基於健康檢查的自動回滾提供了額外的安全網。

ArgoCD 透過其同步和健康評估系統支援自動回滾。如果應用程式在同步後進入降級狀態，ArgoCD 可以自動回滾到最後一個已知的良好狀態。

對於更復雜的回滾場景，Argo Rollouts 和 Flagger 可以分析 Prometheus 指標、執行自動化測試並中止顯示效能下降的回滾。

秘密管理與密封秘密

在 Git 中儲存機密對於 GitOps 來說是一個嚴峻的挑戰。 Sealed Secrets 透過加密只能由目標叢集中執行的控制器解密的機密來解決此問題。

# Install Sealed Secrets controller
helm repo add sealed-secrets https://bitnami-labs.github.io/sealed-secrets
helm install sealed-secrets sealed-secrets/sealed-secrets \
  --namespace kube-system

# Encrypt a secret
kubectl create secret generic db-credentials \
  --from-literal=username=admin \
  --from-literal=password=s3cure-p@ss \
  --dry-run=client -o yaml | \
  kubeseal --format yaml > db-credentials-sealed.yaml

由此產生的 SealedSecret 資源可以安全地提交給 Git。只有目標叢集中的 Sealed Secrets 控制器持有解密所需的私鑰。替代方法包括外部 Secrets Operator（用於從 AWS Secrets Manager、HashiCorp Vault 等提取）和用於檔案級加密的 SOPS。

監控部署

部署狀態的可見性對於生產 GitOps 管道至關重要。實施多層次監控：

• ArgoCD指標 - ArgoCD 公開 Prometheus 同步狀態、執行狀況和操作持續時間的指標。建立 Grafana 儀表板來跟蹤部署頻率和故障率。
• Kubernetes 活動 - 監控 Pod 排程、映象拉取和就緒探測事件以及早發現問題。
• 應用程式健康檢查 - 使用 Lua 指令碼在 ArgoCD 中配置自定義執行狀況檢查，以定義“健康”對您的特定資源意味著什麼。
• 警報 - 將 ArgoCD 通知與 Slack、PagerDuty 或電子郵件整合，以針對同步失敗、執行狀況惡化或漂移檢測發出警報。

# ArgoCD Notification ConfigMap
apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-notifications-cm
  namespace: argocd
data:
  trigger.on-sync-failed: |
    - when: app.status.operationState.phase in ['Error', 'Failed']
      send: [slack-notification]
  template.slack-notification: |
    message: |
      Application {{.app.metadata.name}} sync {{.app.status.operationState.phase}}.
      Revision: {{.app.status.sync.revision}}
  service.slack: |
    token: $slack-token
    channel: deployments

多叢集交付

隨著組織規模的擴大，跨多個叢集部署變得必要。 ArgoCD 透過註冊外部叢集來原生支援多叢集管理。 Flux 透過引導工作負載叢集的管理叢集來實現這一點。

ArgoCD 中的 ApplicationSet 控制器對於多叢集場景特別強大。它可以根據叢集列表、Git 目錄或拉取請求事件動態生成應用程式資源。

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: my-app-set
  namespace: argocd
spec:
  generators:
    - clusters:
        selector:
          matchLabels:
            env: production
  template:
    metadata:
      name: 'my-app-{{name}}'
    spec:
      project: default
      source:
        repoURL: https://github.com/myorg/k8s-manifests.git
        targetRevision: main
        path: 'apps/my-app/overlays/{{metadata.labels.region}}'
      destination:
        server: '{{server}}'
        namespace: my-app

結論

帶有 ArgoCD 或 Flux CD 的 GitOps 為 Kubernetes 持續交付提供了堅實的基礎。透過將 Git 視為事實來源、自動協調並利用漸進式交付策略，團隊可以充滿信心地進行部署並快速從故障中恢復。從簡單的單叢集設定開始，建立 Git 儲存庫結構，並隨著平臺的成熟逐步採用金絲雀部署、多叢集管理和自動回滾策略等高階模式。

對 GitOps 基礎設施的投資透過提高可靠性、更快的事件響應、完整的審計跟蹤以及使部署像合併拉取請求一樣簡單的開發人員體驗而獲得回報。