写点什么

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

评论

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

创新引擎加速数字时代:揭秘JNPF平台与云计算的完美共舞!

不在线第一只蜗牛

云计算 低代码 数字化

通过容器化实现前端微服务化架构设计

FinFish

小程序容器 小程序化 小程序技术 前端服务化

代码随想录训练营 Day06 - 哈希表(上)

jjn0703

一篇文章带你上手性能测试框架K6

QE_LAB

自动化测试框架 测试自动化 #性能测试

华为开发者大会2023(Cloud):华为云邀您共话开源

华为云开源

开源 云原生 HDC.Cloud

多项目管理难在哪,多项目同时进行该如何做好进度管理?

优秀

项目管理 项目进度管理

扫光动效在移动端应用实践

百度Geek说

动效 移动端 企业号 7 月 PK 榜

MQTT 性能测试入门:常见测试场景和指标

EMQ映云科技

物联网 性能测试 mqtt

和鲸科技 ModelWhale 入选北京市人工智能行业赋能典型案例(2023)丨2023全球数字经济大会人工智能高峰论坛

ModelWhale

人工智能 AI 数字化 大模型 论坛

用ChatGPT搞定K8s!

互联网工科生

k8s kubernetes 运维 ChatGPT

2023-07-03:讲一讲Redis缓存的数据一致性问题和处理方案。

福大大架构师每日一题

redis 底层原理 福大大架构师每日一题

2023 MWC上海:移动云勇担新基建国家队 引领算网新趋势

Geek_2d6073

谁是家居智能化时代“头号玩家”? 小度全屋智能将登陆中国建博会

新消费日报

软件DevOps云化发展的趋势 【课程限时免费】

华为云PaaS服务小智

云计算 DevOps 云原生 华为云 华为开发者大会2023

​瓶颈期别挣扎了,低代码或许可以帮到你

伤感汤姆布利柏

高性能存储SIG月度动态:io_uring支持nvme直通,DSMS完成开发测试

OpenAnolis小助手

开源 io_uring 高性能存储 anck 龙蜥sig

Flink-Learning 实战营在升级!更多精美好礼等你来!

Apache Flink

大数据 flink 实时计算

时序数据库 TDengine 与 DBeaver 达成合作,生态系统再壮大

爱倒腾的程序员

涛思数据 tdengine 时序数据库

追击策略?微软云服务器业务2022年规模少于亚马逊AWS一半

B Impact

营销SaaS SemRush 2.9 亿美元年收入的五个经营数据分析

B Impact

算法复杂度介绍

宁静知行者

算法

组合框架:融合创新技术,实现一次编码多平台运行

FinFish

flutter 跨端开发 小程序容器 跨端框架 跨端应用开发

SQL 优化(四):如何使用 join

hungxy

第九届“互联网+”大赛产业赛道百度命题正式公布!57道命题,等你揭榜!

飞桨PaddlePaddle

人工智能 百度

蓬勃发展的数智革命:低代码开发平台开启制造业繁荣新纪元!

EquatorCoco

人工智能 低代码 制造业 数智转型

POCO库的安装与基础知识说明

芯动大师

合作、参与、让开源更易用 | 亚马逊的开源文化

亚马逊云科技 (Amazon Web Services)

云计算

揭秘元宇宙背后的最炫科技风

华为云PaaS服务小智

云计算 华为云 元宇宙

手把手带你搭建企业低成本万能架构

EquatorCoco

架构 软件架构 低成本

人工智能泡沫:揭秘低代码开发平台的革命性崛起

快乐非自愿限量之名

人工智能 低代码 数智化 ChatGPT

数据挖掘18大算法实现以及其他相关经典DM算法:决策分类,聚类,链接挖掘,关联挖掘,模式挖掘。图算法,搜索算法等

汀丶人工智能

人工智能 数据挖掘 机器学习 深度学习 决策树

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