2. 资源配额模型基础：Kubernetes 资源配额（ResourceQuota）的定义、字段解析与典型配置

在 Kubernetes 多租户或团队共享集群场景中，资源配额（ResourceQuota）是防止“吵闹邻居”效应、保障集群稳定性的第一道防线。ResourceQuota 通过声明式配置限制命名空间（Namespace）级别的聚合资源消耗，是 OPA 策略审计中衡量“配置漂移”的基准线之一。

2.1 ResourceQuota 核心定义与作用域

ResourceQuota 是 Kubernetes 内置的准入控制机制，作用于命名空间级别。它定义了一个命名空间内所有 Pod 可消耗的计算资源（CPU、内存）与对象数量（Pod、Service、PVC 等）的上限。一旦配额被创建，任何超出配额范围的创建或更新请求都会被 API Server 拒绝。

2.2 字段解析：ResourceQuota 的 Spec 结构

一个标准的 ResourceQuota YAML 定义包含 apiVersion、kind、metadata 和 spec。核心逻辑集中在 spec.hard 字段中，该字段是一个键值对映射，支持以下三类资源维度：

2.3 典型配置示例与解析

以下是一个面向“生产级微服务命名空间”的 ResourceQuota 配置，它同时限制了计算资源上限和关键对象数量：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: production-quota
  namespace: team-alpha
spec:
  hard:
    # 计算资源：所有 Pod 的 requests 总和上限
    requests.cpu: "20"
    requests.memory: "40Gi"
    # 计算资源：所有 Pod 的 limits 总和上限
    limits.cpu: "40"
    limits.memory: "80Gi"
    # 存储资源：PVC 总容量上限
    requests.storage: "500Gi"
    # 对象数量：核心资源
    count/pods: "50"
    count/services: "10"
    count/configmaps: "30"
    count/secrets: "30"
    count/persistentvolumeclaims: "20"
    # 对象数量：扩展资源（Apps 组）
    count/deployments.apps: "10"
    count/statefulsets.apps: "5"

该配置的审计要点：

• 资源比例： limits.cpu 是 requests.cpu 的 2 倍，允许一定程度的突发，但防止无限超卖。
• 对象上限： Pod 上限 50 个，Deployment 上限 10 个，平均每个 Deployment 可管理 5 个 Pod，符合微服务典型密度。
• 存储隔离： PVC 数量与总容量双重限制，防止存储资源被单个应用耗尽。

2.4 ResourceQuota 的 Scope 与优先级

ResourceQuota 支持通过 spec.scopes 字段实现更精细的资源隔离。Scope 决定了配额适用的 Pod 类别：

2.5 ResourceQuota 状态与漂移检测点

ResourceQuota 的 status 字段记录了当前命名空间的实际资源消耗，是 OPA 审计“配置漂移”的关键数据源：

status:
  hard:
    requests.cpu: "20"
    requests.memory: 40Gi
  used:
    requests.cpu: "12"
    requests.memory: 25Gi

OPA 策略通过对比 status.hard（期望值）与 status.used（实际值），可以判断资源利用率是否异常。但“配置漂移”审计的核心是：比较当前生效的 ResourceQuota 对象与 Git 仓库中的基线配置是否一致。任何对 spec.hard 中字段值的修改（如将 requests.cpu 从 “20” 改为 “40”），即使未导致资源超限，也属于配置漂移。

2.6 典型配置模式对比

在实际生产环境中，ResourceQuota 的配置模式通常分为以下三种，OPA 审计策略需要针对不同模式调整漂移检测的敏感度：