Kubernetes 包管理器 Helm 现在由 CNCF 托管

本月早些时候，云原生计算基金会（CNCF）技术监督委员会（TOC）投票决定接受 Helm 作为孵化器托管项目。 Helm 是一个软件包管理器，提供了一种“简单的方法来查找、共享和使用为 Kubernetes 而构建的软件”。

自 2016 年 2 月起，Helm 作为 Kubernetes CNCF 托管项目的子项目存在。该项目由 Deis（于 2017 年被微软收购）发起并与谷歌的 Kubernetes 部署管理器合并成为 Kubernetes Helm。 CNCF 在博文中宣布将 Helm 作为独立项目托管，并表示，“随着Kubernetes 将重点转移到自己的核心，以更好地管理增长，CNCF 是Helm 的理想家园，可以让开发人员和运营商继续更容易地简化Kubernetes 部署”。

从概念上讲，Helm 与Debian 的APT、Red Hat 的Yum 和MacOS 的Homebrew 等操作系统的软件包管理器类似，它将文件复制到文件系统适当的位置，适当地设置权限，并配置应用程序应该如何初始化和运行。 Helm 的打包格式（称为 chart ）是一组描述相关 Kubernetes 资源的文件集合。chart 为带有特定目录树中结构的文件，可以被打包成带有版本的压缩包进行部署。

三星 SDS 高级工程师及 Kubernetes Special Interest 小组联合创始人 Matt Farina 写了一篇翔实的博文，解释了软件包管理器 Helm 可用在 Kubernetes 工具生态系统的哪些地方。Farina 指出，Helm 是“与 apt 相类似的软件包管理器”，从概念方面看，它位于其他抽象之上，如 ELF 二进制文件和存储在系统特定目录（“/etc”和“/opt”）里的配置文件。他还指出，与使用操作系统配置管理工具来管理高级应用程序一样，如 Chef、Puppet 和 Ansible，从概念上看，还有其他项目位于 Helm 的上层，包括 helmfile 、 armada 、 landscaper 等。

包含Operator 的Kubernetes 管理结构栈（图片来自 Matt Farina 的博客）

Farina 还写道，有很多运维人员在想知道为什么他们需要使用像 Helm 这样的软件包管理器来管理 Kubernetes 应用程序。很大一部分原因是为了共享可重用的应用程序专业知识。

如果你是典型的应用程序运维人员，那么你关心的是应用程序，而不是运行应用程序的平台或应用程序的依赖项。

他列举了三个要考虑的事项：

• 管理分布式应用程序特定的运维专业知识——开发人员可以依赖专业人士提供的软件包，因此无需拥有该软件包，可专注于自己特定的业务需求。

• 可重用的组织包——定制包，公司的运维专家将它们放在一起，可以在本地、测试环境和生产环境中运行。

• 应用程序的特定配置——在进行应用程序运维时，要关注应用程序，它们会有不同的配置需求。

需要指出的是，Helm 只是解决 Kubernetes 软件包管理和应用程序安装问题的一个解决方案，Shahidh K Muhammed 在另一篇叫作“ Draft vs Gitkube vs Helm vs Ksonnet vs Metaparticle vs Skaffold ”的博文中探讨了其他替代方案。

对这一领域感兴趣的读者也熟悉一下最初由 CoreOS 团队（现已被红帽公司收购）定义的 Operator 模式，该模式定义了一种机制来“可靠地创建、配置和管理 Kubernetes 上的复杂应用实例”。Operator 由 Kubernetes定制资源（有时称为定制资源定义）和定制控制器组成。Shopify 是一个大型电子商务平台，广泛使用了定制控制器。Niko Kurtti 将在即将到来的QCon 纽约大会上发表演讲“ Forced Evolution：Shopify’s Journey to Kubernetes ”，深入探讨这一问题。

有关 Helm 的更多信息，请访问 https://helm.sh/ 。这里有一个 KubeCon/CloudNativeCon 2017 大会的演讲视频，叫作“ Building Helm Charts From the Ground Up ”，演讲者 Amy Chen 在视频中讨论了如何构建 Helm 的 chart，该视频可在 CNCF 的 YouTube 频道上找到。

查看英文原文： Kubernetes Package Manager Helm Now Hosted by the CNCF