Why doesn't changing a Kubernetes ConfigMap change my running app?

You apply the ConfigMap, and kubectl says it's configured. The API even returns true for NEW_CHECKOUT. But the app's log line, which is illustrative here, still says false and the legacy flow. The stored data changed, so why didn't the running app notice?

kubectl apply only talks to the API Server, and the API Server stores ConfigMap version two with true. That's where the change ends. Kubernetes doesn't restart Pods for a ConfigMap edit, so the web Pod keeps what it read at start. Whether it ever sees true depends on how the value was delivered.

Take one ConfigMap, app-flags, with NEW_CHECKOUT set to false. Pod A gets it as an environment variable, copied into the process when the container started. Pod B gets it as a file under /etc/flags, and its app read that file. Both begin with false. Let's trace what happens to each.

Here's how the two paths look in the manifest. Pod A uses configMapKeyRef, which copies one key into an environment variable. Pod B declares a configMap volume and mounts it at /etc/flags. The gotcha is subPath: mount a single file with it, and Kubernetes never updates that file.

Follow Pod A. The kubelet reads the flag as false and starts the container with that value in its environment. Then kubectl applies true, and the ConfigMap updates. But the running process never hears about it. Its environment was fixed at startup, and nothing outside can change it. Only a new container picks up true.

Pod B mounts the ConfigMap as a volume, and at startup the app reads false from the file. After kubectl applies true, the kubelet picks it up on its periodic sync, and then swaps the mounted file. That takes a delay, often tens of seconds. The file now says true, but the app still holds false in memory.

A ConfigMap edit changes the stored recipe, not the running process. Environment variables and subPath mounts need a new container to see the change. A volume mount does update, after a delay, but only helps if the app re-reads the file. Delivery method plus app behavior decides everything.

You have three fixes, each with a trade-off. A rollout restart is simple, but it's manual and easy to forget. The checksum annotation in Helm automates it, because a config change alters the Pod template and triggers a rollout. App reload skips restarts, but it needs a volume mount and code.

A ConfigMap edit changes the stored recipe, not the running process. Env vars and subPath need a new container. Volumes update the file eventually, but your app has to re-read it. So check the delivery method before you expect a flag to flip.