31. K8s 核心组件讲解——kubelet
本章讲解知识点
- kubelet 概述
- 节点管理
- Pod管理
- 容器健康检查
<br>
1. kubelet 概述
在 Kubernetes 集群中,每个节点(Node)上都会运行一个 kubelet 服务进程。kubelet 是 Kubernetes 中的一个重要组件,用于管理该节点上的 Pod 和容器。
kubelet 进程会从 Kubernetes 的 Master 节点上接收指令,执行相应的任务,如创建、启动、停止、销毁 Pod 和容器等。同时,kubelet 会定期向 Master 节点汇报该节点上的资源使用情况和容器状态等信息,以供集群管理者进行资源调度和容器运维等工作。
为了更好地监控节点和容器的资源使用情况,kubelet 还集成了 cAdvisor 组件,用于收集和展示节点和容器的 CPU、内存、磁盘等资源的使用情况。通过 cAdvisor,集群管理者可以及时发现节点和容器的异常情况,保障集群的稳定性和可靠性。
kubelet 的主要职责包括:
- 启动和停止 Pod 中的容器
- 监视 Pod 的状态并报告给控制平面
- 与控制平面的各个组件进行通信,例如 kube-apiserver、kube-scheduler 和 kube-controller-manager
- 管理 Pod 的生命周期,包括在 Pod 失败时重新启动它们
- 对节点资源的使用情况进行监视,确保 Pod 不会超过节点的容量限制
在启动时,Kubelet 会从 API 服务器中获取其管理的节点的 Pod 列表,并尝试在节点上启动这些 Pod 中的容器。一旦 Pod 被启动,kubelet 会不断监视它们的状态,并报告给控制平面。
<br>
2. 节点管理
节点通过设置 kubelet 的启动参数 “--register-node
”,来决定是否自动主动地向 API Server 注册自己,默认为 true。
在自注册时,kubelet 启动时还包含以下参数:
--api-servers
: API Server 的位置--kubeconfig
:kubeconfig 文件,用于访问 API Server 的配置文件--cloud-provider
:云服务商地址,仅用于公有云环境
当前每个 kubelet 被授予创建和修改任务节点的权限,未来将会限制这一权限,仅允许它修改和创建其所在节点的权限。在集群运行过程中,如果遇到资源不足的情况,则用户很容易通过添加机器及利用 kubelet 的自注册模式来实现扩容。如果系统管理员希望手动创建节点信息,则可以通过设置 --register-node=false
即可。
每个 kubelet 进程会在 API Server 上注册节点自身信息,定期向 Master 节点汇报节点资源的使用情况,API Server 在收到这些信息后,会将其写入 etcd 中。通过 --node-status-update-frequency
参数,可以配置 kubelet 向 API Server 报告节点状态的时间频率,默认为间隔 10s。
<br>
3. Pod 管理
kubelet 通过以下几种方式获取自身 Node 上所需要运行的 Pod 清单。
- 静态 Pod 配置文件:kubelet 启动参数 "--config" 指定的配置文件目录下的文件,通过
--file-check-frequency
设置检查该文件目录的时间间隔,默认为 20s。 - HTTP 端点(URL):通过 "--manifest-url" 参数设置,通过
--http-check-frequency
设置检查时间间隔,默认为 20s。 - API Server:kubelet 通过 API Server 监听 etcd 目录,同步 Pod 列表。
所有以非 API Server 方式创建的 Pod 都称为 Static Pod。 kubelet 负责监控特定目录中的 YAML 或 JSON 格式的 Static Pod 配置文件,并将它们转换成相应的 Pod 对象。一旦 kubelet 接收到 Static Pod 配置文件,它将在本地 Node 节点上创建和管理该 Pod,并将其状态汇报给 API Server。 API Server 会在 etcd 中记录该 Pod 的信息,然后为该 Static Pod 创建一个 Mirror Pod 和其相匹配。Mirror Pod 的状态将真实反映 Static Pod 的状态。当 Static Pod 被删除时,与之相对应的 Mirror Pod 也会被删除,确保集群中的所有 Pod 的状态与 API Server 中的记录保持同步。
在本文只讨论通过 API Server 获得 Pod 清单的方式。kubelet 通过 API Server Client 使用 Watch 加 List 的方式监听 etcd 中 /registry/nodes/${当前节点名称}
和 /registry/pods
的目录,将获取的信息同步到本地缓存中。
kubelet 通过与 etcd 的通信,监听 Pod 清单的变化。当有新的 Pod 绑定到本节点时,kubelet 根据清单要求创建该 Pod。同时,kubelet 也会监控本地 Pod 是否被修改,并对其做出相应的修改操作。例如,如果需要删除某个 Pod 中的容器,kubelet 会通过 Docker Client 删除该容器。如果本节点上的 Pod 被删除,则 kubelet 也会相应地删除该 Pod,并通过 Docker Client 删除其容器。这样,kubelet 可以确保 Pod 的状态与清单保持一致,并随时做出相应的调整以保证 Pod 的可靠运行。
kubelet 读取监听到的信息,如果是创建和修改 Pod 任务,则做如下处理:
- 为该 Pod 创建一个数据目录。
- 从 API Server 读取该 Pod 清单。
- 为该 Pod 挂载外部卷(External Volume)
- 下载 Pod 用到的 Secret。
- 检查已运行在节点中的 Pod,如果该 Pod 没有容器或 Pause 容器没有启动,则先停止 Pod 里所有容器的进程。如果在 Pod 中有需要删除的容器,则删除这些容器。
- 用 "kubernetes/pause" 镜像为每个 Pod 创建一个容器。该 Pause 容器用于接管 Pod 中所有其它容器的网络。
- 为 Pod 中的每个容器做如下处理:为容器计算一个 hash 值,然后用容器的名字去查询对应 Docker 容器的 hash 值。这里的 hash 值可以理解为是依据容器的定义文件所生成的。对比两个 hash 值,发现有不同则会停止 Docker 中容器的进程,并停止与之关联的 Pause 容器的进程。若二者相同,则不做任何处理。如果容器被终止了,且没有指定 restartPolicy 重启策略,则不做任何处理。调用 Docker Client 下载容器镜像,调用 Docker Client 运行容器。
<br>
4. 容器健康检查
Pod 的健康状态由两类探针来检查:LivenessProbe 和 ReadinessProbe。在 Pod 章节中我们进行了详细的介绍,这里再简要回顾一下。
LivenessProbe:用于判断容器是否存活(running 状态)。如果 LivenessProbe 探针探测到容器非健康,则 kubelet 将杀掉该容器,并根据容器的重启策略做相应处理。如果容器不包含 LivenessProbe 探针,则 kubelet 认为该探针的返回值永远为“success”。kubelet 定期执行 LivenessProbe 探针来判断容器的健康状态。
LivenessProbe 参数:initialDelaySeconds:启动容器后首次进行健康检查的等待时间,单位为秒。timeoutSeconds:健康检查发送请求后等待响应的时间
剩余60%内容,订阅专栏后可继续查看/也可单篇购买
本专刊适合于立志转行云计算的小白,有一定的编程、操作系统、计算机网络、数据结构、算法基础。 本专刊同时也适合于面向云计算(Docker + Kubernetes)求职的从业者。 本专刊囊括了云计算、VMWare、Docker、Kubernetes、Containerd等一系列知识点的讲解,并且最后总