Kustomize和Helm的有哪些差异？

Kustomize 相对于Helm而言，更加的轻量，只有一个CLI 工具。也集成到了kubectl自身，使用及配置成本接近于0。Kustomize 放弃了对模板的要求，改为参考Docker镜像的形式，通过Base+Overlay 的方式对应用的原始YAML 进行派生。

• Base YAML 管控：Helm最大的特点是定制仅限于预先存在的配置选项。不仅如此，Chart 作者还必须用有点麻烦的模板化方式实现这些定制选项。这个时候Kustomize 不受限制的Overlay 会更加灵活，想怎么覆盖就怎么覆盖。所以Helm对Base YAML 强管控；而Kustomize 虽然也有Base，但Overlay 的存在让这个限制几乎不存在。

• 模板语法层面：Kustomize 相较于Helm去掉了模板语法，入门门槛更低，更易使用。当然如果玩的高阶，两者都要学习很多东西。

• 部署层面：虽然Kustomize 最为轻量，但因为Helm3 取消了Tiller 依赖，所以差别也不是很大，两者都是二进制命令工具生成YAML 后直接下发。

• 工作流程上：

 Helm：定义Chart->填充->运行。在Chart 中没有定义的内容是无法更改的。

 Kustomize：Base 和Overlay 都是可以独立运作的，增加新对象，或者对编写Base 时未预料到的内容进行变更，都非常简单。

基于上述工作流程的对比，如果是要公开发布一个复杂的组件，编写一个复杂而设计良好的Helm Chart 可以给用户很大帮助。用户在缺失了自由性之下，仅仅通过values.yaml 的阅读和配置就可以对这种复杂的部署产生一个较为深入的认知。

如果是常见的业务应用，虽然不同的部署之间差异不大（比如日常预发生产），但是因为快速迭代及需求变化，未必可以一开始就做好相关的变化限制，用Kustomize是更好的选择。

对于承载应用（Application）这个概念而言，Kustomize 和Helm 的短板是一致的，都没有进一步提供包之间的依赖处理、外部资源申请及维护、变量间传递等能力。

对于承载组件（Component）这个概念而言，Kustomize 和Helm类似，都是合适的工具。虽然Helm和Kustomize 在自身的能力和流程上有着很多区别，但最终流程都是：开发者（一堆YAML）->合适的参数映射及渲染方式->使用者（填参/覆盖）->apply 到目标K8S 中。萝卜青菜，各有所爱。"

以上内容摘自《SREWorks 云原生数智运维工程实践》电子书，点击https://developer.aliyun.com/ebook/download/7784可下载完整版。