📚 课程目录第4章缓存机制原理

4、资源配额（ResourceQuota）基础：Namespace级别配额、CPU/内存限制、对象数量限制

在 Kubernetes 集群中，资源配额（ResourceQuota）是保障多租户隔离与集群稳定性的核心机制。它通过 Namespace 级别的策略，限制一个租户（团队、项目）能够消耗的集群资源总量，防止单个 Namespace 的“资源饥饿”行为影响其他租户。对于 Secrets 管理而言，资源配额直接决定了缓存组件的部署规格、可缓存的对象数量上限，以及缓存命中率调优的物理边界。

4.1 ResourceQuota 的核心作用域

ResourceQuota 作用于 Namespace 级别，一旦创建，即对该 Namespace 内的所有 Pod、Service、PersistentVolumeClaim 等对象生效。它主要管理三类资源：

资源类别	管理对象	典型配额项	对 Secrets 缓存的影响
计算资源	Pod 容器	requests.cpu, requests.memory, limits.cpu, limits.memory	限制缓存代理（如 sidecar 或 DaemonSet）的 CPU/内存上限，影响缓存容量与查询吞吐
存储资源	PersistentVolumeClaim	requests.storage, persistentvolumeclaims	限制缓存后端（如 Redis、本地磁盘）的持久化存储大小
对象数量	Kubernetes 资源	count/secrets, count/configmaps, count/pods, count/services	直接限制 Namespace 内可创建的 Secrets 总数，决定缓存最大条目数

关键认知： 在 Secrets 缓存调优场景中，count/secrets 配额决定了缓存容量的硬上限；limits.memory 决定了缓存数据结构（如哈希表、LRU 链表）能占用的最大内存。两者共同约束了缓存命中率的上限。

4.2 计算资源配额：CPU 与内存限制

计算资源配额通过 requests（预留）和 limits（上限）两个维度进行控制。对于 Secrets 缓存组件，推荐使用 Guaranteed QoS（即 requests == limits）来避免因资源争抢导致的缓存抖动。

apiVersion: v1
kind: ResourceQuota
metadata:
  name: cache-quota
  namespace: team-alpha
spec:
  hard:
    requests.cpu: "4"
    requests.memory: "8Gi"
    limits.cpu: "8"
    limits.memory: "16Gi"
    count/secrets: "500"

上述配额意味着：

该 Namespace 所有 Pod 的 CPU 请求总和不超过 4 核，限制总和不超过 8 核。
内存请求总和不超过 8 GiB，限制总和不超过 16 GiB。
Secrets 对象总数不超过 500 个。

常见陷阱： 如果缓存组件的 limits.memory 设置过高，但 Namespace 总配额不足，Pod 将无法调度。反之，如果 requests.memory 设置过低，缓存组件可能因内存不足被 OOMKill，导致缓存数据丢失、命中率骤降。

4.3 对象数量配额：Secrets 与 ConfigMaps

对象数量配额直接限制了 Namespace 内可创建的资源实例数。对于 Secrets 缓存，count/secrets 是最直接的约束。此外，count/configmaps 也可能影响缓存策略（如果缓存依赖 ConfigMap 存储配置）。

配额项	API 组	作用范围	缓存调优建议
count/secrets	核心组 (v1)	所有 Secrets 类型（Opaque, TLS, dockerconfigjson 等）	设置缓存最大条目数 = 配额值的 80%，预留 20% 给突发创建
count/configmaps	核心组 (v1)	所有 ConfigMaps	如果缓存配置热更新依赖 ConfigMap，需预留配额
count/pods	核心组 (v1)	所有 Pod（包括静态 Pod）	限制缓存代理 Pod 的最大副本数，影响缓存集群规模
count/services	核心组 (v1)	所有 Service	限制缓存服务发现端点数量

4.4 配额与缓存命中率的关联模型

下图展示了 ResourceQuota 如何从三个维度约束 Secrets 缓存系统，并最终影响缓存命中率。

4.5 配额冲突排查与缓存调优实践

当 Secrets 缓存命中率低于预期时，应首先检查 ResourceQuota 是否成为瓶颈。以下是标准排查流程：

查看 Namespace 配额使用量：

kubectl get resourcequota -n team-alpha -o yaml
kubectl describe quota cache-quota -n team-alpha

检查缓存组件是否被限流： 查看 Pod 的 resources 字段是否接近配额上限，以及是否出现 OOMKill 或 CPU Throttling。
评估 Secrets 数量与缓存容量的比例： 如果 count/secrets 使用量达到配额的 90% 以上，缓存淘汰将频繁发生，命中率会显著下降。
调整策略：
- 增加 limits.memory 配额以扩大缓存容量。
- 增加 count/secrets 配额以容纳更多 Secrets。
- 优化缓存淘汰算法（如 LRU → LFU）以适应配额约束。

  调优黄金法则： 缓存命中率 ≈ min(1, 缓存容量 / 活跃 Secrets 总数)。在 ResourceQuota 约束下，缓存容量 = min(内存配额可支撑的条目数, count/secrets 配额值)。因此，提升命中率的核心是让这两个配额值匹配实际工作负载的活跃 Secrets 规模。

4.6 多维度配额组合示例

以下是一个面向 Secrets 缓存系统的完整 ResourceQuota 配置示例，展示了如何同时约束计算、存储和对象数量：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: secrets-cache-quota
  namespace: production
spec:
  hard:
    # 计算资源
    requests.cpu: "8"
    requests.memory: "32Gi"
    limits.cpu: "16"
    limits.memory: "64Gi"
    # 对象数量
    count/secrets: "2000"
    count/configmaps: "500"
    count/pods: "100"
    count/services: "50"
    # 存储资源
    requests.storage: "500Gi"
    persistentvolumeclaims: "20"

该配额为缓存系统预留了充足的资源边界：64Gi 内存上限可支撑约 200 万个 Secrets 条目（按每个条目 32KB 估算），而 2000 个 Secrets 的对象配额则成为实际硬限制。缓存命中率将主要受限于 count/secrets 而非内存。