AICon 上海站|90%日程已就绪,解锁Al未来! 了解详情
写点什么

微软 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:001611

评论

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

降维打击:数据可视化降本增效,传统制造业价值即将扭转!

一只数据鲸鱼

物联网 数据可视化 工业物联网 数字化运维 3D

6大创新技术及2亿美元投入计划,这个活动有点料

华为云开发者联盟

人工智能 数据库 华为 云原生 HDC.Cloud

近万字原创长文,以追忆2020年:《请回答,2020》

朱季谦

随笔杂谈

另类数据:投资中的怪咖

博文视点Broadview

基于深度学习的端到端通信系统模型

华为云开发者联盟

深度学习 端到端 编码器 通信系统 信道模型

基于NB-IoT的智慧路灯监控系统(NB-IoT专栏—实战篇5:手机应用开发)

不脱发的程序猿

物联网 28天写作 3月日更 NB-IoT智慧路灯 手机应用开发

风暴眼中的“以太坊”堪比堵车的北京东三环,NA公链(Nirvana)NAC公链对垒胜算几何?

区块链第一资讯

区块链

智慧公安一键扫描二维码报警定位系统

13828808769

智慧交通

Rust从0到1-基础概念-函数

rust 函数

压抑了五个月的我终于可以放声呐喊了!阿里是真的难进,Java四面面经+面试题

Java架构追梦

Java 阿里巴巴 架构 面试 金三银四

MindSpore实践:对篮球运动员目标的检测

华为云开发者联盟

深度学习 mindspore 图像检测 yolo 篮球运动

云端数智新引擎,腾讯云原生数据湖计算重磅发布

腾讯云大数据

大数据 数据湖

未来几年,低代码开发平台会如何发展?

优秀

低代码

是谁拖(慢)了 Redis 的后腿?

escray

redis 学习 极客时间 3月日更 Redis 核心技术与实战

visualvm工具远程对linux服务器上的JVM虚拟机进行监控与调优

朱季谦

JVM GC 调优

数字化进入深水区

鲸品堂

方法论 数字化 企业数字化转型

区块链电子合同签署平台,助力企业数字化转型

13828808769

区块链+ #区块链#

关于企业容器安全问题的思考

阿里巴巴中间件

spark性能调优之JVN调优

大数据技术指南

spark 3月日更

vue项目中使用tinymce富文本编辑器实现图片上传/粘贴格式

yumibgt

tinymce

关于热力图数据上报清洗,我们做了一个有意思的尝试

阿里巴巴中间件

大“食”代来临,后厨重地可以更“聪明”点儿

IoT云工坊

人工智能 物联网 PaaS 智慧厨房 智慧餐饮

Python OpenCV 图像平移,取经之旅第 10 天

梦想橡皮擦

3月日更

Knativa 基于流量的灰度发布和自动弹性实践

Serverless Devs

Serverless Kubernetes 运维 云原生 Knative

策略枚举:消除在项目里大批量使用if-else的正确姿势

朱季谦

枚举 策略模式

初识Golang之函数及方法的多返回值

Kylin

3月日更

智能安防监控系统的发展与应用

anyRTC开发者

android 监控 音视频 WebRTC RTC

金三银四,冰河为你整理了这份20万字134页的面试圣经!!

冰河

面试 面经 offer 金三银四 我要进大厂

区块链产品宗谱链,一款记录族谱的APP

13828808769

区块链+ #区块链#

EGG Network阿凡提的模式是怎么样的?早点了解别错失这个机会!

币圈那点事

区块链

v01.12 鸿蒙内核源码分析(双向链表) | 谁是内核最重要结构体 | 百篇博客分析 HarmonyOS 源码

鸿蒙研究站

鸿蒙 HarmonyOS 鸿蒙内核源码分析 百篇博客分析鸿蒙 百万汉字注解鸿蒙

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