Secrets and ConfigMaps

Motivation

The source of truth for Secret and ConfigMap Resources typically resides somewhere else, such as a .properties file. Apply offers native support for generating both Secrets and ConfigMaps from other sources such as files and literals.

Additionally, Secrets and ConfigMaps require rollouts to be performed differently than for most other Resources in order for the changes to be rolled out to Pods consuming them.

Generators

Secret and ConfigMap Resources can be generated by adding secretGenerator or configMapGenerator entries to the kustomization.yaml file.

The generated Resources name’s will have suffixes that change when their data changes. See Rollouts for more on this.

ConfigMapsGenerator

Consider we have to generate ConfigMap from a preset values stored in .properties file. One can make use of the following kustomization.yaml file to do so.

# kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
configMapGenerator:
- name: my-application-properties
  files:
  - application.properties

# application.properties
FOO=Bar

We get a generated ConfigMap YAML as output:

apiVersion: v1
data:
  application.properties: |-
        FOO=Bar
kind: ConfigMap
metadata:
  name: my-application-properties-f7mm6mhf59

SecretGenerator

Rollouts

ConfigMap values are consumed by Pods as: environment variables, command line arguments and files.

This is important because Updating a ConfigMap will:

• immediately update the files mounted by all Pods consuming them
• not update the environment variables or command line arguments until the Pod is restarted

Typically users want to perform a rolling update of the ConfigMap changes to Pods as soon as the ConfigMap changes are pushed.

Apply facilitates rolling updates for ConfigMaps by creating a new ConfigMap for each change to the data. Workloads (e.g. Deployments, StatefulSets, etc) are updated to point to a new ConfigMap instead of the old one. This allows the change to be gradually rolled the same way other Pod Template changes are rolled out.

Each generated Resources name has a suffix appended by hashing the contents. This approach ensures a new ConfigMap is generated each time the contents is modified.

Note: Because the Resource names will contain a suffix, when looking for them with kubectl get, their names will not match exactly what is specified in the kustomization.yaml file.

Feedback

Was this page helpful?

Glad to hear it! Please tell us how we can improve.

Sorry to hear that. Please tell us how we can improve.