大家在生产环境中用 Helm 么？大致用到什么程度？

[resouer]

最近 Helm 官方跟我们团队沟通，希望从技术和社区多个渠道上合作在国内普及与推广 Helm。

对这个我们非常欢迎，国内 K8s 应用管理这块，跟社区差距还是有点大的。但是：

不知道大家在生产环境中用 Helm 么？大致用到什么程度？

先说我的看法：

1. Helm 在国外的普及程度是非常高的，说是 CNCF 里除了 K8s，Prometheus 之外的 NO.3 应该没异议。
2. Helm 本身在应用定义方面做得不错，但是它试图连整个应用的管理周期都管下来的做法是有问题的。我们和 Google 正在跟 Helm 聊 Helm 拆分，但还非常早期。
3. 结合 2，Helm 对 Release 和“发布”的管理功能，堪称鸡肋。
4. Templating 和 DSL 是定制应用参数比较差的做法，我们在用 Overlay （ Kustomize ） 做这件事情。

Feel free to feedback!

[ps1aniuge]

Helm 在我眼中，是解决集群应用，有状态应用的。 的幺蛾子。

我看好 operater。但 operater 太少。
这相当于给 k8s 注入功能。或许谷歌会偷偷封杀，设置障碍。
同时由于 k8s 更新频繁，operater 面临兼容新版本问题。

并不能怪他俩。甚至第三个冒出来的小弟。
毕竟有状态应用，集群应用本身就是，k8s 的癌症。

彻底改写应用架构，逻辑，以适应 k8s 集群。这个最难，当然效果也最好。

[YzSama]

@resouer #9 等 V3，感觉新版本有看头。目前采用的是 env 注入模板。还能用着先。但是，管理起来太麻烦了。 观望下半年和服务

[unco020511]

我以为你说的是 mac 下的 host 切换软件...

[xbigfat]

@unco020511 我也是这么以为的。。。

[xfriday]

目前只用 kubectl，生成 configmap 会用到 kustomize 的 configMapGenerator

[hyuwang]

开始用了一段时间 template + apply
之后干脆直接 tiller+tls 分集群了

还是要等 v3 搭配 helm-secrets 这种插件非常好用

[resouer]

@twl007 生成出来的 patch 多还好吧，我们通过 Git 组织起来， 不过看起来缺失一个面向 Git 的应用管理工具来操作这些 patch。另外我其实觉得生成 Patch 的过程比较难弄，感觉少一个像 Dockerfile 这种的文件。。。

[resouer]

@sampeng v3 没有 tiller 了，但我们觉得 Helm templating 实际上问题也不小

[resouer]

@Ley 对的，我们目前对 Helm 的用法，就是只把它当包管理使用，后面的流程都是 kubectl

[resouer]

@monsterxx03 感谢分享，你们的这个 workflow 感觉很典型

[resouer]

@ps1aniuge 这里理解有点偏差，Helm 重点解决的是应用定义和打包的静态问题，Operator 解的是有状态应用怎么部署运行升级的动态问题。当然，现在 Helm 有点想往后吃动态的部分，做的很差。关于 Operator 的沿革和未来，以及它和有状态应用的关系，不知道有没有读过我们之前的这篇文章： https://www.lijiaocn.com/%E9%A1%B9%E7%9B%AE/2019/01/08/kubernetes-api-and-operator-history.html

[resouer]

@recall704 可以试一下 https://v3.helm.sh/docs/using_helm/#installing-helm

[sampeng]

@resouer 没有银弹的。完美的东西本身是不存在的。但有几十个微服务。再加 n 套环境。反正我觉得现在 helm 是最舒服的。用其他的我基本得累死…

之前 tiler 也不是不能用吧…

[leeeee9]

helm 现在是 3 tiler 还有这个概念吗？还是说 helm 直接解析去调用 apiserver ？

[resouer]

@leeeee9 没有了，helm 3 把状态保存在 server 端，然后在 cli 里处理