Dat*_*atz 38 kubernetes kubernetes-helm kustomize
我已经使用 Kubernetes 和 Helm 一段时间了,现在第一次遇到 Kustomize。
但是 Kustomize 和 Helm 到底有什么区别呢?
两者是否只是用于捆绑 K8s 元素(例如服务、部署等)的不同解决方案?或者同时使用 Helm 和 Kustomize 是否有意义?
TJ *_*man 38
描述差异的最佳方式是将它们称为不同类型的部署引擎。一个是模板引擎,一个是覆盖引擎。
那么这些是什么?好吧,当您使用模板引擎时,您可以创建文件的样板示例。从那里你用已知的过滤器抽象出内容,在这些抽象中你提供对变量的引用。这些变量通常被抽象到另一个文件中,您可以在其中插入特定于环境的信息。然后,在运行时,当您执行模板引擎时,模板会加载到内存中,并且所有变量都与其占位符进行交换。
这在一些细微的方面与覆盖引擎不同。通常是关于信息如何进入配置示例。注意到我在那里使用了examples一词而不是templates。这是有意为之,因为 Kustomize 不使用模板。相反,您创建一个Kustomization.yml文件。这个文件然后指向两个不同的东西。你的基地 和你的叠加层。在运行时,您的 Base 被加载到内存中,如果存在匹配的 Overlays,它们将合并到您的 Base 配置之上。
后一种方法允许您更轻松地将配置扩展到大量变体。想象一下,为 10,000 种不同的配置维护 10,000 组不同的变量文件。现在想象一下维护可以以任何组合或排列方式继承的模块化和小型配置的层次结构吗?它将大大减少冗余并大大提高可管理性。
另一个需要注意的细微差别是项目的所有权。Helm 由第三方运营。Kustomize 由 Kubernetes 团队直接开发。事实上,Kubectl 直接支持 Kustomize 功能。您可以构建和像这样进行Kustomize项目:kubectl apply -k DIR。但是,嵌入在 kubectl 二进制文件中的 kustomize 版本已经过时并且缺少一些新功能。
Kustomize 中还有一些其他改进,这些改进稍微小一些,但仍然值得一提。它可以引用来自互联网或其他非标准路径的基础。它支持生成器根据文件和字符串文字自动为您构建配置文件。它支持强大且细粒度的 JSON 修补。它支持跨配置文件注入元数据。
在下面的评论中添加了以下链接以进行更多比较:
几乎所有的东西。就像问 Apache 和 Nginx 之间有什么区别一样 :) 他们做的工作有些相似,但量化差异有点不可能。
简而言之,Helm 是一个基于去中心化模型的模板驱动系统,用于图表共享。Kustomize 基于 YAML 数据的深度合并和其他结构化转换。
在某些情况下,两者都使用是合理的,例如将 helm 模板的输出提供给 kustomize 以进行叠加。
小智 8
两者都有其优点和缺点。让我们看一下这张表
Helm 对于打包、移植和安装定义良好的应用程序特别有用,而 Kustomize 最适合修改现有的 Kubernetes 应用程序。
事实上,Kustomize 和 Helm 提供了独特的具体优势,最好的做法是同时使用这两个工具。
| 归档时间: |
|
| 查看次数: |
11915 次 |
| 最近记录: |