广告

你觉得Helm 3无聊?其实这说明它成熟了

  • 浏览(57)
  • 评论(0)
  • 译者:k8s

如果你听说过关于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/

  • 分享到:
  • icon
  • icon
  • icon
  • icon
箭头