在最近于圣地亚哥举行的 KubeCon+CloudNativeCon 2019 大会上,有超过 12000 名与会者出席,Helm 尤其是 Helm 3.0.0 的发布成为了全场焦点。
Helm 是 Kubernetes 的一个包管理器,类似于 yum、apt、Homebrew 等操作系统的包管理器,它使得安装和管理包及包的依赖关系变得更加容易。在与联合创始人 Matt Butcher 的访谈中,我们已经了解到 Helm 的历史源于第一次的 KubeCon 。因此,它遗留了一些技术债,其中就包括备受争议的服务端组件 tiller 。
InfoQ 就 Helm 3.0.0 的发布采访了微软软件工程师、Helm 和 Draft 的维护者之一 Matt Fisher。
Fisher 谈到了 Helm3.0.0 的特性,这是一个主版本,访谈中包括了它的一些技术债的成因以及是如何克服它们的,其中这些技术债主要是与 tiller 相关的。他还谈到了 Helm 对向后兼容的承诺,这对项目来说一直都是很重要的。在这个访谈中,他还概述了 Helm 2 和 Helm 3 之间的一些关键变化。
InfoQ:Helm 3.0.0 是一个主版本,对吧?在我们讨论 tiller 之前,您能否先高度概述下该新版本中的功能呢?
Matt Fisher:最明显的变化是去除了 tiller。
Helm 3 采用了一种三向合并补丁( three-way merge patch)的策略。在生成补丁时,Helm 会考虑先前版本的状态、“实时”状态和建议的状态。在 Helm 2 中,它使用的是双向合并补丁(two-way merge patch)策略。
发布版本的发布分类账现在存储在与发布版本本身相同的命名空间中。这意味着 helm install wordpress stable/wordpress 可以按命名空间进行管理。
另一个变化是引入了 JSON 模式,可以将其应用于 chart 值。这可以确保用户提供的值是遵循 chart 维护者所定制的模式的,从而允许用户在发布过程的早期捕获错误,并确保能按照 chart 维护者的预期来提供值。
一些功能已经被弃用或重构了,这使得它们与 Helm 2 不兼容。helm serve 是在 Helm 2 时首次引入的一个非常有用的工具,但是现在使用诸如 chartmuseum 之类的其他工具已经是非常成功的项目了,所以 helm serve 被从项目中移除了。
还引入了一些新的实验性功能,其中包括 对 OCI 支持。
此外,这个版本还提供了其他更多可用的功能。文档中的 FAQ 对这些变化的内容和原因有更详细地介绍。
InfoQ:现在,我们来谈谈 tiller 。您能否简单地谈一下它是什么,为什么必须摆脱它,以及是如何摆脱它的呢?
Fisher:在此先介绍一下背景,这个很重要。
Helm 的第一个版本(又名 Helm Classic)是在 2015 年 11 月的首次 KubeCon 上推出的。Kubernetes 1.1.1 于当月初发布,而 1.0.0 在 2015 年 7 月发布,两次发布版本仅隔了 4 个月。
那时,Kubernetes 还没有 ConfigMap 的概念。 ReplicationControllers 被大肆宣传(还记得吗?)。Kubernetes API 的变化非常快。
在构建 Helm 2 时,我们需要一个对 Kubernetes API 的抽象层,这样我们自己能够留出一定空间来保证向后兼容。
Tiller 就是作为该抽象层而创建的。它为我们提供了一个可以控制输入(通过 gRPC)、输出(也是通过 gRPC)的层,并为用户提供了一些向后兼容的保证。
Helm 从 2.0.0 开始就一直致力于向后兼容,我们对此感到非常自豪。
随着时间的推移,Kubernetes 的 API 层变得更加稳定。Helm 3 为我们提供了机会去重构那些四年前引入的保护层,tiller 就是其中之一。
InfoQ:在采用容器方面,容器的安全性是最重要、最不重要还是处于中间状态呢。开发人员和架构师还应该注意哪些与 Helm 3 相关的安全问题呢?
Fisher:在 Helm 3 发布的前几周,CNCF 资助了 Cure53 来对 Helm 3 进行安全审计。Cure53 已经对其他 CNCF 项目进行过审计了,其中包括 Prometheus 、Envoy、Jaeger、Notary 等项目。
整个报告都值得一读,因为任何摘要都不能准确地描述它。作为其摘要的一部分,Cure53 给出了一个结论,内容如下:
根据这个由 CNCF 资助的项目得出的结论,Cure53 只能说明 Helm 项目给人的印象是非常成熟的。
这个结论是由许多不同的因素决定的,从本质上讲,这意味着可以推荐 Helm 用于公共部署,特别是当需要根据开发团队指定的建议进行适当配置和保护时。
安全审计是 CNCF 项目的优势之一,我们对它们以及 Cure53 所做的分析表示感谢。这一分析为我们提供了一些可以尝试改进的具体领域,并使我们对我们所拥有的充满了信心。
InfoQ:尽管有像 helm2to3 这样的工具,但还是有一些破坏性的变化会阻止从 Helm 2 迁移到 Helm 3,对吗?您能否总结一下这些变化,以及如何消除迁移过程中的困难?另外,您是否推荐同时使用 Helm 2 和 Helm 3 的混合模式开发呢?
Fisher:Helm 3 是一个主版本。多年来我们一直对 Helm 2 的每个小版本和补丁版本都保持向后兼容,我们利用这个机会重写了 Helm 的大部分内容,并且出现了一些向后兼容方面的缺陷。这些变化大多与 Kubernetes 中的存储后端有关,或者与我们如何处理某些 CLI 标志有关。大部分的工作都是围绕着将 Tiller 从架构中移除后 Helm 3 会是怎样的来展开的。
完成此操作后,我们需要确保可以顺利地向前迁移,这就引入了 helm-2to3 插件。
我们考虑的一个主要设计目标是如何避免对 chart 进行任何破坏性的变更。我们希望可以确保已经建立了 chart 的社区不必再维护同一 chart 的两个不同版本:一个用于 Helm 2,另一个用于 Helm 3。
我们从社区成员那里了解到,他们的集群采用了绞杀者模式(strangler pattern ),使用 Helm 2 维护的版本需要继续使用 Helm 2,但新安装的可以使用 Helm 3。
不过,我们强烈反对用户尝试同时使用 Helm 2 和 Helm 3 来管理同一版本。这行不通。后端产生了一些重大的变化,这是 helm-2to3 迁移工具可以帮助他们进行迁移的地方之一。
InfoQ:您能简单概括下 Helm 所处的生态系统吗?关于 Helm 的工具,您推荐给开发人员和架构师的首选工具是什么?主要差距在哪里?
Fisher:Helm 是一个包管理器,与 apt、yum、homebrew 等处于同一领域。
包管理器允许了解如何在某平台上运行应用程序的人(例如,debian 上的 postgresql )以一种其他人不需要学习就可以运行该应用程序的方式将其打包。
这就是为什么我可以定期使用 apt install ,而不需要了解在系统上运行这些应用程序的业务逻辑的原因。
包管理器使我们可以划分专业知识并使之自动化。
在工具方面,使用 chartmuseum 或 Harbor 来托管自己的 chart 存储库是不会出错的。chart-releaser 是 chart 存储库 API 的另一种形式,它依赖于自动化,会使用 Github Releases 和 Github Pages 来托管 chart 包。
用于 Visual Studio Code 的 Kubernetes 扩展有一些很好的可视化工具,可用于与 Kubernetes 集群进行交互。我发现自己在执行简单的 Kubernetes 操作(比如 kubectl edit )时会更高频率地使用它,或者当我尝试根据集群中当前安装的内容来组装新的 Helm chart 时也会使用它。
InfoQ:最后,除了 Helm 3 之外,还有什么路线图吗?对于那些没有使用过 Helm 的人或者那些想为 Helm 社区做出贡献的人,还有其他的建议吗?
Fisher:现在,我们正在做收尾工作,并在了解社区的情况。我们正在努力提升稳定性并强化现有的功能集。将实验性功能(如 OCI 注册中心集成)推进到通用阶段,并从使用 Go 客户端库的用户那里收集反馈。当然,安全修复和补丁发布也会根据需要来进行安排。
对于那些想做出贡献的人来说,在 #helm-users Kubernetes Slack 频道中与其他社区成员聊天始终是一个不错的开始。如果你遇到了问题,这也是一个寻求帮助的好地方。社区成员会与他人分享他们的故事,或者帮助他人解决他们以前遇到的某些问题,对此我都会很感动。
核心维护人员也在寻找那些将 Helm( CLI 或 Go SDK)集成到他们自己项目中的社区成员的反馈。#helm-dev Kubernetes Slack 频道对于联系核心维护人员以了解高级主题非常有用。
Helm 3.0.0 引入了一些新功能并删除了集群侧组件 tiller,想要了解更多关于 Helm 3.0.0 版本的详细细节请访问 helm.sh。更多关于 Helm 的详细文档可以在文档中找到。会议上还举行了许多关于 Helm 的议题,其中包括 Helm 3 Deep Dive。
原文链接:
Q&A with Matt Fisher of Microsoft about Helm 3.0.0 release for Kubernetes
评论