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_keySecret 不应该出现在日志、错误信息和前端环境变量里。这个要求很基础但事故里经常出现。四、配置变更要能追责谁改了配置为什么改影响范围是什么什么时候回滚这些都要可查。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 轮换记录变更和回滚。能热更新是能力知道哪些配置不能随便改是工程判断。