写点什么

微软 Matt Fisher 访谈:Kubernetes Helm 3.0.0 发布

  • 2019-12-13
  • 本文字数:3258 字

    阅读完需:约 11 分钟

微软 Matt Fisher 访谈:Kubernetes Helm 3.0.0 发布

在最近于圣地亚哥举行的 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


2019-12-13 09:001757

评论

发布
暂无评论
发现更多内容

极客时间 - 架构师培训 - 6 期作业

Damon

Mysql插入百万条数据

Java小咖秀

MySQL 运维 数据

每周学习总结 - 架构师培训 5 期

Damon

【计算机网络】为什么要三次握手四次挥手?

烫烫烫个喵啊

TCP 计算机网络

昆明市成立两大“高端”中心,区块链赋能生物医药和高原特色农业

CECBC

智慧4S店解决方案发布,看英特尔如何引领汽车销售行业变革

最新动态

【计算机网络】如何实现可靠数据传输?

烫烫烫个喵啊

ARTS-WEEK6

一周思进

ARTS 打卡计划

ARTS打卡 - Week 07

teoking

ARTS打卡-06

Geek_yansheng25

简述CAP理论

lei Shi

一致性hash算法及标准差验证

Damon

ARTS打卡 第7周

引花眠

ARTS 打卡计划

Cache解决算法 Charles断点调试breakpoint John 易筋 ARTS 打卡 Week 08

John(易筋)

ARTS 打卡计划

设计模式(1)—什么是设计模式?设计模式的六大原则是什么?

爱嘤嘤嘤斯坦

Java 程序员 编程语言 设计模式 23种设计模式

抽象工厂模式

Leetao

Python 面试 设计模式

观智能化浪潮如何改变产业链创新

CECBC

负载均衡方式

羽球

负载均衡

Go:Stringer命令,通过代码生成提高效率

陈思敏捷

stringer Go 语言

数据驱动 vs 关键字驱动:对UI自动化测试框架搭建的探索

冯文辉

DevOps 敏捷 自动化测试

看动画学算法之:排序-插入排序

程序那些事

Java 数据结构 算法 插入排序

每周学习总结 - 架构师培训 6期

Damon

进程、线程基础知识全家桶,30 张图一套带走

小林coding

Linux 操作系统 计算机基础 进程 进程线程区别

程序的机器级表示-程序的编码

引花眠

计算机基础

低代码与无代码

lidaobing

低代码 无代码开发

ARTS WEEK5

紫枫

ARTS 打卡计划

SpringBoot 入门:03 - 统一请求返回

封不羁

Java spring springboot

编程核心能力之抽象

顿晓

抽象 编程日课

分布式系统设计理念这么难学?

架构师修行之路

架构 分布式

redis系列之——高可用(主从、哨兵、集群)

诸葛小猿

redis redis集群 redis哨兵 redis主从

MySQL实战45讲总结

`

MySQL

微软 Matt Fisher 访谈:Kubernetes Helm 3.0.0 发布_软件工程_Rags Srinivas_InfoQ精选文章