kubernetes node notReady触发pod重调度策略

当kubernetes中node的状态异常的时候，会导致无状态的pod重新调度到其他的节点中，关于什么时候会触发重新调度，很多人都很关心，kubernetes原生提供了参数配置触发重新调度的时间，首先分析触发该流程的具体流程：

1. kubelet周期性的更新自身状态到apiserver,周期为–node-status-update-frequency 默认值10s
2. controller manager每–-node-monitor-period会检查kubelet上报上来的状态，默认值为5s
3. node的状态将会–node-monitor-grace-period周期内更新，controller manager中设置默认值为40s

4. kubelet在更新自身状态的时候将会有nodeStatusUpdateRetry 次重试，当前nodeStatusUpdateRetry 设置的默认值为5次

   所以将会发生nodeStatusUpdateRetry * –node-status-update-frequency才能更新一次node的状态。同时，controller manager将会每个–node-monitor-period周期内检查nodeStatusUpdateRetry 次，当–node-monitor-grace-period周期之后将会认为node unhealthy. 它将会根据–pod-eviction-timeout时间来移除pods

这里需要注意以下内容

1. controller manager和kubelet之间是异步工作的。他们之间的delay将会受到network latency, apiserver latency ,etcd latency，以及master node上的负载的影响。如果–node-status-update-frequency设置成5s，实际上etcd中数据的变化将会有6-7s甚至更长的时间。

2. kube proxy会watch api-server。一旦pod evicted, kube proxy将会注意到，更新node的iptables. 将会从services中移除对应的endpoints

对于配置参数的设置，社区推荐可以根据不同的集群规模场景进行配置

• default

  社区默认的配置

参数	值
-–node-status-update-frequency	10s
–node-monitor-period	5s
–node-monitor-grace-period	40s
–pod-eviction-timeout	5m

• Fast update and Fast Reaction

  快速响应的配置场景，但是同时会产生频繁的node update事件，加重etcd的负担

参数	值
-–node-status-update-frequency	4s
–node-monitor-period	2s
–node-monitor-grace-period	20s
–pod-eviction-timeout	30s

这种场景下20s之后，会认为node down了，接着—pod-eviction-timeout=30s之后，pod将会被驱逐，也就是50s会发生evict. 但是会增加etcd的负载，每个node将会每2s更新一次etcd的状态。

如果环境中有1000 nodes, 那么每分钟将会有15000次node updates操作

• Medium Update and Average Reaction

  快速响应的配置场景，但是同时会产生频繁的node update事件，加重etcd的负担

参数	值
-–node-status-update-frequency	20s
–node-monitor-period	5s
–node-monitor-grace-period	2m
–pod-eviction-timeout	1m

将会20s更新一次node状态，也就是说controller manager认为node状态不正常之前，会有2m*60/20*5=30次更新node的状态。Node状态为down之后1m，就会触发evict.

如果1000node的场景，1分钟内将会有60s/20s*1000=3000次 etcd node状态的更新

• Low Update and Show reaction

  快速响应的配置场景，但是同时会产生频繁的node update事件，加重etcd的负担

参数	值
-–node-status-update-frequency	1m
–node-monitor-period	5s
–node-monitor-grace-period	5m
–pod-eviction-timeout	1m

Kubelet将会1m更新一次node的状态，在认为不健康之后会有5m/1m*5=25次重试更新的机会。Node为不健康的时候，1m之后pod开始evict.

参考

https://github.com/kubernetes-incubator/kubespray/blob/master/docs/kubernetes-reliability.md