把 Kyverno 当成“策略 YAML 工具”很容易上手，也很容易在生产里误判风险。放在真实集群语境里，它更接近一层挂在 Kubernetes API Server 旁边的分布式控制面。真正昂贵的事故，多数出在控制边界，而并非语法边界。

截至 2026-03-23（UTC），kyverno/kyverno 上游仓库公开信号为 7,521 stars、1,262 forks、334 open issues，最近一次 push 时间为 2026-03-21T18:22:41Z。[1] GitHub 最新发布序列包含 v1.17.1（发布时间 2026-02-19）。[2] 项目活跃度并不低，但活跃度不会自动替你偿还架构债务。

这篇笔记只收敛到三条最影响稳定性的边界。

边界一：准入路径决定实时摩擦，报告/后台路径决定收敛质量

Kyverno 的官方架构把职责拆成独立控制器与独立 Deployment：admission、reports、background、cleanup。[3][4]

这套拆分本身是合理的，问题通常出在运维假设：很多团队默认“所有控制器都能用加副本得到同样收益”。现实并非这样。

高可用文档给出的要点非常明确：

• Kyverno 是 四个 Deployment 的控制器拆分架构；[4]
• admission 控制器的多副本同时承载可用性与吞吐扩展；
• reports/background 属于状态型 leader-election 路径，同一时刻只有 leader 执行核心处理；[4]
• cleanup 同时包含 leader 组件与可并行的清理吞吐组件。[4]

这会直接改变故障体感：admission 过载时，用户立刻感知到 API 阻塞；reports/background 过载时，短期表面或许平静，但策略报告收敛与 generate/mutate-existing 队列会逐步积压。

因此 Kyverno 运行的时间结构天然是双时钟：

1. 快时钟：Admission webhook 响应预算；
2. 慢时钟：报告与后台变更的最终一致性收敛。

把双时钟当成单时钟管理，事故阶段就会出现定位错位。

边界二：超时与失败语义是安全契约，并非调参装饰

策略设置文档给出两组关键默认值：webhookTimeoutSeconds 默认 10 秒，允许范围 1–30 秒；failurePolicy 默认 Fail（fail-close），也支持 Ignore（fail-open）。[5]

这组配置属于强约束的运行契约。

在高压负载下把超时预算压得过紧，准入失败会迅速放大；把全部策略都切到 fail-open，集群可用性表面更平滑，但最需要强约束的时刻，策略防线也最容易失去硬度。

可操作的做法是先完成策略分层：

• 明确“必须阻断”与“允许降级”两条执行车道；
• 高风险控制保持 fail-close；
• 可容忍短期降级的路径再评估 fail-open；
• 在压测里验证真实突发流量与外部依赖抖动下的超时行为。

“Kyverno 如何工作”文档也把这件事说得足够清楚：admission 回调是执行入口，policy reports 是下游证据，并非执行替代品。[3] 事故排查若跳过这个层次，结论很容易偏离根因。

边界三：证书生命周期与平台特例是常驻工作，并非一次性交付

Kyverno 自管证书的默认机制有明确时间锚点：

• CA 有效期 1 年；
• TLS 证书有效期 150 天；
• 至少每 12 小时检查一次有效性；
• 通常在到期前约 15 天启动续签流程。[6]

机制“自动”并不意味着运维责任消失。证书更新、Webhook 配置重写、平台控制器行为之间仍然会与 RBAC 与托管集群策略发生耦合。

平台说明文档给出两条常见盲点：

• EKS 场景中，kube-system 排除与节点自举稳定性相关；Kyverno 自 1.12 起已默认排除 kube-system；[7]
• AKS 场景中，Admission Enforcer 或许与 Kyverno webhook 协调冲突；官方同样给出注解策略，并注明自 1.12 起已内置默认值。[7]

“Helm 安装成功”只能说明第一阶段结束。续签、重配、平台约束在变更窗口和异常窗口里都能稳定通过，才算这条边界真正闭环。

两种解释路径

解释 A：Kyverno 问题主要来自策略编写质量

这一路径强调策略规范化与模板化，认为把写法统一后，稳定性会显著改善。

解释 B：Kyverno 问题主要来自控制面边界失配

这一路径认为策略质量当然重要，但高成本事故更常见于 admission 预算、状态型控制器吞吐与失败语义没有被协同设计。

在多租户、策略密度较高的集群里，解释 B 往往更有预测力。原因并不复杂：策略写法问题通常早期可见，边界问题常常要到扩容、升级、依赖波动才集中显影。

可直接落地的架构检查清单

1. 准入 SLO 车道：把 admission 延迟与错误预算作为 API 可靠性一等指标。
2. 控制器扩展车道：分开评估 admission 扩展与 reports/background 收敛，不做“副本线性增益”假设。
3. 失败语义车道：按策略风险等级显式定义 fail-close 与 fail-open。
4. 证书车道：把续签与 webhook 更新纳入演练，而并非只看常态运行。
5. 平台车道：提前验证 EKS/AKS/OpenShift 场景下的 webhook 与安全上下文细节。

证伪条件

如果一个集群长期处于低策略密度、低 admission QPS、单团队低复杂度状态，在缺少专门边界工程投入的前提下仍持续稳定运行，且没有明显执行漂移与可用性代价，那么本文“边界优先”的判断强度会下降；在该阶段，额外架构复杂度或许并不划算。

2026 年这件事为什么仍然关键

Kyverno 成不成熟，已经并非核心分歧。核心分歧转移到运维建模：把它当“一个 webhook 加若干报告”的团队，会在关键时刻承担隐性风险；把它当“快时钟准入 + 慢时钟收敛 + 明确失败语义”的控制面来治理，安全与可用性更容易同时获得可预测性。

来源

1. GitHub API — kyverno/kyverno 仓库元数据（stars、forks、open issues、push 活跃度）
2. GitHub API — kyverno/kyverno 近期发布（含 v1.17.1 时间线）
3. Kyverno 文档 — How Kyverno Works（admission 回调、引擎处理、报告/后台流程）
4. Kyverno 文档 — High Availability（控制器拆分、副本行为、leader election 特征）
5. Kyverno 文档 — Policy settings（超时范围、failure policy 默认值）
6. Kyverno 文档 — Configuration/customization（证书有效期与续签机制）
7. Kyverno 文档 — Platform notes（EKS/AKS 运行注意项及 1.12 默认行为）