如果你听说过关于Helm 3的唯一一件事就是它删除了Tiller动态配置文件生成工具，那么你已经知道最重要的一点：该项目经历了一次重大的重写，以赶上Kubernetes的发展并消除长期的安全问题。
这是项目成熟的标志，也反映在其他关键开发中，如更好的补丁合并、对可用性（包括发布管理）的重大改进，以及对Helm 2 chart的明确支持生命周期。
微软的Helm主程序经理Bridget Kromhout表示，对于安全性和稳定性来说，这是一个很好的信号。
“Helm 3更简单，更安全，它可能不会吸人眼球，但这些功能足以让运维大规模系统的人高兴。"
“一个项目删除大块代码，这是成熟的标志。”Azure Container Compute和Kubernetes 1.16发布的首席程序经理Lachlan Evenson表示，“我们需要做的是改善安全。在Helm 2社区我们听到的是，我们喜欢Helm，但是Helm的安全特性并不是我们在生产中想要的。”
去掉Tiller
Helm是一个古老的项目，由Deis在Kubernetes之后不久开始研发，并在第一次Kubecon上宣布。Helm 2是与谷歌的Kubernetes Deployment Manager团队一起构建的，添加了Tiller组件和GRPC来处理Helm chart的安装和管理，呈现chart并将它们推送到Kubernetes API服务器。
Tiller允许团队共享一个Kubernetes集群，多个operator可以使用同一组版本，但是随着Kubernetes API的发展，Tiller没有跟上，这导致了一些人担心授予任何可以访问Tiller的人的权限过于宽泛。
“Helm的问题很多都是关于安全性的，比如如何将现成的软件安全地交付到集群中？”Azure Compute主管Gabe Monroy解释道，他在Deis的团队启动了这个项目。“Helm 3被重新设计，移除了Tiller，并将许多逻辑转移到更现代的Kubernetes技术中，比如operator和客户端模板。”
移除Tiller是可能的，因为自从Helm 2在2016年发布以来，Kubernetes增加了一些重要的功能，比如Role-Based Access Control和Custom Resource Definitions。“当时，没有CRD，也没有RBAC。God是唯一模式，没有其他方法可以做到。”
既然CRD已经可用，就不再需要Tiller来维护状态或成为通过Helm部署的发布信息的中心枢纽——所有这些信息都可以作为记录存储在Kubernetes中。用户身份验证和授权现在由Kubernetes完成，Helm权限只是Kubernetes权限，因此它们使用RBAC，集群管理员可以选择要使用的细粒度Helm权限。
代替Tiller的客户机-服务器模型，Helm变成了Kubernetes客户端——这样去除了复杂度层，但仍然给运维人员提供他们需要的工具。
IBM高级软件工程师兼Helm核心维护人员Martin Hickey表示，如果你习惯了Helm 2，这将是思维方式的一个重大转变。
Helm 3还降低了安装和运维的复杂性
当你部署一个版本时，它并没有存储在集群内的命名空间中。它被储存在Tiller的命名空间里。默认情况下，这就是kubesystem。这是你的系统命名空间！如果你习惯了Helm 2的工作方式，命名空间的改进可能会有些混乱，因为你必须在正确的地方寻找你的部署。
“因为Tiller是在god模式下运行的，除非你对它进行了不同的配置，否则helm-ls命令会返回所有东西。现在它将进入你要求它进入的命名空间-是的，现在你必须创建命名空间。”
版本、配置和chart
没有Tiller，Helm需要一种方法来跟踪集群中不同版本的状态。Helm 2可以选择使用秘密来释放对象，现在这是默认的。
与版本一起存储在命名空间中的版本信息也非常不同：它既包括关于chart的特定安装的版本实例，也包括存储版本升级、回滚或删除详细信息的ReleaseVersion秘密。
如果你需要在多个地方安装同一个应用程序，那么将版本信息存储在相关的命名空间中也可以更容易地重复名称。对于Helm 2，如果有一个为集群运行的Tiller实例，那么版本名称必须是唯一的。
随着Tiller的消失，Helm现在直接与Kubernetes API对话，helm init和home也被删除，因为你不需要它们来创建和存储配置；相反，配置文件现在使用XDG存储。
尽管Helm基本上是重写了来删除Tiller，Helm 2 chart仍将可以用于Helm 3（少数例外，这将意味着它们需要更新）。
“架构非常不同，更加现代化，但它仍然具有生态系统中创建的内容的所有相同优点，这些内容为你提供了输入helm install kafka的良好体验，并且你有一个增加了安全性的kafka集群正在运行。”
围绕CRD的变化反映了这样一个事实：Kubernetes生态系统仍然在决定如何管理VRD，以避免类似DLL地狱的情况。“一个应用程序可以拥有一个CRD，CRD也可以由许多应用程序拥有，我们试图用chart来管理CRD。我们已经对它进行了简化和重新设计，只创建CRD；因此不再进行修改或删除。现在将自动安装CRDS，但是如果它们已经存在，不再安装，并且有一个命令跳过安装。这符合越来越普遍的DevOps模式，即用一个chart安装CRD，然后用自己的chart安装应用程序。”
如果希望chart既可以用于Helm 2，也可以用于Helm 3，请确保它们创建了命名空间并同时使用crd install钩子和crds/目录；Helm 3将忽略该钩子，并发出警告。
但是如果你已经准备好了用Helm 3，你可以利用一些新的chart特性，但应该将helm3 chart标记为使用Helm version 2 API。
需求和依赖关系会移动到chart.yaml文件中，因此需要为Helm 2和3分别指定它们。chart现在还可以使用JSON模式来验证install、upgrade、template和lint命令，以便更清楚地知道需要设置哪些值。
当你使用Helm更新版本时，它现在执行一个三向合并，其中包括live cluster状态以及使用最新的和建议的chart清单。
更简单，更安全
Helm 3重新架构的另一个结果是Go-SDK也进行了重组。CLI是围绕SDK的一个包装器，使其易于使用，但是如果你想创建更复杂的部署模式，则需要直接使用SDK并在Helm 2中使用，这很难做到。“现在它已经很好地被解压出来了，而且包更好地封装在远离CLI部分的地方。”如果你想让Helm成为管道的一部分（在这个管道中你需要使用Helm所做的一部分并在其间插入自己的步骤），那么可以直接调用Go SDK中的包来完成这项工作。实际上，从Helm 2迁移到3的插件就是这样工作的。
强调Helm引擎和社区chart内容的成熟度，是该项目从云计算基础孵化状态中毕业的一步，也是通过其先决条件的第三方安全审核的一步。
与Helm安全审计一起，Snyk还对public Helm repo中的chart进行了安全审计，查找这些图表引用的镜像中的漏洞。
Helm这样被广泛使用的技术（每月下载量超过100万次，是CNCF第三大被采用的技术）仍在孵化中，这是令人惊讶的。它曾经是一个顶级的Kubernetes项目，直到2018年Kubernetes自己“搬到”CNCF后才成为一个独立项目。随着安全审计的完成，Helm很可能在2020年初毕业。
“围绕Helm的社区规模庞大，种类繁多，并继续以令人难以置信的速度增长。能够用一个命令安装复杂软件，是Kubernetes和CNCF生态系统所追求的。Helm支持helm安装模式，而生态系统的其他部分仍在努力实现这种模式。”
能够在不影响用户的情况下进行重大的内部更改，使项目与当前关注的问题保持相关性，这是一项令人印象深刻的成就。尽管在云原生世界中有各种各样的打包和安装工具，Helm仍然能够很好地保持相关性。
“经得起时间考验的平台有能力随着技术基础的变化而发展。Kubernetes正在展示以这种方式进化的能力，Helm也是一样的。”
原文链接：https://thenewstack.io/helm-3-is-almost-boring-and-thats-a-great-sign-of-maturity/