4. 配置缓存基础：Kubernetes ConfigMap 与 Secret 概述、缓存机制原理、缓存命中与未命中场景

4.1 Kubernetes 配置对象：ConfigMap 与 Secret

在 Kubernetes 集群中，ConfigMap 和 Secret 是两种核心的配置资源对象，用于将配置数据与容器镜像解耦。Kyverno 策略引擎在评估策略时，频繁读取这些对象以获取规则参数、白名单或敏感凭证，因此理解其底层缓存机制是优化策略性能的前提。

4.2 缓存机制原理

Kubernetes API Server 和客户端库（如 client-go）内置了多级缓存架构。Kyverno 作为控制器运行，其策略引擎通过 informer 机制监听资源变化，并在本地维护一份缓存副本。下图展示了从策略触发到缓存命中的完整链路：

4.3 缓存命中与未命中场景

Kyverno 策略引擎在处理准入请求时，对 ConfigMap/Secret 的访问分为两种典型场景。理解这些场景有助于开发者设计高效的策略模板。

4.3.1 缓存命中场景

• 同一策略多次评估：短时间内多个 Pod 创建请求触发同一策略，策略引用的 ConfigMap 已被缓存，直接返回本地数据。
• 资源未变更：ConfigMap/Secret 自上次缓存后未被修改，informer 的 watch 机制未推送更新事件，缓存保持有效。
• 策略模板复用：多个策略引用相同的配置数据（如全局白名单），共享 informer 缓存池。

4.3.2 缓存未命中场景

• 首次加载：策略启动或控制器重启后，缓存为空，所有引用都需要回源到 API Server。
• 资源频繁更新：ConfigMap/Secret 被高频修改，导致缓存不断失效，每次评估都触发新请求。
• 跨命名空间引用：策略引用的 ConfigMap 位于不同命名空间，informer 可能未监听该命名空间，导致缓存缺失。
• 缓存驱逐：内存压力或配置的 TTL 过期导致缓存条目被移除。

4.4 缓存键与失效策略

Kyverno 内部使用 namespace/name 作为缓存键，结合 resourceVersion 判断数据是否最新。失效策略遵循以下规则：

1. 基于事件驱动：当 ConfigMap/Secret 发生 UPDATE/DELETE 事件时，informer 回调自动更新或移除缓存条目。
2. TTL 兜底：默认 TTL 为 5 分钟，防止因 watch 连接中断导致缓存数据过时。
3. 手动刷新：通过 Kyverno 的 reload 注解或 API 触发强制刷新。

# 示例：Kyverno 策略中引用 ConfigMap 的 context 定义
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: check-config-cache
spec:
  rules:
  - name: validate-from-config
    context:
    - name: allowedRegistries
      configMap:
        name: registry-allowlist
        namespace: kyverno-policies
        # cacheEnabled: true  # 默认启用，可显式关闭
    match:
      any:
      - resources:
          kinds:
          - Pod
    validate:
      message: "镜像仓库不在允许列表中"
      deny:
        conditions:
          any:
          - key: "{{ request.object.spec.containers[].image }}"
            operator: AnyNotIn
            value: "{{ allowedRegistries.data.allowed }}"

4.5 缓存命中率监控指标

Kyverno 暴露 Prometheus 指标用于监控缓存性能，关键指标包括：

• kyverno_cache_hits_total：缓存命中次数
• kyverno_cache_misses_total：缓存未命中次数
• kyverno_cache_entries：当前缓存条目数
• kyverno_cache_request_duration_seconds：缓存请求延迟分布