第26章：Kubernetes部署——从单机到集群资源治理

1. 项目背景

业务场景

某公司AI平台从单机Docker Compose（第25章）平稳运行了两个月后，迎来了业务的快速增长。客服团队从30人扩展到100人，研发团队也新增了两个项目组，日均AI调用量从5000次暴涨到30000次。单台GPU服务器在高峰期开始频繁超时——P95延迟从3秒恶化为25秒。

CTO在扩容评审会上拍板："加机器，上K8s。"但运维老李面临挑战——Ollama是单进程推理服务，不像Web服务那样天然无状态。模型文件要如何分发到多台GPU节点？用户请求如何路由到有空闲GPU的节点？多租户如何隔离？如何在K8s中做GPU调度？

更棘手的是——HPA（水平自动扩缩容）对推理服务不太适用：扩容一个新Pod意味着要拉取模型、加载到GPU显存，冷启动需要30秒，流量高峰已经过去了。

痛点

1. 模型分发成本高：每台GPU节点都需要完整的模型文件（7B模型4.7GB），镜像打包不可行（镜像体积爆炸），需要独立的数据卷挂载。
2. GPU资源稀缺：K8s集群中可能只有3个节点有GPU，需要精细的节点亲和性调度。
3. 推理服务无状态化难：Ollama Runner是长驻进程，模型加载有冷启动成本——传统的"Pod挂了就重建"会导致服务中断。
4. 多租户资源争抢：不同部门/项目的AI请求打到同一台GPU，需要资源隔离和配额管理。

一句话总结：