我领悟了，这个世界没有 Helm 会更好

[byzf]

在我刚刚开始用 k8s 的时候，Helm 已经成为了事实标准，基本上用它来管理第三方应用没什么问题，部署完了一年半载才会更新一次，所以好不好用也无所谓了。

最近高强度配置了一些服务，被 Helm 的几个痛点折磨得头昏眼花。说句难听点的，自己用 php 写的模板好用多了。

1. 模板逻辑抽象程度低。

values 里没给你的，你不能要。
values 里给你的，你自己找。
values 里把配置放哪个层级，叫什么名称，看心情。
values 进行了什么骚操作，看源码。
一次配置，两份文档。一份薪水，三倍时间。

2. values 混杂臃肿。

一坨服务，扔一个 values 里配置，应用配置归你管，编排规则归你管，资源限制归你管，权限 Policy 归你管，一个服务一千多行配置，跳转全靠代码搜索，重用靠 yaml ahcor ，这还能管吗？管不了。你不如让我去死。

3. 反应慢。

我真的不知道为什么 helm 处理一遍文件为什么会这么慢。是我的 7600X 速度让您不满意了还是 3gb/s 的硬盘读取落后于时代了，还是 kubectl 20ms 的延迟太长了？说句难听点的 php 里这么慢的引擎早被淘汰了。

4. 版本兼容性一塌糊涂。

你说成熟项目都有官方 chart ，有赞助的项目就算没有 Helm ，你给它个记事本它也能给你整一套完善的部署方案，没赞助的项目愿意给你写两笔文档不错了，配置项更了个字段？自己找吧。

以后反正是不会用 Helm 了，用什么取代暂时还没想好。

[aapeli]

helm 就是个模板引擎，相对来说我更喜欢 kustomize

[whileFalse]

你可以不用 你凭什么让别人不用

[seers]

helm 违背了 kiss ，让事情变成一团糟，每次运行 helm 心里都没底，一次都没

[token10086]

楼下推荐个好用的

[justdoit123]

哈哈哈~

[lasuar]

第一点没看懂啊，values 没定义你不能自己加吗，官方给的 chart 不符合你的需求就自己修改模板不就完了？

复杂项目搭建生产，比如 MySQL 和 ES 你确实可以不用 helm 的，用就得读一遍文档和模板，这没法避免的。但实际你的工作并没有简化太多，因为你要自己去编写 statefulset.yaml ，这不一定有官方 chart 完善。

[asuraa]

helm 有啥问题 多好用啊，模板你自己写不就行了 想咋写咋写

[coolcoffee]

学习 helm 的编写和 debug 也是痛苦的过程，如果 helm 能够提供一个编辑器扩展会好很多。

[eryajf]

也许，最好用的，还是 yaml🙈

[winson030]

业务复杂了，yaml 文件数量上去了的话，用 helm chart 可以稍微减少一些负担。最起码自己写的 helm chart 自己知道

[byzf]

@lasuar Helm 之后，一个配置条目可以源自 helm values ，可以源自 helm template ，甚至可能是经过逻辑、运算、拼接生成的，也可以源自 template 里生成的一个 ConfigMap ，而这个 ConfigMap 可能又引用了 values 的值。

Helm 把原本基于 yaml 的 source of truth ，变成了各个项目综合计算后的结果，debug 难度上升一层。再加上 template 毫无体验的语法，可以说是吃饱了给自己找点活干干。

[byzf]

@lasuar 对于包管理器肯定是希望它类似于 apt ，yum ，pip ，安装了都是直接看软件文档而不需要再看一遍打包过程。这又回到古代了，安装软件之前先读一遍 makefile 。

[byzf]

归纳一下观点，就是 Helm 依赖上游 repo 提供 Tmplate ， 而下游用户提供 values ，两者之间的逻辑非常固定。

但实际情况下，上游不能完全考虑到用户需要什么，往往是用户的想法一旦和开发者有一点出入，就要回过头去查阅和 Debug 模板，有时候还要自己写模板，导致 Helm 变成了多余的步骤。

[pain2w]

软件的特性就是这样，每引入一层抽象层就伴随着复杂度带来的风险，有的人会接受风险，有的人则不会。

[lasuar]

@byzf 做这个抽象(template, values)是为了实现它的灵活性。这就是 helm 的用处啊。简单的应用它的部署模板自然就简单，那相对应的必然也有复杂的。
根据你的描述，我认为你还是没有理解 helm 的真正作用。
另外，在部署之前，你可以用他的一个验证命令打印出实际的 yaml 内容，确认无误之后再部署。
你也不能说是 helm 依赖上游的 chart ，因为 chart 这个东西应用的官方自愿提供的，如果一个东西没有作用，他没必要花精力来维护。helm 自身只是一个将 yaml 和配置分离的工具，这种工具在需要经常迭代应用的时候是非常有用的。
最后，我想说的是，阅读官方提供的 chart 模板是可以帮助部署人员进一步理解这个应用应该如何部署的，特别是对于那些不擅长部署应用的开发者人员。

[Frankcox]

引入新的 chart 包肯定麻烦，Helm Chart 的一个好处是在公司内部项目初始化完成之后，后续迭代升级回滚过程减少运维负担。

[cz5424]

Helm 我用来部署复杂的第三方依赖，每次执行心里没底+1

[mantou99]

1. 看不懂，感觉就像是没做好版本管理，难道是用别人的 chart 还嫌弃写的不好？
2. 很多开源的 chart 本来就是从满足大多数人的需求出发，k8s 本身就很复杂，你不用 policy 指望别人也不用吗？你用对象存储，他用文件存储，世事两难全啊
3. 处理慢确实有点，不过部署应用我不太在乎这几十秒，我觉得锅也得 k8s 交互 go 模板先背
4. 这难道不是 k8s 的问题吗，api 变了 chart 才不兼容

k8s 中部署应用选项足够少，我觉得他也能像 apt yum 一样直接 helm install,但是这样的东西能满足需求吗？不同发行版直接 apt yum 的东西只用官方源都不一样，pip conda 做的已经足够好了，python 不同版本下装不同版本软件还是会有问题。这和不同的 chart 版本，也没什么区别吧

[xzysaber]

能减少一些负担，但是也会增加一些负担。看自己能忍受哪些，不能忍受哪些了。
个人目前还没遇到很满意的工具。

[ganbuliao]

自己制作 helm chart 就行了呗
模板语言 要理解模板的含义