Kubernetes Pod Pending 时怎么排查

Pod Pending 的特点是看起来“什么都没报错，但它就是起不来”。

业务侧通常只会看到：

• 副本数一直补不上
• 发布卡住
• HPA 扩容了但没有新实例真正接流量
• Pod 状态一直停在 Pending

它和 CrashLoopBackOff 不一样，Pending 说明容器通常还没真正运行起来。大多数根因集中在：

• 调度不到节点
• 资源申请过大
• 亲和性/污点限制太严
• PVC 绑定或挂载卡住
• 镜像拉取前置条件没准备好

先说结论

• Pod Pending 第一件事是看事件，先分清是调度问题还是存储问题
• 如果是批量 Pending，要先判断是集群容量不足，还是某个调度约束把可用节点都排除了
• 如果是有状态服务 Pending，要特别警惕 PVC、StorageClass、Zone 和节点约束组合出来的问题
• 很多 Pending 不是“集群不够大”，而是 requests、亲和性、污点、卷绑定条件叠加后没有可落点了

一个典型故障现场

一个典型场景是业务高峰期触发 HPA 扩容，结果：

• 目标副本数上去了
• 新 Pod 一直 Pending
• 老 Pod 负载继续升高
• 应用方以为“扩容失效”

另一种典型场景是 StatefulSet 发布或节点漂移后：

• 某个 Pod 删除后一直起不来
• PVC 一直卡在绑定或挂载阶段
• 同机房有节点，但就是调度不上去

这类问题如果只看 Pod 状态本身，很容易看不出真正卡点。

第一阶段：先止血，别让发布和扩容继续加剧问题

1. 如果是发版引发的 Pending，先暂停滚动

因为继续滚动通常只会让更多旧副本被替换掉，而新副本又起不来。

2. 如果是高峰期扩容失败，先评估是否需要临时人工扩容节点或降级业务

Pending 本身不会耗 CPU，但它意味着你指望的新容量根本没有真正落地。

3. 对有状态服务先保护现有健康实例

如果 Pending 的是 StatefulSet，不要急着反复删 Pod 重建，更要先确认卷和调度约束是否匹配。

第二阶段：先判断卡在调度，还是卡在存储

1. 调度型 Pending

典型信号是：

• 没有合适节点
• request 太大
• 亲和性要求太严
• 污点没容忍
• topology spread、zone 限制把节点都排除了

2. 存储型 Pending

典型信号是：

• PVC 一直没绑定
• volume attach/mount 失败
• StorageClass 配置不匹配
• Zone 和卷位置不一致

先分清这两类，很多时候就已经接近根因了。

第三阶段：现场最该看的几类信息

1. Pod 事件

Pending 最有价值的信息通常就在事件里，比如：

• Insufficient cpu
• Insufficient memory
• node(s) had taint
• node(s) didn't match Pod affinity
• pod has unbound immediate PersistentVolumeClaims

2. requests/limits 和节点可用资源

很多团队看到节点整体资源还有余量，就以为不该 Pending。但调度看的是：

• 单节点是否能满足这一个 Pod 的 request
• 节点碎片化是否严重
• 亲和性和污点过滤后还剩多少可选节点

3. 亲和性、反亲和性、污点容忍

这类约束很容易在平时没问题，但扩容、节点维护、某个可用区资源吃紧时突然暴露出来。

4. PVC、StorageClass、Zone

尤其是 StatefulSet、数据库、中间件类服务，很多 Pending 的根因并不在 CPU/内存，而在：

• 卷没绑定
• 卷和节点不在同一区域
• StorageClass 不支持当前模式
• 原卷还挂在别的节点或状态异常

常见根因画像

1. request 配太大，集群资源被碎片化

节点总资源够，但没有任何一个单节点能完整放下这个 Pod。

2. 亲和性太强，把候选节点几乎筛没了

例如既要求某个 zone，又要求和另一组服务同节点，同时还要求避开某类节点，最后没有可调度目标。

3. 污点和容忍没对上

节点明明有资源，但工作负载没有对应的 toleration。

4. PVC 绑定失败或卷挂载卡住

有状态服务里这是非常高频的一类 Pending 根因。

5. 集群扩容速度跟不上业务扩容速度

HPA 已经开始扩 Pod，但底层节点池没有及时补上，结果大量副本 Pending。

一个更实用的排查顺序

现场我通常按这个顺序看：

1. 先看 Pod 事件，判断是调度型还是存储型 Pending。
2. 如果是调度型，再看 request、节点资源、污点、亲和性。
3. 如果是存储型，再看 PVC、PV、StorageClass、Zone 和挂载事件。
4. 看这是单个工作负载问题，还是同一批 workload 都在 Pending。
5. 最后再判断是暂时扩容节点、调整调度约束，还是回滚变更。

这个顺序能避免把本来很明确的 Pending 事件，排查成一场漫无目的的集群巡检。

止血后的治理方向

1. 给工作负载做更真实的 requests 评估

不要为了“看起来保险”就把 request 拉得过高。

2. 亲和性和污点规则要定期审查

很多规则在最初设计时合理，但随着节点池、机房和服务规模变化，会越来越容易卡调度。

3. 有状态服务要提前演练卷漂移和节点故障恢复

不要等 Pod Pending 了才第一次去理解 PVC、StorageClass 和 Zone 的绑定关系。

4. 扩容链路要看完整

HPA、节点池扩容、存储供应速度，这几层缺一层，最终都会表现成 Pod Pending。

总结

Pod Pending 真正要解决的，不是“它为什么还没起来”这个表象，而是先分清：

• 是没地方调度
• 还是卷没准备好
• 是资源不够
• 还是规则太严

把“事件、资源、调度约束、存储绑定”这四条线先看清，绝大多数 Pending 故障都能很快缩到真正根因上。