Helm通过六年来最大规模的版本发布，提升了Kubernetes的包管理能力
Source: InfoQ - Cloud
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升级何时能达到足以广泛采用的程度——安全、稳定且文档完善。
原文链接：