轉自微信公衆號： 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中的配置使用一致的權限。管理員可以按照自己認爲合適的粒度來管理用戶權限。