对比

Admission Webhook 主流方案对比

维度	Kyverno	OPA Gatekeeper	Kubewarden
策略语言	K8s YAML	Rego（Datalog 变体）	Rust / Go / Rego / CEL
学习曲线	零（K8s 用户）	陡（Rego）	中（Rust/Go 编程）
Mutate	✅ 原生 + 强	⚠️ 实验性	⚠️ 实验性
Validate	✅	✅ 强	✅
Generate	✅ 自动生成资源	❌	❌
复杂逻辑	中等（CEL/JMESPath 辅助）	强（Rego 全表达）	强（编程语言）
背景扫描	✅	✅（Audit）	✅
镜像签名验证	✅ 内置	❌（要外部）	✅ 内置
沙箱隔离	❌	❌	✅ Wasm 沙箱
策略分发	K8s manifest	K8s manifest	OCI 镜像
跨集群统一管理	弱（要 gitops）	弱	强（policy as image）
性能	中	中	快（wasm 接近原生）
生态成熟度	高（CNCF incubating）	最高（CNCF graduated）	中（CNCF incubating）
文档 / 中文	强	中	弱

一句话定位

• Kyverno：K8s 团队首选，零学习成本，mutate 强
• OPA Gatekeeper：复杂策略 + 跨平台（Terraform / Envoy 也用 OPA）首选
• Kubewarden：多集群统一 + Wasm 沙箱，新方向

决策树

团队熟悉度？
  ├─ 只熟悉 K8s → Kyverno
  ├─ 已用 Rego / 跨平台 → Gatekeeper
  └─ 想要 wasm 沙箱 / 多集群统一 → Kubewarden

要 mutate？
  ├─ 频繁 mutate（注入 sidecar / 配置）→ Kyverno
  └─ 偶尔 mutate + validate → 任一

要复杂逻辑（跨资源 / 跨字段）？
  ├─ 简单到中等 → Kyverno
  └─ 复杂 → Gatekeeper（Rego）或 Kubewarden（编程语言）

要策略跨集群分发？
  └─ Kubewarden

实战建议

• 新集群 / 默认选型：Kyverno，YAML 友好
• 已有 Rego 策略 / 复杂业务规则：Gatekeeper
• 多租户 SaaS / 多集群管理：Kubewarden
• 混合：Kyverno 做 mutate + Gatekeeper 做 validate（不常见，但可行）

跟 PSA（PodSecurity Admission）关系

K8s 内置的 PSA 替代了 PSP，是最简的 admission：

• 三档：privileged / baseline / restricted
• namespace label 启用：pod-security.kubernetes.io/enforce=baseline
• 不需装额外组件

但 PSA 能力有限（只能管 Pod 安全，不能注入、自动生成）。需要细粒度策略时，仍要 Kyverno / Gatekeeper。

性能 / 可靠性

• Webhook 是同步阻塞：apiserver 每次都调 webhook，超时 10s 默认
• 每个集群 webhook 数：建议 ≤ 30（K8s 自身有容量限制）
• 自定义 webhook：
• 必须 HA（Deployment 多副本）
• 必须配 --failure-policy=Fail 或 Ignore（默认 Fail）
• 必须快，>1s 就有性能影响

一句话选型

默认 → Kyverno；复杂 / 跨平台 → Gatekeeper；多集群 / wasm → Kubewarden。