Kustomize – its Features and Best Practices

Yet another topic to learn for GitOps. So far we have seen some important topics you should know on Kubernetes, now its time to know about another interesting tool.

What is Kustomize?

Kustomize is an increasingly popular tool for managing Kubernetes manifests. Rather than using templates, as Helm does, Kustomize works by building on existing manifests. Using this pattern, it provides various features including resource namespacing, modification of metadata, and generation of Kubernetes Secrets – all without editing the source original manifests.

To start using Kustomize you just need one or more Kubernetes manifests and a Kustomization file called kustomization.yaml. The Kustomization file is itself a manifest, which specifies a list of resources, patches to apply, and various other options.

Patches

Manifests that give complete Kubertnetes resources are listed in the Kustomization as resources.

Partial manifests can also be used as strategic merge patches, where they are combined with existing resources with matching metadata to add or edit fields. This can be a convenient way to add large blocks of YAML to a resource, as the patch file just looks like a normal YAML manifest.

JSON patches can also be used in a similar way, but with a more concise syntax that’s better suited to small changes.

Overlays

If you like to modify or create more variants, for that you can use overlays. Overlays also contain a kustomization.yaml file and can include new resource manifests, or patches for existing resources.

An overlay Kustomization must specify one or more bases. These bases must be directories containing Kustomizations which the overlay can build on. Overlays can also specify other overlays as bases, allowing them to be stacked.

Where Kustomize requires?

You may ask, as there is Helm and other tools, we have why we need Kustomize. Here will see where it uses and how it useful. 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.

Here you can see where the kustomize places in your continuous deployment pipeline, with this you can enable the GIT events or GitOps. With this you can keep Helm to generate the yaml files and Kustomize to patch environment specific values based on the events. For example, you can maintain a file with changes specific to branches, like if ‘master’ branch triggers, apply to Production environment.

Comparison

Before we check further let’s compare Kustomize to native Helm and native Kubectl to better highlight the differentiated functionality that it offers.

Benefits of Using Kustomize

Reusability

Kustomize allows you to reuse one base file across all of your environments (development, staging, production) and then overlay unique specifications for each.

Fast Generation

Since Kustomize has no templating language, you can use standard YAML to quickly declare your configurations.

Easier to Debug

YAML itself is easy to understand and debug when things go wrong. Pair that with the fact that your configurations are isolated in patches, and you’ll be able to triangulate the root cause of performance issues in no time. Simply compare performance to your base configuration and any other variations that are running.

Best Practices

1. Keep your custom resources and their instances in separate packages, otherwise you will encounter race conditions and your creation will get stuck. For example, many people keep both the CertManager CRD and CertManager’s resources in the same package, which can cause problems. Most of the time, reapplying the YAML fixes the issue. But it’s good practice to keep them separately.
2. Try to keep the common values like namespace, common metadata in the base file.
3. Organize your resources by kind, using the following naming convention: lowercase-hypenated.yaml (e.g., horizontal-pod-autoscaler.yaml). Place services in the service.yaml file.
4. Follow standard directory structure, using bases/ for base files and patches/ or overlays/ for environment-specific files.
5. While developing or before pushing to git, run “kubectl kustomize cfg fmt file_name” to format the file and set the indentation right.

Install Kustomize

Kustomize mostly used in conjunction with Helm as we seen above, and to use Kustomize, it is released both as a standalone binary and, since version 1.14 onwards, as a Kubectl integration. As earlier versions with kubectl integrated kustomize was not updated to match standalone version, due to that most of features were missing. To fix that, from Kubectl version 1.21 integrated Kustomize version was updated and has been kept up to date in following versions.

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

Hope this helps to understand about kustomize, in coming posts let see some example and integrations.

You can learn more Kubernetes and latest technologies on Udemy, Deal extended: Courses Up To 85% Off