K8s 配置热更新：配置变了，应用不一定真的生效
一、配置更新不是自动魔法
K8s ConfigMap 和 Secret 很方便，但很多人误以为配置改了，应用就会立刻使用新值。实际上，环境变量注入的配置不会自动变化，挂载文件可能更新但应用未必监听，业务代码也可能缓存旧值。
配置变了，应用不一定真的生效。
二、先区分配置来源
flowchart TD A[K8s 配置] --> B[环境变量] A --> C[挂载文件] A --> D[配置中心] A --> E[启动参数]不同来源的更新语义不同。环境变量适合启动时配置，动态开关更适合配置中心或挂载文件监听。
env: - name: FEATURE_FLAG valueFrom: configMapKeyRef: name: app-config key: feature_flag这类环境变量在 Pod 启动后不会自动刷新。
三、热更新要有应用支持
如果使用挂载文件，K8s 会更新文件内容，但应用需要监听文件变化并重新加载。重新加载还要校验配置合法性，不能把坏配置直接生效。
void reload(Config next) { validate(next); currentConfig.set(next); }加载失败时应该保留旧配置，并打告警。配置热更新最怕坏配置把服务全量打挂。
四、滚动重启仍然是可靠方案
很多核心配置不适合热更新，例如数据库连接、线程池大小、安全策略、序列化协议。对这些配置，滚动重启更可控。
config_change_policy: feature_flag: hot_reload datasource: rolling_restart thread_pool: rolling_restart log_level: hot_reload配置变更要有策略分类，不要所有配置都追求热更新。
最后，配置生效要可观测。应用启动或刷新后暴露当前配置版本、加载时间和来源，排查时才能知道服务到底用的是哪版配置。
还要防止配置漂移。同一批 Pod 里，有的已经加载新配置，有的仍使用旧配置，短时间内行为不一致。对于关键配置，要通过版本号和指标确认全量实例都完成切换。
config_observability: expose_config_version: true count_pods_by_version: true alert_on_mixed_version: optionalSecret 热更新更要谨慎。证书、数据库密码、第三方密钥更新时，连接池和客户端 SDK 是否能重新建立连接，需要单独验证。文件变了，不代表已有连接已经换新凭据。
最后，配置回滚要和发布回滚一样设计。坏配置导致异常时，能快速恢复旧版本，并确认所有实例重新加载成功。
动态配置还要做灰度。先让少量实例或少量租户加载新配置，观察错误率和核心指标，再扩大范围。配置变更如果直接全量生效，风险和直接发布代码没有区别。
config_rollout: scope: tenant_or_instance steps: [5, 25, 100] auto_pause_on_error: true配置项本身也要有类型和范围校验。线程池大小不能是负数，超时时间不能随便写成 0，开关组合不能互相冲突。把校验放在生效前，而不是故障后排查。
最后，配置文档要说明是否热更新。使用者知道改完需要滚动重启，才不会误以为配置中心保存成功就代表线上行为已经改变。
五、总结
K8s 配置热更新要区分环境变量、挂载文件和配置中心，并要求应用支持校验、回退和生效观测。
配置变了，不代表应用真的生效。可控的配置变更，比追求实时更重要。
