ResourceQuota是Kubernetes中限制命名空间级资源总量的机制，通过hard字段设置CPU、内存、存储及对象数量上限；需与LimitRange配合使用以确保配额生效。
在 Kubernetes 中，ResourceQuota 是限制命名空间级别资源总量的核心机制，它不分配资源，而是设置“上限”，防止某个命名空间无节制地消耗集群资源。正确配置 ResourceQuota 能有效避免因单个命名空间抢占过多 CPU、内存或对象数量而影响其他业务。
ResourceQuota 的作用范围和关键字段
ResourceQuota 必须定义在具体命名空间内（不能跨命名空间生效），它通过
hard
字段声明该命名空间允许使用的资源总量上限，支持三类限制：
计算资源
：如
、
、
、
—— 控制 Pod 请求/限制的总和
存储资源
：如
、
—— 限制 PVC 或临时存储总量
对象数量
：如
、
、
、
、
等 —— 防止元数据爆炸
创建一个典型的 ResourceQuota 示例
以下 YAML 限制命名空间
最多使用 4 核 CPU、8Gi 内存、20 个 Pod 和 10 个 Service：
注意：
和
是独立统计的；若未设
，Pod 可不设 limit，但受
约束；所有数值必须带单位（如
、
、
）。
验证与排查配额是否生效
配额创建后不会自动拒绝超限请求，而是由 API Server 在创建/更新资源时实时校验。可通过以下方式确认状态：
运行
查看当前已用配额（
）和剩余（
）
尝试创建超出配额的 Pod，会收到类似错误：
检查事件：
配合 LimitRange 实现更精细控制
ResourceQuota 管“总量”，LimitRange 管“单个容器默认值和上下限”。两者常搭配使用：
为命名空间设置 LimitRange，自动为未声明 resources 的 Pod 注入默认 request/limit
这样能确保 ResourceQuota 统计有据可依，避免用户故意不写 requests 导致 quota 形同虚设
例如：LimitRange 设定默认
，那么 20 个 Pod 就天然占用至少 10Gi 内存，配合 ResourceQuota 的 8Gi 限制就会立刻触发拒绝
requests.cpurequests.memorylimits.cpulimits.memoryrequests.storageephemeral-storagepodsservicesreplicationcontrollersconfigmapssecretsdev-teamapiVersion: v1
kind: ResourceQuota
metadata:
name: quota-dev
namespace: dev-team
spec:
hard:
requests.cpu: "4"
requests.memory: 8Gi
limits.cpu: "6"
limits.memory: 12Gi
pods: "20"
services: "10"
configmaps: "50"
secrets: "30"
limitsrequestslimitsrequests"4"8Gi"20"kubectl describe quota -n dev-teamUsedHarderror: failed to create resource: pods "test-pod" is forbidden: exceeded quota: quota-dev, requested: requests.memory=4Gi, used: requests.memory=6Gi, limited: requests.memory=8Gikubectl get events -n dev-team --field-selector reason=FailedCreaterequests.memory: 512Mi