文章整理：6 個阻止週五晚上被 Call 的 Argo CD 防護欄

段落重點與總結

前言

• 段落重點：我們都喜歡 GitOps，直到週五晚上 9:42。一個意外的 latest 標籤、一個意想不到的 LoadBalancer，突然間 Slack 警報大作。解決方案不是更多的儀表板，而是更好的防護欄（guardrails）。作者將分享他用來讓發布變得無聊、可預測且令人愉快的六種 Argo CD 模式：同步視窗（sync windows）、AppProjects、策略檢查、漸進式交付、安全的同步設定和漂移控制。

• 總結：文章開宗明義指出，為了避免在非工作時間（如週五晚上）因錯誤的 Kubernetes 發布而引發緊急事件，關鍵不在於事後監控，而在於事前預防。作者提出了六個實用的 Argo CD 防護欄（guardrails）設定，旨在讓 GitOps 流程變得安全、可預測。

1) AppProject 邊界：圍堵爆炸半徑

• 段落重點：大多數事故始於一個本不應針對該叢集/命名空間/資源種類（kind）的變更。解決方法是定義 AppProject，明確允許哪些 Git 倉儲、目標叢集和資源種類是合法的。其他一切預設都被阻止。例如，以下 YAML 定義了一個名為 platform 的專案，限制了來源倉儲、目標命名空間，並只允許 ConfigMap 和 Deployment 等特定資源。這能有效防止將測試應用指向生產環境，或在私有叢集中創建 LoadBalancer 等「手滑」時刻。

  # project-platform.yaml
  apiVersion: argoproj.io/v1alpha1
  kind: AppProject
  metadata:
    name: platform
  spec:
    sourceRepos:
    - 'https://git.example.com/platform/*'
    destinations:
    - namespace: 'platform-*'
      server: 'https://kubernetes.default.svc'
    namespaceResourceWhitelist:
    - group: ''
      kind: 'ConfigMap'
    - group: 'apps'
      kind: 'Deployment'

• 總結：AppProject 是限制變更影響範圍的第一道防線。透過在 AppProject 中明確定義允許的 Git 來源、目標叢集/命名空間以及資源類型白名單，可以從根本上阻止開發人員將錯誤的設定應用到錯誤的環境中，從而有效控制潛在風險的「爆炸半徑」。

2) 同步視窗：為風險設定時間限制 (凍結週五)

• 段落重點：大多數團隊並非真的需要 24x7 全天候部署。應該讓非工作時間的部署成為一種選擇，而不是預設行為。使用同步視窗（sync windows）可以在安全時段之外拒絕自動同步，但仍允許在緊急情況下手動覆寫。例如，設定只在週一至週五的 09:00-17:30 之間允許自動同步。這將週五晚上的部署變成了一個需要明確決策的行為。如果真的需要發布，可以執行手動同步，並留下稽核記錄。

  # project-platform.yaml (add to spec)
  syncWindows:
  - kind: allow
    schedule: "Mon-Fri 09:00-17:30"
  - kind: deny
    schedule: "Fri 17:30-Mon 09:00"

• 總結：同步視窗（Sync Windows）是一個強大的時間防護欄，它透過設定僅在指定工作時間（如週一至週五的辦公時間）才允許自動同步，來「凍結」高風險時段（如週五晚上和週末）的自動部署。這迫使任何非工作時間的發布都必須經過審慎的手動操作，從而將意外發布的風險降至最低。

3) 策略即程式碼：在變更落地前阻止高風險設定

• 段落重點：Git 是唯一的真相來源；利用它來拒絕那些會讓你半夜被叫醒的變更。在 Argo CD 同步之前，使用 OPA Gatekeeper 或 Kyverno 進行驗證。禁止使用 :latest 標籤、cluster-admin RBAC 權限和意外的公開服務。例如，使用 Kyverno 策略可以強制要求使用不可變的鏡像摘要或固定的標籤，並禁止創建 type: LoadBalancer 的服務。這些策略可以在事故發生之前就消除整類的風險。

  # Example Kyverno rule
  apiVersion: kyverno.io/v1
  kind: ClusterPolicy
  metadata:
    name: block-latest-and-public
  spec:
    validationFailureAction: enforce
    rules:
    - name: disallow-latest-image
      match: { resources: { kinds: ["Deployment", "StatefulSet", "Job"] } }
      validate:
        message: "Use immutable image digests or pinned tags."
        pattern:
          spec:
            template:
              spec:
                containers:
                - image: "!*:latest"

• 總結：透過整合 OPA Gatekeeper 或 Kyverno 等策略引擎，實現「策略即程式碼」。這可以在 Git 提交階段或 Argo CD 同步前，自動驗證 Kubernetes manifests，強制執行如「禁止使用 :latest 鏡像標籤」、「禁止創建公開 LoadBalancer」等安全規則，從源頭上杜絕高風險設定進入叢集。

4) 漸進式交付 + 健康閘門：安全發布，緩慢推廣

• 段落重點：「在一個 pod 上運行成功」並不是一個完整的推出策略。將 Argo CD 與 Argo Rollouts（用於金絲雀/藍綠部署）結合，並使用基於指標的健康閘門（如 Prometheus）來自動中止有問題的發布。例如，可以設定金絲雀發布策略，逐步將流量從 10% 增加到 30%，再到 100%，並在每個階段之間設定暫停時間以觀察系統指標。有了金絲雀部署和 SLO 檢查，事故會優雅地降級為一次靜默的回滾，而不是一場救火大戰。

  # Argo Rollouts example
  apiVersion: argoproj.io/v1alpha1
  kind: Rollout
  spec:
    strategy:
      canary:
        steps:
        - setWeight: 10
        - pause: { duration: 300 }
        - setWeight: 30

• 總結：單純的部署成功並不意味著服務健康。結合 Argo Rollouts 實施金絲雀或藍綠等漸進式交付策略，並設定基於 Prometheus 指標的健康閘門（health gates），可以讓系統在發布過程中自動監控服務的錯誤率或延遲。一旦指標異常，發布會自動暫停或回滾，從而將風險控制在小範圍內，避免大規模故障。

5) 安全的同步設定：謹慎對待 Prune 和重試

• 段落重點：Argo CD 的預設設定可能有點……過於激進。應該馴服它們。從保守的 syncPolicy 開始：延遲 prune（刪除資源），啟用 selfHeal（自動修復漂移），並設定合理的重試退避策略。使用 wave 和 hook 來排序變更。例如，設定 prune: false 來避免立即刪除資源，並設定重試策略，在失敗時以指數退避方式重試。較慢的同步實際上更快，因為你犯錯刪除錯誤東西的次數會更少。

  # application-api.yaml
  syncPolicy:
    automated:
      prune: false # delete only after a bake-in period
      selfHeal: true
      retry:
        limit: 3
        backoff:
          duration: 30s
          factor: 2

• 總結：Argo CD 的預設同步策略可能過於激進。應採取更保守的設定，例如將 prune 設為 false（或使用延遲刪除），以避免意外刪除資源；啟用 selfHeal 以自動修正配置漂移；並配置帶有指數退避的重試機制。同時，使用 sync-wave 註解來確保資源（如 ConfigMap 和 Secret）在應用程式部署之前被創建，保證部署的有序性。

6) 漂移控制、噪音過濾和鏡像鎖定

• 段落重點：警報疲勞會讓真正的問題變得不可見。同時，可變的標籤會在你不知不覺中發生漂移。應該使用 ignoreDifferences 來靜音已知的、由系統自動產生的欄位噪音（如 checksum 註解）。將 Argo CD Notifications 設定為僅在健康狀況下降或長時間未同步時才發出警報。使用 Argo CD Image Updater（或你的 CI）來通過摘要（digest）而不是標籤來鎖定鏡像。過濾掉無關緊要的警報，讓你的待命大腦只聽到真正重要的事情。

  # ignore noisy fields
  spec:
    ignoreDifferences:
    - group: apps
      kind: Deployment
      jsonPointers:
      - /spec/template/metadata/annotations/checksum

• 總結：為了減少警報疲勞並確保發布的確定性，必須進行精細化管理。使用 ignoreDifferences 過濾掉良性的配置漂移噪音；精簡 Argo CD 通知，只在發生實質性問題時告警；最重要的是，強制使用鏡像的摘要（digest）而非可變的標籤（tag）來進行部署，確保每次部署的鏡像是不可變且可追溯的。

整篇文章總結

這篇文章提供了一份極具實用價值的「Argo CD 安全發布手冊」，核心觀點是：穩定的 GitOps 流程不是靠事後補救，而是靠預先建立的「防護欄」（Guardrails）。

文章詳細介紹了六個關鍵的防護策略，旨在將 Kubernetes 的發布過程從一場高風險的賭博，變為一個無聊、可預測的例行公事，從而杜絕「週五晚上的緊急修復」：

1. AppProject 邊界：通過限制來源、目的地和資源類型，定義清晰的權責邊界，防止錯誤配置擴散。
2. 同步視窗：設定允許自動部署的時間窗口，將高風險的非工作時間部署轉為需要手動介入的慎重操作。
3. 策略即程式碼：利用 Kyverno/OPA 在變更應用前自動檢查，從源頭上阻止不合規（如使用 :latest 標籤）的配置。
4. 漸進式交付：結合 Argo Rollouts 進行金絲雀或藍綠部署，並以監控指標作為「健康閘門」，實現安全、可控的流量切換和自動回滾。
5. 安全的同步設定：採用保守的同步策略，如禁用立即刪除（prune）、啟用自愈（self-heal）和設定合理的重試機制，避免激進操作引發的災難。
6. 精細化控制：通過忽略良性漂移、鎖定鏡像摘要（digest）和精簡告警，減少噪音，確保發布的確定性。

總之，Argo CD 的強大之處不在於「即裝即用」，而在於其高度的可配置性。通過精心設計這些防護欄，團隊可以建立一個真正健壯、可靠且讓工程師可以安心度過週末的自動化交付系統。