01
Identify the consumption mechanism
Inspect the workload’s Pod template for env, envFrom, volume mounts, or an application-specific configuration client. The same ConfigMap can be consumed through different paths with different update behavior.
Our lab used configMapKeyRef to set MODE in the process environment. The application started with old. Changing the ConfigMap’s API value to new left that already running process with old, which was the expected behavior of this injection method.
kubectl -n your-namespace get deployment your-deployment -o yaml
kubectl -n your-namespace get configmap app-settings -o yaml02
Compare a non-sensitive key at both ends
Verify the namespace, ConfigMap name, and exact key referenced by the live template. Then inspect only the relevant non-sensitive setting in the running application. Avoid dumping the entire process environment because unrelated entries may contain credentials.
For the Python test container, the command below reads MODE specifically. A real application may have a safer configuration-status endpoint or its own diagnostic command. Use the mechanism appropriate to that application.
# Example assumes a Python container and a non-sensitive MODE setting.
kubectl -n your-namespace exec your-pod -c app -- \
python -c 'import os; print(os.environ.get("MODE", "unset"))'
kubectl -n your-namespace get configmap app-settings \
-o jsonpath='{.data.MODE}'03
Make the container reference explicit
The fragment below shows the environment reference used in the test. The referenced ConfigMap must be available in the Pod’s namespace. Editing only the ConfigMap does not change this Pod template or automatically create a new Deployment revision.
If a release system deliberately versions ConfigMap names or records a configuration checksum in the template, use that system’s normal rollout mechanism. Do not add a second ad hoc replacement process that competes with the existing delivery controller.
env:
- name: MODE
valueFrom:
configMapKeyRef:
name: app-settings
key: MODE04
Roll out the intended configuration safely
After confirming the ConfigMap update, trigger the approved workload replacement. For a manually managed Deployment, rollout restart is one available mechanism. Review replica availability, disruption requirements, and any stateful behavior before restarting production workloads.
In the isolated test, the API value and old process environment diverged until the Deployment restarted. Once rollout completed, the replacement process reported new. The observed change was at container startup, not a live mutation of the old process environment.
kubectl -n your-namespace rollout restart deployment/your-deployment
kubectl -n your-namespace rollout status deployment/your-deployment05
Verify the application rather than only the object
Check the new Pod identity, the relevant effective setting, and the behavior the setting controls. A ConfigMap with the right text is only configuration evidence. A completed rollout can still start the wrong image or reference the wrong key.
Mounted ConfigMap files have different propagation and subPath behavior, and the application must still reload changed files if that is its design. Diagnose that path separately instead of applying the environment-variable explanation to every configuration update.
Know the limits
Reproduced on Kubernetes v1.32.2 with a one-replica Deployment reading the non-sensitive MODE key through configMapKeyRef. This experiment covers environment variables, not projected-volume propagation or application hot reload.
Sources & further reading
A technical publication by CoreTrailKit.
Browse all articles