CNCF Kyverno 毕业后策略即代码怎样落到平台治理

我在做 Kubernetes 平台选型时，最容易被“项目毕业”这四个字带偏：看到 CNCF 公告，就想马上把它写进平台基线；真正开始接入后才发现，策略怎么评审、例外谁批准、准入失败怎么回退，仍然是团队自己的工程问题。CNCF 于 2026 年 3 月 24 日宣布 Kyverno 毕业，这条消息更适合被理解为成熟度和生产采用信号，而不是一份自动完成治理的安装说明。

Kyverno 毕业后，最稳妥的落地方式是把它当成 Kubernetes 平台中的策略执行层：用声明式策略表达护栏，用准入、扫描和报告形成证据，再由平台团队补上权限、例外、版本、回滚和责任边界。

官方公告：https://www.cncf.io/announcements/2026/03/24/cloud-native-computing-foundation-announces-kyvernos-graduation/

Kyverno 官方地址：https://kyverno.io/

这次毕业到底确认了什么

CNCF 官方公告将 Kyverno 描述为 Kubernetes 原生策略引擎，强调它可以用策略即代码的方式帮助平台和安全团队定义、管理并执行云原生环境中的护栏。公告还提到项目的生产采用、社区增长、安全审计和治理评审。对选型者来说，这些信息降低了“项目是否值得长期评估”的不确定性。

但它没有替团队确认以下事情：你的集群版本一定兼容、现有 GitOps 流程一定能接入、所有策略都能直接阻断、例外审批已经有人负责，或者引入 Kyverno 就能自动满足某一项合规要求。毕业是生态层面的成熟度结论，不是针对某个组织环境的验收报告。

我会把这条新闻拆成三个判断：

• 可以进入候选清单：Kyverno 值得和平台工程、准入控制、策略报告体系一起评估。
• 需要做架构分层：Kyverno 负责策略表达与执行，Kubernetes 仍负责运行基础，组织流程负责审批和风险接受。
• 必须保留现场证据：策略测试、准入结果、例外记录和报告，才是上线后能复盘的治理资产。

把 Kyverno 放回平台治理的三层边界

采用时不要先问“要装哪些组件”，先问每一层由谁负责。这样做的好处是，项目能力和组织责任不会在部署图里混成一团。

Kyverno 官方文档把策略管理解释为“管理其他配置或运行时行为”的配置层，并列出 YAML、CEL、Kubernetes 资源、准入控制、CLI 扫描、资源校验和策略报告等能力。这个定位很适合平台团队做统一护栏，但不应被误读为它会接管所有集群运维。

先用一个小策略包验证边界

第一轮试用时，我更倾向于选择“命名空间和资源范围清楚、失败影响可控”的策略，而不是一上来阻断全部生产对象。比如先观察工作负载是否携带团队约定的 owner 标签，再根据报告决定哪些命名空间可以升级为阻断。

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-owner-label
spec:
  # 先观察现状，避免历史资源一接入就被全部阻断
  validationFailureAction: Audit
  # 让后台扫描也能发现已经存在的违规对象
  background: true
  rules:
    - name: check-owner-label
      match:
        any:
          - resources:
              kinds:
                - Deployment
      validate:
        message: "Deployment 必须声明 owner 标签"
        pattern:
          metadata:
            labels:
              owner: "?*"  # 用非空值确认责任归属，而不是只检查字段存在

这段示例的重点不是复制一条万能规则，而是保留一个可回退的起点：先用 Audit 观察实际影响，再把规则、对象范围和责任人一起纳入评审。真正接入前还要按照当前版本文档确认策略类型、字段和弃用边界。

准入、扫描和报告要承担不同职责

治理回路里，准入控制、CLI 扫描和报告不是同一个按钮的三种叫法。准入适合在资源进入集群的关键时刻阻断明显风险；扫描适合在 CI 或既有资源上提前发现问题；报告则负责把结果留给平台团队、应用团队和审计人员继续处理。

一个实际可用的分工通常是：

• 开发阶段：在策略仓库里做单元测试，让规则随代码评审，而不是只在集群里试错。
• 交付阶段：在 CI 或 CLI 扫描中提前反馈，尽量让开发者在提交前看见清晰的失败原因。
• 集群阶段：对高风险对象使用准入控制，对仍需观察的规则先积累报告。
• 复盘阶段：将报告、例外和策略版本关联起来，分清是规则误报、历史债务还是实际违规。

如果所有问题都只在准入阶段暴露，平台团队很快会面对大量紧急例外；如果所有策略都只记录不阻断，治理又会停在报表展示。成熟的做法是按风险分级，把“发现问题”和“阻止变更”拆成可调整的两个控制点。

把 Git、准入和审计报告连成一条回路

策略即代码的价值不只是把 YAML 放进 Git，而是让一次变更能被追踪。至少应当知道哪次提交改变了规则、CI 测试覆盖了什么资源、准入结果对应哪个策略版本、例外由谁批准，以及报告里的问题最终怎样处理。

Kyverno 官方文档也提供策略测试、例外管理和报告相关入口。落地时可以把它们接到现有 GitOps 或发布流程中，但不要把“有一个报告对象”当成“已经完成审计”。报告还需要明确保留周期、责任人、处理状态和复查方式。

例外不是绕过策略，而是另一类受控变更

平台治理里最容易失控的是例外。某个命名空间、镜像或临时发布因为业务压力需要放行，如果例外只是聊天记录里的一句“先过一下”，后面就很难知道它什么时候失效。

我建议至少给例外绑定四个字段：

1. 范围：具体资源、命名空间、策略和版本，避免使用无法解释的全局豁免。
2. 理由：说明是迁移兼容、误报、紧急修复还是业务限制。
3. 负责人：由能承担风险的人批准，而不是只由执行部署的人口头确认。
4. 失效条件：写明时间、版本或修复动作，避免临时例外变成永久漏洞。

这样设计后，策略本身和例外都能进入同一套评审与审计路径。例外数量持续增加时，问题通常不在“团队不愿遵守规则”，而在规则范围、迁移窗口或策略说明仍不够准确。

用权限和版本控制扩大采用范围

Kyverno 毕业后，是否扩大采用范围仍然要看平台约束。至少需要明确以下边界：

• 策略编写、策略发布、例外批准和集群管理员权限分离，避免一个账号同时修改规则并放行自己提交的资源。
• 策略仓库、镜像和运行组件都保留版本，升级前先说明兼容范围和回滚路径。
• 从审计模式切到阻断模式前，先统计现有违规对象、误报比例和例外数量。
• 对关键命名空间保留一条不依赖临时网络服务的回退路径，避免策略控制面异常时无法恢复业务变更。

这里的“回退”不是关闭所有策略，而是能回到上一个已知可用的策略版本，并且知道哪些例外需要重新确认。对平台团队来说，这比单纯追求规则数量更重要。

这条新闻对平台选型意味着什么

我的结论是：Kyverno 毕业让平台团队更有理由认真做 PoC，但 PoC 的验收对象不能只是“组件启动成功”。至少要用一组真实策略证明资源范围、失败动作、例外、报告和回滚都能被团队理解和接管。能回答这些问题后，再决定把控制范围从试点命名空间扩大到更广的集群。

相关问题

Kyverno 毕业后是不是安装就能满足 Kubernetes 合规要求？

不是。毕业说明项目成熟度、治理和生产采用得到 CNCF 认可，具体合规目标仍要结合组织标准、策略内容、证据保留和人工审核完成。

Kyverno 会替代 Kubernetes 的准入控制器吗？

Kyverno 可以作为策略执行和准入控制的一部分，但不会替代 Kubernetes 集群、身份、网络、存储和资源治理体系。是否接入现有控制器，要按职责和兼容性评估。

小团队应该先开阻断模式吗？

通常先从审计模式和小范围资源开始，观察违规对象与误报，再选择高价值、低争议的规则逐步阻断。直接全局阻断会把历史债务一次性变成发布事故。

策略例外怎样避免越积越多？

给例外绑定资源范围、理由、负责人和失效条件，并定期根据报告复查。例外长期存在时，应回头修正规则或完成迁移，而不是继续扩大豁免范围。