Ollama在Kubernetes中的核心部署方案是通过创建StatefulSet配合持久化存储卷，将模型文件与容器状态解耦，从而实现高可用、可扩展且数据不丢失的私有化大模型服务集群。
将本地单机运行的Ollama迁移到K8s集群,并非简单的容器化打包，而是一场关于存储、网络和服务发现的架构升级，很多开发者在初次尝试Ollama K8s部署时，常因模型加载慢、显存溢出或配置丢失而受挫，业内专家指出，成功的K8s部署关键在于理解“有状态应用”的特性，Ollama本身是一个有状态服务，它需要读取庞大的模型权重文件，这些文件通常以GB甚至TB计，因此存储策略直接决定了部署的成败。
Ollama K8s部署核心架构解析
在深入代码之前,我们需要明确K8s环境下的Ollama运行逻辑，与无状态的Web服务不同，Ollama需要持久化模型数据，否则每次Pod重启都需要重新下载模型，这在生产环境中是不可接受的。
存储层：解决模型持久化难题
模型数据是Ollama的灵魂,在K8s中，我们通常使用PersistentVolumeClaim（PVC）来挂载模型目录。
本地存储 vs 网络存储的选择
- 本地存储（Local Path）：适用于开发测试或单机多节点场景，优势在于I/O性能极高，模型加载速度最快，劣势是节点故障时数据可能丢失，且跨节点迁移困难。
- 网络存储（NFS/Ceph/云盘）：适用于生产环境，优势在于数据共享和高可用，多个Pod可以挂载同一个PVC，实现模型共享，节省存储资源，劣势是网络延迟可能影响推理速度，需确保存储后端性能足够。
据行业共识认为,对于大多数中小规模部署，使用云厂商提供的块存储（如AWS EBS、阿里云云盘）作为PVC后端是性价比最高的选择，既保证了性能，又提供了快照备份能力。
计算层：GPU资源的调度与隔离
Ollama重度依赖GPU,在K8s中，必须正确配置资源请求（requests）和限制（limits），否则调度器无法正确分配节点。
- GPU调度器：确保集群安装了NVIDIA Device Plugin或AMD GPU Operator。
- 资源声明：在Deployment或StatefulSet中，明确指定
nvidia.com/gpu: 1。 - 显存预留：建议预留10%-20%的显存给系统和其他进程，避免OOM（Out of Memory）。
Ollama K8s部署实操步骤详解
理论框架搭建完毕后,让我们进入具体的实施阶段，以下流程基于标准的K8s环境，使用YAML配置文件进行部署。
第一步：创建持久化存储卷（PVC）
我们需要一个空间来存放下载的模型,创建一个名为ollama-pvc.yaml的文件。
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: ollama-pvc
namespace: default
spec:
accessModes:
- ReadWriteMany # 如果多副本共享模型，必须使用RWX
resources:
requests:
storage: 50Gi # 根据模型大小调整，LLaMA-3-70B需约140GB，建议预留足够空间
storageClassName: standard # 替换为你集群实际的StorageClass
应用该配置：kubectl apply -f ollama-pvc.yaml，这一步确保了即使Pod被销毁重建，模型文件依然保存在存储后端。
第二步：编写StatefulSet部署文件
StatefulSet是管理有状态应用的最佳实践,它保证了Pod的唯一标识和启动顺序，创建ollama-statefulset.yaml。
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: ollama-server
spec:
serviceName: "ollama"
replicas: 1 # 初期建议单副本，便于调试
selector:
matchLabels:
app: ollama
template:
metadata:
labels:
app: ollama
spec:
containers:
- name: ollama
image: ollama/ollama:latest
ports:
- containerPort: 11434
env:
- name: OLLAMA_HOST
value: "0.0.0.0" # 允许外部访问
- name: OLLAMA_MODELS
value: "/models"
resources:
requests:
memory: "8Gi"
cpu: "2"
nvidia.com/gpu: "1" # 申请一张GPU
limits:
memory: "16Gi"
cpu: "4"
nvidia.com/gpu: "1"
volumeMounts:
- name: ollama-storage
mountPath: /root/.ollama # Ollama默认模型路径
volumes:
- name: ollama-storage
persistentVolumeClaim:
claimName: ollama-pvc
第三步：暴露服务（Service）
为了让集群内外的应用能访问Ollama,需要创建一个Service。
apiVersion: v1
kind: Service
metadata:
name: ollama-service
spec:
selector:
app: ollama
ports:
- protocol: TCP
port: 11434
targetPort: 11434
type: ClusterIP # 生产环境建议结合Ingress或LoadBalancer
应用配置后,你可以通过kubectl get pods查看Pod状态，确保Running且Ready。
Ollama K8s部署常见问题与优化策略
部署完成只是开始,稳定性与性能优化才是长期运维的重点，许多用户关心Ollama K8s部署是否稳定，以及如何处理高并发请求。
模型加载速度慢的解决方案
首次启动时,Ollama会从Hub下载模型，在K8s环境中，如果多个Pod同时启动，会引发“惊群效应”，导致带宽拥堵。
- 预拉取镜像与模型：在CI/CD流水线中，提前在测试节点下载常用模型（如Llama3、Mistral），并将模型文件打包进Docker镜像或预置到PVC中。
- 使用Sidecar容器：可以编写一个Init Container，在主容器启动前检查模型是否存在，若不存在则异步下载，避免阻塞主服务启动。
多副本部署与负载均衡
当流量增大时,单副本Ollama难以承受，增加Replicas至3或5是常见做法。
- 共享模型存储：确保所有Pod挂载同一个
ReadWriteMany的PVC，这样只需下载一次模型，所有节点共享。 - 负载均衡：使用K8s Service的ClusterIP，后端会自动进行轮询负载均衡，对于更高性能需求，可引入Nginx Ingress Controller或专门的大模型网关（如vLLM Gateway）进行更细粒度的流量控制。
资源争抢与QoS保障
在共享GPU节点上,不同任务可能相互干扰。
- 设置资源Limit：严格限制CPU和Memory的Limit，防止某个Pod耗尽节点资源。
- GPU隔离：虽然Ollama默认独占GPU，但在K8s层面，确保没有其他高优先级Pod抢占GPU资源，可使用NodeSelector或Taints/Toleration将Ollama Pod调度到专用的GPU节点池。
Ollama K8s部署相关常见问题解答
Ollama在K8s中如何配置多GPU支持？
Ollama默认使用所有可用GPU,在K8s中，若节点有多张GPU，需在StatefulSet中设置nvidia.com/gpu的数量，若希望单个Pod使用2张GPU进行大模型推理，需将nvidia.com/gpu: 1改为nvidia.com/gpu: 2，并相应增加显存和内存的Requests/Limits，需确保容器内NVIDIA驱动和CUDA版本与Ollama镜像兼容。
Ollama K8s部署成本如何估算？
成本主要取决于GPU实例类型、存储容量和运行时长，以主流云厂商为例，一张A10G GPU实例每小时费用约在几元到十几元人民币不等，具体价格因地域和计费模式（包月/按量）而异，存储方面，50GB的高速云盘每月费用通常在几十元，相比本地购买硬件，K8s弹性伸缩优势明显，闲时可缩容至0，仅保留存储，大幅降低闲置成本。
如何监控Ollama K8s集群的健康状态？
推荐使用Prometheus + Grafana栈，Ollama本身暴露了/metrics接口，可通过ServiceMonitor自动抓取，关键监控指标包括：GPU利用率、显存占用、请求延迟（Latency）、每秒请求数（QPS）以及Pod重启次数，配置Alertmanager告警，当GPU显存使用率超过90%或Pod频繁重启时，及时通知运维人员介入处理。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/399281.html
