在一次应用发布检查中，我们遇到一个很典型但也很迷惑的问题：

• Pod 明明是 Running，而且已经 Ready
• Deployment 也显示 Available=True
• 但应用的滚动状态却一直卡在检查阶段
• 根因提示指向 PodDisruptionBudget（PDB）
• 并显示 currentHealthy=0、desiredHealthy=1

表面上看，像是 PDB 在“卡发布”；
但当我们继续往下查时，却发现实际情况并没有那么简单。

这篇文章就记录一次完整的排查过程，并总结一下这类问题应该如何分析、如何建立证据链，以及 AI 智能诊断在这类场景下应该怎么做。

---

一、问题现象

我们先看到的是应用状态中的报错：

PodDisruptionBudget currentHealthy is less than desiredHealthy, CurrentHealthy=0, DesiredHealthy=1

这句话的意思很直接：

• PDB 要求至少保留 1 个健康 Pod
• 但当前系统认为健康 Pod 数量是 0
• 所以不允许继续驱逐、升级或滚动替换

从结果看，发布链路被卡住了。

---

二、第一反应：是不是 Pod 挂了？

遇到这种问题，很多人的第一反应都是：

• Pod 是不是崩了？
• 容器是不是重启了？
• 资源是不是不足？
• 镜像是不是拉不下来？

于是我们先看 Pod 状态：

kubectl get pod -n ali -l account.super=admin -o wide

结果却让人意外：

• 两个 Pod 都是 Running
• 两个 Pod 都是 1/1 Ready
• RESTARTS=0

也就是说，从 Pod 层面看，它们是健康的。

---

三、再看 Deployment：也正常

接着我们继续看 Deployment：

kubectl describe deploy ali-adbpg-engine-ali -n ali

结果显示：

• Available=True
• Progressing=True
• NewReplicaSet 已经 2/2 replicas created
• 没有旧 ReplicaSet
• 没有 Events

这说明 Deployment 已经完成发布，当前也处于健康状态。

到这里就出现了一个很关键的矛盾：

Pod 和 Deployment 都是健康的，为什么 PDB 还说 currentHealthy=0？

---

四、检查 PDB：确实在阻塞

我们继续看 PDB：

spec:
  minAvailable: 1
  selector:
    matchLabels:
      account.super: admin

status:
  currentHealthy: 0
  desiredHealthy: 1
  disruptionsAllowed: 0
  expectedPods: 2
  reason: InsufficientPods

这说明：

• PDB 选中了 2 个 Pod
• 但它认为当前健康 Pod 数为 0
• 因此不允许任何中断

从 PDB 自身看，它并没有“坏掉”，而是在执行它的保护策略。

问题是：它为什么还认为健康 Pod 为 0？

---

五、关键线索：时间线不对劲

接下来我们看时间：

• PDB 的 lastTransitionTime 是 2026-04-09T19:02:38Z
• 两个 Pod 的 Start Time 是 2026-04-10 03:02:39/40 +0800

这说明什么？

说明 PDB 进入 InsufficientPods 状态的时间，早于这两个 Pod 当前实例的启动时间。

换句话说，PDB 很可能是在 Pod 重建之前就已经进入了保护态，
而在 Pod 后面恢复并 Ready 之后，PDB 的状态没有及时刷新。

这就是整个问题最关键的证据。

---

六、我们是怎么一步步排除其他可能性的

这类问题不能上来就拍脑袋下结论，最重要的是建立证据链。

1. 排除 Pod 故障

Pod 都是 Running/Ready，而且没有重启，所以不是容器异常。

2. 排除标签选择错误

Pod 标签里明确包含：

account.super=admin

和 PDB selector 完全一致，所以不是 selector 选错对象。

3. 排除 Deployment 未完成发布

Deployment 已经 Available=True，New ReplicaSet 也已 2/2，所以不是发布没收敛。

4. 排除明显的配置错误

PDB 的 minAvailable: 1 对于 2 副本应用来说是合理的，不属于过严配置。

排除完这些之后，剩下最合理的解释就是：

PDB 状态未刷新，或者平台层对“健康”的判断比 Kubernetes 原生 Ready 更严格。

---

七、这类问题为什么容易误判

因为它本质上不是一个“Pod 真坏了”的问题，而是一个状态不一致问题：

• Pod 看起来是健康的
• Deployment 看起来也是健康的
• 但 PDB 仍然停留在历史异常状态

这时候如果只看单一资源，很容易误判为：

• 发布系统异常
• PDB 配置有问题
• 应用容器不健康

实际上，真正的问题可能只是：

控制器状态没有及时同步。

---

八、引入 AI 智能诊断，应该怎么做？

这类问题非常适合做成“证据链驱动”的 AI 诊断，而不是单纯关键词匹配。

AI 应该先做什么？

第一步，先抽取事实：

• PDB：currentHealthy=0，desiredHealthy=1
• Pod：2 个，Running，Ready
• Deployment：Available=True
• 时间线：PDB 先异常，Pod 后恢复

然后做什么？

第二步，AI 要做的是反证分析：

• 如果 Pod 真坏了，为什么还能 Ready？
• 如果 selector 错了，为什么标签完全匹配？
• 如果 Deployment 没收敛，为什么已经 2/2？
• 如果是瞬时延迟，为什么状态长期没变？

通过这些反证，AI 就能把根因收敛到：

PDB 状态未刷新，或者平台层健康判定未收敛。

最后输出什么？

AI 的输出不应该只给一个原因，还要告诉用户：

• 已排除哪些原因
• 当前证据支持什么判断
• 还需要补查哪些信息
• 下一步建议看哪些资源

这才是真正有价值的智能诊断。

---

九、这次故障给我们的启发

这次排查让我有一个很深的体会：

Kubernetes 故障排查，不能只看单点状态，必须看完整证据链。

尤其是在平台化环境里，原生 Kubernetes 状态和平台状态往往不是完全一致的：

• Pod Ready，不代表平台一定认为它可用
• Deployment Healthy，不代表 PDB 一定已经刷新
• PDB 卡住，不一定是配置错了，也可能是状态没同步

---

十、总结

这次问题的最终结论可以概括为一句话：

PDB 在历史异常阶段进入了 InsufficientPods 状态，而后续 Pod 和 Deployment 已经恢复健康，但 PDB 没有及时刷新，导致滚动发布一直被阻塞。

如果你也在排查类似问题，建议记住这三个步骤：

1. 看 PDB 是否真的在阻塞；
2. 看 Pod 和 Deployment 是否真的健康；
3. 看时间线是否能证明状态滞后。

只要把逻辑关系串起来，很多“看起来很玄”的 Kubernetes 问题，其实都能解释清楚。