微服务架构的引入彻底改变了当今软件的开发方式。 后微服务架构取代了单体，容器取代了虚拟机。 通过这种转换，构建应用程序因多个容器而变得复杂。 容器编排是一个新的瓶颈，被 Kubernetes 解决了。
在这个过程中，容器和 Kubernetes 带来了很多新的挑战。 最困难的是在 Kubernetes 上部署和管理应用程序。 正在开发一系列开源工具来简化该过程。 Helm 就是这样一种工具。
历史: Helm 的开端????
在社区中待了一年多之后，Kubernetes 终于在 2015 年夏天发布了第一个通用版本 1.0。致力于支持 Kubernetes 生态系统的企业 Deis 在其初始迭代中创建了 Helm。
在首届 KubeCon 上推出。 2016 年 1 月，该项目与名为 Kubernetes Deployment Manager 的 GCS 工具合并，该项目转移到 Kubernetes 下。 从一开始，Helm 就旨在充当包管理工具。 对于 Helm V4，Helm 目前正处于第四次迭代。 随着 Helm V3 的第三次迭代，由于减少了安全问题，它吸引了大量的采用。
Helm到底是什么？ ????
如果你是 javascript 或 python 开发者，你可以认为 Helm 相当于 npm 或 PyPI 。 包管理器的概念并不新鲜，如果你是 linux 用户，我敢肯定你已经使用过 apt/yum 来安装和卸载软件。
随着复杂服务的增长，仅使用一个 k8s 配置文件进行部署是行不通的。 随着 YAML 数量的增长，将这些 YAML 存储在哪里也成了一个问题。 Helm 可以帮助解决这些问题。
假设我们想要实现 Elastic Stack 来进行日志记录。 为此，我们需要编写 configmap、secret、stateful set、permissions 等。 编写所有这些有时会变得非常乏味，而且常常会增加出错的机会。 这样捆绑就完成了。 这些捆绑包称为 Helm Charts。
为什么 Helm 如此受欢迎？????
使用 Helm 的最大好处与 CI 和 CD 目标非常相似：可重复性和一致性。 想象一下，拥有还原代码的数百万用户使用的服务器，现金消耗量将是疯狂的。 此外，捆绑减少了出错的机会。 Helm 也称为模板引擎，有助于定义通用蓝图。 动态值被占位符取代，这有助于实现代码一致性和 POC。
最终使用 Helm 节省了开发时间。 它负责 CI/CD 管道，我们可以在其中专注于构建重要的东西。 使用 Helm，我们不再需要为堆栈中的每个应用程序构建单独的 YAML 文件。 Helm Charts 是高度可定制的，我们只需下载 Helm Chart 并将其与我们的 YAML 文件结合起来，因此我们不再需要从头开始构建所有内容。
Helm Developer 开发了 Helm Charts，以便每个人都可以使用它。 创建图表后，它会被推送到存储库中，然后由开发人员进一步使用。 开发人员使用 Helm 从存储库中拉取镜像，根据他们在定义自己的集群时使用的所需值进行修改。
不仅软件开发人员或开源项目可以使用 Helm 打包。 每个为日常目的安装软件的个人或组织都可以使用 Helm 打包。 随着 Kubernetes 投资的继续，使用包管理器可以降低协调包管理器中指定过程的复杂性和重复性。 具有发布管理功能的 Helm 还支持回滚附加组件，以防出现任何问题。
什么是 Helm 图表？ ????
Helm 图表是构成应用程序的 Kubernetes YAML 文件的捆绑包或集合。 Helm 操作的主要格式是 Chart。 Helm Charts 可以轻松存储在 Chart Repositories 中，因为它们是基于文件的并且遵循基于约定的目录结构。 图表可以安装和卸载到 Kubernetes 集群中。
Chart 的运行实例称为 Release，就像图像与其容器之间的关系一样。
Helm Chart 最终是一个可执行模板，可将 Chart 定义转换为 Kubernetes 清单。
Helm 图表在创建时必须具有版本号。 Helm Charts 可以引用其他 Charts 作为依赖项，这是任何包管理器的核心。 此外，还有私有和公共存储库，我们可以在其中存储 Helm Charts。
解密Helm图表 ????????♂️
使用单个 Helm Chart，Helm 允许我们为同一应用程序部署许多配置。 Helm 使用模板引擎完成此操作。 为了响应可以在 values.yaml 文件中修改的输入参数，模板引擎生成清单文件。
可以通过 Helm 创建和共享应用程序配置。 我们可以在 Artifact Hub 上搜索 Helm Charts，或者通过 helm search [keyword] 命令使用 cli。
我们还可以在 GitHub、GitLab、BitBucket 和相关平台上找到 Helm Charts。 这是经过验证的 Nginx Helm Chart。 现在，我们已经知道在哪里可以找到 Helm Charts，让我们深入了解 Helm Chart 的框架。
分解 Helm 图表????
Helm Charts 以模块化方式存储。 所有特定图表都有相似的目录。
有了这些部分，Helm 就可以在我们的 Chart 上执行了。 要了解 Helm Charts，我们需要了解 4 个基本构建块：
1️⃣ Chart.yaml 文件：这是我们放置有关我们正在打包的图表的所有信息的地方。 因此，例如，版本号等。这是我们将放置所有这些详细信息的地方。
2️⃣ Values.yaml 文件：这是我们定义要注入模板的所有值的地方。 Values.yaml 类似于 terraform 中的 variable.tf。
3️⃣ 图表：这是我们存储图表所依赖的其他图表的地方。 我们可能正在调用我们的图表正常运行所需的另一个图表。
4️⃣ Templates目录：该目录包含图表的模板文件，当它们与值结合时，它们生成有效的清单文件。
演练：让我们看看它是如何工作的????
要安装 Helm 命令，请使用支持的包管理器或简单地下载预编译的二进制文件。
使用 Helm init 命令安装 Tiller，开始将应用程序部署到纯 Kubernetes 集群中。
现在，Helm 可以特别以两种方式使用。 要么修改从网络上获取的帖子，要么从头开始创建。
从网络安装图表 ????
对于第一种方式，即从 Web 安装 Helm 图表，我们需要做两件事。
管理远程稳定存储库：
然后安装图表：
现在，如果我们想使用自定义 yaml 文件并覆盖一些值，我们只需要运行
在本地创建图表 ????????
使用 Helm 包非常简单。 编写 Helm 图表只是稍微复杂一点。 创建 Helm 图表涉及创建图表本身、配置图像拉取策略以及在 values.yaml 文件中指定其他详细信息。
使用创建图表命令初始化
发布运行命令并检查启动目录。 我们可以找到包含以下内容的图表目录：
根据需求配置好后，我们就可以部署了。 通过这种方式，Helm 图表简化了 Kubernetes 集群上的应用程序部署。
结论????
Helm 无疑是 K8s 包管理的未来。 Helm 不仅可以帮助想要在其上安装一些应用程序的开发人员，还可以帮助 DevOps 工程师，他们仍然可以创建 YAML 清单文件并使用 kubectl 命令进行部署。 使用模板引擎工程师可以专注于真正重要的事情，Helm 负责代码的一致性和冗余。
YAML 文件的捆绑最终减少了服务器应用程序的捆绑大小并增强了 CI/CD 流程。 此外，Helm 简化了 DevOps 学习曲线：我们不需要全面、详细地了解每个 Kubernetes 对象的功能即可开始开发和部署容器应用程序。 Helm 可轻松集成到 CI/CD 管道中，并允许软件工程师专注于编写代码而不是部署应用程序。