我目前正在使用 kubernetes，并且遇到了 helm。
假设我不喜欢用与我的应用程序无关的进程“感染”我的 kubernetes 集群，但如果它有益的话，我很乐意接受。
所以我做了一些研究，但我仍然找不到任何使用我的 yaml 描述符和 kubectl 无法轻松完成的事情，所以现在我找不到任何用途，除了环境。
例如（从我读过的指南中获取：
- 您可以轻松安装应用程序，例如。 helm install nginx —> 我将 nginx 映像添加到我的部署描述符中，完成
- 存储库 -> 我有 docker 存储库（我从中提取图像）
- 如果发布失败，您可以轻松地进行回滚 -> 我只需将 kubernetes 描述符中的映像版本更改为前一个版本，简单
令我困扰的是，在命令级别，我做了几乎相同的工作（helm update->kubectl apply）。
作为交换，我有很多样板文件，因为要保留 helm 想要的目录结构，而且我感觉缺少对普通部署描述符的控制......我缺少什么？
你的问题是完全可以理解的。对于小型和简单的部署来说，好处实际上并没有那么大。但是当某些东西的部署非常复杂时，Helm 会提供很大帮助。
假设您有几个团队为某家公司开发微服务。如果您可以制作一个适用于大多数微服务的图表，那么每个微服务的部署将仅因映像和所需资源而有所不同。通过这种方式，您可以获得标准化的部署，并且对所有开发人员来说都更容易。
另一个用例是部署需要大量移动部件的应用程序。例如，如果您想在 Kubernetes 上部署 Grafana 服务器，您可能至少需要一个 Deployment 和一个 Configmap，然后您需要一个与此部署匹配的服务。如果您想将其公开到互联网上，您也需要一个入口。
一个相对简单的应用程序，需要 4 个不同的 YAML，您需要手动配置并确保一切正确，而不是您可以执行一个简单的操作helm install并重用某人已经做出的配置，有时甚至是创建应用程序的公司。
还有很多其他用例，但这两个是我认为最常见的用例。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
