皇上,还记得我吗?我就是1999年那个Linux伊甸园啊-----24小时滚动更新开源资讯,全年无休!

Helm:三思而后用

作者 Bartłomiej Antoniak     ,译者 谢丽

Helm 是 Kubernetes 的包管理器。它可以大幅简化发布过程,但有时候也会带来问题。近日,Helm 已经正式提升为顶级的 CNCF 项目,并且在社区得到了广泛的应用。这说明 Helm 确实是个不错的项目了,但我将和你分享我对于 Helm 的一些思考。

本文将说明我不相信那些大肆宣传的原因。

Helm 的真正价值是什么?

到现在我仍然不清楚 Helm 的价值。它没有提供任何特别的东西。Tiller 带来了什么价值(服务器端部分)?

许多 Helm 图表还很不完善,需要花些功夫才能把它们用在 Kubernetes 集群上,例如,缺少 RBAC、资源限制或网络策略;这意味着你无法以二进制方式安装 Helm 图表,忘记里面有什么吧。

我希望有人可以向我解释一下 安全的多租户生产环境 方面,而不仅仅是使用 hello world 的例子吹嘘它有多酷。

Linus Torvalds 说过,”Talk is cheap. Show me the code.”

另一个身份验证& 访问控制层

有人把 Tiller 比作“巨型 sudo 服务器”。对我来说,它只是另一个授权层,没有访问控制,而且需要维护额外的 TLS 证书。为什么不利用 Kubernetes API,依赖现有的具有适当审计和 RBAC 功能的安全模型呢?

它只是一个被美化了的模板工具?

它就是使用 values.yaml 中的配置渲染和检查 go-template 文件。然后,把渲染好的 Kuberentes 清单以及相应的元数据存储在 ConfigMap 中。

这可以使用几个简单的命令替代:

$ # 使用 golang 或 python 脚本渲染 go-template 文件 
$ kubectl apply --dry-run -f .
$ kubectl apply -f .

据我观察,团队常常在每个环境中都有一个 values.yaml 文件,甚或是在使用之前从 values.yaml.tmpl 渲染它。

对于 Kubernetes Secrets 来说,这是没有意义的,因为它们通常是在库中进行加密和版本化。你既可以使用 helm-secrets 插件来实现这一点,也可以使用 set key=value 来覆盖它,但它还是增加了另外一层复杂性。

Helm 作为基础设施生命周期管理工具

忘了它吧。它不会奏效,特别是对于核心的 Kubernetes 组件,如 kube-dns、CNI 提供程序、“集群自动定标器(cluster autoscaler)”等。这些组件有不同的生命周期,Helm 不适合这些组件。

根据我使用 Helm 的经验,对于使用基础 Kubernetes 资源(很容易地从头重新创建,而且没有复杂的发布过程)的简单部署,它可以做得很好。

遗憾的是,Helm 不能处理更高级和频繁的部署,包括名称空间、RBAC、网络策略、ResourceQuota 或 PodSecurityPolicy。

我知道这可能会冒犯对 Helm 着迷的人,但这是一个可悲的事实。

Helm 状态

Tiller 服务器将信息存储在位于 Kubernetes 内部的 ConfigMaps 中。它不需要自己的数据库。

遗憾的是,由于 etcd 的限制 ,ConfigMap 的限值仅有 1MB

希望有人能想出个注意来扩展 ConfigMap 存储驱动程序,在存储之前压缩序列化的版本,但在我看来,这仍然不能解决实际问题。

随机故障和错误处理

这是我最担心的事情——我不能依赖它。

Error: UPGRADE FAILED: “foo” has no deployed releases

错误:升级失败:“foo” 没有已部署的版本

恕我直言,这是 Helm 令人讨厌的问题之一。

如果第一次发布失败,那么随后的每次尝试都会返回一个错误,说它无法从未知状态升级。

下面 PR 通过添加–forceflag 来“修复”它,但实际上是通过执行 helm delete&helm install –replace 隐藏了问题:https://github.com/kubernetes/helm/pull/3597

然而,大多数情况下,你最终会彻底清理该发布。

helm delete --purge $RELEASE_NAME

如果 ServiceAccount 缺失或 RBAC 不允许创建特定的资源,Helm 将返回以下错误消息:

Error: release foo failed: timed out waiting for the condition

很遗憾,Helm 并没有提供出现这种情况的根本原因:

kubectl -n foo get events --sort-by='{.lastTimestamp}'
Error creating: pods "foo-5467744958" is forbidden: error looking up service account foo/foo: serviceaccount "foo" not found

有个别情况下,Helm 成功失败而不做任何事情。例如,有时它不更新资源限制。

helm init 运行单副本 Tiller——非 HA

在默认情况下,Tiller 不是 HA 的,下面的 PR 仍处于打开状态:https://github.com/helm/helm/issues/2334

有一天,这可能会导致宕机……

Helm 3? Operators? 未来?

Helm 的下个版本将带来一些值得期待的特性:

  • 不分客户端/服务器端的单服务架构——无需 Tiller
  • 嵌入式 Lua 脚本引擎
  • 拉式 DevOps 工作流, 一个新的 Helm Controller 项目将会启动

要了解更多信息,请查看 Helm 3 设计提案。

我非常喜欢无 Tiller 架构的想法,但对于 Lua 脚本,我不确定,因为它会额外增加图表的复杂性。

最近我发现 Operators 有一个大的变化,与 Helm 图表相比,它更像是 Kubernetes 原生的。

我真希望社区能尽快解决这个问题,但与此同时,我更倾向于尽可能少地使用 Helm。

不要误解我——我花了一些时间在 Kubernetes 之上构建了一个混合云部署平台,以上这些只是我从中得出的个人观点。

查看英文原文:Think twice before using Helm

转自 http://www.infoq.com/cn/articles/think-twice-before-using-helm

分享到:更多 ()