kubernetes 自1.14 之后,Kubernetes 项目本身开始具备了原生的应用管理能力,这其中最重要的一个功能,就是 Kustomize。
Kustomize 允许用户从一个基础 YAML 文件,通过 Overlay 的方式生成最终部署应用所需的 YAML 文件,而不是像 Helm 那样通过字符串替换的方式来直接修改基础 YAML 文件(模板)。这样,在一个用户通过 Overlay 生成新的 YAML 文件的同时,其他用户可以完全不受影响的使用任何一个基础 YAML 或者某一层生成出来的 YAML 。这使得每一个用户,都可以通过 fork/modify/rebase 这样 Git 风格的流程来管理海量的 YAML 文件。这种 PATCH 的思想跟 Docker 镜像是非常类似的,它既规避了“字符串替换”对 YAML 文件的入侵,也不需要用户学习蹩脚的 DSL 语法(比如 Lua)。
在kubernetes 1.14 之后,Kustomize 已经成为了 kubectl 的一个内置命令。不难看到,Kubernetes 社区正在探索一种 Helm 之外的、更加 Kubernetes 原生的应用管理方法。具体效果如何,我们不妨拭目以待。
当然,你可以只需要1.14的kubectl就行,不需要1.14的kubernetes服务器版本支持。
非常适合多环境部署(例如,你需要发布到开发、测试、生产环境)
用法:
在包含YAML 资源 文件(部署,服务,配置映射等)的某个目录中,创建一个 kustomization文件。
此文件应声明这些资源以及要应用于它们的任何自定义,例如添加公共标签。
文件结构:
此目录中的资源可能是其他人配置的分支。如果是这样,您可以轻松地从源材料重新定义以捕获改进,因为您不直接修改资源。
生成定制的YAML:
$ kubectl kustomize ~/someApp
YAML可以直接应用于集群:
$ kubectl kustomize build | kubectl apply -f -
注意 Kustomize现在可以在kubectl v1.14上使用,可以通过指定包含以下内容的目录来使用kustomization.yaml:
$ kubectl apply -k ~/someApp
通过继承基础 配置来适应不同的发布环境- 如 开发,测试和生产。
文件结构:
base: 存放各个环境的公共配置,kustomization.yaml 如下:
然后在 overlays 中可以定义子环境,上面定义了两个子环境(devlopment、production):
overlays/development/kustomization.yaml如下:
可以看到 overlays 下继承了 base 的配置,并且添加了 cpu_count.yaml、replica_count.yaml 配置。同时,kustomize 不仅仅支持文件级别的 patch,还支持对一个文件某些字段的 patch 如下所示,replica_count.yaml 只包含了有关 replicas 的部分即可,在执行 kustomize build 之后就可以将这部分覆盖默认的配置。
生成YAML
$ kubectl kustomize ~/someApp/overlays/production
YAML可以直接应用于集群:
更多例子:
https://github.com/4220182/kustomize-example
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!