Changes to Kustomize Since v2.0.3 to v4.x

Kustomize is continuously improved to increase its capability and efficiency in the implementation of the code. Since v2.0.3 improvements that have been made have touched on handling patches, namespace, and go-module, amongst others. New commands such as the create and namespace have also been introduced to make it easier for developers to create code. Below are some of the main changes that have been made to kustomize since v2.0.3.

Introduction of go-module-packages

The introduction of go-modules to manage dependencies made kustomize more dynamic in handling external libraries. It increased the number of libraries that can be added to Kustomize and also the types of implementations that it could handle. Modules now declare their identity in the go-mod through the module directive. The packages in the module have to be imported with their paths matching the declared module path. In case of a mismatch between the declared module path and the import path, the unexpected module path error is reported by the go command.

Multiple objects patch

Kustomize started allowing one patch to support multiple resources from v3.1.0. This is supported by patching either a JSON patch or a strategic patch. With a strategic patch, you have to re-specify what you are looking to modify with the in-place changes. With a JSON patch, you specify in syntax the operation/target/value tuples. Implementation of a strategic patch:

• Deployments:

  $ cat <<EOF >$DEMO_HOME/deployments.yaml
  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: deploy1
  spec:
    template:
      metadata:
        labels:
          old-label: old-value
      spec:
        containers:
          - name: nginx
            image: nginx
            args:
            - one
            - two
  ---
  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: deploy2
  spec:
    template:
      metadata:
        labels:
          key: value
      spec:
        containers:
          - name: busybox
            image: busybox
  EOF
  

• Declaration of a strategic patch

  $ cat <<EOF >$DEMO_HOME/patch.yaml
  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: not-important
  spec:
    template:
      spec:
        containers:
          - name: istio-proxy
            image: docker.io/istio/proxyv2
            args:
            - proxy
            - sidecar
  EOF
  

• Defining the customization file

  $ cat <<EOF >$DEMO_HOME/kustomization.yaml
  resources:
  - deployments.yaml
  
  patches:
  - path: patch.yaml
    target:
      kind: Deployment
  EOF
  

Resource Matching Improvement

In v3.1.0 multiple improvements were introduced to make the “namespace” more powerful than “name suffix/prefix” when separating resources. This made it possible to better organize the code into logical clusters and prevent collisions of names, which is a common occurrence when multiple libraries are included in the base code.

Below is an example of namespace being used in patch definition:

apiVersion: apps/v1
kind: Deployment
metadata:
 name: deploy1
 namespace: main
spec:
 template:
   spec:
     containers:
     - name: nginx
       env:
       - name: ANOTHERENV
         value: TESTVALUE
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deploy1
  namespace: production
spec:
  template:
    spec:
      containers:
        - name: main
          env:
            - name: ANOTHERENV
              value: PRODVALUE

Improvement of Variable Resolution

Since v3.1.0 it is now possible to include the namespace field while creating a variable declaration. This makes it possible to declare multiple service objects that have a similar elasticsearch name in the same YAML.

vars:
- name: elasticsearch-test-protocol
  objref:
    kind: Service
    name: elasticsearch
    namespace: test
    apiVersion: v1
  fieldref:
    fieldpath: spec.ports[0].protocol
- name: elasticsearch-dev-protocol
  objref:
    kind: Service
    name: elasticsearch
    namespace: dev
    apiVersion: v1
  fieldref:
    fieldpath: spec.ports[0].protocol

Inline Patches

Inline patches were introduced in v3.2.0 and are now allowed in patches, patchesStrategicMerge, and patchesJson6902. This feature eliminated the need to create separate patch files by allowing the developer to add the patch content as a single string into the customization file. Example of inline patch in patchesStrategicMerge:

$ SMP_OVERLAY=$DEMO_HOME/smp

$ mkdir $SMP_OVERLAY

$ cat <<EOF >$SMP_OVERLAY/kustomization.yaml
resources:
- ../base

patchesStrategicMerge:
- |-
  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: deploy
  spec:
    template:
      spec:
        containers:
        - name: nginx
          image: nginx:latest
          
EOF

New create subcommand

This command was introduced in v3.2.0 and allows the developer to create a customization.yaml in a directory. Example of an overlay created from the base:

$ kustomize create --resources ../base

Go API-only module

After the introduction of Go API-only module in v3.3.0 top-level sigs.k8s.io/kustomize defined the Kustomize Go API with the Kustomize CLI sitting below it under an independent module sigs.k8s.io/kustomize/kustomize.