## TL;DR
Pods do not automatically reload ConfigMap changes: mounted volumes update eventually (with a delay), and environment variables never update without a restart. The reliable patterns are a rolling restart after the change, or a reloader tool that watches ConfigMaps and restarts pods for you. Pick one pattern per cluster and make it the default.

## The query
```text
configmap change not picked up by pods: how to force reload
```

## Use this when
- You edited a ConfigMap and the app still uses old values
- Mounted config files in the pod look stale
- You need config changes to roll out predictably
- Choosing between restart-based and watch-based reload

## Not for when
- Rotating secrets (similar but use secret-specific handling)
- Applications that watch their own config files (they handle it)
- First-time ConfigMap creation

## Steps

### Step 1: Identify how the pod consumes the ConfigMap
Check whether the pod uses environment variables (envFrom or valueFrom) or a mounted volume. Env vars are snapshotted at pod start and never refresh; volumes update on the kubelet sync loop with a delay. This determines everything that follows.
Expected output: a clear answer: env-based (needs restart) or volume-based (syncs eventually).

### Step 2: For volume mounts, wait out or shorten the sync delay
Volume updates propagate via the kubelet sync period plus a cache TTL, typically taking up to a couple of minutes. If that delay is acceptable, just wait and verify. Do not restart pods in a panic during the window.
Expected output: updated files appear in the mount without any restart, within the expected delay.

### Step 3: For env vars, trigger a rolling restart
Run a rollout restart on the workload after changing the ConfigMap. This is the simple, predictable pattern: config change, then restart, then verify. Make it a documented two-step in your runbooks.
Expected output: new pods start with the new values; the rollout completes with no downtime.

### Step 4: Automate with a reloader for frequently changed config
If config changes are routine, deploy a reloader controller that watches ConfigMaps and triggers rolling restarts automatically when they change. This removes the human step and the forgotten-restart incidents.
Expected output: editing the ConfigMap alone rolls the workload; nobody has to remember step 3.

### Step 5: Version your ConfigMaps for rollbacks
Instead of editing a ConfigMap in place, create a new versioned ConfigMap and update the workload to reference it. Then a bad config change rolls back with a normal rollout undo.
Expected output: config changes get the same versioning and rollback story as code changes.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_POUDHIGt32PEI4a4hNvMlQ