kubernetes-工作节点异常时pod的重新调度机制

节点状态更新机制

1. kube-controller-manager会每隔–node-monitor-period=5s时间去调用kube-apiserver读取etcd数据检查 kubelet上报的node状态信息。
2. kubelet会每隔–node-status-update-frequency=10s时间去调用kube-apiserver上报node状态信息，失败重试次数为–node-status-update-retry=5。
3. kube-controller-manager和kubelet是异步工作的。

节点被置为notready状态的两种情况

1. 运行中的节点在没有响应的情况下，持续–node-monitor-grace-period=40s后，kube-controller-manager会把node置为notready状态。
2. 新启动的节点在没有响应的情况下，持续–node-startup-grace-period=1m后，kube-controller-manager会把node置为notready状态。

pod重新调度机制(TaintBasedEvictions)

1. 当kube-controller-manager把node状态置为notready后，会在对应的节点打上node.kubernetes.io/not-ready标签。
2. 在kube-apiserver的–default-not-ready-toleration-seconds=300s的参数下，默认会在所有pod自动加上容忍度配置。
3. 在节点被打上node.kubernetes.io/not-ready标签后，触发容忍度机制，默认达到300s后，pod开始迁移。

ps：–pod-eviction-timeout在Kubernetes v1.18版本后被废弃，全部采用TaintBasedEvictions。
ps：当node处于unreachable状态时同理。

重新调度的限制

1. 当pod使用pv的accessModes为ReadWriteOnce，会导致新pod创建阻塞。
2. statefulset要保证不会有两个拥有相同标记和存储的pod同时运行，所以statefulset要明确知道一个pod不再运行之后，才会调度新的pod。但是当一个节点突然失效，导致Kubernetes并不知道节点或者它上面的pod的状态，所以statefulset类型在该节点的pod不会被自动调度。

官网对于statefulset的部署和扩缩容的解释

• 对于包含 N 个 副本的 StatefulSet，当部署 Pod 时，它们是依次创建的，顺序为 0…N-1。
• 当删除 Pod 时，它们是逆序终止的，顺序为 N-1…0。
• 在将扩缩操作应用到 Pod 之前，它前面的所有 Pod 必须是 Running 和 Ready 状态。
• 在一个 Pod 终止之前，所有的继任者必须完全关闭。