KubeCon 参会记录之 -- Helm 3 Deep Dive

KubeCon 第一天有很多Sig Introduce 就是K8s 社区对应的Maintainer来对应的社区兴趣小组大家见见面,聊一聊目前社区此小组关注的事情,正在开发的进展,以及社区此方向下一步进展。第一天一般都是介绍性质的,第二天就会有Deep Dive xxx,一般就是各个maintainer 来深入的讲一下本sig 将要进行的大feature 或者深入的和参会者聊一聊大家有啥意见或者想法。参加此次大会发现,一般关于分论坛的topic,热门领域比如AI,区块链,大厂分享几乎都是会议室爆满,对于这样的sig 特别兴趣小组讨论,第一天介绍性的时候人就很少,第二天deep dive的可能就屈指可数。举个例子,我参加了第一天和第二天的sig app讨论,第一天会议室大约有15个人去听,第二天deep dive sig app 讨论,整个会议室,加上工作人员一共7个人,maintainer 说,我也不准备啥 ppt 了,咱们坐下来聊聊吧。其实作为一个一线开发者,这样的maintainer面对面能了解到更多社区的发展意图,目前社区正在进行的事情,已经如何与社区互动,相比一些介绍性的topic,坐下来聊一聊,更能受益匪浅。

闲话说的有点多,下面进入正题。本篇主要介绍Helm v3下一步的发展,已经目前开发进度情况。此场topic属于deep dive sig 议题,主讲人是Helm core maintainer Taylor Thomas。按理说应该参会人员极少,但是等我到达会场的时候发现座位已经几乎满员,后来陆陆续续来的人塞满了会议室的过道与讲台,甚至会议室的门口都排了一些人探着头,maintainer应该也没预料到会有这么多人关心helm v3的进展,让大家多挤一挤。

Helm 3 啥时候发布

想必主讲者也知道,大家最想问的一个问题就是,helm 3到底啥时候发布,进展情况如何。开篇maintainer就丢出来一个地址 https://github.com/helm/helm/projects/1,这是第一个helm project tracker,里面包含了所有目前helm v3正在进行的工作以及将要进行的工作,同时branch https://github.com/helm/helm/tree/dev-v3 也能跟踪到目前 v3版本正在进行的所有工作,大家可以在这里看到他们正在提交的代码。

KubeCon 参会记录之 -- Helm 3 Deep Dive

这里回顾了一下Helm的发展历史,可以看到最终Helm 3发布的时间是 Soon. 主讲者说每个session都可以进行提问互动,这里就有一位哥们问了一个问题,soon 到底是啥时候。 maintainer回答的也比较风趣,他表示我不能说这个版本将在某一天某一日发布,我只能说这一个版本 comming very soon.全场爆笑,但是他也表示了此版本的alpha release将在明年的第一季度发布。

Embedded Lua engine

Helm 3将会集成Lua 引擎,在chart.yaml 里面可以使用 lua代替yaml template。这带来的好处主要有以下几点。

  • Treat Kubernetes resources as objects, not strings
  • Intercept lifecycle events, modify chart on-the-fly
  • Develop and import reusable “library charts”
  • Helm plugins will have access to the Lua runtime

基本理解为,使用Lua后,yaml资源描述就由原来的yaml字符串变为lua对象,这样整个资源的生命周期就变为lua对象的生命周期管理。同时这样能够复用很多基本的chart,使用import来复用。同时helm client也提供了定制,能够让helm plugin 接触 lua 运行时。其实这么说大家是有一点懵逼的,在场的同志们也是一脸懵逼,下面我们看一下helm 2与helm 3 chart 对比图。

KubeCon 参会记录之 -- Helm 3 Deep Dive
KubeCon 参会记录之 -- Helm 3 Deep Dive

是不是满脸惊讶。这还是我认识的那个 Helm 吗?在场的同学问了第一个问题是,Helm3还能兼容Helm 2的chart吗? 估计大家被Helm 3 Chart的样子惊呆了。粗粗来看,基本上 Helm3就把chart 由原来的 yaml 描述变成了lua描述,这样能够以一个对象的形式去描述 k8s 资源,也能够实现复用,不过看起来怪怪的,一切等helm3出来才能明白。

Removal of Tiller

这个应该是 Helm3最令人期待的特性了。当Maintainer show 出这个页面的时候,现场响起来掌声。可见tiller是一个大家公认不应该存在的玩意。Maintainer很尴尬的也跟着象征性的鼓鼓掌。去掉Tiller后主要有以下几个变化。

  • Shrinks the security model for Helm, now client-only
  • Auth is delegated to Kubernetes RBAC
  • “Release” CRD will store instance of an application
  • “ReleaseVersion” CRD will store version of release

KubeCon 参会记录之 -- Helm 3 Deep Dive

可以通过这个架构图看到,tiller 没有后,最大的好处就是多租户的权限控制,一切都重归k8s的 RBAC,这样可以很好的进行多租户的权限控制。Helm会创建两个 CRD,一个是Release记录应用的源信息,另一个ReleaseVersion 记录历史版本信息。现在 k8s 官方也是如此建议,所有的新功能都先以 CRD 的方式扩展,不要对主干代码有太多变更。Helm client不用再通过gPRC和 tiller 通信,其实这还有一个好处,写过使用自己的Helm client代码的同学应该都有一个痛苦点,那么就是使用gPRC通信,每次都得通过tunnel和tiller连接,网络消耗极大,代码写起来也很麻烦,一切都 HTTP 后,世界就清静了。

Chart repo auth & upload

Helm 社区终于意识到 chart 存储也是很重要的一件事,helm3将默认集成chart repo的授权与推送命令。这里的改变主要有如下几处:

  • “helm push” command to upload chart to a repo
  • Plugins can supply custom protocols (e.g. s3://)
  • “helm login” command to authenticate against a repo
  • Limit which users can upload/install which charts

主要概括一下就是可以helm login登录chart repo服务,然后 push 自己的chart,同时也可以pull 一些公开的chart。这里其实有一个类似docker hub的概念,后面应该也会有chart hub,这些会由第三方来实现,当然maintainer由于现在在微软工作,他们也表示微软也会提供chart托管服务。

New chart.yaml

新的chart 版本将在helm 3提供,主要由一下几点:

  • Current chart.yaml files will not be broken
  • The requirements file will no longer exist
  • Requirements will now be part of the charts.yaml

举个例子很好理解。

KubeCon 参会记录之 -- Helm 3 Deep Dive

可以看到所有依赖项都直接在chart.yaml里面展现,这样比较一目了然。

Other Helm 3 changes

  • “Managed” hooks - if Helm creates something, it will delete it
  • index.yaml will move to index.json, and be partitioned for performance
  • Schematize your values by including a values.schema.yaml file
  • Helm client libraries will be much better

现在Helm 2使用hooks创建的 k8s 资源在删除release的时候不会被连带删除。index.yaml被替换为index.json,maintainer表示这是为了增加性能。对于开发者最好的消息莫过于helm 3将要提供client library,再也不用为了引用helm client代码,而去翻看它的源码一点点找依赖了,不得不吐槽,k8s vendor真的很可怕。

In the end

从参会者的积极性来看,Helm依然是社区以及线下生产公认的通用包管理器。自从Helm 进入到CNCF社区项目后,估计后面社区会把所有关于包管理器的功能都放到Helm中,Helm后面在社区的发展应该会越来越火热。这里穿插一下sig app讨论的一个小故事,sig app开发了一个Application kind,其实就是定义了一个应用级别的 spec,描述了一些 k8s 子资源的聚合体,并不具备update等功能,当时sig app成员就表示,helm v3将会默认支持application kind,由此可见,关于包管理与资源管理社区会把资源越来越多的投入到Helm这一边。

上一篇:全球首个!阿里云开源批流一体机器学习平台Alink


下一篇:使用docker compose 测试集群网络连接性