2.2 K8s 配置管理：ConfigMap、Secret 与健康检查的生产级实践
1. 引言：从硬编码到配置中心
在“石器时代”，开发者喜欢把数据库地址写死在代码里：String url = "jdbc:mysql://192.168.1.100:3306/mydb";
一旦数据库迁移，就要修改代码、重新编译、重新打包、重新发布。这简直是灾难。
后来进化到了“配置文件时代”，我们把配置写在application.properties里。虽然不用改代码了，但每次改配置还得重新打镜像。
Kubernetes 带来了原生配置中心的能力：ConfigMap和Secret。
它们实现了“配置与镜像解耦”——镜像是不变的（Immutable），配置是可插拔的。
本节我们将深入挖掘 K8s 配置管理的各种高级玩法，包括配置热更新、密钥安全管理，以及决定应用生死的健康检查机制。
2. ConfigMap 的核心用法与热更新
ConfigMap (CM)用于存储非敏感的文本配置（如config.ini,nginx.conf,application.yaml）。
2.1 注入方式对比
假设我们有一个game-configConfigMap：
apiVersion:v1kind:ConfigMapmetadata:name:game-configdata:player_lives:"3"ui_properties:|color=blue size=large方式 A：环境变量注入 (Environment Variables)
适合简单的 Key-Value 配置。
env:-name:PLAYER_LIVESvalueFrom:configMapKeyRef:name:game-configkey:player_lives- 优点：简单，符合 12-Factor App 原则。
- 缺点：不支持热更新。修改 ConfigMap 后，Pod 里的环境变量不会变，必须重启 Pod 才能生效。
)
