A pod doesn't pick up a ConfigMap change after it's updated — why, and how would you make the app actually reload it?

For a volume-mounted ConfigMap, the file on disk inside the container does eventually update automatically (via the kubelet's periodic sync, typically within about a minute) — but the application itself has to notice the file changed and reload it, which most applications don't do on their own without an explicit file-watch mechanism. If the ConfigMap is instead consumed via subPath, the file never updates at all until the pod restarts, which is a separate, harder limitation.

Volume-mounted ConfigMaps do update on disk, just not instantly: the kubelet periodically re-syncs mounted ConfigMap/Secret volumes (governed by the kubelet's sync period, plus a cache propagation delay), so the file content inside the container's mounted volume genuinely does change — but this can take up to roughly a minute, and it's easy to check too soon and conclude nothing happened.

The more common actual cause: the application never re-reads the file: most applications read configuration once at startup and hold it in memory — updating the file on disk doesn't make the running process notice, unless the application specifically implements file-watching (inotify-based reload, or a periodic re-read) or is explicitly signaled to reload. This is an application-level gap, not a Kubernetes bug.

subPath mounts are a separate, harder limitation: when a ConfigMap key is mounted using subPath (common when you want a ConfigMap key to appear as a specific file alongside other files in a directory, rather than the ConfigMap owning the whole directory), Kubernetes does not propagate updates to that file at all — the content is copied in at pod creation and never refreshed until the pod is recreated, regardless of how long you wait. This is a well-documented, deliberate limitation of how subPath works, not a bug.

Environment-variable-sourced config never updates without a restart, regardless of mount method: if the ConfigMap's values are injected as environment variables (envFrom or individual env entries with configMapKeyRef), those are resolved once at pod creation time — there's no mechanism at all for a running process's environment variables to change after the process starts, so this path always requires a pod restart to pick up new values.

Solutions depend on which of these applies: for a genuinely watch-capable application with a plain volume mount, no special action is needed — just wait for the kubelet's sync and let the app's own file-watcher notice; for an application that doesn't watch files, or a subPath mount, or env-var-sourced config, the practical fix is triggering a pod restart when the ConfigMap changes — commonly done via a checksum annotation on the pod template (computed from the ConfigMap's content) that changes whenever the ConfigMap does, triggering a rolling update, or a dedicated tool that watches ConfigMaps and restarts dependent Deployments automatically.

• Volume-mounted ConfigMaps do update on disk automatically, but with real propagation delay (up to about a minute) — check timing before assuming it's broken.
• The application itself usually needs explicit file-watching logic to notice and reload an updated file; most applications don't do this by default.
• subPath mounts never update automatically at all, regardless of how long you wait — this requires a pod restart unconditionally.
• Environment-variable-sourced config is always resolved once at pod start and never updates without a restart, independent of the ConfigMap mount method.

• Kubernetes: ConfigMaps — Mounted ConfigMaps are updated automatically