为什么DevOps团队喜欢用Helm，将应用部署到容器集群？

微服务架构的采用改变了当今应用程序的开发方式。随着微服务架构取代单一架构，容器取代了虚拟机。但这种转换，给应用程序部署带来了挑战。容器编排因Kubernetes得到了改善。与此同时，与其他新技术一样，容器和Kubernetes也带来了新的复杂性。

其中，Kubernetes上部署和管理应用程序成为了IT团队新的困扰，但这并没有阻碍Kubernetes的不断增长，而且有越来越多的工具专注于解决应用程序部署的复杂性。这些工具同样以开源项目存在。Helm就是其中之一，它成功简化了Kubernetes的部署问题。

Helm最早是Deis容器厂商和Google共同创建（现在，Deis已经是微软的一部分），Helm在2016年成为了Kubernetes 1.4发行版的一部分。Helm通过Helm图表（Helm Charts）帮助IT团队管理Kubernetes应用程序。这些图表让IT团队可以定义，安装和升级最复杂的Kubernetes应用程序。

什么让Helm如此受欢迎？

尽管在Kubernetes上管理应用程序的问题很复杂，但Helm使用起来非常简单。

没有Helm：

IT团队依靠Kubernetes YAML文件来配置Kubernetes工作负载。这些YAML文件指定了部署容器所需的一切。在这些YAML文件中，必须提到从配置每个Pod的方式，到Kubernetes集群如何完成负载均衡的所有内容。因此，要设置新的Kubernetes工作负载，需要为该工作负载创建一个YAML文件。手动完成意味着写入多个YAML文件，即每个创建的工作负载一个YAML文件。

使用Helm：

不必为每个应用程序手动编写单独的YAML文件，只需创建一个Helm图表，然后让Helm将应用程序部署到集群中即可。Helm图表包含各种Kubernetes资源的模板，这些模板结合起来构成一个应用程序。将Helm图表部署到不同的Kubernetes集群时可以对其进行自定义。在创建Helm图表时，可以将特定于环境或部署的配置提取到单独的文件中，方便在部署Helm图表时指定这些值。比如，在开发和生产环境中部署应用程序不需要单独的图表。

Helm不断发展，并且每次进行新的升级，都使Kubernetes上的应用程序管理变得更加简单。Helm 3的推出，大大超出了DevOps团队的预期。

Helm3 Tiller

当启动Helm 2时，Kubernetes没有基于角色的访问控制（RBAC）。Helm包含一个名为Tiller的组件，该组件负责部署图表。但是，对于较新版本的Kubernetes，默认情况下会启用RBAC，并且Tiller允许用户绕过访问控制。因此，在Helm 3中删除了Tiller，最终消除了Helm的安全性薄弱环节，使其更加可靠和稳定。

Helm的好处

通过单击按钮或单个CLI命令，Helm图表可以利用Kubernetes软件包。还可以在其他Helm图表中包括Helm图表，并具有各种依赖关系。

Helm建立在Kubernetes之上。这些图表补充了Kubernetes的集群架构。在使用Helm将应用程序部署到Kubernetes时，可伸缩性从一开始就是默认的好处，因为Helm使用的所有容器镜像的图表都存储在一个名为Helm Workspace的注册表中，DevOps团队可以轻松查找该注册表并将其添加到他们的项目中。

Helm提供的另一个与众不同的功能是能够在部署期间自定义应用程序配置。DevOps团队可以为应用程序中包含的所有Kubernetes资源提供配置，并为这些资源配置所有特定于环境的需求。这使团队可以在多个环境中重用一个Helm图表。

所以，现在Helm是Kubernetes部署的必备条件。但是真正的好处在于它在简化CI/CD管道中所扮演的角色。

Helm自动维护发行版所有版本的数据库。因此，只要在部署过程中出现问题，回滚到以前的版本仅需一个命令。

Helm中有多个CI/CD integration hooks，使团队可以自动执行默认情况下的某些操作，如微软Office中的宏。在安装开始之前或升级完成之后，甚至可以安排对Helm的运行状况检查，以验证部署是否已成功完成。

故障排除和调试

Helm面临的最大挑战是复杂性。整个系统基于模板Helm图表，这使得创建和调试可能由多个Kubernetes资源组成的复杂应用程序变得非常困难。Helm图表越多，整个系统越复杂。想象一下，一个团队要花多少时间才能发现并解决Helm图表模板中的错误，该模板已在复杂应用程序的许多Kubernetes资源中多次使用。

学习曲线

Helm简化了Kubernetes集群的管理。但是，创建第一个Helm图表绝对不像键入一些命令那样简单。这个过程相当复杂，涉及到陡峭的学习曲线，可能需要一些时间才能让DevOps团队习惯。Helm尝试通过其有关如何完成工作的广泛文档来尽可能简化这项操作。

Helm的替代品

当谈到使用Kubernetes的CI/CD时，对于一种工具来说，能够完全解决所有情况显然不现实。Helm尝试简化应用程序部署，但有一些限制。如果Helm无法满足需求，可以尝试使用Helm的几种替代方法。

在所有的Helm替代产品中，Kustomize最受欢迎。Kustomize是一种无模板的方式，可以自定义应用程序配置和管理Kubernetes工作负载。在许多情况下，使用Helm进行模板制作可能会很复杂。开发人员倾向于根据需求同时使用Helm和Kustomize。关于哪个更好的问题，争议仍然存在。