Helm 是 Kubernetes 生态中最流行的包管理工具，它的作用类似于 Linux 系统中的 apt 或 yum。通过 Helm，我们可以把一整套 Kubernetes 资源清单（Deployment、Service、ConfigMap 等）打包成一个称为 Chart 的单元，然后通过一条命令完成部署、升级和卸载。相比手工编写和维护大量 YAML 文件，Helm 大幅简化了应用的交付流程，尤其在管理有状态服务、中间件以及复杂微服务应用时优势明显。本文将从核心概念、安装部署、Chart 定制与生命周期管理几个方面，完整讲解 Helm 的使用方法。
一、Helm 核心概念与Chart目录结构
Helm 的工作围绕几个核心概念展开。Chart 是应用的定义包，包含了一组 Kubernetes 资源模板和默认配置；Release 是 Chart 的一次运行实例，同一个 Chart 可以在集群中安装多个不同名字的 Release；Repository 是存放和共享 Chart 的仓库，类似 npm 或 Maven 的仓库概念。理解这三者的关系是掌握 Helm 的基础：从仓库拉取 Chart，通过安装生成 Release，后续的升级和回滚都针对具体的 Release 进行。
一个标准的 Chart 目录结构如下：
mychart/ ├── Chart.yaml # Chart的元信息：名称、版本、描述 ├── values.yaml # 默认配置值，可被外部覆盖 ├── charts/ # 依赖的子Chart存放目录 ├── templates/ # 模板目录，存放资源清单模板 │ ├── deployment.yaml │ ├── service.yaml │ ├── _helpers.tpl # 可复用的模板片段 │ └── NOTES.txt # 安装成功后的提示信息 └── .helmignore # 打包时忽略的文件列表
Chart.yaml 中声明了 Chart 的名称与版本，其中 version 表示 Chart 自身版本，appVersion 表示应用版本，两者相互独立。templates 目录下的文件最终会被渲染成真正的 Kubernetes 清单，模板中通过 Go template 语法引用 values.yaml 中定义的变量，例如 {{ .Values.image.repository }}。这种模板与配置分离的设计，让同一份 Chart 可以适配开发、测试、生产等多种环境。
二、安装Helm并部署第一个应用
Helm 客户端是一个单独的二进制程序，不依赖集群内部组件，通过 kubeconfig 与 Kubernetes API 通信。在 Linux 上可以通过官方脚本一键安装：
# 下载并安装Helm（以v3.14.0为例） curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 chmod 700 get_helm.sh ./get_helm.sh # 验证安装 helm version
安装完成后，第一步通常是添加第三方仓库。以部署 Nginx Ingress Controller 为例，流程如下：
# 1. 添加Bitnami官方仓库 helm repo add bitnami https://charts.bitnami.com/bitnami helm repo update # 2. 搜索想要的Chart helm search repo nginx # 3. 安装Chart，生成一个名为my-nginx的Release helm install my-nginx bitnami/nginx \ --namespace ingress-nginx \ --create-namespace # 4. 查看Release状态 helm list -n ingress-nginx helm status my-nginx -n ingress-nginx
helm install 命令中的第一个参数是 Release 名称，第二个参数是 Chart 的仓库引用。如果不指定名称，可以加 --generate-name 让 Helm 自动生成。安装后可以用 helm get manifest 查看实际渲染出来的资源清单，这对排查模板渲染问题非常有用。卸载则使用 helm uninstall my-nginx -n ingress-nginx，Helm 会自动清理该 Release 创建的所有资源。
三、使用values文件定制Chart配置
直接使用默认配置安装 Chart 往往无法满足实际需求，Helm 提供了多种覆盖 values 的方式。最常用的做法是编写自定义的 values 文件，在安装时通过 -f 参数传入：
# my-values.yaml 自定义配置
replicaCount: 3
image:
repository: my-registry.ipipp.com/myapp
tag: "1.2.0"
pullPolicy: IfNotPresent
service:
type: NodePort
port: 8080
resources:
limits:
cpu: 500m
memory: 512Mi
requests:
cpu: 100m
memory: 128Mi
# 使用自定义配置安装 helm install myapp ./mychart -f my-values.yaml -n prod # 也可以直接在命令行覆盖单个值 helm upgrade myapp ./mychart --set image.tag=1.3.0 -n prod # 查看某个Release当前生效的完整配置 helm get values myapp -n prod --all
三种覆盖方式的优先级从低到高依次是：Chart 内置的 values.yaml、-f 传入的文件、--set 命令行参数。需要注意的是，--set 适合临时调整少量参数，大量配置还是应该用文件管理并纳入 Git 版本控制，这样每次部署的配置都可追溯。此外，可以用 helm show values bitnami/nginx 查看一个 Chart 支持的全部配置项，这是了解第三方 Chart 定制能力的最佳途径。
在多环境场景下，通常会为每个环境维护独立的 values 文件，例如 values-dev.yaml、values-prod.yaml，公共配置放在基础文件中，环境差异只写增量部分。结合 Helm 的层叠覆盖机制，就能实现一套 Chart 适配多套环境的目标，避免为每个环境复制一份完整的配置。
四、升级、回滚与Chart的生命周期管理
应用迭代时需要更新镜像版本或调整副本数，这时使用 helm upgrade。一个实用的习惯是每次升级都加上 --install 参数，这样即使 Release 不存在也会自动创建，脚本中就不必区分首次安装和后续升级：
# 升级Release：更新镜像版本并增加副本 helm upgrade --install myapp ./mychart \ -f values-prod.yaml \ --set image.tag=2.0.0 \ --set replicaCount=5 \ -n prod # 查看历史版本 helm history myapp -n prod # 回滚到上一个版本 helm rollback myapp -n prod # 回滚到指定修订版本 helm rollback myapp 2 -n prod
Helm 会为每次升级生成一个修订号（Revision），回滚时可以精确指定回到哪个版本。要注意的是，回滚只针对通过 Helm 管理的资源生效，如果资源被外部工具直接修改过，可能出现状态不一致。生产环境中建议升级时配合 --wait 参数，让 Helm 等待所有资源就绪才返回成功，还可以加上 --timeout 10m 控制等待上限。
当 Chart 开发完成需要分发时，可以执行 helm package ./mychart 生成 .tgz 压缩包，再通过 helm repo index 生成索引文件，搭建私有仓库供团队共享。Chart 版本管理建议遵循语义化版本规范：功能性变更递增次版本号，仅修复问题递增修订号，不兼容变更递增主版本号。配合 CI/CD 流水线，可以实现提交代码后自动打包 Chart、自动部署到指定环境的完整交付链路，这也是 Helm 在生产环境中最大的价值所在。
五、常见问题与使用建议
使用 Helm 过程中有几个常见坑需要注意。第一，Helm 3 已移除 Tiller 服务端组件，权限完全依赖当前 kubeconfig 的身份，因此报权限错误时应检查 ServiceAccount 的 RBAC 配置。第二，删除 Release 时可以加 --keep-history 保留历史记录，方便事后排查；默认的 --no-hooks 行为也值得了解，避免误删 Hook 资源。第三，模板渲染错误是最常见的问题，可以用 helm template ./mychart 或 helm install --dry-run --debug 在本地验证渲染结果而不实际部署。
在团队协作层面，建议把 Chart 源码和 values 文件都放进 Git 仓库管理，环境配置与 Chart 定义分离存放；对生产环境的 Release 操作统一走流水线，避免人工随意执行 upgrade；定期用 helm list --all-namespaces 巡检集群中的 Release 状态，及时清理废弃实例。遵循这些实践，Helm 就能真正成为 Kubernetes 应用交付的可靠基石。
Helm ChartKubernetes部署Helm命令修改时间：2026-09-01 22:54:38