kustomize 介绍

kustomize 是一个通过 kustomization 文件定制 kubernetes 对象的工具，它可以通过一些资源生成一些新的资源，也可以定制不同的资源的集合。

kustomize 术语

  • kustomization

kustomization 指的是 kustomization.yaml 文件，或者指的是包含 kustomization.yaml 文件的目录以及它里面引用的所有相关文件路径

  • base

base 指的是一个 kustomization , 任何的 kustomization 包括 overlay (后面提到)，都可以作为另一个 kustomization 的 base (简单理解为基础目录)。base 中描述了共享的内容，如资源和常见的资源配置

  • overlay

overlay 是一个 kustomization, 它修改(并因此依赖于)另外一个 kustomization. overlay 中的 kustomization指的是一些其它的 kustomization, 称为其 base. 没有 base, overlay 无法使用，并且一个 overlay 可以用作 另一个 overlay 的 base(基础)。简而言之，overlay 声明了与 base 之间的差异。通过 overlay 来维护基于 base 的不同 variants(变体)，例如开发、QA 和生产环境的不同 variants

  • variant

variant 是在集群中将 overlay 应用于 base 的结果。例如开发和生产环境都修改了一些共同 base 以创建不同的 variant。这些 variant 使用相同的总体资源，并与简单的方式变化，例如 deployment 的副本数、ConfigMap使用的数据源等。简而言之，variant 是含有同一组 base 的不同 kustomization

  • resource

在 kustomize 的上下文中，resource 是描述 k8s API 对象的 YAML 或 JSON 文件的相对路径。即是指向一个声明了 kubernetes API 对象的 YAML 文件

  • patch

修改文件的一般说明。文件路径，指向一个声明了 kubernetes API patch 的 YAML 文件

kustomization.yml

一个常见的 kustomization.yml 如下所示，一般包含 apiVsersion 和 kind 两个固定字段

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
- manager.yaml

configMapGenerator:
- files:
  - controller_manager_config.yaml
  name: manager-config

kustomize 提供了比较丰富的字段选择，除此之外还可以自定义插件，下面会大概列举一下每个字段的含义，当我们需要用到的时候知道有这么个能力，然后再去 Kustomize 官方文档 查找对应的 API 文档就行了

  • resources 表示 k8s 资源的位置，这个可以是一个文件，也可以指向一个文件夹，读取的时候会按照顺序读取，路径可以是相对路径也可以是绝对路径，如果是相对路径那么就是相对于 kustomization.yml的路径

  • crds 和 resources 类似，只是 crds 是我们自定义的资源

  • namespace 为所有资源添加 namespace

  • images 修改镜像的名称、tag 或 image digest ，而无需使用 patches

  • replicas 修改资源副本数

  • namePrefix 为所有资源和引用的名称添加前缀

  • nameSuffix 为所有资源和引用的名称添加后缀

  • patches 在资源上添加或覆盖字段，Kustomization 使用 patches 字段来提供该功能。

  • patchesJson6902 列表中的每个条目都应可以解析为 kubernetes 对象和将应用于该对象的 JSON patch。

  • patchesStrategicMerge 使用 strategic merge patch 标准 Patch resources.

  • vars 类似指定变量

  • commonAnnotations 为所有资源加上 annotations 如果对应的 key 已经存在值，这个值将会被覆盖

    1
2
3
4
5

    commonAnnotations:
  app.lailin.xyz/inject: agent

resources:
- deploy.yaml

  • commonLabels 为所有资源的加上 label 和 label selector 注意：这个操作会比较危险

    1
2
3
4
5

    apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

commonLabels:
  app: bingo

  • configMapGenerator 可以生成 config map，列表中的每一条都会生成一个 configmap

  • secretGenerator 用于生成 secret 资源

  • generatorOptions 用于控制 configMapGenerator 和 secretGenerator 的行为

kustomize 示例

一个比较典型的场景是我们有一个应用，在不同的环境例如生产环境和测试环境，它的 yaml 配置绝大部分都是相同的，只有个别的字段不同，这时候就可以利用 kustomize 来解决，kustomize 也比较适合用于 giweights 工作流。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

[root@dev-01 sammy-app]# tree
.
├── base
│   ├── configmap.yml
│   ├── deployment.yml
│   ├── kustomization.yaml
│   └── service.yml
└── overlays
    └── production
        ├── kustomization.yml
        └── map.yaml

​ 如上图所示，有一个 sammy-app 的应用，/base目录保存的是基本的配置，/overlays里放置的不同环境的配置，例如 /dev、/staging，/prod这些就是不同环境的配置，/base等文件夹下都有一个 kustomization .yml 文件，用于配置。

执行 kustomize build dir的方式就可以生成我们最后用于部署的 yaml 文件，也就是进行到了我们上图的第四步，然后通过 kubectl apply -f命令进行部署。

workflows 工作流

​ kustomize 将对 Kubernetes 应用的管理转换成对 Kubernetes manifests YAML 文件的管理，而对应用的修改也通过 YAML 文件来修改。这种修改变更操作可以通过 Git 版本控制工具进行管理维护, 因此用户可以使用 Git 风格的流程来管理应用。 workflows 是使用并配置应用所使用的一系列 Git 风格流程步骤。官网提供了两种方式，一种是定制配置，另一种是现成配置。

定制配置

在这个工作流中，所有的配置（YAML 文件）都属于用户所有。

img

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

# 定制工作流步骤如下：

1、创建一个目录用于版本管理
git init ~/ldap

2、创建一个 base
mkdir -p ~/ldap/base  # 在这个目录中创建并提交 kustomization.yaml 文件和一组资源，例如 deployment、service

3、创建 overlays
mkdir -p ~/ldap/overlays/staging
mkdir -p ~/ldap/overlays/production

4、生成 variants
kustomize build ~/ldap/overlays/staging | kubectl apply -f -
kustomize build ~/ldap/overlays/production | kubectl apply -f -

kubectl v1.14 版使用下面：
kubectl apply -k ~/ldap/overlays/staging
kubectl apply -k ~/ldap/overlays/production

现成配置

在这个工作流方式中，可从别人的 repo 中 fork kustomize 配置，并根据自己的需求来配置

img

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

# 现成配置工作流步骤如下：

1、通过 fork 方式获得现成配置

2、clone 作为你的 base
mkdir ~/ldap
git clone https://github.com/$USER/ldap ~/ldap/base
cd ~/ldap/base
git remote add upstream [email protected]:$USER/ldap

3、创建并填充 overlays
mkdir -p ~/ldap/overlays/staging
mkdir -p ~/ldap/overlays/production

4、生成 variants
kustomize build ~/ldap/overlays/staging | kubectl apply -f -
kustomize build ~/ldap/overlays/production | kubectl apply -f -

5、(可选)更新上游配置，用户可以定期更新他的 base, 以更新上游所做的修改
cd ~/ldap/base
git fetch upstream
git rebase upstream/master通过上面两种工作流方式，可以实现自定义管理应用的声明式资源文件，或者基于别人的应用声明式资源进行自定义修改

总结

总的来说 kustomize 更适合 giweights 模式，相比于 helm ，kustomize更加轻量，原生的yaml模版，不必学习新语法。而 helm 支持 GoTemplate，组件上也要多一些，并且 helm 通过 chart 包来进行发布相对来说还是要重量级一些。

参考文章