4. 资源配额模型（Resource Quota Model）基础：Kubernetes ResourceQuota 对象、命名空间级别配额、配额范围与作用域

资源配额模型是 Kubernetes 多租户与资源治理的基石。通过 ResourceQuota 对象，平台团队可以在命名空间级别设定资源消耗的硬性上限，防止单个团队或应用“资源饥饿”导致集群不稳定。在 Admission Policy 校验发布包完整性的场景中，ResourceQuota 是策略即代码必须验证的“前置条件”——只有配额模型正确配置，后续的资源声明（如 Pod 的 requests/limits）才有合规基准。

4.1 ResourceQuota 对象核心结构

ResourceQuota 是一个命名空间作用域的 Kubernetes 原生对象，其核心由 spec.hard 字段定义资源上限。以下是一个典型的 ResourceQuota YAML 定义：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-quota
  namespace: team-alpha
spec:
  hard:
    requests.cpu: "4"
    requests.memory: "8Gi"
    limits.cpu: "8"
    limits.memory: "16Gi"
    persistentvolumeclaims: "5"
    pods: "20"
    configmaps: "10"
    services: "10"
    secrets: "10"

该对象同时限制了计算资源（CPU/内存）和对象数量（Pod、PVC、ConfigMap 等）。当命名空间内资源总和超过 hard 阈值时，API Server 会拒绝后续创建请求。

4.2 命名空间级别配额：隔离与共享的边界

ResourceQuota 的生效范围严格限定在单个命名空间内。这种设计实现了以下目标：

• 租户隔离：每个团队或项目拥有独立的命名空间，配额互不干扰。
• 公平调度：避免某个命名空间耗尽集群全部资源。
• 成本核算：通过配额使用量可量化每个命名空间的资源消耗。

4.3 配额范围与作用域

ResourceQuota 支持通过 spec.scopes 字段限定配额生效的 Pod 状态或 QoS 类别，从而实现更精细的资源控制。下表列出了 Kubernetes 支持的配额范围：

使用范围时，ResourceQuota 的 hard 字段只能包含与该范围兼容的资源类型。例如，BestEffort 范围下不能设置 requests.cpu，因为 BestEffort Pod 不设置 requests。

4.4 配额作用域选择器（ScopeSelector）

对于 PriorityClass 等更灵活的范围匹配，Kubernetes 提供了 scopeSelector 机制。以下示例为高优先级 Pod 单独设置配额：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: high-priority-quota
  namespace: team-alpha
spec:
  hard:
    pods: "10"
    requests.cpu: "8"
    requests.memory: "16Gi"
  scopeSelector:
    matchExpressions:
      - operator: In
        scopeName: PriorityClass
        values:
          - high-priority

4.5 资源配额模型与 Admission Policy 的关联

在策略即代码的发布包完整性校验中，ResourceQuota 模型是以下策略规则的输入源：

• 配额存在性校验：目标命名空间是否已创建 ResourceQuota？
• 配额覆盖度校验：ResourceQuota 是否覆盖了发布包中所有声明的资源类型（如 CPU、内存、PVC）？
• 配额阈值合理性校验：发布包中 Pod 的 requests/limits 总和是否超过配额上限？

下图展示了 ResourceQuota 在 Kubernetes 资源治理中的位置及其与 Admission Policy 的交互关系：

4.6 配额模型设计原则

在构建资源配额模型时，应遵循以下原则以确保与策略即代码的兼容性：

1. 全覆盖原则：每个命名空间至少有一个 ResourceQuota，覆盖所有可计费资源类型。
2. 分层配额原则：使用 scopeSelector 为不同优先级或生命周期的工作负载设置独立配额池。
3. 预留缓冲原则：配额上限应略高于预期使用量（通常 110%~120%），避免因微小的资源波动导致 Pod 创建失败。
4. 审计可追溯原则：ResourceQuota 的 metadata.annotations 中记录配额审批人、有效期等元数据，供策略引擎审计。

4.7 常见配置陷阱与避坑指南