2. Kyverno 基础：项目背景、核心概念与架构组件
2.1 项目背景：从 Admission Webhook 到策略即代码
Kubernetes 原生提供了 Admission Controller 机制，允许在资源创建、更新或删除时注入自定义逻辑。然而，直接编写 Admission Webhook 需要开发、部署和维护独立的 HTTP 服务，门槛较高。Kyverno 应运而生，它是一款专为 Kubernetes 设计的策略引擎，将策略定义为 Kubernetes 资源（CRD），无需编写 Webhook 代码即可实现准入控制、资源验证、变更和生成。
Kyverno 的核心价值： 策略即代码（Policy as Code）—— 策略以 YAML 清单形式管理，可版本化、可审计、可自动化测试，与 GitOps 工作流天然集成。
| 对比维度 | 原生 Admission Webhook | Kyverno |
|---|---|---|
| 开发方式 | 编写 Go/Python 服务，处理 HTTP 请求 | 编写 YAML 策略清单 |
| 部署复杂度 | 需构建镜像、配置 TLS、部署 Service | kubectl apply 即可 |
| 策略管理 | 分散在多个代码仓库 | 统一 CRD 资源，支持集群级/命名空间级 |
| 学习曲线 | 需掌握 Webhook 框架和 Kubernetes API | 熟悉 YAML 和 Kubernetes 资源即可 |
2.2 核心概念：Policy、Rule、Match / Exclude
Kyverno 的策略模型围绕三个核心概念构建：Policy（策略）、Rule（规则）、Match / Exclude（匹配/排除）。理解这三者的关系是编写有效策略的基础。
2.2.1 Policy（策略）
Policy 是顶层资源，分为两种类型：
- ClusterPolicy：集群范围生效，可匹配所有命名空间中的资源。
- Policy：命名空间范围生效，仅匹配指定命名空间内的资源。
每个 Policy 包含一个或多个 Rule，规则之间是 OR 关系——只要有一条规则匹配，策略即生效。
2.2.2 Rule（规则）
Rule 定义了具体的策略逻辑，包含以下关键字段：
- name：规则名称，在同一策略内唯一。
- match：定义规则匹配的资源条件（必填）。
- exclude：定义规则排除的资源条件（可选）。
- validate / mutate / generate：规则的动作类型，分别对应验证、变更、生成。
2.2.3 Match / Exclude（匹配/排除）
Match 和 Exclude 使用相同的资源选择语法，支持按 资源类型、标签、命名空间、名称模式 等条件筛选。两者组合形成规则的生效范围：
- Match：必须满足的条件（AND 逻辑）。
- Exclude：一旦满足即跳过规则（OR 逻辑）。
最佳实践： 在 Match 中尽量使用精确的资源类型和标签选择器；Exclude 常用于排除系统命名空间（如 kube-system）或特定标签的调试 Pod。
# 示例：ClusterPolicy 定义，匹配所有命名空间中带有 app=frontend 标签的 Deployment
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: require-frontend-labels
spec:
rules:
- name: check-labels
match:
any:
- resources:
kinds:
- Deployment
selector:
matchLabels:
app: frontend
validate:
message: "必须包含 'version' 标签"
pattern:
metadata:
labels:
version: "?*"2.3 架构组件：Kyverno 如何工作
Kyverno 以 Deployment 形式运行在集群中，核心组件包括 Webhook Server、Controller 和 Cache。下图展示了 Kyverno 处理准入请求的完整流程。
2.4 组件职责详解
| 组件 | 职责 | 关键行为 |
|---|---|---|
| Webhook Server | 接收 API Server 的 AdmissionReview 请求 | 解析请求中的资源对象，匹配策略规则，执行 validate/mutate/generate 动作，返回 AdmissionResponse |
| Controller | 管理 Policy/ClusterPolicy 资源的生命周期 | 监听策略 CRD 变化，更新内部缓存，生成对应的 Webhook 配置（MutatingWebhookConfiguration / ValidatingWebhookConfiguration） |
| Cache | 缓存策略定义和集群状态 | 减少对 etcd 的直接读取，加速策略匹配；支持策略热更新 |
| etcd | 持久化存储策略 CRD 和集群资源 | Kyverno 本身不直接操作 etcd，通过 Kubernetes API 间接读写 |
2.5 策略动作类型：Validate / Mutate / Generate
Kyverno 的每条 Rule 必须指定一个动作类型，决定了策略对资源的影响方式：
- validate：验证资源是否符合预期模式，不符合则拒绝（或仅告警）。
- mutate：在资源持久化之前自动修改其字段（如注入 Sidecar、添加标签）。
- generate：基于规则自动创建新资源（如为每个 Namespace 生成默认 NetworkPolicy）。
注意： generate 动作仅在资源创建时触发，不会对已有资源生效。如果需要为已有资源生成资源，需手动触发或使用 Kyverno 的 BackgroundScan 功能。