Kubelet 状态更新机制

栏目: 编程工具 · 发布时间: 5年前

内容简介:当 Kubernetes 中 Node 节点出现状态异常的情况下,节点上的 Pod 会被重新调度到其他节点上去,但是有的时候我们会发现节点 Down 掉以后,Pod 并不会立即触发重新调度,这实际上就是和 Kubelet 的状态更新机制密切相关的,Kubernetes 提供了一些参数配置来触发重新调度到嗯时间,下面我们来分析下 Kubelet 状态更新的基本流程。kube-controller-manager 和 kubelet 是异步工作的,这意味着延迟可能包括任何的网络延迟、apiserver 的延迟、

当 Kubernetes 中 Node 节点出现状态异常的情况下,节点上的 Pod 会被重新调度到其他节点上去,但是有的时候我们会发现节点 Down 掉以后,Pod 并不会立即触发重新调度,这实际上就是和 Kubelet 的状态更新机制密切相关的,Kubernetes 提供了一些参数配置来触发重新调度到嗯时间,下面我们来分析下 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,甚至更长时间。

Kubelet在更新状态失败时,会进行 nodeStatusUpdateRetry 次重试,默认为 5 次。

Kubelet 会在函数 tryUpdateNodeStatus 中尝试进行状态更新。Kubelet 使用了 Golang 中的 http.Client() 方法,但是没有指定超时时间,因此,如果 API Server 过载时,当建立 TCP 连接时可能会出现一些故障。

因此,在 nodeStatusUpdateRetry * --node-status-update-frequency 时间后才会更新一次节点状态。

同时,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 了。

配置

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

社区默认的配置

参数
–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 状态不正常之前,会有 2m* 6020 *5=30 次的 node 状态更新,Node 状态为 down 之后 1m,就会触发驱逐操作。

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

实际上,将有4到6个节点更新尝试。 尝试总次数从20到30不等。

低更新和慢响应

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

实际上,将有3到5次尝试。 尝试总次数从15到25不等。

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

原文链接: https://github.com/kubernetes-sigs/kubespray/blob/master/docs/kubernetes-reliability.md

Kubelet 状态更新机制

微信公众号

扫描下面的二维码关注我们的微信公众帐号,在微信公众帐号中回复◉加群◉即可加入到我们的 kubernetes 讨论群里面共同学习。

Kubelet 状态更新机制

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

复盘+:把经验转化为能力(第2版)

复盘+:把经验转化为能力(第2版)

邱昭良 / 机械工业出版社 / 39.00

随着环境日趋多变、不确定、复杂、模糊,无论是个人还是组织,都需要更快更有效地进行创新应变、提升能力。复盘作为一种从经验中学习的结构化方法,满足了快速学习的需求,也是有效进行知识萃取与共享的机制。在第1版基础上,《复盘+:把经验转化为能力》(第2版)做了六方面修订: ·提炼复盘的关键词,让大家更精准地理解复盘的精髓; ·基于实际操作经验,梳理、明确了复盘的"底层逻辑"; ·明确了复......一起来看看 《复盘+:把经验转化为能力(第2版)》 这本书的介绍吧!

CSS 压缩/解压工具
CSS 压缩/解压工具

在线压缩/解压 CSS 代码

RGB转16进制工具
RGB转16进制工具

RGB HEX 互转工具

RGB HSV 转换
RGB HSV 转换

RGB HSV 互转工具