ConfigMap 适合存非敏感配置如数据库地址、超时时间、日志级别；Secret 用于密码、token、私钥等需加密字段，但仅 base64 编码，真正安全需启用 etcd 加密或集成 Vault 等外部密钥服务。
ConfigMap 和 Secret 怎么选，什么时候该上配置中心
ConfigMap 适合存数据库地址、超时时间、日志级别等非敏感配置；Secret 专用于密码、token、私钥等必须加密的字段——但注意：Secret 只是 base64 编码，不是加密，真正安全需配合 etcd 加密启用或 Vault 等外部密钥服务。
当你的服务数
- 硬编码
DB_HOST或在 Deployment 中写死value: "192.168.1.100"→ 必须改镜像重部署，违反十二要素原则 - 把所有环境变量塞进一个
config.yaml并提交到代码库 → 敏感信息泄露风险极高 - 用 ConfigMap 挂载文件后，应用不监听变更 → 配置更新后 Pod 仍读旧值，造成“已更新但未生效”假象
配置即代码（GitOps）怎么落地才不翻车
不是把 YAML 往 Git 里一扔就叫配置即代码。关键在结构化 + 自动化同步。推荐采用分层目录结构：
config-repo/ ├── base/ # 公共字段：service.name, logging.level ├── dev/ # 覆盖 base：database.url → "localhost:5432" ├── staging/ # 同名字段覆盖，加灰度开关：feature.flag.canary: true └── production/ # 加密字段留空，由 CI 注入 Secret 引用
这样做的好处是：同一份 base 被所有环境复用，避免重复定义；CI 流水线用 kustomize build staging 即可生成对应环境完整 manifest。
- 禁止在不同环境分支（如
prod/staging）中维护独立 YAML —— 分支合并极易冲突，且无法保证字段一致性 - 不要用
envFrom: configMapRef一次性注入全部键值 —— 一旦 ConfigMap 多了个调试字段，可能意外覆盖应用内部默认值 - Git 提交配置前，务必用
conftest test或datree扫描合规性（比如检查是否漏了resources.limits或误写了明文password）
配置热更新为什么失败？应用层要做什么
Kubernetes 的 ConfigMap 更新后，挂载的卷内容确实会变（Linux 下是 inotify 事件），但绝大多数语言运行时不会自动 reload。Java Spring Boot 默认不监听文件变化；Go 的 viper.WatchConfig() 需手动调用；Python 的 configparser 更是纯静态读取。
正确做法分两层：K8s 层用 subPath 挂载单个文件（避免整个目录 reload 触发重启），应用层主动监听或定期轮询。例如：
volumeMounts: - name: app-config mountPath: /etc/app/config.yaml subPath: config.yaml # 关键：只挂单个文件，不触发 Pod 重建
- Spring Cloud Config 客户端需加
@RefreshScope注解，并调用/actuator/refresh端点 - Go 项目建议用
fsnotify监听文件变更，再触发viper.ReadInConfig() - Node.js 可用
chokidar+require.cache清理后重载模块，但要注意全局状态污染
配置中心选型：Consul/Vault/Nacos/Apollo 怎么取舍
Consul 适合已有 HashiCorp 技术栈、强依赖服务发现的场景，但原生不支持配置回滚和审计日志；Vault 是密钥管理王者，但做通用配置太重，学习成本高；Nacos 和 Apollo 更贴近国内落地需求：Nacos 支持 K8s 原生集成和 DNS 服务发现，Apollo 提供完善的 UI、灰度发布、配置对比和生效追踪。
真实踩坑点在于客户端耦合——别让业务代码直接调 apollo-client 的 getConfig()，应封装成统一配置门面（如 conf.Get("db.timeout")），内部按环境自动路由到 Consul 或 Apollo，未来切换成本才低。
- 用 Nacos 时，
nacos.client.config.auto-refresh默认为 false，不打开就收不到推送 - Apollo 的 namespace 设计易混淆：
application是公共配置，自定义 namespace 如redis-dev需显式初始化ConfigService.getConfig("redis-dev") - 所有配置中心都面临网络分区问题：客户端断连时，必须 fallback 到本地缓存配置（如
/data/apollo/cache），否则启动直接失败
配置管理最难的从来不是工具选型，而是组织层面的规范落地：谁有权限改生产配置？配置变更是否强制关联工单？测试环境配置能否一键同步到预发？这些流程没对齐，再好的技术方案也会在上线前最后一刻崩掉。
