AKS集群重启后Pod显示运行于已不存在节点的问题排查

核心原因：集群启停方式导致Kubernetes状态不一致 #

你的操作流程（先缩容节点池至0再停止集群，重启时反向执行）会触发Kubernetes的节点失联+资源清理不彻底问题，具体逻辑如下：

1. 节点缩容的强制中断：
   使用Update-AzAksNodePool -NodeCount 0直接缩容时，AKS会快速删除节点VM，但跳过了Kubernetes的优雅驱逐流程——正常缩容时节点会先被标记为不可调度，再触发Pod的优雅终止（发送TERM信号等待应用处理），最后完成节点移除。直接缩容到0会导致Pod状态停留在Terminating，但对应节点已被强制删除。
2. 集群停止的状态冻结：
   停止AKS集群会冻结控制平面和节点资源，此时控制平面无法完成剩余的Pod状态清理（比如更新Pod终结状态、从etcd中移除无效记录）。集群重启后，控制平面恢复但旧Pod记录仍存在，而节点已被替换为新VM，就出现了"Pod显示Running/Terminating但节点不存在"的幽灵Pod。
3. 普通删除等待的本质：
   执行普通kubectl delete pod时，Kubernetes会尝试联系Pod所在节点执行终止流程，但节点已不存在，kubelet无法响应，导致API Server一直等待终止确认，最终陷入无限等待。--grace-period=0 --force是直接绕过节点，强制从etcd中删除Pod记录，属于治标不治本的临时修复。

排除Pod内服务的问题 #

集群正常运行时删除Pod能正常重启，说明你的应用可以正确处理TERM信号、完成优雅终止，不是Pod内服务的实现问题。

优化建议：修正集群启停流程 #

为避免状态不一致，调整操作步骤：

• 停止集群前：
  1. 将目标节点标记为不可调度：kubectl cordon <node-name>（批量操作可结合脚本遍历节点）
  2. 驱逐节点上所有Pod：kubectl drain <node-name> --ignore-daemonsets
  3. 再执行缩容节点池至0和停止集群的命令
• 启动集群后：
  扩容节点池完成后，检查Pod状态，若仍有幽灵Pod，再用强制删除清理（或依赖Deployment自动重建机制）

内容的提问来源于stack exchange，提问作者Markus S.