Pod 处于 Pending 状态通常意味着调度器无法找到合适的节点来运行它，最优先的动作是查看 Pod 的详细事件信息。
先说结论：多数情况是资源不足或调度规则冲突，需通过事件日志定位具体阻碍。
- 先确认 Pod 事件中的调度失败提示
- 先处理节点资源或约束配置问题
- 再验证 Pod 是否成功转入 Running 状态
命令速用版
直接查看 Pod 详情和事件，这是最快的定位方式：
kubectl describe pod <pod-name> -n <namespace>重点关注输出末尾的 Events 部分，通常会直接写明调度失败的原因，例如 Insufficient cpu 或 node(s) had taints。
为什么会这样
Kubernetes 调度器在分配 Pod 到节点时，需要满足一系列条件。如果集群中没有节点能同时满足所有条件，Pod 就会一直停留在 Pending 状态。常见阻碍包括集群剩余资源不足、节点被打上污点且 Pod 未配置容忍度、存储卷未绑定，或者命名空间配额已用完。公开资料中没有看到可靠的量化数据说明哪种原因占比最高，但资源不足和污点容忍是最常见的两类。
分步处理
1. 查看调度失败事件
使用 describe 命令，滚动到最下方查看 Events。如果看到 FailedScheduling，仔细阅读 Reason 和 Message 字段。
2. 检查节点资源
确认集群是否有可用资源。可以使用以下命令查看节点分配情况：
kubectl top nodes如果未安装 metrics-server，可通过 kubectl describe node <node-name> 查看 Allocated resources 部分。
3. 检查存储卷状态
如果 Pod 依赖 PVC，检查 PVC 是否处于 Pending 状态。存储类（StorageClass）配置错误或动态供给失败会导致 Pod 无法调度。
kubectl get pvc -n <namespace>4. 检查命名空间配额
查看当前命名空间是否限制了 CPU 或内存总量：
kubectl describe resourcequota -n <namespace>怎么验证是否生效
执行以下命令，观察 STATUS 列是否变为 Running：
kubectl get pod <pod-name> -n <namespace> -w如果状态变更成功，事件日志中会出现 Scheduled 和 Pulling 等相关记录。
常见坑
- 忽略了节点被标记为 Cordoned（禁止调度），此时新 Pod 无法调度到该节点。
- 混淆了 LimitRange 和 ResourceQuota，前者限制单容器，后者限制命名空间总量。
- 使用了节点亲和性（Affinity）但标签匹配不上，导致没有候选节点。
参考来源
- Kubernetes 官方文档，Pod 生命周期与状态，https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/
- Kubernetes 官方文档，调试调度失败，https://kubernetes.io/docs/tasks/debug/debug-application/debug-pod-failure/