介绍 Helm 3

笔记。 翻译。：今年 16 月 3.0 日标志着 Kubernetes 包管理器 Helm 开发的一个重要里程碑。 这一天，该项目未来主要版本的第一个 alpha 版本 - XNUMX - 发布了。 它的发布将为 Helm 带来期待已久的重大变化，Kubernetes 社区的许多人对此寄予厚望。 我们自己就是其中之一，因为我们积极使用 Helm 进行应用程序部署：我们已将其集成到我们用于实施 CI/CD 的工具中 韦尔夫 不时为上游的发展做出自己的贡献。 此翻译结合了来自 Helm 官方博客的 7 个注释，这些注释致力于 Helm 3 的第一个 alpha 版本，并谈论该项目的历史和 Helm 3 的主要功能。它们的作者是 Microsoft 员工 Matt “bacongobbler” Fisher也是 Helm 的主要维护者之一。

15 年 2015 月 2 日，现在称为 Helm 的项目诞生了。 成立仅一年后，Helm 社区就加入了 Kubernetes，同时积极致力于 Helm 2018。XNUMX 年 XNUMX 月，Helm 加入 CNCF 作为一个正在开发（孵化）的项目。 快进到现在，新 Helm 3 的第一个 alpha 版本即将发布。 （本次发布 已经发生了 五月中旬 - 大约。 译）.

在本文中，我将讨论这一切的起点、我们如何走到今天的位置、介绍 Helm 3 第一个 alpha 版本中提供的一些独特功能，并解释我们计划如何进一步开发。

摘要：

• Helm 的创建历史；
• 向蒂勒温柔地告别；
• 图表存储库；
• 发布管理;
• 图表依赖性的变化；
• 图书馆图表；
• 接下来呢？

头盔的历史

分娩

Helm 1 最初是由 Deis 创建的开源项目。 我们是一家小型初创公司 吸收 微软，2017 年春季。 我们的另一个开源项目，也称为 Deis，有一个工具 deisctl，它被用来（除其他外）安装和操作 Deis 平台 舰队集群。 当时，Fleet 是最早的容器编排平台之一。

2015 年中，我们决定改变路线，将 Deis（当时更名为 Deis Workflow）从 Fleet 迁移到 Kubernetes。 第一个重新设计的是安装工具。 deisctl。 我们用它来安装和管理 Fleet 集群中的 Deis Workflow。

Helm 1 是按照 Homebrew、apt 和 yum 等著名包管理器的形象创建的。 其主要目标是简化在 Kubernetes 上打包和安装应用程序等任务。 Helm 于 2015 年在旧金山 KubeCon 会议上正式推出。

我们对 Helm 的第一次尝试取得了成功，但也存在一些严重的限制。 他采用了一组 Kubernetes 清单，并使用生成器作为介绍性 YAML 块 （前题）*，并将结果加载到 Kubernetes 中。

* 笔记。 翻译。：从 Helm 第一个版本开始，选择 YAML 语法来描述 Kubernetes 资源，在编写配置时支持 Jinja 模板和 Python 脚本。 我们在“Helm 简史”一章中详细介绍了这一点以及 Helm 第一个版本的总体结构 这种材料.

例如，要替换 YAML 文件中的字段，您必须将以下构造添加到清单中：

#helm:generate sed -i -e s|ubuntu-debootstrap|fluffy-bunny| my/pod.yaml

今天模板引擎的存在真是太好了，不是吗？

由于多种原因，这个早期的 Kubernetes 安装程序需要一个硬编码的清单文件列表，并且只执行一小部分固定的事件序列。 由于使用起来非常困难，Deis Workflow 研发团队在尝试将产品转移到这个平台时遇到了困难——然而，这个想法的种子已经播下。 我们的第一次尝试是一个很好的学习机会：我们意识到我们真正热衷于创建实用的工具来解决用户的日常问题。

基于过去错误的经验，我们开始开发 Helm 2。

制作头盔 2

2015年底，Google团队联系了我们。 他们正在为 Kubernetes 开发类似的工具。 Kubernetes 的 Deployment Manager 是用于 Google Cloud Platform 的现有工具的端口。 “我们愿意，”他们问道，“花几天时间来讨论相似点和不同点吗？”

2016 年 2 月，Helm 和部署管理器团队在西雅图会面交流想法。 谈判以一个雄心勃勃的计划结束：将两个项目结合起来创建 Helm XNUMX。与 Deis 和 Google 一起，来自 斯基普盒子 （现在是 Bitnami 的一部分 - 大约翻译），然后我们开始开发 Helm 2。

我们希望保持 Helm 的易用性，但添加以下内容：

• 用于定制的图表模板；
• 团队的集群内管理；
• 世界一流的图表存储库；
• 具有签名选项的稳定包格式；
• 对语义版本控制和维护版本之间的向后兼容性的坚定承诺。

为了实现这些目标，Helm 生态系统中添加了第二个元素。 这个集群内组件称为 Tiller，负责安装 Helm 图表并管理它们。

自 2 年发布 Helm 2016 以来，Kubernetes 增加了几项重大创新。 添加了基于角色的访问控制（RBAC），最终取代了基于属性的访问控制（ABAC）。 引入了新的资源类型（部署当时仍处于测试阶段）。 自定义资源定义（最初称为第三方资源或 TPR）被发明。 最重要的是，已经出现了一套最佳实践。

在所有这些变化中，Helm 继续忠实地为 Kubernetes 用户服务。 经过三年的时间和许多新的添加，很明显是时候对代码库进行重大更改，以确保 Helm 能够继续满足不断发展的生态系统不断增长的需求。

向蒂勒温柔告别

在 Helm 2 的开发过程中，我们引入了 Tiller 作为与 Google 部署管理器集成的一部分。 Tiller 对于在公共集群中工作的团队发挥了重要作用：它允许操作基础设施的不同专家与同一组版本进行交互。

由于 Kubernetes 1.6 中默认启用基于角色的访问控制 (RBAC)，因此在生产中使用 Tiller 变得更加困难。 由于可能的安全策略数量巨大，我们的立场是默认提供宽松的配置。 这使得新手可以尝试 Helm 和 Kubernetes，而无需先深入研究安全设置。 不幸的是，这种权限配置可能会赋予用户太多他们不需要的权限。 在多租户集群中安装 Tiller 时，DevOps 和 SRE 工程师必须学习额外的操作步骤。

在了解社区在特定情况下如何使用 Helm 后，我们意识到 Tiller 的发布管理系统不需要依赖集群内组件来维护状态或充当发布信息的中心枢纽。 相反，我们可以简单地从 Kubernetes API 服务器接收信息，在客户端生成图表，并将安装记录存储在 Kubernetes 中。

如果没有 Tiller，Tiller 的主要目标也可以实现，因此我们关于 Helm 3 的第一个决定就是完全放弃 Tiller。

Tiller 消失后，Helm 的安全模型得到了彻底简化。 Helm 3 现在支持当前 Kubernetes 的所有现代安全、身份和授权方法。 Helm 权限是通过以下方式确定的 kubeconfig 文件。 集群管理员可以将用户权限限制到任何粒度级别。 版本仍然保存在集群中，并且 Helm 的其余功能保持不变。

图表存储库

从较高层次来看，图表存储库是可以存储和共享图表的地方。 Helm 客户端打包图表并将其发送到存储库。 简而言之，图表存储库是一个原始的 HTTP 服务器，带有一个 index.yaml 文件和一些打包的图表。

虽然 Charts Repository API 在满足最基本的存储要求方面有一些优点，但也有一些缺点：

• 图表存储库与生产环境中所需的大多数安全实现不兼容。 在生产场景中，拥有用于身份验证和授权的标准 API 极其重要。
• Helm 的图表来源工具用于签署、验证图表的完整性和来源，是图表发布过程的可选部分。
• 在多用户场景中，同一图表可以由另一个用户上传，从而使存储相同内容所需的空间量增加一倍。 已经开发了更智能的存储库来解决这个问题，但它们不是正式规范的一部分。
• 使用单个索引文件来搜索、存储元数据和检索图表使得开发安全的多用户实现变得困难。

项目 Docker 发行版 （也称为 DockerRegistry v2）是 DockerRegistry 的后继者，本质上充当一组用于打包、运输、存储和交付 Docker 镜像的工具。 许多大型云服务都提供基于分发的产品。 由于越来越多的关注，发行版项目受益于多年的改进、安全最佳实践和现场测试，使其成为开源世界最成功的无名英雄之一。

但您是否知道分发项目旨在分发任何形式的内容，而不仅仅是容器映像？

感谢努力 开放容器倡议 （或 OCI），Helm 图表可以放置在任何 Distribution 实例上。 目前，这个过程还处于实验阶段。 完整的 Helm 3 所需的登录支持和其他功能正在开发中，但我们很高兴能够从 OCI 和 Distribution 团队多年来的发现中学习。 通过他们的指导和指导，我们了解了大规模运营高可用服务的感觉。

提供了有关 Helm 图表存储库即将发生的一些更改的更详细说明 链接.

发布管理

在 Helm 3 中，应用程序状态由一对对象在集群内跟踪：

• 释放对象——代表一个应用程序实例；
• 发布版本秘密 - 表示应用程序在特定时间点的所需状态（例如，发布新版本）。

通话 helm install 创建一个发布对象和发布版本秘密。 称呼 helm upgrade 需要一个发布对象（它可以更改）并创建一个包含新值和准备好的清单的新发布版本密钥。

Release 对象包含有关发行版的信息，其中发行版是指定图表和值的特定安装。 该对象描述有关发布的顶级元数据。 发布对象在应用程序的整个生命周期中持续存在，并且是所有发布版本机密以及由 Helm 图表直接创建的所有对象的所有者。

发布版本秘密将发布与一系列修订（安装、更新、回滚、删除）相关联。

在 Helm 2 中，修订非常一致。 称呼 helm install 创建了 v1，后续更新（升级）- v2，依此类推。 发布和发布版本秘密已被折叠成一个称为修订版的单个对象。 修订版存储在与 Tiller 相同的命名空间中，这意味着每个版本在命名空间方面都是“全局”的； 因此，只能使用该名称的一个实例。

在 Helm 3 中，每个版本都与一个或多个版本密钥相关联。 发布对象始终描述部署到 Kubernetes 的当前版本。 每个发行版秘密仅描述该发行版的一个版本。 例如，升级将创建新的发布版本密钥，然后更改发布对象以指向该新版本。 在回滚的情况下，您可以使用以前的发行版本密钥将版本回滚到以前的状态。

Tiller 被废弃后，Helm 3 将发布数据存储在与发布相同的命名空间中。 此更改允许您在不同的命名空间中安装具有相同版本名称的图表，并且数据在集群更新/重新启动之间保存在 etcd 中。 例如，您可以将 WordPress 安装在“foo”命名空间中，然后安装在“bar”命名空间中，这两个版本都可以命名为“wordpress”。

图表依赖关系的更改

图表打包（使用 helm package）与 Helm 2 一起使用的可以与 Helm 3 一起安装，但是图表开发工作流程已被彻底修改，因此必须进行一些更改才能继续使用 Helm 3 进行图表开发。特别是图表依赖项管理系统已发生变化。

图表的依赖管理系统已从 requirements.yaml и requirements.lock 上 Chart.yaml и Chart.lock。 这意味着使用该命令的图表 helm dependency，需要一些设置才能在 Helm 3 中工作。

让我们看一个例子。 让我们向 Helm 2 中的图表添加依赖项，看看迁移到 Helm 3 后会发生什么变化。

在头盔 2 requirements.yaml 看起来像这样：

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

在 Helm 3 中，相同的依赖关系将反映在您的 Chart.yaml:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

图表仍会下载并放置在目录中 charts/，所以子图 （子图），位于目录中 charts/，将继续工作而不做任何改变。

图书馆图表简介

Helm 3 支持一类称为库图表的图表 （图书馆图表）。 该图表由其他图表使用，但不会自行创建任何发布工件。 库图表模板只能声明元素 define。 其他内容将被忽略。 这允许用户重用和共享可跨多个图表使用的代码片段，从而避免重复并遵守原则 干性.

库图表在 部分中声明 dependencies 在文件中 Chart.yaml。 安装和管理它们与其他图表没有什么不同。

dependencies:
  - name: mylib
    version: 1.x.x
    repository: quay.io

我们对该组件将为图表开发人员开放的用例以及库图表中出现的最佳实践感到兴奋。

接下来是什么？

Helm 3.0.0-alpha.1 是我们开始构建新版本 Helm 的基础。 在文章中，我描述了 Helm 3 的一些有趣的功能。其中许多功能仍处于开发的早期阶段，这是正常的； alpha 版本的目的是测试这个想法，收集早期用户的反馈，并确认我们的假设。

alpha 版本一发布 （记住这是 已经发生了 - 大约。 译），我们将开始从社区接受 Helm 3 的补丁。 您需要创建一个坚实的基础，以允许开发和采用新功能，并让用户通过开票和进行修复来感受到参与该过程。

我试图强调 Helm 3 的一些主要改进，但这个列表并不详尽。 Helm 3 的完整路线图包括改进的更新策略、与 OCI 注册表的更深入集成以及使用 JSON 模式来验证图表值等功能。 我们还计划清理代码库并更新过去三年中被忽视的部分。

如果您觉得我们错过了什么，我们很想听听您的想法！

加入我们的讨论 松弛通道:

• #helm-users 提出问题并与社区进行简单的沟通；
• #helm-dev 讨论拉取请求、代码和错误。

您还可以在每周四 19:30 MSK 举行的每周公共开发者电话会议中聊天。 会议致力于讨论主要开发人员和社区正在处理的问题以及本周的讨论主题。 任何人都可以加入并参加会议。 Slack 频道中提供链接 #helm-dev.

译者PS

另请阅读我们的博客：

• «Kubernetes 的包管理器 - Helm：过去、现在、未来“;
• «冷静地审视 Helm 2：“这就是它……”“;
• «Kubernetes 包管理器实用介绍 - Helm“;
• «Kubernetes 提示和技巧：将集群中运行的资源转移到 Helm 2 管理“;
• «使用 dapp 进行练习。 第 2 部分：使用 Helm 将 Docker 映像部署到 Kubernetes“。

来源： habr.com