推出 kustomize；Kubernetes 的无模板配置自定义

如果您运行 Kubernetes 环境，很可能您已经自定义了 Kubernetes 配置 — 您复制了一些 API 对象 YAML 文件并对其进行了编辑以满足您的需求。

但是这种方法存在缺点 — 很难回到源材料并合并对其所做的任何改进。今天，Google 宣布推出 kustomize，这是一个命令行工具，作为 子项目贡献于 SIG-CLI。该工具提供了一种新的、纯粹声明式的配置自定义方法，该方法遵循并利用了熟悉且精心设计的 Kubernetes API。

这是一个常见的场景。在互联网上的某个地方，您找到了某人为内容管理系统提供的 Kubernetes 配置。它是一组包含 Kubernetes API 对象 YAML 规范的文件。然后，在您自己公司的某个角落，您找到了一个用于支持该 CMS 的数据库的配置 — 您偏爱的数据库，因为它您很熟悉。

您想以某种方式将它们一起使用。此外，您希望自定义文件，以便您的资源实例在集群中显示一个标签，该标签将它们与在同一集群中做同样事情的同事的资源区分开来。您还希望为 CPU、内存和副本数设置适当的值。

此外，您还需要整个配置的多个变体：一个用于测试和实验的小变体（就使用的计算资源而言），以及一个用于在生产中为外部用户提供服务的大得多的变体。同样，其他团队也希望拥有自己的变体。

这引发了各种问题。您是否将您的配置复制到多个位置并独立编辑它们？如果数十个开发团队需要略有不同的堆栈变体怎么办？如何维护和升级它们共同拥有的配置方面？使用 kustomize 的工作流程为这些问题提供了答案。

自定义是重用

Kubernetes 配置不是代码（作为 API 对象的 YAML 规范，它们更严格地被视为数据），但配置生命周期与代码生命周期有许多相似之处。

您应该将配置保存在版本控制中。配置所有者不一定与配置用户是同一组人。配置可以用作更大整体的一部分。用户希望重用配置以用于不同目的。

与代码重用一样，一种配置重用的方法是简单地全部复制并自定义副本。与代码一样，切断与源材料的连接使得很难从源材料的持续改进中受益。对于许多团队或环境采用这种方法，每个团队或环境都有其自己的配置变体，使得简单的升级难以处理。

另一种重用方法是将源材料表示为参数化模板。工具处理模板 — 执行任何嵌入式脚本并将参数替换为期望的值 — 以生成配置。重用来自将不同的值集与同一模板一起使用。这里的挑战在于，模板和值文件不是 Kubernetes API 资源的规范。它们必然是一种新事物，一种新的语言，它包装了 Kubernetes API。是的，它们可以很强大，但也带来了学习和工具成本。不同的团队想要不同的更改 — 因此您可以在 YAML 文件中包含的几乎每个规范都成为需要值的参数。因此，值集变得很大，因为必须指定所有参数（没有信任默认值）以进行替换。这破坏了重用的目标之一 — 在没有完整资源声明的情况下，保持变体之间的差异大小较小且易于理解。

配置自定义的新选项

将其与 kustomize 进行比较，该工具的行为由名为 kustomization.yaml 的文件中表达的声明式规范决定。

kustomize 程序读取该文件及其引用的 Kubernetes API 资源文件，然后将完整的资源发送到标准输出。此文本输出可以由其他工具进一步处理，或直接流式传输到 kubectl 以应用于集群。

例如，如果名为 kustomization.yaml 的文件包含

   commonLabels:
     app: hello
   resources:
   - deployment.yaml
   - configMap.yaml
   - service.yaml

与它提到的三个资源文件一起位于当前工作目录中，然后运行

kustomize build

将发出一个 YAML 流，其中包含给定的三个资源，并为每个资源添加一个通用标签 app: hello。

同样，您可以使用 commonAnnotations 字段向所有资源添加注释，并使用 namePrefix 字段向所有资源名称添加通用前缀。这种微不足道但常见的自定义只是开始。

更常见的用例是，您需要一组公共资源的多个变体，例如 development、staging 和 production 变体。

为此，kustomize 支持 overlay 和 base 的概念。两者都由一个 kustomization 文件表示。base 声明变体共享的公共内容（包括资源和对这些资源的公共自定义），而 overlay 声明差异。

以下是一个文件系统布局，用于管理给定集群应用程序的 staging 和 production 变体

   someapp/
   ├── base/
   │   ├── kustomization.yaml
   │   ├── deployment.yaml
   │   ├── configMap.yaml
   │   └── service.yaml
   └── overlays/
      ├── production/
      │   └── kustomization.yaml
      │   ├── replica_count.yaml
      └── staging/
          ├── kustomization.yaml
          └── cpu_count.yaml

文件 someapp/base/kustomization.yaml 指定公共资源和对这些资源的公共自定义（例如，它们都获得一些标签、名称前缀和注释）。

someapp/overlays/production/kustomization.yaml 的内容可以是

   commonLabels:
    env: production
   bases:
   - ../../base
   patches:
   - replica_count.yaml

此 kustomization 指定一个 patch 文件 replica_count.yaml，该文件可以是

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: the-deployment
   spec:
     replicas: 100

补丁是资源的局部声明，在本例中是对 someapp/base/deployment.yaml 中的部署的补丁，仅修改 replicas 计数以处理生产流量。

补丁是部署规范的一部分，具有明确的上下文和目的，即使从剩余配置中单独读取，也可以进行验证。它不仅仅是一个没有上下文的 {参数名称、值} 元组。

要为 production 变体创建资源，请运行

kustomize build someapp/overlays/production

结果将作为一组完整的资源打印到 stdout，可以将其应用到集群。类似的命令定义了 staging 环境。

总结

使用 kustomize，您可以使用 Kubernetes API 资源文件来管理任意数量的独特自定义 Kubernetes 配置。kustomize 使用的每个工件都是纯 YAML，并且可以进行验证和处理。kustomize 鼓励 fork/modify/rebase 工作流程。

要开始使用，请尝试 hello world 示例。如需讨论和反馈，请加入 邮件列表 或 打开一个 issue。欢迎提交 pull 请求。

• ←上一篇
下一篇→