tune kubernetes eviction parameter

Highlight

本文会介绍kubernetes中关于集群驱逐的相关参数，合理设置驱逐速率的考虑因素，但是不会涉及node层面资源的驱逐阈值的设置。

Basic

在kubernetes中，如果一个node出现故障，例如节点宕机或与节点网络异常， controller manager中的node controller会检测到心跳超时后会将node状态置为ConditionUnknown，等待一段时间后开始驱逐该node上面的pod，默认是40s认为心跳超时，等待5min后开始驱逐pod，可以设置--node-monitor-grace-period参数指定NodeController判定心跳超时的时间，默认为40s，通过设置参数 --pod-eviction-timeout指定node异常多久后开始驱逐pod，默认是5min，--node-monitor-period 为心跳检查间隔，即node controller会在该间隔内检查心跳node状态，默认是5s。
kubelet 会经过--node-status-update-frequency上报node信息，默认是10s，在1.13版本之前， node status 的更新就是心跳， 1.13引入了新的node lease机制，这是专门为心跳引入的机制，可以有效降低master的负载，为了与现在的行为保证一致，现在的lease renew 间隔为10s，且目前该值hard code 在代码中。

在一个集群中，可能会出现所有的node都无法连接master，例如master节点网络故障， kubernetes充分考虑到了这种情况，会有一些异常处理措施。默认情况下，集群状态正常， node controller 驱逐的速率为--node-eviction-rate，默认是0.1，即kubernetes最快每10s中驱逐一个node上的pod。但是当一个大集群中有一定比例的node都not ready后，此时kubernete会认为是master节点出现了故障，会减慢该驱逐速率，采用二级驱逐速率，其中大集群是通过--large-cluster-size-threshold参数控制，默认是50，集群不健康的比例是通过--unhealthy-zone-threshold 控制，默认是0.55，二级驱逐速率是通过--secondary-node-eviction-rate控制，默认是0.001，也就是说默认情况下：当集群规模大于50个node时，集群中只要有55%的node不健康，就会认为master出现了故障，会将驱逐速率从0.1降为0.001；如果集群规模小于50个node，集群中出现55%的node不健康，就会停止驱逐。

Tune eviction parameter

这几个参数都是异常重要的，在必要时候免于危难，尤其是在大集群情况下。通常情况下， master无法连接的概率较小，相对于网络分区等这种故障，比较常见的是master前面的LB出现故障，一般我们会部署多个master节点来实现failover，然后在前面设置一个共同的入口LB，所有kubelet连接LB。社区中有不少issue是关于LB无法连接的问题的。还有一种情况是当一个集群中部分node不可用之后，大量pod漂移可能会导致故障扩散，也就是集群雪崩。合理的设置这几个参数可以保证在最坏情况下都不至于出现大量pod漂移的问题。

这几个参数都是互相关联的，设置的时候需要综合考虑，并且需要结合集群的现有状况。比如上述这些参数默认是指kubernetes部署在多zone环境下，一个zone挂掉之后可以驱逐pod到另外一个健康的zone中，但是如果我们是一个的单机房，单集群的话，就没办法实现跨zone 容错，此时我们应该设置--secondary-node-eviction-rate为0，也就是说，一个大集群中有大量node不可用时，我们就停止驱逐，防止故障扩散。

--unhealthy-zone-threshold 的选择需要根据集群buffer来设置，比如说一个集群已经将近饱和，所有的资源已经快分配完了，集群buffer最多可以容纳50个pod，此时如果还设置--unhealthy-zone-threshold为默认值的话，极端情况下，当集群不可用时间过长，会导致kubernetes驱逐大概一半的pod，这是因为集群buffer已满，新创建的pod已经无法容纳了，此时驱逐也没有用。
一般情况下，我们集群的buffer < 15%，所以该参数设置为 <10%，虽然buffer为15%，但是考虑到集群资源的碎片等问题， 15%的buffer不能全部分配出去，所以该值最好小于10%。当然这个值根据不同的集群资源情况和上面--secondary-node-eviction-rate的速率合理取舍。

--pod-eviction-timeout的设置更多的是根据业务类型来取舍，如果设置的太短，可能会因为一些网络抖动导致一些不必要的驱逐，如果设置的太长，会导致业务在短时间内无法恢复到指定实例数。官方默认的5min感觉一般情况下是无需改变。

还有一种情况是，集群在大小集群之间摇摆，比如说，对于默认的--large-cluster-size-threshold的值为50，当集群node数刚好在50和51之间时摇摆时，需要考虑两种情况分别作用的影响。

可以看到所有的这些参数都是建立在集群不可用时间的基础上，只有故障快速恢复才是王道，当你集群可用性是0.9999，四个九时，年不可用时间约为50分钟，以默认的二级驱逐速率0.001来说，相当于才驱逐了30个node，一般情况下，对于稍大点的集群来说，还不算什么问题。故障发生的时候，真是分秒必争啊。

当选择了合适的参数之后，可以通过一些虚拟的简单进行测试一下，社区有一些virtual kubelet 和kubemark都可以用来创建虚拟node来模拟大规模集群，具体使用细节此处不做深究，感兴趣的读者请自行探索。

Reference

kubernetes document: Nodes

欢迎交流，我会积极回复的 ☺