从原生 K8s 到 Helm彻底搞懂templates/、values与Chart.yaml刚学完k8s/文件夹里那一堆原生 YAML以为自己懂了 Kubernetes 部署。打开helm/目录后却懵了templates/里全是{{ .Values.xxx }}values.yaml、values-dev.yaml、values-prod.yaml长得还不一样还有个Chart.yaml不知道是干嘛的。这篇文章把这几个核心问题一次性讲透。一、为什么需要 Helm从手写简历到简历模板如果你把k8s/里的文件比作手写简历——内容固定改一个字就得重抄一份——那helm/templates/就是简历模板。你写一次模板填入不同的信息就能生成无数份针对不同岗位的简历。Helm 干的就是这件事把静态 YAML 变成动态模板让同一套配置能适配开发、测试、生产等多种环境。二、templates/你的智能 YAML 工厂templates/是 Helm Chart 的核心引擎室。它存放的是带变量的 YAML 草稿Helm 根据values.yaml里的配置自动生产出适合不同环境的 Kubernetes 资源清单。2.1 每个文件的作用Table文件作用_helpers.tpl模板工具箱定义可复用的代码片段如统一标签生成不会直接产出 K8s 资源deployment.yaml定义 Pod 怎么跑镜像、副本数、环境变量、资源限制service.yaml定义集群内如何访问 Podingress.yaml定义外部流量怎么进来域名、路径、TLSconfigmap.yaml/secret.yaml配置和敏感数据注入容器pvc.yaml持久化存储hpa.yaml自动扩缩容resourcequota.yaml命名空间资源配额networkpolicy.yamlPod 间网络安全隔离serviceaccount.yamlRBAC 权限身份monitoring.yaml监控配置notes.txt安装完成后给用户的提示信息2.2 核心语法占位符与渲染templates/deployment.yaml里可能是这样写的yamlspec: replicas: {{ .Values.replicaCount.backend }} template: spec: containers: - name: backend image: {{ .Values.image.repository }}:{{ .Values.image.tag }} resources: requests: memory: {{ .Values.backend.resources.requests.memory }}Helm 渲染后就变成你熟悉的原生 K8s YAMLyamlspec: replicas: 3 template: spec: containers: - name: backend image: ghcr.io/xxx/camp-backend:v1.0.0 resources: requests: memory: 512Mi三、values.yaml与values-*.yaml基准值 vs 覆盖值这是最容易让人困惑的地方。为什么有三个values文件它们怎么协作3.1 角色定位Table文件角色类比values.yaml默认值文件基准配置菜单上的默认套餐values-dev.yaml开发环境覆盖文件不要辣、少盐——只改需要改的地方values-prod.yaml生产环境覆盖文件加量、加辣、加芝士——强化配置Helm 的合并逻辑非常简单plain最终配置 values.yaml完整默认值 values-xxx.yaml只覆盖差异部分3.2 为什么覆盖文件那么短因为它们只写和默认值不一样的地方。假设values.yaml里有完整的默认配置yamlreplicaCount: backend: 3 web: 2 auth: 2 image: repository: ghcr.io/xxx/camp-backend tag: v1.0.0 backend: resources: requests: memory: 1Gi cpu: 500m limits: memory: 2Gi cpu: 1000m ingress: enabled: true host: camp.example.comvalues-dev.yaml只需要覆盖差异部分yamlreplicaCount: backend: 1 # 开发环境只要1个副本省资源 web: 1 auth: 1 backend: resources: requests: memory: 256Mi # 低配就行 cpu: 100m limits: memory: 512Mi cpu: 200m ingress: host: camp-dev.local # 本地域名注意image.repository、ingress.enabled等字段在values-dev.yaml里没有出现——因为它们和默认值一样不需要改。执行命令时bashhelm install camp ./camp --values values-dev.yamlHelm 会自动合并最终生效的就是默认值 开发环境补丁。3.3values-prod.yaml与 dev 完全相反的方向它和values-dev.yaml本质一样——都是覆盖文件。但方向完全相反Table维度values-dev.yaml降级values-prod.yaml升级副本数1 个省资源3~5 个高可用资源限制CPU/内存给最低配requests 和 limits 都大幅提高HPA 自动扩容关闭开启CPU 70% 自动扩容安全策略宽松NetworkPolicy 收紧、RBAC 细化监控告警基础或关闭Prometheus/Grafana 全开域名本地/内网正式公网域名 TLS 证书日志级别DEBUG方便排错INFO/WARNING减少噪音values-prod.yaml可能长这样yamlreplicaCount: backend: 5 web: 3 backend: resources: requests: memory: 2Gi cpu: 1000m limits: memory: 4Gi cpu: 2000m hpa: enabled: true minReplicas: 3 maxReplicas: 10 targetCPUUtilizationPercentage: 70 ingress: host: camp.company.com tls: enabled: true secretName: camp-tls执行bashhelm install camp ./camp --values values-prod.yaml最终生成的是能扛住真实流量的生产级配置。3.4 这样设计的好处Table好处说明DRY不重复自己通用配置只写一次在values.yaml不用复制 N 份维护简单升级镜像版本改values.yaml一处即可所有环境自动生效差异一目了然打开values-prod.yaml一眼看出生产环境和默认配置到底哪里不同减少人为错误不会因为漏复制某个字段导致 dev 和 prod 行为不一致灵活组合你可以随时创建values-staging.yaml、values-test.yaml零成本扩展新环境四、Chart.yamlHelm Chart 的身份证Chart.yaml不是 Kubernetes 资源不会交给kubectl执行而是专门给 Helm 工具自己看的元数据文件。Helm 靠它来识别、管理、分发这个 Chart。4.1 典型内容yamlapiVersion: v2 # Helm 3 固定写 v2 name: camp # Chart 的名字 description: Cloud Asset Management Platform Helm Chart type: application # 这是应用 Chart不是库 Chart version: 1.0.0 # Chart 自身的版本号 appVersion: 1.0.0 # 里面部署的应用版本号 # 如果有依赖其他 Chart写在这里 dependencies: - name: postgresql version: 12.x.x repository: https://charts.bitnami.com/bitnami condition: postgresql.enabled4.2 关键字段解析Table字段作用apiVersion: v2声明这是 Helm 3 格式的 ChartnameChart 的名字安装时默认的 release 名前缀typeapplication可部署的应用或library仅供其他 Chart 引用的模板库versionChart 包版本。每次改模板、改默认值这个版本要升级appVersion应用代码版本。比如后端镜像 tag 是v2.3.1这里就写2.3.1dependencies依赖的其他 Chart。比如你的应用需要 PostgreSQL不用自己写直接引用官方 Chart4.3 为什么需要它版本管理打包时生成camp-1.0.0.tgz版本号来自这里。仓库索引推送到 Helm 仓库后别人能搜索到bashhelm search repo camp # 显示camp 1.0.0 Cloud Asset Management Platform Helm Chart依赖解析自动下载 PostgreSQL、Redis 等依赖 Chart。区分Chart 更新和应用更新改了templates/deployment.yaml的 HPA 逻辑 → 升级versionChart 变了后端代码从v1.0.0升级到v2.0.0→ 升级appVersion应用变了五、完整使用示例bash# 1. 预览开发环境渲染结果 helm template camp ./camp --values ./values-dev.yaml # 2. 安装到开发环境 helm install camp-dev ./camp \ --namespace camp-dev \ --create-namespace \ --values ./values-dev.yaml # 3. 安装到生产环境 helm install camp-prod ./camp \ --namespace camp-prod \ --create-namespace \ --values ./values-prod.yaml # 4. 查看部署状态 helm list --all-namespaces helm status camp-prod -n camp-prod # 5. 升级修改配置后 helm upgrade camp-prod ./camp \ --namespace camp-prod \ --values ./values-prod.yaml # 6. 回滚到上一个版本 helm history camp-prod -n camp-prod helm rollback camp-prod 2 -n camp-prod # 7. 打包分享 helm package ./camp # 生成 camp-1.0.0.tgz六、总结从k8s/到helm/本质是从静态配置走向动态管理。记住这个公式Chart.yaml我是谁templates/模板骨架values.yaml默认值values-*.yaml环境补丁 生产级 Kubernetes 部署templates/让你写一次到处用values.yaml给你统一的基准values-dev.yaml和values-prod.yaml让你只改差异环境隔离Chart.yaml让 Helm 知道这个包叫什么、什么版本、依赖谁掌握这套机制你就从会写 Kubernetes YAML进阶到了会用 Helm 管理生产级多环境部署。下一步就是去挑战多集群部署和 GitOps 了。