第一章：一个 GPU Pod 是如何被创建的¶

本章以单副本 vLLM Deployment 为主线，说明 Kubernetes 运行 GPU 服务时各组件的分工。用户提交 Deployment、PVC 和 Service 后，API Server 接收请求，etcd 保存对象，Controller 创建 ReplicaSet 和 Pod，Scheduler 选择 GPU 节点。Pod 到达节点后，Kubelet 协调容器运行时、CNI、CSI 和 NVIDIA Device Plugin。/v1/models 接口和一次真实推理用于确认模型已经可以服务。

vLLM 部署路径¶

下图展示了 Deployment 从提交到 vLLM 接收推理请求之间的对象变化和组件交接。

flowchart LR
    U["kubectl apply\nDeployment + PVC + Service"]
    A["API Server\n认证、授权、Admission"]
    E["etcd\n对象与 revision"]
    C["Controller\nDeployment → ReplicaSet → Pod"]
    S["Scheduler\n选择 GPU Node"]
    K["Kubelet\n驱动 Pod 收敛"]
    R["Runtime / CNI / CSI\nSandbox、网络与卷"]
    G["Device Plugin / CDI\n分配并注入 A100"]
    V["vLLM API 可用\n响应推理请求"]

    U --> A --> E
    E --> C
    C --> A
    A --> E
    E --> S
    S --> A
    A --> E
    E --> K
    K --> R
    K --> G
    R --> V
    G --> V

箭头表示对象变化的先后关系。Controller、Scheduler 和 Kubelet 分别通过 API Server 观察并更新对象；Deployment 运行期间会产生多次 etcd 写入和 Watch 事件。

章节目录¶

页面	内容
Kubernetes 架构：控制面与工作节点	控制面、工作节点以及各组件之间的边界
API Server：集群的统一入口	请求处理链、认证授权、Admission、API 校验与 Watch Cache
etcd：Kubernetes 的状态存储	Raft、MVCC、revision、Watch、Compaction 与备份恢复
Controller：从 Deployment 到 Pod	Deployment Controller、ReplicaSet Controller、OwnerReference 与 Status
Scheduler：Pod 的节点选择	调度队列、Scheduling Cycle、Binding Cycle 与 GPU 资源过滤
Kubelet：节点上的 Pod 管理	Node 注册、syncLoop、Pod Worker、CRI、PLEG 与状态回写
容器运行时：从 CRI 到容器进程	CRI、Pod Sandbox、containerd、shim、runc 与 Linux 隔离
网络：通信与流量转发	CNI、Pod 网络、Service 数据面及常见网络方案
存储：PersistentVolume、CSI 与数据路径	PersistentVolume、CSI 卷生命周期、存储项目与 AI 数据路径
GPU 设备：Device Plugin 与设备注入	NVIDIA Device Plugin、Allocate、CDI 与 DRA 的位置
Pod 生命周期：启动、就绪、重启与终止	启动、就绪、重启、资源限制和正常终止
端到端流程：部署并访问 vLLM	从 Deployment 创建到第一条推理响应的完整复盘
实验：搭建 nvkind 集群并追踪 vLLM 部署	宿主机准备、集群搭建、vLLM 部署和日志追踪

学习目标¶

完成本章后，可以说明 API Server 与 etcd、Controller 与 Scheduler、Kubelet 与容器运行时的分工，区分 CNI 与 Service 数据面，并根据对象状态判断部署进度。Deployment 已经存在而 ReplicaSet 尚未出现时，应检查 Controller；Pod 没有 spec.nodeName 时，应检查 Scheduler；Pod 已绑定节点却停在 ContainerCreating 时，应检查 Kubelet、CRI、CNI、CSI 和设备分配。

阅读方式¶

各组件页面说明组件职责和内部机制，并给出对应的源码入口、状态检查命令与故障证据。完整安装、部署和追踪流程集中在实验：搭建 nvkind 集群并追踪 vLLM 部署。

本章实验固定使用 Ubuntu 24.04、单张 A100 80 GB、Kubernetes v1.36.1、nvkind、Calico、CSI Hostpath Driver 和 NVIDIA Device Plugin。涉及控制面与 Kubelet 实现时，源码链接固定到同一 minor 的 v1.36.4。Hostpath Driver 与 nvkind 都只用于教学环境，不能据此推断生产集群的存储可靠性或 GPU 隔离能力。