resourcequota 是 kubernetes 中命名空间级资源总量控制机制，通过硬性限额约束 cpu、内存、对象数量等聚合用量，强制 pod 显式声明资源需求，并需配合 limitrange 与 scopeselector 实现精准管控。
ResourceQuota 是 Kubernetes 中专用于命名空间级资源总量控制的核心机制，它不干预单个 Pod 的调度逻辑，而是通过硬性限额阻止资源总量突破预设边界。要真正防止超额占用，关键在于配额定义、强制约束和配套策略三者协同生效。
明确配额作用范围与对象粒度
ResourceQuota 仅在命名空间内生效，每个命名空间最多绑定一个活跃的 ResourceQuota 对象。它限制的是该命名空间下所有非终止状态资源的聚合用量，包括：
- CPU 和内存：按 requests.cpu、limits.memory 等字段统计总和
- 对象数量：如 pods、services、configmaps、persistentvolumeclaims
- 扩展资源：如 requests.nvidia.com/gpu 或 hugepages-2Mi
注意：配额修改不影响已运行的 Pod 或 Service，只约束新建或更新操作。
Kubernetes Security Posture Scorecard
下载
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
强制要求 Pod 显式声明资源需求
当 ResourceQuota 启用了 cpu 或 memory 类型（例如设置了 requests.cpu 或 limits.memory），Kubernetes 会拒绝创建未设置对应 requests 或 limits 的 Pod。这不是可选行为，而是准入控制的硬性检查。
- 若只配置了
requests.cpu: "2"，则所有新 Pod 必须含resources.requests.cpu - 若同时配置了
limits.cpu和requests.cpu，Pod 必须同时声明二者，否则创建失败 - 建议配合 LimitRange 设置默认值，避免因遗漏声明导致部署中断
合理设置配额值并启用范围筛选
配额值需结合节点实际容量与团队工作负载特征设定，避免过严导致无法扩容，也忌过松失去管控意义。可借助 scopeSelector 进一步细化适用场景：
- 用
scopeSelector.matchExpressions限定仅对NotBestEffort类型 Pod 计入 CPU 内存配额 - 用
scopes: ["PriorityClass"]将高优任务单独纳入配额统计，隔离普通任务影响 - 对临时存储类配额（如
requests.ephemeral-storage），无需强制 Pod 声明，适合弹性场景
验证与故障排查要点
配额生效后，异常请求会返回 HTTP 403 Forbidden，错误信息中明确指出违反哪项约束。日常维护建议：
- 用
kubectl describe resourcequota -n <ns></ns>查看当前使用量与剩余配额 - 若 Deployment 创建成功但 Pod 无法调度，检查
kubectl describe deploy中的 Events 字段，常见提示为 “exceeded quota” - 禁止普通用户具备
update或deleteResourceQuota 的 RBAC 权限，防止绕过管控
