改了 ConfigMap 的环境变量 Pod 里 printenv 还是旧值

ConfigMap 里 LOG_LEVEL 从 info 改成 debug，kubectl exec 进 Pod 执行 printenv 还是 info，重启进程也没用。乍看像缓存或者权限的锅，追下去往往不是。

kubectl rollout restart deploy/api
kubectl exec api-5d8c7b6f4-2nq9x -- printenv LOG_LEVEL
kubectl get cm app-config -o yaml | grep LOG_LEVEL

追下去是这么回事：env 引用 ConfigMap 只在容器创建时解析一次，之后 ConfigMap 更新不会回写进程环境。改了对象不等于改了已经运行的容器。

「ConfigMap 环境变量未更新」相关的日志我一般连着看前后五分钟，单看一条报错经常判断不出是哪一步失败。测试环境和线上的差别，往往就在版本号和那几行被忽略的配置上。

线上出问题先对时间点，跟发布、备份、任务执行的时刻排一排，能省掉一半功夫。日志级别临时调高可以，记得改回去，长期开着既占磁盘又掩盖真问题。

权限不要一口气开到最大，先加到够用再往上试，范围小才好收。

具体做法是，确认 Pod 的 env 是 valueFrom 还是 envFrom 两者都在创建时固化；用 kubectl rollout restart 重建 Pod 不要只重启进程；给 Pod 模板加 checksum 注解 配置变更自动触发发布；需要热更新的配置改成挂载文件 让应用自己监听。

验收就看一点，重建后 printenv 输出 debug Deployment 的 generation 增加 1。