3. 平台门户集成:平台门户如何集成 Kyverno 作为准入控制器

在云原生平台门户中,Kyverno 作为 Kubernetes 原生的动态准入控制器,其集成方式直接影响策略生效范围、运维复杂度以及性能基准测试的基线。本章聚焦于平台门户(如 Rancher、OpenShift Console、自研控制台)与 Kyverno 的集成架构、配置步骤及关键集成点,为后续性能基准测试奠定环境基础。

3.1 集成架构概览

平台门户集成 Kyverno 的核心思路是将 Kyverno 部署为集群内的 ValidatingAdmissionWebhook 与 MutatingAdmissionWebhook,并通过门户的扩展机制暴露策略管理、监控与审计能力。下图展示了典型集成架构:

平台门户集成 Kyverno 准入控制器架构 平台门户集成 Kyverno 准入控制器架构 平台门户 扩展 / 插件层 API 网关 Kubernetes API Server Kyverno 准入控制器 (Validating / Mutating) 策略存储 (ClusterPolicy) ConfigMap / CRD 审计日志 / 事件 集成核心:Webhook 注册
集成要点:平台门户不直接调用 Kyverno API,而是通过 Kubernetes API Server 的准入 Webhook 机制间接触发策略评估。门户的职责是封装策略的创建、更新、删除及审计日志展示,而非代理请求。

3.2 集成步骤与配置清单

平台门户集成 Kyverno 通常包含以下 5 个步骤,每个步骤都涉及门户侧与集群侧的协同配置:

步骤 操作内容 门户侧配置 集群侧配置
1 部署 Kyverno Helm Chart 集成 Helm 仓库,一键部署 创建 kyverno 命名空间,安装 CRD
2 注册 ValidatingWebhookConfiguration 自动生成 Webhook 配置 配置 failurePolicy、timeoutSeconds
3 策略管理界面挂载 嵌入 Kyverno 策略列表 API 暴露 ClusterPolicy / Policy 资源
4 审计日志对接 对接 Kyverno 事件或 Loki 启用 reportChangeRequest
5 性能监控集成 暴露 Prometheus 指标 配置 ServiceMonitor

3.3 关键集成点:Webhook 配置与策略同步

集成过程中,ValidatingWebhookConfiguration 的生成与策略同步是两大核心难点。平台门户需要确保 Webhook 的 failurePolicy 与 timeoutSeconds 参数与性能基准测试目标一致。以下是一个典型的 Webhook 配置片段:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: kyverno-resource-validating-webhook
  labels:
    app: kyverno
webhooks:
- name: validate.kyverno.svc
  failurePolicy: Fail          # 生产环境建议 Fail,测试时可设为 Ignore
  timeoutSeconds: 10           # 默认 10s,性能测试可调整为 5s
  sideEffects: None
  admissionReviewVersions: ["v1"]
  clientConfig:
    service:
      name: kyverno-svc
      namespace: kyverno
      path: /validate
    caBundle: <base64-ca-cert>
  rules:
  - operations: ["CREATE", "UPDATE"]
    apiGroups: ["*"]
    apiVersions: ["*"]
    resources: ["pods", "deployments", "services", "configmaps"]
  matchConditions:
  - name: exclude-kyverno-ns
    expression: "object.metadata.namespace != 'kyverno'"
性能测试注意:在基准测试阶段,建议将 failurePolicy 设为 Ignore 以避免策略故障导致集群不可用;同时将 timeoutSeconds 设为 5s 以模拟真实超时场景。测试完成后务必恢复为 Fail。

3.4 策略同步机制:从门户到集群

平台门户通常通过 Kubernetes API 的 CRD 接口直接管理 Kyverno 策略。策略同步流程分为“推模式”与“拉模式”两种:

  • 推模式(Push):门户通过 ServiceAccount 直接向集群写入 ClusterPolicy 或 Policy 资源,Kyverno 控制器实时监听并生效。延迟低,但需要门户具备集群写权限。
  • 拉模式(Pull):门户将策略存储于 Git 仓库或 ConfigMap,Kyverno 通过定期轮询或 Webhook 触发更新。安全性高,但同步延迟可能影响测试实时性。

在性能基准测试场景下,推荐使用 推模式 以减少同步变量对测试结果的影响。以下是一个通过门户 API 创建策略的示例:

# 门户后端调用 Kubernetes API 创建 ClusterPolicy
POST /apis/kyverno.io/v1/clusterpolicies
Content-Type: application/json

{
  "apiVersion": "kyverno.io/v1",
  "kind": "ClusterPolicy",
  "metadata": {
    "name": "require-pod-labels"
  },
  "spec": {
    "validationFailureAction": "Enforce",
    "rules": [
      {
        "name": "check-labels",
        "match": {
          "resources": {
            "kinds": ["Pod"]
          }
        },
        "validate": {
          "message": "Pod must have label 'app'",
          "pattern": {
            "metadata": {
              "labels": {
                "app": "?*"
              }
            }
          }
        }
      }
    ]
  }
}

3.5 集成验证与健康检查

完成集成后,平台门户应提供以下验证能力,确保 Kyverno 准入控制器正常工作:

验证项 检查方法 预期结果
Webhook 注册状态 kubectl get validatingwebhookconfiguration kyverno-resource-validating-webhook 存在且 AGE 正常
策略生效 创建违反策略的 Pod 请求被拒绝,返回策略提示信息
审计日志输出 查看 Kyverno 日志或事件 出现 PolicyViolation 事件
门户策略列表 门户界面刷新策略列表 显示已创建的 ClusterPolicy
性能指标暴露 curl /metrics 返回 kyverno_admission_* 指标
集成完成标志:平台门户能够无感地创建、更新、删除 Kyverno 策略,并实时展示准入审核结果与审计事件,同时 Prometheus 指标端点正常暴露,为后续性能基准测试提供数据源。