vLLM Helm Chart 深度解析用 chart-helm 在 Kubernetes 上部署 vLLM 推理服务【免费下载链接】vllmA high-throughput and memory-efficient inference and serving engine for LLMs项目地址: https://gitcode.com/GitHub_Trending/vl/vllm本篇基于仓库中的 Helm Charts 说明文档 展开讲解 vLLM 官方示例中chart-helm目录下的 Helm Chart 如何把 vLLM 服务部署到 Kubernetes涵盖默认值配置镜像、资源、探针、HPA、S3 模型预下载机制Job init 容器、各类 K8s 对象的模板渲染逻辑以及如何用 helm-unittest 对 Chart 进行单元测试。读完后可独立修改values.yaml完成一次可运行的 vLLM 推理服务发布并理解每个模板文件对应的 K8s 资源及其生效条件。Chart 元数据与目录结构Chart 的元信息定义在 Chart.yaml 中apiVersion: v2 name: chart-vllm description: Chart vllm type: application version: 0.0.2 maintainers: - name: mfournioux要点type: application表明这是一个应用 Chart而非提供模板函数的 library Chart可直接helm install部署version: 0.0.2遵循语义化版本每次修改 Chart 或模板都应递增名称为chart-vllmmaintainer 为mfournioux。按 README 的说明该目录包含一个用于部署 vllm 应用的 Helm Chart内置了部署、自动扩缩容、资源管理等配置能力。完整文件清单如下均在 chart-helm 目录 下文件作用Chart.yamlChart 元数据名称、版本、维护者ct.yamlchart-testing 配置chart-dirs: [charts]、validate-maintainers: falselintconf.yamlYAML 文件的 Lint 规则values.schema.json用于校验values.yaml的 JSON Schemavalues.yamlChart 默认值templates/_helpers.tpl公共模板片段端口、命名、策略、探针、资源等templates/deployment.yamlDeployment 模板核心templates/service.yamlService 模板ClusterIPtemplates/hpa.yamlHorizontalPodAutoscaler 模板templates/job.yaml模型下载 Job 模板templates/pvc.yaml模型存储 PVC 模板templates/secrets.yamlS3 凭据等 Secret 模板templates/configmap.yaml环境变量 ConfigMap 模板templates/custom-objects.yaml渲染用户自定义 K8s 对象templates/poddisruptionbudget.yamlPod 扰动预算模板tests/helm-unittest 单元测试deployment/hpa/job/pvc/service 五套注意values.schema.json的存在Helm 在install/upgrade/template时会自动用它校验用户传入的 values缺必填字段会直接报错这是本 Chart 防止误配置的第一道防线。values.yaml 默认值逐项解析values.yaml 是整个 Chart 的“总开关”每个字段都有# --形式的注释即 helm-docs 风格供生成文档。下面按分组完整解析。镜像与启动命令imageimage: repository: vllm/vllm-openai tag: latest command: [vllm, serve, /data/, --served-model-name, opt-125m, --enforce-eager, --dtype, bfloat16, --block-size, 16, --host, 0.0.0.0, --port, 8000]默认使用vllm/vllm-openai官方镜像容器内直接运行vllm serve启动 OpenAI 兼容 API 服务command会被 deployment.yaml 模板 原样注入容器的command字段等价于替换容器 entrypoint——因此所有 vLLM 引擎参数如--tensor-parallel-size、量化选项等都可以通过覆盖该列表来传递默认命令中模型路径为/data/这与 Chart 的 PVC 挂载路径严格对应见下文“模型存储”一节。opt-125m、--enforce-eager等只是小模型演示配置生产环境应替换为自己的模型目录与参数按 values.schema.json 校验image.command、image.repository、image.tag三者均为必填项。端口、副本与 ServicecontainerPort: 8000 serviceName: # 留空则默认渲染为 release-service servicePort: 80 extraPorts: [] replicaCount: 1 deploymentStrategy: {}containerPort默认 8000与vllm serve --port 8000对应helpers 模板 中定义其为端口名container-port对应的端口值servicePort默认 80即 Service 对外暴露 80 端口并转发到容器的container-port命名端口见 service.yaml 模板固定type: ClusterIP、TCP 协议serviceName留空时helper 会生成release-service作为 Service 名deploymentStrategy留空时_helpers.tpl 提供默认的rollingUpdate: maxSurge: 100%, maxUnavailable: 0策略——对推理服务而言这是合理的滚动更新期间新旧副本并存不会因缩容导致服务中断Deployment 的progressDeadlineSeconds在 deployment.yaml 中硬编码为 1200 秒给大模型加载留出充足的启动时间。资源与 GPU 调度resources / gpuModelsresources: requests: cpu: 4 memory: 16Gi nvidia.com/gpu: 1 limits: cpu: 4 memory: 16Gi nvidia.com/gpu: 1 gpuModels: - TYPE_GPU_USED从 helpers 的资源模板 看resources.requests.memory、cpu以及limits侧对应项均使用required强制定义缺失会导致渲染直接失败GPU 请求仅在requests与limits中nvidia.com/gpu均大于 0 时才会被写入二者必须成对出现当 GPU 数量大于 0 时deployment.yaml 会自动为 Pod 追加三件事runtimeClassName: nvidia启用 NVIDIA 容器运行时节点亲和性requiredDuringSchedulingIgnoredDuringExecution按nvidia.com/gpu.product节点标签匹配gpuModels列表默认占位符为TYPE_GPU_USED部署前必须替换为实际 GPU 型号如NVIDIA-H100由此推断该机制用于把 vLLM Pod 固定调度到指定型号的 GPU 节点避免模型与硬件不匹配。自动扩缩容autoscalingautoscaling: enabled: false minReplicas: 1 maxReplicas: 100 targetCPUUtilizationPercentage: 80 # targetMemoryUtilizationPercentage: 80对应 hpa.yaml 模板仅当autoscaling.enabled: true时渲染autoscaling/v2的HorizontalPodAutoscalerscaleTargetRef指向chart.deployment-name即release-deployment-vllm。CPU 与内存两个指标是独立开关设置了targetCPUUtilizationPercentage就加入 CPU 指标取消注释targetMemoryUtilizationPercentage则同时加入内存指标。需要注意 HPA 依据的是资源利用率对以 GPU 吞吐为主要瓶颈的推理负载通常需要配合自定义指标方案Chart 本身只提供 CPU/内存两种内置指标。模型存储与 S3 下载extraInit这是该 Chart 最具特色的部分用于解决“镜像里不带权重Pod 启动前先下载模型”的问题extraInit: modelDownload: enabled: true image: repository: amazon/aws-cli tag: 2.6.4 pullPolicy: IfNotPresent waitContainer: command: [/bin/bash] args: - -eucx - while aws --endpoint-url $S3_ENDPOINT_URL s3 sync --dryrun s3://$S3_BUCKET_NAME/$S3_PATH /data | grep -q download; do sleep 10; done # env: # 可选若指定则完全覆盖默认 S3 环境 # - name: HUGGING_FACE_HUB_TOKEN # value: your-token # - name: MODEL_ID # value: meta-llama/Llama-2-7b downloadJob: command: [/bin/bash] args: - -eucx - aws --endpoint-url $S3_ENDPOINT_URL s3 sync s3://$S3_BUCKET_NAME/$S3_PATH /data # env: # 同上可选 initContainers: [] # 自定义 init 容器追加在 wait-download-model 之后 s3modelpath: relative_s3_model_path/opt-125m pvcStorage: 1Gi awsEc2MetadataDisabled: true工作机制结合 job.yaml、pvc.yaml 与 deployment.yamlPVC只要extraInit存在就创建名为release-storage-claim的 PVCReadWriteOnce容量由pvcStorage指定默认 1Gi生产请按模型大小调整。该卷被 Job、init 容器与主容器三方挂载到/data是三者共享模型文件的关键。下载 Jobrelease-init-vllm由downloadJob.commandargs执行aws s3 sync s3://$S3_BUCKET_NAME/$S3_PATH /data把 S3 上的权重同步到 PVCrestartPolicy: OnFailure失败自动重试ttlSecondsAfterFinished: 100让 Job 完成后自动清理。等待 init 容器wait-download-model主容器启动前先跑这个轻量 bash 循环——每 10 秒执行一次aws s3 sync --dryrun只模拟不落盘只要输出中还有download字样说明同步未完成就继续等待直到 Job 完成才放行 vLLM 主容器。这实现了“先下载、后启动”的解耦Job 可以并行下载而 Pod 不阻塞在单个下载进程上。S3 凭据来自 Secret_helpers.tpl 的chart.extraInitEnv定义注入 Job 和 wait 容器的环境变量S3_ENDPOINT_URL、S3_BUCKET_NAME、AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY均通过secretKeyRef从release-secrets中读取s3endpoint、s3bucketname、s3accesskeyid、s3accesskey四个 keyS3_PATH则取自extraInit.s3modelpath。因此部署前必须按 secrets.yaml 模板 的约定在values.secrets中提供这四个 key模板会自动b64enc编码。其他可选项initContainers允许追加自定义 init 容器values.yaml 注释中给出了 llm-d routing sidecar 的示例awsEc2MetadataDisabled: true会注入AWS_EC2_METADATA_DISABLED避免在非 EC2 环境中 SDK 误连 EC2 元数据服务若waitContainer.env/downloadJob.env显式给出则完全替代上述默认 S3 环境变量values.yaml 中的注释示例说明该机制也适用于 HuggingFace token 等场景。探针readinessProbe / livenessProbereadinessProbe: initialDelaySeconds: 5 periodSeconds: 5 failureThreshold: 3 httpGet: path: /health port: 8000 livenessProbe: initialDelaySeconds: 15 failureThreshold: 3 periodSeconds: 10 httpGet: path: /health port: 8000两段配置由 helpers 的chart.probes以toYaml原样序列化进 Deployment 容器并直接对应 vLLM API Server 暴露的/health端点端口 8000与--port一致readiness 每 5 秒探测一次连续 3 次失败即摘除流量liveness 启动后延迟 15 秒开始、每 10 秒一次、连续 3 次失败则重启容器两者均允许整体覆盖helper 中判断.Values.readinessProbe/.Values.livenessProbe非空才渲染大模型加载时间较长时可自行调大initialDelaySeconds。其他扩展项configs: {} # 渲染为 release-configs ConfigMap并 envFrom 注入主容器 secrets: {} # 渲染为 release-secrets SecretenvFrom 注入 S3 凭据 externalConfigs: [] # 额外的 envFrom 条目可引用集群内已有 ConfigMap/Secret customObjects: [] # 任意 K8s 对象数组经 tpl 渲染后输出 extraContainers: [] # 追加到 Pod 的额外容器如 sidecar maxUnavailablePodDisruptionBudget: # 留空默认 maxUnavailable1 labels: environment: test release: testconfigmap.yaml 与 secrets.yaml 生成的对象在 deployment.yaml 中通过envFromconfigMapRef/secretRef整体注入主容器适合作为 vLLM 相关环境变量如HF_TOKEN的通道custom-objects.yaml 使用{{ tpl (. | toYaml) $ }}对数组内每个对象做模板渲染可声明式地附加 Ingress、InferenceService 等任意资源且支持引用{{ .Release.Name }}等上下文变量poddisruptionbudget.yaml 固定渲染policy/v1PDBmaxUnavailable默认 1保障节点维护时至少有一个副本可用labels在 values.schema.json 中要求environment与release均必填。从 deployment.yaml 的结构看labels 同时用于 Deployment 的selector.matchLabels与 Pod 模板标签——这意味着发布后不可随意修改 labels否则 selector 变更会导致新 Deployment 与旧 Pod 失配升级时应保持 labels 稳定。模板渲染全景每个文件产生什么把上面各片段串起来一次helm template的典型产物为模板文件产出 K8s 对象渲染条件deployment.yamlrelease-deployment-vllmDeployment总是service.yamlrelease-service或自定义 serviceNameClusterIP Service总是poddisruptionbudget.yamlrelease-pdbPDB总是secrets.yamlrelease-secretsSecret总是内容为secrets值hpa.yamlrelease-hpaHPA v2autoscaling.enabledtruejob.yamlrelease-init-vllm下载 JobextraInit.modelDownload.enabledtruepvc.yamlrelease-storage-claimPVCextraInit存在configmap.yamlrelease-configsConfigMapconfigs非空custom-objects.yaml用户自定义对象customObjects非空对象间协作关系Job写入 PVC 的/data→wait init 容器轮询确认下载完成 →vLLM 主容器挂载同一 PVC 并从/data/加载权重 →Service以 80 端口对外提供 OpenAI 兼容 API →HPA可选按 CPU 利用率扩缩 Deployment 副本。运行 Chart 单元测试README 明确了测试方式Chart 内置基于 helm-unittest 的单元测试tests/ 目录覆盖 deployment、hpa、job、pvc、service 五个模板。安装插件并执行# Install plugin helm plugin install https://github.com/helm-unittest/helm-unittest # Run tests helm unittest .以 deployment_test.yaml 为例测试集验证了三个关键行为也即修改模板时必须回归的场景labels 一致性spec.selector.matchLabels与 Pod 模板标签必须完全等于配置的labels如environment: production/release: qwen-servingmodelDownload 开启时Deployment 恰有一个 init 容器且第一个是wait-download-model镜像amazon/aws-cli:2.6.4、imagePullPolicy: IfNotPresentinit 容器组合逻辑modelDownload.enabledfalse时只渲染用户自定义 init 容器测试用例以 llm-d routing proxy 为例两者同时启用时共 2 个 init 容器且wait-download-model恒在首位——这保证了模型就绪校验永远先于其他初始化逻辑执行。ct.yaml则为 chart-testingct lint/ct install流程提供配置chart-dirs: [charts]、validate-maintainers: false配合lintconf.yaml的 Lint 规则用于 CI 中对 Chart 做静态校验。部署前检查清单综合 Chart 模板与 Schema 的约束执行helm install前应确认image.command指向真实模型路径且与 PVC/data挂载点一致vllm serve的第一个位置参数就是模型目录resources四元组requests/limits 的 cpu、memory齐备GPU 场景下nvidia.com/gpu请求与限制成对设置并把gpuModels占位符TYPE_GPU_USED替换为节点标签nvidia.com/gpu.product对应的实际型号secrets中包含s3endpoint、s3bucketname、s3accesskeyid、s3accesskey四个 key且extraInit.s3modelpath指向桶内正确的相对路径关闭 S3 下载时置extraInit.modelDownload.enabledfalse此时 Job 与 wait 容器均不渲染PVC 仍会创建labels.environment/labels.release已按环境设置且发布后保持稳定如需扩缩容将autoscaling.enabled置为 true 并按容量规划设置minReplicas/maxReplicas本地先跑helm unittest .与helm lint验证模板改动。小结chart-helm是 vLLM 仓库中面向 Kubernetes 的完整部署方案示例以 values.yaml 为配置入口、values.schema.json 为约束、11 个模板文件渲染出 Deployment/Service/HPA/Job/PVC/Secret/ConfigMap/PDB 等对象并用“S3 下载 Job wait init 容器 共享 PVC”的组合解决大模型权重的分发与就绪等待问题tests/ 中的 helm-unittest 用例则为模板改动提供了可执行的回归保障。理解这套结构后可针对自有的 GPU 集群节点标签、对象存储、Service 类型按需覆盖 values 完成落地。【免费下载链接】vllmA high-throughput and memory-efficient inference and serving engine for LLMs项目地址: https://gitcode.com/GitHub_Trending/vl/vllm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 vLLM Helm Chart 深度解析：用 chart-helm 在 Kubernetes 上部署 vLLM 推理服务
vLLM Helm Chart 深度解析用 chart-helm 在 Kubernetes 上部署 vLLM 推理服务【免费下载链接】vllmA high-throughput and memory-efficient inference and serving engine for LLMs项目地址: https://gitcode.com/GitHub_Trending/vl/vllm本篇基于仓库中的 Helm Charts 说明文档 展开讲解 vLLM 官方示例中chart-helm目录下的 Helm Chart 如何把 vLLM 服务部署到 Kubernetes涵盖默认值配置镜像、资源、探针、HPA、S3 模型预下载机制Job init 容器、各类 K8s 对象的模板渲染逻辑以及如何用 helm-unittest 对 Chart 进行单元测试。读完后可独立修改values.yaml完成一次可运行的 vLLM 推理服务发布并理解每个模板文件对应的 K8s 资源及其生效条件。Chart 元数据与目录结构Chart 的元信息定义在 Chart.yaml 中apiVersion: v2 name: chart-vllm description: Chart vllm type: application version: 0.0.2 maintainers: - name: mfournioux要点type: application表明这是一个应用 Chart而非提供模板函数的 library Chart可直接helm install部署version: 0.0.2遵循语义化版本每次修改 Chart 或模板都应递增名称为chart-vllmmaintainer 为mfournioux。按 README 的说明该目录包含一个用于部署 vllm 应用的 Helm Chart内置了部署、自动扩缩容、资源管理等配置能力。完整文件清单如下均在 chart-helm 目录 下文件作用Chart.yamlChart 元数据名称、版本、维护者ct.yamlchart-testing 配置chart-dirs: [charts]、validate-maintainers: falselintconf.yamlYAML 文件的 Lint 规则values.schema.json用于校验values.yaml的 JSON Schemavalues.yamlChart 默认值templates/_helpers.tpl公共模板片段端口、命名、策略、探针、资源等templates/deployment.yamlDeployment 模板核心templates/service.yamlService 模板ClusterIPtemplates/hpa.yamlHorizontalPodAutoscaler 模板templates/job.yaml模型下载 Job 模板templates/pvc.yaml模型存储 PVC 模板templates/secrets.yamlS3 凭据等 Secret 模板templates/configmap.yaml环境变量 ConfigMap 模板templates/custom-objects.yaml渲染用户自定义 K8s 对象templates/poddisruptionbudget.yamlPod 扰动预算模板tests/helm-unittest 单元测试deployment/hpa/job/pvc/service 五套注意values.schema.json的存在Helm 在install/upgrade/template时会自动用它校验用户传入的 values缺必填字段会直接报错这是本 Chart 防止误配置的第一道防线。values.yaml 默认值逐项解析values.yaml 是整个 Chart 的“总开关”每个字段都有# --形式的注释即 helm-docs 风格供生成文档。下面按分组完整解析。镜像与启动命令imageimage: repository: vllm/vllm-openai tag: latest command: [vllm, serve, /data/, --served-model-name, opt-125m, --enforce-eager, --dtype, bfloat16, --block-size, 16, --host, 0.0.0.0, --port, 8000]默认使用vllm/vllm-openai官方镜像容器内直接运行vllm serve启动 OpenAI 兼容 API 服务command会被 deployment.yaml 模板 原样注入容器的command字段等价于替换容器 entrypoint——因此所有 vLLM 引擎参数如--tensor-parallel-size、量化选项等都可以通过覆盖该列表来传递默认命令中模型路径为/data/这与 Chart 的 PVC 挂载路径严格对应见下文“模型存储”一节。opt-125m、--enforce-eager等只是小模型演示配置生产环境应替换为自己的模型目录与参数按 values.schema.json 校验image.command、image.repository、image.tag三者均为必填项。端口、副本与 ServicecontainerPort: 8000 serviceName: # 留空则默认渲染为 release-service servicePort: 80 extraPorts: [] replicaCount: 1 deploymentStrategy: {}containerPort默认 8000与vllm serve --port 8000对应helpers 模板 中定义其为端口名container-port对应的端口值servicePort默认 80即 Service 对外暴露 80 端口并转发到容器的container-port命名端口见 service.yaml 模板固定type: ClusterIP、TCP 协议serviceName留空时helper 会生成release-service作为 Service 名deploymentStrategy留空时_helpers.tpl 提供默认的rollingUpdate: maxSurge: 100%, maxUnavailable: 0策略——对推理服务而言这是合理的滚动更新期间新旧副本并存不会因缩容导致服务中断Deployment 的progressDeadlineSeconds在 deployment.yaml 中硬编码为 1200 秒给大模型加载留出充足的启动时间。资源与 GPU 调度resources / gpuModelsresources: requests: cpu: 4 memory: 16Gi nvidia.com/gpu: 1 limits: cpu: 4 memory: 16Gi nvidia.com/gpu: 1 gpuModels: - TYPE_GPU_USED从 helpers 的资源模板 看resources.requests.memory、cpu以及limits侧对应项均使用required强制定义缺失会导致渲染直接失败GPU 请求仅在requests与limits中nvidia.com/gpu均大于 0 时才会被写入二者必须成对出现当 GPU 数量大于 0 时deployment.yaml 会自动为 Pod 追加三件事runtimeClassName: nvidia启用 NVIDIA 容器运行时节点亲和性requiredDuringSchedulingIgnoredDuringExecution按nvidia.com/gpu.product节点标签匹配gpuModels列表默认占位符为TYPE_GPU_USED部署前必须替换为实际 GPU 型号如NVIDIA-H100由此推断该机制用于把 vLLM Pod 固定调度到指定型号的 GPU 节点避免模型与硬件不匹配。自动扩缩容autoscalingautoscaling: enabled: false minReplicas: 1 maxReplicas: 100 targetCPUUtilizationPercentage: 80 # targetMemoryUtilizationPercentage: 80对应 hpa.yaml 模板仅当autoscaling.enabled: true时渲染autoscaling/v2的HorizontalPodAutoscalerscaleTargetRef指向chart.deployment-name即release-deployment-vllm。CPU 与内存两个指标是独立开关设置了targetCPUUtilizationPercentage就加入 CPU 指标取消注释targetMemoryUtilizationPercentage则同时加入内存指标。需要注意 HPA 依据的是资源利用率对以 GPU 吞吐为主要瓶颈的推理负载通常需要配合自定义指标方案Chart 本身只提供 CPU/内存两种内置指标。模型存储与 S3 下载extraInit这是该 Chart 最具特色的部分用于解决“镜像里不带权重Pod 启动前先下载模型”的问题extraInit: modelDownload: enabled: true image: repository: amazon/aws-cli tag: 2.6.4 pullPolicy: IfNotPresent waitContainer: command: [/bin/bash] args: - -eucx - while aws --endpoint-url $S3_ENDPOINT_URL s3 sync --dryrun s3://$S3_BUCKET_NAME/$S3_PATH /data | grep -q download; do sleep 10; done # env: # 可选若指定则完全覆盖默认 S3 环境 # - name: HUGGING_FACE_HUB_TOKEN # value: your-token # - name: MODEL_ID # value: meta-llama/Llama-2-7b downloadJob: command: [/bin/bash] args: - -eucx - aws --endpoint-url $S3_ENDPOINT_URL s3 sync s3://$S3_BUCKET_NAME/$S3_PATH /data # env: # 同上可选 initContainers: [] # 自定义 init 容器追加在 wait-download-model 之后 s3modelpath: relative_s3_model_path/opt-125m pvcStorage: 1Gi awsEc2MetadataDisabled: true工作机制结合 job.yaml、pvc.yaml 与 deployment.yamlPVC只要extraInit存在就创建名为release-storage-claim的 PVCReadWriteOnce容量由pvcStorage指定默认 1Gi生产请按模型大小调整。该卷被 Job、init 容器与主容器三方挂载到/data是三者共享模型文件的关键。下载 Jobrelease-init-vllm由downloadJob.commandargs执行aws s3 sync s3://$S3_BUCKET_NAME/$S3_PATH /data把 S3 上的权重同步到 PVCrestartPolicy: OnFailure失败自动重试ttlSecondsAfterFinished: 100让 Job 完成后自动清理。等待 init 容器wait-download-model主容器启动前先跑这个轻量 bash 循环——每 10 秒执行一次aws s3 sync --dryrun只模拟不落盘只要输出中还有download字样说明同步未完成就继续等待直到 Job 完成才放行 vLLM 主容器。这实现了“先下载、后启动”的解耦Job 可以并行下载而 Pod 不阻塞在单个下载进程上。S3 凭据来自 Secret_helpers.tpl 的chart.extraInitEnv定义注入 Job 和 wait 容器的环境变量S3_ENDPOINT_URL、S3_BUCKET_NAME、AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY均通过secretKeyRef从release-secrets中读取s3endpoint、s3bucketname、s3accesskeyid、s3accesskey四个 keyS3_PATH则取自extraInit.s3modelpath。因此部署前必须按 secrets.yaml 模板 的约定在values.secrets中提供这四个 key模板会自动b64enc编码。其他可选项initContainers允许追加自定义 init 容器values.yaml 注释中给出了 llm-d routing sidecar 的示例awsEc2MetadataDisabled: true会注入AWS_EC2_METADATA_DISABLED避免在非 EC2 环境中 SDK 误连 EC2 元数据服务若waitContainer.env/downloadJob.env显式给出则完全替代上述默认 S3 环境变量values.yaml 中的注释示例说明该机制也适用于 HuggingFace token 等场景。探针readinessProbe / livenessProbereadinessProbe: initialDelaySeconds: 5 periodSeconds: 5 failureThreshold: 3 httpGet: path: /health port: 8000 livenessProbe: initialDelaySeconds: 15 failureThreshold: 3 periodSeconds: 10 httpGet: path: /health port: 8000两段配置由 helpers 的chart.probes以toYaml原样序列化进 Deployment 容器并直接对应 vLLM API Server 暴露的/health端点端口 8000与--port一致readiness 每 5 秒探测一次连续 3 次失败即摘除流量liveness 启动后延迟 15 秒开始、每 10 秒一次、连续 3 次失败则重启容器两者均允许整体覆盖helper 中判断.Values.readinessProbe/.Values.livenessProbe非空才渲染大模型加载时间较长时可自行调大initialDelaySeconds。其他扩展项configs: {} # 渲染为 release-configs ConfigMap并 envFrom 注入主容器 secrets: {} # 渲染为 release-secrets SecretenvFrom 注入 S3 凭据 externalConfigs: [] # 额外的 envFrom 条目可引用集群内已有 ConfigMap/Secret customObjects: [] # 任意 K8s 对象数组经 tpl 渲染后输出 extraContainers: [] # 追加到 Pod 的额外容器如 sidecar maxUnavailablePodDisruptionBudget: # 留空默认 maxUnavailable1 labels: environment: test release: testconfigmap.yaml 与 secrets.yaml 生成的对象在 deployment.yaml 中通过envFromconfigMapRef/secretRef整体注入主容器适合作为 vLLM 相关环境变量如HF_TOKEN的通道custom-objects.yaml 使用{{ tpl (. | toYaml) $ }}对数组内每个对象做模板渲染可声明式地附加 Ingress、InferenceService 等任意资源且支持引用{{ .Release.Name }}等上下文变量poddisruptionbudget.yaml 固定渲染policy/v1PDBmaxUnavailable默认 1保障节点维护时至少有一个副本可用labels在 values.schema.json 中要求environment与release均必填。从 deployment.yaml 的结构看labels 同时用于 Deployment 的selector.matchLabels与 Pod 模板标签——这意味着发布后不可随意修改 labels否则 selector 变更会导致新 Deployment 与旧 Pod 失配升级时应保持 labels 稳定。模板渲染全景每个文件产生什么把上面各片段串起来一次helm template的典型产物为模板文件产出 K8s 对象渲染条件deployment.yamlrelease-deployment-vllmDeployment总是service.yamlrelease-service或自定义 serviceNameClusterIP Service总是poddisruptionbudget.yamlrelease-pdbPDB总是secrets.yamlrelease-secretsSecret总是内容为secrets值hpa.yamlrelease-hpaHPA v2autoscaling.enabledtruejob.yamlrelease-init-vllm下载 JobextraInit.modelDownload.enabledtruepvc.yamlrelease-storage-claimPVCextraInit存在configmap.yamlrelease-configsConfigMapconfigs非空custom-objects.yaml用户自定义对象customObjects非空对象间协作关系Job写入 PVC 的/data→wait init 容器轮询确认下载完成 →vLLM 主容器挂载同一 PVC 并从/data/加载权重 →Service以 80 端口对外提供 OpenAI 兼容 API →HPA可选按 CPU 利用率扩缩 Deployment 副本。运行 Chart 单元测试README 明确了测试方式Chart 内置基于 helm-unittest 的单元测试tests/ 目录覆盖 deployment、hpa、job、pvc、service 五个模板。安装插件并执行# Install plugin helm plugin install https://github.com/helm-unittest/helm-unittest # Run tests helm unittest .以 deployment_test.yaml 为例测试集验证了三个关键行为也即修改模板时必须回归的场景labels 一致性spec.selector.matchLabels与 Pod 模板标签必须完全等于配置的labels如environment: production/release: qwen-servingmodelDownload 开启时Deployment 恰有一个 init 容器且第一个是wait-download-model镜像amazon/aws-cli:2.6.4、imagePullPolicy: IfNotPresentinit 容器组合逻辑modelDownload.enabledfalse时只渲染用户自定义 init 容器测试用例以 llm-d routing proxy 为例两者同时启用时共 2 个 init 容器且wait-download-model恒在首位——这保证了模型就绪校验永远先于其他初始化逻辑执行。ct.yaml则为 chart-testingct lint/ct install流程提供配置chart-dirs: [charts]、validate-maintainers: false配合lintconf.yaml的 Lint 规则用于 CI 中对 Chart 做静态校验。部署前检查清单综合 Chart 模板与 Schema 的约束执行helm install前应确认image.command指向真实模型路径且与 PVC/data挂载点一致vllm serve的第一个位置参数就是模型目录resources四元组requests/limits 的 cpu、memory齐备GPU 场景下nvidia.com/gpu请求与限制成对设置并把gpuModels占位符TYPE_GPU_USED替换为节点标签nvidia.com/gpu.product对应的实际型号secrets中包含s3endpoint、s3bucketname、s3accesskeyid、s3accesskey四个 key且extraInit.s3modelpath指向桶内正确的相对路径关闭 S3 下载时置extraInit.modelDownload.enabledfalse此时 Job 与 wait 容器均不渲染PVC 仍会创建labels.environment/labels.release已按环境设置且发布后保持稳定如需扩缩容将autoscaling.enabled置为 true 并按容量规划设置minReplicas/maxReplicas本地先跑helm unittest .与helm lint验证模板改动。小结chart-helm是 vLLM 仓库中面向 Kubernetes 的完整部署方案示例以 values.yaml 为配置入口、values.schema.json 为约束、11 个模板文件渲染出 Deployment/Service/HPA/Job/PVC/Secret/ConfigMap/PDB 等对象并用“S3 下载 Job wait init 容器 共享 PVC”的组合解决大模型权重的分发与就绪等待问题tests/ 中的 helm-unittest 用例则为模板改动提供了可执行的回归保障。理解这套结构后可针对自有的 GPU 集群节点标签、对象存储、Service 类型按需覆盖 values 完成落地。【免费下载链接】vllmA high-throughput and memory-efficient inference and serving engine for LLMs项目地址: https://gitcode.com/GitHub_Trending/vl/vllm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考