Kubernetes上部署Ollama：Helm Chart详解与GPU配置实战

1. 项目概述在Kubernetes上部署Ollama的Helm Chart如果你正在寻找一种标准化的、可重复的方式来在Kubernetes集群中部署和管理Ollama那么otwld/ollama-helm这个社区维护的Helm Chart绝对值得你花时间研究。Ollama本身已经极大地简化了在本地运行大型语言模型LLM的流程但当你需要将其集成到生产级的容器化环境中尤其是在需要GPU加速、高可用性或与现有CI/CD流水线结合时手动编写和维护一堆Kubernetes YAML文件很快就会变得繁琐且容易出错。这个Helm Chart的核心价值就是将这些部署细节抽象化、模板化让你通过一份values.yaml配置文件就能轻松完成从基础CPU部署到复杂GPU集群、甚至Knative无服务器架构的Ollama服务搭建。简单来说它解决了几个关键痛点环境标准化确保开发、测试、生产环境一致、配置即代码所有参数从模型列表到资源限制都通过版本控制的配置文件管理、以及运维自动化一键安装、升级、回滚。无论你是想在自己的实验室集群里快速搭建一个AI模型服务供内部调用还是计划构建一个面向多团队的多模型服务平台这个Chart都提供了一个坚实的起点。接下来我将结合自己多次部署和调优的经验为你拆解这个Chart的核心设计、关键配置以及那些官方文档可能没细说的“踩坑”细节。2. 核心设计思路与架构解析2.1 为什么选择Helm来部署Ollama在深入Chart细节之前我们先聊聊“为什么是Helm”。Ollama的Docker镜像本身确实可以docker run一键启动但在Kubernetes生态中一个生产就绪的服务远不止一个Pod。你需要考虑服务发现Service、配置管理ConfigMap/Secret、存储卷PersistentVolume、自动扩缩容HPA、网络策略Ingress等等。手动组合这些资源定义不仅工作量大升级和回滚更是噩梦。Helm作为Kubernetes的包管理器通过“Chart”这个概念将所有这些相关的Kubernetes资源打包在一起。otwld/ollama-helm这个Chart预先定义了Ollama服务所需的完整资源拓扑。它的设计思路非常清晰提供最大程度的灵活性同时覆盖最常见的用例。例如它通过values.yaml中的开关让你可以轻松在“传统DeploymentService”模式和“Knative Service”模式之间切换通过结构化的配置块来管理GPU资源申请、模型预加载、健康检查等复杂功能。这种设计意味着你不需要成为Kubernetes专家也能通过修改几个直观的配置项部署出一个健壮的Ollama服务。2.2 Chart的两种核心运行模式剖析这个Chart最巧妙的设计之一是同时支持两种差异巨大的运行模式这直接对应了不同的应用场景和基础设施能力。2.2.1 传统Deployment模式默认这是最常用、最经典的模式。Chart会为你创建以下Kubernetes资源一个Deployment定义了Ollama应用的Pod模板包括容器镜像、环境变量、资源请求/限制、存储卷挂载等。一个Service为Ollama的API端口默认11434提供稳定的集群内部访问域名。可选的Ingress如果你配置了ingress.enabledtrueChart会创建Ingress资源将服务暴露到集群外部。可选的PersistentVolumeClaim (PVC)用于持久化存储模型文件避免Pod重启后模型丢失。这种模式适合需要长时间运行、稳定服务的场景。你可以结合autoscaling配置实现基于CPU/内存的自动扩缩容也可以利用nodeSelector或affinity将Pod调度到带有特定标签如拥有GPU的节点上。它的行为是可预测的Pod会持续运行直到你手动删除或更新部署。2.2.2 Knative Serving模式当knative.enabledtrue时Chart的部署逻辑会发生根本性变化。它不再创建Deployment和Service而是生成一个KnativeService资源。Knative是构建在Kubernetes之上的无服务器Serverless框架。在此模式下按需伸缩当没有API请求时Ollama的Pod可以缩容到零不占用任何计算资源尤其是宝贵的GPU。当请求到来时Knative会自动快速扩容出Pod来处理。请求驱动非常适合间歇性、突发性的模型调用场景。例如一个内部工具偶尔需要调用LLM进行文本摘要或者一个批处理任务每天只运行几次。冷启动与模型加载这是Knative模式下的关键挑战。Ollama模型动辄数GB冷启动时从零加载模型会导致首次请求响应极慢。为此Chart引入了一个独立的bootstrap Job。这个Job会在部署或升级时运行负责将ollama.models.pull中指定的模型预先拉取并存储到持久化卷中。当Knative Service的Pod启动时就可以直接从卷中加载模型大大缩短冷启动时间。选择哪种模式取决于你的流量模式和对成本/延迟的权衡。持续高负载选Deployment间歇性负载且追求资源利用率选Knative。2.3 模型生命周期管理的设计哲学Ollama的核心是模型因此这个Chart在模型管理上花了大量心思其设计涵盖了模型从获取到运行的全生命周期预拉取通过ollama.models.pull列表在Pod启动初期或bootstrap Job中从Ollama官方仓库下载模型。这是保证服务可用性的关键一步。定制创建通过ollama.models.create支持基于现有模型创建自定义变体。例如修改llama3.1的上下文长度num_ctx。这既可以直接内联template定义也可以引用预先存储在ConfigMap中的复杂模板实现了模型配置的代码化。预热加载通过ollama.models.run在启动时将指定模型加载到GPU内存中。对于高频使用的核心模型预热能消除首次推理的延迟提升用户体验。但这会持续占用GPU显存需要根据显存大小谨慎选择。自动清理通过ollama.models.clean: true可以自动删除持久化卷中存在但未在pull列表中声明的模型。这有助于控制存储成本避免无用模型堆积但操作前务必确认以防误删。这套组合拳让你能精细地控制模型在集群内的状态平衡了启动速度、运行时性能和存储开销。3. 关键配置详解与实操要点3.1 GPU支持的配置与深层原理在Kubernetes中使用GPU尤其是混合了NVIDIA和AMD硬件的环境一直是个有挑战性的任务。这个Chart通过ollama.gpu配置块对此进行了良好的抽象。3.1.1 NVIDIA GPU的标准配置对于最常见的NVIDIA GPU配置相对直接ollama: gpu: enabled: true type: nvidia number: 1 # nvidiaResource: nvidia.com/gpu # 默认值申请整卡enabled和type是必须的。number指定申请的GPU卡数量。Pod会通过Kubernetes的resources.limits自动申请对应数量的nvidia.com/gpu资源。背后依赖你的Kubernetes集群必须已安装NVIDIA Device Plugin。这个DaemonSet负责在节点上发现GPU并将其作为可调度资源上报给API Server。没有它Pod调度会失败。3.1.2 NVIDIA MIG (Multi-Instance GPU) 配置对于A100、H100等支持MIG的显卡你可以将一块物理GPU划分为多个更小的、隔离的实例。Chart对此也有支持ollama: gpu: enabled: true type: nvidia mig: enabled: true devices: mig-1g.10gb: 2 # 申请两个 1g.10gb 规格的MIG实例当mig.enabledtrue时number参数会被忽略。devices字段是一个映射键是MIG实例规格如mig-1g.10gb值是需要申请的数量。关键点你需要将nvidiaResource设置为对应的MIG资源名。但根据Chart的默认逻辑当使用MIG时它可能不会自动修改nvidiaResource。一个更稳妥的做法是显式指定ollama: gpu: enabled: true type: nvidia nvidiaResource: nvidia.com/mig-1g.10gb # 明确指定资源类型 number: 2 # 申请两个该类型的实例实操心得MIG的配置强烈依赖于节点管理员对GPU的预先划分。在部署前务必与集群管理员确认可用的MIG实例规格和名称。错误资源名会导致Pod无法调度。3.1.3 AMD GPU配置对于AMD GPU如MI系列配置需要稍作调整ollama: gpu: enabled: true type: amd # 关键类型改为amd当type设置为amd且未手动指定image.tag时Chart会自动为镜像标签添加-rocm后缀例如使用ollama/ollama:latest-rocm。这是因为Ollama为CUDANVIDIA和ROCmAMD提供了不同的基础镜像。背后依赖集群需要安装AMD GPU Device Plugin或通过Kubernetes Device Plugin Framework暴露AMD GPU资源。资源名称通常是amd.com/gpu或rocm.amd.com/gpu具体取决于插件实现。Chart目前可能默认使用amd.com/gpu如果遇到调度问题可能需要通过extraArgs或修改Chart模板来调整资源请求。重要提示正如项目README所警告Ollama对AMD GPU的支持仍在持续完善中并非所有型号都能获得稳定支持。部署前强烈建议在目标显卡型号和驱动版本上进行小范围测试。3.1.4 新兴的DRA (Dynamic Resource Allocation) 模式Kubernetes 1.26引入了一种更灵活的GPU管理方式——DRA。它允许更细粒度的资源分配和共享。Chart通过ollama.gpu.draEnabled提供了实验性支持。ollama: gpu: enabled: true draEnabled: true draDriverClass: gpu.nvidia.com # 驱动类名 # draExistingClaimTemplate: my-gpu-claim-template # 可选使用已存在的ResourceClaimTemplateDRA模式下Pod不再直接请求nvidia.com/gpu而是创建一个ResourceClaim由特定的驱动控制器来动态分配GPU资源。这为未来实现GPU时间片共享、虚拟化等功能奠定了基础。但目前截至我撰写时DRA及其相关驱动如NVIDIA DRA Driver仍处于早期阶段生产环境使用需要评估稳定性和生态工具链的支持情况。注意事项无论使用哪种GPU模式都必须确保Pod被调度到拥有相应GPU资源的节点上。通常需要配合nodeSelector使用例如nodeSelector: { accelerator: nvidia-tesla-v100 }。同时GPU节点的Docker或Container运行时需要配置为使用nvidia-container-runtime。3.2 模型管理的进阶用法基础的pull列表很简单但create和run的用法蕴含着更大的灵活性。3.2.1 从ConfigMap创建复杂模型当你的模型ModelfileOllama的模型定义文件非常复杂包含多个FROM、ADAPTER、TEMPLATE等指令时内联在values.yaml里会难以维护。这时可以将其存储在ConfigMap中。# 首先创建一个ConfigMap kubectl create configmap my-llama-modelfile --from-fileModelfile./path/to/my-llama-modelfile.txt # 在values.yaml中引用 ollama: models: create: - name: my-custom-llama configMapRef: my-llama-modelfile configMapKeyRef: Modelfile # 对应ConfigMap中的键名Chart会将这个ConfigMap作为卷挂载到Pod的/models目录下然后在启动时执行ollama create my-custom-llama -f /models/Modelfile。优势实现了模型配置与部署配置的分离便于单独管理和版本控制。你可以用Git管理一堆Modelfile用CI流程生成ConfigMap。3.2.2run的陷阱与显存管理run指令非常强大它让模型在启动后就常驻GPU内存。但这把双刃剑需要小心使用。ollama: models: pull: - llama3.1:8b - qwen2.5:7b run: - llama3.1:8b # 仅预热这一个模型假设llama3.1:8b需要16GB显存qwen2.5:7b需要14GB。如果你在run列表中同时写上这两个Pod启动时就会尝试加载总计约30GB的模型到显存中。如果节点只有一张24GB的卡Pod会因为OOM内存不足而启动失败。最佳实践只为最核心、调用最频繁、且对延迟极度敏感的模型配置run。对于其他模型采用“按需加载”策略即通过API调用时Ollama会自动从磁盘加载到显存。这要求你的应用能容忍模型首次调用的额外延迟。监控建议部署后使用kubectl top pod或集群监控系统如Prometheus密切关注Pod的显存使用量确保其稳定在安全水位线下。3.2.3 理解clean操作的风险ollama.models.clean: true是一个“破坏性”操作。它会在每次Pod启动或bootstrap Job运行时检查持久化卷中的模型文件并删除那些不在当前pull列表中的模型。使用场景适用于模型版本迭代快速的实验环境或者存储空间极其紧张的情况。巨大风险如果你不小心从pull列表中移除了一个模型比如打错了名字或者临时注释掉某行进行测试下次部署时这个模型文件就会被永久删除。恢复可能需要重新下载数十GB数据。避坑指南在values.yaml中为clean配置添加明确的注释提醒团队成员。考虑在生产环境中默认关闭clean采用手动或通过脚本定期清理陈旧模型的方式。务必对持久化卷进行定期备份例如使用Velero以防误删。3.3 存储与持久化卷配置模型文件体积巨大因此持久化存储是生产部署的必选项。Chart通过persistentVolume配置块来管理。3.3.1 动态Provisioning与静态ProvisioningpersistentVolume: enabled: true accessModes: - ReadWriteOnce size: 100Gi storageClassName: fast-ssd # 指定StorageClass # existingClaim: # 如果使用已有PVC则填写其名称并忽略以上参数动态Provisioning默认当existingClaim为空时Chart会创建一个PersistentVolumeClaim。Kubernetes集群会根据storageClassName找到对应的StorageClass并动态地创建一个PersistentVolumePV与之绑定。这是最方便的方式但要求集群管理员已配置好可用的StorageClass。静态Provisioning如果你已经有一个现成的PV比如手动创建的NFS卷可以先将这个PV绑定到一个手动创建的PVC例如ollama-data-pvc然后在Chart中设置persistentVolume.enabled: true和persistentVolume.existingClaim: ollama-data-pvc。这样Chart就会直接使用这个已有的PVC而不会创建新的。3.3.2 存储性能考量存储类型模型加载是IO密集型操作尤其是从冷启动加载大模型时。SSD存储无论是云盘还是本地盘是强烈推荐的选择。使用HDD可能会导致模型加载时间长达数分钟严重影响服务响应速度。容量规划size需要仔细规划。考虑所有计划部署的模型大小之和并预留至少30%的缓冲空间用于未来模型更新和临时文件。例如部署3个约30GB的模型建议设置size: 150Gi。访问模式Ollama Pod通常以ReadWriteOnce模式运行一个卷只能被一个节点读写。即使在多副本部署中每个Pod也需要自己独立的卷副本或者使用支持ReadWriteMany的共享存储如NFS、CephFS但共享存储可能带来性能瓶颈和锁的问题需要测试。3.3.3 Knative模式下的存储特殊性在Knative模式下persistentVolume.enabled必须为true。这是因为bootstrap Job和实际服务的Pod需要共享同一个卷来传递模型文件。同时如README所述你的Knative Serving必须启用特定的feature flags来支持PVC挂载。这是一个容易忽略的配置项务必在部署前通过kubectl get configmap/config-features -n knative-serving -o yaml命令确认kubernetes.podspec-persistent-volume-claim等特性已启用。4. 完整部署流程与实战示例4.1 基础环境准备与前置检查在运行helm install之前花10分钟做好以下检查能避免90%的部署失败。Kubernetes集群版本确认集群版本符合要求。对于GPU支持强烈建议使用1.26或更高版本以获得更稳定的设备插件和DRA支持。Helm客户端版本使用Helm 3.x。可通过helm version检查。GPU节点准备如需要NVIDIA确保节点已安装NVIDIA驱动、nvidia-container-toolkit并且nvidia-device-pluginDaemonSet正在运行。可以运行kubectl get nodes -o json | jq .items[].status.allocatable查看节点是否上报了nvidia.com/gpu资源。AMD确保安装了相应的ROCm驱动和AMD设备插件。存储类运行kubectl get storageclass确认有可用的默认StorageClass或者记下你计划使用的StorageClass名称。Ingress Controller如需要外部访问确认集群已安装Ingress Controller如Nginx Ingress、Traefik等。4.2 分步部署从开发到生产我们以一个典型的、从简单到复杂的部署流程为例。步骤一添加Helm仓库并查看Chart# 添加OTWLD的Helm仓库注意已从旧地址迁移到新地址 helm repo add otwld https://helm.otwld.com/ helm repo update # 搜索并查看Chart详情 helm search repo otwld/ollama helm show values otwld/ollama values-basic.yaml步骤二创建基础开发环境配置创建一个values-dev.yaml文件用于在开发集群快速启动一个CPU版本的Ollama。# values-dev.yaml # 基础开发配置无GPU仅拉取一个小模型 ollama: # GPU未启用 gpu: enabled: false # 拉取一个较小的模型加快启动速度 models: pull: - llama3.2:1b # 1B参数的小模型适合测试 # 资源限制避免占用过多集群资源 resources: requests: memory: 2Gi cpu: 500m limits: memory: 4Gi cpu: 1 # 启用Ingress方便通过浏览器或curl测试假设有ingress controller ingress: enabled: true className: nginx # 根据你的Ingress Controller修改 hosts: - host: ollama-dev.yourcompany.com paths: - path: / pathType: Prefix # 持久化存储使用默认的StorageClass persistentVolume: enabled: true size: 20Gi # 开发环境小容量即可执行安装helm install ollama-dev otwld/ollama -n ollama --create-namespace -f values-dev.yaml安装后通过kubectl get pods -n ollama -w观察Pod状态直到变为Running。然后就可以通过http://ollama-dev.yourcompany.com访问API了。步骤三创建生产环境GPU配置创建一个更复杂的values-prod.yaml面向生产环境。# values-prod.yaml # 生产环境配置启用GPU预加载核心模型 ollama: gpu: enabled: true type: nvidia number: 1 # 假设每个Pod分配一张A100 # 如果使用MIG可以这样配置 # mig: # enabled: true # devices: # mig-1g.10gb: 2 # nvidiaResource: nvidia.com/mig-1g.10gb models: pull: - llama3.1:8b - qwen2.5:7b - gemma2:9b # 仅预热最核心的模型避免显存溢出 run: - llama3.1:8b # 生产环境谨慎开启clean或设置为false clean: false # 可选覆盖Ollama数据挂载路径通常不需要改 # mountPath: /ollama-data # 资源配置根据模型大小和并发需求调整 resources: requests: memory: 32Gi # 预留足够内存 cpu: 2 nvidia.com/gpu: 1 # 必须与ollama.gpu.number匹配 limits: memory: 64Gi cpu: 4 nvidia.com/gpu: 1 # 副本数与自动扩缩容 replicaCount: 2 autoscaling: enabled: true minReplicas: 2 maxReplicas: 10 targetCPUUtilizationPercentage: 70 # 基于CPU使用率扩容 # 节点亲和性将Pod调度到带GPU的节点 nodeSelector: accelerator: nvidia-a100 # 或使用更复杂的亲和性/反亲和性规则 # affinity: # nodeAffinity: # requiredDuringSchedulingIgnoredDuringExecution: # nodeSelectorTerms: # - matchExpressions: # - key: accelerator # operator: In # values: # - nvidia-a100 # 持久化存储大容量高性能SSD persistentVolume: enabled: true accessModes: - ReadWriteOnce size: 500Gi storageClassName: gp3-ssd # 示例AWS gp3 StorageClass # 更严格的健康检查 livenessProbe: enabled: true initialDelaySeconds: 120 # 给模型加载留足时间 periodSeconds: 20 timeoutSeconds: 10 failureThreshold: 3 readinessProbe: enabled: true initialDelaySeconds: 120 periodSeconds: 10 timeoutSeconds: 5 failureThreshold: 3 # 不直接对外暴露通过ClusterIP在集群内访问 service: type: ClusterIP # ingress.enabled: false执行生产部署或升级# 首次安装 helm install ollama-prod otwld/ollama -n ollama-prod --create-namespace -f values-prod.yaml # 后续升级 helm upgrade ollama-prod otwld/ollama -n ollama-prod -f values-prod.yaml步骤四验证部署部署完成后进行全方位验证Pod状态kubectl get pods -n ollama-prod应显示所有Pod为Running且READY。模型加载查看Pod日志确认模型拉取和预热成功。kubectl logs -n ollama-prod deployment/ollama-prod -c ollama --tail50你应该能看到类似pulling manifest,creating model,success的日志。API访问在集群内创建一个临时Pod进行API测试。kubectl run curl-test --imagecurlimages/curl -n ollama-prod -it --rm --restartNever --command -- sh # 进入容器后执行 curl http://ollama-prod.ollama-prod.svc.cluster.local:11434/api/tags应返回已加载模型的JSON列表。GPU资源检查Pod是否成功分配到GPU。kubectl describe pod -n ollama-prod pod-name | grep -A 5 -B 5 Limits在Limits部分应看到nvidia.com/gpu: 1。存储检查PVC是否绑定成功。kubectl get pvc -n ollama-prod4.3 与现有生态集成示例4.3.1 集成LangChainOllama是LangChain支持的本地模型运行器之一。在LangChain中配置非常简单# Python LangChain示例 from langchain_community.llms import Ollama llm Ollama( base_urlhttp://ollama-prod.ollama-prod.svc.cluster.local:11434, # Kubernetes Service地址 modelllama3.1:8b ) response llm.invoke(Hello, how are you?) print(response)确保你的应用Pod与Ollama服务在同一个Kubernetes集群内或者网络可达。4.3.2 通过Ingress暴露并配置域名如果你需要从集群外部访问例如给前端应用调用配置Ingress是标准做法。以下是一个使用Nginx Ingress并配置TLS的示例# 在values-prod.yaml的ingress部分补充 ingress: enabled: true className: nginx annotations: cert-manager.io/cluster-issuer: letsencrypt-prod # 使用cert-manager自动签发证书 nginx.ingress.kubernetes.io/proxy-body-size: 100m # 允许大请求体用于长上下文 hosts: - host: ai-api.yourcompany.com paths: - path: / pathType: Prefix tls: - hosts: - ai-api.yourcompany.com secretName: ollama-tls-secret # cert-manager会自动创建此Secret部署后你就可以通过https://ai-api.yourcompany.com安全地访问Ollama API。5. 常见问题排查与运维技巧5.1 部署与启动问题问题1Pod一直处于Pending状态。可能原因A资源不足。Pod请求的CPU、内存或GPU资源集群中没有节点能满足。排查kubectl describe pod pod-name查看Events部分通常会有Insufficient cpu/memory/nvidia.com/gpu的提示。解决调整resources.requests为更小的值或向集群添加更多/更大规格的节点。可能原因BPVC无法绑定。指定的storageClassName不存在或者动态provisioner失败。排查kubectl describe pvc pvc-name查看事件。解决检查kubectl get storageclass使用正确的名称。或者改用existingClaim指向一个已存在的、状态为Bound的PVC。可能原因C节点选择器/亲和性规则无法满足。例如nodeSelector指定了不存在的节点标签。排查kubectl describe pod的Events和kubectl get nodes --show-labels。解决修正nodeSelector或affinity配置或给目标节点打上相应标签。问题2Pod启动失败进入CrashLoopBackOff状态。可能原因A镜像拉取失败。网络问题或镜像标签不存在特别是AMD GPU时自动添加-rocm后缀可能出错。排查kubectl describe pod查看Eventskubectl logs --previous查看上一次崩溃的日志。解决检查网络连通性。对于AMD可以尝试在values.yaml中显式指定一个已知可用的带-rocm标签的镜像如image.tag: latest-rocm。可能原因B模型拉取或创建失败。网络超时、模型名错误、或Modelfile语法错误。排查kubectl logs查看Ollama容器的详细日志。错误信息通常会明确指出是网络错误、模型未找到还是模板解析失败。解决确保模型名称正确可去Ollama官网查询。检查内联或ConfigMap中的Modelfile语法。对于网络问题考虑配置镜像加速或使用离线私有镜像仓库。可能原因CGPU驱动或库问题。在GPU节点上容器内缺少必要的CUDA/ROCm库。排查日志中可能出现CUDA driver version is insufficient或Failed to initialize ROCm等错误。解决确保节点驱动版本与Ollama镜像内预期的版本兼容。可能需要尝试不同版本的Ollama镜像。问题3服务无法通过Ingress访问。可能原因AIngress Controller未就绪或配置错误。排查kubectl get ingress查看ADDRESS字段是否为空。kubectl describe ingress查看事件。解决确认Ingress Controller Pod正在运行。检查ingress.className是否与Controller匹配。可能原因BService端口或Selector不匹配。排查Chart生成的Service名称默认为release-name。检查Ingress中backend.service.name和port.number是否正确指向了该Service和端口11434。解决通常Chart会自动配置正确但如果自定义了fullnameOverride或service.port需要确保Ingress配置同步更新。5.2 运行时性能问题问题4模型推理速度慢首次调用延迟极高。可能原因A模型未预热。首次调用需要从磁盘加载模型到显存。解决将高频使用的模型添加到ollama.models.run列表中进行预热。但需权衡显存占用。可能原因B存储IO性能瓶颈。模型文件存储在慢速磁盘如HDD上。排查监控Pod所在节点的磁盘IO使用率。解决使用高性能SSD存储类。在云环境中选择 provisioned IOPS 的云盘。可能原因C节点资源竞争。节点上运行了其他高负载应用。解决通过resources.limits为Ollama Pod保证最低资源。使用nodeSelector/affinity/toleration将其调度到专用节点。问题5服务运行一段时间后OOM内存不足被杀死。可能原因Arun了过多模型显存耗尽。解决减少run列表中的模型或升级到显存更大的GPU。可能原因B并发请求过多加载了多个模型实例。Ollama本身会管理模型在内存中的实例但高并发下内存压力增大。解决调整Pod的resources.limits.memory到一个更高的值。考虑水平扩容增加replicaCount来分担负载。可能原因C内存泄漏。可能是Ollama特定版本或某个模型的bug。排查观察内存使用量是否随时间持续增长即使在没有请求的情况下。解决升级Ollama到最新版本。如果问题由特定模型触发尝试更换模型。为Pod配置livenessProbe和readinessProbe使其在异常时能自动重启。5.3 运维与升级问题6如何安全地升级Chart或Ollama版本备份如果开启了持久化卷确保有备份例如对PVC进行快照。查阅Release Notes始终先查看Ollama官方和此Helm Chart的Release Notes了解破坏性变更。例如从Chart的0.x升级到1.xollama.models的结构就发生了变化。小范围测试先在开发或测试命名空间进行升级验证核心功能。执行升级helm repo update helm upgrade release-name otwld/ollama -n namespace -f values.yaml观察密切监控Pod滚动更新状态和日志确保新版本稳定。回滚计划如果升级失败使用helm rollback release-name revision-number快速回退。问题7如何查看和管理已拉取的模型Ollama API提供了相关端点你可以通过端口转发或Ingress访问# 端口转发到本地 kubectl port-forward svc/service-name -n namespace 11434:11434 # 然后在另一终端查询 curl http://localhost:11434/api/tags要删除模型需要通过API发起删除请求或者手动清理持久化卷中的文件不推荐直接操作卷。问题8如何实现多租户或模型隔离单一的Ollama实例所有模型共享内存和计算资源。如果需要强隔离方案A部署多个Release。为不同团队或项目创建不同的Helm Release例如ollama-team-a,ollama-team-b每个Release有独立的Deployment、Service和PVC。通过资源配额ResourceQuota限制每个团队的用量。方案B使用命名空间隔离。在不同的Kubernetes命名空间中部署独立的Ollama实例。这是最清晰的隔离方式。方案C等待Ollama多模型服务特性成熟。Ollama团队可能在未来提供更原生的多模型管理和隔离功能。这个otwld/ollama-helmChart将部署一个生产可用的Ollama服务从一项复杂的工程任务简化成了配置管理。它覆盖了从资源申请、模型预热、健康检查到外部暴露的完整链路。最关键的是理解其设计模式传统vs Knative和核心配置项GPU、模型、存储之间的联动关系。在实际操作中我建议从一个最简单的CPU配置开始逐步叠加GPU、模型预热、Ingress等特性每步都做好验证。这样能最清晰地定位问题所在。对于生产环境务必仔细规划存储、资源限制和监控告警毕竟这些动辄数十GB的模型无论是存储成本还是计算成本都不是小数目。