我使用Kubernetes和Helm已有一段时间了，现在第一次遇到Kustomize。
但是Kustomize和Helm之间到底有什么区别？
bundle K8元素(例如服务，部署等)的解决方案是否完全不同？还是同时使用Helm和Kustomize是否有意义？
最佳答案
描述差异的最佳方法是将它们称为不同类型的部署引擎。一个是模板引擎，另一个是覆盖引擎。
那这些是什么？好吧，当您使用模板引擎时，您将创建文件的样板示例。在这里，您可以使用已知的过滤器提取内容，并在这些抽象中提供对变量的引用。这些变量通常被抽象到另一个文件中，您可以在其中插入特定于环境的信息。然后，在运行时，当您执行模板引擎时，会将模板加载到内存中，并且所有变量都将与它们的占位符交换。
这与覆盖引擎有一些细微的差别。通常关于信息如何进入配置示例。注意我是如何在其中使用示例而不是模板的。这是故意的，因为Kustomize不使用模板。而是，您创建一个Kustomization.yml文件。然后，该文件指向两个不同的事物。您的基础和叠加层。在运行时，您的Base会加载到内存中，如果存在任何匹配的Overlay，则会将它们合并到Base配置之上。
后一种方法使您可以更轻松地将配置扩展到大量变体。想象一下，为10,000个不同的配置维护10,000个不同的变量文件集。现在想象维护一个模块化和小型配置的层次结构，该结构可以以任何组合或排列来继承吗？这将大大减少冗余并大大提高可管理性。
需要注意的另一个细微差别是项目的所有权。 Helm 由第三方操作。 Kustomize由Kubernetes团队直接开发。实际上，Kubectl直接支持Kustomize功能。您可以像这样构建并执行Kustomize项目:kubectl apply -k DIR。但是，kubectl二进制文件中嵌入的kustomize版本已过时，并且缺少一些新功能。
Kustomize中还有其他一些改进，虽然有些微小，但仍然值得一提。它可以引用来自Internet或其他非标准路径的基准。它支持生成器根据文件和字符串文字自动为您构建配置文件。它支持健壮且细粒度的JSON修补。它支持跨配置文件注入(inject)元数据。
以下评论中添加了以下链接，以进行更多比较:
关于kubernetes - Helm和Kustomize有什么区别？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/60519939/