Helm 3预览：探索我们的未来 - 第2部

作者：Matt Fisher

这是Helm 3预览：探索我们的未来博客文章7部中的第2部。（查看我们之前关于Helm历史的第1部。）

在Helm 2开发周期中，我们引入Tiller作为与谷歌部署管理器（Deployment Manager）集成的一部分。对于在共享集群上工作的团队来说，Tiller发挥了重要的作用，使多个不同的操作者能够与同一组版本交互。

在Kubernetes 1.6中默认启用了基于角色的访问控制（role-based access controls，RBAC），锁定Tiller以便在生产场景中使用变得难以管理。由于有大量可能的安全政策，我们的立场是提供一个允许的默认配置。这使得第一次使用Helm和Kubernetes的用户可以直接开始尝试，而无需深入到安全控制。不幸的是，这种允许的配置会授予用户他们不需拥有的广泛权限。将Tiller安装到多租户集群时，DevOps和SREs必须学习额外的操作步骤。

在了解社区成员如何使用Helm之后，我们发现Tiller的发布管理系统不需要依赖集群内的管理器来维护状态，或充当Helm发布信息的中心枢纽。相反，我们可以简单地从Kubernetes API服务器获取信息，生成Chart客户端，并在Kubernetes中存储安装记录。

Tiller的主要目标可以在没有Tiller的情况下完成，所以我们在Helm 3做出的第一个决定就是完全移除Tiller。

Tiller消失后，Helm的安全模型大大地简化。Helm 3现在支持现代的Kubernetes的所有现代的安全性、身份和授权特性。Helm的权限使用kubeconfig文件进行评估。集群管理员可以在他们认为合适的粒度上限制用户权限。版本仍然在集群中记录，Helm的其他功能仍然保留。

https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/

我们的下一篇博客文章讨论Chart储存库。不要错过Helm 3预览：探索我们的未来博客系列共7部文章。