deployment、replica 與 rollout

Deployment 的責任是宣告目標狀態：期望副本數、版本、更新策略。rollout 的責任是把現況收斂到目標狀態，並在過程中維持可服務能力。這兩者分開理解後，才能在異常時判斷是目標設定問題，還是收斂過程問題。

rolling update 常用來降低單次切換風險。rolling update 的判讀重點是批次大小與節奏：每批新增多少新副本、每批回收多少舊副本、每批觀察多長時間。這些參數以服務容量曲線與回退時間目標校準、名稱本身只是工具標籤、不是判讀條件。

probe 對齊服務生命週期

probe 要對齊服務生命週期，不同 probe 有不同責任：

1. startup probe：確認服務啟動完成，避免慢啟動服務被過早重啟。
2. readiness probe：確認服務可安全接流量。
3. liveness probe：確認服務仍可維持基本運作，必要時觸發重建。

probe 設計若只回傳固定成功，rollout 期間會出現「容器在線但服務未就緒」的流量抖動。穩定做法是讓 readiness 反映依賴就緒條件，例如資料庫連線池、必要配置、關鍵背景任務狀態。

Startup probe 設計注意事項

startup probe 跟 initialDelaySeconds 解決同一個問題（避免慢啟動服務被 liveness 殺掉），但機制不同。initialDelaySeconds 是 liveness / readiness probe 的延遲啟動——在等待期間 probe 完全不跑，無法觀測啟動進度。startup probe 在啟動期間持續探測，一旦成功就交棒給 liveness / readiness，啟動失敗時能更快偵測到。

startup probe 的總容忍時間 = failureThreshold × periodSeconds。例如 failureThreshold: 30, periodSeconds: 10 給服務 300 秒啟動窗口。設計時先量測服務在最差情境下的啟動時間（冷啟動 + image pull + 依賴連線建立），再加 20-30% headroom 作為總容忍時間。

Readiness probe 的深度選擇

readiness probe 的檢查深度決定它能攔截多少「可啟動但不可服務」的狀態。三個常見層級：

1. Port check（TCP probe）：確認進程在監聽。最淺，無法偵測依賴未就緒。適合依賴簡單、啟動快的服務。
2. Dependency check（HTTP endpoint 檢查必要依賴）：確認資料庫連線池、cache 連線可用。涵蓋多數「啟動完但依賴不通」的場景。常用做法是在 /ready endpoint 內驗證必要依賴的連線狀態。
3. Deep health（業務路徑驗證）：執行一次簡化的業務查詢確認端到端通路。最深但代價最高——probe 本身消耗資源，且可能被下游延遲拖慢導致 readiness 抖動。

依賴分類（必要 / 可降級 / 觀測）的判讀框架見 5.6 Readiness 設計的核心取捨。

config rollout 與版本相容

Config Rollout 需要和應用版本一起治理。設定先行、版本後行，或版本先行、設定後行，都要保留相容窗口。相容窗口存在時，才有漸進 rollout 與快速回退空間。

跨版本配置遷移要先定義停止條件：錯誤率上升、延遲尖峰、關鍵路徑失敗或下游壓力超標。停止條件明確後，部署決策才能一致。

N-1 相容與 Feature Flag Gating

版本相容窗口的操作基線是 N-1 相容：版本 N 的程式碼可以處理版本 N-1 的設定，反之亦然。這讓 rollback 從「版本 + config 必須同時回退」降級成「版本先回退、config 稍後再處理」，回退操作的原子性要求降低。

N-1 相容的實作通常搭配 feature flag gating：新功能在程式碼中預設關閉，先部署程式碼（版本 N 上線但新功能 off），確認版本穩定後再開啟 feature flag。這讓版本部署跟功能啟用分成兩個獨立決策，rollback 時只需關 flag 而不必回退版本。

N-1 相容窗口的壽命要有明確終點。長期維護雙版本相容會累積技術債——舊欄位不能刪、舊路徑不能移除。穩定做法是在 rollout 完成 + 觀測確認穩定後設定移除 deadline，把 N-1 相容視為暫時性保護而非永久設計。設定注入方式與版本追蹤見 5.1 配置注入方式與取捨。

Autoscaling 與部署策略協同

autoscaling 在部署期間扮演容量緩衝角色。部署批次若超過服務可承受變動幅度，autoscaling 會被動補償並延長收斂時間。穩定做法是讓 rollout 節奏與容量策略同時設計：先保證服務穩態，再提高切換速度。

長連線服務或有大量背景任務的 workload，通常需要比 stateless API 更保守的 rollout 策略，並額外搭配 drain 與 reconnect 設計。

擴縮策略的演進需要版本化跟可回放。對應 5.C6 Airbnb K8s 叢集擴縮演進：揭露「擴縮策略版本化跟可回放」「不同 workload 區分擴縮政策」「容量治理跟事故指標綁定」三個方向。以下基於通用工程知識展開。

可重複套用的做法：

1. 擴縮策略進 IaC：HPA / VPA / Karpenter / Cluster Autoscaler 的配置都進 git、變更走 release flow、避免手動調整在事故後被遺忘。IaC + 自動化的 ownership 邊界見 [5.7 control plane boundary](/backend/05-deployment-platform/traffic-config-control-plane-boundary/)。
2. workload 分群擴縮：stateless API、長連線服務、batch job、background worker 對擴縮的需求不同。把不同 workload 用不同 namespace + 不同 autoscaler policy 隔離，避免一套規則套全部。
3. 擴縮事件接事故指標：HPA 觸發、scale-up 延遲、scale-down 過快、cluster autoscaler 加 node 失敗，都該在事故 timeline 上可見。回到 4.13 service topology 的擴縮事件 vs 事故區分。

分階段平台遷移

平台遷移的本質是流量跟依賴的分段切換。遷移期內新舊叢集同時存在，rollout 策略要把跨叢集流量切換納入批次節奏、視為連續多批決策。本段聚焦流量 / 依賴切換時序；遷移期的團隊職責邊界重訂見 5.7 Managed 平台跟團隊職責邊界。

對應 5.C1 Tradeshift：self-managed K8s → EKS：揭露「零停機遷移要把切換做成分段策略」「難點通常在跨叢集服務依賴跟流量切換、不在 Kubernetes API 本身」。對應 5.C4 Mobileye workloads 遷移：揭露「分批遷移 workload、保留觀測對照」「明確切換 / 回退條件」「新平台先驗證容量跟恢復節奏」。以下基於通用工程知識展開。

可重複套用的分階段做法：

1. 新叢集 + 共通配置基線：先在新叢集上建立跟舊叢集對等的配置基線（namespace、ResourceQuota、NetworkPolicy、Ingress class、storage class），讓 workload 可以無縫部署。
2. 小流量先導服務：選擇影響面小、依賴單純的服務作為先導，先在新叢集跑完整 deployment cycle（rollout、drain、rollback 驗證）、累積信心後再擴大。
3. 可控流量分批切換：用 DNS 加權、service mesh 流量切分或 LB 規則把流量分批從舊叢集導到新叢集。每批切換後驗證 SLI 偏差、再進下一批。
4. 每批保留回退路徑：舊叢集服務不立即下線，保留作為回退目標。回退條件先驗證（rollback script、流量切回 DNS / LB 規則），再開始下一批切換。

延伸 5.C1 揭露的「跨叢集服務依賴是難點」、5.C10 中型組織判讀「服務本身切過去了、但資料面、認證面、觀測面還沒同步」也指向同類問題。跨叢集遷移最容易出的事故是「服務切過去了、依賴沒切過去」。Database、cache、message queue、observability pipeline、auth service 的切換時機要分別規劃，避免應用層在新叢集但仍跨網路打舊叢集的依賴，造成隱性 latency 或單點失效。規模差異下的同類問題見 5.C10 對照。

大規模 K8s 的設計取捨

K8s 在不同規模下的設計取捨會明顯分歧。小規模叢集追求簡單跟低運維成本，大規模叢集追求隔離跟自動化治理。同一套部署策略放到不同規模會在某個量級開始失效。

對應 9.C12 Riot Games：246 個 EKS cluster：揭露架構決策從 multi-tenant cluster 改成 single-tenant per game、Karpenter + Terraform 的 cluster 級自動化、35ms 延遲門檻 + Local Zones / Outposts 區域部署（case 中「35ms 反推 region 部署」屬作者判讀層、本章引用此推論）。對應 9.C34 GCP 130,000-node GKE cluster：揭露 control plane 極限取決於 storage backend（GCP 用 Spanner 替代 etcd）、AI workload 跟 web workload 容量規劃差異。對應 9.C33 Maersk + Bosch AKS：揭露 Maersk 工程訴求引語「focus on things that makes the most business impact」、傳統產業上 K8s 動機是治理一致性（作者判讀）、適合 single-cluster-multi-namespace。

可重複套用的取捨判讀：

1. single-tenant per workload vs single-cluster multi-namespace：高隔離需求（每個 workload 失效不能影響其他）、高延遲敏感度（需 region cluster）→ 多 cluster；治理一致性訴求（統一 release flow、合規邊界）→ 單一 cluster 多 namespace。
2. Cluster 容量極限取決於 control plane：data plane（worker nodes）擴容容易、control plane（API server、etcd / storage）擴容難、瓶頸通常在 control plane。etcd 撐 5K-10K node 後吃力、需要替換 storage backend（Spanner / PostgreSQL / 自家 KV）才能撐萬級節點（見 9.C34）。control plane 的 ownership 邊界由 5.7 control plane boundary 處理。
3. Multi-cluster 治理需要 IaC + 自動化：Terraform / Crossplane / Cluster API + Karpenter / Cluster Autoscaler 是基本工具。手動管理超過數十個 cluster 不可行。
4. AI workload 跟 web workload 容量規劃完全不同：AI workload 短時間爆量創建 Pods（萬級 / 秒）、preempt 頻繁；web workload 節點生命週期長、變動緩。把 web 經驗套到 AI workload 容量規劃會嚴重低估壓力。

關鍵判讀是「先決定 cluster 是隔離單位還是治理單位」。Riot Games 把 cluster 當隔離單位（246 個獨立 cluster），Maersk / Bosch 把 cluster 當治理單位（單 cluster 多 namespace）。同一個工具兩種用法、決定整體運維模型。

對應 5.C2 Condé Nast：EKS 平台整併與標準化：揭露多叢集整併到單一控制面的場景、跟 Maersk-Bosch 同屬「治理一致性」取捨方向（治理單位優先於隔離單位）。Condé Nast 的整併路徑是「盤點既有叢集差異 → 建立統一平台基線 → 藍綠或漸進切換業務流量」、對應前面「分階段平台遷移」段的批次節奏。

判讀訊號

常見誤區

把 Kubernetes 部署看成 YAML 套版，會忽略服務語意差異。相同 deployment 參數在不同服務上，可能代表完全不同風險。

把 probe 當成健康檢查 URL，會讓服務在邊界條件下過早接流量。probe 的工程價值在於反映服務真實可用條件。

把 cluster scale-up 想成「加 node 就好」也是常見誤判。當 cluster 規模超過 control plane 預設邊界，etcd / API server 會先撐不住，加 node 反而加重 control plane 負擔。

案例回寫

部署切換語意可用 5.C9 反例 做回寫。先看事件中的失敗是在 rollout 批次、probe 判斷、還是 drain 時序，再對照本章的 rollout 節奏與停止條件。

這個案例主要支撐的是「部署批次與切換時序」判讀，不直接支撐資料庫交易切分或 consumer 冪等；若問題落在提交一致性或重播補償，應轉到 1.3 或 3.4。

若版本已切換但錯誤率延遲上升，先回到 probe 與 config 相容窗口，再把證據欄位接到 4.20 Observability Evidence Package 與 8.19 Incident Decision Log。

跨模組路由

Kubernetes 部署策略要和觀測、驗證、事故流程同時對齊。

1. 與 5.6 的交接：startup / readiness / liveness / drain 的生命週期定義回到 Platform Lifecycle Contract。
2. 與 5.1 的交接：image、entrypoint、resource limit 的 runtime 層回到 container 與 runtime。
3. 與 5.3 的交接：流量承接與退出落在 load balancer 合約。
4. 與 5.4 的交接：endpoint 註冊與摘除回到 service discovery。
5. 與 5.7 的交接：control plane 跟 data plane 邊界落在 Traffic、Config 與 Control Plane Boundary。
6. 與 4.20 的交接：版本切換證據進入 Observability Evidence Package。
7. 與 6.8 的交接：放行與停損條件進入 Release Gate。
8. 與 8.19 的交接：部署中止與回退判斷進入 Incident Decision Log。

下一步路由

要把部署與流量切換一起治理，接著讀 5.3 load balancer 合約。要看切換失敗與回退判讀，接著讀 5.C9 反例。要看大規模 K8s 容量設計，接著讀 9.C12 Riot Games 跟 9.C34 GCP 130K-node。

服務定位

cert-manager 的核心責任是 K8s cluster 內所有 cert 的生命週期治理。從 Ingress / Gateway 對外 TLS、internal service mTLS、到 workload-level 短期 cert、都用同一套 declarative model 表達。Issuer 抽象讓底層 cert 來源可換 — 公開 cert 走 Let’s Encrypt ACME、內部 cert 走 Vault PKI engine 或 self-signed CA、企業環境走 Venafi 或 AWS PCA — 上層 Certificate spec 不變。

跟 AWS ACM 的差異是 cert 的部署面：ACM 是 AWS-managed cert、只能掛在 AWS service（ELB / CloudFront / API Gateway）、私鑰永不離 AWS；cert-manager 是 K8s-native client、cert 放在 cluster 內的 Secret、可以掛任何 ingress controller 或 workload mTLS。跟 Let’s Encrypt 的關係是 client vs issuer — cert-manager 是 ACME client、Let’s Encrypt 是 ACME server、不是替代關係。跟 SPIRE 的差異是 身份模型 — cert-manager 給 DNS-named cert（CN / SAN 是 hostname）、SPIRE 給 SPIFFE ID-based workload identity（spiffe://trust-domain/workload）、兩者互補不衝突。

本章目標

讀完本頁、讀者能判斷：

1. cert-manager 用 Issuer / ClusterIssuer 哪個、配什麼 issuer backend（Let’s Encrypt / Vault PKI / self-signed / 公司 CA）
2. Challenge solver 選 HTTP01 還是 DNS01、為什麼 wildcard cert 必須用 DNF01
3. Auto-renewal 觸發點、renew 失敗的 alert 時機、跟 Ingress / Gateway API 整合的 annotation
4. 何時用 cert-manager、何時改走 ACM（雲端原生 service）或 SPIRE（workload identity）

最短判讀路徑

判斷 cert-manager 部署是否健康、最少看四件事：

• Issuer 配置：是 ClusterIssuer（cluster-wide）還是 Issuer（namespace-scoped）、backend 是哪一種（acme / vault / ca / venafi）、credential（ACME private key、Vault token、CA cert）放哪、RBAC 限制誰能參考這個 issuer
• Certificate spec：dnsNames / ipAddresses 跟實際 service 一致、duration 跟 renewBefore 比例合理（renewBefore >= duration / 3）、secretName 指向的 Secret 是不是 ingress 真的會讀的那個
• Renewal 觸發：controller log 有沒有按時觸發 renew、kubectl describe certificate 的 Renewal Time 接近沒、Challenge resource 沒有卡在 pending
• Challenge solver：HTTP01 的 ingress / Gateway 80 port 真的能被 Let’s Encrypt 從 Internet 打到、DNS01 用的 cloud provider credential 還有效、wildcard cert 沒誤用 HTTP01

四件事任一缺失、cert 就會在不知不覺中過期、production 看到 x509: certificate has expired 才驚覺、是 Transport Trust and Certificate Lifecycle 的典型缺口。

日常操作與決策形狀

Issuer vs ClusterIssuer 的選擇：Issuer 是 namespace-scoped、只能 issue 該 namespace 的 cert、適合 單 team 自管 issuer credential 的場景；ClusterIssuer 是 cluster-wide、所有 namespace 都可以參考、適合 平台 team 統一管理 issuer。production 通常用 ClusterIssuer 配特定 issuer backend + RBAC 收 Certificate 建立權（讓 application team 只能在自己 namespace 建 Certificate、不能改 ClusterIssuer）。

Certificate spec 設計：dnsNames 列出該 cert 涵蓋的 hostname（支援 wildcard *.example.com）、ipAddresses 加 IP SAN（mTLS 跨 service 常用）、duration 是 cert 有效期、renewBefore 是提前多久 renew（預設 duration 的 1/3）。短期 cert（hours-level、Vault PKI 常用）配 renewBefore 短、長期 cert（90 天、Let’s Encrypt）配 renewBefore 30 天。secretName 指向 cert-manager 會寫入的 Secret、Ingress 跟 workload 從這個 Secret 讀。

Challenge solver 的選擇：ACME issuer（Let’s Encrypt）需要證明 你控制這個 domain、有兩個方法：HTTP01（在 http://yourdomain/.well-known/acme-challenge/<token> 放檔案、Let’s Encrypt 從 Internet 來抓）跟 DNS01（在 DNS zone 加 _acme-challenge.yourdomain TXT <token> record、Let’s Encrypt 查 DNS）。wildcard cert（*.example.com）必須用 DNS01、HTTP01 不支援 wildcard 因為 Let’s Encrypt 不知道要打哪個 subdomain。HTTP01 要求 ingress controller 80 port 對 Internet 開放、DNS01 要求 cluster 有 cloud DNS API credential。

Auto-renewal 機制：cert-manager 在 cert lifetime 達到 (duration - renewBefore) 時間時觸發 renew、預設約 lifetime 2/3 點。Let’s Encrypt cert 90 天 = 60 天時開始嘗試 renew、留 30 天緩衝給 renew 失敗的重試。renew 失敗會持續重試（exponential backoff、最長 8 小時間隔）、剩下 ~7 天時 controller log 開始 ERROR 級別 alert — 監控要 hook 進這個 log 訊號、否則 cert 真的過期才知道就太晚。

跟 Ingress 整合：Ingress resource 加 annotation cert-manager.io/cluster-issuer: letsencrypt-prod（或 cert-manager.io/issuer:）、cert-manager 看到 Ingress 的 tls.hosts 自動建立對應 Certificate、issue 完寫進 tls.secretName 指定的 Secret、ingress controller 自動 reload 用新 cert。Gateway API 的整合機制類似、用 cert-manager.io/issuer annotation 在 Gateway resource。

CertificateRequest Approval Policy（v1.4+）：每個 Certificate 建立會產生 CertificateRequest、由 Approver 決定要不要送給 issuer。預設 cert-manager 內建 approver 自動 approve、但可以加 admission policy（Kyverno / OPA / 自寫 webhook）限制「誰能在哪個 namespace 建什麼 SAN 的 cert」— 防 internal compromise 任意 issue cert 對外冒名。production 環境通常會在 platform-level 鎖 wildcard cert、防 application team 誤建涵蓋整個 zone 的 cert。

核心取捨表

選 cert-manager 的核心訴求：cluster 內 cert 跨 issuer 統一管理 + 自動 renew + 跟 Ingress / Gateway declarative 整合。如果 cert 完全給 AWS service 用、不進 K8s workload、ACM 更簡單（不用裝 controller、AWS 自動處理）。如果是非 K8s 環境（VM、bare-metal Nginx）、certbot + cron 仍是合理選擇、不需要為了 cert 跑 K8s controller。

進階主題

DNS01 challenge 跟 cloud DNS 整合：cert-manager 支援多家 cloud DNS provider 作為 DNS01 solver — Route53、Cloud DNS（GCP）、Azure DNS、Cloudflare、ACMEDNS（自管 DNS proxy）。每個 provider 需要 DNS zone 寫入 credential（IAM role、service account key、API token）— 這份 credential 等於 任意改該 zone DNS record 的權力、blast radius 大、要走 least privilege 限定到 specific zone + 只給 TXT record write、不要全 zone 全 record type。

跟 Vault PKI engine 整合：cert-manager 可用 Vault PKI engine 作為 issuer backend — 在 cluster 內建 Issuer / ClusterIssuer type 為 vault、指向 Vault address + PKI mount path + auth method（Kubernetes auth / AppRole）。每張 cert 的 issue / revoke 都進 Vault audit log、跟 secret rotation 用同一套 evidence chain（呼應 Credential Rotation Scoped Evidence）。typical 用法：short-lived workload mTLS cert（hours-level duration、minutes-level renewBefore）、靠 Vault PKI 短期 cert + cert-manager 自動換。

跟 SPIRE 的互補：cert-manager 自動更新 cert、但 cert 是給人讀的 DNS name；SPIRE 自動建立 workload identity、identity 是 SPIFFE ID。兩者解不同問題 — cert-manager 解「Ingress / external API 的 TLS」、SPIRE 解「service A 要怎麼證明自己是 A 給 service B 看」。production 環境常 並存：edge cert 跟 user-facing TLS 用 cert-manager + Let’s Encrypt、internal service mesh 用 SPIRE + SPIFFE。

Trust bundle 管理（trust-manager）：trust-manager 是 cert-manager 姐妹專案、解決 trust anchor（root CA bundle）跨 namespace 同步 問題。傳統做法是每個 pod ConfigMap 各自塞 CA bundle、更新時要逐個改；trust-manager 提供 Bundle resource 一處定義、自動 distribute 到指定 namespace 的 ConfigMap。對應 cert rotation 跟 CA rotation 是兩條獨立 chain、後者是 trust-manager 的領域。

排錯與失敗快速判讀

• Challenge 卡在 pending：HTTP01 卡 = ingress 80 port 沒對 Internet、firewall / NLB 沒開、redirect 80→443 把 challenge 也轉了；DNS01 卡 = DNS provider credential 過期、IAM 沒 zone write 權、_acme-challenge record 沒寫進去 — kubectl describe challenge 看 reason
• Wildcard cert 用 HTTP01：申請失敗 + log 寫 “wildcard not supported with HTTP-01” — 改 DNS01 solver
• renewBefore 太短：renew 失敗只剩幾天才 alert、實際過期前來不及處理 — renewBefore 至少 duration / 3、production cert 給 30 天
• Secret 沒被 ingress 讀到：Certificate 已 Ready 但 ingress 還用舊 cert — ingress tls.secretName 拼錯、ingress controller 沒 reload、TLS handshake 用的 SNI 沒匹配
• ACME rate limit 撞牆：Let’s Encrypt rate limit 每週同 domain 50 cert / 同 account 300 pending — 反覆建錯 Certificate 重 issue 會撞、staging environment 用 letsencrypt-staging issuer 測過再上 prod
• ClusterIssuer 被 application team 誤改：沒設 RBAC、任何 namespace 都能 patch ClusterIssuer — 用 admission policy 鎖 ClusterIssuer 變更權給 platform team
• Approval Policy 缺失：任何 namespace 能建 wildcard cert、internal compromise 拿到 K8s API token 就能 issue 假冒 cert — 上 CertificateRequest Approval Policy + Kyverno / OPA rule

何時改走其他服務

不在本頁內的主題

• cert-manager Helm chart 的所有 value 細節跟版本相容性矩陣
• 每個 issuer backend 的完整 schema（acme / vault / venafi / ca / selfSigned）
• Gateway API 跟 Ingress API 的 cert-manager annotation 完整對照
• ACME RFC 8555 protocol 細節（HTTP01 / DNS01 / TLS-ALPN-01 challenge mechanism）
• trust-manager 的 Bundle source 種類（inMemory / secret / configMap / defaultPackage）

案例回寫

cert-manager 在 07 案例庫沒有直接 vendor-level 事件、以下案例採對照引用：

下一步路由

• 上游：7.6 秘密管理與機器憑證治理、Transport Trust and Certificate Lifecycle
• 平行：Let’s Encrypt（ACME issuer）、AWS ACM（AWS-managed cert）、SPIRE（workload identity）
• 下游：HashiCorp Vault（PKI engine 作為 issuer backend）
• 跨模組：8 事故處理 vendor 清單（cert 過期 / mis-issue 事件如何 routing）
• 官方：cert-manager Documentation

本文是 Kubernetes overview 的 implementation-layer deep article。Overview 已說明 K8s 在 deployment platform 譜系的定位、本文聚焦 pod termination 這個 production 最常踩、被誤解最深的議題：序列、配置、五個 case、跟 service mesh 整合。

Graceful shutdown 沒做對、500 期間每次 deploy 都吃 502

最常見的觸發場景：deploy 新 image、prometheus alert 在 5 分鐘內收到一波 502 / 503、SRE 翻 application log 看到「正在處理 request」「connection closed」交替出現。Application 本身沒 bug、但 K8s 在 pod terminate 時跟 traffic 來源 沒對齊步調、舊 pod 還在處理請求時就被 SIGKILL、新 request 還在打到準備關閉的 pod 上。

很多團隊修法是 把 terminationGracePeriodSeconds 從 30 拉到 120、暫時掩蓋問題；但症狀會在下次 rolling update / HPA scale-down / node drain 時換個形式回來。根因在 termination 序列 — pod 不是收到 SIGTERM 就 graceful、序列裡每一步出錯都有不同 fail mode。

Termination 序列：五步、每步都能爆

K8s 收到 delete pod 請求後、發生的事 按時間 是：

關鍵誤解：

1. 「pod 從 Service 移除」跟「container 收到 SIGTERM」是 平行、不是序列。Endpoint controller 更新 Endpoints object → kube-proxy 重新寫 iptables → 各 node 的 traffic 才真正停 — 這條鏈通常需要 1-5 秒；同時間 SIGTERM 已經發給 application。

2. preStop hook 是「container 還在跑、SIGTERM 還沒發」期間執行。pre-Stop 設 sleep 10 是 production 標準作法 — 用 sleep 讓 endpoint controller 有時間把 pod 從 Service 移除、避免 SIGTERM 期間還有新 request 進來。

3. terminationGracePeriodSeconds 是 從 preStop 開始 計時、不是從 SIGTERM。preStop sleep 10s + application 30s graceful = 至少要設 40s。

4. graceful 不是 framework 自動的。Application 必須 主動處理 SIGTERM：拒絕新 request、等 in-flight 完成、close DB connection、flush log。沒處理 SIGTERM、container 會在 grace period 後被強殺。

5. readiness probe 在 Terminating 期間 仍會被執行、但結果不影響 traffic（已經從 Endpoints 移除）。但若 application 沒主動讓 readiness fail、service mesh / external LB 可能仍在送 request（依不同 mesh 行為）。

配置全圖

Deployment spec

 1apiVersion: apps/v1
 2kind: Deployment
 3spec:
 4  template:
 5    spec:
 6      terminationGracePeriodSeconds: 60          # SIGTERM 後 60s 才 SIGKILL
 7      containers:
 8        - name: app
 9          lifecycle:
10            preStop:
11              exec:
12                command: ["/bin/sh", "-c", "sleep 10"]
13          readinessProbe:
14            httpGet:
15              path: /healthz/ready
16              port: 8080
17            periodSeconds: 5
18            failureThreshold: 2

時序：t=0 preStop 開始 sleep 10s → t=10s container SIGTERM → t=70s SIGKILL（不是 t=60s、是 60s after SIGTERM）。

Application 處理 SIGTERM（Go 範例）

 1sigs := make(chan os.Signal, 1)
 2signal.Notify(sigs, syscall.SIGTERM)
 3
 4server := &http.Server{Addr: ":8080"}
 5go server.ListenAndServe()
 6
 7<-sigs                                              // 等 SIGTERM
 8log.Println("SIGTERM received, draining...")
 9
10// 1. readiness fail（讓 mesh-aware 流量停）
11ready.Store(false)
12
13// 2. wait 5s 讓 readiness probe failureThreshold 觸發
14time.Sleep(5 * time.Second)
15
16// 3. graceful shutdown server（拒新請求、等 in-flight）
17ctx, cancel := context.WithTimeout(context.Background(), 45*time.Second)
18defer cancel()
19server.Shutdown(ctx)
20
21// 4. close DB / cache / message consumer
22db.Close()
23consumer.Stop()
24
25// 5. flush log + exit
26logger.Sync()

關鍵：server.Shutdown(ctx) 是 拒新請求、等 in-flight、ctx timeout 設 grace period 減去 preStop sleep 跟 readiness fail 等待時間（60s - 10s - 5s = 45s）。

Production 故障演練

Case 1：Rolling update 期間 502 / 503

徵兆：每次 deploy 後 5 分鐘內 LB / ingress log 一波 502 / 503、application log 顯示「context canceled」「connection closed by peer」、新 pod 已 ready 但舊 pod 在 grace period 內仍收 request。

根因：沒設 preStop sleep、container 收到 SIGTERM 後立刻 server.Shutdown()、但 kube-proxy 還沒把舊 pod 從 iptables 移除、新 request 持續送到舊 pod、舊 pod 已拒收。

修法：preStop sleep 10、讓 endpoint propagation 完成再進入 SIGTERM 流程。

Case 2：Connection drain race，long-running request 被中斷

徵兆：deploy 後 application log 有大量 context canceled 對應到 long-running endpoint（例：報表生成、檔案上傳）、user 端看到 transaction 失敗、但短 request 沒事。

根因：long-running endpoint 處理時間 > terminationGracePeriodSeconds、server.Shutdown(ctx) ctx timeout 設太短、in-flight 強制中斷。

修法：

1. 把 long-running endpoint 改 async（背景 job + status endpoint）、HTTP request 立刻 return job ID
2. 短期：terminationGracePeriodSeconds 拉到 long-running 99 percentile + buffer
3. application 側 ctx timeout = grace period - preStop - readiness fail wait

Case 3：Init container 在 grace period 期間重啟、SIGTERM 沒到 main

徵兆：pod 顯示 Terminating 但 phase 一直在 Running、main container restart count + 1、application log 沒看到「SIGTERM received」。

根因：init container 用 restartPolicy: Always（K8s 1.28+ sidecar 模式）、或 main container 在 SIGTERM 前先 crash 觸發 restart、kubelet 在 restart 後 不重發 SIGTERM、main container 跑到 grace period 結束直接 SIGKILL。

修法：

1. Sidecar container（restartPolicy: Always）的 preStop 也要設 sleep、跟 main 同 lifecycle
2. main container readinessProbe 失敗時 別自動 restart（restartPolicy: OnFailure + crashLoopBackOff 觀察）
3. 觀察 kubectl describe pod 的 events、SIGTERM 沒發出來會有 Killing container event 缺失

Case 4：StatefulSet 串行終止、總時間 = pod 數 × grace period

徵兆：StatefulSet rolling update / scale-down 比 Deployment 慢 N 倍（N = replica 數）、deploy 一個 5 replica 的 statefulset 要 5 分鐘以上。

根因：StatefulSet 預設 podManagementPolicy: OrderedReady — pod 串行終止 + 串行創建、每個 pod 至少要 grace period 完成才動下一個。Deployment 用 RollingUpdate 預設 maxUnavailable=25% 平行終止。

修法：

1. StatefulSet 改 podManagementPolicy: Parallel（若 application 不要求嚴格順序）
2. 嚴格順序情境（Cassandra / Kafka / etcd）保留 OrderedReady、但 grace period 設 單 pod 必要時間、不要設 總時間能承受
3. 接受序列化代價、把 deploy 排在低流量時段

Case 5：Job / CronJob 不 graceful、SIGTERM 直接 SIGKILL

徵兆：CronJob 在 Job timeout / pod eviction 時不 graceful、寫一半的 file 留在 PVC、下次跑時 corrupt；application log 沒「SIGTERM received」、直接斷。

根因：Job 的 activeDeadlineSeconds 到期 / node eviction 觸發時、K8s 對 Job pod 仍會發 SIGTERM、但 很多 batch framework（Spring Batch / Argo Workflow worker）沒處理 SIGTERM、application 沒主動 checkpoint。

修法：

1. Batch application 處理 SIGTERM、checkpoint 進度寫 storage、下次跑時 resume
2. 不適合 checkpoint 的 batch、保證 idempotent re-run、SIGKILL 後重跑不會 corrupt
3. Job spec 加 terminationGracePeriodSeconds（預設 30、batch 通常要 60-300）

規模影響

Graceful shutdown 的成本主要在 deploy 時間 跟 capacity buffer：

實務 default：

• Web service：terminationGracePeriodSeconds: 60、preStop sleep 10、application graceful 45s
• Backend worker（消費 queue）：terminationGracePeriodSeconds: 120、preStop 不 sleep（用 readiness 控）、application 處理當前 message + commit offset
• Batch job：terminationGracePeriodSeconds: 300、checkpoint pattern
• StatefulSet（DB / queue）：grace period 對齊 vendor 建議（Kafka 90s、PostgreSQL 60s）

跟其他元件整合

Service mesh（Istio / Linkerd）

Service mesh sidecar（envoy / linkerd-proxy）也有自己的 termination — 通常比 main container 晚一點關。配置原則：

1. mesh sidecar 設 terminationGracePeriodSeconds 比 main 多 5-10s、main 處理完才換 sidecar
2. Istio 1.12+ 的 proxy.istio.io/config.holdApplicationUntilProxyStarts 控啟動順序、shutdown 也要對應
3. mTLS 環境 graceful 多一道：在 SIGTERM 後等 mesh 主動 close cert rotation、不要硬斷

Readiness probe 跟 mesh-aware traffic

純 K8s Service（kube-proxy iptables）：endpoint 移除後 已建立 connection 仍會跑完、新 connection 不來。Mesh-aware traffic（service mesh / external LB with health check）：要 readiness fail 才會停送。

修法：application graceful 第一步是 ready.Store(false) + 等 readiness probe 至少 fail 一次（5-10s）、才開始 server.Shutdown。

跟 Pod Disruption Budget（PDB）的衝突

Node drain 時 PDB 限制可同時 unavailable 的 pod 數、graceful shutdown 拖長會讓 drain 卡住。對策：

1. 緊急 drain（node 硬體故障）：kubectl drain --grace-period=30 --force、接受短時間 502
2. 正常 drain（升級 / 維運）：PDB 設 minAvailable: <replicas-1>、容許單 pod 慢慢 graceful
3. 不要設 maxUnavailable: 0、會讓 drain 卡死

下一步

• Application graceful 寫法：12-factor app disposability 章節給 framework-agnostic 模板、各語言 SDK 寫法見對應 framework
• Queue consumer 的 graceful：訊息 ack / offset commit 必須在 SIGTERM 內完成、否則 duplicate message — 對應 03 message queue 模組的 consumer-design 段
• 跨 region / 多 cluster 的 graceful：multi-cluster service mesh（Istio multicluster / Linkerd multicluster）的 traffic shift 期間 graceful 行為跟單 cluster 不同、需要對齊 mesh 配置

相關連結

• 上游 vendor 頁：Kubernetes
• 上游 chapter：5.X deployment-rollout-drain-rollback
• 對照案例：rolling update 期間 502 多見於 stage-3 mesh adoption case 庫
• 平行 deep article：pgBouncer 配置 / Vault Dynamic Credential
• Methodology：Vendor 深度技術文章的寫作方法論

本文是跨 vendor migration playbook、cross-link Docker Swarm 跟 Kubernetes。跑 migration-playbook-methodology 6 維 audit 後對映 Paradigm = High（Swarm 簡單 container orchestration → K8s declarative resource model）→ Type E paradigm shift。

5 個 Swarm production cluster 撞牆數據

從 2020-2024 觀察 5 個中型 organization 的 Swarm production cluster lifecycle、典型撞牆點：

5 個共同 pattern：

• Swarm 簡單但 ceiling 100-200 service / 20-40 node
• 跨 service 治理（mesh / RBAC / secret / autoscale）需要 外掛 工具、複雜度反超 K8s
• 無 multi-region native、災備受限
• 生態縮、社群活躍度低、新 feature 緩

撞牆點不是「Swarm 跑不動」、是「Swarm 不會幫你解 跨 service 治理 問題、要自寫」。Kubernetes 不是 simpler、是 把治理問題納入框架。

為什麼遷：ceiling / ecosystem / multi-region 三條 driver

反向 driver（K8s → Swarm）：

• 純 internal tool / 小規模（< 30 service）、K8s 過度複雜
• Edge / IoT scenario、Swarm footprint 小

6 維 audit

Schema + Paradigm 雙 High → Type E paradigm shift 為主、Schema 高維獨立段。

Paradigm 對位

Schema gap：docker-compose vs K8s YAML

 1# Docker Swarm stack.yml
 2version: '3.8'
 3services:
 4  webapp:
 5    image: myapp:1.0
 6    deploy:
 7      replicas: 3
 8      update_config:
 9        parallelism: 1
10      restart_policy:
11        condition: on-failure
12    networks:
13      - frontend
14    ports:
15      - "8080:8080"

 1# K8s equivalent (Deployment + Service + Ingress)
 2apiVersion: apps/v1
 3kind: Deployment
 4metadata:
 5  name: webapp
 6spec:
 7  replicas: 3
 8  strategy:
 9    type: RollingUpdate
10    rollingUpdate:
11      maxSurge: 1
12      maxUnavailable: 0
13  selector:
14    matchLabels: { app: webapp }
15  template:
16    metadata:
17      labels: { app: webapp }
18    spec:
19      containers:
20        - name: webapp
21          image: myapp:1.0
22          ports:
23            - containerPort: 8080
24          readinessProbe:
25            httpGet:
26              path: /healthz
27              port: 8080
28          resources:
29            requests:
30              cpu: 100m
31              memory: 128Mi
32            limits:
33              cpu: 500m
34              memory: 512Mi
35---
36apiVersion: v1
37kind: Service
38metadata:
39  name: webapp
40spec:
41  selector: { app: webapp }
42  ports:
43    - port: 8080
44      targetPort: 8080

1 Swarm service → 2-3 K8s resource（Deployment + Service + 可能 Ingress / HPA）；application 不改但 deployment 端工作量 5-10x。

Migration 流程

Partial migration + 混合架構

跟 Kafka ↔ NATS / etcd → Consul 同 Type E pattern：

 11. Audit application：列所有 Swarm stack + service
 22. 分類處理 plan:
 3   - 簡單 stateless: 先切 K8s (低風險)
 4   - Stateful (DB / queue): 評估 K8s operator 或保留 Swarm
 5   - Critical service: 雙跑期確認 K8s 行為對等
 63. K8s cluster 建置:
 7   - Managed (EKS / GKE / AKS) vs self-host (kubeadm)
 8   - 配 ingress controller / cert-manager / monitoring
 94. Application 遷移 (per stack)
10   - 寫 K8s YAML / Helm chart
11   - 配 readiness/liveness probe / resource request
12   - Networking + secret 對位
135. Cutover + Swarm decommission
14   - 部分 stack 切完、評估 Swarm 是否保留 (legacy / edge)
15   - 多數 organization 完全 decommission Swarm

整體 3-6 個月、依 stack 數量跟 application 複雜度。

Production 故障演練

Case 1：Networking model 差、cross-service connectivity 失效

徵兆：cutover 後 service A 連 service B 失敗、Swarm 端 tasks.service_b DNS 對位 K8s 端 service-b.namespace.svc.cluster.local 不通。

根因：Swarm overlay network 內 service-to-service 用 short name (service_b)、K8s 用 FQDN；application 端 service URL 寫死。

修法：

1. Application 端用 short name + cluster DNS search domain
2. K8s 端設 dnsPolicy: ClusterFirst 預設、確認 kubectl get svc -A 對應
3. NetworkPolicy 預設 deny-all、明示 allow rule

Case 2：Secret rotation 從 Swarm secrets 換 Vault / Secrets Manager

徵兆：原本 Swarm 用 docker secret 旋轉 secret、切 K8s 後 K8s Secret 是 static value、rotation 不自動。

根因：K8s Secret 是 K8s-native 但 not auto-rotated、需要外部 Vault / Secrets Manager + agent (vault-agent-injector / external-secrets-operator)。

修法：

1. K8s 端 deploy external-secrets-operator + AWS Secrets Manager / Vault integration
2. Application 端 mount file or env variable、不在 code 寫死
3. Rotation 走 vendor-side、K8s 端 sidecar 自動 reload

Case 3：Readiness probe 沒設、rolling update 期間 traffic loss

徵兆：cutover 後 deploy 期間 application 5-10% request 失敗；發現 pod startup 完成前就接 traffic。

根因：Swarm 簡單 restart_policy 沒對等 probe 概念；K8s 預設 deploy 後 immediate ready、若沒 readiness probe、startup 時間長的 application 會在未 ready 時接流量。

修法：

1. 必加 readiness probe：HTTP / TCP / exec check
2. 配 initial delay：JVM application 預留 30-60s
3. 配 minReadySeconds：deployment 端設 30s 確保 stable

Case 4：HPA 預設不啟、autoscaling 失效

徵兆：Swarm 端寫了 cron-based autoscale script、切 K8s 後 script 失效、流量高峰沒 scale up。

根因：K8s HPA 不是預設啟動、需要 明示配置 + metrics-server install。

修法：

 1apiVersion: autoscaling/v2
 2kind: HorizontalPodAutoscaler
 3metadata:
 4  name: webapp-hpa
 5spec:
 6  scaleTargetRef:
 7    apiVersion: apps/v1
 8    kind: Deployment
 9    name: webapp
10  minReplicas: 3
11  maxReplicas: 20
12  metrics:
13    - type: Resource
14      resource:
15        name: cpu
16        target:
17          type: Utilization
18          averageUtilization: 70

裝 metrics-server / Keda（event-driven autoscaling）+ 配 HPA per Deployment。

Case 5：YAML 維護地獄、Helm / Kustomize 配置遲

徵兆：cutover 後 K8s YAML 從 5 個檔（Swarm stack）變 50+ 個 K8s manifest；每個 application 端要改一個 config 都要動 N 個 file。

根因：K8s YAML 是 very verbose、不像 docker-compose 簡潔；缺 templating 跟 environment 抽象。

修法：

1. Helm chart：對 application 包成 chart、用 values.yaml 抽象環境差異
2. Kustomize：base + overlay pattern、不靠 templating
3. GitOps with Argo CD / Flux：宣告式部署、降 manual kubectl 操作

Capacity / cost

判讀：< 30 service 小 organization 可不切；50+ service 開始撞 Swarm ceiling、值得評估；100+ service / multi-region 必切。

整合 / 下一步

跟 Service mesh 整合

Cutover 後 順便 評估 Istio / Linkerd / Cilium service mesh、cover mTLS / observability / traffic policy；不要在 Swarm migration 後立刻上 mesh、分階段。

跟 GitOps 整合

K8s + Argo CD / Flux 是 natural pair；migration 時直接走 GitOps、避免 manual kubectl 操作累積。

跟 Vault → AWS Secrets Manager 對齊

Swarm secrets → K8s Secret → external secrets management 是 3-step 演進、不是 1-step；migration 期間先用 K8s Secret、之後切 Vault / Secrets Manager。

相關連結

• Target vendor：Kubernetes
• 平行 migration playbook (Type E)：Kafka ↔ NATS / Redis → Memcached / etcd → Consul / Sentry → Honeycomb
• Methodology：Migration playbook methodology

服務定位

Kyverno 的定位是 K8s admission controller-shaped policy engine、policy 用 YAML 表達。底層是 dynamic admission webhook + background controller、頂層 CRD 包含 ClusterPolicy（cluster 範圍）/ Policy（namespace 範圍）/ PolicyException（明確例外）/ ClusterCleanupPolicy（過期 resource 清理）/ PolicyReport（CIS / NIST 等審計輸出）。Nirmata 是 Kyverno 商業版、補 policy library / multi-cluster management / audit dashboard / 24x7 support。

跟 OPA 比、Kyverno 走 narrow + opinionated — OPA 是 general-purpose policy engine（K8s / API gateway / Terraform / 自家服務都能用、語言是 Rego）、Kyverno K8s-only + YAML、學習成本對 K8s admin 接近零。跟 Gatekeeper 比、Gatekeeper 也是 K8s admission controller 但底層用 OPA + Rego、ConstraintTemplate / Constraint 兩層 CRD；Kyverno 不用 Rego、policy 就是 YAML rule list。跟 Trivy 的 misconfig scan 比、Trivy 是 scan static manifest、Kyverno 是 admission gate + background scan、定位互補不衝突。

關鍵張力：YAML policy 的表達力上限 ↔ 跨平台統一 policy 的訴求。Kyverno YAML rule 對 90% K8s 場景夠用、但需要跨 K8s / API gateway / Terraform 統一 policy decision 時、Rego 的表達力跟可移植性勝出。要看清楚 policy 邊界是否就在 K8s 內。

本章目標

讀完本頁、讀者能判斷：

1. Kyverno 在 K8s 治理 stack 中承擔哪一段（admission gate / mutation / generation / image verify / cleanup）、跟 Trivy scan / SBOM Tools / Sigstore cosign 怎麼分工
2. ClusterPolicy / Policy 的 ownership 設計（platform team 還是 app team 寫、誰 review、PolicyException 怎麼治理）
3. Validate / Mutate / Generate / Verify Images / Cleanup 五類 rule 的使用邊界跟陷阱
4. 何時用 Kyverno、何時走 OPA / Gatekeeper / K8s native ValidatingAdmissionPolicy 的取捨

最短判讀路徑

判斷 Kyverno deployment 是否健康、最少看四件事：

• Policy 是否走 GitOps：ClusterPolicy / Policy 是否在 Git 版控、走 ArgoCD / Flux sync、policy change 是否經 PR review、staging cluster 跑過 audit mode 才 promote 到 enforce
• Mode 配置：每條 policy 是 Audit（只記、不擋）還是 Enforce（擋 admission）、新規則是否先 audit 觀察 24-48hr 再 enforce、Background scan 是否開（補 admission 不到的 historical drift）
• Verify Images 啟用度：production cluster 是否要求 image 必須通過 cosign signature verify、SBOM attestation 是否驗、policy 是否包含 keyless verify（Fulcio + Rekor）
• PolicyException 治理：例外是否走 PR 申請 + 到期日 + owner、跟 Detection Coverage and Signal Governance 的 exception governance 對齊

四件事任一缺失、就是 7.12 供應鏈完整性 邊界的待補項目。

日常操作與決策形狀

ClusterPolicy / Policy 結構：Kyverno policy 是 K8s CRD、結構 spec.rules[] 一條條 rule、每條 rule 有 match（套用對象、kind / namespace / label / name）+ exclude（明確排除）+ rule body（validate / mutate / generate / verifyImages / cleanup 五選一）。ClusterPolicy 套整個 cluster、Policy 套單一 namespace、app team 通常只能改自家 namespace 的 Policy、平台 team 控 ClusterPolicy。

Validate rule：admission 階段檢查 manifest 是否符合條件、不符合就拒絕。最常見場景 — 禁止 latest tag、要求所有 pod 有 resource limit、禁止 privileged container、要求 specific label。寫法是 validate.pattern 或 validate.deny（後者支援更複雜的 boolean expression）、output 是 admission webhook reject。Validate 是 K8s policy as code 的入門場景、80% 的 ClusterPolicy 都是 Validate rule。

Mutate rule：admission 階段修改 manifest、把缺的欄位補上或改成符合的值。常見場景 — 自動注入 sidecar（service mesh proxy / log forwarder）、自動加 resource limit default、自動加 label（cost center / owner）、自動把 imagePullPolicy 改成 Always。Mutate 是 OPA / Gatekeeper 做不到的（兩者都偏 Validate-only）、是 Kyverno 的 K8s-specific 強項。陷阱是 mutate 變更後 GitOps diff 會永遠不一致、要在 ArgoCD ignoreDifferences 上對齊。

Generate rule：cluster event（namespace 建立、resource 變動）觸發、自動建立 關聯 resource。最常見場景 — 新 namespace 自動建 default NetworkPolicy（deny-all egress 起手）、自動建 ResourceQuota / LimitRange、自動 copy ConfigMap / Secret 到新 namespace。Generate 是把 security default 從文件層落到 runtime layer、避免 app team 忘記設 NetworkPolicy 就把整個 cluster 暴露。Generate 也是 OPA / Gatekeeper 做不到、Kyverno 獨有。

Verify Images rule：admission 階段驗證 container image 的簽章 / SBOM attestation / in-toto provenance。實作底層 Sigstore cosign — keyless 簽章驗 Fulcio CA + Rekor transparency log、key-based 驗 public key、attestation 驗 SLSA provenance / SBOM。production 場景 — internal registry image 必須 cosign 簽 + 來自 trusted CI runner、external image 必須在 allowlist。對應 SolarWinds 2020 Sunburst 的 supply chain attack 防禦邊界。

Cleanup policy：ClusterCleanupPolicy / CleanupPolicy 是 K8s 1.27+ 引入、Kyverno 1.10+ 支援、按 cron 跑、清掉符合條件的 resource。常見場景 — 過 30 天的 completed Job、過 7 天的 failed Pod、ephemeral namespace（PR preview env）超過 TTL 自動刪。Cleanup 補的是 K8s 沒有 resource lifecycle policy 的洞、TTL controller 只覆蓋 Job / Pod 子集。

Background scan：除了 admission 攔截 新 resource、Kyverno 定期掃描 已存在 resource 是否違反 policy、結果寫入 PolicyReport CRD。意義是補 歷史 drift — policy 是後來加的、已 deploy 的 resource 不會被 admission 攔到、background scan 才會找出來。production 一定要開、不開等於 policy 只防新犯不抓舊案。

ValidatingAdmissionPolicy (VAP) 整合：K8s 1.30+ 內建 CEL-based admission policy、不需要 admission webhook（VAP 由 kube-apiserver 直接 enforce、延遲低、不會因為 Kyverno pod 掛掉就讓 admission 失敗）。Kyverno 1.11+ 可以從 ClusterPolicy 生成 VAP、把簡單 Validate rule 卸載給 K8s native engine、複雜 rule（Mutate / Generate / Verify Images）留在 Kyverno。長期趨勢 — K8s native VAP 會吃掉 Kyverno Validate-only 的場景、Mutate / Generate / Verify Images 仍是 Kyverno 護城河。

GitOps 整合：ClusterPolicy / Policy 是普通 K8s CRD、走 ArgoCD / Flux sync 沒任何特殊性。staging cluster 跑 Audit mode 24-48hr 看 PolicyReport 有多少違規 → tune rule 或加 PolicyException → 確認沒誤殺再 promote 到 production cluster 的 Enforce mode。對應 Detection Engineering Lifecycle 的 propose → staging → promote pattern。

Policy Reporter：OSS dashboard（不是 Kyverno 內建、是社群專案）、把 PolicyReport CRD 視覺化、給 platform team / app team 看 cluster 違規概況。Nirmata 商業版有更完整的 multi-cluster dashboard + 歷史 trend + compliance mapping（CIS / NIST / PCI）。

核心取捨表

選 Kyverno 的核心訴求：K8s-only 場景 + 不想學 Rego + 需要 Mutate / Generate / Verify Images 的 K8s-specific 能力。團隊已投資 Rego ecosystem、或 policy 邊界跨 K8s + Terraform + API gateway、走 OPA / Gatekeeper 更合適。CI-time pre-merge 檢查走 Conftest 補位。

進階主題

Verify Images 進階 — cosign keyless + SBOM attestation：production-grade image trust 不只驗 signature、要驗 who signed it from where with what build process。keyless 模式驗 Fulcio CA-issued 短期憑證 + Rekor transparency log entry、確認簽章來自 trusted CI runner 的 OIDC identity（例如 https://github.com/myorg/myrepo/.github/workflows/release.yaml@refs/tags/v*）。SBOM attestation 用 verifyImages.attestations 驗 in-toto envelope、確認 image 帶 SLSA provenance + SBOM（CycloneDX / SPDX）。對應 XZ Backdoor 2024 的 lesson：maintainer takeover 也能簽 image、要靠 build provenance attestation 看出 build process 跟過去不一致。

Mutate policy 跟 GitOps 的張力：Mutate 自動補欄位、ArgoCD / Flux 會永遠看到 live state 跟 Git state diff。處理方式有三 — ignoreDifferences on specific fields（ArgoCD spec.ignoreDifferences、Flux spec.patches）、把 mutate 改成 validate + 在 PR template 補預設（成本高但 GitOps diff 乾淨）、Mutate at create only（用 mutate.mutateExistingOnPolicyUpdate: false、只在 admission 動、不重複 mutate existing resource）。

Generate policy 跟 multi-tenant security default：新 namespace 一建立、Generate rule 自動建 default-deny NetworkPolicy + ResourceQuota + LimitRange + 必要 RoleBinding。意義是 security default 從 README 落到 runtime、app team 開新 namespace 不會忘記設安全邊界。陷阱是 generated resource 的 ownership — 預設 Kyverno owns、app team 修改會被 reconcile 回去；要讓 app team 改、用 synchronize: false。

Nirmata Enterprise：商業版補三件事 — Policy Library（CIS / NIST / PCI / SOC 2 預製 policy pack）、Multi-cluster Management（中央 console 推 policy 到多 cluster + audit dashboard + drift detection）、Policy Reporter Plus（trend + compliance mapping + JIRA / Slack integration）。對大企業多 cluster + 合規驅動的場景值得評估、中小 deployment OSS Kyverno + 社群 Policy Reporter 夠用。

PolicyException 治理：Kyverno 1.9+ 引入 PolicyException CRD、讓特定 resource 明確繞過特定 policy、避免「app team 為了 deploy 直接把 policy 改寬」。Exception 走 PR + 到期日 + owner、跟 Detection Coverage and Signal Governance 的 exception lifecycle 對齊 — 例外不是黑箱、是 暫時性、有 owner、有 review 日期。

排錯與失敗快速判讀

• Policy 改了沒生效：admission webhook 沒 ready、或 policy 寫在錯的 namespace（Policy CRD 是 namespace-scoped、放錯 namespace 不會作用）— kubectl get clusterpolicies 看 ready 狀態、kubectl describe 看 events
• Admission 卡住 / Pod 起不來：Kyverno webhook 掛掉、failurePolicy 設 Fail 結果整個 cluster 不能 deploy — production 對 critical workload 設 failurePolicy: Ignore + 監控 Kyverno controller availability、不要讓 policy engine 變成 cluster-wide SPOF
• Mutate 後 ArgoCD 永遠 OutOfSync：mutate 改的欄位沒在 ArgoCD ignoreDifferences 排除 — 對應加 spec.ignoreDifferences[*].jsonPointers 或 .jqPathExpressions、不然每次 sync 都跳 diff
• Verify Images 全部失敗：cluster 沒對外網路、Fulcio / Rekor 拉不到、或 image 真的沒簽 — 先 audit mode 跑 + 看 PolicyReport 統計 unsigned image 比例、確認預期路徑（內部 image 簽 / 外部 image allowlist）後才 enforce
• Background scan 跑爆 controller：cluster 太大、scan interval 太短 — 調整 backgroundScan: false for 高頻變動 policy、或拉長 scan interval、或 Nirmata 用分散式 scan
• PolicyException 變成漏洞：例外沒到期日、owner 離職、規則永久繞過 — Exception CRD 補 metadata（owner / expiry / ticket）+ 定期 audit 過期 Exception
• VAP migration 不一致：Kyverno 生成的 VAP 跟原 ClusterPolicy 行為有差（CEL 不支援部分 Kyverno feature）— 對 critical rule 保留 Kyverno 不 migrate、只把簡單 Validate 卸載

何時改走其他服務

不在本頁內的主題

• Kyverno policy 完整 YAML reference、JMESPath 進階用法
• Sigstore cosign CLI 操作、Fulcio / Rekor 部署
• Nirmata Enterprise 詳細功能跟 pricing
• K8s ValidatingAdmissionPolicy CEL 語法 reference
• 跟 service mesh（Istio / Linkerd）整合的 sidecar injection 細節

案例回寫

下一步路由

• 上游：7.12 供應鏈完整性、Detection Coverage and Signal Governance
• 平行：OPA、Gatekeeper
• 下游：Trivy（scan + label）、Snyk（vuln 資訊源）、SBOM Tools（attestation 來源）
• 跨類：Sigstore cosign（CI 簽、Kyverno 驗）、ArgoCD / Flux（GitOps sync policy 本身）
• 跨模組：8 事故處理 vendor 清單（policy violation → IR routing）
• 官方：Kyverno Documentation、Sigstore Documentation

服務定位

Gatekeeper 的核心定位是 Rego policy 在 K8s admission 層的 K8s-native 包裝、不是另一個 policy engine。底層仍是 OPA、Rego 是同一套語言；上層加了兩個 K8s-specific 抽象 — ConstraintTemplate（Rego policy + parameter schema 的 CRD 定義）跟 Constraint（Template 的 instance、指定 match scope 與 parameter）。意義是同一份 Rego policy 寫一次、在不同 cluster / 不同 namespace 給不同 Constraint instance、不用改 Rego 本體。

跟 OPA（純 sidecar）比、Gatekeeper 走 K8s-native + 兩層抽象、犧牲 OPA 純 sidecar 的跨平台彈性（OPA 可同時管 K8s admission + API gateway + Terraform plan）、換來 K8s 內部 CRD + RBAC + GitOps 的一致體驗。跟 Kyverno 比、Gatekeeper 走 Rego DSL、Kyverno 走 YAML pattern matching — team 已投資 OPA / Rego（API gateway / Terraform 已用 Rego）就走 Gatekeeper、純 K8s shop + 沒 Rego 包袱直接用 Kyverno 較省學習成本。跟 Conftest 比、Conftest 是 CI-time static config check、Gatekeeper 是 runtime admission + audit、兩者互補不互斥（CI 用 Conftest 擋 PR、admission 用 Gatekeeper 擋 deploy）。

關鍵張力：Rego 學習曲線 ↔ 跨平台 policy 一致性 是 Gatekeeper 跟 Kyverno 最大的選擇分水嶺。純 K8s 場景 Kyverno YAML 寫起來快、但同樣的 image signature 規則若要在 Terraform plan / CI / admission 三處 enforce、Rego 寫一次跨三處比 YAML / Cue / Sentinel 多種語言混用乾淨。

本章目標

讀完本頁、讀者能判斷：

1. Gatekeeper 在 cluster policy stack 中承擔哪一段（admission validation / audit / mutation）、哪些要外接（OPA 純 sidecar 管非 K8s 對象、Conftest 補 CI-time）
2. ConstraintTemplate 跟 Constraint 兩層怎麼切（Template 由 platform team 維護、Constraint 給 app team 在 namespace 內 instantiate）
3. Audit / Mutation / External Data Provider 何時開、開了之後 cost 與 failure mode
4. 何時用 Gatekeeper、何時改 Kyverno 或退回純 OPA 的取捨

最短判讀路徑

判斷 Gatekeeper deployment 是否健康、最少看四件事：

• ConstraintTemplate 的 ownership：誰寫 Rego、誰 review、Template 是否走 Git（PR review + Gator CLI unit test）、是否有共用 library 避免每個 Template 重寫 K8s helper
• Audit coverage：除了 admission 攔截、Audit 是否定期 scan 已存在 resource（pre-Gatekeeper 部署的 legacy resource 違規）、auditFromCache 是否開、audit interval 是否合理（預設 60s、production 通常拉到 5-10min 避 API server 壓力）
• Failure mode 治理：Constraint enforcementAction 是 deny / warn / dryrun、Webhook failurePolicy 是 Fail / Ignore、Fail + Gatekeeper pod down 會擋全 cluster deploy
• 跟 GitOps 的對接：ConstraintTemplate / Constraint 是否走 ArgoCD / Flux 部署、policy change 是否經 staging cluster 驗證、emergency exception 流程是否定義

四件事任一缺失、就是 Detection Coverage and Signal Governance 在 admission 層的待補項目。

日常操作與決策形狀

ConstraintTemplate（CT）— Rego policy + CRD 定義：CT 是 Gatekeeper 的核心抽象、由 Rego policy + parameter schema（OpenAPI v3）兩段組成。Template 寫好 apply 到 cluster 後、Gatekeeper 會生成同名 CRD（例 K8sRequiredLabels）、app team 就能用該 CRD 寫 Constraint。Template 由 platform team 維護、不該每個 app team 自己寫 Rego — 集中維護才能保證 helper / convention / unit test 一致。

Constraint — Template 的 instance + match scope：Constraint 指定三件事 — 該套用哪個 Template（kind）、套用範圍（match：kinds / namespaces / labelSelector / excludedNamespaces）、parameter 值（spec.parameters、對應 Template 的 schema）。同一個 Template 可以有多個 Constraint instance（production / staging 不同 threshold、不同 namespace 不同 required label set）。這層抽象的意義是 policy logic 跟 environment-specific configuration 分開。

Audit — background scan 已存在 resource：除了 admission webhook 在 create / update 時攔、Audit controller 定期（預設 60s）掃整個 cluster 找違規 resource、結果寫到 Constraint status 的 violations 欄位。意義是 legacy resource 在你 install Gatekeeper 之前就在那、admission 不會觸發、Audit 才會抓到。auditFromCache: true 用 Gatekeeper 自己的 informer cache 不打 API server、適合大 cluster。

Mutation — 2024+ stable：早期 Gatekeeper 只有 Validation、Mutation 在 v3.10+ 進 beta、2024 隨 v3.14+ 進 stable。Mutation 走獨立 CRD（Assign / AssignMetadata / ModifySet）、不走 ConstraintTemplate。常見用法：注入 securityContext.runAsNonRoot: true、補 default resource limit、加 organization label。Mutation 跟 Validation 都開的話、Mutation 先跑、Validation 看 mutated 後的結果。

Sync Resources — cross-resource lookup：Rego policy 若要查 別的 resource（例：擋 Service 用了不存在的 Namespace）、要先 declare Config CRD 把該 resource type 加進 Gatekeeper 的 sync list、Gatekeeper 才會在 cache 裡有那個 resource 供 Rego 查。沒 sync 的 resource 不能跨 reference、是常見踩雷點。

External Data Provider — query 外部 API 做 decision：Gatekeeper v3.10+ 引入 External Data Provider、Rego 可以 call 外部 HTTPS endpoint 取 runtime data 做 policy decision。典型用法：query image scan service（例 Trivy server）確認 image 沒 CVE、query SBOM attestation service 確認 supply chain 完整、query custom IAM 確認 namespace owner 有權建立該 resource。要設 timeout + cache、外部 service down 不能擋全 cluster admission。

Gator CLI — policy unit test：Gator 是 Gatekeeper 官方 CLI、本機跑 Template + Constraint 對 mock K8s manifest、不需 cluster。CI pipeline 跑 gator test 對每個 Template 跑 fixture、policy change 出 PR 時自動驗證 — 避免 production deploy 才發現 Template Rego bug 擋全 cluster。

跟 GitOps 整合：ConstraintTemplate / Constraint / Mutation / Config CRD 都是純 YAML、走 ArgoCD / Flux 部署是標準作法。實務 layout：gatekeeper-system namespace 裝 Gatekeeper、gatekeeper-policies repo 放 Template 跟 baseline Constraint（platform team owned）、各 app namespace 的 Constraint instance 可以由 app team 在自己 repo 管理（透過 ArgoCD AppProject 限制 Constraint kind）。

核心取捨表

選 Gatekeeper 的核心訴求：team 已用 Rego（API gateway / Terraform plan / CI 已 OPA）+ 想把 same policy 延伸到 K8s admission + 看重 OPA ecosystem 一致性。純 K8s shop 沒 Rego 包袱、又特別需要 Mutation 場景密集（PSP 廢除後重建、跨 namespace 統一 sidecar 注入）直接走 Kyverno 更省學習成本。

進階主題

Rego idioms for K8s admission：K8s admission review 物件結構是 input.review.object、Template 的 violation rule 走 violation[{"msg": msg}] { ... } 形式。常見 idiom：match.kinds 跟 match.namespaceSelector 在 Constraint 層處理 scope、Rego 內只寫 policy logic；K8s helper（label 取值、container loop、init container 排除）抽到 shared library Template；錯誤訊息要帶 input.review.object.metadata.name 幫 app team 定位是哪個 resource 被擋。

External Data Provider 的 production 治理：Provider 是獨立 service、Gatekeeper webhook 透過 HTTPS call、cache 在 Gatekeeper 內。要設 timeout（預設 3s、過時 ConstraintTemplate failurePolicy 決定 fail-open / fail-closed）、cache TTL、Provider 自身的 readiness / liveness。Provider down 不該擋全 cluster — 用 failurePolicy: Ignore 對 External Data Provider 例外、但記錄 metric alert。對應 XZ Backdoor 2024 的 SBOM attestation 查詢場景。

Gator CLI 在 CI 的 pipeline 設計：gator test 對 fixture 跑、gator verify 跑 Template 自帶 test suite、gator expand 預覽 Mutation 結果。PR 流程：Template change → gator verify 跑 unit test → kind cluster 起 Gatekeeper apply Template + sample violation manifest → confirm 擋下來才 merge。

跟 Styra DAS / Nirmata 整合：Gatekeeper OSS 本身沒 central management UI、多 cluster deployment 看 violation status 要自己拼。Styra DAS 是 OPA 商業 control plane、可以 push Template / Constraint 到多 cluster Gatekeeper、彙整 audit violation、做 policy impact analysis。Nirmata 走類似路線。OSS-only deployment 通常用 ArgoCD ApplicationSet + Prometheus exporter（gatekeeper-policy-manager / Open Policy Agent metrics）拼。

排錯與失敗快速判讀

• Gatekeeper webhook timeout / 擋全 cluster admission：Rego policy 寫了 expensive operation（大量 cross-resource lookup、External Data Provider call without cache）— webhook timeout 預設 3s、超過就走 failurePolicy；改寫 Rego 用 indexed lookup、External Data Provider 加 cache、failurePolicy: Ignore for non-critical Template
• 新 Template apply 後 admission 整個壞：Rego syntax / logic bug、production 才發現 — PR 必跑 gator verify + staging cluster 24-48hr soak、Constraint 先用 enforcementAction: dryrun 觀察 violation count 才切 deny
• Audit 跑很慢 / API server 壓力大：cluster resource 量大、Audit interval 預設 60s 太頻繁 — 拉長到 5-10min、auditFromCache: true 用 informer 不打 API server、大 cluster 開 auditChunkSize 分批處理
• legacy resource 不擋：admission webhook 只攔 create / update、kubectl apply 沒改動 spec 不觸發 — 用 Audit 抓 violation、配合手動 migration plan、不要期待 admission 自動修
• Mutation 跟 Validation 衝突：Mutation 加了 label、Validation 又擋說 label 不該存在 — Mutation 先跑、Validation 看 mutated 結果；設計 policy 時要對齊兩端、不能各自寫
• Sync 沒 declare、cross-resource policy 看不到對象：Rego data.inventory.namespace["foo"].v1.Pod 回 undefined — Config CRD 加 sync targets、確認 Gatekeeper pod restart 後 cache 載入
• External Data Provider down 擋全 cluster：Provider service 自己掛、failurePolicy: Fail 整個 admission 壞 — Provider 走 failurePolicy: Ignore + metric alert、Provider 自身 HA 部署、cache TTL 拉長

何時改走其他服務

不在本頁內的主題

• Rego 完整語法 reference（unification、comprehension、partial evaluation）
• Gatekeeper helm chart / installation 細節（看官方 docs）
• Open Policy Agent 在 service mesh / API gateway 的 sidecar 部署模式（看 OPA 頁）
• Pod Security Admission（K8s 內建、跟 Gatekeeper 互補但不是 Gatekeeper 一部分）
• Multi-cluster policy bundle 的 OCI registry 分發（屬 7.12 供應鏈完整性 邊界）

案例回寫

Gatekeeper 在 07 案例庫沒有直接 vendor-level 事件、但 supply chain 跟 admission policy 相關 case 都是 Gatekeeper 落實位置的對照：

下一步路由

• 上游：7.12 供應鏈完整性與 Artifact Trust、7.13 偵測覆蓋率與訊號治理
• 平行：OPA、Kyverno、Conftest
• 下游：Trivy（image scan 結果 feed External Data Provider）、SPIRE（workload identity 跟 admission policy 互補）
• 跨類：Splunk（admission violation event 進 SIEM correlation）
• 跨模組：8 事故處理 vendor 清單（policy violation → IR routing）
• 官方：OPA Gatekeeper Documentation

服務定位

Tetragon 的核心定位是 eBPF 為基底的 runtime observability + enforcement、TracingPolicy CRD 是 first-class concept — 一份 YAML 同時描述 要觀察什麼 syscall / kprobe / tracepoint 跟 觀察到後要不要 enforce。底層 hook 點包括 syscall entry/exit、kprobe（任意 kernel function）、tracepoint（穩定 kernel event）、uprobe（user-space function），enforcement action 包括 Sigkill（kill process）、Override（override syscall return value）、NotifyEnforcer、Post（送 event 出 plane）。

跟 Falco 比、Falco rule 用 Sysdig filter syntax、Tetragon 用 K8s CRD + JSON schema、對 K8s native 模型更貼近；Falco 主走 alert、Tetragon 主走 alert + enforce；Falco 對非 K8s VM-heavy 場景更 mature。跟 Datadog Cloud Workload Security 比、Datadog 是 SaaS-only + per-host 計費、Tetragon 是 OSS Apache 2.0 + 自管 + Isovalent Enterprise 付費版可選。跟 Prisma Cloud Defender 比、Prisma 是 CSPM/CWPP 一體化平台、Tetragon 專注 runtime + 跟 Cilium L3-L7 network policy 同 plane。

關鍵張力：eBPF inline enforcement 的爆炸半徑 ↔ 偵測即時性。在 kernel-level 直接 kill process 比 userspace agent 更難 bypass、但 TracingPolicy 寫錯（match 太寬）可能誤殺合法 workload、且回退路徑只能改 CRD 再 reload。要看清楚自己 能不能承擔 enforcement 規則錯誤的 blast radius、再決定哪些 policy 進 enforce、哪些只 observe。

本章目標

讀完本頁、讀者能判斷：

1. Tetragon 在 K8s runtime stack 中承擔哪一段（process visibility / file access / network syscall / enforcement）、哪些要外接（Falco for VM-heavy、SIEM for log aggregation）
2. TracingPolicy 的 ownership 設計（誰寫 CRD、enforcement action 誰簽核、staging vs production rollout）
3. Observe vs Enforce 的階段化決策、什麼樣的 policy 適合 inline kill、什麼樣的應該停在 alert
4. 何時用 Tetragon、何時走 Falco / Datadog CWS / Prisma Defender 的取捨

最短判讀路徑

判斷 Tetragon deployment 是否健康、最少看四件事：

• TracingPolicy 治理：CRD 是否走 Git + PR review、enforcement action（Sigkill / Override）是否需額外簽核、staging cluster 是否先跑 24-48hr 觀察 false positive 才 promote production
• 跟 Cilium 整合深度：Hubble flow + Tetragon process event 是否同 plane export、Pod identity 是否在 process event 自動 enrich、跟 Cilium NetworkPolicy 是否雙層 enforcement 設計
• Enforcement coverage 分層：哪些 policy 處於 observe-only（log JNDI lookup / setuid abuse / unexpected outbound）、哪些升到 enforce（kill known exploit pattern）、升級條件是什麼
• Event export pipeline：Tetragon event 是否進 SIEM（OpenTelemetry / JSON log → Splunk / Elastic）、是否跟 Detection Coverage and Signal Governance 邊界一致

四件事任一缺失、就是 runtime security 邊界的待補項目。

日常操作與決策形狀

TracingPolicy CRD：Tetragon 的 first-class concept、一份 YAML 描述 hook 點 + match selector + enforcement action。Hook 點包含 syscall（最穩定但 surface 廣）、kprobe（任意 kernel function、版本相依）、tracepoint（穩定 kernel event、首選）、uprobe（user-space function、低層用）。Match selector 支援 K8s namespace / pod label / container image、process credentials（UID / GID / capabilities）、parent process。Production rule 用 pod label selector + 具體 syscall name + 額外 process credentials 條件、避免 cluster-wide 寬鬆 match 誤殺。

kprobe / tracepoint / syscall hook 的選擇：tracepoint 是 kernel 公開穩定介面、跨版本不變、首選；kprobe 可 hook 任意 kernel function 但跟 kernel build 緊綁、kernel upgrade 後可能要重寫；raw syscall 適合 audit 整類 syscall（如全部 execve）但量大、需要 in-kernel filter 控成本。

Process credentials tracking：Tetragon 從 process exec 開始 track UID / GID / capabilities / namespace、偵測 privilege escalation（setuid abuse、capabilities drift、container escape）是 first-class use case。跟 audit log 比、credentials drift 是 狀態變遷、不是單一事件、更能 surface lateral movement 早期訊號（process 開始時 UID 1000、跑到一半變 0 是異常）。

Pod identity correlation：Tetragon 在 K8s 環境會自動把 process event enrich K8s metadata（namespace / pod name / container image / service account）、不用後處理 join；event schema 跟 Hubble flow 同根、可在 Hubble UI 看 某 Pod 的 network flow + process event 同 timeline。

跟 Cilium NetworkPolicy 雙層 enforcement：Cilium 控 network ingress / egress / L7 HTTP、Tetragon 控 process / syscall / file access。雙層設計的意義是 — network layer 擋不住的（如 process 內部 lateral movement、container escape syscall）由 process layer 補上；process layer 漏的（如合法 process 突然 outbound 異常 destination）由 network layer 補上。對 supply chain 攻擊特別有效、攻擊鏈通常跨 malicious process spawn + outbound C2。

Event export 跟 SIEM 整合：Tetragon event 預設走 JSON log 到 stdout、可走 OpenTelemetry exporter 進 collector pipeline、再 fanout 到 Splunk / Elastic Security / Google Security Operations。在 SIEM 端做跨來源 correlation（process event + IdP audit + cloud control plane）是 production 標配、不可只看 Tetragon 自家視圖。

Observe → Enforce 階段化：TracingPolicy 通常 先進 observe-only、跑 1-2 週收 baseline、確認 false positive 可控、再加 enforcement action 進 staging cluster、staging 觀察 24-48hr 才 promote production。對應 Detection Engineering Lifecycle 的章節原則 — runtime enforcement 不是 console 直改、是 detection content lifecycle。

核心取捨表

選 Tetragon 的核心訴求：K8s heavy + 已用 Cilium CNI + 想要 kernel-level inline enforcement + OSS 免授權成本、且有 SRE / security team 能維護 TracingPolicy CRD lifecycle。VM-heavy 或 K8s 但用其他 CNI 走 Falco 更划算。

進階主題

Inline enforcement 的 blast radius 設計：Sigkill 直接 kill 觸發 process、Override 改寫 syscall return value（讓 process 以為成功但實際沒做）— 兩者都在 kernel-level、攻擊者很難 bypass、但寫錯規則的 blast radius 是 整個 cluster 內 match 到的 process 全死。實務治理：enforcement action 規則進 GitOps、PR 需 security + SRE 雙簽、staging cluster 跑 namespace-scoped 規則先驗證、production rollout 走 canary namespace 再擴散。

Process credentials drift detection：track UID / GID / capabilities 變遷、偵測 setuid abuse（process 從 uid 1000 變 0）、capabilities 突然新增（特別是 CAP_SYS_ADMIN / CAP_NET_ADMIN）。對 lateral movement 早期警報是 first-class signal — 攻擊者拿到初始 access 後通常要 escalate privilege、credentials drift 是必經訊號。配對 SolarWinds 2020 Sunburst 的 lesson：簽章驗證通過但 runtime 行為異常需 runtime credentials + process behavior 雙重 baseline。

跟 Cilium L3-L7 雙層 enforcement：典型 supply chain 攻擊鏈 — malicious dependency loaded → process spawn → C2 outbound、network layer 擋 outbound（Cilium NetworkPolicy 限制 egress destination）、process layer 擋 process（Tetragon KillerAction kill 異常 spawn）。雙層任一通則攻擊鏈中斷。對應 3CX 2023 Desktop App Supply Chain 的 case shape。

跟 SBOM / image signing 整合 baseline：Tetragon 偵測 runtime 行為偏離 baseline、SBOM / image signing 控 build-time 信任、合在一起是 trusted artifact + verified runtime behavior 雙重保障。runtime 行為 baseline 通常從 SBOM 列出的合法 process / syscall set 出發、deviation 進 alert。

Isovalent Enterprise：商業版加值在 multi-cluster management、policy 集中下發、support SLA、跟 Isovalent Hubble Enterprise / Cilium Service Mesh Enterprise 整合。OSS 版本核心功能完整、Enterprise 主要解 多 cluster 大規模管理 跟 企業 support、不是 feature gating。

排錯與失敗快速判讀

• TracingPolicy 誤殺合法 workload：match selector 太寬、cluster-wide 沒加 namespace / pod label 條件 — 改 namespace-scoped + 加 process credentials 額外條件、staging 跑 48hr 再 promote
• kprobe rule kernel upgrade 後壞：hook 的 kernel function 改名或 signature 變 — 改用 tracepoint（穩定介面）、kprobe 進 staging 版本相依測試
• Event volume 爆炸 / SIEM ingestion cost 飆：raw syscall hook 沒做 in-kernel filter、所有 execve 都進 event — 加 in-kernel filter（按 pod label / process name），讓 filter 在 eBPF 端做、不要事後 drop
• Inline enforcement 規則錯誤 blast radius 太大：production 直接上 Sigkill 沒走 staging — enforcement action 規則一律先 observe-only 1 週、staging cluster 24-48hr、canary namespace、才 production
• 跟 Cilium NetworkPolicy 重疊或衝突：同一個 attack pattern 被 network + process 同時阻擋、log 重複、誤判 — 設計時雙層各管 互補面（network 管 destination、process 管 process spawn）、不重複管同一面
• non-K8s workload 進不來：Tetragon DaemonSet 只在 K8s 跑、VM / bare metal 不支援 — VM-heavy 環境改走 Falco、K8s + VM 混合走雙 stack
• Pod identity enrich 不全：某些 process event 缺 namespace / pod name — 通常是 process 在 pod sandbox 啟動前 spawn、或 short-lived process 太快結束、調 Tetragon 的 process cache lifetime + K8s API server 連線健康

何時改走其他服務

不在本頁內的主題

• TracingPolicy CRD 完整欄位 reference 跟 kprobe / tracepoint 寫法 cookbook
• Cilium NetworkPolicy 寫法（屬 network 治理、跨章節）
• eBPF kernel programming 內部原理跟 verifier 限制
• Isovalent Enterprise 跟 Cilium Service Mesh 商業整合細節
• Hubble UI 操作（屬 observability 視角、跨章節）

案例回寫

Tetragon 在 07 案例庫沒有直接 vendor-level 事件、但所有 runtime detection + supply chain case 都是 eBPF inline enforcement 的對照：

下一步路由

• 上游：7.13 偵測覆蓋率與訊號治理、Detection Engineering Lifecycle
• 平行：Falco、Datadog Security
• 下游：Splunk / Elastic Security（Tetragon event 進 SIEM 做跨來源 correlation）
• 跨類：Cloudflare WAF（network edge 擋 + process 層補位）、HashiCorp Vault（credentials drift 配 secret rotation）
• 跨模組：8 事故處理 vendor 清單（runtime alert → IR routing）、4 observability（Hubble + Tetragon event pipeline 共用）
• 官方：Tetragon Documentation、Cilium Project