2. K8s 策略引擎介绍：OPA/Gatekeeper、Kyverno、准入控制器的工作原理与对比

在 Kubernetes 集群中，策略引擎是保障安全合规、资源治理与运维规范的核心组件。本章深入剖析三种主流策略实现机制：原生准入控制器（Admission Controller）、OPA/Gatekeeper 与 Kyverno，从工作原理、架构差异到选型建议进行系统性对比。

2.1 准入控制器（Admission Controller）——K8s 原生的策略拦截点

准入控制器是 Kubernetes API Server 内置的插件机制，在请求经过认证与鉴权之后、对象被持久化到 etcd 之前，拦截并处理 API 请求。它分为两类：变更（Mutating）与验证（Validating），分别对应 MutatingAdmissionWebhook 与 ValidatingAdmissionWebhook。

原生准入控制器（如 NamespaceLifecycle、LimitRanger、PodSecurity）以静态编译方式集成在 API Server 中，而 Webhook 模式允许用户注册外部 HTTP 回调，实现自定义策略逻辑。

2.2 OPA/Gatekeeper——基于 Rego 的策略即代码

OPA（Open Policy Agent）是一个通用的策略引擎，使用声明式语言 Rego 编写策略。Gatekeeper 是 OPA 在 Kubernetes 上的集成实现，作为 Admission Webhook 运行，拦截 API 请求并执行策略评估。

2.2.1 核心架构组件

• ConstraintTemplate：定义策略的 Rego 逻辑模板，描述如何评估资源。
• Constraint：实例化模板，指定作用范围（如命名空间、资源类型）与参数。
• Gatekeeper Webhook：接收 API Server 的准入请求，调用 OPA 引擎执行策略。
• Audit 机制：定期扫描集群中已有资源，标记违反策略的对象。

# constraint-template.yaml
apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8sdisallowedtags
spec:
  crd:
    spec:
      names:
        kind: K8sDisallowedTags
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8sdisallowedtags
        violation[{"msg": msg}] {
          container := input.review.object.spec.containers[_]
          endswith(container.image, ":latest")
          msg := sprintf("Image %v uses tag :latest", [container.image])
        }
---
# constraint.yaml
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sDisallowedTags
metadata:
  name: disallow-latest-tag
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
  parameters:
    tags: ["latest"]

2.2.2 工作流程

1. 管理员创建 ConstraintTemplate 与 Constraint 资源。
2. 用户提交创建 Pod 的请求。
3. API Server 将请求转发给 Gatekeeper Webhook。
4. Gatekeeper 加载匹配的 Constraint，使用 Rego 引擎评估请求。
5. 若违反策略，返回拒绝响应；否则放行。

2.3 Kyverno——专为 K8s 设计的策略引擎

Kyverno 是一个云原生策略引擎，使用 Kubernetes 原生资源定义策略，无需学习 Rego 等新语言。它支持 验证（Validate）、变更（Mutate）、生成（Generate） 与 清理（Cleanup） 四种策略类型。

2.3.1 策略定义方式

Kyverno 策略使用 YAML 编写，直接引用 K8s 对象字段，学习曲线低。例如，禁止特权容器的策略：

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-privileged-containers
spec:
  validationFailureAction: Enforce
  rules:
  - name: check-privileged
    match:
      any:
      - resources:
          kinds:
          - Pod
    validate:
      message: "Privileged containers are not allowed."
      pattern:
        spec:
          containers:
          - securityContext:
              privileged: "false"

2.3.2 核心特性

• 无需额外语言：策略直接使用 K8s 资源字段匹配，降低学习成本。
• 内置变更能力：可自动注入 Sidecar、添加标签、修改资源字段。
• 资源生成：根据策略自动创建 ConfigMap、Secret 等资源。
• 策略报告：自动生成 PolicyReport 资源，记录策略执行结果。
• Webhook 自动管理：Kyverno 自动注册与更新 Webhook 配置，简化运维。

2.4 三大策略引擎对比

2.5 选型建议与最佳实践

2.5.1 场景化选型

2.5.2 生产部署要点

• 高可用部署：Webhook 服务至少 2 副本，配置 Pod Anti-Affinity 与 PDB。
• 证书轮换：Webhook 证书需定期轮换，建议使用 cert-manager 自动管理。
• 性能监控：监控 Webhook 响应延迟（P99 < 100ms），避免阻塞 API Server。
• 灰度发布：新策略先设为 audit 模式（Kyverno）或 dryrun（Gatekeeper），确认无影响后再强制实施。
• 策略版本管理：将策略代码纳入 GitOps 流程，使用 CI/CD 自动化测试与部署。