行为定位
更新 ConfigMap 之后配置会不会生效，取决于注入方式：卷挂载（非 subPath）会被 kubelet 分钟级同步到容器内文件，应用需要自行重读；环境变量注入完全不会更新，必须重建 Pod；subPath 挂载同样不更新；immutable 的 ConfigMap 甚至禁止修改。适用平台是 Kubernetes。这三条规则覆盖了绝大多数「改了配置没反应」的现场。
基本信息
| 适用平台 | Kubernetes，ConfigMap 为命名空间级对象 |
|---|---|
| 卷挂载传播 | 默认分钟级（受 kubelet 同步周期与缓存 TTL 影响） |
| env 注入 | 容器创建时读取一次，运行中不更新 |
| immutable 限制 | spec.immutable=true 后禁止修改键值，只能删除重建 |
典型使用场景
- 修改业务配置后验证生效路径：确认是卷还是 env，决定要不要重启
- 排查「配置改了没反应」：优先检查是否用了 subPath 挂载
- 证书与白名单轮换：靠卷挂载同步，再配合应用重载机制
- 发布流程设计：把配置变更与 Pod 重建绑定，避免灰度期间新旧混用
- 审计配置历史：immutable 场景用版本化命名，避免误改线上配置
更新与观察
更新与观察
kubectl create cm app-config --from-literal=LOG_LEVEL=debug --dry-run=client -o yaml | kubectl apply -f -
kubectl exec -it web-x -- cat /etc/app/conf.d/log-level.txt # 卷挂载：等 1 分钟左右再执行
kubectl exec -it web-x -- printenv LOG_LEVEL # env 注入的：仍是旧值
kubectl rollout restart deploy/web # 需要新值时触发一次滚动更新
kubectl get cm app-config -o jsonpath='{.immutable}' # 是否不可变
kubectl rollout status deploy/web注入方式与传播
| 配置方式 | 更新是否传播 | 应用侧动作 |
|---|---|---|
| 环境变量（env/envFrom） | 不传播 | 重建 Pod 才能拿到新值 |
| 卷挂载（普通） | 分钟级传播 | 应用需要重读文件或热加载 |
| 卷 + subPath | 不传播 | 重建 Pod |
| immutable: true | 禁止更新 | 只能删除重建 |
kubelet 同步周期与缓存 TTL 决定传播延迟（常见约 1 分钟内），对时效敏感用 rollout restart 或应用层热加载。
卷挂载的原理是切换符号链接，进程若一直持有文件句柄，读到的仍是旧内容，需要应用重新打开文件。
改配置的标准做法
- 先确认注入方式：env、普通卷、subPath 三种路径的生效行为完全不同，方案从这里分叉
- 需要立即生效时统一用 rollout restart，把配置版本与副本版本对应起来，便于回滚
- 能热加载的应用显式配置重载触发（如 SIGHUP 或管理端点），避免无谓重建
- 改完立刻验证：打印容器内文件内容或环境变量，比看 ConfigMap 对象更接近真实效果