📚 课程目录第4章控制平面驱动模式（Control Plane Driven）概念

4. 控制平面驱动模式（Control Plane Driven）概念

在 Kubernetes 准入控制生态中，控制平面驱动（Control Plane Driven） 是一种新兴的架构范式。它不再依赖集群外部的独立服务或事件总线来执行策略，而是将策略决策逻辑直接嵌入到 Kubernetes 控制平面的核心组件中，利用 API 服务器原生支持的扩展点来完成准入校验。

理解这一模式的关键在于厘清它与传统 事件驱动（Event Driven） 和 Webhook 驱动（Webhook Driven） 的本质区别。下表从多个维度进行了对比：

对比维度	控制平面驱动	Webhook 驱动	事件驱动
决策位置	API 服务器内部（原生扩展）	集群外独立服务	事件处理管道（如 Knative）
调用方式	API 服务器直接调用内置逻辑	HTTP 回调至外部 Webhook	事件触发异步处理
延迟特征	极低（进程内）	中等（网络往返）	较高（事件队列）
故障模式	API 服务器自身故障	Webhook 超时/不可用	事件丢失/积压
典型实现	ValidatingAdmissionPolicy	ValidatingWebhookConfiguration	Knative Eventing + 策略引擎
运维复杂度	低（无外部依赖）	中（需管理 TLS、高可用）	高（需事件基础设施）

4.1 核心差异详解

Webhook 驱动：Kubernetes 在资源持久化前，向外部 HTTPS 端点发送 AdmissionReview 请求。外部服务返回允许/拒绝决策。这是 Kyverno、OPA/Gatekeeper 等传统策略引擎的默认模式。缺点是需要管理证书、网络连通性和服务可用性。
事件驱动：资源变更被发布到事件总线（如 CloudEvents），由下游消费者异步处理。这种模式适合审计、合规报告等非实时场景，但不适合需要同步拒绝非法请求的准入控制。
控制平面驱动：策略以声明式配置（如 ValidatingAdmissionPolicy + ValidatingAdmissionPolicyBinding）的形式直接存储在集群中。API 服务器在内部编译并执行这些策略，无需网络调用。这是 Kubernetes 1.28+ 引入的原生能力。

  关键洞察： 控制平面驱动模式将策略执行从“外部附加组件”转变为“平台内置能力”，显著降低了准入控制链的故障半径和运维负担。

4.2 Kubernetes 原生资源：ValidatingAdmissionPolicy

ValidatingAdmissionPolicy 是控制平面驱动模式在 Kubernetes 中的核心实现。它使用 Common Expression Language (CEL) 编写策略规则，无需部署任何 Pod 或 Service。

一个典型的策略定义包含三个部分：

策略定义（ValidatingAdmissionPolicy）：声明匹配的资源类型、CEL 表达式和失败消息。
策略绑定（ValidatingAdmissionPolicyBinding）：将策略定义绑定到特定的命名空间或集群范围。
参数资源（可选）：通过 paramKind 引用外部配置对象，实现策略参数化。

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: "require-labels-policy"
spec:
  matchConstraints:
    resourceRules:
      - apiGroups:   [""]
        apiVersions: ["v1"]
        operations:  ["CREATE", "UPDATE"]
        resources:   ["pods"]
  validations:
    - expression: "has(object.metadata.labels) && has(object.metadata.labels['app'])"
      message: "所有 Pod 必须包含 'app' 标签"
---
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicyBinding
metadata:
  name: "require-labels-binding"
spec:
  policyName: "require-labels-policy"
  matchResources:
    namespaceSelector:
      matchLabels:
        environment: production

实践提示： CEL 表达式在 object（请求对象）和 oldObject（旧对象，仅 UPDATE 时可用）上操作。支持丰富的函数库，包括字符串处理、正则匹配、列表操作等。

4.3 控制平面驱动 vs. Kyverno 的 Webhook 驱动

Kyverno 传统上以 Webhook 驱动模式运行。当我们将 Kyverno 策略移植到控制平面驱动模式时，需要理解以下映射关系：

Kyverno 概念	控制平面驱动等价物	移植要点
`ClusterPolicy`	`ValidatingAdmissionPolicy`	规则从 YAML 断言转为 CEL 表达式
`Policy`（命名空间级）	`ValidatingAdmissionPolicyBinding` + `namespaceSelector`	作用域通过绑定控制，而非策略本身
`preconditions`	`matchConditions`（CEL 前置条件）	条件逻辑从 Kyverno 语法转为 CEL
`validate.deny`	`validations[].expression`	拒绝条件直接映射为 CEL 布尔表达式
`validate.pattern`	CEL 字符串/正则函数	模式匹配需用 `matches()` 等函数重写

4.4 控制平面驱动架构示意

下图展示了控制平面驱动模式与 Webhook 驱动模式在架构层面的核心差异：

4.5 为什么选择控制平面驱动？

对于 Kyverno 策略移植适配而言，控制平面驱动模式带来了三个关键优势：

零运维策略引擎：无需部署、升级或监控 Kyverno Pod，策略直接由 API 服务器原生执行。
更短的故障链：没有网络超时、证书过期、Webhook 服务崩溃等外部故障模式。
原生一致性：策略行为与 Kubernetes 版本绑定，避免策略引擎与 API 版本之间的兼容性问题。