2026-08-20 — Kyverno 轉型平台原語，ngrok 拆解 Kubernetes probe 底層機制

Kyverno 不只是安全閘門：CNCF 部落格拆解四種平台自動化用法

CNCF Blog · 2026-08-19

原本的問題

CNCF 大使 Koray Oksay 在部落格中指出，多數團隊評估 Kyverno 時，習慣把它與 OPA/Gatekeeper 放在同一個框架下比較，並只用來擋掉不合規的資源。這種「政策即閘門」的用法只動用了 Kyverno 四種能力中的一種：validate。其餘三種——mutate、generate、verify images——都是建設性操作，會新增、修改或產生資源，而不是單純擋下請求。文章認為只把 Kyverno 當安全工具，等於浪費了它作為平台元件的能力。

採用的方法

文章定義了「平台原語」（platform primitive）需具備的四個特性：對開發者隱藏複雜度、提供自動化保證、可與其他元件組合、支援自助服務。基於這個框架，作者列出平台團隊實際在用的五種 Kyverno 用法：

命名空間建置：新增 Namespace 時自動產生 NetworkPolicy、ResourceQuota、LimitRange 與 RoleBinding
Sidecar 注入：透過 mutate 規則替 Pod 加上可觀測性代理、mesh proxy 或密鑰同步容器
映像位址改寫：把 nginx:1.25 這類公開映像改寫為 mirror.internal/nginx:1.25，強制走內部 registry
預設資源請求：直接注入符合工作負載型態的 CPU/記憶體預設值，取代單純擋下不合規 Pod
擁有者標籤：強制或補上 team、cost center、environment 等標籤

影響範圍

作者將這種模式總結為「政策是平台表達意圖的方式」，把 Kyverno 定位成「平台對外表達組織意圖的 API」，而非單純的合規檢查器。這意味著平台團隊在導入 Kyverno 時，除了寫 validate 規則擋掉壞資源，也該評估用 generate、mutate 規則把重複性的手動設定自動化，讓開發者拿到「開箱即用」但仍符合治理要求的資源，而不必等待平台團隊人工介入。

原始來源：CNCF Blog：Kyverno is a platform primitive, not a security tool

ngrok 做了一個瀏覽器版 Kubernetes，逐格重現 probe 判活邏輯

ngrok Blog · 2026-08-19

背景

ngrok 工程師 cyndunlop 發表文章，用自製的 webernetes——一個把超過十萬行 Kubernetes Go 原始碼移植成 TypeScript 的專案——在瀏覽器中互動式重現 startupProbe、readinessProbe、livenessProbe 三種探針的實際行為。文章強調這些探針彼此職責不同：startupProbe 只負責判斷容器是否完成初始化；readinessProbe 持續檢查容器健康度，失敗時只會把 Pod 標為 NotReady 並從服務負載平衡中移除，不會重啟容器；livenessProbe 則會在容器判斷為卡死時觸發重啟策略（預設 Always）。作者在用 webernetes 對照驗證行為時，意外在 k3s 上發現一個 Kubernetes 的既有 bug。

核心機制

文章逐一拆解探針的關鍵欄位：periodSeconds 決定檢查頻率，failureThreshold（預設 3）決定連續失敗幾次才觸發動作，successThreshold（預設 1）決定連續成功幾次才視為恢復。對 HTTP GET 類型的探針，回應碼落在 200–399 之間即視為成功。一個典型的 startupProbe 設定如下：

startupProbe:
  httpGet:
    path: "/startup"
    port: 8080
  periodSeconds: 1
  failureThreshold: 5

容器重啟走 CrashLoopBackOff 時，退避時間從 10 秒開始，每次崩潰倍增，最高封頂在 5 分鐘，且這個退避是以每個 Pod 為單位獨立計算，不會跨叢集共用。

設計原則與注意事項

文章給出的實務建議是：startupProbe 要「便宜且有界」，readinessProbe 要保守，livenessProbe 只在「非常確定容器卡死、重啟能解決問題」時才觸發。文中特別警告，若在 livenessProbe 裡檢查資料庫等下游依賴，一旦下游短暫抖動就會讓所有相關 Pod 同時被判定不健康並重啟，形成連鎖故障。此外，容器優雅終止的預設寬限期是 30 秒，探針週期設定過短會直接影響部署 rollout 的速度與穩定性。

原始來源：ngrok Blog：How Kubernetes Probes Work、webernetes（GitHub）

End of article