ConfigMap 已修改，Pod 环境变量仍是旧值：更新不会自动替换进程环境

ConfigMap 已更新，Deployment 的应用却继续使用旧配置。如果容器通过 env 的 configMapKeyRef 或 envFrom 读取值，运行中的进程环境不会随 ConfigMap 变化自动更新。更新对象和替换使用它的 Pod 是两步。

先确认应用读取的是环境变量还是挂载文件。文件投影有自己的更新机制，而且应用还需要重新读取文件；不能把“ConfigMap 会更新”理解成所有消费方式都能热更新。

检查正在运行的 Pod 如何引用配置

以下是只读检查示例，替换命名空间和对象名，配置内容应在受控终端查看：

kubectl -n app get deployment web -o yaml
kubectl -n app get configmap web-config
kubectl -n app get pods

在实际模板中查 env、envFrom、引用名称及键。确认更新的是同一命名空间的同一个 ConfigMap，再检查 Pod 是否仍来自修改前的模板。不要为了比对配置输出整个进程环境，它可能包含其他敏感字段。

如果某些新 Pod 已使用新值，而旧 Pod 仍保留旧值，往往是扩容或其他事件创建了新的容器，而既有 Pod 没有被替换。只看一个副本的日志容易误以为更新全部生效。

通过受控 rollout 替换旧 Pod

应用可以接受 Pod 替换、且新配置已检查时，可对原 Deployment 发起滚动更新。以下是变更示例：

kubectl -n app rollout restart deployment web
kubectl -n app rollout status deployment web

第一条会触发新的 Pod，不是修改旧进程的环境；第二条观察部署更新是否完成。执行前核对副本、更新策略、就绪检查、可用容量及应用停机影响。单副本或缺少就绪判断时，不能把滚动更新当作无中断保证。

新 Pod 会在启动时读取当时的 ConfigMap 内容。若继续改同一个配置对象，更新途中不同 Pod 仍可能读取不同版本。需要一致交付时，可以采用带版本名称的 ConfigMap，并在 Pod 模板中引用目标版本，通过既有部署流程一起发布。

使用 Helm、Operator 或 GitOps 时，应修改它们实际管理的配置与模板。临时执行 restart 能让当前值生效，但不替代配置在原管理入口中的保存，也不保证下一次同步不会覆盖它。

rollout undo 不会恢复同名 ConfigMap 的旧数据

变更前保存原配置内容及引用关系。Deployment 修订保存的是模板，不会替你保存每次编辑同名 ConfigMap 的历史。因此仅回滚 Deployment，可能让重新创建的 Pod 仍读取已经改过的配置。

若使用版本化 ConfigMap，保留旧对象，回退时恢复模板中的旧引用；若原地修改了同名对象，应先恢复它的正确旧内容，再安排受控 Pod 替换。不能先删掉 ConfigMap 再临时重建，其他引用者可能正在启动或挂载它。

真正需要热更新，应用必须支持它

采用目录挂载的 ConfigMap 时，kubelet 会按自己的同步与缓存机制更新文件，存在传播延迟；应用如果只在启动时读取一次，仍不会自动改变行为。通过 subPath 挂载也不会接收自动更新。

要避免 Pod 替换，需要应用明确支持读取更新后的文件、校验内容并应用新设置。改成卷挂载本身不等于获得热更新；无法热加载的配置仍应通过重启或重新部署按设计生效。

验收应核对所有目标副本对应的配置版本，以及应用实际行为，而不是只确认 ConfigMap 的更新时间变化。更新失败时保留仍可用的副本，恢复已保存的配置与引用，再检查恢复后的新 Pod。配置已保存、Pod 已替换和业务已采用新值，应分别确认。