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版本正在进行的所有工作，大家可以在这里看到他们正在提交的代码。

这里回顾了一下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 对比图。

是不是满脸惊讶。这还是我认识的那个 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

可以通过这个架构图看到，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

举个例子很好理解。

可以看到所有依赖项都直接在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这一边。