Kubelet运行机制
Kubelet是Kubernetes中的一个重要组件,在每个 Node 节点上都会启动 kubelet 服务。 该服务主要用于处理 Master 节点下发到本节点的任务,管理 Pod及Pod 中的容器。每个kubelet 进程会在 API Server 上注册节点自身信息,定期向 Master 节点汇报节点资源的使用情况 , 并通过cAdvisor 监控容器和节点资源。在本文中,我们将分析Kubelet的运行机制。
Kubelet的工作流程
每个节点上的kubelet启动后,它的工作流程可以分为以下几个步骤:
-
获取Pod列表:Kubelet(watch机制监视)会从Master节点获取节点上的Pod列表。Master节点会将Pod列表发送给Kubelet,并告诉Kubelet哪些Pod需要在该节点上运行。
-
创建Pod:如果Kubelet发现节点上没有某个Pod的容器在运行,它会根据Pod的定义创建容器。Kubelet会根据Pod的定义创建一个Pod Sandbox,然后在Pod Sandbox中创建容器。
-
监控容器状态:Kubelet会定期检查容器的状态,并将状态报告给Master节点。如果容器出现故障,Kubelet会尝试重启容器。如果重启失败,Kubelet会将容器标记为失败,并将状态报告给Master节点。
-
清理容器:如果Kubelet发现某个容器已经被删除,它会将该容器从节点上清理掉。
Kubelet的相关配置
Kubelet的配置文件可以放在多个配置文件中,具体看部署方式。可能是/etc/kubernetes/kubelet.conf、/usr/lib/systemd/system/kubelet.service、/var/lib/kubelet/config.yaml。很多默认配置都可以不用修改,主要的配置包括以下几个方面:
-
节点名称:Kubelet需要知道节点的名称,以便向Master节点注册自己。
-
Pod网络:Kubelet需要知道Pod网络的配置,以便能够正确地创建Pod Sandbox和容器。
-
容器运行时:Kubelet需要知道容器运行时的一些参数,以便能够满足业务需要。
-
资源限制:Kubelet需要知道节点的资源限制,以便能够正确地调度Pod,与优化相关。
Kubelet 状态更新机制
当 Kubernetes 中 Node 节点出现状态异常的情况下,节点上的 Pod 会被重新调度到其他节点上去,但是有的时候我们会发现节点 Down 掉以后,Pod 并不会立即触发重新调度,这实际上就是和 Kubelet 的状态更新机制密切相关的,Kubernetes 提供了一些参数配置来触发重新调度到node时间,下面我们来分析下 Kubelet 状态更新的基本流程。
默认情况下,正常的行为如下:
- kubelet 自身会定期更新状态到 apiserver,更新周期由--node-status-update-frequency参数指定,默认值是10s
- Kubernetes Controller Manager定期的检查kubelet状态,该参数由–-node-monitor-period参数指定,默认值5s
- Kubernetes Controller Manager对kubelet状态更新有一个容忍值,如果kubelet在这个容忍值内更新状态,那么Kubernetes Controller Manager认为kubelet状态有效。具体为:
- 当 node 失联一段时间后,kubernetes 判定 node 为notready 状态,这段时长通过 –node-monitor-grace-period 参数配置,默认为40s
- 当 node 失联一段时间后,kubernetes 判定 node 为unhealthy 状态,这段时长通过 –node-startup-grace-period 参数配置,默认为1m
- 当 node 失联一段时间后,kubernetes 开始删除原 node 上的 pod,这段时长是通过–pod-eviction-timeout 参数配置,默认为5m
- Kubernetes Controller Manager和kubelet异步工作,这意味着延迟可能包含网络延迟,API Server延迟,etcd延迟,节点负载等引起的延迟,所以如果设置--node-status-update-frequency参数为5秒时,那么当etcd无法将数据提交到仲裁节点时,它可能会在etcd中等待6-7秒甚至更长才能被呈现
失败情况
- kubelet将尝试发送nodeStatusUpdateRetry ,当前nodeStatusUpdateRetry在kubelet.go.中设置为5次
- kubelet将使用 tryUpdateNodeStatus方法发送状态.kubelet使用golang的http.Client()方法,但是没指定超时时长,因此当在apiserver过载时TCP连接会造成一些问题.
- 因此,这里尝试使用nodeStatusUpdateRetry 乘以 --node-status-update-frequency的值设置node状态.
- 在同时Kubernetes Controller Manager每隔--node-monitor-period设置的时间检查nodeStatusUpdateRetry设置的次数,经过--node-monitor-grace-period设定的时间将认为node不健康,通过在 kube-apiserver组件中设置--default-not-ready-toleration-seconds & --default-unreachable-toleration-seconds 这两个默认的容忍参数。Kubernetes 会自动为每个 pod 添加一个默认容忍配置,默认容忍限制为60s。在添加这两个参数后需要重新部署所有 Pod 以确保将容忍添加到所有 Pod 中。除了使用kube-apiserver的参数使其对所有 pod 进行全局更改之外你还可以指定为 pod 设置忍驱逐时间。
- 同时Kube-Proxy watch API server,一旦pod被删除,那么集群中所有kube-proxy将更新其节点上的iptables规则,移除相应的endpoint,这使得请求无法被发送到故障节点的pod
实际应用
默认的配置(参数所属组件)
参数 | 值 | 组件 |
---|---|---|
--node-status-update-frequency | 10s | kubelet |
--node-monitor-period | 5s | controller manager |
--node-monitor-grace-period | 40s | controller manager |
快速更新和快速响应
参数 | 值 | 组件 |
---|---|---|
--node-status-update-frequency | 4s | kubelet |
--node-monitor-period | 2s | controller manager |
--node-monitor-grace-period | 20s | controller manager |
如果--node-status-update-frequency设置为4s(默认为10s)。 --node-monitor-period设置为2s(默认为5s)。--node-monitor-grace-period设置20s(默认为40s)。--default-not-ready-toleration-seconds & --default-unreachable-toleration-seconds 设置为30(默认为 300 秒)。注意,这两个值应该是表示秒数的整数。
在这种情况下,Pod 将在 50s 后被驱逐,因为节点将在 20s 后被视为Down掉了,--default-not-ready-toleration-seconds 或者 --default-unreachable-toleration-seconds 在 30s 之后开始删除Pod。但是,这种情况会给 etcd 产生很大的开销,因为每个节点都会每 2s 更新一次状态。
如果环境有1000个节点,那么每分钟将有30000次节点更新操作,这可能需要大型 etcd 容器甚至是 etcd 的专用节点。
如果我们计算尝试次数,则除法将给出5,但实际上每次尝试的 nodeStatusUpdateRetry 尝试将从3到5。 由于所有组件的延迟,尝试总次数将在15到25之间变化。
中等更新和平均响应
参数 | 值 | 组件 |
---|---|---|
--node-status-update-frequency | 20s | kubelet |
--node-monitor-period | 5s | controller manager |
--node-monitor-grace-period | 2m | controller manager |
我们设置--node-status-update-frequency设置为20s。--node-monitor-grace-period设置为2m,并将 --default-not-ready-toleration-seconds 和 --default-unreachable-toleration-seconds设置为60s。这种场景下会 20s 更新一次 node 状态,Kubernetes Controller Manager 对 kubelet检测,在2分钟内进行 6 * 5 = 30 次尝试如果没有更新节点状态。1m后它将驱逐所有 pod。那么将在一分钟后驱逐所有pod总共耗时3分钟。
此处情况适用于中等环境,因为1000个节点每分钟需要对etcd进行3000次更新。
低更新和慢响应
参数 | 值 | 组件 |
---|---|---|
--node-status-update-frequency | 1m | kubelet |
--node-monitor-period | 5s | controller manager |
--node-monitor-grace-period | 5m | controller manager |
如果--node-status-update-frequency设置为1m。 --node-monitor-grace-period设置为5m,并将 --default-not-ready-toleration-seconds 和 --default-unreachable-toleration-seconds设置为60s。在这种情况下kubelet将在每分钟上报状态,5分钟内kubelet没有更新节点状态Kubernetes Controller Manager将节点设置为不健康,在一分钟后开始驱逐所有pod总共耗时6分钟。
总结
Kubelet是Kubernetes中的一个重要组件,它负责管理节点上的容器和Pod,并与Master节点进行通信。Kubelet的工作流程包括获取Pod列表、创建Pod、监控容器状态和清理容器。Kubelet的配置包括节点名称、Pod网络、容器运行时和资源限制。
计算公式
驱逐时间 =( --node-monitor-grace-period + --default-not-ready-toleration-seconds 或 --default-unreachable-toleration-seconds)
可以有不同的配置组合,满足自己实际的使用情况。
更多关于kubernetes的知识分享,请前往博客主页。编写过程中,难免出现差错,敬请指出