节点CPU看起来很空，Pod为什么仍提示资源不足

监控面板上的CPU曲线很低，新建Pod却一直等待调度，这两种现象并不必然矛盾。它们可能在回答不同的问题：一个反映当前实际使用，另一个关系到调度时要为工作负载安排多少资源。

Kubernetes官方资源管理文档说明，调度器使用Pod中容器的资源请求决定放置节点。即使节点当前CPU或内存使用率很低，如果资源容量检查不能通过，调度器仍会拒绝把Pod放上去，以防后续需求上升时出现资源不足。[1] 因此，不能仅凭一张低利用率截图就认定调度器发生故障。

排查时，先阅读目标Pod的实际事件。文档给出FailedScheduling的资源不足示例，并说明找不到合适节点时，Pod会保持未调度状态，同时产生事件。[1] 记录应保留发生时间、对象和原始原因，不把所有Pending状态都统一解释成CPU不足。若事件指向其他约束，应沿实际证据继续判断。

接着把请求值和即时用量分开看。请求是资源配置的一部分，用量会随任务变化；limit又是另一类运行约束，不能因为字段都与CPU或内存有关就混为一谈。整理问题说明时，可以并排保留Pod的相关配置、同一时间的监控数据和事件，让审阅者知道每个数值来自哪里。

节点也有总容量与可分配给Pod的资源之分。官方文档指出，系统守护进程会占用一部分资源，并用Node的status.allocatable字段描述可供Pod使用的资源。[1] 因而，直接拿物理总量减去监控用量，不足以复现调度判断；已有工作负载的请求及其他放置条件也需要结合现场核对。

本文解释的是文档中的调度机制，没有连接或修改任何集群，也不提供为“尽快跑起来”而盲目降低请求的配置值。先保存实际事件，再区分请求、限制、用量与可分配资源，有助于把问题描述清楚。扩容、调整资源或迁移工作负载，应根据真实负载与集群条件经过验证后决定。