kubelet主要功能（kubelet工作原理）



        Kubelet组件运行在Node节点上，维持运行中的Pods以及提供kuberntes运行时环境，其主要功能就是定时从某个地方获取节点上 pod/container 的期望状态（运行什么容器、运行的副本数量、网络或者存储如何配置等等），并调用对应的容器平台接口达到这个状态。

        比较经典的一张图：

        每个Node节点上都运行一个 Kubelet 服务进程，默认监听 10250 端口，接收并执行 Master 发来的指令，管理 Pod 及 Pod 中的容器。每个 Kubelet 进程会在 API Server 上注册所在Node节点的信息，定期向 Master 节点汇报该节点的资源使用情况，并通过 cAdvisor 监控节点和容器的资源。

        节点管理主要是节点自注册和节点状态更新：

1.2.1 获取 Pod 清单

        Kubelet 以 PodSpec 的方式工作。PodSpec 是描述一个 Pod 的 YAML 或 JSON 对象。 kubelet 采用一组通过各种机制提供的 PodSpecs（主要通过 apiserver），并确保这些 PodSpecs 中描述的 Pod 正常健康运行。

        向 Kubelet 提供节点上需要运行的 Pod 清单的方法：

1.2.2 通过 API Server 获取 Pod 清单及创建 Pod 的过程

        Kubelet 通过 API Server Client(Kubelet 启动时创建)使用 Watch 加 List 的方式监听 "/registry/nodes/$ 当前节点名" 和 “/registry/pods” 目录，将获取的信息同步到本地缓存中。

        Kubelet 监听 etcd，所有针对 Pod 的操作都将会被 Kubelet 监听到。如果发现有新的绑定到本节点的 Pod，则按照 Pod 清单的要求创建该 Pod。

        如果发现本地的 Pod 被修改，则 Kubelet 会做出相应的修改，比如删除 Pod 中某个容器时，则通过 Docker Client 删除该容器。 如果发现删除本节点的 Pod，则删除相应的 Pod，并通过 Docker Client 删除 Pod 中的容器。

        Kubelet 读取监听到的信息，如果是创建和修改 Pod 任务，则执行如下处理：

1.2.3 Static Pod

        所有以非 API Server 方式创建的 Pod 都叫 Static Pod。Kubelet 将 Static Pod 的状态汇报给 API Server，API Server 为该 Static Pod 创建一个 Mirror Pod 和其相匹配。Mirror Pod 的状态将真实反映 Static Pod 的状态。当 Static Pod 被删除时，与之相对应的 Mirror Pod 也会被删除。

1.3 容器健康检查

Pod 通过两类探针检查容器的健康状态:

        Kubelet 定期调用容器中的 LivenessProbe 探针来诊断容器的健康状况。LivenessProbe 包含如下三种实现方式：

        LivenessProbe 和 ReadinessProbe 探针包含在 Pod 定义的 spec.containers.{某个容器} 中。

        Kubernetes 集群中，应用程序的执行情况可以在不同的级别上监测到，这些级别包括：容器、Pod、Service 和整个集群。Heapster 项目为 Kubernetes 提供了一个基本的监控平台，它是集群级别的监控和事件数据集成器 (Aggregator)。Heapster 以 Pod 的方式运行在集群中，Heapster 通过 Kubelet 发现所有运行在集群中的节点，并查看来自这些节点的资源使用情况。Kubelet 通过 cAdvisor 获取其所在节点及容器的数据。Heapster 通过带着关联标签的 Pod 分组这些信息，这些数据将被推到一个可配置的后端，用于存储和可视化展示。支持的后端包括 InfluxDB(使用 Grafana 实现可视化) 和 Google Cloud Monitoring。

        cAdvisor 是一个开源的分析容器资源使用率和性能特性的代理工具，集成到 Kubelet中，当Kubelet启动时会同时启动cAdvisor，且一个cAdvisor只监控一个Node节点的信息。cAdvisor 自动查找所有在其所在节点上的容器，自动采集 CPU、内存、文件系统和网络使用的统计信息。cAdvisor 通过它所在节点机的 Root 容器，采集并分析该节点机的全面使用情况。

        cAdvisor 通过其所在节点机的 4194 端口暴露一个简单的 UI。

        Kubelet 会监控资源的使用情况，并使用驱逐机制防止计算和存储资源耗尽。在驱逐时，Kubelet 将 Pod 的所有容器停止，并将 PodPhase 设置为 Failed。

        Kubelet 定期（housekeeping-interval）检查系统的资源是否达到了预先配置的驱逐阈值，包括：

        这些驱逐阈值可以使用百分比，也可以使用绝对值，如：

        这些驱逐信号可以分为软驱逐和硬驱逐：

        驱逐动作包括回收节点资源和驱逐用户 Pod 两种：

        除了驱逐之外，Kubelet 还支持一系列的容器和镜像垃圾回收选项，它们未来将会被驱逐替代：

        容器运行时（Container Runtime）是 Kubernetes 最重要的组件之一，负责真正管理镜像和容器的生命周期。Kubelet 通过  与容器运行时交互，以管理镜像和容器。

        Container Runtime Interface（CRI）是 Kubernetes v1.5 引入的容器运行时接口，它将 Kubelet 与容器运行时解耦，将原来完全面向 Pod 级别的内部接口拆分成面向 Sandbox 和 Container 的 gRPC 接口，并将镜像管理和容器管理分离到不同的服务。

        CRI 最早从从 1.4 版就开始设计讨论和开发，在 v1.5 中发布第一个测试版。在 v1.6 时已经有了很多外部容器运行时，如 frakti 和 cri-o 等。v1.7 中又新增了 cri-containerd 支持用 Containerd 来管理容器。

        CRI 基于 gRPC 定义了 RuntimeService 和 ImageService 等两个 gRPC 服务，分别用于容器运行时和镜像的管理。其定义在

        Kubelet 作为 CRI 的客户端，而容器运行时则需要实现 CRI 的服务端（即 gRPC server，通常称为 CRI shim）。容器运行时在启动 gRPC server 时需要监听在本地的 Unix Socket （Windows 使用 tcp 格式）。

        目前基于 CRI 容器引擎已经比较丰富了，包括：

        如下 kubelet 内部组件结构图所示，Kubelet 由许多内部组件构成：

2.1.1 PLEG

        PLEG全称为PodLifecycleEvent，PLEG会一直调用container runtime获取本节点的pods，之后比较本模块中之前缓存的pods信息，比较最新的pods中的容器的状态是否发生改变，当状态发生切换的时候，生成一个eventRecord事件，输出到eventChannel中。syncPod模块会接收到eventChannel中的event事件，来触发pod同步处理过程，调用contaiener runtime来重建pod，保证pod工作正常。

2.1.2 cAdvisor

        cAdvisor集成在kubelet中，起到收集本Node的节点和启动的容器的监控的信息，启动一个Http Server服务器，对外接收rest api请求。cAvisor模块对外提供了interface接口，可以通过interface接口获取到node节点信息，本地文件系统的状态等信息，该接口被imageManager，OOMWatcher，containerManager等所使用。

        cAdvisor相关的内容详细可参考github.com/google/cadvisor

2.1.3 GPUManager

        对于Node上可使用的GPU的管理，当前版本需要在kubelet启动参数中指定feature-gates中添加Accelerators=true，并且需要才用runtime=Docker的情况下才能支持使用GPU,并且当前只支持NvidiaGPU,GPUManager主要需要实现interface定义的Start()/Capacity()/AllocateGPU()三个函数

2.1.4 OOMWatcher

        系统OOM的监听器，将会与cadvisor模块之间建立SystemOOM,通过Watch方式从cadvisor那里收到的OOM信号，并发生相关事件。

2.1.5 ProbeManager

        探针管理，依赖于statusManager,livenessManager,containerRefManager，实现Pod的健康检查的功能．当前支持两种类型的探针：LivenessProbe和ReadinessProbe：

探针有三种实现方式：

2.1.6 StatusManager

        该模块负责pod里面的容器的状态，接受从其它模块发送过来的pod状态改变的事件，进行处理，并更新到kube-apiserver中。

2.1.7 Container/RefManager

        容器引用的管理，相对简单的Manager，通过定义map来实现了containerID与v1.ObjectReferece容器引用的映射。

2.1.8 EvictionManager

        evictManager当node的节点资源不足的时候，达到了配置的evict的策略，将会从node上驱赶pod，来保证node节点的稳定性。可以通过kubelet启动参数来决定evict的策略。另外当node的内存以及disk资源达到evict的策略的时候会生成对应的node状态记录。

2.1.9 ImageGC

        imageGC负责Node节点的镜像回收，当本地的存放镜像的本地磁盘空间达到某阈值的时候，会触发镜像的回收，删除掉不被pod所使用的镜像。回收镜像的阈值可以通过kubelet的启动参数来设置。

2.1.10 ContainerGC

        containerGC负责NOde节点上的dead状态的container，自动清理掉node上残留的容器。具体的GC操作由runtime来实现。

2.1.11 ImageManager

        调用kubecontainer.ImageService提供的PullImage/GetImageRef/ListImages/RemoveImage/ImageStates的方法来保证pod运行所需要的镜像，主要是为了kubelet支持cni。

2.1.12 VolumeManager

        负责node节点上pod所使用的volume的管理，主要涉及如下功能：

        Volume状态的同步，模块中会启动gorountine去获取当前node上volume的状态信息以及期望的volume的状态信息，会去周期性的sync　volume的状态，另外volume与pod的生命周期关联，pod的创建删除过程中volume的attach/detach流程。更重要的是kubernetes支持多种存储的插件，kubelet如何调用这些存储插件提供的interface。涉及的内容较多，更加详细的信息可以看kubernetes中volume相关的代码和文档。

2.1.13 containerManager

        负责node节点上运行的容器的cgroup配置信息，kubelet启动参数如果指定–cgroupPerQos的时候，kubelet会启动gorountie来周期性的更新pod的cgroup信息，维持其正确．实现了pod的Guaranteed/BestEffort/Burstable三种级别的Qos,通过配置kubelet可以有效的保证了当有大量pod在node上运行时，保证node节点的稳定性．该模块中涉及的struct主要包括

2.1.14 runtimeManager

        containerRuntime负责kubelet与不同的runtime实现进行对接，实现对于底层container的操作，初始化之后得到的runtime实例将会被之前描述的组件所使用。

        当前可以通过kubelet的启动参数–container-runtime来定义是使用docker还是rkt.runtime需要实现的接口定义在src/k8s.io/kubernetes/pkg/kubelet/apis/cri/services.go文件里面。

2.1.15 podManager

        podManager提供了接口来存储和访问pod的信息，维持static pod和mirror　pods的关系，提供的接口如下所示：

        跟其他Manager之间的关系，podManager会被statusManager/volumeManager/runtimeManager所调用，并且podManager的接口处理流程里面同样会调用secretManager以及configMapManager。

        kubelet 本身，也是按照“控制器”模式来工作的，工作原理如下所示：

        kubelet 的工作核心，就是一个控制循环SyncLoop，驱动这个控制循环运行的事件，包括四种：

        SyncLoop 需要处理的数据的来源：是kubelet注册到k8s里面的informer获取的。对于kubelet 来说，它启动的时候，要做的第一件事情，就是设置 Listers，也就是注册它所关心的各种事件的 Informer。

        kubelet 还负责维护着很多其他的子控制循环，比如 Volume Manager、Image Manager、Node Status Manager 等等，这些控制循环的责任，就是通过控制器模式，完成 kubelet 的某项具体职责。

        例如：Node Status Manager，就负责响应 Node 的状态变化，然后将 Node 的状态收集起来，并通过 Heartbeat 的方式上报给 APIServer。CPU Manager，就负责维护该 Node 的 CPU 核的信息，以便在 Pod 通过 cpuset 的方式请求 CPU 核的时候，能够正确地管理 CPU 核的使用量和可用量。

        kubelet 通过 Watch 机制，监听了与自己相关的 Pod 对象的变化：

        例如：ADD 事件，kubelet 就会为这个新的 Pod 生成对应的 Pod Status，检查 Pod 所声明使用的 Volume 是不是已经准备好。然后，调用下层的容器运行时，开始创建这个 Pod 所定义的容器。

        kubelet 调用下层容器运行时的执行过程，并不会直接调用 Docker 的 API，而是通过一组叫作 CRI（Container Runtime Interface，容器运行时接口）的 gRPC 接口来间接执行的。kubelet 实际上就会调用一个叫作 GenericRuntime 的通用组件来发起创建 Pod 的 CRI 请求。Kubernetes 通过虚拟出一个CRI shim(例如：dockershim)让容器项目能够自主开发，进而为k8s提供一个统一的容器抽象层，使得下层容器运行时可以自由地对接进入 Kubernetes 当中。

        CRI是Container Runtime Interface（容器运行时接口）的简写，CRI解耦了kubelet与容器运行时，让kubelet无需重新编译就可以支持多种容器运行时，kubelet将通过CRI接口来跟第三方容器运行时进行通信，来操作容器与镜像。实现了 CRI 接口的容器运行时通常称为 CRI shim， 这是一个 gRPC Server，监听在本地的 unix socket 上；而 kubelet 作为 gRPC 的客户端来调用 CRI 接口，来进行Pod 和容器、镜像的生命周期管理。另外，容器运行时需要自己负责管理容器的网络，推荐使用 CNI。

        CRI shim 的能力：将 Kubernetes 发出的 CRI 请求，转换成对 containerd 的调用，然后创建出 runC 容器，runC 项目，负责执行设置容器 Namespace、Cgroups 和 chroot 等基础操作的组件的操作。

        对于CRI shim来说主要针对的是下面runtimeService和imageService两类操作，Pod运行时会通过调用这些接口来把容器运行起来，如下所示：

        例如：kubectl run 创建了一个名叫 foo 的Pod（备注：Pod里面包括了 A、B 两个容器）。这个 Pod 的信息最后来到 kubelet，kubelet 就会按照图中所示的顺序来调用 CRI 接口，这些接口里面会封装好对于cpu、mem、网络等资源的操作，而这部分操作无非就是调用操作系统内核的对应接口来完成。

K8S之kubelet介绍_灰子学技术的博客-CSDN博客

kubelet 介绍 - 无敌小格鲁 - 博客园

Kubernetes 核心组件 kubelet_富士康质检员张全蛋的博客-CSDN博客_kubelet

版权声明：

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！

转载请注明出处，原文链接：https://www.xkablog.com/jszy-gxgz/52226.html