本文基于 GitHub 项目 helm/helm 的源码结构、官方文档及最新发布信息全面剖析 Helm 的核心概念、架构设计、版本演进、实战用法及生态定位。截至撰写时Helm 最新稳定版为v4.2.32026 年 7 月发布累计获得超过30,100 个 GitHub Star和7,700 个 Fork。一、引言为什么 Kubernetes 需要 Helm在 Kubernetes 生态中部署一个真实应用通常涉及 Deployment、Service、ConfigMap、Secret、Ingress 等多种资源类型的 YAML 清单。当应用规模从单个微服务扩展到包含数据库、缓存、消息队列的复合系统时手写和维护这些 YAML 文件会迅速变成一场管理噩梦。Helm 的诞生正是为了解决这一痛点。它将自身定位为“Kubernetes 的包管理器”类似于 Linux 世界中的apt、yum或homebrew。通过将一组 Kubernetes 资源打包成可版本化、可分发、可依赖管理的单元ChartHelm 实现了一键安装复杂应用如 Prometheus、Redis、MySQL 等版本管理与一键回滚配置参数化同一 Chart 适配多环境依赖管理自动拉取子 Chart仓库分发通过 HTTP(S) 或 OCI 注册表共享二、项目概览维度信息仓库地址https://github.com/helm/helm官网https://helm.sh开源协议Apache-2.0编程语言Go所属组织CNCF云原生计算基金会GitHub Star30,100当前稳定版v4.2.32026-07-09v3 支持状态Bug 修复至 2026-07-08安全修复至 2026-11-11源码目录结构helm/ ├── cmd/helm/ # CLI 入口helm 命令行工具的 main 包 ├── internal/ # 内部实现不对外暴露的包 ├── pkg/ # 公共包SDK API 对外暴露的核心库 ├── scripts/ # 构建、安装等辅助脚本 ├── testdata/ # 测试数据 ├── Makefile # 构建入口 ├── go.mod / go.sum # Go 模块依赖声明 ├── .goreleaser.yaml # 发布配置GoReleaser ├── .golangci.yml # 代码检查配置 └── ADOPTERS.md # 采纳者列表这一结构遵循了 Go 项目的经典布局cmd/放命令入口pkg/放可复用的公共库internal/放私有实现。Helm 的 SDK 使用者可以直接引用pkg/下的包来在代码中调用 Helm 功能。三、核心概念Helm 围绕四个核心概念构建其包管理体系1. Chart图表Chart 是 Helm 的打包单元是一组 Kubernetes 资源描述文件的集合。一个 Chart 的典型目录结构如下myapp/ ├── Chart.yaml # Chart 元数据名称、版本、描述等 ├── values.yaml # 默认配置值 ├── charts/ # 子 Chart 依赖打包时会被一起归档 ├── templates/ # Go 模板文件目录 │ ├── deployment.yaml │ ├── service.yaml │ ├── configmap.yaml │ └── _helpers.tpl # 模板辅助函数 ├── crds/ # 自定义资源定义可选 └── README.md # 说明文档Chart 使用SemVer 2语义化版本规范进行版本管理。Chart.yaml中必须包含apiVersion当前主流为v2和version字段。2. Config配置Config 是一组可合并到 Chart 中的配置信息。最常见的形式是values.yaml文件它为模板中的变量提供默认值。用户可以在安装时通过--set或-f参数覆盖这些默认值从而实现同一 Chart 在不同环境开发、测试、生产下的差异化部署。3. Release发布Release 是 Chart 与特定 Config 结合后在 Kubernetes 集群中运行的实例。每次helm install都会创建一个新的 Release并分配一个唯一的 Release 名称。Release 支持升级helm upgrade、回滚helm rollback和卸载helm uninstall形成完整的生命周期管理。4. Repository仓库Chart Repository 是存储和共享 Chart 的远程服务。它本质上是一个 HTTP(S) 服务器提供一个index.yaml文件列出所有可用 Chart 及其版本。Helm v3 起原生支持OCI 注册表如 Docker Registry作为 Chart 仓库v4 进一步增强了 OCI 支持允许基于 digest 的安装方式helminstallmyapp oci://registry.example.com/charts/appsha256:abc123...digest 不匹配时将阻止安装显著提升了供应链安全。四、架构演进从 v2 到 v3 再到 v4Helm 的架构经历了三次重大变革每一次都深刻影响了其使用方式和安全模型。Helm v2Client Tiller 的双组件架构Helm v2 采用客户端-服务端架构┌──────────────┐ gRPC ┌──────────────┐ REST/JSON ┌──────────────┐ │ Helm Client │ ◄──────────────► │ Tiller Server│ ◄───────────────► │ K8s API │ │ (用户终端) │ │ (集群内 Pod) │ │ Server │ └──────────────┘ └──────────────┘ └──────────────┘Helm Client运行在用户本地或 CI/CD 中负责本地 Chart 开发、仓库管理、发送指令给 Tiller。Tiller Server运行在 Kubernetes 集群内部的 Pod 中接收 Client 的 gRPC 请求将 Chart 与 Config 合并生成 Release然后通过 Kubernetes API 进行实际的资源创建、更新和删除。Tiller 带来的问题Tiller 通常以高权限 ServiceAccount 运行在多租户集群中构成安全隐患RBAC 配置复杂权限边界模糊增加了集群内的攻击面Helm v3Tillerless 架构2019 年 11 月Helm v3 的最大变化是彻底移除了 Tiller┌──────────────┐ kubeconfig ┌──────────────┐ │ Helm Client │ ◄────────────────► │ K8s API │ │ (用户终端) │ REST/JSON │ Server │ └──────────────┘ └──────────────┘v3 的 Helm 客户端直接读取kubeconfig配置文件通常位于$HOME/.kube/config像kubectl一样直接与 Kubernetes API Server 通信。这一改变带来了安全性提升不再需要集群内的特权 Pod权限完全由用户的 kubeconfig 和 Kubernetes RBAC 控制部署简化无需helm init初始化 Tiller下载二进制即可使用Release 存储变更Release 记录从 Tiller 的内存/ConfigMap 迁移到集群内的 Secretv3 默认按 Namespace 隔离Helm v4现代化重构2025 年 11 月Helm v4.0.0 于2025 年 11 月 12 日正式发布这是继 v3 之后的首次主版本升级。v4 在保持 v3 Tillerless 架构的基础上进行了全面的现代化改造┌────────────────────────────────────────────────┐ │ Helm v4 Client │ │ │ │ ┌──────────┐ ┌──────────┐ ┌──────────────┐ │ │ │ Template │ │ Plugin │ │ OCI / │ │ kubeconfig │ │ Engine │ │ System │ │ Repository │ │ ◄──────────────► K8s API Server │ │(GoSprig) │ │(CLIWASM)│ │ Client │ │ │ └──────────┘ └──────────┘ └──────────────┘ │ │ │ │ ┌──────────────────────────────────────────┐ │ │ │ kstatus Resource Monitor │ │ │ │ (Server-Side Apply Support) │ │ │ └──────────────────────────────────────────┘ │ └────────────────────────────────────────────────┘v4 核心新特性全新插件系统引入可选的WebAssemblyWASM插件运行时支持 CLI 插件、Getter 插件和 Post-renderer 插件三种类型为安全沙箱化扩展创造了空间。现有插件仍可向后兼容使用。Server-Side Apply 支持解决多工具如 Operator、Flux、ArgoCD同时管理同一资源时的冲突问题。Server-Side Apply 允许 Kubernetes 跟踪字段所有权避免 Helm 与其他控制器的写入冲突。kstatus 资源监控引入基于 kstatus 的资源状态计算引擎使 Helm 能更准确地判断部署是否就绪在处理复杂应用如有就绪条件的 CRD时表现更好。Post-renderer 插件化--post-renderer不再允许直接传入可执行文件路径必须指定已注册的插件名称。这是 v4 的破坏性变更之一。增强的 OCI 支持支持基于 digest 的安装digest 不匹配将阻止安装提升供应链安全。可复现构建相同的 Chart 输入产生完全一致的归档包增强供应链一致性。slog 日志集成使用 Go 1.21 引入的slog包实现结构化日志。多文档 values 文件values 文件可由多个 YAML 文档构成适合复杂多配置场景。自定义模板函数可通过插件扩展 Helm 模板函数库。CLI 旗标重命名--atomic→--rollback-on-failure--force→--force-replace旧旗标暂时兼容但会打印弃用警告。兼容性ChartapiVersion v2继续受支持现有 Chart 在 v4 中可正常安装和升级。五、实战指南5.1 安装 Helm# macOSbrewinstallhelm# WindowswingetinstallHelm.Helm# 或chocoinstallkubernetes-helm# Linux (脚本安装)curl-fsSL-oget_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-4chmod700get_helm.sh ./get_helm.sh5.2 添加仓库并安装 Chart# 添加 Bitnami 仓库helm repoaddbitnami https://charts.bitnami.com/bitnami helm repo update# 搜索 Redis Charthelm search repo redis# 安装 Redishelminstallmy-redis bitnami/redis\--setauth.passwordmy-secret-password\--setreplica.replicaCount3\--namespacecache --create-namespace# 查看 Release 状态helm status my-redis-ncache# 列出所有 Releasehelm list-A5.3 创建自定义 Charthelm create my-app生成的values.yaml核心字段# values.yamlreplicaCount:1image:repository:nginxpullPolicy:IfNotPresenttag:1.27service:type:ClusterIPport:80ingress:enabled:falseclassName:hosts:-host:chart-example.localpaths:-path:/pathType:ImplementationSpecificresources:limits:cpu:500mmemory:256Mirequests:cpu:250mmemory:128Mitemplates/deployment.yaml中的 Go 模板示例apiVersion:apps/v1kind:Deploymentmetadata:name:{{.Release.Name}}-deploymentlabels:app:{{.Chart.Name}}spec:replicas:{{.Values.replicaCount}}selector:matchLabels:app:{{.Chart.Name}}template:metadata:labels:app:{{.Chart.Name}}spec:containers:-name:{{.Chart.Name}}image:{{ .Values.image.repository }}:{{ .Values.image.tag }}ports:-containerPort:{{.Values.service.port}}{{-if .Values.resources}}resources:{{-toYaml .Values.resources|nindent 12}}{{-end}}模板中可使用的内置对象包括对象说明.ReleaseRelease 实例信息名称、命名空间、版本等.Valuesvalues.yaml 中的值可被--set/-f覆盖.ChartChart.yaml 中的元数据.FilesChart 中的文件内容.CapabilitiesKubernetes 集群能力信息API 版本等.Template当前模板的元信息5.4 升级、回滚与卸载# 升级 Release修改 values 或 Chart 版本helm upgrade my-redis bitnami/redis\--setreplica.replicaCount5\-ncache# 查看历史版本helmhistorymy-redis-ncache# 回滚到上一个版本helm rollback my-redis1-ncache# 卸载helm uninstall my-redis-ncache5.5 打包与分发# 语法检查helm lint my-app/# 打包为 tgz 归档helm package my-app/# 推送到 OCI 注册表helm push my-app-0.1.0.tgz oci://registry.example.com/charts六、Helm 在云原生生态中的定位Helm 不是孤立存在的工具它深度嵌入在云原生生态的多个关键环节GitOps 工具链ArgoCD和Flux等 GitOps 控制器原生支持 Helm Chart 作为应用源。开发者将values.yaml提交到 Git 仓库GitOps 控制器自动拉取 Chart 并同步到集群实现声明式持续部署。CI/CD 流水线在 Jenkins、GitHub Actions、GitLab CI 等流水线中Helm 常被用于部署阶段# GitHub Actions 示例-name:Deploy to Kubernetesrun:|helm upgrade --install my-app ./my-app-chart \ --values values-prod.yaml \ --namespace production \ --atomic --timeout 5m生态仓库Artifact Hub 是 CNCF 支持的云原生包发现平台收录了数千个 Helm Chart涵盖数据库MySQL、PostgreSQL、Redis、监控Prometheus、Grafana、服务网格Istio、消息队列Kafka、RabbitMQ等几乎所有主流云原生组件。Kubernetes 发行版与平台几乎所有主流 Kubernetes 平台EKS、GKE、AKS、Rancher、OpenShift都以某种方式集成或推荐使用 Helm 进行应用部署。Azure Defender for Containers 的传感器甚至通过 Helm 进行部署。七、Helm vs Kustomize如何选择Kustomize 是 Kubernetes 生态中另一个流行的配置管理工具已于 Kubernetes 1.14 起内置到kubectl。两者在设计哲学上有根本性差异维度HelmKustomize核心定位包管理器类似 apt/yum声明式配置叠加器工作原理Go 模板渲染 变量注入Base Overlay 的 YAML 补丁覆盖配置控制强管控仅允许修改预定义变量弱管控自由修改任意字段模板引擎Go 模板条件、循环、函数无模板纯 YAML 合并版本管理内置 Release 版本与回滚需依赖 Git 等外部工具依赖管理内置子 Chart 依赖机制无原生支持包分发Chart 仓库HTTP/OCI无仓库概念多环境适配多份 values.yaml原生 Overlay 目录结构kubectl 集成需独立安装内置kubectl apply -k学习曲线中等需掌握模板语法较低仅需 YAML 基础选择建议选 Helm需要打包分发标准化应用如 MySQL、Prometheus需要版本控制与回滚跨团队共享 Chart使用 GitOps 工具链。选 Kustomize需要快速修改已有 YAML 的少量字段如镜像版本、副本数遗留系统迁移不想引入模板化轻量级需求零额外安装成本。两者结合实践中常见先用 Helm 部署标准化组件再用 Kustomize 对特定环境做微调覆盖社区有helm-convert等插件辅助转换。八、版本路线图与社区当前版本状态Helm v4main分支当前稳定版最新 v4.2.32026-07-09后续 v4.3.0 计划于 2026 年 9 月发布Helm v3dev-v3分支维护模式Bug 修复截止 2026-07-08安全修复截止 2026-11-11。v3.22.0 将是最后一个 v3 功能版本社区参与渠道链接/说明Kubernetes Slack#helm-users、#helm-dev、#charts邮件列表cncf-helmlists.cncf.io开发者会议每周四 9:30-10:00 太平洋时间Chart 发现Artifact Hub贡献指南CONTRIBUTING.md从 v3 迁移到 v4 的关键注意事项Post-renderer必须从直接可执行文件路径改为插件名称CLI 旗标更新--atomic→--rollback-on-failure--force→--force-replace插件测试全面测试 CLI、Getter、Post-renderer 三类插件Server-Side Apply如启用需测试与现有 Operator/控制器的兼容性SDK 使用者v4 SDK API 已重构并稳定化需重新验证CI/CD 脚本检查所有 helm 命令中的旗标和参数九、总结Helm 自 2016 年作为 CNCF 孵化项目诞生以来已经从最初的 Helm Classic → v2ClientTiller→ v3Tillerless演进到今天的v4现代化重构。它始终围绕一个核心理念——让 Kubernetes 应用的打包、分发和管理像操作系统包管理器一样简单。Helm v4 通过引入 WASM 插件运行时、Server-Side Apply、kstatus 资源监控、增强 OCI 支持和可复现构建等特性在安全性、可扩展性和现代化体验上迈出了重要一步。同时对 v2 Chart 格式的向后兼容确保了迁移成本可控。对于任何在 Kubernetes 上运行复杂应用的团队Helm 都是值得掌握的基础工具。无论你是使用现成的社区 Chart 快速部署基础设施还是为自己的微服务编写自定义 Chart 实现标准化交付Helm 都能显著降低 Kubernetes 应用管理的复杂度。参考资料Helm GitHub 仓库: https://github.com/helm/helmHelm 官方文档: https://helm.sh/docsHelm v4.0.0 发布分析: https://cloud.tencent.com/developer/article/2604364Helm Releases 页面: https://github.com/helm/helm/releasesArtifact Hub (Chart 搜索): https://artifacthub.io