💊 🔩 👍 阿姆斯特丹2019头盔峰会的五大亮点 🛤️ 🐒 🤫

注意事项 佩雷夫 ：最近发现，人们对“ Kubernetes软件包管理器”-Helm越来越感兴趣。 我们已经撰写的关于Helm v3的期待已久的重大更新正处于活跃阶段-不仅是开发，还包括发行版。 他的最新测试版连续第三次发布，已于9月初发布。 就在最近，发生了一个相当大的事件（对于这样一个专门的开源项目），其印象是来自CloudARK的访问者的印象，CloudARK为Kubernetes提供了iPaaS（集成平台即服务）。

从CNCF Flickr帐户拍摄的原始照片

上周在阿姆斯特丹举行了头盔峰会。它汇集了代表Kubernetes上的各种用户和服务提供商的大约150名爱好者。这是此事件的五个关键点。

1.在Helm 3.0中-更好的安全性，CRD支持以及一些打破常规方法的更改

Helm核心开发团队的一些关键成员出席了此次峰会。从他们在场外的讲话和交流中可以明显看出，Helm 3.0将是该项目的重要里程碑。你们中许多人可能听说过，第三版将没有Tiller-Helm服务器组件。 （ 请注意 ：有关此内容的更多信息，请参见本文。） Helm 3.0中还将有其他重要的创新，例如更紧密的安全控制和对自定义资源定义（CRD）的更好支持。我特别记得以下三个关键方面：

在安全区域中，默认情况下，用户的预配置权限集很小。与自动获得整个集群管理员权限的蒂勒不同，在Helm 3.0中，您将必须手动授予旨在与Helm一起使用的用户（用户）和服务（服务）帐户的特权。此更改可确保管理员就其群集的安全性做出明智的决策。
第二个主要变化是增强了CRD支持。在当前版本的Helm中，通过定义为注释的crd-install钩安装CRD。但是，并非所有CRD开发人员和操作员都使用它。这使得Helm图表容易受到安装错误的影响，因为正确设置图表需要将CRD放在“自定义资源”清单的前面。 Helm 3.0将把对CRD的支持提高到一个新的水平。 chrts子目录将出现在crd目录中。用户将所有CRD YAML文件添加到此目录就足够了。在设置图表的其余部分之前，Helm将对其进行处理。此过程将确保在安装“自定义资源”清单之前已安装CRD。
重大更改将影响CLI的工作。例如，现在在图表安装期间，如果未将其指定为输入参数，则会生成一个随机发行名称。在Helm 3.0中，情况将相反：带有名称的参数将变为必需。为了保留发行版的随机命名，在输入命令时需要指定一个特殊标志。

2.整合云原生工件

有几次会议专门讨论了存储Helm图表的问题。这些会议由ChartMuseum的作者Josh Dolitsky 主持。他介绍了问题，现有解决方案，并谈到了该领域的总体趋势。主要结论是，与您必须使用云原生方法处理的各种工件（Docker图像，Helm图表，Kustomize补丁文件）的工作应保持一致。

调用ORAS项目-OCI注册表作为存储，以确保将所有这些工件存储在单个注册表中。对于Kubernetes用户而言，这绝对是朝着正确方向迈出的一步，因为它将使您能够在一个注册表中整合各种工件，同时为诸如注册表分区，访问控制等功能提供支持。

3.舵手和操作员

几位发言者在演讲中谈到了用户控制器和操作员的话题。 CloudARK的演讲重点介绍了为运营商创建Helm图表的最佳实践。红帽团队讨论了运营商和运营商中心。

来自Workday ， Weaveworks和Notre Dame大学的代表在演讲中讨论了Kubernetes原生方法，该过程使用称为GitOps的过程来持续协商集群中基于Helm的发行版。 （ 注意翻译 ：在此处阅读有关GitOps的更多信息。）

所有这些性能的关键结论是，Helm和操作员相得益彰。前者（Helm）专注于管理工件的模板和简单性，而后者（操作员）则专注于管理第2天的任务（即在系统生命周期的阶段，当它开始为创建者带来成果时- 大约） ，例如在Kubernetes集群中运行的第三方软件，例如关系/非关系数据库。

4.舵图管理问题

当涉及大型企业应用程序时，一张Helm图表是不够的。需要一些图表。从这个意义上讲，GitLab的展示是一个真正的发现。他们有很多图表，而图表的平均大小也很大（几千行）。管理所有这些图表本身并不是一件容易的事。

关于此问题的各个方面，有两个有趣的演示。在一个示例中，IBM团队展示了其内部工具，该工具可通过各种标准简化对Helm图表的搜索。他们专注于解决DevOps工程师的问题，他们被迫在集群中选择并安装图表。在另一组中，复制团队讨论了如何解决在不创建副本或分叉的情况下管理Helm图表编辑的问题。他们方法的本质是分离基本的Helm图表，并通过从补丁文件中借鉴kustomize的思想来创建自定义的Helm图表。将来，随着各种提供商专注于影响其管理的Helm图表的各个方面，我们将能够目睹朝着这一方向的暴力活动。例如，我们在CloudARK 专注于为运营商提供的Helm图表，这些图表会收到特殊的platform-as-code注释，从而使发现和使用自定义资源变得更加容易。

5.好客社区

掌舵人和社区的关键成员原来是非常友好的人。它们是开放的，可用于任何讨论和问题，例如发布日期，关于Helm和Kustomize的想法，与KubeCon的联合活动等。

他们还谈到了参与Helm开发的过程。他似乎并不复杂。 Helm项目尚未采用KEP程序（Kubernetes增强建议）。但是，在孵育阶段完成后，情况可能会发生变化。

CloudARK在头盔峰会上

我们在峰会上的演讲致力于为运营商创建Helm图表的原理和最佳实践。我们提供iPaaS，它使DevOps团队可以构建自己的Kubernetes平台堆栈，而无需与Kubernetes提供程序或专有接口建立任何连接。必要的CRD /运算符以Helm图表的形式打包，并特别强调来自各种运算符的自定义资源的兼容性。

该演示基于从数家运营商的独立开发中汲取的经验教训，并分析了一百多家公开可用的运营商，以获取可用于企业使用的自定义Kubernetes Native平台层。