Helm3版本中改了哪些内容
Helm 3版本中改了哪些内容?针对这个问题,今天小编总结这篇有关Helm 3的文章,希望能帮助更多想解决这个问题的朋友找到更加简单易行的办法
公司主营业务:成都做网站、成都网站制作、移动网站开发等业务。帮助企业客户真正实现互联网宣传,提高企业的竞争能力。创新互联公司是一支青春激扬、勤奋敬业、活力青春激扬、勤奋敬业、活力澎湃、和谐高效的团队。公司秉承以“开放、自由、严谨、自律”为核心的企业文化,感谢他们对我们的高要求,感谢他们从不同领域给我们带来的挑战,让我们激情的团队有机会用头脑与智慧不断的给客户带来惊喜。创新互联公司推出南山免费做网站回馈大家。
1、 移除了Tiller
Helm最终移除了其服务器端组件,Tiller。现在,它完全没有代理。Tiller之前是一个运行在Kubernetes上的小型应用程序,它用于监听Helm命令并处理设置Kubernetes资源的实际工作。
这是Helm3中最重大的更改。为什么Tiller的移除备受关注呢?首先,Helm应该是一种在Kubernetes配置上的模板机制。那么,为什么需要在服务器上运行某些代理呢?
Tiller本身也存在一些问题,因为它需要集群管理员的ClusterRole才能创建。因此,假设你要在Google Cloud Platform中启动的Kubernetes集群上运行Helm应用程序。首先,你需要启动一个新的GKE集群,然后使用helm init初始化Helm,然后…发现它失败了。这种情况之所以会发生是因为,在默认状态下,你没有给你的kubectl上下文分配管理员权限。现在你了解到了这一点,开始搜索为分配管理员权限的magic命令。这一系列操作下来,也许你已经开始怀疑Helm是否真的是一个不错的选择。
此外,由于Tiller使用的访问权限与你在kubectl上下文中配置的访问权限不同。因此,你也许可以使用Helm创建应用程序,但你可能无法使用kubectl创建该程序。这一情况如果没排查出来,看起来感觉像是安全漏洞。
幸运的是,现在Tiller已经被完全移除,Helm现在是一个客户端工具。这一更改会导致以下结果:
Helm使用与kubectl上下文相同的访问权限
你无需再使用helm init来初始化Helm
- Release Name 位于命名空间中
Helm 3一直保持不变的是:它应该只是一个在Kubernetes API上执行操作的工具。如此,如果你可以使用纯粹的kubectl命令执行某项操作,那么也可以使用helm执行该操作。
2、 分布式仓库以及Helm Hub
Helm命令可以从远程仓库安装Chart。在Helm 3之前,它通常使用预定义的中心仓库,但你也能够添加其他仓库。但是从现在开始,Helm将其仓库模型从集中式迁移到分布式。这意味着两个重要的改变:
预定义的中心仓库被移除
- Helm Hub(一个发现分布式chart仓库的平台)被添加到helm search
为了能够更好地理解这一改变,我给你们一个示例。在Helm 3之前,如果你想要安装一个Hazelcast集群,你需要执行以下命令:
$ helm2 install --name my-release stable/hazelcast
现在,这个命令不起作用了。你需要先添加远程仓库才能进行安装。这是因为这里不再存在一个预定义中心仓库。要安装Hazelcast集群,你首先需要添加其仓库然后安装chart:
$ helm3 repo add hazelcast https://hazelcast.github.io/charts/
$ helm3 repo update
$ helm3 install my-release hazelcast/hazelcast
好消息是现在Helm 命令可以直接在Helm Hub中寻找Chart。例如,如果你想知道在哪个仓库中可以找到Hazelcast,你只需执行以下命令即可:
$ helm3 search hub hazelcast
以上命令列出在Helm Hub中所有分布式仓库中名称中包含“hazelcast”的Chart。
现在,我来问你一个问题。移除掉中心仓库是进步还是退步?这有两种观点。第一种是chart维护者的观点。例如,我们维护Hazelcast Helm Chart,而Chart中的每个更改都需要我们将其传播到中心仓库中。这项额外的工作使得中心仓库中的许多Helm Chart没有得到很好地维护。这一情况与我们在Ubuntu/Debian包仓库中所经历的很相似。你可以使用默认仓库,但它常常只有旧的软件包版本。
第二种观点来自Chart的使用者。对于他们来说,虽然现在安装一个chart比之前稍微困难了一些,但另一方面,他们能够从主要的仓库中安装到最新的chart。
3、 JSON Schema 验证
从Helm 3开始,chart维护者可以为输入值定义JSON Schema。这一功能的完善十分重要,因为迄今为止你可以在values.yaml中放入任何你所需的内容,但是安装的最终结果可能不正确或出现一些难以理解的错误消息。
例如,你在port参数中输入字符串而不是数字。那么你会收到以下错误:
$ helm2 install --name my-release --set service.port=string-name hazelcast/hazelcast
Error: release my-release failed: Service in version "v1" cannot be handled as a Service:
v1.Service.Spec: v1.ServiceSpec.Ports: []v1.ServicePort: v1.ServicePort.Port: readUint32:
unexpected character: �, error found in #10 byte of ...|","port":"wrong-name|..., bigger
context ...|fault"},"spec":{"ports":[{"name":"hzport","port":"wrong-name","protocol":
"TCP","targetPort":"hazelca|...
你不得不承认这个问题难以分析和理解。
此外,Helm 3默认添加了针对Kubernetes对象的OpenAPI验证,这意味着发送到Kubernetes API的请求将会被检查是否正确。这对于Chart维护者来说,是一项重大利好。
4、 Helm 测试
Helm测试是一个小小的优化。尽管微小,但它也许实际上鼓励了维护者来写Helm测试以及用户在安装完每个chart之后执行helm test命令。在Helm 3之前,进行测试多少都显得有些奇怪:
1、 此前测试作为Pod执行(好像需要一直运行);现在你可以将其定义为Job。
2、 测试Pod不会自动被移除(除非你使用magic flag –cleanup
),所以默认状态下,没有任何技巧,对于既定的版本你不能多次执行helm test。但幸运的是,现在可以自动删除测试资源(Pod、Job)。
当然旧的测试版本也并非不能使用,只需要使用Pod并始终记得执行helm test –cleanup
。但也不得不承认,这一改进有助于提升测试体验。
5、 命令行语法
最后一点是,Helm命令语法有所改变。从积极的一面来看,我认为所有的改变都是为了让体验更好;从消极的方面看,这一语法不与之前的版本兼容。因此,现在编写有关如何使用Helm安装东西的步骤时,需要明确指出所使用的命令是用于Helm 2还是用于Helm 3。
举个例子,从helm install
开始说起。现在版本名称已经成为必填参数,尽管在Helm 2中你可以忽略它,名称也能够自动生成。如果在Helm3中要达成相同的效果,你需要添加参数--generate-name
。所以,使用Helm 2进行标准的安装应该如下:
$ helm2 install --name my-release hazelcast/hazelcast
在Helm 3中,需要执行以下命令:
$ helm3 install my-release hazelcast/hazelcast
还有另一个比较好的改变是,删除Helm版本后,无需添加—purge。简单地输入命令helm uninstall <release-name>
即可删除所有相关的资源。
还有一些其他改变,如一些命令被重命名(不过使用旧的名称作为别名),有一些命令则被删除(如 helm init
)。如果你还想了解更多关于Helm 命令语法更改的信息,请参考官方文档:
https://helm.sh/docs/faq/#cli-command-renames
关于Helm 3的新特点就分享到这里了,希望以上内容可以对大家有一定的帮助,可以学到更多知识。如果觉得文章不错,可以把它分享出去让更多的人看到。
本文标题:Helm3版本中改了哪些内容
URL地址:http://myzitong.com/article/gpedcc.html