when Pods have ConfigMaps mounted, a change to the ConfigMap doesn't necessarily trigger a new Pod to run; ConfigMaps are considered immutable over the lifetime of the Pod that mounts them.
https://www.tuanh.net/blog/devops/your-kubernetes-pods-dont-restart-automatically-after-configmap-updates-and-how-to-fix-it
There's a pattern we use whereby we calculate the hash of the configmap and put it as a label or annotation on the deployment pod's spec; that way the update to the configmap computes to a new hash and that triggers the creation of a new pod