📚 课程目录第2章 Kubernetes资源配额基础

Kubernetes 资源配额基础：ResourceQuota 对象、LimitRange 对象、命名空间隔离

在云原生网关的 Helm 部署场景中，资源配额管理是保障集群稳定性与公平性的第一道防线。Kubernetes 通过 ResourceQuota 和 LimitRange 两个核心 API 对象，结合命名空间（Namespace）的隔离机制，实现了多租户环境下的资源管控。理解这三者的协同关系，是诊断“资源配额模型故障”的前提。

3.1 命名空间隔离：资源配额的作用边界

命名空间是 Kubernetes 实现逻辑隔离的基本单元。ResourceQuota 和 LimitRange 均绑定在特定命名空间上，其生效范围不会跨越命名空间边界。在 Helm 部署网关时，通常为每个网关实例或每个环境（如 dev、staging、prod）创建独立的命名空间，以实现资源配额的独立管理。

  关键原则：ResourceQuota 只对所在命名空间内的 Pod、Service、PVC 等对象生效；跨命名空间的资源请求不受配额约束。

3.2 ResourceQuota 对象：硬性资源上限

ResourceQuota 为命名空间内的所有 Pod 设置聚合资源消耗的上限。当命名空间内的资源使用量达到配额时，Kubernetes 将拒绝新的 Pod 创建请求，并返回 403 Forbidden 错误。这是 Helm 部署网关时最常见的故障触发点之一。

3.2.1 支持的资源维度

资源类型	字段示例	说明
CPU	`requests.cpu: "8"`	所有 Pod CPU request 总和上限
内存	`requests.memory: "32Gi"`	所有 Pod 内存 request 总和上限
存储	`requests.storage: "100Gi"`	所有 PVC 存储请求总和上限
对象数量	`count/pods: "20"`	命名空间内 Pod 总数上限
扩展资源	`requests.nvidia.com/gpu: "2"`	GPU 等自定义资源配额

3.2.2 典型 ResourceQuota 配置示例

apiVersion: v1
kind: ResourceQuota
metadata:
  name: gateway-quota
  namespace: gateway-prod
spec:
  hard:
    requests.cpu: "8"
    requests.memory: "32Gi"
    limits.cpu: "16"
    limits.memory: "64Gi"
    count/pods: "20"
    count/services: "10"
    count/secrets: "20"
    count/configmaps: "20"
    persistentvolumeclaims: "10"

故障排查提示：当 Helm 部署网关时出现 exceeded quota 错误，应首先检查 kubectl describe quota -n <namespace> 查看当前使用量与配额的对比。

3.3 LimitRange 对象：单 Pod 资源约束

LimitRange 在命名空间级别为每个 Pod 或容器设置资源请求（request）和限制（limit）的默认值、最小值与最大值。它解决了两个关键问题：

默认值注入：当 Pod 未显式设置资源 request/limit 时，LimitRange 自动注入默认值。
边界约束：阻止用户创建资源请求超出允许范围的 Pod。

3.3.1 LimitRange 配置示例

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

3.3.2 配额冲突场景

当 ResourceQuota 与 LimitRange 同时存在时，Pod 创建请求必须同时满足两者的约束。以下表格列出了常见的冲突模式：

场景	ResourceQuota 检查	LimitRange 检查	结果
Pod request 超出 LimitRange max	可能通过	拒绝	Pod 创建失败
Pod request 低于 LimitRange min	可能通过	拒绝	Pod 创建失败
Pod 未设置 request，LimitRange 注入默认值	重新计算配额	通过	Pod 创建成功（配额可能超限）
命名空间总 request 超出 ResourceQuota hard	拒绝	通过	Pod 创建失败

3.4 配额模型协同工作流程

当 Helm 部署网关时，Kubernetes 准入控制器（Admission Controller）按以下顺序执行资源配额检查：

LimitRange 默认值注入：如果 Pod 未设置资源 request/limit，LimitRange 自动注入默认值。
LimitRange 边界校验：检查注入后的 request/limit 是否在 min 与 max 范围内。
ResourceQuota 聚合校验：将 Pod 的资源请求累加到命名空间当前使用量，检查是否超出 hard 上限。
最终决策：所有检查通过则创建 Pod，否则返回错误。

3.5 故障排查核心命令

在诊断资源配额相关故障时，以下命令是必备工具：

命令	用途
`kubectl describe quota -n <ns>`	查看命名空间配额使用详情（Used vs Hard）
`kubectl describe limitrange -n <ns>`	查看 LimitRange 配置的 min/max/default 值
`kubectl get pods -n <ns> -o wide`	查看 Pod 状态及所在节点
`kubectl describe pod <pod-name> -n <ns>`	查看 Pod 事件，定位配额拒绝原因
`kubectl get events -n <ns> --sort-by='.lastTimestamp'`	按时间排序查看命名空间事件

常见误区：ResourceQuota 的 limits.cpu 与 requests.cpu 是独立计数的。一个 Pod 可能 request 很小但 limit 很大，导致配额看似充足但实际无法创建。务必同时检查 request 和 limit 两个维度的配额使用量。

3.6 本章小结

命名空间是资源配额的作用边界，不同命名空间的配额相互独立。
ResourceQuota 设置命名空间级别的聚合资源上限，超出后拒绝新 Pod 创建。
LimitRange 设置单 Pod/容器的资源边界，并注入默认值。
两者协同工作，任何一方检查不通过都会导致 Pod 创建失败。
Helm 部署网关时，exceeded quota 和 forbidden 错误通常指向 ResourceQuota 或 LimitRange 配置不当。