Kustomize is a tool to solve the application management problem of k8s yaml. kubectl has integrated kustomize since version 1.14. Before that, we had to install it ourselves.
You can download the package of the corresponding operating system on GitHub for installation (https://github.com/kubernetes-sigs/kustomize/releases).

Under windows, it is an exe file. After we put it in a directory and add environment variables, we can use it on the command line.

$ kustomize version
{Version:kustomize/v3.5.2 GitCommit:79a891f4881cfc780e77789a1d240d8f4bfa2598 BuildDate:2019-12-17T03:48:17Z GoOs:windows GoArch:amd64}

Well, back to k8s, when we deploy, will we use a lot of kubernetes objects to describe our services. For example, deployment,ingress,service,configMap,secret, etc. We use yaml files for configuration. For example, a typical deployment.yaml file looks like this

apiVersion: apps/v1beta2
kind: Deployment
metadata:
  name: smcp-service
  namespace: smcp-dev
spec:
  selector:
    matchLabels:
      app: smcp-service
  replicas: 1
  template:
    metadata:
      labels:
        app: smcp-service
    spec:
      containers:
        - name: smcp-service
          image: harbor.xxx.com/example/smcp-web:1.0
          imagePullPolicy: Always
          livenessProbe:
            httpGet:
              path: /api/anon/health
              port: 9000
            initialDelaySeconds: 80
            periodSeconds: 20
            timeoutSeconds: 2
          readinessProbe:
            httpGet:
              path: /api/anon/health
              port: 9000
            initialDelaySeconds: 90
            timeoutSeconds: 2
          ports:
            - containerPort: 9000
          envFrom:
            - configMapRef:
                name: smcp-config
            - secretRef:
                name: smcp-service-secret

For example, when we deploy the spring boot application to the dev environment, we can see that the namespace is SMCP dev, but when we deploy it to other environments, such as beta, staging, and production environments, we need to copy all the files mentioned above, and then modify the small variables (namespace,replica,image, etc.).

Moreover, if the contents of our environment variables are updated, the deployment will not be updated by scrolling, because their name s do not change (SMCP config, SMCP service secret).

kustomize came into being, which can solve our problems. It proposes the common part as the base, that is, the base layer, and then overlays the content in the base, which is similar to the concept of docker image layer. Base is insensitive to overlays. The resulting directory structure is like this

$ tree
.
|-- base
|   |-- deployment.yaml
|   |-- ingress.yaml
|   |-- kustomization.yaml
|   `-- service.yaml
`-- overlays
    |-- devlopment
    |   |-- cert
    |   |   |-- tls.crt
    |   |   `-- tls.key
    |   |-- config.properties
    |   |-- ingress-patch.yaml
    |   |-- kustomization.yaml
    |   `-- secret.properties
    `-- production
        |-- cert
        |   |-- tls.crt
        |   `-- tls.key
        |-- config.properties
        |-- ingress-patch.yaml
        |-- kustomization.yaml
        `-- secret.properties

6 directories, 16 files

However, only a few other files have been introduced into the base/kustomization.yaml file. The contents of its yaml file are as follows

resources:
- deployment.yaml
- ingress.yaml
- service.yaml

For example, the file ingress.yaml or service.yaml in the base only defines the deployment object and service object. For some parameters that need to be set according to different environments, such as namespace and replicas, you can set a default value first, and then modify them in overlays.

In overlays, we can see that we have placed the configuration of two environments under the overlays folder, respectively storing the unique configuration (config.properties,secret.properteis) in these two environments, and in the kustomization.yaml file, this is our modification to the content of the template file (base). Let's look at the configuration in the development environment

resources:
- ../../base

# Set namespace
namespace: smcp-example-dev


replicas:
- name: smcp-service
  count: 2

# Set configMap
configMapGenerator:
- name: smcp-config
  files:
  - config.properties

# Set secret
secretGenerator:
- name: smcp-service-secret
  envs:
  - secret.properties
- name: smcp-service-cert
  files:
  - cert/tls.crt
  - cert/tls.key
  type: kubernetes.io/tls

# The value of group/version here is equal to the value of apiVersion in the file ingress.yaml
patchesJson6902:
- target:
    group: extensions
    version: v1beta1
    kind: Ingress
    name: smcp-service-ingress
  path: ingress-patch.yaml

# Set image version
images:
- name: harbor.xxx.com/example/smcp-web
  newTag: 0.10.0-test

The content of the file is as follows. In fact, it is to modify the configuration of the domain name in the file and change the original domain name to be unique to the dev environment. ​

- op: replace
  path: /spec/tls/0/hosts/0
  value: test.example.com

- op: replace
  path: /spec/rules/0/host
  value: test.example.com

Finally, when we execute kustomize build overlays/devlopment, the newly generated api objects (deployment,ingress, etc.) will replace the values in the template as we set.

The newly generated Deployment object is as follows

apiVersion: apps/v1beta2
kind: Deployment
metadata:
  name: smcp-service
  namespace: smcp-example-dev
spec:
  replicas: 2
  selector:
    matchLabels:
      app: smcp-service
  template:
    metadata:
      labels:
        app: smcp-service
    spec:
      containers:
      - envFrom:
        - configMapRef:
            name: smcp-config-f5thmfmkb6
        - secretRef:
            name: smcp-service-secret-66m2658btb
        image: harbor.xxx.com/example/smcp-web:0.10.0-test
        imagePullPolicy: Always
        livenessProbe:
          httpGet:
            path: /api/anon/health
            port: 9000
          initialDelaySeconds: 80
          periodSeconds: 20
          timeoutSeconds: 2
        name: smcp-service
        ports:
        - containerPort: 9000
        readinessProbe:
          httpGet:
            path: /api/anon/health
            port: 9000
          initialDelaySeconds: 90
          timeoutSeconds: 2

You can see that compared with deployment.yaml in base,
replicas becomes 2,namespace becomes SMCP example dev, configmap and secret are generated according to ${name}-hash, and everything is modified according to the configuration of kustimization.yaml file.

And now as long as we update configMap and secret, we can trigger the rolling update (only the content in spec.spec in the deployment will trigger the rolling update).

At this point, we have completed the use of kustomization. With it, we can quickly deploy a set of systems to other environments, and modify the basic configuration only once, rather than in different environments.

Don't get lost