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

半年用一次，部署完拉到

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

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

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

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

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

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

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

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

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

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

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

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

第三方应用的 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 的,我都想办法禁掉, 单独部署它的依赖

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

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

另外 jsonnet 也可以考虑下。

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

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

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

没用，等 3

不用内置 tiller 版本出来了吗

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

之前 tiler 也不是不能用吧…

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

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