RKE部署本地K8s节点宕机后运行Pod迁移失败如何解决

核心排查路径 #

• 首先确认节点故障判定时效
  执行kubectl get nodes查看关机的worker2节点状态，只有当节点被标记为NotReady后，kube-controller-manager才会等待pod-eviction-timeout配置的时长（RKE集群默认值为5分钟）触发Pod驱逐流程，关机后短时间内Pod不迁移属于正常现象，不是故障。
• 排查Pod是否存在硬节点绑定规则
  执行kubectl get pod <故障Pod名> -o yaml查看Pod配置，确认是否存在以下阻止跨节点调度的配置：
  • 直接配置nodeName: worker2硬指定运行节点
  • 配置nodeSelector仅匹配worker2节点独有的标签
  • 配置硬节点亲和性规则requiredDuringSchedulingIgnoredDuringExecution，强制要求调度目标节点必须携带只有worker2有的标签
  • 若故障Pod属于StatefulSet，检查其绑定的存储卷是否为localPersistentVolume本地存储，这类存储和单节点生命周期绑定，无额外迁移能力的前提下无法漂移到其他节点
• 排查污点与容忍配置不匹配问题
  执行kubectl describe node <其余可用worker节点名>查看节点Taints字段：
  • 若其余worker节点被误打上node-role.kubernetes.io/controlplane:NoSchedule、node.kubernetes.io/unreachable:NoSchedule这类业务Pod没有对应容忍的污点，调度器会直接跳过这些节点
  • 反过来检查故障Pod的tolerations字段，如果只配置了针对worker2节点专属污点的容忍，也无法调度到其余节点
• 排查PDB规则阻塞驱逐
  执行kubectl get pdb -A查看所有Pod中断预算配置，如果对应业务的PDB设置了过高的minAvailable值，会导致驱逐流程被API Server拦截，无法在其他节点创建新的Pod副本。
• 明确PriorityClass方案无效的原因
  PriorityClass仅在集群资源不足、需要抢占低优先级Pod资源释放配额时生效，完全不涉及节点故障判定、驱逐触发、调度规则匹配、污点校验这些流程，无法解决你当前的故障属于正常情况，方案本身不对症。

对应修复方案 #

• 调整节点故障判定时效（按需操作）
  如果默认5分钟的驱逐等待时间过长，可以修改RKE集群的cluster.yml配置文件，在kube-controller-manager配置段添加参数pod-eviction-timeout: 1m（可根据业务对网络抖动的容忍度调整，不建议设置小于30s避免误驱逐），之后执行rke up滚动更新集群控制组件即可。

  RKE2集群需要在所有control-plane节点的/etc/rancher/rke2/config.yaml中添加对应参数，重启rke2-server服务生效。

• 解除硬调度绑定
  删除Pod模板里的nodeName硬编码，调整nodeSelector、节点亲和性规则，给所有可用worker节点打上匹配的业务标签，保证调度规则能覆盖全部工作节点。
• 解决存储绑定问题
  对需要故障漂移能力的基础业务，更换为支持多节点挂载的共享存储（Longhorn、Ceph RBD、NFS等），不要使用单节点本地存储承载这类工作负载。
• 修复污点配置
  执行kubectl taint node <节点名> <污点key>-删除worker节点上误加的NoSchedule类污点；如果是业务专属污点，给对应Pod的工作负载模板添加匹配的容忍规则即可。
• 调整PDB规则
  修改对应业务的PDB配置，保证节点故障场景下至少允许1个副本被驱逐重建，避免驱逐流程被阻塞。
• 修复后验证
  不要直接关机测试，先手动给worker2打上模拟不可达的污点kubectl taint node worker2 node.kubernetes.io/unreachable:NoSchedule，等待配置的驱逐时长后，观察Pod是否能正常调度到其余可用节点，确认漂移正常后再做关机验证。

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