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

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

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

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

楼下推荐个好用的

哈哈哈~

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

是的，helm chart 就是太松散了，用一个别人写的 chart ，如果文档和模板质量很高则谢天谢地直接用，如果文档看明白，就要 pull 下来解压看代码琢磨，更坏的情况下发现有些 chart 的模板不满足，要自己改/加东西。然而这么难用的东西就是业界标准。

我觉得问题根源不在 helm ，而是整个 k8s 世界过于复杂但完全基于 yaml 文件

只要你自己从 0 开始写过一份 Helm Chart ，很多你吐槽的点实际上都是不存在的。如果你只把 Helm Chart 当作一个傻瓜工具来用，那么工具的易用程度极其依赖于作者的文档水平。

> values 里没给你的，你不能要

错误的。只要末端 manifest （ deployment 、service 、configmap 、tpl ）预留了位置，你可以直接插入。



> values 里给你的，你自己找
> values 里把配置放哪个层级，叫什么名称，看心情。
> values 进行了什么骚操作，看源码。

你在试图通过 values 去正向推理最终的 deployment.yaml 的渲染结果，这当然是错误的。values 的目的是为了抽象末端 manifest 中的配置项，你可以集中在一个地方看到你的改动，而不需要深入文件去一个个翻，因此 values 的运行逻辑必须从末端 manifest 开始反向推理，末端文件决定了 values 里面存在什么配置、每个配置放在什么地方。



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

应用配置、编排规则、资源限制、权限 Policy 通常可能分属到不同的末端文件，而且除此之外还有储存配置、网络配置等，如果 values 能成功把散落在不同的 yaml 里的配置抽象到一份配置文件里，那说明 values 成功了。

比如我有一个服务，我需要配置 storageClass.yaml 、配置 priorityClass.yaml 、配置 service.yaml 、配置 ingress.yaml 、根据用户选择判断调用 deployment.yaml 还是 statefulset.yaml 、拥有不同类型的 secret.yaml 、拥有多份 configmap.yaml 、需要多个 PVC.yaml 、或许还拥有自己的 crds.yaml ，如果没有 values 会发生什么？你改了一份文件里的值，你需要串联同步改多份文件，变动散落在各处，查历史改动淹没在 git commit 里，而 values 要做的就是把所有的修改集中到同一份配置文件里，集中配置、集中管理、集中读取，每一个终端文件都保持变量引用的 clean state ，不写死任何值，预留尽可能全面的参数引用，这样 manifest 是完全无需维护的，仅需要维护 values 和 readme 即可。



> 我真的不知道为什么 helm 处理一遍文件为什么会这么慢

这个确实从没遇到过，常见的多层 nested 的复杂 chart 比如 gitlab 、kube-prometheus-stack ，渲染均是即时的。



> 没赞助的项目愿意给你写两笔文档不错了，配置项更了个字段？自己找吧。

本质上是项目作者的问题，与工具无关。而且 Helm Chart 并非黑盒，可以通过自己读 Chart 的方式，知道每一个 values 的值类型以及可用选项，或者手动改写末端 manifest 来允许自己在 values 中带入自定义字段，非常自由。

@mantou99 Helm 开发团队对自己的定义是 k8s 的包管理器，目的是简单配置和稳定部署。helm chart 不是写的不好，而是根本没有人能写好，因为在它的模式下，上游要么让 values 变得大而全，要么只实现部分自定义，这两种情况都脱离了 helm 对自己的功能定位。

我觉得你对工具的理解有问题，如果下游用户要自己动手解决所有问题，那工具就没有意义了不是吗。


@CivAx
1. 不是所有 chart 都预留了插入配置的位置，并且官方也没有定义标准的预留方式，导致每个团队预留的方式都不同，最终还是要看文档或源码。这是 hack ，不是 solution 。设计得过于自由开放导致每个人用法不一样，实际更难用的软件比比皆是。

2. 你所表述只是 Helm 的一部分，即通过 Template + values 的方式，实现一个管理 k8s manifest 文件的抽象工具，这部分功能没有问题。

但 Helm 还有一个角色，是作为 k8s 体系的打包工具和包管理器。涉及到的问题是打包，配置，安装，卸载。而配置不方便并不是某个项目的个例，以至于很多复杂的项目开始用 Operator 来管理。

你是怎么用 Helm 的？是每个 repo 都 fork 了再配置再部署吗？

@byzf

1. Hack 或 Solution ，取决于一个语言有没有足够的规范来约束用法、语法更新频率是否够高，强约束性和能够及时更新特性的高级语言，是很少、或仅能短暂存在 Hack 的，比如 Jenkins 用的 Groovy 。Yaml 作为一种 markup language ，本质上是一份描述文件，Helm 在描述文件的基础上提供了逻辑判断、运算符的中间层逻辑，而最终文件仍然是 markup language 逻辑的声明式描述文件，这种软件对于编码语言的弱约束带来的极高自由度是一定会存在 Hack 的，而且并不能称为 Hack ，因为解析编码语言的处理器本身并没有缺失对应的处理逻辑，而是直接告诉你万物皆允。

通常在 Nested Chart 里，子 Chart 里的配置在母 Values 里缺失的情况非常常见，这种可以在母 Values 里用 key override 的方式直接覆盖。如果子 Chart 没有，或者 Chart 作者提供的判断逻辑对你而言不适用，你可以直接改造子 Chart ，并在 Values 中新增对应的键值。

2. Helm 作为一个包管理器角色事实上是有些过誉了，Helm 做不到传统意义上的包管理器比如 yum 的逻辑复杂度，这类包管理器通常会存在大量的自检、判断、依赖检查、善后检查。Helm 更近似 npm 这种依赖作者的 manifest 进行包安装、包卸载的简单管理器。Helm 的出发点和主要服务目的，是简化零散 K8s 资源的管理、安装、卸载，并在这之上被社区发展出了版本管理、回滚（实则是操作 RS ）等添头。使用 Operator 管理是正确的，而且与 Helm 并不冲突，Helm 在原始文件的管理阶段，比如你 operator 的 deployment 仍然可以通过 Helm 来部署，而 Operator 的核心目的实际上是试图解决 StatefulSet 在扩容上的棘手问题，出于该核心目的衍生出了部署逻辑，Operator 才因而存在可以 gracefully 部署、清除应用以及跟该应用相关联的 K8S res 的能力，这与 Helm 是两个不同的出发点，两者在某些角度上来看存在功能的重叠，但实则是不同的处理逻辑。

我们这边使用 Helm 的方式，是公司有专门的 infra team 管理 Chart ，Chart 的来源可能是自编或 bitnami 等他人写好的，每一个 Chart 都会 Clone 到本地，固化 Values 数值变动（或准备多份 Values ），然后提供 git repo 给 cluster operator 部署。如果 remote 有更新，就 diff 对比变动，然后择选合并到本地，并且创建新的版本分支且 M 到 Main ；如果内部有需求，则根据内部需求修改 Values 或者改造 Chart 本身。

我觉得 helm 很好用，但是不好编写，每次调试 Chart 太麻烦了。

Helm 适合高级用户，对 k8s 和 helm 都很懂的。如果都是一知半解，极容易出现应用被覆盖的问题

看了几个替代的方案：

1. kustomize

第一个考虑的选项，因为不需要引入外部依赖。抽象方式是先声明一个 resource ，然后以这个 resource 为 base ，声明对它的修改 overlay ，每个 overlay 又可以作为 base 。

用法很灵活，但语法不太聪明的样子，另外项目搞复杂的话，嵌套体系 debug 起来很麻烦。

2. cdk8s

用代码生成 resource ，彻底抛弃 yaml 扁平易读的特点，因而获得了代码补全，相当于写 helm chart 的时候方便了很多。

不太能接受这种设计，yaml 是实践出的最佳标准，语法对运维来说太合理了，抛弃 yaml 舍本取末，大概率走不远。

3. carvel.ytt

感觉不错的项目，语法简单干净，本身是合法的 yaml ，配套设施完整，教程也直观。

没有 windows 版，似乎用的人不多。这种自创语法的模板，如果没有广泛的社区支持，很容易被时代遗忘。整体来说，ytt 是所有项目里给我感觉最合理、贴近运维需求的。

4. tanka + jsonnet

感觉不错，美中不足用了 json 而不是 yaml 。发展的很一般，同样没有 windows 版，用的人不多。google 似乎对 jsonnet 没有什么动力了， 试图借 jsonnet 生态完善功能的美梦最后起了反作用。

优点是语法很直观，靠推测就能用，几乎不用文档。

5. operator

官方应该是推荐简单部署用 kustomize ， 复杂部署直接用 operator 。但就我个人的体验来说，operator 如果配置错误，是有能力把整个 cluster 搞崩的，更不用说 operator 本身可能有漏洞。

运维发展了这么多年，这么多项目和代价，终于有了一个不用担心把其他服务带崩的环境。我在 docker 时代就已经解决了的问题，为什么到 k8s 里要引入更复杂的抽象来创造问题呢？但目前的打包方案都有些瑕疵，所以比较成熟的项目都是跟着官方用 operator ，也没办法。