Kubernetes中注入环境变量的核心是实现代码与配置分离，而非依赖Linux命令；需通过Pod YAML声明，支持直接写死value（仅限非敏感调试）、ConfigMap单个注入（精准可控，须同命名空间）或全量注入（键名须合规，不支持过滤）。
在 Kubernetes 中注入环境变量，核心是把配置从容器镜像中剥离，实现“代码与配置分离”。Linux 系统本身不直接参与注入过程——真正起作用的是 Kubernetes 控制平面根据 Pod 或 Deployment 的 YAML 定义，在容器启动时将环境变量写入容器的进程空间。关键不在 Linux 命令，而在如何正确声明和引用。
直接写死 value：仅限调试或公开开关
适合临时验证、CI/CD 流水线标识（如 CI=true）或完全非敏感的开关类参数（如 LOG_LEVEL=debug）：
- name 和 value 都必须显式写出，值原样注入，不解析变量
- 含空格或特殊字符时，YAML 中需加引号，否则解析失败
- 同名变量后定义的会覆盖前一个；也会覆盖镜像中已有的同名 ENV
- 生产环境避免使用——配置难复用、易泄露、无法热更新
通过 ConfigMap 单个注入：精准可控
适用于只取几个关键键值，比如 RUN_ENV、SERVICE_PORT，避免污染环境变量命名空间：
- 在容器 env 列表中使用 valueFrom.configMapKeyRef
- 必须指定 name（ConfigMap 名称）和 key（data 中的键名），大小写和拼写必须完全一致
- ConfigMap 必须与 Pod 在同一 namespace，否则报错 "configmap 'xxx' not found"
- 若 ConfigMap 不存在或 key 缺失，Pod 启动失败（Pending 状态），kubectl describe pod 可看到 config lookup 错误
通过 ConfigMap 全量注入：批量但有约束
用 envFrom.configMapRef.name 引用整个 ConfigMap，所有 data 下的键自动转为环境变量：
- 键名必须符合 Linux 环境变量规范：只能含字母、数字、下划线，且不能以数字开头；不合规的键会被静默跳过，无提示
- 不支持重命名、加前缀或过滤；已有同名环境变量会被覆盖
- 不建议在生产 Deployment 中直接引用未经清洗的 ConfigMap，尤其由外部工具生成时
- 若同时用了 envFrom 引用 ConfigMap 和 Secret，Secret 中同名 key 的值会覆盖 ConfigMap 的值
应用侧读取要注意的细节
环境变量注入成功不等于应用能安全使用：
- os.getenv("KEY") 可能返回 None（ConfigMap key 不存在或引用错误），务必提供默认值：os.getenv("DB_HOST", "localhost")
- 数值型变量（如端口）需显式转换：int(os.getenv("PORT", "8080"))，否则字符串拼接易出错
- 敏感信息（密码、Token）绝不能走 ConfigMap，应使用 Secret，并通过 secretKeyRef 注入
