3. 策略引擎架构：OPA/Gatekeeper 与 Kyverno 的架构对比、决策流程与数据流

在 Kubernetes 原生策略引擎领域，OPA/Gatekeeper 与 Kyverno 是两种主流的实现方案。两者虽然都实现了“策略即代码”的理念，但在架构设计、决策流程、数据流以及运维模型上存在本质差异。理解这些差异，是设计资源配额模型接口调用机制的前提。

3.1 架构设计对比

下表从核心组件、数据存储、策略语言、扩展性等维度，对两种引擎进行横向对比：

3.2 决策流程对比

两种引擎在 Admission Review 阶段的决策流程存在显著差异。下图展示了各自的请求处理路径：

3.3 数据流模型分析

数据流是策略引擎的核心性能瓶颈。两种引擎在数据获取、缓存、同步机制上采用了截然不同的策略：

3.3.1 OPA/Gatekeeper 的数据流

• 数据源：OPA 引擎维护一个独立的内存数据文档（data），通过 data.sync 机制从 Kubernetes API Server 拉取资源数据。
• 同步方式：支持 Pull 模式（定时轮询）和 Push 模式（通过 Bundle API 推送）。
• 数据隔离：每个约束模板（ConstraintTemplate）可以声明需要同步的 Kubernetes 资源类型，实现按需加载。
• 性能特征：策略评估时无需访问 API Server，但数据同步存在延迟（通常秒级），不适合对实时性要求极高的场景。

# OPA 数据同步配置示例（Bundle 模式）
services:
  - name: acmecorp
    url: https://bundle-server.example.com/v1/bundles
    credentials:
      bearer:
        : "<bundle->"

bundles:
  acmecorp:
    service: acmecorp
    resource: /opa/data/system/bundle.tar.gz
    polling:
      min_delay_seconds: 60
      max_delay_seconds: 120

3.3.2 Kyverno 的数据流

• 数据源：Kyverno 控制器直接通过 Informer 机制监听 Kubernetes 资源变化，数据存储在本地缓存中。
• 同步方式：基于 Watch 事件（List + Watch），数据更新延迟在毫秒级。
• 数据隔离：通过 spec.match 中的 resources 选择器过滤关注的资源类型。
• 性能特征：策略评估与 API 调用耦合，但 Informer 缓存保证了数据一致性，适合对实时性要求高的准入控制场景。

# Kyverno 策略示例（匹配特定资源）
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: check-resource-quota
spec:
  rules:
    - name: validate-quota
      match:
        resources:
          kinds:
            - Pod
            - Deployment
      validate:
        message: "Resource quota exceeded."
        pattern:
          spec:
            containers:
              - resources:
                  requests:
                    memory: "<= 2Gi"

3.4 资源配额场景下的数据流对比

在资源配额校验场景中，两种引擎的数据流差异直接影响接口调用机制的设计：