Kubernetes 里 ConfigMap 改了但 Pod 没生效，四个容易被忽略的原因

改完 ConfigMap 直接等 Pod 自动更新，是很多人踩过的坑。ConfigMap 以卷方式挂载时确实会自动同步，但进程读的还是启动时那份；以环境变量注入时根本不会更新。下面按排查顺序列四个原因。

一、用环境变量注入的，永远不会热更新

envFrom / valueFrom.configMapKeyRef 只在容器启动时求值一次。改完 ConfigMap，Pod 里进程看到的还是旧值，必须重建 Pod（kubectl rollout restart deploy/xxx）。这是最常见的一条，很多人看到"改了没生效"其实是注入方式决定的。

二、卷挂载有同步延迟，且不是立刻

kubelet 的 sync period 默认 1 分钟，叠加 ConfigMap 的 watch 缓存，实际生效通常在 1~2 分钟内。更要注意：通过 subPath 挂载的单个文件，官方明确说明不会更新。如果只挂了某个 key 到指定路径，改这个 key 是永远不会变的。

三、应用自己不重读文件

就算文件已经变成新的，进程内存里的配置还是旧的。要么进程自己监听文件变化（如 fsnotify / Spring Cloud 的 refresh），要么发信号让它 reload。文件更新 ≠ 应用生效，这一段经常被跳过。

四、看错了对象

同名 ConfigMap 在不同 namespace 是两份；改了 default 里的，Pod 跑在 prod 里当然没反应。另外 Deployment 引用的是名字，改了 ConfigMap 名字但没改 Deployment 引用，等于没改。

排查建议按这个顺序：kubectl exec 进 Pod 看文件内容是否已是新的 → 是则问题在应用重载 → 否则看挂载方式（subPath / 环境变量）→ 最后核对 namespace 和引用名。

一句话总结：先确认文件变了没，再确认进程读了没。