Managing Kubernetes Resources with Kustomize

In our last post we have seen about kustomize and also, we have seen where Kustomize will be used. Before we start, here will see some of its features and limitations are:

• It is already integrated into the kubectl CLI but the integrated version is normally outdated. Therefore, the standalone binary must be used to benefit from the latest features.
• It manages variants of resources with overlaying and merging yaml files in a structured way.
• It provides convenient built-in features to generate common resources like ConfigMaps and Secrets
• It has built-in transformers to modify resources.
• It can be extended via a plug-in mechanism.
• It is possible to dynamically change resources but this is restricted to particular fields of a resource.
• It only manages the yaml files and does not actively manage the resources in the cluster.

Philosophy

Let’s consider, your team using a Helm chart from an external organization or provider. As it is external one, we should modify as per our organization needs. How we can do? We need to either fork their repo and need to make all our changes and should apply to our cluster.

After a sometime you need to upgrade to latest version or any reason, like new version or security patching or some interesting new feature adaptation. In this case, to leverage those requirements, you have to fork the new Helm chart and re-apply your configuration changes. This may add more complexity to manage the changes and also adds risk in your application stability.

Here Kustomize comes to picture, it enables you to do that by creating a file that ties everything together, or optionally includes “overrides” for individual parameters. With that you can keep the changes in single files which helps to maintain it with versioning in GIT.

Installation

For a standalone kustomize installation (aka kustomize cli), use the following to set it up.

# curl -s "https://raw.githubusercontent.com/kubernetes-sigs/kustomize/master/hack/install_kustomize.sh"  | bash
# mv kustomize /usr/local/bin

Once you moved, you can run following command to test the command,

# kustomize -h

To check with kubectl,

# kubectl kustomize -h

Bases and overlays

Kustomize’s configuration helps to change the approach to leverage the use of kustomization layers so that the same base configuration files can be reused across multiple configurations. It achieves this with the concepts of bases and overlays.

• A base is a directory containing a file called kustomization.yaml, which can enumerate some set of resources with some customizations that will be applied to them. A base should be declared in the resources field of a kustomization file.
• An overlay is a directory that refers to another kustomization directory as its, or one of its, bases.

Overlays are what help us to accomplish our goal by producing variants without templating.

To start with Kustomize, you need to have your original yaml files describing any resources you want to deploy into your cluster. Let’s store the files in ./kustomize/base folder.

As we seen in last post, Kustomize not going to make any change original yaml files, all the changes will just apply customization above them to create new resources definitions.

Note: You can build base templates (e.g. for dev environment) at any point in time using the command kubectl apply -f ./kustomize/base/.

Continue reading on https://foxutech.com/managing-kubernetes-resources-with-kustomize/

If you like, you can Buy Me a Coffee.