笔记。 翻译。：本文由 Scott Lowe 撰写，他是一位在 IT 领域拥有丰富经验的工程师，也是七本印刷书籍的作者/合著者（主要是关于 VMware vSphere）。 他现在就职于VMware子公司Heptio（2016年被收购），专门从事云计算和Kubernetes。 文本本身就是对 Kubernetes 使用技术进行配置管理的简洁易懂的介绍 ，最近成为 K8s 的一部分。
Kustomize 是一个工具，允许用户“为不同的目的定制简单的、无模板的 YAML 文件，使原始 YAML 保持完整和可用”（描述直接借用自 ）。 Kustomize 可以直接运行，或者从 Kubernetes 1.14 开始使用 kubectl -k 访问其功能（尽管从 Kubernetes 1.15 开始，单独的二进制文件比 kubectl 中内置的功能更新）。 (笔记。 翻译。: 随着最近的发布 自定义 也在 kubeadm 实用程序中。） 在这篇文章中，我想向读者介绍 kustomize 的基础知识。
在最简单的形式/应用程序中，kustomize 只是资源的集合（定义 Kubernetes 对象的 YAML 文件：部署、服务等）以及需要对这些资源进行更改的指令列表。 正如 make 使用包含在中的指令集一样 Makefile，并且 Docker 根据以下指令构建容器 Dockerfile,定制用途 kustomization.yaml 存储有关用户想要对一组资源进行哪些更改的说明。
这是一个示例文件 kustomization.yaml:
resources:
- deployment.yaml
- service.yaml
namePrefix: dev-
namespace: development
commonLabels:
environment: development
我不会尝试讨论文件中所有可能的字段。 kustomization.yaml （这写得很好 ），但我会用一个具体的例子来简单解释一下：
- 领域
resources指示 kustomize 的内容（哪些资源）将发生变化。 在这种情况下，它将在文件中查找资源deployment.yamlиservice.yaml在您的目录中（如有必要，您可以指定完整或相对路径）。 - 领域
namePrefix指示 kustomize 添加特定前缀（在本例中 -dev-) 属性name字段中定义的所有资源resources。 因此，如果 Deployment 有name有意义nginx-deployment，定制就可以了dev-nginx-deployment. - 领域
namespace指示 kustomize 将给定命名空间添加到所有资源。 在这种情况下，Deployment和Service将落入命名空间development. - 最后是田野
commonLabels包含一组将添加到所有资源的标签。 在我们的示例中，kustomize 将为具有名称的资源分配一个标签environment和意义development.
如果用户这样做 kustomize build . 在包含该文件的目录中 kustomization.yaml 以及必要的资源（即文件 deployment.yaml и service.yaml），然后在输出处它将收到一个文本，其中指定的更改 kustomization.yaml.
笔记。 翻译。：项目文档中有关 kustomize“简单”使用的插图
如果需要提交更改，可以重定向输出：
kustomize build . > custom-config.yaml输出数据是确定性的（相同的输入数据将产生相同的输出结果），因此您不必将结果保存到文件中。 相反，它可以直接传递给另一个命令：
kustomize build . | kubectl apply -f -
还可以通过以下方式访问 kustomize 功能 kubectl -k （自 Kubernetes 版本 1.14 起）。 但是，请记住，独立的 kustomize 包的更新速度比集成的 kubectl 包更快（至少 Kubernetes 1.15 版本是这样）。
读者可能会问：“如果可以直接编辑文件，为什么还要这么复杂呢？” 很好的问题。 在我们的例子中，确实 人们可以 修改文件 deployment.yaml и service.yaml 直接，但如果它们是其他项目的分支怎么办？ 当对源/源进行更改时，直接更改文件会使重新设置分支变得困难（如果不是不可能的话）。 使用 kustomize 允许您将这些更改集中在一个文件中 kustomization.yaml，保持原始文件完整，从而在必要时更容易重新调整原始文件的基础。
kustomize 的好处在更复杂的用例中变得显而易见。 在上面的例子中 kustomization.yaml 并且资源都在同一个目录下。 但是，kustomize 支持存在基本配置及其许多变体的用例，也称为 覆盖。 例如，用户想要采用我用作示例的 nginx 的部署和服务，并创建这些文件的开发、暂存和生产版本（或变体）。 为此，他需要上述覆盖层，实际上还需要基本资源本身。
来说明overlays和底层资源的思想 （基础资源），我们假设目录具有以下结构：
- base
- deployment.yaml
- service.yaml
- kustomization.yaml
- overlays
- dev
- kustomization.yaml
- staging
- kustomization.yaml
- prod
- kustomization.yaml
在文件中 base/kustomization.yaml 使用该字段的用户 resources 只需声明 kustomize 应包含的资源即可。
在每个文件中 overlays/{dev,staging,prod}/kustomization.yaml 用户参考现场基本配置 resources，然后指出具体更改 给定环境。 例如，文件 overlays/dev/kustomization.yaml 可能类似于前面给出的示例：
resources:
- ../../base
namePrefix: dev-
namespace: development
commonLabels:
environment: development
在这种情况下，文件 overlays/prod/kustomization.yaml 可能完全不同：
resources:
- ../../base
namePrefix: prod-
namespace: production
commonLabels:
environment: production
sre-team: blue
当用户运行时 kustomize build . 在目录中 overlays/dev, kustomize 将生成开发选项。 如果你跑 kustomize build . 在目录中 overlays/prod - 您可以获得生产选项。 而这一切——无需对原始内容进行任何更改 （基础） 文件，全部以声明性和确定性的方式。 您可以将基本配置和覆盖目录直接提交到版本控制，因为您知道基于这些文件您可以随时重现所需的配置。
笔记。 翻译。：项目文档中有关在 kustomize 中使用叠加层的插图
定制即可 更 比本文涵盖的内容还要多。 不过，我希望它能作为一个很好的介绍。
Дополнительныересурсы
有很多关于 kustomize 的好文章和出版物。 以下是我发现特别有用的一些内容：
- ;
- ;
- ;
- .
笔记。 翻译。：您还可以推荐发布为的链接块 在该实用程序的网站上，随后是一系列视频，其中包含有关 kustomize 的最新报告。
如果您对改进本材料有疑问或建议，我随时欢迎反馈。 您可以通过以下方式联系我 或 。 享受使用 kustomize 修改清单的乐趣！
译者PS
另请阅读我们的博客：
- «“;
- «“;
- «“;
- «“。
来源： habr.com