一次完整的容器创建过程:从YAML到Pod运行

我们在使用 Kubernetes 时，经常会写一份 Deployment 或 Pod 的 YAML 文件，执行一条 kubectl apply -f 命令，短短几秒钟，一个容器就运行起来了。

这背后到底发生了什么？YAML 文件里的定义，是如何一步步转化为一个运行中的 Pod？Kubernetes 又如何调用底层容器运行时，将镜像拉起并运行？

本文从一个开发者常见的操作出发，拆解整个过程，带你理解 Kubernetes 背后这套强大而精密的机制。

---

一、从 YAML 到 Kubernetes API Server

我们以一个最简单的 Pod 配置为例：

apiVersion: v1
kind: Pod
metadata:
  name: demo-pod
spec:
  containers:
    - name: app
      image: nginx:latest

当你执行命令：

kubectl apply -f pod.yaml

发生的第一件事，其实是 kubectl 把这段 YAML 解析成结构化的 JSON 对象，并调用 Kubernetes 的 RESTful API，把它发送给 API Server。

流程如下：

此时，Pod 资源只是一段存储在 etcd 中的数据，尚未被实际调度执行。

---

二、Scheduler：决定 Pod 应该跑在哪个节点上

API Server 接收到 Pod 请求后，Pod 对象会先处于 Pending 状态，因为它还没被调度。

这时，调度器（Scheduler）会启动工作：

1. 过滤：从所有 Node 中筛选出满足要求的节点（如资源够用、taint 允许、selector 匹配等）
2. 打分：对符合条件的节点打分，通常根据负载、拓扑等策略决定
3. 绑定：选出最佳节点，调用 API Server 把 Pod 绑定到该节点

绑定过程通过写入一个字段 spec.nodeName 来实现，也仍是数据操作：

spec:
  nodeName: node-1

至此，Pod 被分配到了某个具体的 Node 上，但容器还未开始启动。

---

三、Kubelet 接管调度结果，启动容器

每个 Node 上都运行着一个 Kubelet 组件，它会不断向 API Server 查询与自己相关的 Pod 信息。一旦发现有新绑定到自己的 Pod，Kubelet 就开始执行以下动作：

1. 拉取镜像（如果本地不存在）
2. 为容器分配资源、挂载卷、配置网络
3. 通过容器运行时（Container Runtime）启动容器

这里涉及另一个重要角色：Container Runtime Interface (CRI) ，Kubelet 并不直接启动容器，而是通过 CRI 与底层的容器运行时通信，如：

• containerd
• CRI-O
• 早期的 Docker shim（已弃用）

Kubelet 调用容器运行时的流程大致如下：

容器启动成功后，Kubelet 会定期汇报 Pod 状态给 API Server，Pod 状态从 Pending 变为 Running。

---

四、CNI 插件：配置网络连接

启动容器的过程中，还有一个至关重要的环节------网络配置。

Kubernetes 使用 CNI（Container Network Interface）插件 为每个 Pod 分配 IP，并将它接入虚拟网络。整个流程如下：

1. Kubelet 请求 CNI 插件为 Pod 分配 IP
2. CNI 插件创建虚拟网卡、配置路由、桥接或 VXLAN 隧道
3. 分配到的 IP 写入 Pod 的 network namespace 中
4. 网络就绪，Pod 可通信

主流的 CNI 插件包括 Flannel、Calico、Cilium、Weave 等，它们各自实现了不同的网络策略与路由机制。

---

五、Pod 启动完成，进入就绪状态

至此，一个完整的 Pod 已经启动成功。回顾整个流程：

我们常说的"创建 Pod"看似一行命令，其实背后涉及了 API 通信、调度逻辑、镜像拉取、容器运行、网络配置等多个模块的协同运作。

---

六、为什么了解这些流程很重要？

• 排查问题：知道哪些阶段可能失败，才能有针对性地检查日志
• 优化性能：调度器策略、镜像预拉、网络插件选择都可能影响启动速度
• 安全治理：CRI 与网络配置也是安全风险的入口，理解细节有助于加固
• 架构扩展：开发自定义控制器或调度器时，需要精通这些底层机制

在生产环境中，如果 Pod 卡在 Pending、镜像拉取失败、网络异常等问题层出不穷，这些知识可以帮你快速定位并解决问题。

---

七、总结：一图胜千言

---

后记

每次运行 kubectl apply -f，都是对 Kubernetes 背后复杂系统的一次"触发"。从声明式 YAML 到容器真正启动，中间跨越多个组件协同、状态流转和底层调用。

这不是一场魔法，而是一套精密的工程。理解它，才是掌控它的开始。