ConfigMap 和 Secret：配置能热更新，不代表可以随便改

ConfigMap 和 Secret：配置能热更新，不代表可以随便改

Kubernetes 让配置管理变得方便，ConfigMap 和 Secret 一改，服务就能读取新配置。但方便不等于随便。AI 后端里模型路由、Prompt 模板、安全阈值、限流策略都可能放在配置里，改错一次就会影响线上行为。

配置也是发布。它需要版本、审查、回滚和观测。不要因为它不是代码，就绕过工程纪律。

一、先区分配置类型

配置可以分成普通配置、敏感配置、策略配置和实验配置。不同类型的变更风险不同。

flowchart TD A[配置] --> B[普通配置] A --> C[敏感配置 Secret] A --> D[策略配置] A --> E[实验配置] D --> F[需要审查和灰度] C --> G[需要加密和轮换]

模型安全阈值、限流额度、路由比例属于策略配置，不能像改日志级别一样随意。

二、配置要有校验

服务启动或热加载时，应校验配置格式和范围。错误配置宁可拒绝加载，也不要带着未知状态运行。

type ModelPolicy struct { TimeoutMs int `yaml:"timeout_ms"` MaxTokens int `yaml:"max_tokens"` } func (p ModelPolicy) Validate() error { if p.TimeoutMs < 1000 || p.TimeoutMs > 120000 { return fmt.Errorf("timeout_ms out of range") } if p.MaxTokens <= 0 || p.MaxTokens > 8192 { return fmt.Errorf("max_tokens out of range") } return nil }

配置校验是基础设施的刹车。没有刹车的热更新，只是更快把错误送到线上。

三、Secret 要有轮换计划

模型 API Key、数据库密码、Webhook 密钥都应放 Secret，并且有轮换机制。轮换时服务要支持新旧密钥短时间并存，避免瞬间切断。

secret_rotation: phase_1: add_new_key phase_2: deploy_services_accept_both phase_3: switch_outbound_to_new phase_4: revoke_old_key

Secret 不应该出现在日志、错误信息和前端环境变量里。这个要求很基础，但事故里经常出现。

四、配置变更要能追责

谁改了配置，为什么改，影响范围是什么，什么时候回滚，这些都要可查。GitOps 是不错的方式：配置进仓库，走 PR，自动同步。

配置变更后，也要观察关键指标。比如限流阈值调低后，拒绝率是否上涨；模型路由调整后，成本和延迟是否变化。

配置还需要分环境。开发、预发、生产可以共享结构，但不要共享值。尤其是模型 Key、回调地址、限流额度和实验开关，环境隔离能挡住很多误操作。

config_environments: dev: model_timeout_ms: 30000 quota_per_minute: 20 prod: model_timeout_ms: 15000 quota_per_minute: 1000

最后，热更新要有回滚。服务加载新配置后如果错误率上升，应能快速回到上一版本。配置中心保存历史版本，比临时在群里找旧值靠谱得多。

五、总结

ConfigMap 和 Secret 让配置管理更方便，但配置仍然是发布。区分配置类型，做格式校验，规划 Secret 轮换，记录变更和回滚。

能热更新是能力，知道哪些配置不能随便改是工程判断。