1. K8s与vLLM初识：Kubernetes核心概念与vLLM推理框架
大家好，我是你们的运维老司机。今天咱们聊聊K8s和vLLM这对黄金搭档。说实话，我第一次接触vLLM时，脑子里第一个念头就是——这东西要是没有K8s管着，生产环境迟早要出乱子。嗯，咱们一步步来。
1.1 Kubernetes核心三件套：Pod、Service、Deployment
K8s的概念很多，但真正天天打交道的，说白了就这三个：Pod、Service、Deployment。我习惯把它们比作「工人、门牌、老板」。
Pod：最小的计算单元
Pod是K8s里能跑容器的最小单位。一个Pod可以装一个或多个容器，共享网络和存储。我在项目中遇到过有人把Pod当虚拟机用，一个Pod里塞七八个容器，结果日志都分不清谁是谁的。记住：一个Pod一个主进程，这是最佳实践。
Service：稳定的访问入口
Pod会死会活，IP会变。那客户端怎么访问？Service就是干这个的。它提供一个固定的虚拟IP和DNS名，后端Pod随便换，前端无感知。
你想想看，vLLM推理服务对外暴露API，总不能每次Pod重启都改客户端配置吧？Service就是那个「永远不变的电话号码」。
Deployment：声明式的控制器
Deployment负责管理Pod的「生老病死」。你告诉它「我要3个vLLM副本」，它就会一直维持3个。有人误删了一个Pod？Deployment秒级重建。我曾经在生产环境手滑删错Pod，Deployment三秒就给我拉起来了，吓得我赶紧去改RBAC权限。
replicas和resources，不然vLLM吃满CPU你都不知道怎么死的。
1.2 vLLM推理框架简介
vLLM是什么？简单说，它是一个高性能的大模型推理引擎。相比传统的HuggingFace Transformers，vLLM在显存管理和批处理上做了大量优化。
我刚开始用vLLM时，最惊艳的是它的PagedAttention机制。说白了，就是把显存像操作系统的虚拟内存一样分页管理。以前跑一个13B模型，单卡A100勉强塞下，用了vLLM之后，同样的模型还能同时处理4个并发请求。
| 特性 | vLLM | 传统Transformers |
|---|---|---|
| 显存利用率 | 高（PagedAttention） | 低（静态分配） |
| 并发处理 | 连续批处理 | 逐请求处理 |
| 部署复杂度 | 中等 | 低 |
| 生产环境推荐 | 强烈推荐 | 不推荐 |
1.3 为什么用K8s管理vLLM？
这个问题我问过自己很多遍。直接在一台机器上跑vLLM不香吗？香，但仅限于实验环境。生产环境里，你会遇到这些问题：
- 单点故障：机器挂了，服务全停。K8s可以自动调度到健康节点。
- 资源碎片：GPU利用率低，有的节点满载，有的空转。K8s可以智能调度。
- 滚动更新：模型版本升级，总不能停服吧？K8s的Deployment支持零停机更新。
- 自动扩缩：白天请求多，晚上请求少。K8s的HPA（水平自动扩缩）可以根据CPU/GPU利用率自动调整副本数。
我举个例子。之前有个客户，白天推理请求量是晚上的10倍。手动扩缩？运维得累死。用K8s的HPA配合vLLM的metrics，自动从2个Pod扩到20个，晚上再缩回来。电费都省了一半。
1.4 本章知识体系总览
下面这张图，是我自己梳理的K8s+vLLM核心逻辑。你看一遍，心里就有谱了。
1.5 本章小结
这一章咱们把地基打好了。K8s的三个核心概念——Pod、Service、Deployment，是后续所有操作的基础。vLLM作为推理引擎，解决了显存和并发的大问题。而K8s+vLLM的组合，说白了就是「让AI服务像互联网应用一样稳定可靠」。
我记得刚入行时，前辈跟我说：「别急着写代码，先把架构想清楚。」现在我把这句话送给你。下一章咱们会动手搭建一个真正的vLLM推理服务，到时候这些概念都会用上。
kubectl run创建一个简单的nginx Pod试试手。感受一下Pod的创建、删除、日志查看。实践出真知。
公众号:蓝海资料掘金营，微信deep3321