scopes 让配额只覆盖某类 Pod
同一个命名空间里常混着长驻服务与批处理任务，用一条配额管全部就会互相挤占。ResourceQuota 的 scopes 能把配额限定到某一类 Pod：Terminating 与 NotTerminating 按是否设置了 activeDeadlineSeconds 区分批处理与长驻服务，BestEffort 与 NotBestEffort 按是否声明了 requests 或 limits 区分资源声明的规范程度。两对作用域各自互斥，可以给两类负载分别设额。
基本信息
| 适用对象 | 各版本的 ResourceQuota |
|---|---|
| 关键字段 | spec.scopes，数组形式，可写多个值 |
| 可用取值 | Terminating、NotTerminating、BestEffort、NotBestEffort |
| 配对关系 | 每对之内互斥，未落进作用域的对象不受该配额约束 |
| 查看入口 | kubectl describe resourcequota 的 Used 与 Hard 两列 |
典型使用场景
- 分级管控：给批处理任务与在线服务各自设额度，避免互相挤占
- 限制裸奔容器：单独约束未声明 requests 与 limits 的 Pod 数量
- 容量分层：对规范声明资源的服务放宽额度，对不规范的收紧
- 成本归因：按负载类型观察各自消耗，便于容量与费用分析
- 迁移过渡：先把批任务收进单独的配额，再逐步规范在线服务
只约束非 BestEffort 的 Pod
只约束非 BestEffort 的 Pod
apiVersion: v1
kind: ResourceQuota
metadata:
name: prod-quota
namespace: prod
spec:
hard:
pods: "50"
scopes:
- NotBestEffort # 只统计至少声明了 requests 或 limits 的 Pod
---
apiVersion: v1
kind: ResourceQuota
metadata:
name: prod-batch-quota
namespace: prod
spec:
hard:
pods: "20"
scopes:
- Terminating # 只统计设置了 activeDeadlineSeconds 的批处理 Pod核对生效范围
核对生效范围
kubectl describe resourcequota prod-quota -n prod
kubectl get resourcequota -n prod -o jsonpath='{.items[*].spec.scopes}'
kubectl get pods -n prod -o custom-columns='POD:.metadata.name,DEADLINE:.spec.activeDeadlineSeconds'scope 与覆盖对象
| scope | 覆盖对象 | 典型用途 |
|---|---|---|
| Terminating | 设置了 activeDeadlineSeconds 的 Pod | 批处理任务单独设额 |
| NotTerminating | 未设置该字段的 Pod | 长驻服务配额 |
| BestEffort | 未声明 requests 与 limits 的 Pod | 限制不规范容器的数量 |
| NotBestEffort | 至少声明了 requests 或 limits 的 Pod | 管控已规范声明的负载 |
带作用域的配额对可限制的键有一定约束，按 QoS 划分时通常只统计 Pod 数量这类计数项，具体以对应版本的官方说明为准，配置后用 describe 核对范围是否符合预期。
成对的作用域要配各自的配额对象：只建一条 NotBestEffort 配额，未声明资源的 Pod 就完全不在约束范围内，看起来像配额失效。