4. kubelet 内部架构：核心组件与 Pod 生命周期管理

kubelet 是 Kubernetes 集群中运行在每个节点上的核心代理，负责管理节点上所有容器的生命周期。理解 kubelet 的内部架构，特别是 PLEG、SyncLoop、PodManager 等核心组件如何协同工作，是进行容器运行时容量调优的基础。本章将深入剖析 kubelet 的内部组件、Pod 生命周期管理流程以及资源更新的触发机制。

4.1 kubelet 核心组件总览

kubelet 内部由多个协同工作的组件构成，形成一个高效的状态机。以下表格列出了最关键的组件及其职责：

组件名称 核心职责 与容量调优的关联
PodManager 管理本地 Pod 的期望状态（Spec）和实际状态（Status），维护 Pod 缓存。 提供 Pod 资源请求（Requests）和限制（Limits）的本地视图。
PLEG (Pod Lifecycle Event Generator) 定期检查容器运行时状态，生成 Pod 生命周期事件（如容器启动、停止、健康检查失败）。 驱动资源回收和重新分配的关键事件源。
SyncLoop (主同步循环) kubelet 的核心控制循环，监听多个数据源（Pod 更新、PLEG 事件、定时器），驱动 Pod 状态同步。 资源更新请求的最终执行者，决定何时调用 CRI 进行资源调整。
Container Runtime Manager (CRI Manager) 通过 CRI 接口与容器运行时（如 containerd、CRI-O）通信，执行创建、删除、更新容器的操作。 资源调优指令的实际下发通道。
Resource Manager / QoS Manager 管理节点资源（CPU、内存、PID），根据 Pod QoS 等级进行资源分配和回收。 决定资源争抢时的优先级和驱逐策略。
Status Manager 负责将 Pod 状态上报给 API Server。 反馈资源调整后的实际效果。
容量调优视角： 在容量调优场景中，PLEG 和 SyncLoop 是最需要关注的两个组件。PLEG 的检测频率直接影响资源变更的响应速度，而 SyncLoop 的执行效率决定了资源调整的吞吐量。

4.2 kubelet 内部组件架构图

下图展示了 kubelet 内部核心组件之间的数据流和依赖关系：

kubelet 内部核心组件架构与数据流 API Server PodManager PLEG SyncLoop CRI Manager Resource Manager Status Manager 容器运行时 (CRI) 节点资源 (CPU/Mem) 图例说明： 实线：主控制流（SyncLoop 驱动） 虚线：状态反馈流（Status Manager 收集） 核心循环：API Server → SyncLoop → CRI Manager → 容器运行时 → Status Manager → API Server

4.3 Pod 生命周期管理流程

Pod 从创建到销毁的完整生命周期由 kubelet 的 SyncLoop 驱动，并与 PLEG 和 PodManager 紧密协作。以下是标准流程：

  1. Pod 创建阶段
    • API Server 将 Pod 绑定到节点，kubelet 通过 List/Watch 机制获取 Pod 对象。
    • PodManager 将 Pod 添加到本地缓存，标记为 Pending 状态。
    • SyncLoop 检测到新 Pod，调用 CRI Manager 创建沙箱（Sandbox）和容器。
    • 容器运行时返回状态，Status Manager 上报 Running 状态。
  2. Pod 运行阶段
    • PLEG 定期（默认 1 秒）检查容器运行时状态，生成事件（如容器退出、健康检查失败）。
    • SyncLoop 接收 PLEG 事件，对比 PodManager 中的期望状态，决定是否需要重新创建容器或调整资源。
    • Resource Manager 监控节点资源使用率，触发驱逐或资源回收。
  3. Pod 更新阶段
    • 用户更新 Pod Spec（如修改 CPU 限制），API Server 推送更新。
    • PodManager 更新本地缓存，SyncLoop 检测到差异，调用 CRI Manager 执行 UpdateContainerResources 或重建容器。
  4. Pod 删除阶段
    • API Server 删除 Pod 对象，kubelet 收到删除事件。
    • SyncLoop 调用 CRI Manager 停止并删除容器和沙箱。
    • PodManager 清理本地缓存，Status Manager 上报最终状态。
容量调优关键点： Pod 更新阶段是资源调优的核心场景。当需要调整容器的 CPU 或内存限制时，kubelet 会通过 CRI 的 UpdateContainerResources 接口向运行时发送请求。如果运行时支持原地更新（如 containerd v1.6+），则无需重启容器，大幅降低调优对业务的影响。

4.4 资源更新触发机制

kubelet 触发资源更新的场景主要分为三类，每种场景的触发源和处理路径不同：

触发场景 触发源 处理路径 对容器的影响
Pod Spec 更新 API Server Watch SyncLoop → PodManager 对比 → CRI UpdateContainerResources 通常无重启（原地更新）
节点资源压力 Resource Manager 监控 Resource Manager → SyncLoop → 驱逐或调整 QoS 可能触发容器重启或驱逐
PLEG 事件驱动 容器运行时状态变化 PLEG → SyncLoop → 重新同步 Pod 状态 可能触发容器重建

4.5 SyncLoop 与 PLEG 的协作机制

SyncLoop 是 kubelet 的“大脑”，它通过一个多路复用机制监听多个数据源。PLEG 则是“眼睛”，负责感知容器运行时的状态变化。两者的协作流程如下：

SyncLoop 与 PLEG 协作流程图 API Server Watch PLEG 事件通道 定时器 (SyncFrequency) SyncLoop 多路复用器 (PodWorker) CRI Manager Status Manager PodManager 更新 关键参数说明： • PLEG Relist Interval（默认 1s）：PLEG 检查容器运行时状态的频率，影响事件检测延迟。 • SyncFrequency（默认 1s）：SyncLoop 定时同步的频率，影响状态上报的及时性。 • PodWorker：每个 Pod 对应一个工作协程，SyncLoop 将事件分发到对应的 PodWorker 进行处理。
性能陷阱： 当节点上 Pod 数量较多（>1000）时，PLEG 的 Relist 操作可能成为性能瓶颈。每次 Relist 都会调用 CRI 的 ListContainers 和 ListPodSandbox 接口，如果容器运行时响应缓慢，会导致 PLEG 事件积压，进而影响 SyncLoop 的处理效率。在容量调优场景中，建议监控 PLEG 的 relist_duration 指标，确保其不超过 1 秒。

4.6 PodManager 的状态管理

PodManager 维护了 Pod 的两种状态视图，SyncLoop 通过对比这两个视图来决定是否需要执行同步操作：

  • 期望状态（Desired State）：从 API Server 获取的 Pod Spec，存储在 podManager 的 pods 映射中。
  • 实际状态（Actual State）：从容器运行时和 PLEG 事件中获取的 Pod 真实状态，存储在 podManager 的 mirrorPods 或 statusManager 中。

当 SyncLoop 发现期望状态与实际状态不一致时，会触发同步操作。例如，如果期望的 CPU 限制是 2 核，但实际运行时限制是 1 核，SyncLoop 会调用 CRI 的 UpdateContainerResources 进行修正。

调优实践： 在容器运行时容量调优中，可以通过修改 Pod 的 resources.requests 和 resources.limits 字段来触发 kubelet 的资源更新。建议使用 kubectl patch 命令原地更新，避免删除重建 Pod。例如：
kubectl patch pod my-pod -p '{"spec":{"containers":[{"name":"my-container","resources":{"limits":{"cpu":"500m","memory":"512Mi"}}}]}}'
该操作会触发 SyncLoop 调用 CRI 的原地更新接口，无需重启容器。
← 上一章 📖 返回目录 下一章 →