1.kubelet定期上报
--node-status-update-frequency 指定上报频率，默认10s
2.kube-controller-manager 定期检查
--node-monitor-period 定期检查kubelet状态，默认5s
3.node失联状态变更
ready-->notready
--node-monitor-grace-period 失联指定时间后，将readey变成为notready，默认40s
notready-->unhealthy
-node-startup-grace-period 失联指定时间后，判定为unhealthy状态，默认1m
4.删除node上pod
--pod-eviction-timeout 失联指定时间后，删除原node上的pod
5.kubelet状态失败重试
kubelet 在更新状态失败时、会进行nodeStatusUpdateRetry 次使用tryUpdateNodeStatus函数重试；
但kubelet使用了Golang中的http.Client()方法、但没有指定超时时间，即可能出现故障。
因此，实际上在nodeStatusUpdateRetry * --node-status-update-frequency时间后才会更新一次节点状态；
6.controller manager 对kubelet的检查和重试
同时，Kubernetes 的 controller manager 将尝试每--node-monitor-period时间周期内检查nodeStatusUpdateRetry次。在--node-monitor-grace-period之后，会认为节点 unhealthy，然后会在--pod-eviction-timeout后删除 Pod。
kube proxy 有一个 watcher API，一旦 Pod 被驱逐了，kube proxy 将会通知更新节点的 iptables 规则，将 Pod 从 Service 的 Endpoints 中移除，这样就不会访问到来自故障节点的 Pod 了。
7.参数配置
社区默认的配置
–node-status-update-frequency 10s
–node-monitor-period 5s
–node-monitor-grace-period 40s
–pod-eviction-timeout 5m
快速更新和快速响应
–node-status-update-frequency 4s
–node-monitor-period 2s
–node-monitor-grace-period 20s
–pod-eviction-timeout 30s
在这种情况下，Pod 将在 50s 被驱逐，因为该节点在 20s 后被视为Down掉了，--pod-eviction-timeout在 30s 之后发生，但是，这种情况会给 etcd 产生很大的开销，因为每个节点都会尝试每 2s 更新一次状态。
中等更新和平均响应
–node-status-update-frequency 20s
–node-monitor-period 5s
–node-monitor-grace-period 2m
–pod-eviction-timeout 1m
这种场景下会 20s 更新一次 node 状态，controller manager 认为 node 状态不正常之前，会有 2m60⁄205=30 次的 node 状态更新，Node 状态为 down 之后 1m，就会触发驱逐操作。
低更新和慢响应
–node-status-update-frequency 1m
–node-monitor-period 5s
–node-monitor-grace-period 5m
–pod-eviction-timeout 1m
Kubelet 将会 1m 更新一次节点的状态，在认为不健康之后会有 5m/1m*5=25 次重试更新的机会。Node为不健康的时候，1m 之后 pod开始被驱逐。
8.kubelet进程异常时Pod状态
8.1 Node状态变更为NotReady
8.2 pod 5分钟（–pod-eviction-timeout ）之内状态无变化，5分钟（–pod-eviction-timeout ）后
• Daemonset的Pod状态变为Nodelost
• Deployment、Statefulset和Static Pod的状态先变为NodeLost，然后马上变为Unknown
• Deployment的pod会recreate，但受到node selcector等的限制
• Static Pod和Statefulset的Pod会一直处于Unknown状态
有疑问加站长微信联系（非本文作者）
