ConfigMap环境变量注入仅在Pod启动时生效，不支持热更新，适合少量非敏感配置如日志级别、端口等；全量注入用envFrom，单个注入用valueFrom.configMapKeyRef，且ConfigMap须与Pod同命名空间。
在 Kubernetes 中，通过 ConfigMap 向 Pod 注入环境变量是解耦配置与镜像的标准做法。关键不在于“能不能加”，而在于“怎么加更安全、更可控、更易维护”。
明确适用场景：什么情况适合用环境变量注入
ConfigMap 的环境变量注入适合传递少量、结构简单、非敏感的运行时参数，比如日志级别（LOG_LEVEL=debug）、服务端口（SERVICE_PORT=8080）、特征开关（FEATURE_FLAG_CANARY=true）等。它不适合大段配置（如 Nginx 配置文本）或敏感信息（密码、Token 等应交由 Secret 处理）。
两种主流注入方式及写法要点
方式一：单个键值对映射（精准控制）
适用于只取 ConfigMap 中某几个字段，避免污染环境变量命名空间：
- 在容器
env列表中使用valueFrom.configMapKeyRef - 必须指定
name（ConfigMap 名称）和key（对应 data 中的键名） - 若 ConfigMap 不存在或 key 不存在，Pod 启动会失败（默认策略），需提前校验
方式二：全量注入（批量导入）
适用于 ConfigMap 中所有键都需转为环境变量，且命名无冲突风险：
- 使用
envFrom.configMapRef.name直接引用整个 ConfigMap - 所有
data下的键自动成为环境变量名（注意：键名必须符合 Linux 环境变量命名规范，否则会被跳过） - 不支持前缀、重命名或过滤；若已有同名环境变量，会被 ConfigMap 值覆盖（按定义顺序）
实际操作注意事项
ConfigMap 必须与 Pod 在同一命名空间，否则引用无效；更新 ConfigMap 后，已运行的 Pod 不会自动刷新环境变量——环境变量只在容器启动时读取一次，要生效必须重建 Pod（例如滚动更新 Deployment）。
- 创建 ConfigMap 推荐用 YAML 文件（便于 Git 版本管理），而非命令行
kubectl create configmap即时生成 - 避免在 ConfigMap
data中混用大小写或特殊字符的键名，防止因环境变量转换规则导致意外丢失 - 调试时可用
kubectl exec -it检查变量是否注入成功-- env | grep KEY
为什么不推荐大量用环境变量注入？
当配置项超过 10–15 个，YAML 中堆叠的 env 条目会显著降低可读性；某些基础镜像（如 Alpine BusyBox）对环境变量总量有限制；更重要的是，环境变量无法热更新，每次调整都要触发 Pod 重启，影响服务连续性。此时应考虑挂载为文件方式，配合应用自身监听文件变更的机制。
