The kustomize ConfigMap generator lets you declare ConfigMaps directly in your Kustomization files, pulling their contents from local files.
Let’s see it in action. Imagine you have a simple application that needs a settings.conf file.
First, create a directory for your Kustomization resources, say my-app/:
mkdir my-app
cd my-app
Inside my-app/, create your configuration file, settings.conf:
[database]
host = localhost
port = 5432
[logging]
level = INFO
Now, create a kustomization.yaml file in the same my-app/ directory:
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
configMapGenerator:
- name: app-settings
files:
- settings.conf
This kustomization.yaml tells Kustomize to:
- Look for a
configMapGeneratorsection. - Create a ConfigMap named
app-settings. - Populate this ConfigMap by reading the content of the
settings.conffile.
If you run kustomize build . in the my-app/ directory, you’ll see the generated Kubernetes manifest:
# kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
configMapGenerator:
- name: app-settings
files:
- settings.conf
---
apiVersion: v1
data:
settings.conf: |
[database]
host = localhost
port = 5432
[logging]
level = INFO
kind: ConfigMap
metadata:
name: app-settings-mjh2d7g4gd
Notice the name app-settings-mjh2d7g4gd. Kustomize automatically appends a hash of the generated ConfigMap’s content to its name. This is crucial for cache busting: if you change settings.conf and re-run kustomize build, the hash will change, and Kubernetes will treat it as a new ConfigMap, ensuring your application picks up the updated configuration.
This mechanism is how Kustomize handles immutable ConfigMaps and Secrets. When you deploy this to Kubernetes, the deployment object (or whatever consumes the ConfigMap) will reference app-settings-mjh2d7g4gd. If the content changes, the hash changes, the ConfigMap name changes, and Kubernetes sees a new object. It then triggers a rolling update for any Pods that depend on this ConfigMap, effectively updating the configuration without downtime.
You can also specify multiple files for a single ConfigMap:
# kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
configMapGenerator:
- name: app-configs
files:
- settings.conf
- logging.yaml
- api-keys.env
In this case, each file becomes a key-value pair within the app-configs ConfigMap. The filename becomes the key, and the file’s content becomes the value.
The files field can also take glob patterns. If you had many configuration files in a config/ subdirectory, you could do:
# kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
configMapGenerator:
- name: app-configs
files:
- config/.*.conf
- config/.*.yaml
This would include all files ending in .conf or .yaml from the config/ directory.
Sometimes, you might want to override specific keys within a ConfigMap, or even provide inline data. The literals field allows this.
# kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
configMapGenerator:
- name: app-settings
files:
- settings.conf
literals:
- database.port=5433 # Override the port
- logging.level=DEBUG # Add a new logging level
When literals are used alongside files, the literals take precedence. If database.port was already in settings.conf, the database.port=5433 literal would override it. If a key specified in literals doesn’t exist in any of the files, it’s added as a new entry to the ConfigMap. This is powerful for environment-specific overrides or for injecting dynamic values without modifying the source files.
The kustomize ConfigMap generator is a fundamental tool for managing application configuration in Kubernetes. It bridges the gap between your static configuration files and the dynamic, versioned nature of Kubernetes deployments. It ensures that configuration changes trigger necessary updates and simplifies the process of defining and managing your application’s settings.
The next step is often managing secrets, which share a very similar generator pattern.