2. 资源配额模型基础：Kubernetes ResourceQuota 原理、作用域、与 Gateway API 的关系

在云原生环境中，多团队共享集群是常态。若缺乏资源约束，单个应用的异常流量或资源泄漏可能引发“吵闹邻居”效应，导致整个集群不稳定。Kubernetes ResourceQuota 是集群管理员控制命名空间资源消耗的核心策略工具。本章将剖析 ResourceQuota 的工作原理、作用域模型，并重点分析它与 Gateway API 资源配额模型的衔接关系。

2.1 ResourceQuota 核心原理

ResourceQuota 是一个命名空间级别的 API 对象，用于限制该命名空间内所有 Pod 和资源的累计使用量。它通过准入控制器（Admission Controller）在资源创建或更新时进行校验，确保总量不超过配额上限。

2.1.1 资源类型与配额维度

ResourceQuota 支持三类资源维度：

2.1.2 配额作用域（Scope）

ResourceQuota 支持通过 spec.scopeSelector 将配额约束限定到特定范围的 Pod，避免“一刀切”。常见作用域包括：

• Terminating / NotTerminating：区分设置了 activeDeadlineSeconds 的 Pod（如 Job）与长期运行的 Pod（如 Deployment）。
• BestEffort / NotBestEffort：区分 QoS 等级为 BestEffort（未设置 requests/limits）的 Pod 与有资源保障的 Pod。
• PriorityClass：按优先级类划分配额，高优先级任务可占用更多资源。

2.2 ResourceQuota 与 Gateway API 的关系

Gateway API 本身不直接定义 ResourceQuota，但它的资源配额模型建立在 Kubernetes 原生配额体系之上。理解两者的关系，有助于设计合理的多租户网关策略。

2.2.1 资源映射模型

Gateway API 中的核心资源（Gateway、HTTPRoute、ReferenceGrant）在集群中表现为 CRD 对象。ResourceQuota 可以通过 count/gateways.networking.x-k8s.io 等语法直接限制其数量。

apiVersion: v1
kind: ResourceQuota
metadata:
  name: gateway-quota
  namespace: team-a
spec:
  hard:
    count/gateways.gateway.networking.k8s.io: "2"
    count/httproutes.gateway.networking.k8s.io: "10"
    requests.cpu: "4"
    requests.memory: "8Gi"

2.2.2 间接资源约束

Gateway API 资源会间接消耗集群计算资源：

• Gateway 控制器 Pod：每个 Gateway 实例通常对应一个数据面代理 Pod（如 Envoy），其 CPU/内存受命名空间 ResourceQuota 约束。
• Secret 与证书：TLS 终止所需的 Secret 数量受 count/secrets 配额限制。
• Service 与 EndpointSlice：HTTPRoute 引用的后端 Service 数量受对象配额限制。

2.3 配额作用域在 Gateway 场景中的应用

通过作用域组合，可以实现精细化的网关资源隔离：

2.4 ResourceQuota 与 Gateway API 配额模型对比

下表梳理了两者在配额管理上的定位差异：

2.5 内联 SVG：ResourceQuota 与 Gateway API 配额交互架构

2.6 常见故障排查要点

在配置 ResourceQuota 与 Gateway API 时，以下问题需重点关注：

• 配额不足导致 Gateway 创建失败：检查 kubectl describe quota -n <namespace> 确认当前使用量。
• 数据面 Pod 处于 Pending 状态：查看 Pod 事件，确认是否因 CPU/内存配额不足无法调度。
• 作用域冲突：确保 Gateway 控制面 Pod 的 QoS 等级与作用域匹配，避免被错误排除在配额之外。
• CRD 配额未生效：确认 ResourceQuota 中使用了正确的资源名称格式 count/<resource>.<group>。