kubelet用于处理master节点下发到本节点的任务，管理Pod以及Pod中的容器。每个kubelet进程会在API Server上注册节点信息，定期向master节点汇报节点资源的使用情况，并通过cAdvisor监控容器和节点的资源。

kubelet 这个组件本身，也是 Kubernetes 里面第二个不可被替代的组件（第一个不可被替代的组件当然是 kube-apiserver）。也就是说，无论如何，我都不太建议你对 kubelet 的代码进行大量的改动。保持 kubelet 跟上游基本一致的重要性，就跟保持 kube-apiserver 跟上游一致是一个道理。

kubelet 本身，也是按照“控制器”模式来工作的。

kubelet 的工作核心，就是一个控制循环，即：SyncLoop（图中的大圆圈）。而驱动这个控制循环运行的事件，包括四种：

跟其他控制器类似，kubelet 启动的时候，要做的第一件事情，就是设置 Listers，也就是注册它所关心的各种事件的 Informer。这些 Informer，就是 SyncLoop 需要处理的数据的来源。此外，kubelet 还负责维护着很多很多其他的子控制循环（也就是图中的小圆圈）。这些控制循环的名字，一般被称作某某 Manager，比如 Volume Manager、Image Manager、Node Status Manager 等等。不难想到，这些控制循环的责任，就是通过控制器模式，完成 kubelet 的某项具体职责。比如 Node Status Manager，就负责响应 Node 的状态变化，然后将 Node 的状态收集起来，并通过 Heartbeat 的方式上报给 APIServer。再比如 CPU Manager，就负责维护该 Node 的 CPU 核的信息，以便在 Pod 通过 cpuset 的方式请求 CPU 核的时候，能够正确地管理 CPU 核的使用量和可用量。

SyncLoop，又是如何根据 Pod 对象的变化，来进行容器操作的呢？

kubelet 也是通过 Watch 机制，监听了与自己相关的 Pod 对象的变化。当然，这个 Watch 的过滤条件是该 Pod 的 nodeName 字段与自己相同。kubelet 会把这些 Pod 的信息缓存在自己的内存里。而当一个 Pod 完成调度、与一个 Node 绑定起来之后， 这个 Pod 的变化就会触发 kubelet 在控制循环里注册的 Handler，也就是上图中的 HandlePods 部分。此时，通过检查该 Pod 在 kubelet 内存里的状态，kubelet 就能够判断出这是一个新调度过来的 Pod，从而触发 Handler 里 ADD 事件对应的处理逻辑。在具体的处理过程当中，kubelet 会启动一个名叫 Pod Update Worker 的、单独的 Goroutine 来完成对 Pod 的处理工作。

比如，如果是 ADD 事件的话，kubelet 就会为这个新的 Pod 生成对应的 Pod Status，检查 Pod 所声明使用的 Volume 是不是已经准备好。然后，调用下层的容器运行时（比如 Docker），开始创建这个 Pod 所定义的容器。而如果是 UPDATE 事件的话，kubelet 就会根据 Pod 对象具体的变更情况，调用下层容器运行时进行容器的重建工作。

kubelet 调用下层容器运行时的执行过程，并不会直接调用 Docker 的 API，而是通过一组叫作 CRI（Container Runtime Interface，容器运行时接口）的 gRPC 接口来间接执行的。Kubernetes 项目之所以要在 kubelet 中引入这样一层单独的抽象，当然是为了对 Kubernetes 屏蔽下层容器运行时的差异。实际上，对于 1.6 版本之前的 Kubernetes 来说，它就是直接调用 Docker 的 API 来创建和管理容器的。

把 kubelet 对容器的操作，统一地抽象成一个接口CRI。这样，kubelet 就只需要跟这个接口打交道了。而作为具体的容器项目，比如 Docker、 rkt、runV，它们就只需要自己提供一个该接口的实现，然后对 kubelet 暴露出 gRPC 服务即可。

目前kubelet还集成这docker的负责响应的组件dockershim，而其他容器化CRI shim就需要自己实现部署了，所以可见dockershim被移除是必然的趋势，k8s只会提供一套统一的接口cri。

节点通过设置kubelet的启动参数“–register-node”来决定是否向API Server注册自己。如果该参数为true，那么kubelet将试着通过API Server注册自己。在自注册时，kubelet启动时还包括以下参数：

如果没有选择自注册模式，用户需要手动去配置node的资源信息，同时告知ndoe上的kubelet API Server的位置。Kubelet在启动时通过API Server注册节点信息，并定时向API Server发送节点新消息，API Server在接受到这些消息之后，将这些信息写入etcd中。通过kubelet的启动参数“–node-status-update-frequency”设置kubelet每个多长时间向API Server报告节点状态，默认为10s

kubelet通过以下几种方式获取自身node上所要运行的pod清单：

注意：这里static pod，不是被API Server创建的，而是被kubelet创建，之前文章中提到了静态的pod是在kubelet的配置文件中编写，并且总在kubelet所在node上运行。    

Kubelet监听etcd，所有针对pod的操作将会被kubelet监听到。如果是新的绑定到本节点的pod，则按照pod清单的要求创建pod，如果是删除pod，则kubelet通过docker client去删除pod中的容器，并删除该pod。

具体的针对创建和修改pod任务，流程为：

Pod通过两类探针来检查容器的健康状态。一个是livenessProbe探针，用于判断容器是否健康，告诉kubelet一个容器什么时候处于不健康状态，如果livenessProbe探针探测到容器不健康，则kubelet将删除该容器，并根据容器的重启策略做相应的处理；如果一个容器不包含livenessProbe探针，那么kubelet认为livenessProbe探针的返回值永远为“success”。

另一个探针为ReadinessProbe，用于判断容器是否启动完成，且准备接受请求。如果ReadinessProbe探针检测到失败，则pod的状态将被修改，endpoint controller将从service的endpoints中删除包含该容器所在pod的IP地址的endpoint条目。

cadcisor是为容器监控而生的监控工具，目前集成在kubelet中，以4194端口进行暴露。

目前是基于master来进行源码处理，目前release版本是1.20，最常用的是1.18

kubelet使用的是cobra第三方包来做启动包，同时做了命令行参数的处理，首先是NewKubeletCommand

可见kubelet的启动参数可以是命令行参数kubeletFlags，也可以是配置文件kubeletConfig，启动就是使用的cobra中的run方法

这个方法虽然比较长，但是除了最终的Run方法，其余的步骤还是为kubelet的启动构建初始化的参数，无非就是换一个名称，换一个不同的结构体，并配置相依赖的参数，主要包括以下步骤： - 解析参数，对参数的合法性进行判断； - 根据kubeletConfig解析一些特殊的特性所需要配置的参数； - 配置kubeletServer，包括KubeletFlags和KubeletConfiguration两个参数； - 构造kubeletDeps结构体； - 启动最终的Run方法。

继续调用run方法

initForOS通过对操作系统的判断，如果是windows系统需要做一些预先的特殊处理；然后继续执行run方法

RunKubelet方法最重要的方法有两个：CreateAndInitKubelet和startKubelet，可以理解为CreateAndInitKubelet为参数的配置，startKubelet为最终的启动，其实最后说来说去还是把参数封装一遍，重新构造新的结构体来运行。

CreateAndInitKubelet方法通过调用NewMainKubelet返回Kubelet结构体。在NewMainKubelet中，主要的配置有：

最终通过参数填充Kubelet结构体，完成kubelet结构体参数的最终配置。

然后就是启动startKubelet，在启动之前，判断是以后台daemon进程一直运行还是只启动一次，即runOnce，基本上都是以后台daemon启动的方式，所以大部分调用的是startKubelet方法。

可见开来goroutine，调用run方法，上面构建的是kubelet结构体，所以这边调用的也是kubelet的run方法。