📚 课程目录第4章资源配额模型基础

4. 资源配额模型基础：Kubernetes ResourceQuota 与 LimitRange 机制、命名空间级别配额

在云原生网关的规模化部署中，资源争抢是导致性能抖动和稳定性事故的首要原因。Kubernetes 通过 ResourceQuota 和 LimitRange 两个原生准入控制机制，在命名空间级别建立资源配额模型，确保 Ingress 控制器、后端服务与系统组件之间公平、可控地共享集群资源。本章深入剖析这两类对象的原理、配置策略及在网关场景下的最佳实践。

4.1 命名空间资源隔离与配额模型

Kubernetes 命名空间（Namespace）是资源配额的第一道边界。每个命名空间可以独立设置 ResourceQuota，限制该空间内所有 Pod 的 CPU、内存、存储以及 对象数量（如 Services、ConfigMaps、Secrets）。对于网关集群，通常将生产、预发、测试环境分别置于不同命名空间，并配置差异化的配额阈值。

  核心原则：ResourceQuota 只限制 requests 和 limits 的总和，不直接限制单个 Pod 的规格；LimitRange 则用于约束单个 Pod 或容器的资源上下界。

网关场景提示：Ingress 控制器（如 Nginx Ingress、Envoy Gateway）通常以 DaemonSet 或 Deployment 形式运行，其资源消耗与流量吞吐量强相关。建议为 Ingress 控制器所在命名空间单独设置较高的 CPU 和内存配额，并配合 PriorityClass 保障其调度优先级。

4.2 ResourceQuota 对象详解

ResourceQuota 是一个命名空间级别的 API 对象，通过准入控制器在 Pod 创建或更新时校验资源总和是否超出配额。以下是一个针对网关集群的 ResourceQuota 示例：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: gateway-quota
  namespace: production-gateway
spec:
  hard:
    requests.cpu: "16"
    requests.memory: "32Gi"
    limits.cpu: "32"
    limits.memory: "64Gi"
    persistentvolumeclaims: "10"
    services: "20"
    configmaps: "30"
    secrets: "30"
    count/ingresses.extensions: "50"
    count/ingresses.networking.k8s.io: "50"

关键字段说明：

字段	含义	网关场景建议值
`requests.cpu / requests.memory`	所有 Pod 的 request 总和上限	根据 Ingress 副本数与预期吞吐量计算，通常预留 20% 余量
`limits.cpu / limits.memory`	所有 Pod 的 limit 总和上限	建议为 request 的 1.5~2 倍，避免突发流量导致 OOM
`count/ingresses.*`	Ingress 资源对象数量上限	根据域名和路由规则数量设定，防止 Ingress 对象泛滥
`services / configmaps / secrets`	关联对象数量上限	与 Ingress 引用的后端 Service 和 TLS Secret 数量匹配

常见陷阱：ResourceQuota 只对 处于 Active 状态 的命名空间生效。如果命名空间被标记为 Terminating，配额校验会跳过。另外，ResourceQuota 无法限制 Init Container 或 Ephemeral Container 的资源，需要额外通过 OPA/Gatekeeper 策略补充。

4.3 LimitRange 对象详解

LimitRange 在命名空间级别设置 默认资源请求/限制 以及 最小/最大约束。当 Pod 未显式设置资源字段时，LimitRange 会自动注入默认值；同时，它还能阻止用户创建超出合理范围的超大或超小容器。

apiVersion: v1
kind: LimitRange
metadata:
  name: gateway-limits
  namespace: production-gateway
spec:
  limits:
  - max:
      cpu: "4"
      memory: "8Gi"
    min:
      cpu: "100m"
      memory: "128Mi"
    default:
      cpu: "500m"
      memory: "1Gi"
    defaultRequest:
      cpu: "200m"
      memory: "512Mi"
    type: Container

LimitRange 的四个核心维度：

max / min：单个容器资源上下限，防止异常 Pod 占用过多资源。
default：当容器未设置 limits 时，自动注入的默认 limit 值。
defaultRequest：当容器未设置 requests 时，自动注入的默认 request 值。
type：可设置为 Container 或 Pod，分别作用于容器级别和 Pod 级别。

  网关最佳实践：为 Ingress 控制器容器设置 min: cpu: 200m, memory: 512Mi，避免因资源过小导致频繁 OOMKill；同时设置 max: cpu: 4, memory: 8Gi，防止单个副本过度抢占节点资源。

4.4 配额模型架构图

下图展示了 ResourceQuota 与 LimitRange 在命名空间内的协同工作流程：

4.5 配额冲突与调试策略

当 ResourceQuota 与 LimitRange 同时生效时，可能产生以下冲突场景：

场景	现象	根因	解决方案
Pod 未设置资源字段	Pod 创建失败，提示 "failed quota"	LimitRange 未配置 defaultRequest，或默认值超出配额剩余量	为 LimitRange 设置合理的 default 和 defaultRequest
单个容器资源超限	Pod 被 LimitRange 拒绝	容器 spec 中 resources.limits 超过 LimitRange.max	调整容器资源请求，或放宽 LimitRange.max
命名空间总资源超限	Pod 创建失败，ResourceQuota 拒绝	当前命名空间已用资源 + 新 Pod 资源 > 配额 hard 值	扩容集群节点，或清理闲置 Pod
Ingress 对象数量超限	Ingress 创建失败	`count/ingresses.*` 配额已满	合并 Ingress 规则，或提升配额上限

调试命令：
kubectl describe quota -n <namespace> — 查看当前配额使用量
kubectl describe limitrange -n <namespace> — 查看 LimitRange 配置
kubectl get events -n <namespace> --field-selector reason=FailedCreate — 查看准入控制拒绝事件

4.6 网关场景下的配额策略建议

基于生产环境经验，为 Ingress 控制器及其关联资源推荐以下配额策略：

Ingress 控制器命名空间：CPU request 总和 = 预期副本数 × 单副本 CPU request × 1.2（安全系数）；内存同理。设置 count/ingresses.* 上限为预期域名数的 1.5 倍。
后端服务命名空间：CPU request 总和 = 所有微服务 request 之和 × 1.1；内存 request 总和 = 所有微服务 request 之和 × 1.2。设置 count/services 上限为微服务数量的 1.3 倍。
系统组件命名空间（如 kube-system）：建议不设置 ResourceQuota，或设置极高的软配额，避免系统组件因配额不足而异常。
LimitRange 默认值：对于 Ingress 控制器，defaultRequest 建议为 cpu: 200m, memory: 512Mi；对于普通业务容器，defaultRequest 建议为 cpu: 100m, memory: 256Mi。

  性能优化关联：合理的资源配额模型能避免 CPU 节流（Throttling）和内存 OOM，间接提升 Ingress 控制器的连接处理能力和 TLS 握手性能。建议在压测前先验证配额是否成为瓶颈。

4.7 配额模型与集群自动伸缩的协同

ResourceQuota 与 Cluster Autoscaler 配合时，需注意以下要点：

配额不足触发扩容：当命名空间资源配额耗尽，但集群节点仍有空闲资源时，Cluster Autoscaler 不会自动扩容。需要手动调整 ResourceQuota 的 hard 值。
节点资源不足触发扩容：当节点资源不足导致 Pod Pending 时，Cluster Autoscaler 会扩容节点，但 ResourceQuota 仍可能阻止 Pod 创建。此时应优先检查配额使用量。
最佳实践：将 ResourceQuota 的 hard 值设置为集群总容量的 80%~90%，预留部分资源给系统组件和突发扩容。

下图展示了配额模型与集群自动伸缩的交互关系：

4.8 本章小结

ResourceQuota 和 LimitRange 是 Kubernetes 资源配额模型的基石，为云原生网关提供了命名空间级别的资源隔离与约束能力。通过合理配置配额硬限制、默认资源值以及对象数量上限，可以有效防止资源争抢、提升集群稳定性，并为 Ingress 控制器的性能优化奠定基础。在生产环境中，建议将配额策略与监控告警、集群自动伸缩联动，形成完整的资源治理闭环。