转自微信公众号： https://mp.weixin.qq.com/s/lHVYZQQ0uIaooSjxu_-1Ig
引言
由于项目原因，需要在生产环境中部署helm，所以对于helm的版本进行了一些调研。发现19年发布的helm 3 的一个很大变化就是移除了heml2中非常重要的组成部分Tiller，所以专门查阅了官方说明。以了解该重大变更的背景及技术考量。
During the Helm 2 development cycle, we introduced Tiller. Tiller played an important role for teams working on a shared cluster - it made it possible for multiple different operators to interact with the same set of releases.
在helm2中Tiller是helm的一个重要组成部分。它可以在一个共享的集群中管理复杂的应用发布。
With role-based access controls (RBAC) enabled by default in Kubernetes 1.6, locking down Tiller for use in a production scenario became more difficult to manage. Due to the vast number of possible security policies, our stance was to provide a permissive default configuration. This allowed first-time users to start experimenting with Helm and Kubernetes without having to dive headfirst into the security controls. Unfortunately, this permissive configuration could grant a user a broad range of permissions they weren’t intended to have. DevOps and SREs had to learn additional operational steps when installing Tiller into a multi-tenant cluster.
从kubernetes 1.6开始默认开启RBAC。这是Kubernetes安全性/企业可用的一个重要特性。但是在RBAC开启的情况下管理及配置Tiller变的非常复杂。为了简化helm的尝试成本我们给出了一个不需要关注安全规则的默认配置。但是，这会导致一些用户意外获得了他们并不需要的权限。并且，管理员/SRE需要学习很多额外的知识才能将Tiller部署的到关注安全的生产环境的多租户K8S集群中并使其正常工作。
After hearing how community members were using Helm in certain scenarios, we found that Tiller’s release management system did not need to rely upon an in-cluster operator to maintain state or act as a central hub for Helm release information. Instead, we could simply fetch information from the Kubernetes API server, render the Charts client-side, and store a record of the installation in Kubernetes.
在了解了社区成员通常的使用场景后，我们发现Tiller的发布管理系统不需要依靠集群内的Operator来维护状态或充当Helm发布信息的中央枢纽。相反，我们可以简单地从Kubernetes API服务器中获取信息，渲染Charts客户端，并在Kubernetes中存储安装记录。
Tiller’s primary goal could be accomplished without Tiller, so one of the first decisions we made regarding Helm 3 was to completely remove Tiller.
没有Tiller也能实现所有的功能，所以我们针对Helm 3做出的第一个决定就是彻底删除Tiller。
With Tiller gone, the security model for Helm is radically simplified. Helm 3 now supports all the modern security, identity, and authorization features of modern Kubernetes. Helm’s permissions are evaluated using your kubeconfig file. Cluster administrators can restrict user permissions at whatever granularity they see fit. Releases are still recorded in-cluster, and the rest of Helm’s functionality remains.
移除掉Tiller大大简化了hlem的安全模型实现方式。Helm3现在可以支持所有的kubernetes认证及鉴权等全部安全特性。Helm和本地的kubeconfig flie中的配置使用一致的权限。管理员可以按照自己认为合适的粒度来管理用户权限。