调度按什么算容量
调度与容量规划依据的是节点的 Allocatable，而不是 Capacity。Allocatable 等于物理总量减去 kubelet 预留（系统组件与 Kubernetes 组件资源）再减去驱逐阈值：Capacity 是机器实际资源，Allocatable 才是能分给 Pod 的部分。做容量评估时如果按 Capacity 求和，结果通常偏高，等到真正部署才发现放不下，而调度器给出的信号是 Pod 一直 Pending。
基本信息
| 适用对象 | 集群中的每个节点 |
|---|---|
| 三个相关量 | Capacity（物理总量）、Allocatable（可分配）、已分配 requests |
| 预留参数 | kube-reserved 与 system-reserved，在 kubelet 配置中声明 |
| 驱逐阈值 | eviction-hard 等参数，决定留给系统的缓冲 |
| 查看方式 | kubectl describe node，对照 Capacity 与 Allocatable 两段 |
典型使用场景
- 容量规划：按 Allocatable 求和估算可承载的 Pod 与副本数
- 排查 Pending：确认是 requests 已满还是资源碎片导致放不下
- 节点调优：按节点规格与角色调整预留与驱逐阈值
- 成本核算：区分物理资源与可售资源，避免按硬件规格报价
- 混合部署：把系统组件与业务负载的资源账分开计算
对照查看
对照查看
kubectl describe node node1 | sed -n '/Capacity:/,/Allocatable:/p'
kubectl describe node node1 | sed -n '/Allocatable:/,/System Info/p'
kubectl describe node node1 | sed -n '/Allocated resources/,/Events/p'
kubectl get pods -A --field-selector spec.nodeName=node1 -o json | head -5几个量怎么读
| 字段 | 含义 | 使用建议 |
|---|---|---|
| Capacity | 节点物理资源总量 | 只用于了解硬件规格 |
| Allocatable | 可分配给 Pod 的总量 | 容量规划按它求和 |
| Allocated resources | 已声明的 requests 之和 | 接近 Allocatable 时新 Pod 会 Pending |
| 预留与阈值 | 系统与 kubelet 保留的部分 | 按节点角色与规模调整 |
Allocatable 与 Capacity 的差值来自预留和驱逐阈值：节点规格越大、上面运行的组件越多，差值通常越明显，规划时不要用固定比例套算。
排查「监控显示内存还有余量但 Pod 起不来」时，先比较 Allocatable 与已分配 requests，而不是看使用率曲线：调度看的是声明量，不是真实使用量。
节点上跑的组件越多，预留越应该细化：把系统守护进程与 Kubernetes 组件分开统计，才能判断预留是否与实际占用相符，避免出现「预留了却仍被挤占」的情况。