一、开篇从手工 kubectl apply到一行命令装全套在 Kubernetes 的世界里你一定干过这种事要部署一个 GitLab需要 ConfigMap、Deployment、Service、Ingress、Secret、HPA……加起来二十多个 YAML。记不全顺序、搞不清依赖、版本管理混乱、回滚靠人肉对比——运维团队每天疲于奔命出新版本如同上战场。我第一次用 Helm 时感觉就像从手写 Dockerfile跨越到了用 Docker Compose 启动整套服务——那种原来部署可以这么简单的惊喜感至今记忆犹新。今天这篇我们来系统聊聊Helm 3它是什么怎么用怎么写 Chart怎么管理发布与回滚以及我们团队在实际落地中踩过的那些坑。二、Helm 是什么三层概念一次讲清楚很多新人容易把 Helm 和 yum/apt 混为一谈——它们确实都叫包管理器但定位不同yum/apt管理的是系统层面的软件包作用域是操作系统。Helm管理的是Kubernetes 应用层面的包作用域是整个集群。Helm 有三层核心概念记住这三个词就理解了一切概念类比说明Chart软件安装包.deb/.rpm一个 Chart 就是一套可复用的 Kubernetes 资源模板Repository软件源存放 Chart 的仓库类似于 Docker HubRelease安装实例同一个 Chart 可以安装多次每次生成一个 Release互不干扰打个比方Chart 是图纸Repository 是图纸库Release 是按图纸盖出来的楼。同一个图纸可以盖在北京也可以盖在上海互不影响。三、最常用命令增删改查Helm 的命令设计得很直觉记住五个动作就够了# 1. 搜索 Charthelm search repo nginx# 2. 安装最简单的用法helminstallmy-nginx bitnami/nginx# 3. 查看已安装的 Releasehelm list# 4. 升级版本helm upgrade my-nginx bitnami/nginx--setimage.tag1.21# 5. 回滚Helm 的杀手锏helm rollback my-nginx1这里重点说helm install的几个常见参数因为这是我们平时用得最多的# 指定命名空间最常用helminstallmy-nginx bitnami/nginx-nnginx-system --create-namespace# 覆盖默认 valueshelminstallmy-gitlab bitnami/gitlab--setservice.typeLoadBalancer# 用自己的 values 文件helminstallmy-gitlab bitnami/gitlab-fmy-values.yaml四、values.yaml让同一个 Chart 适配多套环境这是 Helm 最精髓的设计之一用同一个 Chart通过不同的 values 文件生成不同环境的资源。比如我们团队有三个环境dev、staging、production它们部署同一个 GitLab Chart但资源配置完全不同dev-values.yaml开发环境追求快速启动resources:requests:cpu:250mmemory:512Milimits:cpu:500mmemory:1GireplicaCount:1persistence:size:5Giprod-values.yaml生产环境追求稳定可靠resources:requests:cpu:2000mmemory:8Gilimits:cpu:4000mmemory:16GireplicaCount:3persistence:size:100Gi部署时一行命令搞定helm upgrade--installgitlab bitnami/gitlab-fprod-values.yaml-ngitlab-system这样做的好处一套 Chart 代码多套环境配置零重复。运维不需要复制二十多个 YAML只维护几套 values 文件就够了。五、Chart 的目录结构与核心文件一个标准的 Chart 长这样myapp/ ├── Chart.yaml # Chart 元信息名字、版本、依赖 ├── values.yaml # 默认配置 ├── values.schema.json # values 校验规则可选 ├── templates/ # Kubernetes 资源模板目录 │ ├── deployment.yaml │ ├── service.yaml │ ├── ingress.yaml │ └── _helpers.tpl # 命名模板可复用片段 └── charts/ # 子 Chart依赖最核心的是Chart.yaml和templates/deployment.yaml。Chart.yaml 示例apiVersion:v2name:myapp-backendversion:1.2.0appVersion:2.1.4description:订单后端服务keywords:-order-backenddependencies:# Helm 3 支持 Chart 依赖-name:redisversion:17.x.xrepository:https://charts.bitnami.com/bitnamitemplates/deployment.yaml 中的模板语法apiVersion:apps/v1kind:Deploymentmetadata:name:{{.Release.Name}}-backendlabels:app:{{.Chart.Name}}version:{{.Values.image.tag}}spec:replicas:{{.Values.replicaCount}}selector:matchLabels:app:{{.Chart.Name}}template:metadata:labels:app:{{.Chart.Name}}version:{{.Values.image.tag}}spec:containers:-name:backendimage:{{.Values.image.repository}}:{{.Values.image.tag}}ports:-containerPort:{{.Values.service.port}}resources:{{-toYaml .Values.resources|nindent 10}}这里的.Release.Name、.Chart.Name、.Values.xxx都是 Helm 的模板变量由 Helm 在渲染时自动注入。记住三个核心对象.Release发布信息Name、Namespace、Revision、IsUpgrade.ChartChart 信息Name、Version、AppVersion.Valuesvalues 文件传入的值六、实战写一个生产级 MySQL Chart光说不练假把式这里用一个简化版 MySQL Chart 演示完整流程精华都在注释里Chart.yamlapiVersion:v2name:mysql-prodversion:1.0.0appVersion:8.0values.yaml带生产级默认值image:repository:mysqltag:8.0pullPolicy:IfNotPresentpersistence:enabled:truesize:50GistorageClass:ssd-gold# 指定高质量存储类resources:requests:cpu:500mmemory:1Gilimits:cpu:2000mmemory:4GiconfigurationFiles:mysql.cnf:|[mysqld] max_connections 2000 innodb_buffer_pool_size 1G slow_query_log 1podAnnotations:prometheus.io/scrape:trueprometheus.io/port:9104templates/deployment.yaml核心逻辑apiVersion:apps/v1kind:Deploymentmetadata:name:{{.Release.Name}}annotations:helm.sh/hook:pre-install,pre-upgrade# 升级前先执行 Hookspec:replicas:1selector:matchLabels:app:{{.Release.Name}}template:metadata:labels:app:{{.Release.Name}}annotations:{{-with .Values.podAnnotations}}{{-toYaml .|trim|nindent 8}}{{-end}}spec:containers:-name:mysqlimage:{{ .Values.image.repository }}:{{ .Values.image.tag }}env:-name:MYSQL_ROOT_PASSWORDvalueFrom:secretKeyRef:name:{{.Release.Name}}-secretkey:root-passwordvolumeMounts:-name:datamountPath:/var/lib/mysql-name:configmountPath:/etc/mysql/conf.dresources:{{-toYaml .Values.resources|nindent 10}}volumes:-name:datapersistentVolumeClaim:claimName:{{.Release.Name}}-pvc-name:configconfigMap:name:{{.Release.Name}}-config这里我踩过的一个重要坑存储类名称要和环境匹配。我们在 dev 环境用了默认 storageClass但 prod 切到 ssd-gold 后发现集群没有这个类PVC 一直 Pending。解决方案是在 values 里显式指定并在 pre-install Hook 里做校验。七、Helm 的 Release 管理哲学原子升级与安全回滚Helm 最有价值的功能不是安装是升级与回滚。每次helm upgradeHelm 都会用新版本 values 渲染新模板对比新旧资源差异diff执行更新Update将本次操作作为一个 Revision 记录下来查看历史版本helmhistorymy-release# REVISION UPDATED STATUS CHART DESCRIPTION# 1 Mon Jul 27 09:00:00 2026 superseded mysql-prod-1.0.0 Install complete# 2 Mon Jul 27 10:30:00 2026 deployed mysql-prod-1.1.0 Upgrade complete# 3 Mon Jul 27 14:00:00 2026 failed mysql-prod-1.2.0 Upgrade failed回滚到上一个健康版本helm rollback my-release2# Rollback was a success! my-release has been rolled back to revision 2.我们团队定的规矩生产环境任何变更必须先在 staging 验证且每次升级后观察 5 分钟再决定是否继续。Helm 的 Revision 记录让我们有了后悔药这是手动 kubectl apply 完全做不到的。八、Helmfile用代码管理多环境、多集群的 Helm Release当集群从 1 个变成 3 个dev/staging/prod每个集群有 10 个 Release纯手工 helm 命令已经管不过来了。这时候需要HelmfileGithHubroboll/helmfile# helmfile.yamlenvironments:default:values:-env/default.yamlproduction:values:-env/production.yamlreleases:-name:gitlabchart:bitnami/gitlabvalues:-values/gitlab.yamlsecrets:-secrets/gitlab-secrets.yaml.gpg# GPG 加密敏感信息installed:{{if eq .Environment.Name dev}}false{{else}}true{{end}}-name:mysqlchart:./charts/mysql-prodvalues:-values/mysql.yamlneeds:-monitoring/prometheus# 声明依赖启动顺序自动处理helmfile sync一键同步所有 Releasehelmfile diff预览变更——这才叫 GitOps。九、我们落地 Helm 过程中的几个关键坑坑 1忘记 --namespace 导致装到 default 命名空间。新人最常踩的坑不指定-n就 install结果 Pod 跑在 default 命名空间和其他应用混在一起排查起来头疼。规范始终加-n namespace --create-namespace。坑 2values 合并优先级混乱。Helm 的 values 合并顺序是Chart 默认 values values 文件 命令行 --set。搞清楚这个顺序很重要不然你以为改了 values.yaml但实际不生效——大概率是被命令行参数覆盖了。坑 3release 重名冲突。同一个集群里helm install redis bitnami/redis跑两次会报错但helm upgrade --install也叫 CI/CD 安全模式可以同时覆盖两种情况。我们 CI/CD 里统一用helm upgrade --install永远不用install。坑 4Chart 版本和 App 版本混用。Chart.yaml里的version是 Chart 本身的版本appVersion是应用如 MySQL 8.0的版本。发布新 Chart 功能时改 version升级 MySQL 版本时改 appVersion。这两个不是一个东西别搞混。坑 5Hook 资源没加 cleanup 策略。我们在 pre-upgrade Hook 里做了数据库备份但 Hook 失败后忘了清理导致备份 Job 一直卡在 Running 状态。最后加上了删除策略annotations:helm.sh/hook-delete-policy:hook-succeeded,hook-failed十、写在最后Helm 解决的核心问题不是如何部署一个应用而是**“如何把一个应用变成一个可版本化管理、可一键部署、可安全回滚的标准交付物”**。从二十多个 YAML 到一行helm install从手动记录版本到helm history可追溯从不敢升级到敢点升级——这套工程化能力才是 Helm 真正的价值所在。我们团队现在的交付标准任何应用上线必须提供 Helm Chart不接受裸 YAML。Chart 即代码Chart 即文档Chart 即交付物。下一站我们可以聊聊Istio/Service Mesh看看在 Ingress 之后网格层的流量治理还有哪些 Helm Chart 能帮我们做的事。关注我架构路上不迷路。—— 本文是《100 篇架构实战》系列第 89 篇前作可回看 Kubernetes Ingress 实战专题。