Use ConfigMap as a dynamic var source in Kustomize - Kubernetes

Update 25.07.2021: As mentioned before, the vars option will be deprecated in favor of replacements.

Kustomize is a declarative configuration tool for Kubernetes. And unlike other tools like Helm, it's "template-free", in a simple put, it's like merging dictionaries (Python) or maps (Java).

A pure declarative style could be annoying sometimes! But actually, Kustomize has a feature called "vars" that allows you to cross-reference K8s objects, or in other words:

Vars are used to capture text from one resource's field
and insert that text elsewhere - a reflection feature.

So I used this feature to unify vars, making it easier to group vars and also for better visibility. The idea is simple, using one or more ConfigMap as a source for vars. Let's have an example to make it more clear assuming that you already know Kustomize basics.



Let's take the famous example on Kubernetes docs as a base for our example which is Deploying WordPress and MySQL with Persistent Volumes. In 3 steps, we will use ConfigMap as vars source in Kustomize.

Step 1 - Create ConfigMap

In the base dir of the component a new ConfigMap will be created it will have all vars for that component (visibility: by just looking at that file, component internals are more visible).

This ConfigMap could actually be filtered using a plugin, so it just works as a transient object and it's not be applied to K8s API.

# base/mysql/vars/configmap.yaml

apiVersion: v1
kind: ConfigMap
  name: vars-mysql
  persistent-storage: /var/lib/mysql

Step 2 - Edit Kustomization file

Now we are going to add 3 things to the kustomization.yaml file, the ConfigMap that we just created, the var reference, and the actual var in

# base/mysql/kustomization.yaml

- vars/configmap.yaml

- path: data
  kind: ConfigMap

    fieldPath: data.persistent-storage
    apiVersion: v1
    kind: ConfigMap
    name: vars-mysql

Step 3 - Use the new Kustomize var

Now the new var MYSQL_PERSISTENT_STORAGE could be used like other Kustomize vars, and it's going to be replaced by Kustomize when applied. For example, let's use it in the StatefulSet resource.

# base/mysql/statefulset.yaml


- name: mysql-persistent-storage


So let me tell you why this method is really helpful:

  • In Kustomize base it gives more visibility, where anyone can know what configs are used in the component.
  • In Kustomize overlay it gives clarity where "MYSQL_PERSISTENT_STORAGE" is more clear than just "/var/lib/mysql".
  • In general it helps readability and avoid any confusion because in many cases the same value could represent different use. e.g. a value could be used in more than place for different contexts.
  • It's easy to change any value at anytime.
  • It's easy to introduce, there is not big change there.


This method works pretty well, however, there are a couple of caveats you need to consider.

Mainly, the vars functionality is limited by design in Kustomize! The find & replace doesn't work everywhere and Kustomize supports predefined list of paths where the replacements are effective!

For the same reason, the issue #2052 - kustomize vars - enhance or replace? was created to discuss the future of the vars functionality in Kustomize. It's a long issue with a lot of details but it seems that everyone agrees that vars would be removed at a certain point and probably that will be soon!

That's why it's maybe a good idea to wait a bit till the new successor is there or find/implement a plugin to do the same to avoid migration later.

That's it, enjoy :-)

Powered by Blogger.

Hello, my name is Ahmed AbouZaid and this is my "lite" technical blog!

I'm a passionate DevOps engineer, Cloud/Kubernetes specialist, Free/Open source geek, and an author.

I believe in self CI/CD (Continuous Improvements/Development), also that "the whole is greater than the sum of its parts".

DevOps transformation, automation, data, and metrics are my preferred areas. And I like to help both businesses and people to grow.

Popular Posts