有人可以解释一下 helm 的一些用例吗？

Question

我目前正在使用 kubernetes，并且遇到了 helm。 假设我不喜欢用与我的应用程序无关的进程“感染”我的 kubernetes 集群的想法，但如果它可能是有益的，我很乐意接受。

所以我做了一些研究，但我仍然找不到任何我无法通过使用我的 yaml 描述符和 kubectl 轻松完成的事情，所以现在我找不到除了环境之外的用途。

例如（取自我阅读的指南：

1. 您可以轻松安装应用程序，例如。 helm install nginx —> 我在部署描述符中添加了一个 nginx 映像，完成
2. repositories -> 我有 docker 的（我从中提取图像）
3. 您可以在发布失败的情况下轻松控制回滚-> 我只是将映像版本更改为我的 kubernetes 描述符中的前一个版本，很容易

困扰我的是，在命令级别，我做了几乎相同的工作（helm update->kubectl apply）。 作为交换，我有很多样板，因为要保持 helm 想要的目录结构，我觉得我错过了简单的部署描述符所拥有的控制......我错过了什么？

Answer 1

您的问题完全可以理解。对于小型和简单的部署，好处实际上并没有那么大。但是当某些东西的部署非常复杂时，Helm 会很有帮助。

假设您有几个小组为某家公司开发微服务。如果您可以制作一个适用于大多数微服务的图表，那么每个微服务的部署将仅因图像和所需资源而异。通过这种方式，您可以获得标准化的部署，并且对所有开发人员都更容易。

另一个用例是部署需要大量活动部件的应用程序。例如，如果你想在 Kubernetes 上部署一个 Grafana 服务器，你可能至少需要一个 Deployment 和一个 Configmap，那么你就需要一个匹配这个部署的服务。如果你想把它暴露在互联网上，你也需要一个入口。

一个相对简单的应用程序，需要 4 个不同的 YAML，您需要手动配置并确保一切正确，而不是您可以做一个简单的 helm install 并重用某人已经完成的配置，有时甚至是创建的公司应用程序。

还有很多其他用例，但我想说这两个是最常见的。

Answer 2

以下是 Helm 有用的三个建议：

1. 您的持续部署系统在某种程度上会定期生成新的构建，并希望将它们发送到 Kubernetes 集群。您可以使用模板来指定部署中的图像名称和标签，因此helm upgrade ... --set tag=201907211931 可以请求特定标签。

2. 您可能拥有各种特定于服务的控件，例如日志级别或外部数据库主机名。 Helm 值机制提供了一种统一的方式来指定它们，而无需了解 Kubernetes YAML 文件的详细信息。

3. 有 a repository of pre-packaged application charts，所以如果你想要复制 PostgreSQL 和集群内持久存储，它已经为你构建好了，你可以依赖它，而不是自己找出 StatefulSets 和 PersistentVolumeClaims 的正确组合.

您可以通过有趣（并且可能很复杂）的方式将这些组合起来：例如，将集群内数据库用于开发人员测试，但将云托管和备份数据库用于生产，并根据以下内容计算数据库主机名提供了哪些设置组合。

当然，还有其他方法可以做所有这些事情。 Kustomize 特别是可以相当直接地更改图像值，并且值得注意的是自 Kubernetes 1.14 以来已包含在 kubectl 工具中（另请参阅 Kubernetes 文档中的 Declarative Management of Kubernetes Objects Using Kustomize）。 “操作员”模式提供了在集群中安装 software 的替代路径，但比 Helm 更重要的是，您信任具有 API 访问权限的任意程序。