2. Kyverno基础架构：Kyverno组件、Admission Webhook机制、Policy Controller工作原理
理解Kyverno的基础架构是编写和调试策略的前提。Kyverno并非一个独立的策略引擎，而是深度嵌入Kubernetes控制面的动态准入控制器。本章从组件、Webhook机制和控制器工作流三个层次拆解其运行原理。
2.1 Kyverno核心组件
Kyverno以Deployment形式运行在集群中，主要包含以下组件：
| 组件 | 部署形态 | 核心职责 |
|---|---|---|
| Kyverno Admission Controller | Deployment（通常2副本） | 接收Admission Review请求，匹配并执行策略，返回允许/拒绝/补丁结果 |
| Kyverno Policy Controller | 与Admission Controller同进程 | 监听ClusterPolicy/Policy资源变化，维护策略缓存，触发后台扫描（Background Scan） |
| Kyverno Webhook Registrar | 内置在Controller中 | 自动管理MutatingWebhookConfiguration和ValidatingWebhookConfiguration的生命周期 |
| Kyverno Cleanup Controller | 可选Deployment | 执行基于策略的资源清理（Cleanup Policy），定时删除匹配的资源 |
| Kyverno Reports Controller | 可选Deployment | 生成ClusterPolicyReport/PolicyReport，提供策略执行审计视图 |
关键认知：Kyverno的Admission Controller和Policy Controller运行在同一个Pod中，共享缓存。这种紧耦合设计减少了网络开销，但也意味着Admission Controller的故障会直接影响策略的实时生效。
2.2 Admission Webhook机制
Kyverno通过Kubernetes原生的Admission Webhook机制拦截资源请求。整个请求链路分为两个阶段：
- Mutating Webhook（变更阶段）：在资源被持久化之前，Kyverno可以对请求进行修改（如注入Sidecar、添加标签）。
- Validating Webhook（验证阶段）：在资源被持久化之前，Kyverno对请求进行校验（如检查镜像来源、禁止特权容器）。
Kyverno自动注册两个Webhook配置：
kyverno-mutating-webhook-cfg：处理所有支持变更操作的资源类型。kyverno-validating-webhook-cfg：处理所有支持验证操作的资源类型。
Webhook配置中的rules字段决定了Kyverno监听哪些资源。当策略创建或更新时，Kyverno会自动调整这些规则，确保只拦截与策略相关的资源，减少不必要的API Server调用。
性能要点：Kyverno使用Failure Policy: Ignore作为默认配置。当Kyverno自身不可用时，API Server会跳过Webhook调用，避免集群控制面因Kyverno故障而阻塞。生产环境中建议根据策略的严格程度调整为Fail。
2.3 Policy Controller工作原理
Policy Controller是Kyverno的策略编排核心，负责策略的加载、匹配、执行和状态报告。其工作流程分为四个阶段：
| 阶段 | 触发条件 | 执行动作 |
|---|---|---|
| 策略注册 | ClusterPolicy/Policy创建或更新 | 解析策略规则，更新Webhook配置的rules字段，注册到策略缓存 |
| 请求匹配 | Admission Review到达 | 根据资源类型、命名空间、标签选择器匹配策略，过滤不相关的规则 |
| 策略执行 | 匹配成功 | 按规则顺序执行validate/mutate/generate/verifyImages操作，生成响应 |
| 后台扫描 | 定时（默认1小时）或策略变更 | 扫描集群中已有资源，生成PolicyReport，标记违反策略的资源 |
注意：后台扫描（Background Scan）仅用于审计和报告生成，不会对已有资源执行变更或删除操作。如果需要强制修复已有资源，必须使用Cleanup Policy或手动触发策略的mutateExistingOnPolicyUpdate功能。
2.4 策略执行优先级与冲突处理
当多个策略作用于同一个资源时，Kyverno按照以下优先级顺序执行：
- Mutating策略：按策略创建时间的升序执行。先创建的策略先生效。
- Validating策略：所有匹配的验证策略必须全部通过，任一策略拒绝则整个请求被拒绝。
- Generate策略：在资源创建完成后异步执行，不阻塞原始请求。
冲突处理原则：如果两个Mutating策略对同一个字段产生冲突（例如一个要求添加标签
env=prod，另一个要求env=dev），后执行的策略会覆盖先执行的策略。建议在策略命名时使用序号前缀（如010-require-label、020-set-env）来控制执行顺序。
2.5 架构设计总结
Kyverno的架构设计体现了云原生优先的理念：
| 设计特性 | 实现方式 | 带来的好处 |
|---|---|---|
| 无外部依赖 | 直接使用Kubernetes Admission Webhook API | 无需额外部署Webhook服务器或Sidecar |
| 策略即代码 | YAML定义策略，支持GitOps管理 | 版本控制、CI/CD集成、审计追溯 |
| 自动Webhook管理 | 策略变更时自动更新Webhook配置 | 减少运维负担，避免配置漂移 |
| 后台审计能力 | 定时扫描已有资源生成报告 | 发现历史遗留的安全问题 |