在本地运行 Ollama 并不复杂，但当模型需要面向团队或业务系统提供稳定服务时，单机部署很快会遇到 GPU 资源固定、模型文件重复下载、故障恢复困难和高峰期排队等问题。将 Ollama 接入 Kubernetes，可以利用统一调度、持久化存储、健康检查和弹性扩缩容能力，把“能运行”升级为“可持续运维”的 GPU 推理服务。🚀
一、部署前先明确整体架构
一套实用的部署架构通常由 Ollama Deployment、ClusterIP Service、模型持久化卷、GPU 节点池、指标采集组件和自动扩缩容控制器组成。业务应用通过 Service 调用 Ollama API，Pod 从持久化卷加载模型，并由 Kubernetes 调度到具备目标 GPU 的节点。
正式部署前应确认三项基础条件：GPU 节点已安装对应驱动；集群已运行 NVIDIA、AMD 等厂商提供的 Device Plugin；节点状态中能够看到 nvidia.com/gpu 或 amd.com/gpu 等可分配资源。Kubernetes 对 GPU 设备插件及资源申请方式的说明可参考GPU 调度官方文档。
二、为 Ollama Pod 分配 GPU
以 NVIDIA GPU 为例，需要在容器资源限制中声明 nvidia.com/gpu: 1。GPU 与 CPU 的申请方式有所不同，通常应在 limits 中指定，Kubernetes 会据此完成设备分配。若同时设置 requests 和 limits，两者的 GPU 数量必须一致。
resources:
limits:
nvidia.com/gpu: 1
cpu: “8”
memory: “32Gi”
requests:
cpu: “4”
memory: “16Gi”
如果集群包含多种 GPU，可给节点添加型号、显存等级或用途标签，再通过 nodeSelector 或 nodeAffinity 精确调度。例如，将推理 Pod 限制到标有 accelerator=nvidia-l4 的节点，避免大模型误调度到显存不足的设备。对专用 GPU 节点设置 taint，并为 Ollama Pod 配置对应 toleration，还能防止普通工作负载占用昂贵资源。🎯
三、处理模型存储与启动流程
Ollama 默认通过 11434 端口提供 API，模型文件应挂载到持久化目录。若模型仅保存在容器可写层，Pod 重建后需要重新拉取，不仅延长启动时间，也会增加镜像仓库或外部网络压力。因此，建议使用 PVC 挂载 /root/.ollama，并根据存储环境选择云盘、节点本地 SSD 或共享文件系统。
模型准备可采用两种方式。第一种是在 initContainer 中执行模型拉取，确保主容器启动前文件已经就绪；第二种是由独立任务预热 PVC，再让多个推理 Pod 使用已准备好的模型。需要注意，并非所有存储都支持多节点同时读写，采用多副本部署时，应检查 StorageClass 的访问模式、吞吐能力和拓扑限制。
容器镜像、GPU 运行方式和硬件兼容范围可查阅Ollama 容器运行说明与Ollama GPU 支持文档。生产环境不建议长期使用浮动的 latest 标签，应固定经过验证的镜像版本，并在升级前完成模型加载、API 响应和 GPU 识别测试。
四、配置健康检查与服务暴露
Ollama Pod 启动后可能仍在加载模型，因此 readinessProbe 不宜只判断进程是否存在。可以先检测 11434 端口或 API，再结合业务侧预热请求确认模型可用。livenessProbe 应设置合理的初始延迟和失败阈值，避免大模型加载期间被错误重启。
- 集群内部调用：使用 ClusterIP Service，减少不必要的公网暴露。
- 外部系统访问：通过 Ingress 或 API Gateway 提供 TLS、鉴权、限流和审计。
- 高可用部署：配置多个副本、Pod 反亲和性以及 PodDisruptionBudget，降低单节点维护造成的中断风险。
五、不要只根据 CPU 使用率扩容
GPU 推理服务的瓶颈通常不是 CPU，因此仅依赖 CPU 指标可能出现请求已经排队、HPA 却没有扩容的情况。更合适的指标包括并发请求数、等待队列长度、首个 Token 延迟、请求持续时间、GPU 利用率和显存使用率。可通过 Prometheus Adapter 或其他自定义指标适配器，将这些指标提供给 HPA。
Kubernetes HPA 能依据资源指标、自定义指标或外部指标调整 Deployment 副本数，具体机制可参考HPA 官方文档。实践中可优先选择“每个 Pod 的排队请求数”作为扩容信号，同时用稳定窗口限制缩容速度，防止流量波动导致副本频繁增减。
建议策略：最少保留 1 至 2 个已预热副本；队列持续超过阈值时快速扩容；流量回落后延迟数分钟缩容；单次缩容只减少部分副本，避免模型反复卸载与加载。
六、Pod 扩容还要配合节点扩容
HPA 只能增加 Pod，无法凭空产生 GPU。如果集群没有空闲 GPU，新副本会一直处于 Pending 状态。因此还需要 Cluster Autoscaler、Karpenter 或云厂商节点自动伸缩能力，根据未调度 Pod 创建 GPU 节点。由于 GPU 节点启动、驱动初始化、镜像拉取和模型加载都需要时间，不能把节点扩容视为即时操作。
降低冷启动影响可从三个方向入手：预留少量 GPU 容量；使用体积更小且经过验证的模型；在节点镜像或本地缓存中预置常用依赖。对于稳定且持续的基础流量，可使用常驻副本承接；对于突发流量，再由弹性节点补充容量，这种组合往往比完全从零启动更可靠。⚙️
七、上线前的检查清单
- 确认 Pod 内可以识别 GPU，且推理过程中确实产生 GPU 使用量。
- 重建 Pod，验证模型文件不会丢失，并记录重新就绪所需时间。
- 执行并发压测，观察队列、延迟、显存及失败率，而不是只看吞吐量。
- 模拟 GPU 节点下线，检查 Pod 是否能重新调度及恢复服务。
- 验证 HPA 扩缩容、GPU 节点扩容和缩容保护是否形成完整闭环。
- 为 API 配置身份认证、流量限制、超时控制和敏感日志脱敏。
总结
Ollama 接入 Kubernetes 的关键，不只是写出一个能申请 GPU 的 Deployment，而是同时解决模型持久化、GPU 精确调度、服务就绪判断、自定义指标扩容和底层节点供给。建议先用单模型、单 GPU 和固定副本跑通链路，再逐步加入 HPA、节点自动扩容与多副本容灾。只有把冷启动时间、显存容量和真实请求队列纳入设计，才能构建成本可控、响应稳定且便于维护的 GPU 推理平台。✅
