1. 起点：kubelet 发起启动请求
整个流程的第一步，是 kubelet 收到了调度器的指令："要在这个节点启动一个 Pod"。
这时候 kubelet 不会自己去启动容器，它会调用CRI 标准接口，发起一个 "启动容器" 的请求。
这一步的核心是解耦：kubelet 只负责 "我要启动一个容器"，至于底层用什么运行时、怎么启动，kubelet 完全不关心，只要你符合 CRI 标准，就能对接，这也是 K8s 能支持这么多容器运行时的原因。
2. 转发：CRI 接口把请求传给 CRI-O
kubelet 的请求通过 CRI 这个通用接口，转发给了节点上配置的容器运行时，也就是这张图里的CRI-O。
CRI 就像一个桥梁，把 K8s 和底层的运行时彻底分开了，以前 K8s 要专门适配 Docker，现在只要适配 CRI，所有符合标准的运行时都能用，不用再做额外的适配。
3. 准备：CRI-O 搞定镜像和存储
CRI-O 收到请求之后，就开始做启动前的准备工作，这也是图里左侧标注的核心逻辑：
CRI-O 使用 /container/image 和 /container/storage 库来拉取容器镜像，并在磁盘上对其进行管理
它会做两件核心的事：
- 拉取镜像：调用镜像管理库，检查本地有没有需要的镜像，如果没有，就从远程镜像仓库（比如 Harbor）把镜像拉到本地，存到磁盘；
- 准备文件系统：调用存储管理库，用 OverlayFS 把镜像的多个只读层合并，给容器准备好可写的根文件系统，让容器能有自己的文件系统环境。
这一步做完，容器的 "安装包" 就准备好了，就等启动了。
4. 执行：runc 真正创建容器
准备工作做完，CRI-O 就会调用runc，这是真正创建容器的工具，也是图里右侧标注的核心逻辑：
CRI-O 守护进程启动一个与开放容器倡议（OCI）兼容的运行时（runc）来运行容器进程
runc 拿到镜像和配置之后，就会调用 Linux 内核，做这几件事：
- 创建 Namespace：给进程做隔离，让它有自己的 PID、网络、文件系统；
- 创建 CGroup：给进程做资源限制，限制它能用多少 CPU、内存；
- 挂载 OverlayFS：把之前准备好的分层文件系统挂载好，变成容器的根目录；
- 启动容器内的进程。
这一步做完，容器就真正被创建出来了！而且 runc 启动完容器就会退出，不会常驻内存，非常轻量，容器进程会交给 CRI-O 守护进程托管。
5. 运行：容器进程正式启动
runc 启动完容器内的进程之后，容器就正式运行起来了，这时候它就是一个独立的、被隔离的进程，有自己的环境，跑我们的业务应用。
6. 支撑：Linux 内核提供所有底层能力
整个流程的最后，所有的能力都来自 Linux 内核：
- Namespace 给容器做隔离墙，让容器看不到宿主机；
- CGroup 给容器做紧箍咒，限制它的资源；
- OverlayFS 给容器做分层存储，实现镜像复用。
这也是容器为什么这么轻量的原因：容器不是虚拟化，它就是一个被内核隔离、限制的普通进程，所有能力都是内核早就有的，Docker/CRI-O 只是把这些能力打包成了好用的工具而已。