How mounted ConfigMap updates propagate to pods

WHAT THIS TESTS Whether you know that Kubernetes updating the file on disk is separate from your application using the new value, and the timing and exceptions involved.

A GOOD ANSWER COVERS When a ConfigMap is mounted as a volume, the kubelet watches it and periodically reconciles the projected files. Propagation is not instant: the kubelet syncs on its periodic cycle, and there is additional delay from the local watch or cache, so a change typically appears in the pod within roughly a minute, on the order of the kubelet sync period plus cache TTL. The update is applied atomically: the volume is a directory of symlinks pointing at a timestamped data directory, and the kubelet creates a new directory and swaps the symlink so readers never see a half-written file. Crucially, the running application does not automatically notice. The files on disk change, but the process keeps using whatever it loaded at startup unless it actively watches the files for changes, for example with inotify or a config library, or is told to reload via a SIGHUP or a sidecar that triggers a reload. Two important exceptions: a ConfigMap mounted with a subPath does not receive updates and needs a pod restart, and values injected as environment variables are read only at container start and never update live.

COMMON WRONG ANSWERS Saying the application automatically picks up new values; only the files change, not the loaded config. Claiming updates are instantaneous. Forgetting that subPath mounts and env-var references do not update without a restart. Believing a rolling restart is always required, when a watch-and-reload app avoids it.

LIKELY FOLLOW-UPS How do tools like Reloader trigger a rollout on ConfigMap change? Why does subPath behave differently? How do immutable ConfigMaps and checksum annotations fit a deliberate-rollout strategy? What is the atomic symlink swap protecting against?

ONE CONCRETE EXAMPLE An nginx pod mounts its config from a ConfigMap volume. You edit the ConfigMap; about a minute later the file on disk shows the new server block thanks to the kubelet's atomic symlink swap. But nginx keeps serving the old config until you send it a reload signal. Teams often add a sidecar or a Reloader annotation that detects the change and triggers nginx -s reload or a rolling restart so the new config takes effect.