注意事项 佩雷夫 ：这篇文章是由资深IT工程师Scott Lowe撰写的，他曾与他人合着了七本印刷书籍（主要用于VMware vSphere）。 他目前在其VMware子公司Heptio（于2016年收购）工作，专门研究云计算和Kubernetes。 该文本本身是使用Kustomize技术（最近随K8一起提供）对Kubernetes进行配置管理的宽敞且易于理解的介绍。
Kustomize是一种工具，它允许用户“出于各种目的自定义简单且无模板的YAML文件，而保留原始的YAML并保持可用”（该描述直接从
GitHub上的kustomize存储库中借用）。 Kustomize可以直接运行，也可以从Kubernetes 1.14开始使用
kubectl -k来访问其功能（尽管从Kubernetes 1.15开始，单独的二进制文件比kubectl中内置的功能更新）。
（ 注意 ：在最新的Kubernetes 1.16版本中， kubeadm实用程序也支持 kustomize。）在本文中，我想向读者介绍kustomize的基础知识。
在最简单的形式/应用程序中，kustomize仅仅是资源的集合（定义Kubernetes对象的YAML文件：部署，服务等），以及有关需要对这些资源进行更改的指令列表。 正如make使用
Makefile包含的指令集，并且Docker根据
Dockerfile指令
Dockerfile容器
Dockerfile ，kustomize使用
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- ）添加到resources字段中定义的所有资源的name属性。 因此，如果Deployment中有一个name nginx-deployment ，则kustomize将从中删除dev-nginx-deployment 。namespace字段指示kustomize将指定的名称空间添加到所有资源。 在这种情况下，部署和服务将属于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为例的Deployment and Service，并为这些文件创建开发，暂存和生产版本（或变体）。 为此，他将需要上面提到的叠加层，并且实际上需要基本资源本身。
为了说明覆盖和
基础资源的概念，假设目录具有以下结构：
- 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最新报告的视频集合。如果您有关于改进本材料的问题或建议，我随时欢迎您提出反馈。 您可以通过
Twitter或
Kubernetes Slack频道与我联系。 玩得开心，用kustomize修改清单！
译者的PS
另请参阅我们的博客：