Helm 通过六年来最大规模的版本发布，提升了 Kubernetes 的包管理能力

Helm（Kubernetes 应用程序包管理器）正式发布4.0.0版本。Helm 4 是六年来的首次重大升级，也标志着 Helm 在云原生计算基金会（CNCF）的指引下迎来了其十周年纪念。本次更新旨在解决可扩展性、安全性和开发工作流等方面的多项挑战。

Helm 4 的 SDK 有几项功能增强，旨在增强集成和开发体验。它采用现代 Go 日志接口支持多日志记录器，并通过可嵌入命令将 Helm 的功能直接嵌入到其他应用程序中。现在，Helm 4 还原生支持 server-side apply（SSA）（这是 Kubernetes 的一个特性，将 kubectl apply 命令的逻辑移到 API 服务器中）。这一变化反映了 Kubernetes 生态系统中广泛存在的一个发展趋势，确保基于 Helm 构建的集成方案既功能强大又符合现代集群行为。

插件系统也已经重新构建：传统 Helm 插件仍然有效，但现在用户还可以编写 WebAssembly（WASM）插件，实现了更广泛的可移植性。此外，图表分发、性能以及图表签名和自动化测试机制也有所改进。

Helm 联合创始人 Rimantas Mocevicius 在博文中指出，这些变化既反映了新特性，也反映了对 Helm v3 时代积累的设计债务的重新审视。

作为指引 Helm 4 发展的提案，HIP-0012（Helm 改进提案）制定了明确的时间表：2024 年末启动规划阶段，2025 年中完成工程开发，2025 年 11 月正式发布。该提案特别强调，团队应在合理的时间内交付开发的功能，同时谨慎引入破坏性更改。路线图涵盖了针对 Kubernetes 集成的改进，包括 server-side apply（SSA）、现代化插件架构及图表 API 优化。同时，通过改进流程，明确并解决了贡献者参与度不足与维护积压等问题。

从更广泛的用户视角来看，Jimmy Song 在其博客中指出，此次发布使 Helm“超越了模板工具的范畴”，并实现了现代化升级。他认为，添加 SSA 使其与 GitOps 方法高度契合，而可重现构建、WASM 插件支持以及 kstatus 等状态解析工具的引入，则使其与现代 Kubernetes 范式保持了同步。Song 认为，这些变革意味着 Helm 正从单纯的图表渲染器转型为真正的部署编排器。

Helm 生态系统中颇具争议的其中一个问题是支持自定义资源定义（CRD）。有一项旨在增强 CRD 更新行为的提案已经提交，其中包括合并新版本、追加到版本列表、保留元数据以及确保回滚路径向后兼容。然而，截至 Helm 4 初始版本发布时，这些提案尚未被采纳。在安装图表时，Helm 仍会将 CRD 放置于专用的”crds/“目录中，但不会通过常规升级流程升级或删除 CRD。现有文档已明确指出：升级位于 crds 文件夹中的 CRD 仅会触发警告提示，不会被实际应用。

社区反馈反映出人们对这一遗漏的失望。在发布后不久的一项Reddit讨论中，有用户询问 CRD 行为是否有所改进。一位用户评论说：“CRD 方面仍然没有改进？“这说明 Helm 仍然无法安全地管理 CRD 生命周期。另一位用户报告说，他们组织里的工具和 CLI 工作流依赖于基于注解的 CRD，适应 Helm CRD 逻辑中的任何变化都将非同小可。

有其他评论（如来自Heinan Cabouly的评论）指出，像 Argo CD 这样的 GitOps 工具早在数年前就已经弥补了 Helm 最显著的工作流缺陷，暗示 Helm 4 的更新更像是追赶潮流而非开创性变革。然而，Helm 4 仍然被公认为是一个重要的里程碑，它提升了项目的长期可行性，而不是一个增量补丁。

从业者者和博主们对 Helm 4 部署安全性的提升表示欢迎，特别是新增的基于就绪状态的控制机制，这能减少发布过程中相互依赖的组件间的竞争条件。Enix撰稿人Pierre-Louis Gueugnon 盛赞其更加智能的基于内容的图表缓存和性能优化，对于频繁进行大规模部署的团队而言，这些改进将大幅提升他们的生活质量。

展望未来，Helm 维护者已明确表示，未被 v4 采纳的功能可能在次要版本甚至 Helm 5 中进行考虑。社区将密切关注 CRD 升级何时能达到足以广泛采用的程度——安全、稳定且文档完善。

原文链接：

https://www.infoq.com/news/2025/11/helm-4/