【kubernetes系列】Kubernetes之Kubelet运行机制和状态更新机制

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的知识分享，请前往博客主页。编写过程中，难免出现差错，敬请指出