ConfigMap 文件与环境变量有不同生命周期
修改 ConfigMap 首先改变的是 API 对象。运行中的应用是否改变行为，还取决于 Kubernetes 如何交付数据，以及应用如何读取它。环境变量注入、普通卷投射、subPath 挂载和已经打开的文件，分别拥有不同生命周期。排查时应找到真正影响业务的消费者，而不是把所有配置传递方式都看成同一种机制。 原文保留示例中的五类交付生命周期。文件刷新不证明应用已经采用配置。本轮集成验证仍受阻，未重跑示例，也未建立通用传播时限。 区分交付与消费 容器环境中的 ConfigMap 引用会在容器启动时解析。更新对象不会重写已有进程的环境，也不会改写同一容器后续 exec 进程所使用的配置环境。替换 Pod 并引用所需版本，可以建立新的环境快照，但这属于生命周期动作，不是修改 data 字段之后自然发生的结果。配置变更记录与进程替换记录应能够对应。 普通 ConfigMap 卷则不同，kubelet 可以在之后把新数据投射进去。延迟受到同步周期和变更发现策略影响，因此 API 修改成功与文件发生变化不是同时发生的事件。投射更新也不会自动调用应用的重新加载函数。只在启动时解析一次配置的程序，即使文件已经变化，也可能一直使用先前读入的值。 打开文件描述引用的是已经打开的文件，而不是每次都重新解析原路径。路径背后的文件被替换，不会迫使旧描述符自动跟随新文件。因此，关闭并重新打开投射路径的进程可能读取新内容，另一个保留的描述符却仍读取旧文件。即使文件系统视图已经刷新，应用自己的缓存还可能再增加一层滞后。 把投射内容复制到可写位置，又会创建一个独立快照。副本不是指向 ConfigMap 的实时链接。如果启动脚本采用这种复制方式，更新这个副本也需要单独实现，不能期待源文件变化自动传播到另一份普通文件。 ...