pod pending 的根本原因是调度失败或节点侧执行卡住；需先查 events 定位资源不足、pvc 未绑定、污点不匹配等，再通过 node 字段判断是否已调度，最后针对性排查节点资源、污点、pvc、标签等。
Pod 一直处于 Pending 状态，说明它已被 API Server 接收，但调度器始终未能将其分配到可用节点上运行，或虽已分配却卡在前置条件验证环节——此时容器根本没开始拉镜像、更未进入 ContainerCreating 阶段。
先看 Events：99% 的线索藏在这里
执行 kubectl describe pod <pod-name> -n <namespace></namespace></pod-name>，直接滚动到底部的 Events 区块。
如果看到类似 0/3 nodes are available: 3 Insufficient cpu，立刻停手——这是资源不足；若出现 pod has unbound immediate PersistentVolumeClaims，跳转到 PVC 排查；若提示 node(s) had untolerated taint，说明污点没配容忍；FailedScheduling 出现但 Events 空白？别急着翻日志，先用 kubectl get events -n <namespace> --field-selector involvedObject.name=<pod-name></pod-name></namespace> 拉取历史事件——有些事件会被新事件冲掉。
【Events 是诊断起点，不是可选项】
确认是否真被调度：看 Node 字段
在 kubectl describe pod 输出中，找到 Node: 这一行。
如果显示 Node: <none></none>，说明调度器压根没选中任何节点，问题一定出在调度阶段（资源、污点、亲和性、PVC）。
如果显示具体节点名（如 Node: node-2），但 Pod 仍 Pending，说明已调度成功，卡在节点侧执行环节——这时要立刻 ssh 登该节点，查 kubelet 日志、docker 或 containerd 状态、磁盘空间、镜像仓库连通性。
逐项排查高频原因
方法一：资源不足（最常见）
① 查 Pod 请求值：kubectl get pod <pod-name> -n <namespace> -o jsonpath='{.spec.containers[*].resources.requests}'</namespace></pod-name>
② 查节点可分配资源：kubectl describe node <node-name></node-name>，重点关注 Allocatable 和 Allocated resources 两栏——差值才是真实剩余量。
③ 注意：调度只看 requests，不看 limits。哪怕 limits 设得再高，只要 requests 超过节点 Allocatable - 已分配 requests 总和，调度器就会拒绝。
方法二：污点与容忍不匹配
执行 kubectl get nodes -o wide，观察 STATUS 列是否含 NotReady；再执行 kubectl describe node <node-name> | grep Taints</node-name>。若输出类似 Taints: node-role.kubernetes.io/control-plane:NoSchedule，而你的 Pod YAML 中没写对应 tolerations，它就永远进不去。
方法三：PVC 未绑定
运行 kubectl get pvc -n <namespace></namespace>，检查状态是否为 Pending。如果是，再执行 kubectl describe pvc <pvc-name> -n <namespace></namespace></pvc-name>，看 Events 是否报 No available persistent volumes to bind 或 StorageClass 不存在。StorageClass 缺失时，动态供给无法触发，PVC 就一直悬着。
方法四：节点标签与 nodeSelector 冲突
执行 kubectl get nodes --show-labels，比对 Pod YAML 中 nodeSelector 指定的键值对——哪怕多一个空格、大小写错一位，都找不到匹配节点。亲和性（affinity）配置更复杂，建议先注释掉整个 affinity 块做最小化测试。
