Namespace-Quota即ResourceQuota，是Kubernetes中用于对命名空间内资源总量进行“总额封顶”的准入控制机制，限制计算资源（如requests.cpu、requests.memory）和对象数量（如pods、services、secrets等），在创建新资源时拒绝超限请求而非驱逐运行中Pod。
Namespace-Quota 是什么，它能管住哪些资源
ResourceQuota 是 Kubernetes 中用于限制某个 Namespace 内可消耗资源总量的对象，不是按 Pod 或用户粒度，而是对整个命名空间做“总额封顶”。它能控制的主要是两类资源：
- 计算类：
requests.cpu、requests.memory、limits.cpu、limits.memory - 对象数量类：
pods、services、configmaps、secrets、persistentvolumeclaims
注意：ResourceQuota 不会自动 kill 超限的 Pod，而是在创建新对象时直接拒绝（报错 exceeded quota），所以它本质是“准入控制”，不是运行时驱逐。
怎么写一个给“dev-team”部门用的配额配置
关键点在于：配额必须和 Namespace 绑定，且需在该命名空间存在后才创建。典型流程是：
- 先创建命名空间：
kubectl create namespace dev-team
- 再应用配额 YAML，例如限制最多 8 个 Pod、总 CPU request 不超 4 核、内存不超 16Gi：
apiVersion: v1 kind: ResourceQuota metadata: name: team-quota namespace: dev-team spec: hard: pods: "8" requests.cpu: "4" requests.memory: 16Gi
- 配额生效后，任何在
dev-team下创建 Pod 的请求，只要累计requests.cpu超过 4，就会被 API Server 拒绝，并返回错误：Forbidden: exceeded quota: team-quota
别漏掉 namespace 字段——如果写错或没写，配额不会绑定到目标空间，等于白配。
为什么设置了 limits.memory 却没生效
limits.memory 在 ResourceQuota 中仅当所有容器都显式声明了 memory limit 时才参与统计；而 requests.memory 只要 Pod 有 request 就计入。常见陷阱包括：
- 用户只写了
limits.memory，没写requests.memory→ 配额不统计该 Pod 的内存 request，但可能触发节点调度失败 - 用户什么都没写（靠 LimitRange 默认值）→ 默认值由
LimitRange提供，但ResourceQuota不自动读取 LimitRange 的默认值来补全统计，导致实际用量无法被配额捕获 - 混用
requests和limits字段：比如只设limits.cpu配额，但 Pod 只申明了requests.cpu→ 这个 request 不受该配额项约束
建议统一用 requests.* 做配额基线，再配合 LimitRange 强制设置默认 limits，这样既可控又符合调度逻辑。
多个配额对象能否叠加？有没有隐含优先级
可以创建多个 ResourceQuota 对象到同一个 Namespace，它们的效果是叠加生效（AND 关系），即任一配额被突破都会拒绝操作。例如：
-
quota-a限制pods: "5" -
quota-b限制requests.cpu: "2"
那么即使只创建了 3 个 Pod（未超 quota-a），但它们的 CPU request 总和达到 2.1，也会被拒绝。
没有优先级，也没有“继承”或“覆盖”机制。但要注意：相同字段不能重复定义在多个配额中（比如两个配额都定义 pods），否则第二个会创建失败，报错：field is immutable after creation。
实际运维中，建议一个 Namespace 只维护一个配额对象，把所有硬性约束写在一起，避免分散管理和冲突判断。
配额本身不感知团队层级或标签，真要支持“部门-子团队”多级管控，得靠外部策略引擎（如 OPA/Gatekeeper）或自研 admission webhook，原生 ResourceQuota 就是个扁平、静态、粗粒度的闸门。
