网站开发工程师薪酬待遇,淮北电子商务网站建设,wordpress做网页,网站推广无锡Kubelet运行机制
Kubelet是Kubernetes中的一个重要组件#xff0c;在每个 Node 节点上都会启动 kubelet 服务。 该服务主要用于处理 Master 节点下发到本节点的任务#xff0c;管理 Pod及Pod 中的容器。每个kubelet 进程会在 API Server 上注册节点自身信息#xff0c;定期…Kubelet运行机制
Kubelet是Kubernetes中的一个重要组件在每个 Node 节点上都会启动 kubelet 服务。 该服务主要用于处理 Master 节点下发到本节点的任务管理 Pod及Pod 中的容器。每个kubelet 进程会在 API Server 上注册节点自身信息定期向 Master 节点汇报节点资源的使用情况 并通过cAdvisor 监控容器和节点资源。在本文中我们将分析Kubelet的运行机制。
Kubelet的工作流程
每个节点上的kubelet启动后它的工作流程可以分为以下几个步骤 获取Pod列表Kubeletwatch机制监视会从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参数指定默认值是10sKubernetes Controller Manager定期的检查kubelet状态该参数由–-node-monitor-period参数指定默认值5sKubernetes 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-frequency10skubelet--node-monitor-period5scontroller manager--node-monitor-grace-period40scontroller manager
快速更新和快速响应
参数值组件--node-status-update-frequency4skubelet--node-monitor-period2scontroller manager--node-monitor-grace-period20scontroller 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-frequency20skubelet--node-monitor-period5scontroller manager--node-monitor-grace-period2mcontroller 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-frequency1mkubelet--node-monitor-period5scontroller manager--node-monitor-grace-period5mcontroller 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的知识分享请前往博客主页。编写过程中难免出现差错敬请指出
