A ConfigMap consumed as environment variables is updated to fix a bad setting, but the running pods keep behaving as if nothing changed, even hours later. Separately, a colleague is confused that `kubectl get rs` shows two ReplicaSets with nonzero replicas mid-rollout and assumes the deploy is stuck. Explain both, and design the fix for the first one.

Both are the same underlying fact wearing two different faces: a running pod's containers do not get live-reloaded when something they were configured from changes — Kubernetes rolls new pods for a new pod template, and a ConfigMap consumed as environment variables is read once at container start, with nothing watching for later changes, so editing the ConfigMap simply doesn't touch already-running pods regardless of how long you wait. The two-ReplicaSets sighting is the same mechanism from the other direction: a Deployment only creates a new ReplicaSet (and therefore new pods) when the pod template's hash changes, and mid-swap it's normal and correct for both the old and new ReplicaSet to show nonzero replicas as the controller works through the bounds a few pods at a time — it isn't stuck, it's the same incremental machinery that a ConfigMap edit never triggers in the first place, because editing a ConfigMap doesn't change the pod template's hash at all. The fix for the ConfigMap case is making the config change look like a template change: a checksum of the ConfigMap's content in a pod annotation, so a config edit changes the annotation, which changes the template hash, which forces exactly the same incremental ReplicaSet swap a rollout normally does.