Helm：三思而后用
Helm是Kubernetes的包管理器。它可以大幅简化发布过程，但有时候也会带来问题。近日，Helm已经正式提升为顶级的CNCF项目，并且在社区得到了广泛的应用。这说明Helm确实是个不错的项目了，但我将和你分享我对于Helm的一些思考。
\u0026#xD;\u0026#xD;本文将说明我不相信那些大肆宣传的原因。
\u0026#xD;\u0026#xD;Helm的真正价值是什么？
\u0026#xD;\u0026#xD;到现在我仍然不清楚Helm的价值。它没有提供任何特别的东西。Tiller带来了什么价值（服务器端部分）？
\u0026#xD;\u0026#xD;许多Helm图表还很不完善，需要花些功夫才能把它们用在Kubernetes集群上，例如，缺少RBAC、资源限制或网络策略；这意味着你无法以二进制方式安装Helm图表，忘记里面有什么吧。
\u0026#xD;\u0026#xD;我希望有人可以向我解释一下安全的多租户生产环境方面，而不仅仅是使用hello world的例子吹嘘它有多酷。
\u0026#xD;\u0026#xD;Linus Torvalds说过，\"Talk is cheap. Show me the code.\"
\u0026#xD;\u0026#xD;另一个身份验证\u0026amp;访问控制层
\u0026#xD;\u0026#xD;有人把Tiller比作“巨型sudo服务器”。对我来说，它只是另一个授权层，没有访问控制，而且需要维护额外的TLS证书。为什么不利用Kubernetes API，依赖现有的具有适当审计和RBAC功能的安全模型呢？
\u0026#xD;\u0026#xD;它只是一个被美化了的模板工具？
\u0026#xD;\u0026#xD;它就是使用values.yaml中的配置渲染和检查go-template文件。然后，把渲染好的Kuberentes清单以及相应的元数据存储在ConfigMap中。
\u0026#xD;\u0026#xD;这可以使用几个简单的命令替代：
\u0026#xD;\u0026#xD;\u0026#xD;$ # 使用golang或python脚本渲染go-template文件\u0026#xD;$ kubectl apply --dry-run -f .\u0026#xD;$ kubectl apply -f .\u0026#xD;\u0026#xD;
据我观察，团队常常在每个环境中都有一个values.yaml文件，甚或是在使用之前从values.yaml.tmpl渲染它。
\u0026#xD;\u0026#xD;对于Kubernetes Secrets来说，这是没有意义的，因为它们通常是在库中进行加密和版本化。你既可以使用helm-secrets插件来实现这一点，也可以使用set key=value来覆盖它，但它还是增加了另外一层复杂性。
\u0026#xD;\u0026#xD;Helm作为基础设施生命周期管理工具
\u0026#xD;\u0026#xD;忘了它吧。它不会奏效，特别是对于核心的Kubernetes组件，如kube-dns、CNI提供程序、“集群自动定标器（cluster autoscaler）”等。这些组件有不同的生命周期，Helm不适合这些组件。
\u0026#xD;\u0026#xD;根据我使用Helm的经验，对于使用基础Kubernetes资源（很容易地从头重新创建，而且没有复杂的发布过程）的简单部署，它可以做得很好。
\u0026#xD;\u0026#xD;遗憾的是，Helm不能处理更高级和频繁的部署，包括名称空间、RBAC、网络策略、ResourceQuota或PodSecurityPolicy。
\u0026#xD;\u0026#xD;我知道这可能会冒犯对Helm着迷的人，但这是一个可悲的事实。
\u0026#xD;\u0026#xD;Helm状态
\u0026#xD;\u0026#xD;\u0026#xD;\u0026#xD;\u0026#xD;Tiller服务器将信息存储在位于Kubernetes内部的ConfigMaps中。它不需要自己的数据库。
\u0026#xD;
遗憾的是，由于etcd的限制，ConfigMap的限值仅有1MB。
\u0026#xD;\u0026#xD;希望有人能想出个注意来扩展ConfigMap存储驱动程序，在存储之前压缩序列化的版本，但在我看来，这仍然不能解决实际问题。
\u0026#xD;\u0026#xD;随机故障和错误处理
\u0026#xD;\u0026#xD;这是我最担心的事情——我不能依赖它。
\u0026#xD;\u0026#xD;\u0026#xD;\u0026#xD;\u0026#xD;Error: UPGRADE FAILED: \"foo\" has no deployed releases
\u0026#xD;\u0026#xD;错误：升级失败：“foo\"没有已部署的版本
\u0026#xD;
恕我直言，这是Helm令人讨厌的问题之一。
\u0026#xD;\u0026#xD;如果第一次发布失败，那么随后的每次尝试都会返回一个错误，说它无法从未知状态升级。
\u0026#xD;\u0026#xD;下面PR通过添加--forceflag来“修复”它，但实际上是通过执行helm delete\u0026amp;helm install --replace隐藏了问题：https://github.com/kubernetes/helm/pull/3597
\u0026#xD;\u0026#xD;然而，大多数情况下，你最终会彻底清理该发布。
\u0026#xD;\u0026#xD;\u0026#xD;helm delete --purge $RELEASE_NAME\u0026#xD;\u0026#xD;
如果ServiceAccount缺失或RBAC不允许创建特定的资源，Helm将返回以下错误消息：
\u0026#xD;\u0026#xD;\u0026#xD;Error: release foo failed: timed out waiting for the condition\u0026#xD;\u0026#xD;
很遗憾，Helm并没有提供出现这种情况的根本原因：
\u0026#xD;\u0026#xD;\u0026#xD;kubectl -n foo get events --sort-by='{.lastTimestamp}'\u0026#xD;Error creating: pods \"foo-5467744958\" is forbidden: error looking up service account foo/foo: serviceaccount \"foo\" not found\u0026#xD;\u0026#xD;
有个别情况下，Helm成功失败而不做任何事情。例如，有时它不更新资源限制。
\u0026#xD;\u0026#xD;helm init运行单副本Tiller——非HA
\u0026#xD;\u0026#xD;在默认情况下，Tiller不是HA的，下面的PR仍处于打开状态：https://github.com/helm/helm/issues/2334
\u0026#xD;\u0026#xD;有一天，这可能会导致宕机……
\u0026#xD;\u0026#xD;Helm 3？ Operators？ 未来？
\u0026#xD;\u0026#xD;Helm的下个版本将带来一些值得期待的特性：
\u0026#xD;\u0026#xD;- 不分客户端/服务器端的单服务架构——无需Tiller\u0026#xD;\t
- 嵌入式Lua脚本引擎\u0026#xD;\t
- 拉式DevOps工作流， 一个新的Helm Controller项目将会启动\u0026#xD;
要了解更多信息，请查看Helm 3设计提案。
\u0026#xD;\u0026#xD;我非常喜欢无Tiller架构的想法，但对于Lua脚本，我不确定，因为它会额外增加图表的复杂性。
\u0026#xD;\u0026#xD;最近我发现Operators有一个大的变化，与Helm图表相比，它更像是Kubernetes原生的。
\u0026#xD;\u0026#xD;我真希望社区能尽快解决这个问题，但与此同时，我更倾向于尽可能少地使用Helm。
\u0026#xD;\u0026#xD;不要误解我——我花了一些时间在Kubernetes之上构建了一个混合云部署平台，以上这些只是我从中得出的个人观点。
\u0026#xD;\u0026#xD;查看英文原文：Think twice before using Helm
\u0026#xD;\u0026#xD;感谢张婵对本文的审校。