K8S篇之谈谈kubelet的上报机制

机制"/>

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秒甚至更长才能被呈现

实际应用
默认的配置（参数所属组件）

快速更新和快速响应

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网络、容器运行时和资源限制