kubernetes_kubelet

Kubelet

kubelet 是 Kubernetes 节点（Node）上的核心组件，负责管理节点上的 Pod 和容器生命周期，是 Kubernetes 控制平面（Control Plane）与节点层之间的桥梁。

整体框架

1. Kubelet API

Kubelet 提供了一系列 HTTP API 服务，用于与外部或 Kubernetes 控制平面通信。关键的端口与服务如下：

:10250 API：接受 Master 节点发来的指令，管理 Pod 和 Pod 中的容器，每个 Kubelet 在 API Server 上注册自身节点信息，定期向 Master 发送节点使用情况，并通过 cAdvisor 监控节点和容器的资源。
:10255 只读 API - 提供一个无需认证的只读接口，通常用于外部系统（如监控系统）获取 Pod 和节点的状态信息。（此端口已逐渐不推荐使用）
:10248 /healthz - 用于 Kubelet 自身的健康检查。主要提供 /healthz 接口，以供其他组件监控 Kubelet 运行状况。

这些接口是外界与 Kubelet 交互的重要入口。

2. 核心组件

(1) syncLoop

syncLoop 是 Kubelet 的核心主循环，负责持续同步节点的状态和调度的 Pod 期望状态。

通过 Kubernetes API Server Watch 机制获取调度到该节点的 Pod 信息（期望状态）。
对比节点上实际运行的 Pod 状态（实际状态）。
调用其他模块（如 PodWorker）完成实际状态与期望状态的对齐。

(2) PodWorker

PodWorker 是每个 Pod 的具体操作执行模块。它是一个并发协程池，用于处理 Pod 的创建、更新、删除等任务。与 syncLoop 配合，PodWorker 实现了节点状态与调度期望状态的最终一致性。

(3) ProbeManager

ProbeManager 负责 Pod 的健康检查。

Liveness Probe：判断容器是否健康，不健康时触发重启。
Readiness Probe：判断容器是否准备就绪，用于流量负载分发。
Startup Probe：当容器启动较慢时，避免被误判为不健康。

ProbeManager 会根据 Pod 的探针配置，周期性调用相关检查逻辑，确保应用运行状态。

(4) OOMWatcher

OOMWatcher 监听容器是否因内存不足（OOM）被系统杀死，并触发回调通知其他模块进行后续处理。

(5) GPUManager

GPUManager 专为需要显卡支持的容器（如深度学习模型或 GPU 加速的应用）服务，确保请求 GPU 资源的 Pod 能够成功调度并正常初始化设备。

(6) cAdvisor

cAdvisor 是 Google 开源的资源监控工具，被内置为 Kubelet 的一部分，负责收集节点和容器的资源消耗（CPU、内存、网络、磁盘 IO 等）。这些数据被用于：

提供给 Kubernetes 控制平面的资源调度。
在节点上触发资源回收或补救机制。

(7) DiskSpaceManager & Image GC

DiskSpaceManager 负责监控节点磁盘空间，并协作执行相应的垃圾回收。
Image GC 用于定期回收未使用的镜像资源，避免磁盘因持久化镜像而耗尽。

(8) StatusManager

StatusManager 负责汇报节点和 Pod 的状态信息。具体工作包括：

将本地运行中 Pod 的状态（如 Ready、运行时间、网络状态）上传到 API Server。
将状态数据同步到 syncLoop，用于进一步决策。

(9) EvictionManager

EvictionManager 负责节点资源压力下的 Pod 驱逐。它监控节点整体资源状况，当内存、磁盘、inode 等资源低于预设阈值时，会主动驱逐“非关键”Pod 以释放资源。

(10) VolumeManager

VolumeManager 负责处理 Pod 的存储卷挂载和卸载，例如支持 PersistentVolume (PV) 的分配与管理。在 Pod 创建过程中，确保所需存储卷按请求挂载到容器。

(11) CertificateManager

CertificateManager 负责管理 Kubelet 所需的证书和密钥文件，用于与 API Server 安全通信的 TLS 握手。

kubelet 管理 Pod 的流程

Pod 清单的生产与获取：
- API Server：Kubelet 从 API Server 获取需要运行的 Pod 信息。
- Manifest 目录：通过启动参数 --config 指定目录（如 /etc/kubernetes/manifests/），周期性扫描文件获取 Pod 定义（默认间隔 20 秒，可配置）。
- HTTP Server：通过启动参数 --manifest-url 设置 URL 来周期性拉取 Pod 清单。
- HTTP 接口调用：通过 kubelet 自身暴露的 HTTP 服务接口，允许动态提交新的 Pod 清单。
syncLoop - 消费者流程：
- Kubelet 的核心事件循环（syncLoop）持续监听 Pod 变更事件（如新建、更新或删除）。
- Worker 处理逻辑：
  - 调用 syncPod 函数处理每个 Pod。
  - 在 syncPod 中，调用 computePodActions 比对清单中的 Pod（期望状态）和当前节点运行中的实际 Pod（实际状态）。
  - 根据比对结果，计算需要新增、修改或删除的 Pod，并通过容器运行时接口（CRI：Container Runtime Interface）执行相应的操作。
容器运行时接口 (CRI)：
- Kubelet 并不会直接操作容器，而是通过 CRI 进行抽象的容器操作。
- CRI 执行 Pod 和容器的新增、更新、删除操作，屏蔽物理容器运行时（如 Docker、containerd）之间的实现差异。

Pod 生命周期管理 (PLEG)

PLEG (Pod Lifecycle Event Generator) 是 Kubelet 的一个关键模块，用于监听和维护容器的实际状态。

功能：
- 收集当前节点上所有 Pod 的运行状态，例如容器是否已启动、运行中、退出等。
- 定期通过 relist 操作，从容器运行时（CRI）中获取实际 Pod 的状态清单。
- 将这些状态事件发送到 Kubelet，帮助它同步期望状态与实际状态。
状态报告：
- PLEG 的状态信息会周期性地上传到 Kubernetes 控制平面（API Server），并最终存储到 etcd 中。
- 如果 PLEG 中出现问题（如 relist 被阻塞或超时），Kubernetes 控制平面可能会错误地认为节点状态异常（Node Not Ready）。
性能限制：
- Kubernetes 会对每个节点上的 Pod 数量设定上限，原因包括：
  - 时间开销：PLEG 每秒 relist 一次节点上的 Pod，如果 Pod 数过多，会使 relist 操作消耗大量时间。
  - 节点状态异常：如 CRI 卡住、无法及时上报状态时，就可能导致控制平面认为节点处于 NotReady 状态。
- 这种限制保障了分布式系统的稳定性。

节点管理

Kubernetes 中的节点由 Kubelet 注册、监控并周期性汇报状态。以下是节点管理的主要流程：

Kubelet 的节点自注册：
- 通过启动参数 --register-node 决定是否自动向 API Server 注册节点。
- 若启用，Kubelet 会在启动时通过与 API Server 通信，注册节点自身的信息（如容量、配置）。
手动注册节点：
- 假如未开启节点自注册模式，用户需手动创建节点资源，并将节点的相关信息配置到 API Server。
- 同时，需要手动配置 Kubelet 的启动参数，告知其 API Server 的地址。
节点状态更新：
- Kubelet 会定期向控制平面（API Server）发送心跳、节点资源使用情况、节点运行状态等信息。
- API Server 在收到这些信息后，将其写入 etcd，供调度器和控制器使用。

Pod 启动流程

1. 用户提交 Pod 创建请求

用户通过 kubectl 命令或 Kubernetes API 客户端将 Pod 的定义（如 YAML 或 JSON 格式）发送到 API Server。

流程细节：
- 用户运行命令：kubectl apply -f pod.yaml 或直接调用 REST API。
- API Server 会对收到的 Pod 对象执行一系列验证、权限检查和默认值填充等逻辑：
  - 权限校验：通过 RBAC（Role-Based Access Control）验证用户对资源类型的权限。
  - Admission Webhook：触发一系列 Admission Controllers，用于资源约束、默认值注入或自定义逻辑的执行。
  - Schema 验证：验证 Pod 定义是否符合 Kubernetes 的 API 规范。
写入 etcd：
- 验证成功后，API Server 将 Pod 信息写入 etcd，与此同时，返回状态 201 CREATED 给用户，表示资源创建成功。
- etcd 是 Kubernetes 的分布式一致性存储组件，所有的集群状态变更最终都会存储在 etcd 中。

2. 调度器 (Scheduler) 分配节点

调度器负责决定每个 Pod 应该在哪个 Node（工作节点）运行，这是 Kubernetes 中资源调度的重要阶段。

流程细节：

Scheduler 监听未绑定的 Pod：
- 调度器通过 Watch 机制监听 API Server，寻找 spec.nodeName 字段为空的 Pod（即尚未绑定到具体节点的 Pod）。
调度决策过程:
- 调度器会根据 调度算法 对集群中的可用节点进行评估。主要包括：
  - Predicate - 过滤节点：
    - 基本过滤条件（如节点健康状态、资源容量是否足够等）会筛选出一组候选节点。
    - 网络、存储条件等插件可能也会影响过滤结果。
  - Priority - 节点评分：
    - 为每个候选节点根据调度优先级打分，例如节点剩余资源多的分数更高，或使 Pod 与本地数据亲和的节点优先。
    - 最终选择得分最高的一个节点。
绑定节点：
- 调度器决定节点后，会通过调用 API Server 的 Bind 接口，将 Pod 的 spec.nodeName 字段设置为目标节点，建立 Pod 与节点的绑定关系。
- Pod 的最新状态信息会被写入到 etcd 中，由 API Server 同步到其他组件。

3. Kubelet 开始管理 Pod

调度完成后，Pod 被分配到具体的工作节点，此时 Kubelet（运行在该节点上的组件）开始接管 Pod 的创建和管理。

Kubelet 的处理流程：

监听 API Server：
- Kubelet 通过 Watch 机制监听 API Server 上的 Pod 定义变更（绑定到本节点的 Pod）。
- Pod 的元数据（如容器镜像名、CPU/内存资源需求等）会被获取到本地。
创建 Pod 的 sandbox 容器：
- Kubelet 调用 CRI（Container Runtime Interface）接口，运行一个 Sandbox 容器（如 pause 容器）。具体流程：
  - Pause 容器作用：
    - pause 是 Pod 的第一个容器，负责承载网络、PID 和 IPC 等共享的 Linux Namespace。
    - 它是一个极为轻量级的容器（通常仅几百 KB 且几乎不占用 CPU），为 Pod 提供基础的隔离环境。
  - 网络配置：
    - Sandbox 容器启动后，CNI（Container Network Interface） Plugin 会为 Pod 配置网络（如分配 IP 和设置网络路由）。
    - 若 Pod 需要挂载存储卷，Kubelet 也会在这个阶段通过 CSI（Container Storage Interface）完成卷的挂载。
构建 Pod 的运行环境：
- Sandbox 容器运行成功后，容器运行时（如 containerd 或 Docker）会等待 Kubelet 的进一步指令来准备用户定义的应用容器。
容器生命周期管理：
- Kubelet 根据 Pod 定义中描述的容器逐一执行以下操作：
  - PullImage：拉取容器镜像（若镜像已存在，则跳过）。
  - CreateContainer：创建容器。
  - StartContainer：启动容器。
- 当所有容器都创建并正常启动后，Pod 进入 “Running” 状态。

4. 状态反馈与同步

状态更新：
- Kubelet 会周期性地获取 Pod 的实际运行状态（通过 CRI 和 PLEG）：
  - 检查容器是否正常运行；
  - 如果存在失败，则可能记录事件（Event）并尝试重启容器。
- 这些状态信息会被汇报到 API Server，API Server 将其写入 etcd。
状态查询结果：
- 用户通过 kubectl get pod <pod-name> -o wide 或其他方式查询 Pod 状态时，会从 etcd 中读取最新状态。
- 当所有容器成功运行，且健康检查通过时，Pod 会被标记为 Ready。

#k8s

kubernetes_kubelet

https://mfzzf.github.io/2025/03/21/kubernetes-kubelet/

作者

Mzzf

发布于

2025年3月21日

许可协议

kubernetes_CRI 上一篇

Golang并发编程下一篇