上一篇【第72篇】CRD详解——让你的K8s认识全新“物种“Operator的基石下一篇【第74篇】Operator模式——让K8s学会自动驾驶摘要你有没有过这种经历部署一个应用要写Deployment、Service、ConfigMap、Ingress、PVC……七八个YAML文件改个镜像版本得全局搜索替换测试环境和生产环境各维护一套几乎一样的配置差一个字段就部署失败。这就是Helm要解决的痛点。它把一套相关YAML打包成Chart图表/包用模板变量把变的部分抽出来放到values.yaml一条helm install就部署好整个应用。就像apt/yum之于Linux、npm之于NodeHelm是K8s的包管理器。这篇文章讲清Helm v3和v2的关键区别v3干掉了危险的Tiller、Chart的目录结构、模板语法、Hook机制以及日常命令。一、Helm解决什么1.1 痛点对比【没有Helm vs 有Helm】 没有Helm: • 部署一个应用 维护5-8个YAML文件 • 改版本 sed全局替换(容易漏) • 多环境 复制N份改N处(容易不一致) • 回滚 手动kubectl apply旧文件(累) • 分享 把YAML打包发群里(不优雅) 有Helm: • 部署 helm install myapp ./chart • 改版本 改values.yaml一个字段 • 多环境 不同values文件覆盖 • 回滚 helm rollback myapp 1 • 分享 helm repo推送(像npm包)要点Helm的核心价值是模板化参数化。把不变的骨架写成模板把变的部分镜像版本、副本数、资源限制、域名抽成values.yaml的变量。一套Chart通过不同values适配测试/生产/客户环境——这就是一次编写处处部署。二、Helm v3 vs v22.1 干掉了Tiller【Helm v2 的架构(已淘汰)】 helm客户端 ──► Tiller(服务端, 跑在集群里) │ ▼ API Server ⚠️ Tiller问题 • 用serviceaccount有过大权限(常给cluster-admin) • 多用户共享Tiller → 权限混乱 • 服务端组件, 多一个要维护的东西 • 安全噩梦【Helm v3 的架构(现在)】 helm客户端 (本地) │ 直接用kubeconfig连API Server ▼ API Server (走RBAC, 你是谁就用谁的权限) ✅ 没有Tiller! ✅ 权限你自己的kubectl权限(安全) ✅ 客户端更轻维度Helm v2Helm v3Tiller有(服务端)无权限模型Tiller的SA权限用户自身kubeconfig安装复杂度高(要装Tiller)低(只装客户端)多租户混乱清晰(RBAC管控)要点v3砍掉Tiller是安全性飞跃——不再有一个超级权限的服务端躺在集群里。helm客户端直接用你的kubeconfig操作权限完全由RBAC控制你是谁就只能部署你能部署的。现在新项目一律用v3v2已彻底淘汰。三、Chart目录结构3.1 标准结构【一个Chart的目录树】 myapp/ ├── Chart.yaml # Chart元数据(名称/版本/依赖) ├── values.yaml # 默认参数值(用户主要改这个) ├── charts/ # 依赖的子Chart(子包) ├── templates/ # 模板目录(核心!) │ ├── deployment.yaml # 用Go template语法写 │ ├── service.yaml │ ├── configmap.yaml │ ├── ingress.yaml │ ├── _helpers.tpl # 公共模板片段(以下划线开头) │ └── NOTES.txt # 安装后显示的提示 └── templates/tests/ # 测试3.2 模板长啥样# templates/deployment.yamlapiVersion:apps/v1kind:Deploymentmetadata:name:{{.Release.Name}}-app# 用Release名动态生成spec:replicas:{{.Values.replicaCount}}# 从values取副本数selector:matchLabels:app:{{.Chart.Name}}template:metadata:labels:app:{{.Chart.Name}}spec:containers:-name:appimage:{{ .Values.image.repository }}:{{ .Values.image.tag }}ports:-containerPort:{{.Values.service.port}}# values.yaml (用户主要改这个)replicaCount:3image:repository:nginxtag:1.25service:port:80type:ClusterIP要点模板用Go template语法{{ .Values.xxx }}从values.yaml取值{{ .Release.Name }}从安装时传入。这样同一个Charthelm install prod ./myapp --set replicaCount5和helm install test ./myapp部署出不同规模的应用。Helm在渲染时把模板values合成最终YAML再apply。四、常用命令4.1 日常操作# 1. 添加仓库helm repoaddbitnami https://charts.bitnami.com/bitnami# 2. 搜索charthelm search repo nginx# 3. 安装(起个release名)helminstallmy-nginx bitnami/nginx-ndefault# 4. 用自定义values覆盖helminstallmy-nginx ./myapp-fvalues-prod.yaml# 5. 升级(改了chart或values)helm upgrade my-nginx ./myapp--setimage.tag1.26# 6. 回滚(救命命令)helm rollback my-nginx1# 回滚到第1个revision# 7. 看历史helmhistorymy-nginx# 8. 渲染看生成的YAML(不实际部署,调试用)helm template my-nginx ./myapp# 9. 卸载helm uninstall my-nginx五、Hook机制4.1 生命周期钩子【Helm Hook —— 部署过程中的特殊时刻】 hooks: • pre-install : 安装前跑(如初始化数据库) • post-install : 安装后跑(如发通知) • pre-upgrade : 升级前跑(如备份) • post-upgrade : 升级后跑 • pre-delete : 删除前跑(如确认) • post-delete : 删除后跑(如清理) • crd-install : 安装CRD前 用annotation标记一个资源是hook: annotations: helm.sh/hook: pre-install# 一个pre-install hook: 部署前先建数据库apiVersion:batch/v1kind:Jobmetadata:name:init-dbannotations:helm.sh/hook:pre-installhelm.sh/hook-weight:-5spec:template:spec:restartPolicy:Nevercontainers:-name:initimage:busyboxcommand:[sh,-c,echo init db...]要点Hook让Chart能在部署生命周期的特殊时刻执行任务初始化、备份、通知。比如pre-install跑个Job初始化数据库pre-upgrade先备份再升级。hook-weight控制多个hook的执行顺序。配合Helm的整体模板化复杂的应用部署也能标准化、可重复。下篇讲Operator——比Helm更智能的自动化运维模式。本篇小结Helm是K8s的包管理器把多文件YAML打包成Chart模板values用helm install/upgrade/rollback标准化部署解决了复制粘贴YAML、多环境不一致、回滚难的噩梦。v3砍掉危险的Tiller直接用用户kubeconfig权限安全性大幅提升。Chart目录里templates/是核心Go template语法values.yaml是用户主要改的参数。Hook机制在部署生命周期的特殊时刻执行任务。Helm管怎么部署下篇的Operator管怎么运维——两者定位不同但常常配合。上一篇【第72篇】CRD详解——让你的K8s认识全新“物种“Operator的基石下一篇【第74篇】Operator模式——让K8s学会自动驾驶