概念定位
调度器做「能不能放」的判断时只看 requests，不看 limits，也不看实际使用率。适用平台是 Kubernetes。它按节点上所有已调度 Pod 的 requests 之和与节点 Allocatable 比较，决定是否还有空间；limits 只影响运行期的上限与超卖程度。这解释了为什么会出现两种相反的困惑：「节点监控显示 CPU 只用了 30%，为什么新 Pod 还是 Pending」以及「明明没超 requests，为什么容器被节流」。
基本信息
| 适用平台 | Kubernetes，调度与资源计量 |
|---|---|
| 判据字段 | Pod 的 requests 与节点 status.allocatable |
| limits 的作用 | 运行期上限：CPU 触发节流，内存触发 OOM |
| Allocatable | Capacity 减去系统预留与驱逐阈值，容量评估要用它 |
典型使用场景
- 排查 Pending：确认是节点剩余 requests 不足还是约束不匹配
- 容量规划：按 requests 之和评估扩节点需求，而不是按 CPU 使用率
- 识别超卖：对比 Allocated 表里 Requests 与 Limits 的百分比关系
- 调整成本：requests 长期虚高会浪费容量，虚低则导致争抢与驱逐风险
- 上线前评审：核对新服务的 requests 是否符合容量模型的预算
核对方法
核对方法
kubectl describe node node1 | sed -n '/Non-terminated Pods/,/Allocated resources/p'
kubectl describe node node1 | grep -A6 'Allocated resources'
kubectl get node node1 -o jsonpath='{.status.allocatable}' # 可分配总量
kubectl get pods --field-selector spec.nodeName=node1 -A -o custom-columns='NS:.metadata.namespace,NAME:.metadata.name'
kubectl get pod web-x -o jsonpath='{.spec.containers[*].resources}'Requests 与 Limits 对照
Requests 与 Limits 对照
Allocated resources:
Resource Requests Limits
cpu 3600m (45%) 12 (150%) # Limits 超过 100% 说明在超卖
memory 7Gi (44%) 14Gi (88%)常见误判
| 说法 | 实际情况 | 正确做法 |
|---|---|---|
| 监控利用率低就该能调度 | 调度算 requests 之和，与实际使用无关 | 看 Allocated resources 的 Requests 百分比 |
| requests 设小没关系 | requests 虚低会让节点超卖，突发时争抢 | 按真实基线设 requests |
| limits 大就不会被限制 | 节点拥挤时仍可能抢不到 CPU 被节流 | 结合 limits 与节点密度评估 |
| Capacity 就是可用容量 | Allocatable 才可分配 | 容量评估用 Allocatable |
调度器还有打分环节：优先把 Pod 放到资源占用更低的节点，所以 Pending 与否由过滤阶段决定，落点是打分阶段决定。
未设 requests 的容器 requests 为 0，对调度几乎没有成本，这正是 BestEffort 负载容易过量堆积的原因。
容量判断的三个口径
- 节点层：看 Allocated resources 里 Requests 的百分比，这才是调度器眼里的余量
- 集群层：统计全部节点的 requests 之和与可分配总量，比看平均利用率更能预测 Pending
- 工作负载层：核对每个服务的 requests 是否符合它的真实基线，模板值长期不校准会造成系统性偏差
- 结论要落到动作：余量不足就扩节点或下调虚高 requests，利用率低但无法调度则说明 requests 设得过大