Kubernetes Pod 一直 Pending？一套完整排查思路

一、先理解 Pending 到底卡在哪

在 Kubernetes 里，Pod 处于 Pending 通常意味着它还没有被成功调度到某个节点上，或者已经调度但容器尚未启动。绝大多数情况下，问题出在调度阶段。排查的第一步永远是：

kubectl describe pod <pod-name> -n <namespace>

重点看输出最底部的 Events 段，调度器给出的失败原因几乎都写在这里，比如 0/5 nodes are available 后面跟的具体约束。

二、五类高频原因与对应解法

1. 资源不足（CPU / Memory 不够）

现象：Insufficient cpu 或 Insufficient memory。集群剩余可分配量小于 Pod 的 requests。

解法：调低 requests、扩容节点，或用 kubectl top nodes 确认实际水位。注意 requests 是调度依据，limits 不影响调度。

2. nodeSelector / 节点亲和性不匹配

现象：node(s) didn't match Pod's node affinity/selector。Pod 要求的标签没有任何节点满足。

解法：核对 kubectl get nodes --show-labels，修正标签或放宽 requiredDuringScheduling 为 preferred。

3. 污点与容忍度（Taints / Tolerations）

现象：node(s) had untolerated taint。节点带 NoSchedule 污点，而 Pod 没有对应容忍。

解法：给 Pod 加 tolerations，或移除节点不必要的污点。

4. PVC 一直未绑定

现象：pod has unbound immediate PersistentVolumeClaims。存储卷没准备好，Pod 无法落到需要它的节点。

解法：检查 PV/PVC 状态、StorageClass 是否存在、供给（provisioner）是否正常。

5. 拓扑分布约束 / 端口冲突

现象：didn't have free ports 或 topology spread constraints 相关。hostPort 被占，或 topologySpreadConstraints 太严格。

解法：去掉 hostPort 改用 Service，或放宽 maxSkew。

三、一条通用排查口诀

先看 Events 定位是"调度失败"还是"调度成功但启动失败"；调度失败就对着 nodes are available 的约束逐条排除（资源→选择器→污点→存储→端口）；如果 Events 信息含糊，再查 kube-scheduler 日志和集群配额（ResourceQuota）。

掌握这套顺序，90% 的 Pending 都能在几分钟内定位。希望对你排障有帮助。