写点什么

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

评论

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

功能完备的 SVN 客户端SmartSVN for Mac

Mac相关知识分享

人工智能发展历程

天津汇柏科技有限公司

AI 人工智能

Tampermonkey for Mac(油猴Safari浏览器插件)

Mac相关知识分享

浏览器插件

释放无限潜力:Databend 存算分离架构如何让企业数据管理焕然一新?

Databend

存算分离架构

App Cleaner & Uninstaller Pro for Mac(苹果应用程序清理卸载软件)

Mac相关知识分享

应用程序卸载

Loopback for Mac(mac虚拟音频设备软件)

Mac相关知识分享

落地ZeroETL 轻量化架构,ByteHouse推出“四个一体化”策略

字节跳动数据平台

软件测试学习笔记丨Linux三剑客-sed

测试人

软件测试

IPQ5010 vs. IPQ5018: A comprehensive comparison of the two WiFi solutions

wifi6-yiyi

wifi6 ipq5018

鸿蒙NEXT开发声明式UI是咋回事?

威哥爱编程

HarmonyOS ArkTS HarmonyOS框架 HarmonyOS NEXT

第70期 | GPTSecurity周报

云起无垠

5分钟了解软件开发的20项基本原则

俞凡

架构 最佳实践

约80%开发效率提升,原生鸿蒙政务、文旅行业样板间专区上线

最新动态

BlockCoin部署进展公示

科技热闻

第三届OpenHarmony技术大会OS内核及视窗分论坛圆满举办

科技热闻

融合大模型技术,激发开发新动力,IDE分论坛成功举办

科技热闻

【HarmonyOS】鸿蒙图片下载加载方案

zhongcx

鸿蒙

百度视觉搜索架构演进实践

百度Geek说

百度 重构 构架 视觉开发

MindNode for mac(思维导图软件)中文版

Mac相关知识分享

思维导图

小心selinux对应用的影响

通明湖

HarmonyOS NEXT开发之ArkTS自定义组件学习笔记

威哥爱编程

HarmonyOS ArkTS HarmonyOS框架 HarmonyOS NEXT

强大的音量控制软件Sound Control for Mac

Mac相关知识分享

2024 年 9 月公链行业研报:Sui 跃升至公链市值前 15,比特币 Layer 2 TVL 激增

Footprint Analytics

公链

面试官:go中的singleflight是如何实现的?

王中阳Go

Go 后端 面试问题

中国3-6岁儿童人群需求与行为洞察

易观分析

淘天集团5篇论文入选NeurIPS,阿里妈妈自动出价比赛决赛白热化

新消费日报

Milvus×Dify半小时轻松构建RAG系统

Zilliz

Milvus 向量数据库 rag dify

网站不安全,提示不可信?你需要安装SSL证书!

国科云

一站实现高效开发,鸿蒙生态伙伴模板&组件专区全新上线

最新动态

AI 大模型应用开发实战营总结

Kevin

AI大模型 openai 向量数据库 LLM langchain

LED会议屏:提升会议体验的利器

Dylan

科技 LED display LED显示屏 技术 优化体系

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