Introduction
ConfigMaps mounted as volumes do update automatically, but not in every mount pattern and not always in the way users expect. The two most common surprises are that subPath mounts do not live-update, and that applications often cache configuration at startup even when the file on disk changed. The result is a rollout that appears to ignore ConfigMap updates.
Symptoms
kubectl get configmapshows new content, but the Pod still sees the old file- The mounted file updates only after deleting or restarting the Pod
- A
subPathmount never reflects changes - The application behavior does not change even after the file content updates
Common Causes
- The ConfigMap is mounted with
subPath, which prevents live updates - kubelet refresh timing is slower than the operator expects
- The application reads config once at startup and never reloads the file
- Operators are checking environment variables instead of mounted file content
Step-by-Step Fix
- 1.Check the actual mount style
- 2.Determine whether the Pod uses a full ConfigMap volume or a
subPathmount.
kubectl describe pod my-pod- 1.**Avoid
subPathif live updates are required** - 2.
subPathis convenient for single-file mounts but it does not get the same automatic refresh behavior as a normal projected directory. - 3.Verify the file inside the Pod, not just the ConfigMap object
- 4.Confirm whether the file changed and whether the application noticed it.
kubectl exec my-pod -- cat /etc/config/app.conf- 1.Restart or roll the workload if the application does not reload config dynamically
- 2.Some applications must be restarted even when the mounted file has updated successfully.
kubectl rollout restart deployment/my-deploymentPrevention
- Avoid
subPathmounts when live ConfigMap refresh is a requirement - Design applications to reload config or restart cleanly after config changes
- Verify mounted file behavior during rollout testing, not only the ConfigMap object itself
- Document the expected delay and refresh behavior for your cluster and workload