2. Kubernetes 资源配额基础：ResourceQuota 对象定义、作用域、核心字段

ResourceQuota 是 Kubernetes 内置的准入控制机制，用于限制命名空间（Namespace）级别的资源消耗总量。当 Operator 控制循环与资源配额冲突时，根本原因往往在于 Operator 创建的 Pod/Job 超出了配额限制，导致调度失败或驱逐。理解 ResourceQuota 的对象定义、作用域和核心字段，是定位此类瓶颈的前提。

2.1 ResourceQuota 对象定义

ResourceQuota 是一个 Kubernetes API 对象，通过 YAML 或 JSON 声明式配置。以下是一个典型的 ResourceQuota 定义示例：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-quota
  namespace: production
spec:
  hard:
    requests.cpu: "4"
    requests.memory: "8Gi"
    limits.cpu: "8"
    limits.memory: "16Gi"
    persistentvolumeclaims: "10"
    pods: "50"
  scopeSelector:
    matchExpressions:
      - operator: In
        scopeName: PriorityClass
        values:
          - high-priority

该示例定义了一个名为 compute-quota 的 ResourceQuota，作用于 production 命名空间。它限制了 CPU 请求总量不超过 4 核、内存请求不超过 8Gi，同时限制了 Pod 数量不超过 50 个。通过 scopeSelector，该配额仅对 high-priority 优先级类的 Pod 生效。

2.2 作用域（Scope）与 scopeSelector

ResourceQuota 的作用域决定了配额约束的生效范围。Kubernetes 支持以下标准作用域：

scopeSelector 字段提供了更精细的匹配能力，支持 In、NotIn、Exists、DoesNotExist 四种操作符。当 Operator 创建 Pod 时，如果 Pod 的标签或优先级类与 scopeSelector 不匹配，该 ResourceQuota 将不会对其生效。

2.3 核心字段：hard

hard 字段是 ResourceQuota 的核心，定义了命名空间内资源消耗的硬性上限。它支持两类资源：

• 计算资源： requests.cpu、requests.memory、limits.cpu、limits.memory、requests.ephemeral-storage、limits.ephemeral-storage
• 对象数量： pods、services、persistentvolumeclaims、configmaps、secrets、replicationcontrollers、resourcequotas、services.nodeports、services.loadbalancers

当命名空间内资源使用量达到 hard 上限时，Kubernetes 准入控制器会拒绝后续的资源创建请求，并返回 403 Forbidden 错误。Operator 控制循环在创建 Pod 或 PVC 时，必须处理此类错误并实现重试或降级逻辑。

2.4 ResourceQuota 与 Operator 控制循环的交互关系

下图展示了 ResourceQuota 在 Operator 控制循环中的位置及其对资源创建的影响：

2.5 多个 ResourceQuota 的叠加规则

一个命名空间可以定义多个 ResourceQuota 对象。当多个配额同时生效时，Kubernetes 遵循以下叠加规则：

• 取并集约束： 所有匹配的 ResourceQuota 的 hard 字段共同构成约束集合。例如，Quota A 限制 pods: 20，Quota B 限制 pods: 30，则实际 Pod 上限为 20（取最小值）。
• 作用域隔离： 不同作用域的 ResourceQuota 互不干扰。例如，BestEffort 配额与 NotBestEffort 配额独立计算。
• 优先级类隔离： 通过 scopeSelector 匹配不同优先级类的配额，可以实现多级资源池。

2.6 核心字段速查表