ResourceQuota 通过 spec.hard 字段限制命名空间资源总量，必须绑定具体 namespace，立即生效且仅约束新增/更新对象；需显式声明 resources.requests 才能创建 Pod，须与 LimitRange 配合使用以防绕过。
限制命名空间资源使用，核心是用 ResourceQuota 设置总量上限，它不预留资源，只在创建新对象时做硬性拦截。
配额必须绑定到具体命名空间
ResourceQuota 对象本身没有全局作用域，必须明确指定 metadata.namespace。同一个集群里，不同命名空间可配置不同配额，互不影响。比如开发环境设宽松些，生产环境则严格限制 CPU 和内存总请求量。
- 配额对象创建后立即生效，无需重启组件
- 它只统计该命名空间内新增或更新的资源，已运行的 Pod 不受配额变动影响
- 删除 ResourceQuota 对象后，原有配额限制即刻解除
关键字段 hard 决定能用多少
spec.hard 是唯一必需字段，定义各类资源的硬上限。常见写法包括：
-
requests.cpu: "4"—— 所有 Pod 的 CPU 请求总和不能超 4 核 -
requests.memory: 16Gi—— 内存请求总和上限为 16GiB -
pods: "30"—— 最多允许 30 个 Pod 存在 -
services: "20"—— Service 数量不能超过 20 个 -
requests.storage: 100Gi—— PVC 总存储请求不超过 100GiB
注意：所有数值必须带单位（如 "4"、16Gi、"30"），且 requests 和 limits 是独立统计的。
启用 requests 配额时，Pod 必须显式声明 resources
一旦配额中包含 requests.cpu 或 requests.memory，Kubernetes 就会强制要求每个新建 Pod（含 Deployment 等控制器生成的底层 Pod）必须在容器 spec 中写出 resources.requests。
- 只写
limits不写requests会被拒绝 - Helm chart 或旧模板若没配 resources，部署会失败
-
kubectl run临时调试需加--requests=memory=512Mi,cpu=100m参数
ResourceQuota 要和 LimitRange 搭配才完整
ResourceQuota 控制“总量”，LimitRange 控制“单个容器的边界”。单独用配额容易被绕过：
- 没设 LimitRange 时，用户可能提交一个
requests.memory: 1Mi的 Pod，大量创建也能耗尽配额 - 没设 ResourceQuota 时，用户可随意设
requests.memory: 60Gi，直接占满节点
推荐组合：LimitRange 设默认 requests 和最大 limits，ResourceQuota 设命名空间总上限。这样既防漏，也防滥用。
