2.2 K8s 配置管理：ConfigMap、Secret 与健康检查的生产级实践

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 才能生效。