📚 课程目录第4章 Validate策略实战

4. Validate策略实战：编写第一个Validate策略

Validate策略是Kyverno最核心的策略类型之一，用于在资源创建或更新时进行合规性检查。本节将带领你从零编写第一个Validate策略——强制Pod必须包含指定标签，并验证策略生效过程与报告查看方法。

4.1 策略目标与设计

本实战的目标是：拒绝所有未携带 app.kubernetes.io/name 标签的Pod创建请求。该策略属于强制性准入控制，一旦部署，任何不满足条件的Pod都会被API Server拒绝。

策略属性	值
策略类型	Validate（验证）
匹配资源	Pod（v1）
验证条件	必须存在 `app.kubernetes.io/name` 标签
违规行为	拒绝创建，返回明确错误信息
执行模式	Enforce（强制）

设计要点：使用 app.kubernetes.io/name 而非自定义标签，是为了与Kubernetes推荐标签体系保持一致，便于后续与监控、日志、服务发现等工具集成。

4.2 编写Validate策略YAML

以下是一个完整的Validate策略定义。策略使用 pattern 方式声明期望的标签结构，Kyverno会自动检查请求中的资源是否匹配该模式。

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-pod-label
spec:
  validationFailureAction: Enforce
  rules:
  - name: check-for-app-label
    match:
      any:
      - resources:
          kinds:
          - Pod
    validate:
      message: "Pod必须包含标签 'app.kubernetes.io/name'。"
      pattern:
        metadata:
          labels:
            app.kubernetes.io/name: "?*"

  关键字段解析：
  validationFailureAction: Enforce — 强制模式，违规直接拒绝。
match.any — 匹配任意一种资源类型，这里只匹配Pod。
pattern — 使用通配符 ?* 表示标签值可以为任意非空字符串。
message — 违规时返回给用户的提示信息。

4.3 部署策略到集群

将上述YAML保存为 require-pod-label.yaml，然后使用 kubectl apply 部署到集群：

kubectl apply -f require-pod-label.yaml

验证策略是否成功创建：

kubectl get clusterpolicy require-pod-label -o wide

输出应显示策略状态为 Ready，表示Kyverno已加载并准备执行该策略。

4.4 测试策略生效

现在分别测试合规与违规两种情况。

4.4.1 测试合规Pod（应被允许）

kubectl run nginx-compliant \
  --image=nginx \
  --labels="app.kubernetes.io/name=nginx"

预期结果：Pod创建成功，返回 pod/nginx-compliant created。

4.4.2 测试违规Pod（应被拒绝）

kubectl run nginx-violation \
  --image=nginx

预期结果：Pod创建被拒绝，返回类似以下错误信息：

Error from server: admission webhook "validate.kyverno.svc" denied the request:

resource Pod/default/nginx-violation was blocked due to the following policies:

require-pod-label:
  check-for-app-label: 'Pod必须包含标签 'app.kubernetes.io/name'。'

常见问题：如果Pod创建成功但未报错，请检查：① Kyverno是否正常运行；② Webhook配置是否正确；③ 策略是否处于 Enforce 模式而非 Audit 模式。

4.5 查看策略报告

Kyverno会为每个策略生成策略报告（PolicyReport），记录所有资源的合规状态。查看全局报告：

kubectl get policyreport -A

查看特定命名空间的报告详情：

kubectl get policyreport -n default -o yaml

报告内容示例（节选）：

apiVersion: wgpolicyk8s.io/v1alpha2
kind: PolicyReport
metadata:
  name: cpol-require-pod-label
  namespace: default
results:
- policy: require-pod-label
  rule: check-for-app-label
  resources:
  - apiVersion: v1
    kind: Pod
    name: nginx-compliant
    namespace: default
  result: pass
  scored: true
- policy: require-pod-label
  rule: check-for-app-label
  resources:
  - apiVersion: v1
    kind: Pod
    name: nginx-violation
    namespace: default
  result: fail
  scored: true
summary:
  pass: 1
  fail: 1
  error: 0
  skip: 0
  warn: 0

报告价值：策略报告是审计合规性的核心依据。你可以通过 kubectl get policyreport -o json 将报告导出为JSON，集成到CI/CD流水线或合规仪表盘中。

4.6 Validate策略执行流程

下图展示了从Pod创建请求到策略决策的完整链路：

4.7 策略调试与常见问题

问题现象	可能原因	排查方法
策略部署后Pod仍可无标签创建	策略处于 `Audit` 模式	检查 `validationFailureAction` 是否为 `Enforce`
Webhook未触发	Kyverno Pod未就绪或Webhook配置异常	`kubectl get pods -n kyverno` 检查状态
策略报告为空	报告生成有延迟或策略未匹配任何资源	等待30秒后重试，或手动创建测试Pod
错误信息不明确	`message` 字段未定义或过于简短	在策略中补充详细的 `message` 描述

4.8 扩展：使用Audit模式先行验证

在生产环境强制生效前，建议先使用 Audit 模式观察策略影响：

spec:
  validationFailureAction: Audit

在Audit模式下，违规Pod仍会被创建，但策略报告会标记为 fail。你可以通过报告评估策略的覆盖面和误报率，确认无误后再切换为 Enforce。

  最佳实践：建议遵循“先Audit后Enforce”的渐进式策略部署流程，避免因策略误判导致生产服务中断。

4.9 本章小结

通过本节实战，你已掌握：

编写基于 pattern 的Validate策略，强制Pod携带指定标签。
使用 kubectl apply 部署ClusterPolicy。
测试合规与违规场景，验证策略的准入控制效果。
通过PolicyReport查看策略执行结果与合规统计。
理解从请求到决策的完整执行流程。