Kustomize 无需模板定制你的 kubernetes 配置

本文介绍了 Kubernetes 原生的应用管理工具 Kustomize。

作者 guoxudong 发表于 2019年4月15日 更新于 2023年1月10日

作者:Jeff Regan (Google), Phil Wittrock (Google) 2018-05-29

如果你在运行 kubernetes 集群,你可能会拷贝一些包含 kubernetes API 对象的 YAML 文件,并且根据你的需求来修改这些文件,通过这些 YAML 文件来定义你的 kubernetes 配置。

但是这种方法存在很难找到配置的源头并对其进行改进。今天 Google 宣布推出 Kustomize ,一个作为 SIG-CLI 子项目的命令行工具。这个工具提供了一个全新的、纯粹的声明式的方法来定制 kubernetes 配置,遵循并利用我们熟悉且精心设计的 Kubernetes API。

有这样一个常见的场景,在互联网上可以看到别人的 CMS(content management system,内容管理系统)的 kubernetes 配置,这个配置是一组包括 Kubernetes API 对象的 YAML 描述文件。然后,在您自己公司的某个角落,您找到一个你非常了解的数据库,希望用它来该 CMS 的数据。

你希望同时使用它们,此外,你希望自定义配置文件以便你的资源实例在集群中显示,并通过添加一个标签来区分在同一集群中做同样事情的其他资源。同时也希望为其配置适当的 CPU 、内存和副本数。

此外,你还想要配置整个配置的多种变化:一个专门用于测试和实验的小服务实例(就计算资源而言),或更大的用于对外提供服务的生产级别的服务实例。同时,其他的团队也希望拥有他们自己的服务实例。

定制就是复用

kubernetes 的配置并不是代码(是使用 YAML 描述的 API 对象,严格来说应该是数据),但是配置的生命周期与代码的生命周期有许多相似之处。

你需要在版本控制中保留配置。所有者的配置不必与使用者的配置相同。配置可以作为整体的一部分。而用户希望为在不同的情况下复用这些配置。

与代码复用相同,一种复用配置的方法是简单的全部拷贝并进行自定义。像代码一样,切断与源代码的联系使得从改进变的十分困难。许多团队和环境都使用这种方法,每个团队和环境都拥有自己的配置,这使得简单的升级变得十分棘手。

另一种复用方法是将源代码抽象为参数化模板。使用一个通过执行脚本来替换所需参数的模板处理工具生成配置,通过为同一模板设置不同的值来达到复用的目的。而这种方式面临的问题是模板和参数文件并不在 kubernetes API 资源的规范中,这种方式必定是一种包装了 kubernetes API 的新东西、新语言。虽然这种方式很强大,但是也带来了学习成本和安装工具的成本。不同的团队需要不同的更改,因此几乎所有可以包含在 YAML 文件中的规范都会需要抽象成参数。

自定义配置的新选择

kustomize 中工具的声明与规范是由名为 kustomization.yaml 的文件定义。

kustomize 将会读取声明文件和 Kubernetes API 资源文件,将其组合然后将完整的资源进行标准化的输出。输出的文本可以被其他工具进一步处理,或者直接通过 kubectl 应用于集群。

例如,如果 kustomization.yaml 文件包括:

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

确保这三个文件与 kustomization.yaml 位于同一目录下,然后运行:

kustomize build

将创建包含三个资源的 YAML 流,其中 app: hello 为每个资源共同的标签。

同样的,你可以使用 commonAnnotations 字段给所有资源添加注释, namePrefix 字段为所有的资源添加共同的前缀名。这些琐碎而有常见的定制只是一个开始。

一个更常见的例子是,你需要为一组相同资源设置不同的参数。例如:开发、演示和生产的参数。

为此,Kustomize 允许用户以一个应用描述文件 (YAML 文件)为基础(Base YAML),然后通过 Overlay 的方式生成最终部署应用所需的描述文件。两者都是由 kustomization 文件表示。基础(Base)声明了共享的内容(资源和常见的资源配置),Overlay 则声明了差异。

这里是一个目录树,用于管理集群应用程序的 演示生产 配置参数:

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

patch 是部分的资源声明,在这个例子中是 Deployment 的补丁 someapp/base/deployment.yaml ,仅修改了副本数用以处理生产流量。

该补丁不仅仅是一个无上下文 {parameter name,value} 元组。其作为部分 deployment spec,可以通过验证,即使与其余配置隔离读取,也具有明确的上下文和用途。

要为生产环境创建资源,请运行:

kustomize build someapp/overlays/production

运行结果将作为一组完整资源打印到标准输出,并准备应用于集群。可以用类似的命令定义演示环境的配置。

综上所述

使用 kustomize ,您可以仅使用 Kubernetes API 资源文件就可以管理任意数量的 Kubernetes 定制配置。kustomize 的每个产物都是纯 YAML 的,每个都可以进行验证和运行的。kustomize 鼓励通过 fork/modify/rebase 这样的工作流来管理海量的应用描述文件。

尝试hello world示例,开始使用 kustomize 吧!有关的反馈与讨论,可以通过加入邮件列表或提 issue,欢迎提交PR。

译者按

随着 kubernetes 1.14 的发布,kustomize 被集成到 kubectl 中,用户可以利用 kubectl apply -k dir/ 将指定目录的 kustomization.yaml 提交到集群中。

原文链接 https://kubernetes.io/blog/2018/05/29/introducing-kustomize-template-free-configuration-customization-for-kubernetes/