Kyverno 基础回顾：架构、策略引擎与原生 NetworkPolicy 的关系
在深入 IDP 拓扑中的故障排查之前，必须先厘清 Kyverno 的核心设计。Kyverno 并非简单的策略引擎，而是一个运行在 Kubernetes 内部的 动态准入控制器，它利用 Kubernetes 原生的 Webhook 机制拦截资源请求，并通过声明式策略进行校验、变更或生成。
2.1 Kyverno 架构核心组件
Kyverno 采用无外部依赖的轻量架构，所有组件均以 Pod 形式运行在集群内。其核心组件包括：
| 组件 | 角色 | 关键说明 |
|---|---|---|
| Kyverno Admission Controller | 策略执行核心 | 接收 API Server 的 Mutating 和 Validating Webhook 请求，执行策略逻辑。 |
| Kyverno Cleanup Controller | 资源清理 | 根据 CleanupPolicy 定期删除过期或不符合要求的资源。 |
| Kyverno Reports Controller | 策略报告 | 生成 ClusterPolicyReport 和 PolicyReport，记录策略执行结果。 |
| Kyverno Background Controller | 后台扫描 | 对已有资源进行周期性扫描，发现违反策略的存量资源。 |
架构要点： Kyverno 不依赖 etcd 之外的额外存储，所有策略和配置都存储在 Kubernetes 原生的 CRD 中。这意味着 Kyverno 的故障排查往往从检查 CRD 状态和 Webhook 配置开始。
2.2 策略引擎工作原理
Kyverno 的策略引擎遵循 匹配-条件-动作 的三段式处理流程。当 API Server 发送准入请求时，引擎按以下顺序执行：
- 匹配阶段： 检查资源是否匹配策略中定义的
match规则（资源类型、标签、命名空间等）。 - 条件阶段： 如果匹配，则评估
preconditions和context中的条件表达式（支持 JMESPath 和 CEL）。 - 动作阶段： 根据策略类型执行对应动作：
- Validate： 拒绝不符合规则的请求。
- Mutate： 自动修改资源字段（如注入 Sidecar、添加标签）。
- Generate： 创建关联资源（如为每个 Namespace 自动生成 NetworkPolicy）。
故障排查提示： 当策略未生效时，优先检查
match 规则是否覆盖了目标资源。Kyverno 的 match 支持 any 和 all 逻辑，误用 any 可能导致策略意外跳过。
2.3 与原生 NetworkPolicy 的关系
理解 Kyverno 与原生 NetworkPolicy 的关系，是排查 IDP 网络策略故障的基础。两者并非替代关系，而是 策略定义层与策略执行层 的协作关系。
| 维度 | 原生 NetworkPolicy | Kyverno 网络策略 |
|---|---|---|
| 本质 | Kubernetes 网络隔离原语 | 策略生成器 / 策略校验器 |
| 执行者 | CNI 插件（Calico、Cilium 等） | Kyverno Admission Controller |
| 作用时机 | 运行时数据平面 | 资源创建/更新时的控制平面 |
| 典型用途 | 定义 Pod 间流量规则 | 自动生成 NetworkPolicy、校验策略合规性 |
| 故障排查入口 | kubectl describe networkpolicy |
kubectl describe policy + kyverno logs |
在 IDP 拓扑中，Kyverno 通常扮演以下角色：
- NetworkPolicy 生成器： 通过
generate策略，为每个新创建的 Namespace 自动生成默认的隔离策略（如拒绝所有入站流量）。 - NetworkPolicy 校验器： 通过
validate策略，确保开发者提交的 NetworkPolicy 符合安全基线（如禁止开放全 0.0.0.0/0 的入口规则）。 - NetworkPolicy 变更器： 通过
mutate策略，自动为 NetworkPolicy 添加审计标签或强制补充特定规则。
常见误区： Kyverno 生成的 NetworkPolicy 与手动创建的 NetworkPolicy 在 CNI 层面完全等价。如果发现生成的策略未生效，不要只排查 Kyverno，还要检查 CNI 插件是否支持该策略类型（如 Cilium 的
Egress 规则可能需要额外配置）。
2.4 策略执行的关键路径
在 IDP 拓扑中，网络策略的故障往往发生在以下关键路径上：
- Webhook 配置路径： Kyverno 的
MutatingWebhookConfiguration和ValidatingWebhookConfiguration是否正确指向 Kyverno Service？证书是否过期？ - 策略匹配路径： 策略的
match规则是否覆盖了目标 Namespace 或 Pod 的标签？exclude规则是否意外排除了目标？ - 生成策略路径：
generate策略是否设置了synchronize: true？如果手动删除了生成的 NetworkPolicy，Kyverno 是否会重新创建？ - 后台扫描路径： 对于存量资源，Background Controller 是否已扫描并生成报告？
kubectl get policyreport可以快速查看。
快速诊断命令：
kubectl describe validatingwebhookconfiguration kyverno-resource-validating-webhook-cfgkubectl get policyreport -n <namespace> -o yamlkubectl logs -n kyverno -l app.kubernetes.io/name=kyverno --tail=50