Pod 环境变量留下 $(DBHOST)：检查 env 定义顺序

Pod 的连接地址写成 mysql://$(DBHOST)/appdb，容器启动以后仍保留 $(DBHOST) 字面量。ConfigMap 中的 host 明明存在，新 Pod 也已经启动，这时需要读最终 Pod 的 env 列表顺序。

Kubernetes 支持在 env[].value 中引用环境变量，但处理这个值时，排在后面的显式变量尚未完成定义。YAML 源文件的顺序与发布后对象不一致时，界面编辑或模板变换也可能引入这个问题。

从实际对象确认先后

以下命令读取配置，不执行数据库查询，名称需替换：

kubectl config current-context
kubectl -n team-app get pod api-abc12 -o yaml
kubectl -n team-app get deployment api -o yaml

比较实际容器的 env，并核对原管理入口渲染出的清单。不要只拿一个重新整理过的简化 YAML 排查，也不要从另一容器的变量推断当前容器。

例如 DB_URL 在前、DBHOST 在后，且前面的 envFrom 或其他有效来源也没有提供 DBHOST，处理 DB_URL 时该名字尚不可用。未解析的引用会保留为普通字符串，容器仍可能正常启动；应用随后连接失败，并不能证明 Kubernetes 会在运行中补做替换。

检查配置时保护业务地址和凭据。含密码的完整连接字符串不适合直接输出到日志；可以在受控环境判断是否仍包含未解析标记，结合应用的配置读取路径确认来源。

先定义被引用变量，再写组合值

下面是容器的局部配置，ConfigMap 名称和键按实际使用：

env:
  - name: DBHOST
    valueFrom:
      configMapKeyRef:
        name: app-db-config
        key: host
  - name: DB_URL
    value: "mysql://$(DBHOST)/appdb"

这里先读取 DBHOST，再计算后面的 DB_URL。多层依赖也应按这个先后关系排列。确认变量名称大小写、ConfigMap 引用与键正确，并检查是否有重复名称或后续覆盖。

$$(DBHOST) 是刻意转义的写法，不会因为调整顺序就展开；需要展开时应核对是否误多写一个 $。${DBHOST} 则不是这里使用的 Kubernetes 引用语法。不要用 eval 再扫描一次配置，也不必为这种受支持的 env 引用增加 shell 启动包装。

这一处理不能推广到整个 Pod YAML。把 $(DBHOST) 写进任意字段、ConfigMap 文件内容或应用自己的配置文件，不代表 kubelet都会替换。Docker CMD 的 exec 形式又有不同规则，可看Docker 启动参数中的字面量变量。

用新实例验证应用真正取得了新地址

在原工作负载模板中修正顺序，保存配置并按正常发布流程生成新 Pod。已有进程的环境不会就地改变；ConfigMap 更新也不会自动刷新旧进程，可参照ConfigMap 与旧 Pod 环境。

验收要看新 Pod 的实际定义顺序、未解析标记是否消失，以及应用是否用预期配置完成连接。应用如果优先读配置文件或命令行参数，即使环境变量正确，也可能仍使用另一地址，应按应用的配置优先级继续检查。

更新后出现认证、网络或数据库不存在的错误，属于后续连接条件，不继续交换 env 顺序来处理。撤回时恢复审定模板和对应配置，观察新一轮副本替换及业务状态。