2. Kyverno 基础：架构、安装部署与核心概念
Kyverno 是一个为 Kubernetes 设计的策略引擎，它利用 Kubernetes 原生的 Admission Webhook 机制，在资源创建、更新或删除时进行校验、生成或变更。本章将深入解析 Kyverno 的架构组件、安装部署流程以及核心概念（Policy、Rule、Match/Exclude），为后续在 Serverless 集群中实施安全合规策略打下坚实基础。
2.1 Kyverno 架构解析
Kyverno 以 Pod 形式运行在 Kubernetes 集群中，主要由三个核心组件构成：Webhook 服务器、策略控制器和报告控制器。它们协同工作，实现策略的加载、执行与审计。
2.2 安装部署 Kyverno
Kyverno 支持多种安装方式，推荐使用 Helm Chart 进行生产级部署。以下为两种主流部署方式。
2.2.1 使用 Helm 安装（推荐）
# 添加 Kyverno Helm 仓库
helm repo add kyverno https://kyverno.github.io/kyverno/
helm repo update
# 安装 Kyverno 到 kyverno 命名空间
helm install kyverno kyverno/kyverno \
--namespace kyverno \
--create-namespace \
--set admissionController.replicas=2 \
--set backgroundController.replicas=1 \
--set reportsController.replicas=12.2.2 使用 YAML 清单安装
# 直接应用官方发布的 YAML 清单
kubectl create -f https://raw.githubusercontent.com/kyverno/kyverno/main/config/install.yaml
生产环境建议： 在 Serverless 集群中，建议将
admissionController.replicas 设置为至少 2 个副本，以确保高可用性。同时，开启 --autogenInternals 特性以自动处理 Job/CronJob 的 Pod 策略继承。
2.3 核心概念：Policy、Rule、Match/Exclude
Kyverno 的策略模型围绕三个核心概念构建：Policy（策略）、Rule（规则）和 Match/Exclude（匹配/排除）。理解这三者的关系是编写有效策略的基础。
2.3.1 Policy（策略）
Policy 是 Kyverno 的最高级资源对象，定义了策略的生效范围和行为类型。Kyverno 支持两种策略类型：
| 策略类型 | 作用域 | 适用场景 |
|---|---|---|
| ClusterPolicy | 集群级别，影响所有命名空间 | 全局安全基线、合规要求（如禁止特权容器） |
| Policy | 命名空间级别，仅影响指定命名空间 | 多租户隔离、特定业务团队的定制规则 |
2.3.2 Rule（规则）
每个 Policy 可以包含一个或多个 Rule。Rule 定义了具体的策略逻辑，包括匹配条件、排除条件和执行动作。Rule 的核心结构如下：
rules:
- name: "require-pod-resources" # 规则名称
match: # 匹配条件
resources:
kinds: ["Pod"]
exclude: # 排除条件（可选）
resources:
namespaces: ["kube-system"]
validate: # 执行动作：校验
message: "Pod 必须设置资源限制"
pattern:
spec:
containers:
- resources:
limits:
memory: "?*"
cpu: "?*"2.3.3 Match/Exclude（匹配/排除）
Match 和 Exclude 是 Rule 的筛选器，决定了策略作用于哪些资源。它们支持多种匹配维度：
| 匹配维度 | 描述 | 示例 |
|---|---|---|
| kinds | 匹配资源类型（支持通配符） | ["Pod", "Deployment"] |
| namespaces | 匹配命名空间 | ["production", "staging"] |
| names | 匹配资源名称（支持通配符） | ["app-*"] |
| selector | 匹配标签选择器 | matchLabels: { app: nginx } |
| annotations | 匹配注解 | {"sidecar-injector/auto-inject": "true"} |
关键原则： Match 和 Exclude 是“与”逻辑关系。资源必须满足 Match 中的所有条件，且不满足 Exclude 中的任何条件，Rule 才会生效。Exclude 的优先级高于 Match。
2.4 策略执行动作
Kyverno 的 Rule 支持三种执行动作，分别对应不同的策略场景：
| 动作类型 | 关键字 | 行为描述 | Serverless 场景示例 |
|---|---|---|---|
| 校验 | validate |
检查资源是否符合规范，不符合则拒绝 | 禁止 Serverless Pod 使用 hostNetwork |
| 变更 | mutate |
自动修改资源字段，无需用户手动操作 | 自动注入 Sidecar 代理或安全标签 |
| 生成 | generate |
根据源资源自动创建新资源 | 为每个命名空间自动生成 NetworkPolicy |
2.5 策略示例：禁止特权容器
以下是一个完整的 ClusterPolicy 示例，展示如何禁止在 Serverless 集群中创建特权容器：
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: disallow-privileged-containers
spec:
validationFailureAction: Enforce # Enforce 表示强制执行，Audit 表示仅审计
background: true # 对已有资源进行后台扫描
rules:
- name: check-privileged
match:
resources:
kinds:
- Pod
validate:
message: "特权容器是不允许的"
pattern:
spec:
containers:
- securityContext:
privileged: false # 强制 privileged 字段为 false
注意： 在 Serverless 集群中，
validationFailureAction 建议先设置为 Audit 模式进行灰度验证，确认无影响后再切换为 Enforce 模式。同时，务必在 exclude 中排除系统命名空间（如 kube-system、knative-serving），避免影响集群核心组件。