机制"/>
K8S篇之谈谈kubelet的上报机制
浅析一下Kubelet的上报机制
1 kubelet上报节点状态
在K8S集群中,由运行在每个节点的Kubelet定期上报心跳到ApiServer,由此来判断Node是否存在,若Node超过一定时间没有上报心跳,则该节点的状态就会被设置为NotReady,同时运行在该节点的容器状态也会被设置为Unknown状态。
1.1 Kubelet上报哪些状态
在K8S中,一个Node的状态包含一下信息:
Addresses
Condition
Capacity
Info
Address主要包含以下几个字段:
HostName:即主机名,可以通过kubelet的–hostname-override参数进行覆盖。
ExternalIP:通常是可以外部路由的Node IP(从集群外可访问)。
InternalIP:通常是仅可以在集群内部路由的Node IP地址。
2 Kubelet运行机制
Kubelet是Kubernetes中的一个重要组件,在每个Node节点上都会启动 kubelet服务。 该服务要用于处理 Master节点下发到本节点的任务,管理Pod及Pod中的容器。每个kubelet 进程会在Server上注册节点自身信息,定期向 Master 节点汇报节点资源的使用情况,并通过cAdivisor监视容器和节点资源。
3 Kubelet的 工作流程
每个节点上的kubelet启动后,它的工作流程可以分为以下几个步骤:
1、获取Pod列表:Kubelet(watch机制监视)会从Master节点获取节点上的Pod列表。Master节点会将Pod列表发送给Kubelet,并告诉Kubelet哪些Pod需要在该节点上运行。
2、创建Pod:如果Kubelet发现节点上没有Pod的容器在运行,它会根据Pod的定义创建容器。Kubelet会根据Pod的定义创建一个Pod Sandbox,然后在Pod Sandbox中创建容器。
3、监控容器状态:Kubelet会定期检查容器的状态,并将状态报告给Master节点。如果容器出现故障,Kubelet会尝试重启容器。如果重启失败,Kubelet会将容器标记为失败,并将状态报告给Master节点。
4、清理容器:如果Kubelet发现某个容器已经被删除,它会将该容器从节点上清理掉。
4 Kubelet的相关配置
Kubelet的配置文件可以放在多个配置文件中,具体看部署方式。可能是/etc/kubernetes/kubelet.conf、/usr/lib/systemd/system/kubelet.service、/var/lib/kubelet/config.yaml。
很多默认配置都可以不用修改,主要的配置包括以下几个方面:
1、节点名称:Kubelet需要知道节点的名称,以便向Master节点注册自己。
2、Pod网络:Kubelet需要知道Pod网络的配置,以便能够正确地创建Pod Sandbox和容器。
3、容器运行时:Kubelet需要知道容器运行时的一些参数,以便能够满足业务需求。
4、资源限制:Kubelet需要知道节点的资源限制,以便能够正确地调度Pod,与优化相关。
5 Kubelet状态异常时的影响
当一个Node处于非Ready状态超过Pod-eviction-timeout的值(默认为5分钟,在kube-controller-manager中定义),kube-controller-manager不会force delete pod,运行在该节点的Pod会一直处于Terminating或者Unknow状态,直到Node从集群中删除,或者kubelet状态变为Ready。
在Node NotReady期间,不同的控制器处理方式不同,依次如下:
Daemonset:Pod的状态变为Nodelost
Deployment:先变为Nodelost,然后变成Unknown,最后会在其他正常的节点重新创建。
StaticPod:先变为Nodelost,然后一直处于Unknown(staticPod即为/etc/kubernetes/manifest下的yaml文件)
Statefulset:先变为Nodelost,然后一直处于Unknown
当Kubelet再次变为Ready状态时,以上控制器的处理方式如下:
Daemonset:Pod不会重新创建,旧Pod的状态直接变为Running。
Deployment:则会将运行在该节点的旧Pod删除。
Statefulset:会将Pod重新进行创建。
Static Pod:则会被删除。
6 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秒甚至更长才能被呈现
实际应用
默认的配置(参数所属组件)
参数 | 值 | 组件 |
---|---|---|
–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 |
7 Kubelet状态上报的实现
Kubelet上报状态有两种方式,分别是NodeStatus和NodeLease。具体实现方式如下:
NodeStatus:由Kubelet定期向Apiserver上报心跳,超时没有上报则会将Node标记为UnReady,Node上的Pod也会标记为NodeLost或者Unknow。默认更新时间5分钟。
NodeLease上报:在命名空间kube-node-lease会为每个节点都关联一个Lease对象,由节点定期更新Lease对象。默认每隔更新周期为10S。
状态的信息依靠NodeLease来实现上报,减少apiserver的压力,并且其上传的信息相对于Node的信息少很多,比较轻量。
8 总结
Kubelet 是Kubernetes中的一个重要组件,它负责管理节点上的容器和Pod,并与Master节点进行通信。Kubelet的工作流程包括获取Pod列表、创建Pod、监控容器状态和清理容器。Kubelet的配置包括节点名称、Pod网络、容器运行时和资源限制
更多推荐
K8S篇之谈谈kubelet的上报机制
发布评论