机制定位
ResourceQuota 给命名空间设总量上限：按所有 Pod 的 requests/limits 求和限制 CPU 与内存，也可以限制对象数量（Pod 数、Service 数、LoadBalancer 数等）。适用平台是 Kubernetes。它的作用是防止某个命名空间把整集群资源吃光，代价是触顶后新对象会被拒绝创建——报错信息会明确写 exceeded quota，属于典型的「突然部署不上」现场。
基本信息
| 适用平台 | Kubernetes，命名空间级对象（v1/ResourceQuota） |
|---|---|
| 统计对象 | 命名空间内 Pod 的 requests 与 limits，以及各类对象数量 |
| 触顶行为 | 创建或更新被准入层拒绝，报 exceeded quota |
| 配套对象 | LimitRange 可提供默认 requests/limits，配合配额使用 |
典型使用场景
- 多团队共享集群：为每个命名空间设上限，避免互相争抢
- 成本治理：限制 LoadBalancer、PVC 总量这类会直接产生费用的资源
- 环境隔离：测试环境给更小的配额，防止误把压测流量打满集群
- 排查创建失败：确认是被配额拒绝而不是被调度器拒绝
- 容量预留：通过配额把关键命名空间需要的资源先占住
配额示例
配额示例
apiVersion: v1
kind: ResourceQuota
metadata:
name: prod-quota
namespace: prod
spec:
hard:
requests.cpu: "20"
requests.memory: 40Gi
limits.cpu: "40"
limits.memory: 80Gi
pods: "100"
services.loadbalancers: "5"查看用量
查看用量
kubectl get resourcequota -n prod # 概览
kubectl describe resourcequota prod-quota -n prod # 已用与硬上限对照
kubectl get resourcequota prod-quota -n prod -o jsonpath='{.status.used}'
kubectl get events -n prod --field-selector reason=FailedCreate --sort-by=.lastTimestamp | tail -5常见报错与含义
| 报错关键词 | 含义 | 处理 |
|---|---|---|
| exceeded quota: pods | Pod 数量已达上限 | 清理无用 Pod 或调大配额 |
| exceeded quota: requests.cpu | requests 之和超上限 | 下调申请量或扩容配额 |
| must specify requests.cpu | 有配额要求但 Pod 未写 requests | 补 requests 或用 LimitRange 兜底 |
| exceeded quota: services.loadbalancers | 负载均衡类 Service 数量超限 | 回收闲置入口或调整配额 |
配额开启后，新建 Pod 必须写 requests/limits（或由 LimitRange 提供默认值），否则直接被拒，这是新命名空间最容易被卡住的一步。
「已用」统计的是 requests 之和而不是实际使用量：配额满不等于节点没资源，反过来配额宽松也可能因为节点容量不足而 Pending。
配置与维护要点
- 配额落地前先定基线：按命名空间的真实用量留出余量再设上限，避免上线当天就触顶
- 配合 LimitRange 设默认值：否则新建 Pod 没写 requests 会被直接拒绝
- 对象数量与资源量一起管：只限 CPU 内存时，空对象仍会大量堆积
- 配额调整要留观察期：下调后任何更新都可能被拒，先盘点存量再分批调整