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

不用内置 tiller 版本出来了吗

没用，等 3

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

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

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

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

另外 jsonnet 也可以考虑下。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

半年用一次，部署完拉到