K8s思维导图
K8s 单节点容器启动全流程
核心前提
K8s 集群中每个节点都需部署容器运行时相关组件，可通过 Ansible 实现所有节点的标准化批量安装配置，避免手动操作不一致。
容器启动核心流程（分层拆解）
整个流程遵循"上层编排→标准化接口→底层执行→内核支撑"的设计，核心链路分两条（根据容器运行时不同）：
- 链路1（CRI-O 运行时）：
Kubelet → CRI → CRI-O → runc → Linux 内核 - 链路2（Containerd 运行时）：
Kubelet → CRI → Containerd → containerd-shim → runc → Linux 内核
| 组件层级 | 组件名称 | 核心角色与作用 |
|---|---|---|
| 节点核心代理 | Kubelet（节点代理） | 1. 节点"大管家"，每个节点必部署，接收控制平面（API Server）的 Pod 调度指令； 2. 不直接操作容器，通过 CRI（容器运行时接口） 调用底层运行时； 3. 额外职责：监控 Pod/容器健康状态、上报节点资源、执行探针检查。 |
| 标准化接口层 | CRI（Container Runtime Interface） | 1. 本质：K8s 定义的接口规范 （非具体软件）； 2. 核心作用：解耦 Kubelet 与容器运行时，只要运行时实现 CRI，即可与 Kubelet 无缝对接（支持 CRI-O、containerd 等）。 |
| 容器运行时层 | CRI-O/Containerd | 1. 本质：符合 CRI 标准的具体容器运行时软件 （CRI-O 专为 K8s 设计，Containerd 更通用）； 2. 核心职责： - 调用 /container/image 库拉取/管理容器镜像； - 调用 /container/storage 库管理容器存储卷和文件系统； - 协调容器生命周期（创建/停止/删除），最终调用 runc 执行实际操作； 3. Containerd 额外通过 containerd-shim 守护进程管理容器，避免主进程挂掉导致容器退出。 |
| 容器执行层 | runc | 1. 本质：符合 OCI（开放容器倡议） 标准的轻量级工具，无常驻守护进程； 2. 核心角色："最终执行者"，直接对接 Linux 内核； 3. 工作逻辑：读取镜像/配置，向内核发起系统调用，利用 Namespaces（资源隔离）和 cgroups（资源限制）创建容器进程。 |
| 底层支撑层 | Linux 内核 | 1. 核心能力：通过 Namespaces 实现容器的 PID/网络/挂载/用户等隔离；通过 cgroups 限制容器 CPU/内存/IO 等资源； 2. 最终结果：创建隔离的容器进程，提供独立运行环境。 |
| 镜像/容器实体 | Container Image/Container | 1. 容器镜像：只读模板，包含应用运行所需的所有文件、依赖、配置； 2. 容器：镜像的运行实例，拥有独立文件系统、网络、进程空间。 |
流程简化理解（通俗版）
- 控制平面告诉节点的 Kubelet："启动这个 Pod"；
- Kubelet 按 CRI 标准喊："CRI-O/Containerd，帮我起容器"；
- CRI-O/Containerd 先把镜像从仓库拉下来，准备好存储环境，然后喊："runc，你来实际创建容器"；
- runc 向 Linux 内核申请："给这个进程开隔离空间、设资源限制"；
- 内核完成隔离和限制，容器进程正式启动。
关键设计特点
- 解耦化：CRI 解耦 Kubelet 与运行时，OCI 解耦 runc 与镜像/运行时，底层内核能力解耦 runc 与操作系统（只要内核支持 Namespaces/cgroups 即可）；
- 轻量化：runc 无守护进程，仅负责容器创建，资源占用极低；
- 标准化：全流程遵循 CRI/OCI 标准，兼容不同运行时和镜像格式；
- 可批量部署：所有节点的 Kubelet、CRI-O/Containerd、runc 等组件，可通过 Ansible 编写 Playbook 实现一键批量安装配置，保证集群节点环境一致。
总结
- K8s 单节点容器启动的核心逻辑是"上层编排指令→标准化接口转发→运行时资源准备→底层工具执行→内核提供隔离环境"；
- 核心链路为
Kubelet → CRI → 容器运行时（CRI-O/Containerd） → runc → Linux 内核； - 所有节点的组件可通过 Ansible 批量部署，保证集群环境统一，体现 K8s "上层编排调度+下层标准化运行时"的架构设计核心。