Pod处于Pending状态时，首选kubectl describe pod命令查看Events事件栏定位原因：如资源不足、节点标签不匹配、污点无容忍、CNI异常、依赖对象缺失或镜像拉取失败等，并结合node描述交叉验证。
Pod处于Pending（挂起）状态，说明它已被API Server接收，但尚未被调度到节点上运行。此时kubectl describe pod是最直接、最有效的第一排查命令——它把调度失败的关键线索集中呈现出来，不需要先猜原因。
重点看Events事件栏
这是诊断Pending的核心区域。执行kubectl describe pod <pod-name>后，滚动到底部的Events部分，常见提示包括：
-
“0/3 nodes are available: 3 Insufficient cpu”：集群所有节点CPU资源都不够，需检查Pod的
resources.requests.cpu是否过高，或节点实际负载是否已满 -
“0/3 nodes match node selector”：Pod配置了
nodeSelector或affinity，但没有节点带对应标签，可用kubectl get nodes -l <key>=<value>验证 -
“0/3 nodes are available: 3 node(s) had taints that the pod didn’t tolerate”：节点有污点（taint），而Pod没配容忍（toleration），需在Pod spec中补全
tolerations字段 - “failed to find plugin “xxx”” 或 “no IP addresses available in network”：CNI网络插件异常，影响Pod初始化，需检查节点上CNI配置和kubelet日志
核对Conditions与Allocated Resources
在describe输出中，上方的Conditions段会显示Scheduled是否为False，并附带原因；中间的Allocated resources则反映该节点已分配的资源量。对比Capacity（节点总容量），可判断是整体资源不足，还是仅当前节点被占满。若多个节点都显示类似瓶颈，说明需扩容或优化资源请求值。
顺带确认依赖对象是否存在
Pending也可能由外部依赖缺失引发，比如：
- 引用了不存在的
Secret或ConfigMap：Events里通常提示FailedMount或NotFound - 绑定
PersistentVolumeClaim但PVC处于Pending：需用kubectl describe pvc <name>继续追查PV供给或StorageClass配置 - 镜像拉取失败（虽更常导致ImagePullBackOff，但某些私有仓库鉴权失败也会卡在Pending）：检查Events中是否有
Failed to pull image类信息，并确认imagePullSecrets是否正确定义
结合节点视角交叉验证
如果Events指向某个具体节点（如scheduled on node-2但失败），立刻执行kubectl describe node node-2，重点关注：
-
Conditions中Ready是否为True，MemoryPressure/DiskPressure是否True -
Allocatable与Capacity差异，确认资源是否真被耗尽 -
Non-terminated Pods列表，看是否有大量旧Pod未清理，或存在高优先级抢占行为
