StatefulSet自动重建Postgres Pod的原因及排查方法咨询

碰到StatefulSet Pod莫名重建的问题确实头疼，我来给你梳理一套一步步排查的思路，从Pod本身到集群层面都覆盖到：

1. 先挖Pod自身的退出原因 #

StatefulSet重建Pod几乎都是因为原Pod出现了故障，所以第一步先聚焦Pod本身：

• 执行 kubectl describe pod postgresPod，重点看Events区块：有没有OOMKilled（内存耗尽被杀死）、CrashLoopBackOff（容器反复崩溃）、Evicted（被kubelet驱逐）这类事件，还有容器的退出码（比如137是被强制杀死，1通常是应用自身错误）。
• 查看上一个Pod实例的日志：因为当前Pod已经是重建后的，用 kubectl logs postgresPod --previous 可以调取旧Pod的日志，看看Postgres是不是因为配置错误、连接问题或者自身崩溃导致的退出。

2. 查看StatefulSet控制器的决策日志 #

StatefulSet的重建逻辑由statefulset-controller管控，它的日志能告诉你为什么触发了重建：

• 先找到kube-controller-manager的Pod（控制器在这个组件里）：kubectl get pods -n kube-system | grep kube-controller-manager
• 过滤目标Pod的相关日志：kubectl logs <kube-controller-manager-pod-name> -n kube-system | grep "postgresPod"，这里会有更细节的决策原因，比如“Pod状态持续Unready超过5分钟”、“节点标记为NotReady”之类的触发条件。

3. 节点层面排查（验证资源/节点状态问题） #

你怀疑和节点资源或调度有关，这部分要重点查：

• 检查节点状态：kubectl describe node <原Pod所在节点名>，看Conditions里的Ready状态是否正常，再看Allocated resources区块，确认CPU、内存、存储有没有接近耗尽——如果节点资源不足，kubelet会触发Pod驱逐（OOM或者资源压力驱逐）。
• 查看kubelet日志：kubelet是节点上管理Pod的代理，用journalctl -u kubelet（systemd节点）查看日志，过滤postgresPod相关内容，看看有没有驱逐通知、节点资源告警、Pod启动失败的记录。
• 检查节点是否有故障：比如用journalctl -b查看节点最近的系统启动日志，确认是不是节点重启导致Pod被销毁重建。

4. 调度相关验证（是否被调度到新节点） #

要确认是不是调度到新节点导致的重建，可以这么做：

• 对比Pod的调度节点：在kubectl describe pod postgresPod里看Node字段，和之前记录的节点对比，确认是不是换了节点。
• 查看调度器日志：调度器在kube-system的kube-scheduler Pod里，执行kubectl logs <kube-scheduler-pod-name> -n kube-system | grep "postgresPod"，能看到调度决策的细节，比如原节点不可用、不符合调度规则，所以调度到了新节点。
• 检查StatefulSet的调度约束：看看你的StatefulSet有没有配置nodeSelector、affinity/anti-affinity规则，是不是这些规则导致Pod被重新调度到其他节点。

额外提醒：关于无PVC的StatefulSet #

你提到这个Postgres StatefulSet没有绑定PVC，那Pod重建后数据丢失是必然的——因为没有持久化存储的话，Pod的存储用的是节点临时存储或者emptyDir，Pod销毁后这些存储就会被清理。如果要保留Postgres数据，一定要给StatefulSet配置volumeClaimTemplates，让每个Pod绑定独立的PersistentVolume。

内容的提问来源于stack exchange，提问作者liotur