场景判断
ConfigMap / Secret 是「集群里的配置对象」，不是运行中进程的热更新总线。通过 envFrom / valueFrom 注入的变量，在容器 create 时由 kubelet 写入进程环境；之后你再 edit ConfigMap，API 对象变了，但已存在的容器不会自动 re-exec。volume 挂载的文件可能被 kubelet 异步刷新（仍有延迟与应用是否重读的问题），而 env 路径几乎总是「不重启就不生效」。把这条因果链记死，能省掉大量「我 apply 了为什么没变」的值班时间。
真实案例骨架：活动前把 APP_MODE 从 prod 改成 debug，get cm 显示新值，客服页面却仍是旧文案——因为 Deployment 的 Pod 还在用启动时的环境。最终 rollout restart（或改 template annotation 触发滚动）后，新 Pod 才 printenv 出新模式。Secret 同理，且更危险：你以为轮换了 token，旧 Pod 仍持有旧 token。
复现步骤
本机勾选备忘（localStorage），不代表你已在集群里跑过，也不连接任何 API。只是帮你对照步骤，别当成「学会了」的勋章。
— / 5本机勾选
- 01
- 02
- 03
- 04
- 05
关键配置
# 基线
kubectl apply -f examples/config/
kubectl get cm app-config -o yaml | grep APP_MODE
kubectl exec deploy/web-config -- printenv | grep APP_
# 改对象 ≠ 改运行中 env
kubectl patch cm app-config --type merge -p '{"data":{"APP_MODE":"debug"}}'
kubectl get cm app-config -o yaml | grep APP_MODE
kubectl exec deploy/web-config -- printenv | grep APP_MODE # 仍旧值
# 让新配置进入新 Pod
kubectl rollout restart deploy/web-config
kubectl rollout status deploy/web-config
kubectl exec deploy/web-config -- printenv | grep APP_MODE # debug
kubectl delete -f examples/config/
get 看见新值只证明 API 对象更新了——进程眼里的世界，仍是启动那一刻的快照。
验收：你能向同事口述「get cm 新、exec 旧」的判断树，并独立完成 patch → 对照 → restart → 再对照。中阶后续发布回滚会继续问你：现在要恢复的是配置，还是 revision？
现场记录
先写自己的证据，再看参考答案。输入只留在当前页面，本站不会读取或验证你的集群。
配置未生效：改 ConfigMap 与 env 惰性
这是你的手动确认，不代表本站已检测命令执行结果。
关联命令
跳转图鉴并展开对应条目（可复制示例）。
对应路径课节