1. 项目背景
某AI中台团队的单机Docker部署方案平稳运行了三个月后，业务方提出了新需求：需要三套独立的vLLM环境（开发、测试、生产），每套有不同的GPU配置、模型版本和扩缩容策略。此外，生产环境需要在GPU节点故障时自动迁移服务，在流量高峰时自动扩容。
运维团队尝试在3台GPU服务器上手动管理9个Docker容器（3环境 × 3模型），很快陷入了混乱：版本不一致（开发环境跑了v0.8.5，生产还是v0.7.2）、配置漂移（某台机器手动改了max-num-seqs但没同步到其他机器）、故障恢复靠人肉重启。一次生产故障中，GPU节点宕机1小时才被发现——因为没有自动健康检查和流量切换。
痛点：单机Docker Compose适合原型和中小规模，但当模型数量>3、GPU节点>2、或者有灾备和扩缩容需求时，手动管理就变成了运维噩梦。Kubernetes提供了声明式部署、自动故障恢复、滚动更新和资源调度能力，是vLLM生产化的必然方向。
本章将从零构建vLLM的K8s部署方案：GPU节点配置、模型PVC持久化、Service暴露、健康检查、HPA自动扩缩容，并对比Deployment/StatefulSet/DaemonSet的选择逻辑。
2. 项目设计
（场景：运维工位。三个终端窗口分别连着三台GPU服务器，每个上面跑着不同版本的vLLM。运维小王用excel记录着"哪台机器跑了哪个模型"的表格。）
小胖：“王哥，你excel上这个’dev-qw
