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
欢迎交流， 我会积极回复的 ☺
