Red Hat OpenShift Developer II: Building and Deploying Cloud-native Applications

Kustomize requires a kustomization.yaml file for each configuration set that can contain, for example:

The kustomization.yaml file must reside in each directory that represents a configuration set.

The resources section of the kustomization.yaml file is a list of files that create all the resources for a specific environment, for example:

resources:
- deployment.yaml
- secrets.yaml
- service.yaml

The layout for a base definition with the preceding resources uses the following directory structure:

myapp
└── base
  ├── deployment.yaml
  ├── kustomization.yaml
  ├── secrets.yaml
  └── service.yaml

Separating Kubernetes objects definition into smaller files simplifies developers to maintain the base set.

The kustomization.yaml file in an overlay directory must point to one or multiple base configuration sets that form the starting point for the overlay, for example:

bases:
- ../../base

This kustomization.yaml file is placed in an overlay, for example:

myapp/
├── base
│   ├── deployment.yaml
│   ├── kustomization.yaml
│   ├── secrets.yaml
│   └── service.yaml
└── overlays
    └── staging
        └── kustomization.yaml

This overlay starts with the base configuration and then applies any patch defined in it.

Kustomize provides a number of directives and configuration options that you can apply in the kustomization.yaml file. For example, you can set labels and annotations with the commonLabels and commonAnnotations sections of a kustomization.yaml file:

commonLabels:
  origin: kustomize

You can alter resource names, which is useful for overlays, for example:

namePrefix: dev-
nameSuffix: -v1

Finally, you can use Kustomize directives to generate resources. Consider the following base/kustomization.yaml file:

resources:
- deployment.yaml
- service.yaml

configMapGenerator:
- name: example-1
  files:
    - application.properties

- name: example-2
  literals:
  - FOO=Bar

The previous example generates two configuration maps. The example-1 configuration map contains the key-value pairs based on the application.properties file. When you define an overlay that uses the preceding base, you can use a different application.properties file to modify the values in the configuration map.

The example-2 configuration map defines the key-value pairs in the base/kustomization.yaml file.

Each overlay can provide a number of modifications to the base configuration through the list of patches. To patch a base configuration, use the patches directive to add the reference to the patch files in the kustomization.yaml file of the overlay, such as:

patches:
- replica_count.yaml

Then, create the patch file. In the patch file, identify the resource to change and modify the resource properties, such as:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 5

The preceding example targets a deployment called myapp and patches the replica count to 5.