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