Pod 在节点落地通信流程

目标

这篇文档只回答一个核心问题：kubelet 如何把“期望运行”的 Pod 变成“真实运行”的容器？

重点放在 kubelet 内部各组件之间的协作与 CRI 通信边界，而不是每一个 gRPC 字段的含义。

一句话摘要

kubelet 收到 Pod 更新后，把期望态交给 podWorkers；podWorkers 驱动单 Pod 生命周期状态机，再由 kubeGenericRuntimeManager 通过 CRI 调用容器运行时完成 sandbox、镜像与容器操作。

1. 流程总览

从通信视角看，这条链路可以拆成 3 个阶段：

更新接入阶段：kubelet 从 Pod source 收到属于本节点的 Pod 更新，并交给内部子系统。
状态机驱动阶段：podWorkers 根据当前状态决定执行同步、终止还是清理。
运行时执行阶段：runtime manager 通过 CRI 把操作翻译给容器运行时，完成 sandbox 和容器的创建/销毁。

Mermaid：总览图

flowchart LR
    A[Pod update from source] --> B[podManager]
    B --> C[podWorkers]
    C --> D{SyncPod or TerminatingPod?}
    D -->|SyncPod| E[prepare volumes / secrets]
    E --> F[kubeGenericRuntimeManager]
    F --> G[CRI RuntimeService / ImageService]
    G --> H[container runtime]
    D -->|TerminatingPod| I[SyncTerminatingPod]
    I --> F

Kubelet 内部组件协作架构图

flowchart TB
    subgraph 输入层["Pod 输入层"]
        direction LR
        API[API Server<br/>Pod 来源]
        FILE[静态文件<br/>Pod 来源]
        HTTP[HTTP 端点<br/>Pod 来源]
    end

    subgraph 聚合层["配置聚合层"]
        PC[PodConfig]
        CH[updates channel]
    end

    subgraph 核心层["Kubelet 核心层"]
        direction TB
        PM[podManager<br/>期望态索引]
        PW[podWorkers<br/>状态机驱动器]
        SM[statusManager<br/>状态同步]
        VM[volumeManager<br/>卷管理]
        PR[probeManager<br/>探针管理]
    end

    subgraph 运行时层["容器运行时层"]
        direction TB
        KRM[kubeGenericRuntimeManager]
        CRI_R[RuntimeService<br/>容器生命周期]
        CRI_I[ImageService<br/>镜像管理]
    end

    subgraph 外部系统["外部系统"]
        RT[容器运行时<br/>containerd/cri-o]
        CSI[CSI Driver<br/>存储插件]
        CNI[CNI Plugin<br/>网络插件]
    end

    API --> PC
    FILE --> PC
    HTTP --> PC
    PC --> CH
    CH --> PM
    PM --> PW
    PW -->|SyncPod| KRM
    PW -->|SyncTerminatingPod| KRM
    PW --> SM
    PW --> VM
    PW --> PR
    VM --> CSI
    KRM --> CRI_R
    KRM --> CRI_I
    CRI_R --> RT
    CRI_I --> RT
    RT --> CNI
    SM -->|状态上报| API

Pod 生命周期状态机图

stateDiagram-v2
    [*] --> SyncPod: Pod 创建/更新
    SyncPod --> Running: 容器启动成功
    SyncPod --> SyncPod: 启动失败,重试
    Running --> SyncTerminatingPod: 收到删除请求
    SyncTerminatingPod --> SyncTerminatedPod: 优雅终止完成
    SyncTerminatingPod --> SyncTerminatedPod: 超时,强制终止
    SyncTerminatedPod --> [*]: 清理完成

    note right of SyncPod
        创建 sandbox
        挂载卷
        拉取镜像
        创建容器
        启动容器
    end note

    note right of SyncTerminatingPod
        发送 SIGTERM
        等待优雅终止期
        超时发送 SIGKILL
        停止容器
    end note

    note right of SyncTerminatedPod
        卸载卷
        清理 sandbox
        从 podManager 移除
    end note

这张图想表达什么

podManager 只负责元数据视图，不负责执行。
podWorkers 是单 Pod 生命周期的驱动器，区分同步和终止路径。
CRI 是 kubelet 与容器运行时之间的标准协议边界。

2. 分阶段通信流程

阶段一：从 Pod source 到内部子系统

这个阶段的本质是：把控制面的 Pod 期望态同步到 kubelet 本地视图。

步骤 1.1：PodConfig 聚合多个来源

kubelet 支持三个 Pod 来源：apiserver source、file source（静态 Pod）、HTTP source。PodConfig 负责聚合这三个来源的更新，对外提供一个统一的更新通道。

通信方向：多个 source → PodConfig 的 merge channel

步骤 1.2：收到 Pod 更新事件

当 PodConfig 从某个 source 收到 Pod 更新时，它会根据 UID 和全名进行去重和合并，然后生成一个统一的 kubetypes.PodUpdate。

通信方向：PodConfig 内部处理

步骤 1.3：podManager 更新本地视图

podManager 收到更新后，会维护本地期望态视图，包括：

podByUID：按 UID 索引 Pod
podByFullName：按 namespace/name 索引 Pod
mirrorPodByUID：静态 Pod 对应的 mirror pod

通信方向：PodConfig → podManager（通过 channel）

步骤 1.4：podWorkers 接收 UpdatePod

podWorkers.UpdatePod(...) 是节点侧生命周期的入口。它会根据 Pod UID 找到或创建对应的工作上下文，并决定下一步走哪条状态机路径。

通信方向：podManager → podWorkers（通过函数调用）

阶段二：podWorkers 驱动状态机

这个阶段的本质是：每个 Pod 有独立的状态机，podWorkers 负责驱动状态转换。

步骤 2.1：判断当前状态

podWorkers 收到更新后，会对比期望态和当前实际状态，决定执行：

SyncPod：需要创建或更新 Pod
SyncTerminatingPod：需要优雅终止 Pod
SyncTerminatedPod：需要清理已终止 Pod 的残留

通信方向：podWorkers 内部状态判断

步骤 2.2：进入 SyncPod 路径（创建/更新）

如果决定执行 SyncPod，kubelet 会依次完成：

准备存储卷（VolumeManager.WaitForAttachAndMount）
拉取 secrets 和 configmaps
准备 pod sandbox
创建并启动容器

通信方向：podWorkers → kubelet.SyncPod(…) → 多个子系统

步骤 2.3：准备存储卷

VolumeManager 会确保 Pod 需要的卷已经 attach 并 mount 到正确位置。这一步可能涉及与 CSI driver 的通信。

通信方向：kubelet → VolumeManager → CSI driver（外部）

步骤 2.4：拉取 secrets/configmaps

如果 Pod 引用了 secrets 或 configmaps，kubelet 会从 API Server 拉取这些资源，并传递给 runtime manager。

通信方向：kubelet → secretManager/configMapManager → API Server

步骤 2.5：进入 SyncTerminatingPod 路径（优雅终止）

如果 Pod 被标记为删除，podWorkers 会进入终止路径。它会先向容器发送 SIGTERM，等待优雅终止期，超时后发送 SIGKILL。

通信方向：podWorkers → kubelet.SyncTerminatingPod(…) → CRI

步骤 2.6：进入 SyncTerminatedPod 路径（清理）

终止完成后，SyncTerminatedPod 会清理 Pod 的残留资源，包括：

卸载存储卷
清理 sandbox
从 podManager 中移除 Pod

通信方向：podWorkers → kubelet.SyncTerminatedPod(…) → 多个子系统

阶段三：通过 CRI 执行容器操作

这个阶段的本质是：kubelet 把操作意图翻译成标准化的 CRI gRPC 调用。

步骤 3.1：创建 pod sandbox

在创建任何业务容器之前，runtime manager 会先调用 CreatePodSandbox 创建一个 pod sandbox。sandbox 是 Pod 的基础运行环境，包含网络命名空间等基础设施。