Kubernetes 资源配额管理实操：ResourceQuota 与 LimitRange 如何配合

多租户或多团队共用一个 Kubernetes 集群时，最常见的故障不是节点不够，而是某个命名空间把配额吃光，其他业务跟着无法创建 Pod。本文把 ResourceQuota 和 LimitRange 分开讲清楚：前者管命名空间的总量上限，后者管单个容器和 Pod 的默认值与上下限，两者配合才能既防超用，又不让合理扩容被误杀。

一、两者分工

ResourceQuota 是命名空间级别的硬上限，统计该命名空间内所有 Pod 的 requests、limits、CPU、内存、Pod 数量、PVC 数量、Service 数量等，超了就拒绝创建。LimitRange 是命名空间内的准入默认值与单体约束：容器没写 requests 或 limits 时自动补默认值，同时限制单个容器、单个 Pod 的最小和最大资源，防止一个容器写出离谱的数值。

只配 Quota 不配 LimitRange，容易出现单个 Pod 占满大半配额；只配 LimitRange 不配 Quota，命名空间整体仍可能被大量小 Pod 拖垮。所以生产上两者通常成对出现。

二、ResourceQuota 示例

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-a-quota
  namespace: team-a
spec:
  hard:
    requests.cpu: "20"
    requests.memory: 40Gi
    limits.cpu: "40"
    limits.memory: 80Gi
    pods: "50"
    persistentvolumeclaims: "20"

注意区分 requests 和 limits：requests 决定调度，limits 决定运行期上限。只限 limits 不限 requests，调度器仍可能把超量 Pod 排到节点上；只限 requests 不限 limits，单个 Pod 仍可能在节点上抢占大量 CPU 或内存。

三、LimitRange 示例

apiVersion: v1
kind: LimitRange
metadata:
  name: team-a-limits
  namespace: team-a
spec:
  limits:
    - type: Container
      default:
        cpu: 500m
        memory: 512Mi
      defaultRequest:
        cpu: 200m
        memory: 256Mi
      max:
        cpu: "4"
        memory: 8Gi
      min:
        cpu: 100m
        memory: 128Mi
    - type: Pod
      max:
        cpu: "8"
        memory: 16Gi

默认值不是越大越安全：默认值过高会快速耗尽配额，过低则让应用在内存压力下频繁被 OOMKill。先按压测和线上监控定一个保守默认值，再按服务分级调整。

四、排错顺序

遇到创建 Pod 被拒绝时，按这个顺序查，不要先调大配额：

1. 看报错原文：如果是 Forbidden exceeded quota，说明是配额问题；如果是 LimitRange 校验失败，说明是单体上下限或默认值冲突。
2. 查配额使用情况：kubectl -n team-a describe quota team-a-quota，确认是 CPU、内存、Pod 数还是 PVC 数先到顶。
3. 查实际占用：kubectl -n team-a get pods，配合 top 或监控，区分是真实业务增长，还是僵尸 Pod、失败重试、测试 Pod 没清理。
4. 查 LimitRange：kubectl -n team-a describe limitrange，确认新 Pod 的 requests 或 limits 是否超出单体最大值，或低于最小值。
5. 先清理再扩容：删掉已完成、无用的 Job Pod 和测试资源，确认仍不足再按比例上调配额，并同步调整 LimitRange 的默认值，避免下次又被默认值拖垮。

五、落地建议

• 按环境分命名空间：开发、测试、生产分开配额，测试环境的配额不要和生产共用一个上限。
• 配额留出缓冲：不要把配额正好等于当前用量，突发扩容、滚动升级期间新旧 Pod 并存会短暂双倍占用。
• 定期复核：每月看一次配额使用率，长期低于 30% 的命名空间可以下调，长期高于 80% 的要提前扩容或拆分命名空间。
• 变更要留痕：配额调整属于影响所有业务的变更，记录调整原因、旧值、新值和生效时间，方便回滚。

配额管理本质是成本与稳定性的权衡：太松会让个别业务拖垮整集群，太紧会让正常扩容频繁失败。先把总量、单体、默认值三层讲清楚，再按监控数据调数值，比凭感觉拍一个大数字更可靠。