Crunchy Postgres Operator节点故障后Pod无法迁移问题排查

1. 确认节点状态与驱逐规则问题 #

• 检查worker3节点状态：运行kubectl get nodes，确认它是否标记为NotReady，以及是否带有node.kubernetes.io/unreachable或node.kubernetes.io/not-ready污点。如果节点未被正确标记为不可用，K8s不会触发Pod重建逻辑。
• 查看PodDisruptionBudget（PDB）配置：执行kubectl get pdb，若Postgres集群配置的PDB中minAvailable值等于副本数（比如2），当原主节点挂掉后，剩余节点无法满足“至少2个可用实例”的要求，会直接阻止新Pod调度。
• 核对节点污点与Pod容忍度：运行kubectl describe node worker1 worker2，检查这两个节点是否存在阻止Postgres Pod调度的污点；再用kubectl describe pod <postgres-pod-name>查看Pod的tolerations配置，确认它能匹配目标节点的污点规则。

2. 验证Crunchy Operator的调度约束 #

• 检查Operator生成的StatefulSet：执行kubectl describe statefulset <your-postgres-statefulset-name>，重点查看Affinity、NodeSelector字段。即使手动调整过亲和性，Operator可能会覆盖这些配置，需确认最终生效的规则里有没有绑定worker3的硬约束。
• 查看PostgresCluster CR配置：运行kubectl get postgrescluster <cluster-name> -o yaml，检查spec.instances下的affinity配置，尤其是requiredDuringSchedulingIgnoredDuringExecution部分，若指定了worker3的节点标签，Pod必然无法调度到其他节点。

3. 排查存储卷绑定问题 #

• 检查PVC/PV的访问模式：Postgres使用的持久化卷如果是ReadWriteOnce（RWO）类型，原节点挂掉后，其他节点无法直接挂载该卷。执行kubectl describe pv <pv-name>确认accessModes，若为RWO，需等原节点彻底释放卷后才能重新挂载，但节点处于NotReady状态时这个过程可能卡住。
• 查看PV回收策略：如果PV的reclaimPolicy为Retain，原节点挂掉后PV不会自动重新分配，需手动删除PV并重新绑定PVC。

4. 查看Pod事件与Operator日志 #

• 查看Terminating状态Pod的事件：运行kubectl describe pod <terminating-pod-name>，在Events板块查找关键错误，比如VolumeInUse（卷被占用）、FailedDelete（删除Pod失败）等提示。
• 查看Operator日志：执行kubectl logs <operator-pod-name> -n <operator-namespace>，搜索与故障转移、Pod调度相关的报错——比如Operator未检测到主节点故障，或无法触发副本晋升，都会导致Pod无法重建。

5. 检查K8s控制器状态 #

• 查看StatefulSet状态：运行kubectl describe statefulset <your-postgres-statefulset-name>，查看Status中的Replicas和Ready Replicas数值，是否存在更新失败的记录。
• 核对kube-controller-manager日志：如果是集群层面的驱逐问题，查看kube-controller-manager的日志，确认是否存在“无法驱逐节点上的Pod”相关报错。

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