好好学K8S：Kustomize工具

1. Kustomize简介

Kustomize是一个独立的工具，用来通过kustomization文件定制Kubernetes对象。
从 1.14 版本开始，kubectl 也开始支持使用 kustomization 文件来管理 Kubernetes 对象。要查看包含 kustomization 文件的目录中的资源，执行下面的命令：

kubectl kustomize <kustomization_directory>

要应用这些资源，使用 –kustomize 或 -k 参数来执行 kubectl apply：

kubectl apply -k <kustomization_directory>

参考文档：

• Kustomize
• 使用 Kustomize 对 Kubernetes 对象进行声明式管理
• kustomize - kustomization
• kustomize - PatchesJson6902
• kubernetes-sigs/kustomize
• kustomize - Examples
• Demo: change image names and tags

2. Kustomize作用

2.1. 生成资源

ConfigMap 和 Secret 包含其他 Kubernetes 对象（如 Pod）所需要的配置或敏感数据。 ConfigMap 或 Secret 中数据的来源往往是集群外部，例如某个 .properties 文件或者 SSH 密钥文件。 Kustomize 提供 secretGenerator 和 configMapGenerator，可以基于文件或字面值来生成 Secret 和 ConfigMap。

2.2. 设置贯穿性字段

在项目中为所有 Kubernetes 对象设置贯穿性字段是一种常见操作。 贯穿性字段的一些使用场景如下：

• 为所有资源设置相同的名字空间
• 为所有对象添加相同的前缀或后缀
• 为对象添加相同的标签集合
• 为对象添加相同的注解集合

2.3. 组织和定制资源

一种常见的做法是在项目中构造资源集合并将其放到同一个文件或目录中管理。Kustomize提供基于不同文件来组织资源并向其应用补丁或者其他定制的能力。

Kustomize 支持组合不同的资源。kustomization.yaml 文件的 resources 字段定义配置中要包含的资源列表。我们可以将 resources 列表中的路径设置为资源配置文件的路径。

补丁文件（Patches）可以用来对资源执行不同的定制。Kustomize 通过 patchesStrategicMerge 和 patchesJson6902 支持不同的打补丁机制。下文【使用Kustomize】一节中会有补丁机制的具体用法。

3. 安装Kustomize

kubectl中集成的kustomize功能不全，因此最好还是单独安装kustomize。

brew install kustomize

4. 使用Kustomize

4.1. 生成资源清单

kustomize build <kustomization_directory>

4.2. patchesStrategicMerge打补丁

patchesStrategicMerge 的内容是一个文件路径的列表，其中每个文件都应可解析为策略性合并补丁（Strategic Merge Patch）。 补丁文件中的名称必须与已经加载的资源的名称匹配。建议构造规模较小的、仅做一件事情的补丁。例如，构造一个补丁来增加 Deployment 的副本个数；构造另外一个补丁来设置内存限制。

示例：

# base/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  replicas: 3

# overlays/patch.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  template:
    spec:
      containers:
        - name: my-container
          image: nginx:latest

# kustomization.yaml
resources:
  - base/deployment.yaml
patchesStrategicMerge:
  - overlays/patch.yaml

在这个示例中，patchesStrategicMerge 使用 YAML 格式的补丁。它修改了 my-deployment 的 spec.template.spec.containers，将其中的镜像更改为 nginx:latest。补丁会与原始资源合并，生成最终的部署资源。

4.3. patchesJson6902打补丁

4.3.1. patchesJson6902补丁机制概述

patchesJson6902 补丁机制使用 JSON Patch 格式，它描述了如何对现有资源进行精确的更改。
JSON Patch 是一个标准的 RFC 6902 文档，它定义了一组操作，如添加、替换、移动、复制和删除，以便对 JSON 对象进行修改。
使用 patchesJson6902，我们可以提供一个或多个 JSON Patch 文件，这些文件将按顺序应用于原始资源，生成最终的结果。

4.3.2. 示例1

// patches/patch.json
[
  { "op": "replace", "path": "/spec/replicas", "value": 5 }
]

// kustomization.yaml
resources:
  - base/deployment.yaml
patchesJson6902:
  - target:
      group: apps
      version: v1
      kind: Deployment
      name: my-deployment
    path: patches/patch.json

示例1中，patchesJson6902 使用 JSON Patch 格式的补丁。它使用 replace 操作将 my-deployment 的 spec.replicas 更改为 5。补丁会被应用到原始资源上，生成具有修改的最终部署资源。

4.3.3. 示例2

// kustomization.yaml
resources:
  - base/deployment.yaml
patchesJson6902:
  - target:
      group: apps
      version: v1
      kind: Deployment
      name: my-deployment
    patch: |-
      - op: replace
        path: /spec/replicas
        value: 5

示例2实现的效果，和示例1相同。

4.3.4. 示例3

// patches/patch.yaml
- op: replace
  path: /spec/replicas
  value: 5

// kustomization.yaml
resources:
  - base/deployment.yaml
patchesJson6902:
  - target:
      group: apps
      version: v1
      kind: Deployment
      name: my-deployment
    path: patches/patch.yaml

示例3中，patchesJson6902 使用 YAML Patch 格式的补丁。实现了和示例1完全相同的效果。

注意：patchesJson6902 默认是不支持 YAML 格式的补丁文件的，但是Kustomize做了额外的实现以支持YAML格式的补丁文件。

4.3.5. 示例4

- target:
    group: networking.k8s.io
    kind: Ingress
    name: test
    version: v1
  patch: |-
    - op: add
      path: /metadata/annotations/argocd.argoproj.io~1sync-options
      value: Skip

示例4中，使用 patchesJson6902 在 Ingress 资源中添加 argocd.argoproj.io/sync-options: Skip ，使argocd忽略该资源的同步。
需要注意的是，annotations的key中的/，被改成了~1。

4.4. 修改镜像

需求：使用kustomize修改pod中使用的镜像。

1、创建测试yaml

cat <<EOF >kustomization.yaml
resources:
- pod.yaml
EOF

cat <<EOF >pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: myapp-container
    image: busybox:1.29.0
    command: ['sh', '-c', 'echo The app is running! && sleep 3600']
  initContainers:
  - name: init-mydb
    image: busybox:1.28.0
    command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;']
EOF

2、不修改镜像，生成资源清单

kustomize build .

3、设置修改镜像
（1）修改image busybox:1.29.0 为 alpine:3.6

kustomize edit set image busybox:1.29.0=alpine:3.6

执行后，kustomization.yaml中会写入：

images:
- name: busybox:1.29.0
  newName: alpine
  newTag: 3.6

（2）修改image busybox 为 alpine:3.6，无论 busybox 版本是什么

kustomize edit set image busybox=alpine:3.6

执行后，kustomization.yaml中会写入：

images:
- name: busybox
  newName: alpine
  newTag: 3.6

4、设置修改镜像后，生成资源清单

kustomize build .

5. Kustomize问题记录

5.1. 部分资源清单前缀未修改

已知 kustomization.yaml 内容为：

namePrefix: prod-
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- deployment.yaml
- pvc.yaml

生产资源清单之后，发现其中一个 deployment 中的claimName并没有添加 prod- 前缀。

解决办法：经过多次测试，发现是因为该 deployment 配置了namespace，去掉后问题解决。