当前位置：首页 > news >正文

管理咨询公司经营范围seo专员招聘

news 2025/8/14 17:31:59

管理咨询公司经营范围,seo专员招聘,网站做app要权限,wordpress文件位置Kubelet运行机制 Kubelet是Kubernetes中的一个重要组件，在每个 Node 节点上都会启动 kubelet 服务。该服务主要用于处理 Master 节点下发到本节点的任务，管理 Pod及Pod 中的容器。每个kubelet 进程会在 API Server 上注册节点自身信息，定期…

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分钟。