介绍kustomize; Kubernetes的无模板配置自定义

作者: Jeff Regan(Google),Phil Wittrock(Google)

如果您运行的是Kubernetes环境,那么您很有可能 自定义Kubernetes配置-您已复制 一些API对象YAML文件并对其进行编辑以适合 your needs.

但是这种方法有缺点-可能是 很难回到原始资料并纳入 对它所做的任何改进。今天的Google announcing Kustomize,一个命令行工具 contributed as a 子项目SIG-CLI。工具 提供纯粹的新 陈述式 接近 遵循和的配置自定义 利用熟悉且精心设计的 Kubernetes API.

这是一个常见的情况。您在互联网上的某个地方 查找某人的Kubernetes配置内容 管理系统。这是一组包含YAML的文件 Kubernetes API对象的规范。然后,在一些 您自己公司的一角,您可以找到以下配置 一个支持该CMS的数据库-您更喜欢的数据库 因为你很了解。

您想以某种方式一起使用它们。另外,你 要自定义文件,以便您的资源 实例出现在集群中并带有标签, 将他们与同事的资源区分开来 在同一集群中做相同的事情。 您还想为CPU,内存设置适当的值 and replica count.

此外,您需要 多种变体 的 整个配置:一个小的变体(就 专门用于测试和 实验,以及更大的变体 在生产中为外部用户提供服务。同样,其他 团队将需要他们自己的变体。

这引发了各种各样的问题。你复制你的 配置到多个位置并对其进行编辑 独立吗?如果您有数十项开发该怎么办 需要稍微不同的变化的团队 堆栈?您如何维护和升级以下方面 他们有共同点的配置?工作流程 using Kustomize 提供这些问题的答案。

定制就是重用

Kubernetes配置不是代码(是YAML API对象的规范,它们更加严格 视为数据),但配置生命周期有很多 与代码生命周期的相似之处。

您应该保留版本配置 控制。配置所有者不一定是 与配置相同的人员 用户。配置可以用作更大的一部分 整个。用户会想要 重用 的配置 different purposes.

一种配置重用的方法,如代码 重用就是简单地复制所有内容并自定义 复制。与代码一样,切断与 原始资料很难从中受益 持续改进原始资料。服用 这种方法有很多团队或环境,每个 结合自己的配置变体 简单的升级很难。

重用的另一种方法是表示源 材料作为参数化模板。工具加工 模板-执行任何嵌入式脚本和 用所需值替换参数以生成 配置。重用来自使用不同的 具有相同模板的值集。挑战 这是模板和值文件不是 Kubernetes API资源的规范。他们是, 必然是一种新事物,新语言 Kubernetes API。是的,它们可以强大,但是 带来学习和工具成本。不同 团队想要不同的改变,所以几乎每个人 可以包含在YAML文件中的规范 成为需要值的参数。结果是, 值集变大,因为所有参数(即 没有可信的默认值),必须为 替代。这挫败了目标之一 重用-保持变体之间的差异 体积小,如果没有则易于理解 完整的资源声明。

配置自定义的新选项

比较一下 Kustomize,该工具的位置 行为由声明性规范确定 expressed in a 文件 called kustomization.yaml.

Kustomize 程序读取文件,然后 它引用的Kubernetes API资源文件然后发出 完成标准输出的资源。此文字输出 可以通过其他工具进一步处理或流式传输 directly to Kubectl 适用于集群。

例如,如果一个名为 kustomization.yaml包含

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

在当前工作目录中,以及 它提到的三个资源文件,然后运行

Kustomize build

发出包含三个给定的YAML流 resources, 和一个dds a common label app: hello to each resource.

同样,您可以使用 commonAnnotations 到 向所有资源添加注释,并且 namePrefix 为所有资源添加通​​用前缀的字段 名称。这项琐碎却又常见的定制只是 the 是 ginning.

一个更常见的用例是您需要多个 一组常见资源的变体,例如 发展, 分期生产 变体。

以此目的, Kustomize 支持一个想法 覆盖 和一个 基础。两者均以 kustomization文件。该基地宣布的东西 变体有共同点(资源和共同点 自定义这些资源)和叠加层 声明差异。

这是文件系统布局,用于管理 分期生产 给定集群应用的变体:

   someapp/
   ├── 基础/
   │   ├── kustomization.yaml
   │   ├── deployment.yaml
   │   ├── configMap.yaml
   │   └── service.yaml
   └── 覆盖s/
      ├── 生产/
      │   └── kustomization.yaml
      │   ├── replica_count.yaml
      └── 分期/
          ├── kustomization.yaml
          └── cpu_count.yaml

的 文件 someapp/base/kustomization.yaml specifies the 那些共同的资源和共同的定制 资源(例如,它们都获得了一些标签,名称前缀 and annotation).

内容 someapp/overlays/production/kustomization.yaml 可以 be

   commonLabels:
    env: 生产
   基础s:
   - ../../base
   补丁es:
   - replica_count.yaml

该Kustomization指定了 补丁 文件 replica_count.yaml,可能是:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: the-deployment
   spec:
     复制品: 100

补丁是部分资源声明,在这种情况下 部署的补丁 someapp/base/deployment.yaml,仅修改 复制品 来处理生产流量。

该补丁是部分部署规范,具有明确的 上下文和目的,即使是 与其余部分隔离阅读 组态。不只是上下文无关 {参数 name, value} 元组。

要为生产变型创建资源,请运行

Kustomize build someapp/overlays/production

结果作为一组完整的信息打印到标准输出 资源,准备将其应用于集群。一种 类似的命令定义了暂存环境。

综上所述

Kustomize,您可以管理任意数量 个性化定制的Kubernetes配置 仅使用Kubernetes API资源文件。每一个 artifact that Kustomize 用途是简单的YAML,可以 如此进行验证和处理。 Kustomize鼓励 a fork/modify/rebase 工作流程.

要开始使用,请尝试 你好,世界 例。 如需讨论和反馈,请加入 邮件列表 要么 打开一个问题。欢迎提出请求。