2. Kyverno 基础架构：组件解析、工作流程与部署模式
Kyverno 是一个为 Kubernetes 设计的策略引擎，以 Kubernetes 原生方式运行。理解其核心组件、请求处理流程以及部署模式，是编写和运维策略的基础。本章将拆解 Kyverno 的内部架构，帮助你在集群中精准定位策略执行点。
2.1 核心组件解析
Kyverno 由三个主要组件构成，它们协同工作以实现策略的加载、评估与执行。下表总结了各组件的职责与关键特征：
| 组件 | 职责 | 关键特征 |
|---|---|---|
| Admission Controller | 拦截 Kubernetes API 请求（创建、更新、删除），调用 Webhook 进行策略校验与变更。 | 作为集群的“守门员”，运行在 API Server 内部流程中。 |
| Webhook | 接收 Admission Controller 转发的请求，执行策略引擎的验证（Validate）与变更（Mutate）逻辑。 | 分为 ValidatingWebhookConfiguration 和 MutatingWebhookConfiguration 两种资源。 |
| Policy Controller | 监控集群中的策略资源（ClusterPolicy / Policy），实时编译并缓存策略规则。 | 负责策略的生命周期管理，包括加载、更新、删除与状态同步。 |
关键概念： Kyverno 本身是一个 Deployment，运行在
kyverno 命名空间中。Admission Controller 和 Policy Controller 是同一个进程内的不同逻辑模块，Webhook 则是该进程对外暴露的 HTTPS 端点。
2.2 组件工作流程
当一个资源请求（例如 kubectl apply -f deployment.yaml）到达 Kubernetes API Server 时，Kyverno 的介入流程如下：
- 请求拦截： API Server 根据注册的 MutatingWebhookConfiguration 和 ValidatingWebhookConfiguration，将请求发送至 Kyverno 的 Webhook 端点。
- 策略匹配： Kyverno 的 Admission Controller 模块解析请求中的资源类型、命名空间、标签等信息，与 Policy Controller 缓存的策略规则进行匹配。
- 变更执行（Mutate）： 如果匹配到 Mutate 策略，Kyverno 生成 JSON Patch 补丁，返回给 API Server。API Server 应用补丁后，生成新的资源对象。
- 验证执行（Validate）： 如果匹配到 Validate 策略，Kyverno 对（可能已被变更的）资源对象进行校验。校验通过则放行，失败则拒绝请求并返回错误信息。
- 生成/清理（Generate/Cleanup）： 对于 Generate 或 Cleanup 策略，Kyverno 在后台创建或删除关联资源，不阻塞原始请求。
2.3 部署模式
Kyverno 支持多种部署模式，以适应不同规模和隔离需求的集群环境。以下是三种主流模式的对比：
| 部署模式 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 单集群模式 | 开发、测试、小型生产集群 | 部署简单，管理成本低 | 单点故障风险，策略影响整个集群 |
| 高可用模式 | 生产集群，要求高可靠性 | 多副本运行，故障自动转移 | 需要配置反亲和性，资源消耗略高 |
| 多集群联邦模式 | 大规模多集群环境，统一策略管控 | 策略集中下发，一致性高 | 需要额外的联邦控制面（如 Karmada / OCM） |
生产建议： 在生产环境中，至少部署 2 个 Kyverno 副本，并配置 Pod 反亲和性（
podAntiAffinity），确保副本分布在不同节点上。同时，为 Webhook 配置 failurePolicy: Fail 以严格拦截违规请求。
2.4 策略执行点与资源模型
Kyverno 的策略资源分为两种作用域：
- Policy（命名空间级）： 仅对指定命名空间内的资源生效。
- ClusterPolicy（集群级）： 对整个集群所有命名空间（或通过
spec.exclude排除的命名空间）生效。
每个策略可以包含多个 规则（rules），每条规则定义：
- match / exclude： 匹配条件（资源类型、标签、命名空间等）。
- validate / mutate / generate / verifyImages： 执行动作。
注意： 当
Policy 和 ClusterPolicy 同时匹配同一个资源时，Kyverno 会按创建时间顺序执行所有匹配的规则。如果规则之间存在冲突（例如一个规则要求添加标签，另一个规则禁止该标签），可能导致意外结果。建议通过 spec.background: false 控制后台扫描行为，避免大规模集群中的性能问题。