我用Kubernetes和Helm已经有一段时间了，现在第一次接触到Kustomize。
但是Kustomize和Helm之间的区别是什么？
两者都是将K8s元素（如服务、部署等）打包的不同解决方案吗？或者同时使用Helm和Kustomize有意义吗？
3个回答
75
描述这些差异的最佳方式是将它们称为不同类型的部署引擎。Helm 是一个模板引擎，而 Kustomize 是一个覆盖引擎。
那么这些是什么呢？当你使用模板引擎时，你创建一个文件的样板示例。然后，你使用已知的过滤器来抽象出内容，并在这些抽象中提供对变量的引用。这些变量通常被抽象到另一个文件中，在该文件中插入特定于您的环境的信息。然后，在运行时，当执行模板引擎时，模板被加载到内存中，并且所有变量都被替换为其占位符。
这与覆盖引擎有一些微妙的区别。通常涉及配置示例中的信息获取方式。注意我在那里使用了“示例”这个词，而不是“模板”。这是有意为之的，因为 Kustomize 不使用模板。相反，你需要创建一个名为“Kustomization.yml”的文件。该文件指向两个不同的东西：你的“Base”和你的“Overlays”。在运行时，你的 Base 被加载到内存中，如果存在任何匹配的 Overlays，则会合并到 Base 配置之上。
后一种方法使您能够更轻松地将配置扩展到大量的变体。想象一下，为10,000个不同的配置维护10,000个不同的变量文件集。现在想象一下，维护一个可以以任何组合或排列方式继承的模块化和小型配置层次结构？这将大大减少冗余并极大提高可管理性。
另一个需要注意的细微差别是项目的所有权。Helm由第三方运营。Kustomize直接由Kubernetes团队开发。尽管两者都是CNCF项目。实际上，Kustomize功能在Kubectl中得到了直接支持。您可以像这样构建和执行Kustomize项目：
Kustomize还有一些其他改进，虽然相对较小，但仍值得一提。它可以引用来自互联网或其他非标准路径的基础。它支持生成器，根据文件和字符串字面值自动构建配置文件。它支持强大且精细的JSON修补。它支持在配置文件之间注入元数据。
以下链接已在下面的评论中添加，以进行更多比较。
那么这些是什么呢？当你使用模板引擎时，你创建一个文件的样板示例。然后，你使用已知的过滤器来抽象出内容，并在这些抽象中提供对变量的引用。这些变量通常被抽象到另一个文件中，在该文件中插入特定于您的环境的信息。然后，在运行时，当执行模板引擎时，模板被加载到内存中，并且所有变量都被替换为其占位符。
这与覆盖引擎有一些微妙的区别。通常涉及配置示例中的信息获取方式。注意我在那里使用了“示例”这个词，而不是“模板”。这是有意为之的，因为 Kustomize 不使用模板。相反，你需要创建一个名为“Kustomization.yml”的文件。该文件指向两个不同的东西：你的“Base”和你的“Overlays”。在运行时，你的 Base 被加载到内存中，如果存在任何匹配的 Overlays，则会合并到 Base 配置之上。
后一种方法使您能够更轻松地将配置扩展到大量的变体。想象一下，为10,000个不同的配置维护10,000个不同的变量文件集。现在想象一下，维护一个可以以任何组合或排列方式继承的模块化和小型配置层次结构？这将大大减少冗余并极大提高可管理性。
另一个需要注意的细微差别是项目的所有权。Helm由第三方运营。Kustomize直接由Kubernetes团队开发。尽管两者都是CNCF项目。实际上，Kustomize功能在Kubectl中得到了直接支持。您可以像这样构建和执行Kustomize项目：
kubectl apply -k DIR。然而，嵌入在kubectl二进制文件中的kustomize版本已经过时，并且缺少一些新功能。Kustomize还有一些其他改进，虽然相对较小，但仍值得一提。它可以引用来自互联网或其他非标准路径的基础。它支持生成器，根据文件和字符串字面值自动构建配置文件。它支持强大且精细的JSON修补。它支持在配置文件之间注入元数据。
以下链接已在下面的评论中添加，以进行更多比较。
- TJ Zimmerman
14
7我猜想你已经有一段时间没有使用 Helm 了，因为 Tiller 不再存在。现在它们都使用类似的通信模型，或者说在对象本身或秘密中存储应用程序跟踪数据。此外，尽管我个人更喜欢 Kustomize，但你的陈述严重高估了它的社区支持。Helm 有更多的用户、集成和支持。技术上说，Kustomize 现在与 kubectl 配套了，但是版本太旧，在大多数情况下与当前的 Kustomize 完全不兼容。 - coderanger
2Helm在安全方面历史不佳，而Kustomize则得到了Kubernetes开发者的官方支持。由于采用继承基础模型设计，Kustomize比Helm更具可扩展性。Kustomize支持插件框架，允许用户使用生成器动态构建清单。YAML并不适合作为模板，因此无法很好地进行模板化。与Helm相比，Ansible和Jinja2是更清晰的模板化解决方案，并能够生成结果性的Kubernetes清单。而且，在大多数现代基础设施堆栈中，它们已经被广泛使用。Kustomize > Ansible > Helm - TJ Zimmerman
2Kubectl（或者说kube本身）固定了Kustomize 2.0.3版本。再次强调，我喜欢使用Kustomize而非Helm，但是您仍然过分夸大了社区在这一点上的共识水平。您并没有错，但仍然有些错误：D - coderanger
1@TJZimmerman，Helm 的安全问题是针对 Helm 2 发布版本的。由于在 Helm 3 中移除了 Tiller，因此我认为您所描述的问题是版本 2 的问题。 - George Tseres
1是的，这已经被多次提到了，我已经相应地更新了我的原始答案。我的说法不是Tiller的存在在Helm 3中仍然是一个安全问题。我的说法是，在项目的大部分生命周期中，Helm使用了Tiller。而开发人员并没有急于删除该功能。Helm因不安全而闻名，并且这种情况不会很快改变。无论Helm 3中发生了什么变化。此外，官方支持Kustomize的事实支持了这样的说法：Helm在未来的市场份额将比Kustomize少。 - TJ Zimmerman
显示剩余9条评论
14
几乎一切。就像问Apache和Nginx之间有什么区别一样 :) 它们执行的工作基本相似，但量化差异有点不可能。
简而言之，Helm是一个基于模板驱动的系统，基于分散的模型用于图表共享。Kustomize基于YAML数据的深度合并和其他结构转换。
在某些情况下，同时使用两者是合理的，例如将helm模板的输出馈入kustomize以进行覆盖。
- coderanger
1
1在技术差异和项目差异方面，比起模板与合并，还有更多微妙之处，这些问题应该得到解决。因此，我已经添加了一条额外的评论，进一步阐述了这两个项目之间微妙的差异。 - TJ Zimmerman
8
两者各有优缺点。让我们看看表格：
Helm特别适用于打包、移植和安装已明确定义的应用程序，而Kustomize最适合修改现有的Kubernetes应用程序。
事实上，Kustomize和Helm提供独特的特定优势，最好的做法是将这两个工具并置使用。
- Nikhil Kumar Agrawal
1
Kustomize 现在可以使用 Helm Charts 进行打包。https://github.com/kubernetes-sigs/kustomize/blob/master/examples/chart.md - Almenon
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接
- 相关问题
- 3 ArgoCD 集成 Sealed Secrets 和 Kustomize
- 8 kustomize edit set image 不能与 kustomize multibases 和 common base 一起使用。
- 7 Kustomize和Kubectl无法找到CRD
- 22 “template”和“include”在Helm中有什么区别？
- 5 在使用Helm之后是否建议使用Kustomize？
- 44 在Kustomize中，patches和patchesJson6902有什么区别？
- 17 起草和Helm与Ksonnet相比有什么区别？
- 34 在 Helm 中，fullnameOverride 和 nameOverride 有什么区别？
- 10 helm uninstall、helm delete和kubectl delete之间有什么区别？
- 30 helm语法中的 {{ something }} 和 {{- something }} 有什么区别？