恕我直言，对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 来覆盖它，但它还是增加了另外一层复杂性。
作为基础设施生命周期管理工具
忘了它吧。它不会奏效，特别是对于核心的 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 （https://github.com/helm/community/blob/master/helm-v3/000-helm-v3.md）设计提案。
我非常喜欢无 Tiller 架构的想法，但对于 Lua 脚本，我不确定，因为它会额外增加图表的复杂性。
最近我发现 Operators 有一个大的变化，与 Helm 图表相比，它更像是 Kubernetes 原生的。
我真希望社区能尽快解决这个问题，但与此同时，我更倾向于尽可能少地使用 Helm。
不要误解我——我花了一些时间在 Kubernetes 之上构建了一个混合云部署平台，以上这些只是我从中得出的个人观点。
英文原文
- https://medium.com/virtuslab/think-twice-before-using-helm-25fbb18bc822