大家在生产环境中用 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!

[dangyuluo]

半年用一次，部署完拉到

[resouer]

@dangyuluo 可以，我们就喜欢这个用法，helm 其它功能太鸡肋了

[binux]

我们的 k8s 集群是我部署和定义的。我禁止在生产环境中使用 helm。
1. 我们主要用 k8s 部署我们自己的应用，既然要自己写 yaml，没有必要使用 helm。
2. Tiller 完全就是一个后门，它绕过 k8s 自己的权限认证。
3. chart 虽然方便，但是很难保证过一两年你安装的配置和原来的兼容。

既然这样，还不如直接管理 yaml，要用 Helm 也是渲染出 yaml 去 apply。

[resouer]

@binux Tiller 这个东西确实变态。

> 要用 Helm 也是渲染出 yaml 去 apply

我们现在是将 Helm Charts Kustomize 化，这样 Base Charts 更新了，你的应用 YAML 就可以做 Rebase。感觉更符合你的使用场景？

[binux]

@resouer #4 对于我们来说第三方应用非常非常少，自己的应用需要的不过是 staging/prod 的一些变量的替换罢了。用 template 可以一套变量用在多个地方（比如 SQS name 可以同时用在 k8s yaml 和 Cloudformation 上）。

[resouer]

@binux 那应用描述与应用依赖关系怎么定义？ DIY 方案？

[binux]

@resouer #6 是啊，terraform 对 k8s 支持不成熟，没办法啊。

[YzSama]

我觉得这东西很好用啊，对于很多开发人员，他们根本不关心服务部署在哪，配置要怎么写。 用 helm 就可以随时调整配置文件，定义几套模板就好了。不必下发到各项目中，集中管理部署模版

[resouer]

@YzSama 那么应用安装好之后的发布回滚流程，倾向于让 Helm 管么？

[tontinme]

用的 kustomize 管理 base，ansible template 生成 patch。

[silenceshell]

@binux tiller 可以部署在自己的 namespace 里，只是浪费一些资源
helm3 有改善

[monsterxx03]

第三方应用的 chart(jenkins,sonarqube...) 我的做法是直接 cp 到自己的 repo 里, 在里面加一个文件夹 helm_vars 用来 override values.yaml 里面的值, 更新时候直接再从上游拷过来覆盖一次,看 git diff, 没问题再 helm upgrade xx . -f helm_vars/prod.yaml( 这句写死在 Makefile 里). 这种应用更新频率很低直接让 helm 管理了.

自己的应用也用 helm 初始化, 后续更新一般都是代码的更新, 只更新 image tag, 不走 helm, 在 jenkins pipeline 用 kubeclt set image + kubectl rollout status 更新. image 都是时间戳, 每次发布新的 image 同时把 latest tag 指向最新的 tag. helm chart 里 image 永远写 latest.

自己的应用只有在改应用运行环境的时候才需要执行 helm upgrade (很少很少), 风险是此时 tag 变成了 latest, 如果之前线上做了 rollback 就会处问题(但只有我有这权限,所以问题不大)

helm 的依赖管理对我真的没啥用处,有的 chart 里有 requirements 的,我都想办法禁掉, 单独部署它的依赖

[anubu]

主要在 CI/CD 环节使用，helm template + kubectl，no tiller。真的只是替换一些环境参数，不管是 template 还是 overlay，不要搞太复杂。可能是程序规模较小，依赖完全可控，人工管理。回滚方面倾向于代码层面回滚，重新发布新的 release，发布流程不变。考虑重新编译时间较长，也可以制品回滚。

[twl007]

@resouer 但是对于上百个重复生成的问题怎么解决呢？ Kustomize 要是有上百个 overlay 也不好管理吧。我们现在对于一些不是要生成上百个，每个之间也仅仅是参数不同。

另外 jsonnet 也可以考虑下。

[sampeng]

我一直纠结的是不是线上要用 helm 的 tiller …因为有近 40 个微服务。全是 template 会有点方。但 tiller 真的就像上面说的，这万一跟后门一样…纠结啊

[jessynt]

用，但是会在需要 Helm 的各个 namespace 部署 tiller

[jade88]

不用，自己封装了一个类似的

[recall704]

没用，等 3

[artandlol]

不用内置 tiller 版本出来了吗

[Ley]

Helm 和 kubectl 似乎有不兼容之处。通过 Helm ungrade 更新的资源如果用 kubectl apply 之后就无法再次被 Helm 更新。诸如此类的问题遇到几个，给人感觉 Helm 成熟度还不够