客座文章之前由Spruha Pandya在Nirmata博客上发表
微服务架构的采用已经彻底改变了今天开发应用程序的方式。随着微服务架构取代了单体架构，容器取代了VM。然而，通过这种转换，应用程序部署不再是一项简单的任务。容器编排是一个新的挑战，Kubernetes解决了这个问题。就像任何新技术一样，容器和Kubernetes带来了新的复杂性。
在所有的挑战中，在Kubernetes上部署和管理应用程序已被证明是IT团队最困难的一个。但是，由于Kubernetes的巨大成功，有越来越多的工具集中在解决应用程序部署的复杂性上。这些工具中的大多数作为开源项目存在，由开发人员社区维护。Helm就是这样一个开源项目，自2016年以来，它成功地简化了Kubernetes用户的生活。
Helm是Deis（一家容器工具公司，现在是微软的一部分）和谷歌共同努力的结果。这是2016年发布的Kubernetes 1.4的一部分。Helm帮助IT团队通过Helm Chart管理Kubernetes应用程序。这些chart可以让团队定义、安装和升级最复杂的Kubernetes应用程序。
是什么让Helm如此受欢迎？
虽然在Kubernetes上管理应用程序的问题可能很复杂，但Helm本身使用起来相当简单。下面是一个典型的视图，说明在没有helm的情况下部署是如何发生的，以及helm是如何简化部署的。
没有Helm：
团队依赖Kubernetes YAML文件来配置Kubernetes工作负载。这些YAML文件指定了部署容器所需的所有内容。从需要配置每个Pod的方式到Kubernetes集群如何实现负载平衡，所有内容都必须在这些YAML文件中提到。因此，要设置新的Kubernetes工作负载，需要为该工作负载创建一个YAML文件。手动操作意味着要编写多个YAML文件——为创建的每个工作负载编写一个。
Helm：
不必为每个应用程序手动编写单独的YAML文件，只需创建一个Helm chart，让Helm为你将应用程序部署到集群。Helm chart包含组合成应用程序的各种Kubernetes资源的模板。在部署到不同的Kubernetes集群时，可以定制Helm chart。在创建Helm chart时，可以将特定于环境或部署的配置提取到单独的文件中，以便在部署Helm chart时指定这些值。例如，在开发、登台（staging）和生产环境中部署应用程序不需要单独的chart。
随着时间的推移，随着每次新的升级，Helm已经使Kubernetes上的应用程序管理变得更加简单。随着最近发布的Helm 3，它带来的好处已经超过了DevOps社区的预期，并且很高兴地将它添加到部署Kubernetes应用程序的必备工具列表中。
Helm 3 - 别了，Tiller
当Helm 2发布时，Kubernetes还没有基于角色的访问控制（Role-Based Access Control，RBAC）。Helm包括一个称为Tiller的组件，负责部署chart。但是，在Kubernetes的新版本中，RBAC是默认启用的，而Tiller允许用户绕过访问控制。因此，在Helm 3中，Tiller被移除，最终消除了Helm的安全薄弱环节，使其更加可靠和稳定。
Helm的好处：
- Helm chart提供了通过单击按钮或单个CLI命令来利用Kubernetes包的能力。你还可以在其他Helm chart中包含Helm chart，并拥有各种依赖关系。
- Helm chart是建立在Kubernetes之上。这些chart补充了Kubernetes的集群架构。当使用Helm将应用程序部署到Kubernetes时，可伸缩性是从一开始就具有的一个默认优势，因为Helm使用的所有容器镜像chart都存储在名为Helm Workspace的注册表中，DevOps团队可以轻松查找并将其添加到他们的项目中。
- Helm提供的另一个独特特性是在部署期间定制应用程序配置的能力。DevOps团队可以为应用程序中包含的所有Kubernetes资源提供配置，并为这些资源配置所有特定于环境的需求。这使得团队能够在多个环境中重用一个Helm chart。
- 很明显，Helm是Kubernetes部署的一个必须。但真正的好处在于它在简化CI/CD流水线方面所扮演的角色。
- Helm会自动维护一个包含所有版本的数据库。因此，只要在部署过程中出现错误，只需一个命令就可以回滚到以前的版本。
- Helm中有几个CI/CD集成钩子，它们允许团队在默认情况下自动执行某些操作，就像Microsoft office中的宏一样，例如，在安装开始之前或升级完成之后。你甚至可以为Helm安排运行状况检查，以验证部署是否已成功完成。
即使有了这些好处，Helm3也不全是彩虹和阳光……
- 故障诊断和调试
Helm面临的最大挑战是复杂性。整个系统基于Helm chart模板，这使得创建和调试可能包含多个Kubernetes资源的复杂应用程序变得非常困难。Helm chart越多，整个系统就越复杂。想象一下，在一个复杂应用程序中，在多个Kubernetes资源中多次使用的Helm chart模板中发现并解决一个bug需要多少时间。
- 学习曲线
Helm简化了Kubernetes集群的管理。但是，创建第一个Helm chart绝对不像输入几个命令那么简单。这个过程相当复杂，涉及到一个陡峭的学习曲线，DevOps团队可能需要一些时间来适应。Helm试图通过它关于如何完成工作的大量文档尽可能地简化这一点。
Helm的替代品
当涉及到Kubernetes的CI/CD时，如何让工具很好地处理所有场景是一个挑战。Helm试图简化应用程序部署，但有一些限制。如果Helm不能满足你的需求，你可能想要探索几种替代方案。
在所有Helm的替代品中，Kustomize是最受欢迎的。Kustomize是一种无模板的定制应用程序配置和管理Kubernetes工作负载的方法。在一些实例中，使用Helm的模板可能会很复杂。这就是Kustomize来拯救你的时候。开发人员倾向于同时使用Helm和Kustomize，这取决于他们的需求。至于这两个中哪一个更好，还没有定论。
总结
此外，在开始部署容器时还要记住一件事——不要忽略全局。DevOps用户需要根据自己的需求灵活地选择合适的工具。但是确保你了解这些工具的局限性也是很重要的，这样你的项目才不会被拖延或延迟。在打包应用程序时，Helm绝对是一个流行的工具，它也是容器管理平台（如Nirmata）最广泛支持的工具。
Kubernetes在应用程序生命周期的第0和第1阶段提供了许多优势。然而，大多数组织发现它缺乏关键的第2天功能，如可靠性、安全性和风险管理。下载第2天Kubernetes白皮书，了解这些挑战，以及如何最大化你的成功与Kubernetes。
CNCF (Cloud Native Computing Foundation)成立于2015年12月，隶属于Linux Foundation，是非营利性组织。
CNCF（云原生计算基金会）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。扫描二维码关注CNCF微信公众号。
