Kubernetes调整Worker节点快速驱逐pod的时间

Kubernetes调整Worker节点快速驱逐pod的时间

Deng YongJie's blog 476 2022-08-07

Kubernetes调整Worker节点快速驱逐pod的时间

在高可用的k8s集群中,当Node节点挂掉,kubelet无法提供工作的时候,pod将会自动调度到其他的节点上去,而调度到节点上的时间需要我们慎重考量,因为它决定了生产的稳定性、可靠性,更快的迁移可以减少我们业务的影响性,但是有可能会对集群造成一定的压力,从而造成集群崩溃。

在高可用的k8s集群中,当Node节点挂掉,kubelet无法提供工作的时候,pod将会自动调度到其他的节点上去,而调度到节点上的时间需要我们慎重考量,因为它决定了生产的稳定性、可靠性,更快的迁移可以减少我们业务的影响性,但是有可能会对集群造成一定的压力,从而造成集群崩溃。

Kubelet 状态更新的基本流程:

  • 1.kubelet 自身会定期更新状态到 apiserver,通过参数–node-status-update-frequency指定上报频率,默认是 10s 上报一次。
  • 2.kube-controller-manager 会每隔–node-monitor-period时间去检查 kubelet 的状态,默认是 5s。
  • 3.当 node 失联一段时间后,kubernetes 判定 node 为 notready 状态,这段时长通过–node-monitor-grace-period参数配置,默认 40s。
  • 4.当 node 失联一段时间后,kubernetes 判定 node 为 unhealthy 状态,这段时长通过–node-startup-grace-period参数配置,默认 1m0s。
  • 5.当 node 失联一段时间后,kubernetes 开始删除原 node 上的 pod,这段时长是通过–pod-eviction-timeout参数配置,默认 5m0s。

kube-controller-manager 和 kubelet 是异步工作的,这意味着延迟可能包括任何的网络延迟、apiserver 的延迟、etcd 延迟,一个节点上的负载引起的延迟等等。因此,如果–node-status-update-frequency设置为5s,那么实际上 etcd 中的数据变化会需要 6-7s,甚至更长时间。

配置

对于这些参数的配置,需要根据不同的集群规模场景来进行配置。

社区默认的配置

参数
–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 更新一次状态。

如果环境有1000个节点,那么每分钟将有15000次节点更新操作,这可能需要大型 etcd 容器甚至是 etcd 的专用节点。

如果计算尝试次数,则除法将给出5,但实际上每次尝试的 nodeStatusUpdateRetry 尝试将从3到5。 由于所有组件的延迟,尝试总次数将在15到25之间变化。

中等更新和平均响应

参数
–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,就会触发驱逐操作。

如果有 1000 个节点,1分钟之内就会有 60s/20s*1000=3000 次的节点状态更新操作。

低更新和慢响应

参数
–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开始被驱逐。

可以有不同的组合,例如快速更新和慢反应以满足特定情况。

也会有特殊情况,例如使用statefulset部署的有状态应用宿主机宕机后应用高可用问题,参考文档 https://www.infoq.cn/article/aMsCvWzhR1It5CxpDWXK

参考文档:

https://github.com/kubernetes-sigs/kubespray/blob/master/docs/kubernetes-reliability.md
https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/kubelet-eviction.md
https://www.qikqiak.com/post/kubelet-sync-node-status/
https://www.infoq.cn/article/aMsCvWzhR1It5CxpDWXK

注意:以上只是快速更新节点状态,并不代表能快速驱逐pod,并快速在其它节点创建pod。节点宕机30秒后,只是节点失联状态,pod处于uknown状态。

实际pod-eviction-timeout参数没任何用。默认创建deployment时会创建 not-ready、unreachable。这2个参数会直接影响在pod不健康状态时恢复的时间。

所以想要更快的恢复pod。有2种办法。

1、直接修改kube-apiserver启动参数。把默认值改了。(须重启pod适配新参数后生效)

下面才是pod快速在其它节点创建的参数,需要修改api-server

 --default-not-ready-toleration-seconds=60 \
 --default-unreachable-toleration-seconds=60 \

因为节点宕机,节点就会被打上污点

文档:https://kubernetes.io/zh-cn/docs/reference/command-line-tools-reference/kube-apiserver/

https://kubernetes.io/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration/

image-20220726191717431