Volume-mounted ConfigMaps update (slowly, and only for some subPath cases); envFrom/Env vars NEVER update. Know the mechanism your app uses and the answer changes.
envFrom/env values are captured at container start — changing the ConfigMap does nothing for running pods. Restart required, by design.
Volume-mounted ConfigMaps sync eventually (up to ~a minute + kubelet sync period), BUT subPath mounts never update. Apps that read the file once at startup also never see changes.
kubectl exec <pod> -- cat /etc/config/app.conf | head -5 ; kubectl get configmap <cm> -o yaml | head -10
kubectl rollout restart deployment <app> # the honest fix for envFrom
kubectl get pod <pod> -o jsonpath='{.spec.volumes[*].configMap}' | python3 -m json.tool
# spec.template.metadata.annotations: configmap/checksum: {{ include (print .Values.configMap) . | sha256sum }} — helm/argo pattern: change config → new pod hash → rollout
Immutable ConfigMaps (immutable: true) exist to stop the sync cost entirely — good for config that never changes in place. The checksum annotation is the standard helm pattern; with plain manifests, pair ConfigMap bumps with rollout restart in your deploy pipeline.
Only volume-mounted ones, eventually, and not through subPath — never env-var injections. If your app reads config once at boot, even a synced file won't help: restart on change regardless.
Treat config as part of the release: bump the ConfigMap and rollout restart in one step (or the checksum-annotation pattern so the rollout triggers automatically). Consistent and observable.
Kustomize base with probes, PDBs, and zero-downtime rollouts already wired.
Kubernetes Production Blueprints — $27 →One-time. Yours to modify. Instant download from the NinjaOps template store.