Kyverno 基础回顾：策略引擎架构、策略类型与匹配规则
在深入流水线集成之前，必须牢固掌握 Kyverno 的核心设计。Kyverno 是一个为 Kubernetes 量身定制的策略引擎，它利用 Kubernetes 自身的 Admission Webhook 机制，在资源创建、更新或删除时拦截请求，并根据用户定义的策略进行校验、变更或生成资源。本章将系统梳理其架构、三种策略类型以及匹配规则的编写方法。
1. 策略引擎架构
Kyverno 以 Pod 形式运行在集群内，通常部署在 kyverno 命名空间。其核心组件包括 Webhook 服务器、策略控制器和报告控制器。下图展示了请求拦截与策略执行的全流程：
架构要点：Kyverno 以 动态 Admission Webhook 方式运行，无需修改 API Server 启动参数。策略以
ClusterPolicy（集群范围）或 Policy（命名空间范围）资源定义，控制器自动将策略转换为 Webhook 配置。
2. 三种策略类型
Kyverno 提供三种核心策略行为，分别对应不同的安全与自动化场景。理解它们的差异是编写有效策略的基础。
| 策略类型 | 行为 | 典型场景 | 示例 |
|---|---|---|---|
| Validate | 校验资源是否符合规则，不符合则拒绝 | 强制镜像必须来自私有仓库；禁止特权容器 | 检查 image 字段是否包含 registry.internal.io |
| Mutate | 在资源持久化之前修改其字段 | 自动注入 Sidecar、添加标签、设置资源限制默认值 | 为所有 Pod 添加 app.kubernetes.io/version 标签 |
| Generate | 根据源资源创建或更新其他资源 | 为每个 Namespace 自动创建 NetworkPolicy、RoleBinding | 当创建 Namespace 时，自动生成一个 LimitRange |
执行顺序：对于同一个资源请求，Kyverno 按 Mutate → Validate → Generate 的顺序执行。Mutate 先修改资源，Validate 再校验修改后的结果，Generate 在资源被允许后异步创建衍生资源。
3. 策略匹配规则
策略通过 match 和 exclude 字段定义作用于哪些资源。匹配规则支持多种条件组合，包括资源类型、标签选择器、命名空间选择器等。
3.1 基本匹配结构
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: require-pod-labels
spec:
validationFailureAction: Enforce # Enforce 或 Audit
rules:
- name: check-required-labels
match:
any: # 满足任一条件即匹配
- resources:
kinds:
- Pod
namespaces:
- production
- staging
selector:
matchLabels:
app: frontend
exclude:
any:
- resources:
namespaces:
- kube-system
validate:
message: "Pod 必须包含 'owner' 标签"
pattern:
metadata:
labels:
owner: "?*" # ?* 表示必须存在且非空3.2 匹配条件详解
| 匹配字段 | 说明 | 示例值 |
|---|---|---|
kinds |
匹配资源类型（支持通配符 *） |
Pod, Deployment, Namespace |
namespaces |
匹配资源所在的命名空间 | production, default |
selector |
基于标签选择器匹配 | matchLabels: { env: prod } |
annotations |
基于注解匹配 | matchAnnotations: { kyverno.io/ignore: "true" } |
any / all |
逻辑组合：any 满足其一即匹配；all 需全部满足 |
— |
3.3 匹配逻辑：any 与 all
Kyverno 2.0+ 引入了 any 和 all 块，替代了旧版的 resources 直接嵌套方式，使匹配逻辑更清晰：
- any：规则中定义的多个条件，只要满足其中一个，策略即生效。
- all：规则中定义的多个条件，必须全部满足，策略才生效。
# 示例：匹配 production 命名空间 或 带有 app=frontend 标签的 Pod
match:
any:
- resources:
namespaces:
- production
- resources:
selector:
matchLabels:
app: frontend
常见误区：在
match 中同时使用 kinds 和 namespaces 时，它们是“与”关系——即资源必须同时属于指定类型和指定命名空间。如果需要“或”关系，请使用 any 块分别定义。
4. 策略模式：Enforce vs Audit
每个策略都可以设置为 Enforce（强制执行）或 Audit（仅审计）模式。在流水线集成中，建议先使用 Audit 模式验证策略效果，确认无误后再切换为 Enforce。
| 模式 | 行为 | 适用阶段 |
|---|---|---|
| Enforce | 违反策略时直接拒绝请求，资源无法创建/更新 | 生产环境、流水线门禁 |
| Audit | 违反策略时仅记录报告，不阻止请求 | 策略开发测试、灰度验证 |
spec:
validationFailureAction: Audit # 先审计，观察策略影响
# 确认无误后改为 Enforce5. 本章小结
- Kyverno 基于 Admission Webhook 实现，策略本身是 Kubernetes 资源，天然支持 GitOps。
- 三种策略类型 Validate、Mutate、Generate 覆盖了校验、变更和资源自动生成三大场景。
- 匹配规则通过
match/exclude结合any/all逻辑，可精确控制策略作用范围。 - 建议在流水线中先使用 Audit 模式收集违规报告，再逐步切换为 Enforce 模式。