4. 资源配额模型理论基础：Kubernetes ResourceQuota 与 LimitRange 的工作原理与设计哲学

在 Ingress 网关性能调优的语境下，资源配额模型是控制平面稳定性的第一道防线。Kubernetes 通过 ResourceQuota 和 LimitRange 两个原生准入控制器，实现了从“命名空间级总量约束”到“Pod/容器级默认值与边界约束”的立体资源治理。理解它们的设计哲学，是后续配置 Ingress 控制器 QoS 策略的前提。

4.1 设计哲学：两层约束 vs. 单一限制

Kubernetes 的资源配额体系遵循“总量控制 + 个体边界”的双层设计：

• ResourceQuota（总量配额）：作用于命名空间级别，限制该命名空间下所有 Pod 的资源总和上限。它解决的是“多租户抢占”问题，防止单个团队或应用耗尽集群资源。
• LimitRange（个体边界）：作用于 Pod 或容器级别，为未显式设置资源请求/限制的容器提供默认值，并强制每个容器的资源上下界。它解决的是“配置遗漏与越界”问题，确保每个工作负载都有合理的资源声明。

4.2 ResourceQuota：命名空间级总量控制

ResourceQuota 是一个命名空间级别的 API 对象，它定义了一组资源配额，包括计算资源（CPU、内存）、存储资源（PVC 容量、存储类）以及对象数量（Pod、Service、ConfigMap 等）。当创建或更新资源时，Kubernetes 准入控制器会检查当前命名空间的使用量是否超出配额。

4.2.1 核心字段与示例

apiVersion: v1
kind: ResourceQuota
metadata:
  name: ingress-gateway-quota
  namespace: ingress-system
spec:
  hard:
    requests.cpu: "8"          # 所有 Pod CPU 请求总和不超过 8 核
    requests.memory: "16Gi"    # 所有 Pod 内存请求总和不超过 16 Gi
    limits.cpu: "16"           # 所有 Pod CPU 限制总和不超过 16 核
    limits.memory: "32Gi"      # 所有 Pod 内存限制总和不超过 32 Gi
    pods: "20"                 # 命名空间内最多 20 个 Pod
    services: "10"             # 最多 10 个 Service
    persistentvolumeclaims: "5" # 最多 5 个 PVC

4.2.2 配额类型对比

4.3 LimitRange：容器级默认值与边界

LimitRange 在命名空间级别设置默认的资源请求/限制，并强制每个容器的资源上下界。它解决了两个关键问题：

• 默认值注入：当 Pod 未显式设置 resources.requests 或 resources.limits 时，LimitRange 自动注入默认值，避免因配置遗漏导致 Pod 被 OOMKill 或调度失败。
• 边界强制：限制单个容器能申请的最大/最小资源量，防止某个容器过度占用。

4.3.1 典型配置示例

apiVersion: v1
kind: LimitRange
metadata:
  name: ingress-container-limits
  namespace: ingress-system
spec:
  limits:
  - max:                         # 单个容器资源上限
      cpu: "4"
      memory: "8Gi"
    min:                         # 单个容器资源下限
      cpu: "100m"
      memory: "256Mi"
    default:                     # 未设置 limits 时的默认值
      cpu: "1"
      memory: "1Gi"
    defaultRequest:              # 未设置 requests 时的默认值
      cpu: "500m"
      memory: "512Mi"
    type: Container

4.3.2 默认值注入逻辑

4.4 准入控制与校验流程

ResourceQuota 和 LimitRange 通过 Kubernetes 的 准入控制器（Admission Controller） 在资源创建或更新时生效。整个校验流程如下：

1. 请求到达 API Server：用户提交 Pod 或 PVC 创建请求。
2. 认证与鉴权：确认用户身份和权限。
3. 变更准入（Mutating Admission）：LimitRange 控制器注入默认值，修改 Pod 的 resources 字段。
4. 校验准入（Validating Admission）：ResourceQuota 控制器检查当前命名空间使用量 + 新请求量是否超出配额；LimitRange 控制器检查每个容器的资源声明是否在 [min, max] 范围内。
5. 持久化与响应：通过则写入 etcd，拒绝则返回错误。

4.5 设计哲学总结：为什么需要两层模型？

单一的资源限制机制无法同时满足“多租户隔离”和“个体行为规范”两个目标。ResourceQuota 和 LimitRange 的配合体现了 Kubernetes 的“分层治理”设计哲学：

• ResourceQuota 是“经济学”约束：它从经济角度限制一个团队能消耗的总资源量，类似于预算上限。团队内部可以自由分配，但不能超支。
• LimitRange 是“法律”约束：它从法律角度规定每个个体必须遵守的最小和最大资源声明，类似于最低工资和最高工时。防止个体行为破坏整体秩序。
• 两者缺一不可：只有 ResourceQuota 没有 LimitRange，会导致某些 Pod 不声明资源，调度器无法合理分配；只有 LimitRange 没有 ResourceQuota，则无法防止团队创建大量 Pod 耗尽集群资源。