注意事项 佩雷夫 ：今年5月16日是Kubernetes-Helm软件包管理器开发的重要里程碑。 在这一天，引入了该项目未来主要版本的第一个alpha版本-3.0。 她的发布将为Helm带来重大且人们期待已久的变化，而Kubernetes社区中的许多人对此寄予了厚望。 当我们积极使用Helm来部署应用程序时，我们自己对待这些问题：我们将其集成到了用于实施CI / CD werf的工具中，我们不时为上游开发做出切实可行的贡献。 该翻译汇集了来自Helm官方博客的7条注释，这些注释与Helm 3 alpha的第一个发行版同步，并讲述了该项目的历史和Helm 3的主要功能。作者是Microsoft员工Matt和“ Helm 3”的主要维护者之一。 该项目于2015年10月15日诞生，现称为Helm。 成立仅一年后，Helm社区就加入了Kubernetes，并积极致力于Helm2。2018年6月，Helm
加入了CNCF，成为一个孵化项目。 快进当下-新的Helm 3的第一个Alpha版本即将发布
（该版本已在5月中旬发布-大约Transl。） 。
在本文中，我将讨论这一切是如何开始的，我们如何进入现阶段，介绍Helm 3的第一个alpha版本中可用的一些独特功能，并解释我们计划如何进一步开发。
总结：
- 头盔创建的历史；
- 告别蒂勒；
- 图表存储库；
- 发布管理；
- 图表依存关系的变化；
- 图书馆图;
- 接下来是什么？
舵史
出生时间
Helm 1最初是由Deis创建的一个开源项目。 我们是一家小型初创公司
，于2017年春季
被 Microsoft
吸收 。 我们的另一个开源项目（也称为Deis）具有一个
deisctl工具，该工具被用于（其中包括）在
Fleet集群中安装和操作Deis平台。 舰队当时是最早的集装箱编排平台之一。
2015年中，我们决定改变航向，将Deis（当时更名为Deis Workflow）从车队转移到Kubernetes。 第一个重新设计
deisctl安装
deisctl 。 我们使用它在Fleet集群中安装和管理Deis Workflow。
Helm 1是按照Homebrew，apt和yum等知名软件包管理器的形象创建的。 它的主要任务是简化诸如在Kubernetes中打包和安装应用程序之类的任务。 Helm于2015年在旧金山的KubeCon会议上正式推出。
我们对Helm的首次尝试成功了，但存在严重的局限性。 他采用了一组Kubernetes清单，并用生成器作为* YAML的
前身 ，然后将结果上传到Kubernetes。
* 注意 佩雷夫 从Helm的第一个版本开始，选择了YAML语法来描述Kubernetes资源，并且在编写配置时支持Jinja模板和Python脚本。 我们在本材料的 “头盔简史”一章中详细介绍了此功能以及头盔的第一个版本。例如，要替换YAML文件中的字段，必须将以下构造添加到清单中：
#helm:generate sed -i -es|ubuntu-debootstrap|fluffy-bunny| my/pod.yaml
今天有模板引擎很酷，不是吗？
由于许多原因，这个早期的Kubernetes安装程序需要清单文件的硬编码列表，并且仅执行少量固定的事件序列。 很难使用，以至于Deis Workflow研发团队在尝试将产品转移到该平台时遇到了困难-但是，这种想法的种子已经播下。 我们的第一次尝试是一个很好的学习机会：我们意识到我们非常热衷于创建实用的工具来为用户解决日常问题。
根据过去的错误经验，我们开始开发Helm 2。
创造头盔2
2015年底，Google团队与我们联系。 他们为Kubernetes开发了类似的工具。 Kubernetes的Deployment Manager是用于Google Cloud Platform的现有工具的端口。 他们问道：“我们会花几天时间讨论异同吗？”
2016年1月，Helm和Deployment Manager团队在西雅图开会，交流想法。 谈判以一个雄心勃勃的计划结束：将两个项目结合起来创建
Helm2。SkippBox （现在是Bitnami的一部分-大约是Transl。）的 员工与Deis和Google一起加入开发团队，我们开始研究Helm 2。
我们希望保持Helm的易用性，但添加以下内容：
- 用于定制的图表模板；
- 团队内部集群管理；
- 一流的图表库
- 具有签名能力的稳定包装格式；
- 对语义版本控制和保持版本之间的向后兼容性的坚定承诺。
为了实现这些目标，已将第二个元素添加到Helm生态系统中。 该集群内组件称为Tiller，参与了Helm图表的安装及其管理。
自2016年发布《头盔2》以来，Kubernetes取得了许多重大创新。
引入了基于角色的访问控制（
RBAC ），最终取代了基于属性的访问控制（ABAC）。 引入了新的资源类型（当时的部署仍处于beta状态）。 发明了自定义资源定义（最初称为第三方资源或TPR）。 最重要的是，出现了一组最佳实践。
在所有这些变化中，Helm继续忠实地为Kubernetes用户提供服务。 经过三年的时间和许多新的增加，很明显，是时候对代码库进行重大更改了，以便Helm可以继续满足发展中的生态系统不断增长的需求。
向蒂勒温柔告别
在开发Helm 2的过程中，我们引入了Tiller，作为与Google的Deployment Manager集成的一部分。 对于在同一个集群中工作的团队，Tiller发挥了重要作用：它允许操作基础结构的各种专家与同一组发行版进行交互。
由于在Kubernetes 1.6中默认启用了基于角色的访问控制（RBAC），因此在生产中使用Tiller变得更加困难。 由于可能的安全策略数量众多，因此我们的立场是默认情况下提议权限。 这样一来，初学者就可以使用Helm和Kubernetes进行试验，而不必首先进入安全设置。 不幸的是，这种宽松的配置可能使用户拥有他不需要的过多权限。 DevOps和SRE工程师必须通过在多租户群集中安装Tiller来学习其他操作步骤。
在了解了社区成员在特定情况下如何使用Helm后，我们意识到Tiller的发布管理系统不需要依靠集群内部组件来维护状态或充当发布信息的中心枢纽。 相反，我们可以只从Kubernetes API服务器获取信息，生成客户端图表，然后将安装记录保存到Kubernetes。
蒂勒的主要任务可以在没有蒂勒的情况下完成，因此我们对头盔3的第一个决定是完全拒绝蒂勒。
随着Tiller的离开，Helm安全模型已得到了根本简化。 Helm 3现在支持当今Kubernetes的所有现代安全性，标识和授权方法。 掌舵权限是使用
kubeconfig文件确定
的 。 群集管理员可以使用任何级别的粒度来限制用户权限。 版本仍存储在集群中，其余的Helm功能保留下来。
图表储存库
在较高的层次上，图表存储库是您可以存储和共享图表的地方。 Helm客户端打包并将图表发送到存储库。 简而言之，图表存储库是具有index.yaml文件和一些打包图表的原始HTTP服务器。
尽管图表存储库API满足存储库的最基本要求有一些优点，但它也有一些缺点：
- 图表存储库与生产环境中所需的大多数安全实现之间的兼容性较差。 在生产场景中，具有用于身份验证和授权的标准API至关重要。
- Helm的跟踪图表来源的工具（用于签名，验证图表的完整性和起源）是图表发布过程中的可选部分。
- 在多用户方案中，另一个用户可以加载相同的图表，从而使存储相同内容所需的空间增加了一倍。 已经开发了更智能的存储库来解决此问题，但是它们不是正式规范的一部分。
- 使用单个索引文件来搜索，存储元数据和获取图表会使安全的多用户实现的开发变得复杂。
Docker Distribution项目（也称为Docker Registry v2）是Docker Registry的后继产品，实际上是一组用于打包，发送，存储和交付Docker映像的工具。 许多大型云服务都提供基于分发的产品。 由于得到了越来越多的关注，Distribution项目受益于多年的改进，安全领域的最佳实践以及“战斗”条件下的测试，这些使之成为开源世界上最成功的无名英雄之一。
但是您知道分发项目旨在分发任何形式的内容，而不仅仅是容器图像吗？
由于
开放容器计划 （或OCI）的努力，Helm图表可以放置在任何Distribution实例上。 到目前为止，该过程是实验性的。 全面支持Helm 3所需的登录名和其他功能的支持工作尚未结束，但是我们很高兴从OCI和发行团队多年来的发现中吸取教训。 由于他们的指导和领导，我们了解了大规模访问高度可访问服务的运作方式。
有关Helm-charts存储库即将进行的某些更改的详细说明，请参见
此处 。
发布管理
在Helm 3中，集群中的应用程序状态由两个对象监视：
- 发布对象-代表应用程序的实例；
- 发布版本密钥-表示特定时间点应用程序的期望状态（例如，发布新版本）。
调用
helm install会创建一个发布对象并发布版本密钥。 调用
helm upgrade需要一个发布对象（可以更改），并创建一个包含新值和准备清单的新发布版本密钥。
发布对象包含发布信息，其中发布是命名图表和值的特定安装。 此对象描述有关发行版的顶级元数据。 发布对象在应用程序的整个生命周期中都得到保留，并充当所有发布版本机密以及由Helm图表直接创建的所有对象的所有者。
发布版本密钥将发布与一系列修订（安装，更新，回滚，卸载）相关联。
在“头盔2”中，修订版本极其一致。
helm install调用创建了v1，随后的升级升级了v2，依此类推。 发布和发布版本的机密被折叠为一个对象，称为修订。 修订版本存储在与Tiller相同的名称空间中，这意味着每个版本在名称空间方面都是“全局的”。 结果，只能使用该名称的一个实例。
在Helm 3中，每个发行都与一个或多个发行版本机密关联。 发布对象始终描述Kubernetes中部署的当前版本。 每个发行版密钥仅描述此发行版的一个版本。 例如，升级将创建新的发行版密钥，然后修改发行版对象以指向该新版本。 在回滚的情况下，您可以使用先前发行版的机密将发行版回滚到其先前的状态。
放弃Tiller之后，Helm 3将发布数据与发布一起存储在单个命名空间中。 这样的更改使您可以在不同的名称空间中安装具有相同发行版名称的图表，并在etcd中集群更新/重新启动之间保存数据。 例如，您可以将Wordpress安装在名称空间“ foo”中，然后安装在名称空间“ bar”中，两个版本都可以称为“ wordpress”。
图表依赖关系更改
可以将与Helm 2一起使用的打包图表（使用
helm package ）可以与Helm 3一起安装，但是图表开发工作流程已完全修改，因此需要进行一些更改以继续使用Helm 3开发图表。特别是，管理系统已更改图表依赖性。
图表依赖关系管理系统已从
Chart.yaml和
Chart.lock移到
Chart.yaml和
Chart.lock 。 这意味着使用
helm dependency命令的图表需要一些配置才能在Helm 3中工作。
让我们来看一个例子。 向Helm 2中的图表添加依赖项，并查看切换到Helm 3时发生的变化。
在Helm 2中，
requirements.yaml如下所示：
dependencies: - name: mariadb version: 5.xx repository: https://kubernetes-charts.storage.googleapis.com/ condition: mariadb.enabled tags: - database
在Helm 3中，相同的依赖关系将反映在您的
Chart.yaml ：
dependencies: - name: mariadb version: 5.xx repository: https://kubernetes-charts.storage.googleapis.com/ condition: mariadb.enabled tags: - database
charts/仍被加载并放置在
charts/目录中，因此
charts/目录中的子
charts/将继续工作而无需更改。
图书馆图介绍
Helm 3支持一个称为
库图表的图表类。 该图表供其他图表使用，但不会自行创建任何发布工件。 库图模板只能声明
define元素。 其他内容将被忽略。 这使用户可以重用和共享可在许多图表上使用的代码片段，从而避免重复并坚持
DRY原理。
库图在
Chart.yaml文件的
dependencies部分中声明。 它们的安装和管理与其他图表没有什么不同。
dependencies: - name: mylib version: 1.xx repository: quay.io
我们期待该组件将向图表开发人员开放的用例，以及库图表可能产生的最佳实践。
接下来是什么？
Helm 3.0.0-alpha.1-我们开始创建新版本的Helm的基础。 在本文中，我描述了Helm 3的一些有趣特性。许多特性仍处于开发的早期阶段，这很正常。 alpha版本的实质是测试该想法，从第一批用户那里收集反馈并确认我们的假设。
Alpha版本发布后
（记得已经发生过 -大约翻译） ，我们将开始从社区接收Helm 3的补丁程序。 有必要创建一个坚实的基础，使您能够开发和采用新的功能，并且用户将能够参与到该过程中，打开工单并进行更正。
在本文中，我试图突出显示将在Helm 3中出现的一些重要改进，但是此列表绝不是详尽的。 Helm 3的全面计划包括创新，例如改进的更新策略，与OCI注册表的更深入集成以及使用JSON方案检查图表值。 我们还计划清除代码库并更新在过去三年中被忽略的部分。
如果您觉得我们错过了什么，我们将很高兴听到您的想法！
加入我们的
Slack频道中的讨论：
#helm-users提出问题并与社区轻松沟通；#helm-dev讨论拉取请求，代码和错误。
您也可以在每周四19:30 MSK的每周公共开发人员电话中聊天。 这些会议专门讨论关键开发人员和社区正在处理的任务，以及本周的讨论主题。 任何人都可以加入并参加会议。 该链接在
#helm-dev Slack频道中可用。
译者的PS
另请参阅我们的博客：