Kubernetes ConfigMaps explained: Create, mount and use them

ConfigMaps let you separate configuration data from your container images. Instead of baking environment-specific values into your image, you store them in a ConfigMap and inject them at runtime. This means the same image can run in development, staging, and production with different configuration, without rebuilding.

ConfigMaps are for non-sensitive data. For passwords, tokens, and certificates, use Secrets instead.

Create a ConfigMap

From a literal value:

1kubectl create configmap demo --from-literal=name=saiyam

From a file:

1kubectl create configmap test --from-file=file.prop

From an environment file (multiple key-value pairs as separate data entries):

1kubectl create configmap test2 --from-env-file=env.prop

View all ConfigMaps:

1kubectl get configmap

Inspect a ConfigMap:

1kubectl describe configmap demo

Expected output:

1Name:         demo
2Namespace:    default
3Data
4====
5name:
6----
7saiyam

Three ways to consume a ConfigMap

Pattern 1: reference a specific key as an environment variable

1apiVersion: v1
2kind: Pod
3metadata:
4  name: demo
5spec:
6  containers:
7  - name: busybox
8    image: busybox
9    command: ["env"]
10    env:
11    - name: HELLO
12      valueFrom:
13        configMapKeyRef:
14          name: demo
15          key: name
16  restartPolicy: Never

1kubectl create -f demo.yaml
2kubectl logs demo

Expected output:

1HELLO=saiyam

Pattern 2: load all keys as environment variables with envFrom

Use envFrom when you want every key in the ConfigMap available as an environment variable without listing them individually:

1apiVersion: v1
2kind: Pod
3metadata:
4  name: demo-envfrom
5spec:
6  containers:
7  - name: busybox
8    image: busybox
9    command: ["env"]
10    envFrom:
11    - configMapRef:
12        name: demo
13  restartPolicy: Never

1kubectl create -f demo-envfrom.yaml
2kubectl logs demo-envfrom

All keys from the demo ConfigMap will appear as environment variables in the container output.

Pattern 3: mount a ConfigMap as a volume

When your application reads configuration from files on disk, mount the ConfigMap as a volume. Each key in the ConfigMap becomes a file at the mount path, with the value as the file contents.

First, create a ConfigMap with multiple keys:

1apiVersion: v1
2kind: ConfigMap
3metadata:
4  name: app-config
5data:
6  file1: |
7    setting1=value1
8    setting2=value2
9  file2: |
10    debug=true
11    log_level=info

1kubectl apply -f cm-for-volume.yaml

Then mount it into a pod:

1apiVersion: v1
2kind: Pod
3metadata:
4  name: cm-volume
5spec:
6  containers:
7  - name: busybox
8    image: busybox
9    command: ["ls", "/etc/config"]
10    volumeMounts:
11    - name: config-volume
12      mountPath: /etc/config
13  volumes:
14  - name: config-volume
15    configMap:
16      name: app-config
17  restartPolicy: Never

1kubectl create -f demo2.yaml
2kubectl logs cm-volume

Expected output:

1file1
2file2

Each key from the ConfigMap appears as a file at /etc/config. The value of each key is the file contents.

ConfigMaps as a volume type

ConfigMaps and Secrets are treated as ephemeral volume types in Kubernetes. They appear in the pod's volumes spec just like any other volume type, alongside emptyDir, hostPath, and PersistentVolumeClaims. The key difference is that their contents come from cluster objects rather than from the node filesystem or a storage backend.

This means you can mix ConfigMap volumes with other volume types in the same pod spec. A pod might mount a ConfigMap for configuration files, a Secret for certificates, and a PersistentVolumeClaim for application data, all in the same volumes section.

One important behaviour: when a ConfigMap is mounted as a volume, Kubernetes updates the files automatically when the ConfigMap changes, typically within 60 seconds. Environment variables set from ConfigMaps at pod startup do not update without a pod restart.