这是《Docker 与 Kubernetes 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。 ConfigMap 管理普通配置，Secret 管理敏感数据。它们把镜像和配置解耦，但都不是完整的密钥管理系统。
13.1 ConfigMap
apiVersion: v1
kind: ConfigMap
metadata:
name: order-config
data:
application.yaml: |
server:
port: 8080
logging:
level:
root: INFO
APP_ENV: prod
使用环境变量：
env:
- name: APP_ENV
valueFrom:
configMapKeyRef:
name: order-config
key: APP_ENV
挂载文件：
volumeMounts:
- name: config
mountPath: /etc/app
volumes:
- name: config
configMap:
name: order-config
13.2 Secret
kubectl create secret generic db-secret \
--from-literal=username=app \
--from-literal=password='strong-password'
使用：
env:
- name: DB_PASSWORD
valueFrom:
secretKeyRef:
name: db-secret
key: password
Secret 默认只是 base64 编码，必须配合 RBAC、etcd 加密、磁盘权限和网络隔离。
13.3 配置更新
| 注入方式 | 更新行为 |
|---|---|
| env | Pod 启动后通常不更新 |
| volume | kubelet 周期同步 |
| subPath | 通常不会自动更新 |
配置变更是否生效还取决于应用是否支持热加载。常见策略是滚动重启：
kubectl rollout restart deployment/order-service
13.4 immutable
apiVersion: v1
kind: ConfigMap
metadata:
name: app-config
immutable: true
data:
APP_MODE: readonly
不可变配置可以降低 kubelet 监控成本，修改需替换对象。
13.5 管理
kubectl get configmap
kubectl get secret
kubectl describe configmap order-config
生产建议：
- Secret 独立权限；
- 大配置拆分；
- 变更走 GitOps；
- 不把 Secret 提交 Git；
- 使用外部密钥系统或 CSI Secret Store；
- 审计访问。
本章小结
ConfigMap 和 Secret 把配置从镜像中拆出来。环境变量适合简单配置，卷挂载适合文件；敏感数据要结合加密、RBAC、审计和外部密钥管理。
思考题
- ConfigMap 和 Secret 的边界是什么？
- 环境变量注入后能否热更新？
- subPath 挂载为什么更新异常？
- Secret 默认安全吗？
- 如何设计配置变更流程？