What is Kustomize?
Kustomize is a tool to customize Kubernetes objects. It makes application configuration (YAML files) management very easy and intuitive. It is not template based and hence we do not need to create a template out of an existing yaml, instead we can reuse an existing yaml. It uses declarative management technique which means it can patch an existing yaml on need basis, or update yaml by generating resources.
Kustomize uses kustomization file through which it provides configuration management functionalities. Kubectl has buildt-in support for it starting with version 1.14. It can run in standalone mode also.
This is all some abstract conceptual view. Let’s explore it with some real time sample application.
Kustomize in action
To demonstrate few of the important capabilities of Kustomize, I have created a sample app (GitHub repo). I have used Docker desktop for windows for this demo.
It has a sample python app(flask based) under ‘python-docker’ folder. Please run the ‘build-docker-image.ps1’ to build the image which will be used to deploy apps to Kubernetes cluster.
The important part for this article is folder ‘k8s’ which consists of all the resource yamls which we need to run an application on Kubernetes(aka k8). it has 2 folders ‘base’ and ‘overlays’. The folder ‘base’ has all the base level resources’ configurations which are common to different environments.
Next is ‘overlays’ folder which consists of 3 different folders: dev, stage & prod; each referring to respective environments. Here based on different environments, resource configurations are overridden. You can check the folder structure in below image.
But there is one yaml file which is common in all the folders and that is ‘kustomization.yaml’. This is the yaml file which Kustomization CLI tool refers to. ‘kustomization.yaml’ file has reference to all the yaml files for respective resources.
You can see the kustomization yaml of base in left side image. The main things to notice here is apiVersion, kind and resources. kind specifies that this file is of type kustomization. resources have reference for all the Kubernetes resources (namespace, deployment, service & ingress) yaml files. The rest of the yaml files in base folder are very much K8 specific.
YAML for different environments
dev environment:
The configurations of dev environment can be found under ‘overlays/dev’ folder. Please check out the kustomization.yaml present in dev folder.
You can see that it has a bases section which is pointing to ‘k8s/base’ folder. This will use all the resources defined (as yaml) in base. Next is namespace which assigns the namespace for this environment by applying it to all the resources. Next one is commonLabels which assigns labels for all resources and selectors. Then comes the configMapGenerator. This generates configmap which will be used for this environment. In this case we are using literals to provide data items. Name of configmap; demo-k-app-configmap is same as mentioned in base yaml file (deployment.yaml).
The last one is ‘patchesStrategicMerge’. It is used to apply different customizations to Resources. It consists of list of file paths where each file should be used to resolve to a strategic merge patch. In simple terms these patch files (of overlays) add/override the same resource mentioned in base. The name mentioned in patch should match Resource name that are already loaded(in our case from base). Here the ingress.yaml of ‘overlays/dev’ combines/overrides the ingress resource defined in base.
You can use the following command to examine the complete set of yaml file.
# kubectl kustomize <path_to_folder_containing_yaml_files>
kubectl kustomize .\k8s\overlays\dev
To deploy app to Kubernetes cluster, run the below command.
# To deploy app/apply changes
# kubectl apply -k <path_to_folder_containing_yaml_files>
kubectl apply -k .\k8s\overlays\dev# Check list of resources
kubectl get pods,deployments,services,ingress,configmaps --namespace=dev-ns
stage environment
This is similar to the dev except for changed namespace, changed commonLabels and change in configMapGenerator. Here data items are provided through application.properties. The .properties file consists all the data items and then is referenced in kustomization.yaml.
prod environment
Production environment is same as dev and stage except for changed namespace, changed commonLabels and change in configMapGenerator. Here data items are provided through .env (present in ‘prod/.env’).
In this kustomization file there are 2 extra yaml files are added increase_replicas.yaml and set_memory.yaml. These 2 are added to increase the replica count and set memory limit. These 2 files are overriding the deployment.yaml of base.
You can see the image above which shows the resources of prod and here 2 pod instances are running based on the patchstrategicmerge of prod>>kustomize.
This was a sample use case showing how to work with Kustomize. Hope this article has helped you understand the basics of Kustomization.
For further reading you can check out Kustomize docs or Kubectl’s docs.
If you want to understand how Helm Chart can be used for configuration management, please check out this article by me.
