主机宕机时如何让K8s忽略terminationGracePeriod立即重调度Pod？

该问题的核心逻辑是：正常优雅删除Pod的场景下，terminationGracePeriod会生效用于处理数据移交等收尾逻辑，但节点宕机属于节点不可达/NotReady异常场景，该场景下的Pod驱逐等待逻辑和terminationGracePeriod互相独立，可通过集群层面或工作负载层面的配置调整重调度等待时长。

1. 集群层面全局配置（适用于所有工作负载） #

调整kube-controller-manager的启动参数，修改全局节点宕机驱逐阈值：

• --node-monitor-grace-period：节点状态无响应后判定为NotReady的等待时长，默认40s，可根据集群网络稳定性适当调低
• --pod-eviction-timeout：节点进入NotReady状态后，等待多久开始驱逐该节点上的所有Pod，默认5m，可调整到你预期的重调度等待时长，例如设置为30s即可在确认节点宕机后30s触发驱逐，无需等待Pod配置的长terminationGracePeriod

注意：该配置全局生效，调整前需评估集群内其他业务的兼容性。

2. 工作负载层面单独配置（仅对Cassandra生效） #

如果不想修改集群全局参数，可以单独给Cassandra StatefulSet添加容忍度规则，自定义该工作负载的节点宕机驱逐等待时长，在spec.template.spec.tolerations字段下添加如下配置即可：

tolerations:
- key: "node.kubernetes.io/unreachable"
  operator: "Exists"
  effect: "NoExecute"
  tolerationSeconds: 30
- key: "node.kubernetes.io/not-ready"
  operator: "Exists"
  effect: "NoExecute"
  tolerationSeconds: 30

其中tolerationSeconds就是节点进入异常状态后，Pod允许留在原节点的最长时长，超过该时长就会被立即驱逐重调度，该参数优先级高于集群全局的pod-eviction-timeout，也不受terminationGracePeriod影响。

注意事项 #

• 重调度前确保Cassandra使用的PV支持跨节点挂载，避免新调度的Pod无法挂载原有数据导致启动失败
• 建议搭配Cassandra自身的一致性策略（如QUORUM读写）使用，避免短时间重调度导致数据不一致
• 正常滚动更新、手动删除Pod等kubelet可正常通信的场景下，terminationGracePeriod仍会正常生效，不会影响原有的优雅数据移交逻辑

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