Pod注入环境变量最常用可靠方式是直接在YAML中配置env或envFrom字段；env适用于少量固定值，envFrom可批量注入ConfigMap/Secret，downwardAPI用于传递Pod元信息，initContainer适合复杂逻辑预生成配置文件。
Pod YAML 中直接写 env 字段最常用也最可靠
绝大多数场景下，往 Pod 注入环境变量，就是改 env 或 envFrom 字段。Kubernetes 不会“读取 Go 程序里的 os.Setenv”，它只认你提交的 Pod spec。Go 应用本身只需像平常一样调用 os.Getenv 读取即可。
常见错误是试图在 Go 启动时动态生成环境变量再 patch Pod —— 这不仅复杂、有竞态，还绕过了声明式管理原则。
-
env适合注入少量确定值，比如APP_ENV=prod、LOG_LEVEL=info -
envFrom更适合批量注入 ConfigMap 或 Secret，例如把整个app-configConfigMap 的 key 全转成环境变量 - 注意：ConfigMap/Secret 中的键名必须符合 DNS-1123 标准（小写字母、数字、连字符），否则字段会被跳过且无报错
用 downwardAPI 注入 Pod 自身元信息
当你要传的是 Pod 名、Namespace、IP 这类运行时才知道的信息，不能硬编码，就得靠 downwardAPI。Go 程序照常读 os.Getenv，但 YAML 里得写清楚字段路径。
典型例子：让服务启动时自动注册自己为 ${POD_NAME}.${NAMESPACE}.svc.cluster.local。
立即学习“go语言免费学习笔记（深入）”；
- 必须用
fieldRef.fieldPath指定路径，比如metadata.name、status.podIP -
status.podIP在 Pod 还没分配 IP 时为空，Go 程序需容忍短暂空值或加重试逻辑 - 不支持注入 labels 或 annotations 的任意字段，仅限
metadata和status下明确列出的子路径
initContainer 预生成环境配置文件再挂载
如果环境变量逻辑复杂（比如要拼接多个 Secret + ConfigMap + 下沉字段 + 时间戳），YAML 写不出来，就用 initContainer 生成一个 /etc/app/env.sh 或 .env 文件，主容器通过 volumeMounts 挂载并 source 它。
Go 程序不用改，仍用 os.Getenv；但启动命令得包装一层 shell，比如 sh -c "source /etc/app/env.sh && exec myapp"。
- initContainer 必须成功退出，否则主容器不启动
- 挂载的 ConfigMap/Secret 会以文件形式出现，内容不含引号和等号，直接 source 即可
- 避免在 initContainer 里执行耗时操作（如调外部 API），它会阻塞主容器启动
Operator 或 controller 动态注入需谨慎评估必要性
只有当你需要根据集群状态（如某 CR 状态变更）实时 patch 所有匹配 Pod 的环境变量时，才考虑用 Operator。普通业务应用几乎不需要。
这种做法代价高：要 watch Pod、处理 ownerReference、避免覆盖用户手动设置的 env、还要处理 rolling update 时的注入时机。
- 95% 的所谓“动态需求”，其实用 ConfigMap +
envFrom+ 应用内监听文件变化就能解决 - 如果真要用 controller 注入，务必只写
env字段，不要碰envFrom—— 后者被 controller 修改后，用户后续更新 ConfigMap 就不会生效了 - Kubernetes v1.27+ 对 Pod spec 的 immutable 字段限制更严，随意 patch 可能触发 validation failure
真正难的不是怎么注入，而是想清楚哪些该进环境变量、哪些该进配置文件、哪些该走服务发现——混在一起会让调试和审计变得极其痛苦。
