节点关机后Pod不重新调度

问题现象

节点关机后，节点上的Pod仍然显示running状态。通过kubectl describe pod <pod-name>命令查询Pod最新事件为：

Warning NodeNotReady 17s node-controller Node is not ready

问题原因

节点关机后，系统会自动给节点添加污点，比如：

• node.kubernetes.io/unreachable:NoExecute
• node.cloudprovider.kubernetes.io/shutdown:NoSchedule
• node.kubernetes.io/unreachable:NoSchedule
• node.kubernetes.io/not-ready:NoExecute

当Pod对这些污点存在容忍策略时，Pod不会进行重新调度，因此需要检查Pod对污点的容忍策略。

解决方案

通过查询Pod或者工作负载的yaml，查看容忍策略。一般情况下，工作负载的容忍度设置由以下字段组成：

tolerations: 
- key: "key1"
  operator: "Equal"
  value: "value1" 
  effect: "NoSchedule"

或者：

tolerations: 
- key: "key1"
  operator: "Exists"
  effect: "NoSchedule"

当上述容忍度的设置填写错误时，可能会出现调度问题。例如以下的容忍策略：

tolerations:
- operator: "Exists"

上述例子中只填写了operator参数为Exists（此时容忍度不能指定value参数）。

• 当一个容忍度的operator参数为Exists但key为空时， 表示这个容忍度与任意的key、value和effect都匹配，即这个容忍度能容忍任何污点。
• 如果effect为空但键名key已填写，则表示与所有键名key的效果相匹配。

关于Kubernetes容忍度的详细说明，请参见污点和容忍度。

因此，需要修改工作负载的yaml，还原tolerations为默认配置如下：

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

上述默认的容忍度表示Pod可以在拥有以上污点的节点上运行300s，然后会被驱逐。