A ConfigMap supplies configuration, but how a change propagates depends on how it is consumed. A volume-mounted ConfigMap updates its files over time, while an environment variable is fixed for the life of the container, so the same edit has different effects.
Before you start
You should be comfortable with ConfigMaps and Deployments. This article covers update propagation and rollout.
Step-by-step walkthrough
Step 1: Environment variables are fixed per container
A container reads environment variables at start. Updating the ConfigMap does not change a running container’s environment, so the app keeps the old value until the pod restarts. The rollout is the trigger, not the edit.
Step 2: Volume mounts update eventually
A ConfigMap mounted as a volume has its files updated in place, though not instantly: the kubelet syncs periodically. An app that watches or re-reads the file sees the change; an app that read it once at startup does not. Files in a subdirectory mount refresh, while whole-mount behavior can differ.
Step 3: Trigger a rollout deliberately
To apply a config change reliably, roll the Deployment. A common technique is a checksum annotation over the ConfigMap content, so a change alters the pod template and triggers a rolling update. This makes the change intentional and observable instead of relying on a file sync.
Worked scenario
The checksum annotation forces a rollout on config change.
spec:
template:
metadata:
annotations:
config-checksum: "{{ include (print $.Template.BasePath \"/configmap.yaml\") . | sha256sum }}"Walk through the example
When the ConfigMap’s content changes, the checksum in the pod template changes, so the Deployment performs a rolling update and new pods read the new config. Without it, an environment-variable consumer would keep the old value and a volume consumer might use a partially updated state.
Common mistake
Editing a ConfigMap and expecting the running pods to pick it up, especially for environment variables. Another is a volume mount that updates the files, but an app that never re-reads them, so the change has no effect.
Verify the behavior
Mount a ConfigMap as a volume, edit it, and confirm the file updates after a delay. Set a value as an environment variable, edit the ConfigMap, and confirm the variable is unchanged until the pod restarts. Add the checksum annotation and confirm the edit triggers a rollout.
Interview exercise
Why is a ConfigMap volume update not applied instantly?
Answer and reasoning
Because the kubelet syncs mounted ConfigMaps on a periodic interval rather than immediately, so there is a small propagation delay. The files are eventually consistent, and the app must re-read them to notice. For changes that must be applied atomically with the app’s lifecycle, roll the Deployment instead of relying on the sync.
Continue learning
Compare config in ConfigMaps and secrets and rollouts in Deployment rollouts. Read the Kubernetes ConfigMap documentation and try the Kubernetes interview questions.