一句话定义：Helm Chart 是把一组 Kubernetes（简称 K8s）资源清单、可替换参数和版本信息打成的安装包；Helm 读取它之后，才把模板渲染成具体 YAML 并提交给集群。
Chart 里装了什么
一个典型 Chart 就是一个小目录：
Chart.yaml：包的名字、版本、描述等元数据；values.yaml：一份默认参数表；templates/：一堆带{{ .Values.xxx }}占位符的 K8s 清单模板，涵盖 Deployment、Service、Ingress、ConfigMap 等；charts/：依赖的子 Chart。
打个比方，Chart 像一份带空格的装修图纸，values 是你填的那张参数表，Helm 是按图纸施工的工头。同一份图纸，填「2 核 4G、单副本」就是测试环境，填「16 核、三副本、开 TLS」就是生产环境。模板保证结构一致，参数决定规模与开关。
它不是部署引擎
这是最容易混淆的地方：Helm 才是工具，负责渲染、安装、升级、回滚；Chart 只是被处理的「内容物」，本身不会执行任何动作。同理，Chart 也不是容器镜像：镜像打包的是单个进程，Chart 打包的是整个应用拓扑和它周围的配置。
| 对象 | 是什么 | 谁执行 |
|---|---|---|
| 容器镜像 | 单个服务的运行体 | 容器运行时 |
| Chart | 参数化的资源模板包 | 不执行，只被读取 |
| Release | Chart 在集群里的一次具体安装（Chart + 你给的 values + 集群状态） | Helm 管理生命周期 |
| Kustomize | 用 overlay 给静态 YAML 打补丁 | kubectl |
真正容易出事的是 values 层级
Chart 的 values 是嵌套的，覆盖时层级写错，往往不会报错，只会静默回落到默认值。比如某个开关实际在子 Chart 的 redis.auth.enabled 下，你写成 redis.enabled，渲染照样成功，但生产环境悄悄用了默认配置；--set 时把副本数写在错误的父节点下，也可能让生产套上测试规格。这类事故的共同点是「没有任何报错」。
可用的防线：优先用分环境的 values 文件而不是一长串 --set；发布前用 helm template 本地渲染出最终 YAML 并与线上做 diff；给 Chart 配 values.schema.json 做类型校验；把渲染结果纳入 CI 评审。
对从业者的意义
对 AI 工程师来说，部署推理服务、向量库、各类 operator 时常直接复用社区维护的 Chart，省掉手写几十个 YAML 的功夫，但要盯住镜像 tag 锁定、资源 requests/limits 和 GPU 调度字段有没有被默认值覆盖。对非技术同事，它示范了一个通用思路：把「结构」和「配置」分开，同一份模板复用多套环境——只是配置这一层，永远值得多看一眼。具体字段与行为以 Helm 官方文档为准。