云原生之旅 - 6）不能错过的一款 Kubernetes 应用编排管理神器 Kustomize

前言

相信经过前一篇文章的学习，大家已经对Helm有所了解，本篇文章介绍另一款工具 Kustomize，为什么Helm如此流行，还会出现 Kustomize？而且 Kustomize 自 kubectl 1.14以来早已内置到其中，说明官方对其很认可。

我认为还是Helm 参数化模板方式来自定义配置需要学习复杂的DSL语法，难上手，易出错，而 kustomize 是使用 Kubernetes 原生概念帮助用户创作并复用声明式配置。

认识 Kustomize

https://kustomize.io/

根据官网的描述：kustomize 是 kubernetes 原生的配置管理，以无模板方式来定制应用的配置。kustomize 使用 kubernetes 原生概念帮助创建并复用资源配置(YAML)，允许用户以一个应用描述文件为基础（Base YAML），然后通过 Overlay 的方式生成最终部署应用所需的描述文件。

安装

参考官方文档。

我本地MacOs 直接运行 brew install kustomize

kubectl 1.14 以后可以不用下载单独的kustomize，直接使用kubectl命令。

示例解析

文件结构：

demo-manifests

├── base

│   ├── deployment.yaml

│   ├── kustomization.yaml

│   ├── service-account.yaml

│   └── service.yaml

└── services

    ├── demo-app

    │   ├── _common

    │   │   ├── deployment-patch.yaml

    │   │   ├── kustomization.yaml

    │   │   └── namespace.yaml

    │   ├── dev

    │   │   ├── config.json

    │   │   ├── deployment-patch.yaml

    │   │   └── kustomization.yaml

    │   ├── staging

    │   │   ├── config.json

    │   │   ├── deployment-patch.yaml

    │   │   └── kustomization.yaml

    │   └── prod

    │   │   ├── config.json

    │   │   ├── deployment-patch.yaml

    │   │   └── kustomization.yaml

    └── demo-app2

        └── xxx

先看base 目录，有几个常见的deployment/service/service-account YAML 资源文件

还有个 kustomization.yaml 配置文件

apiVersion: kustomize.config.k8s.io/v1beta1

kind: Kustomization

resources:

- deployment.yaml

- service.yaml

- service-account.yaml

commonLabels:

managed-by: Kustomize

这里面包含了刚才的几个resource文件以及要应用于它们的一些自定义，如添加一个通用的标签Common Labels

这时候也可以通过 kustomize build 命令来生成完整的YAML进行查看

kustomize build demo-manifests/base > base.yaml

base.yaml

build 出来的 YAML 每个资源对象上都会存在通用的标签 managed-by: Kustomize

接下来看 Service目录，此目录存放所有的服务项目，比如demo-app ，里面的YAML就是来覆盖base 也就是官方说的 Overlays

只需要把不同的资源描述通过Patch方式覆盖掉base中的就行了。这边我又将三个环境 dev/staging/prod 公共的部分抽取出来放入 common文件夹。

_common/kustomization.yaml文件如下

apiVersion: kustomize.config.k8s.io/v1beta1

kind: Kustomization

resources:

- ../../../base

- namespace.yaml

patchesStrategicMerge:

- deployment-patch.yaml

我这个demo-app 需要configMap，另外心跳接口也不一样，所以 deployment-patch.yaml 需要写出这些不一样的，然后去覆盖base中的。

apiVersion: apps/v1

kind: Deployment

metadata:

  name: NAME_PLACEHOLDER

spec:

  template:

    spec:

      serviceAccountName: NAME_PLACEHOLDER

      containers:

      - name: app

        image: wadexu007/demo:IMG_TAG_PLACEHOLDER

        livenessProbe:

          failureThreshold: 5

          httpGet:

            path: /pizzas

            port: 8080

          initialDelaySeconds: 10

          periodSeconds: 40

          timeoutSeconds: 1

        readinessProbe:

          failureThreshold: 5

          httpGet:

            path: /pizzas

            port: 8080

          initialDelaySeconds: 10

          periodSeconds: 20

          timeoutSeconds: 1

        volumeMounts:

        - name: config-volume

          mountPath: /app/conf/config.json

          subPath: config.json

      volumes:

      - name: config-volume

        configMap:

          name: demo-app-config

deployment-patch.yaml

---

apiVersion: v1

kind: Namespace

metadata:

  name: demo

namespace.yaml

### 文章首发于博客园 https://www.cnblogs.com/wade-xu/p/16839829.html

最后我们看 dev/kustomization.yaml

apiVersion: kustomize.config.k8s.io/v1beta1

kind: Kustomization

resources:

- ../_common


namespace: demo


commonLabels:

  app: demo-app


replicas:

- count: 1

  name: demo-app

configMapGenerator:

- files:

  - config.json

  name: demo-app-config

patches:

- patch: |-

    - op: replace

      path: /metadata/name

      value: demo-app

  target:

    name: NAME_PLACEHOLDER


patchesStrategicMerge:

- deployment-patch.yaml


images:

- name: wadexu007/demo

  newTag: 1.0.0

dev env 里面将replicas设置成1，用config.json 生成 configMap

{

    "SOME_CONFIG": "/demo/path"

}

config.json

deployment-patch.yaml 里面也将container resource request/limit 配置设置小一点，采用 patchesStrategicMerge 与 common 和 base里面的deployment资源合并。

apiVersion: apps/v1

kind: Deployment

metadata:

  name: NAME_PLACEHOLDER

spec:

  template:

    spec:

      containers:

      - name: app

        resources:

          limits:

            cpu: 1

            memory: 1Gi

          requests:

            cpu: 200m

            memory: 256Mi

deployment-patch.yaml

另外还采用了 patch 的方式，改了每个资源的name --> demo-app

以及images 替换了原来的 image name and tag.

kustomize 命令如下

 kustomize build demo-manifests/services/demo-app/dev > demo-app.yaml

如果用 kubectl 命令的话，示例如下

kubectl kustomize services/demo-app/dev/ > demo-app.yaml

最终结果

apiVersion: v1

kind: Namespace

metadata:

  labels:

    app: demo-app

  name: demo

---

apiVersion: v1

kind: ServiceAccount

metadata:

  labels:

    app: demo-app

    managed-by: Kustomize

  name: demo-app

  namespace: demo

---

apiVersion: v1

data:

  config.json: |-

    {

        "SOME_CONFIG": "/demo/path"

    }

kind: ConfigMap

metadata:

  labels:

    app: demo-app

  name: demo-app-config-t7c64mbtt2

  namespace: demo

---

apiVersion: v1

kind: Service

metadata:

  labels:

    app: demo-app

    managed-by: Kustomize

  name: demo-app

  namespace: demo

spec:

  ports:

  - port: 8080

    protocol: TCP

    targetPort: http

  selector:

    app: demo-app

    managed-by: Kustomize

  type: ClusterIP

---

apiVersion: apps/v1

kind: Deployment

metadata:

  labels:

    app: demo-app

    managed-by: Kustomize

  name: demo-app

  namespace: demo

spec:

  replicas: 1

  selector:

    matchLabels:

      app: demo-app

      managed-by: Kustomize

  template:

    metadata:

      labels:

        app: demo-app

        managed-by: Kustomize

    spec:

      containers:

      - image: wadexu007/demo:1.0.0

        imagePullPolicy: IfNotPresent

        livenessProbe:

          failureThreshold: 5

          httpGet:

            path: /pizzas

            port: 8080

          initialDelaySeconds: 10

          periodSeconds: 40

          timeoutSeconds: 1

        name: app

        ports:

        - containerPort: 8080

          name: http

        readinessProbe:

          failureThreshold: 5

          httpGet:

            path: /pizzas

            port: 8080

          initialDelaySeconds: 10

          periodSeconds: 20

          timeoutSeconds: 1

        resources:

          limits:

            cpu: 1

            memory: 1Gi

          requests:

            cpu: 200m

            memory: 256Mi

        securityContext:

          allowPrivilegeEscalation: false

        volumeMounts:

        - mountPath: /app/conf/config.json

          name: config-volume

          subPath: config.json

      serviceAccountName: demo-app

      volumes:

      - configMap:

          name: demo-app-config-t7c64mbtt2

        name: config-volume

demo-app.yaml

### https://www.cnblogs.com/wade-xu/p/16839829.html

staging/prod 文件夹也是类似dev的文件，环境不一样，config.json 以及资源配置，image tag 不一样，显示申明就行了。

完整代码请参考我的 Github

涵盖 Kustomize 知识点

commonLabels
patchesStrategicMerge
patches
configMapGenerator
replicas
images

总结

经过本篇文章的学习，以及上一篇 [云原生之旅 - 5）Kubernetes时代的包管理工具 Helm ]关于Helm的学习，您已经能体会到两款工具的不同之处。

Helm 通过将应用抽象成 Chart 来管理, 专注于应用的操作、生命周期管理（如 install、upgrade、rollback）等, 而 kustomize 关注于 k8s API 对象的管理。

Helm 适合对外交付使用，使用的Chart 相对固定、稳定，相当于静态管理，而 kustomize 管理的是正在变更的应用，创建新的 overlay 将应用部署在新的环境，相当于动态管理，适合于 DevOps 流程。

Helm 通过 Chart 方式打包并管理应用版本，kustomize 通过 overlay 方式管理应用不同的变体，通过 Git 来版本管理。

总的来说，Helm 有自己一套体系来管理应用，而 kustomize 更轻量级，也更灵活。另外，Kustomize也有 Terraform provider 通过TF来安装。

感谢阅读，如果您觉得本文的内容对您的学习有所帮助，您可以打赏和推荐，您的鼓励是我创作的动力。