kubectl apply 切换 valueFrom 报错：旧 value 可能仍在对象里

Deployment 原来给某个环境变量写固定 value，现在改为 valueFrom.secretKeyRef。本地 YAML 已经删掉 value，kubectl apply 仍报 may not be specified when value is not empty。应检查更新合并后是否仍保留服务器上的旧值，而不只盯着本地那一段。

非空 value 不能与 valueFrom 同时存在。同名环境变量重复、模板渲染仍带旧值，也可能触发类似错误。本文处理的是客户端 apply 与直接编辑混用后，旧字段没有被清除的情况，不把所有同类报错都视为同一个原因。

看最终清单、现存对象与上次 apply 记录

在有权限的环境中对照三个对象：部署工具最终提交的清单、服务器上该 Deployment 的 env，以及 kubectl.kubernetes.io/last-applied-configuration 注解。环境变量和注解可能包含业务配置或敏感内容，检查结果不要原样贴到公开日志。

先确认 context、namespace、容器名称与环境变量名称正确。多容器模板中，要比较发生错误的那个容器；最终清单还应检查同名变量是否出现两次，或继承模板是否同时保留了 value 和 valueFrom。

客户端 kubectl apply 用最终清单、现存对象及上次 apply 注解计算补丁。后来通过 kubectl edit 等方式加入的字段，可能不在上次 apply 记录里。新清单里省略它，未必会生成删除这个字段的补丁，于是旧 value 与新增 valueFrom 合并后一起接受校验。

这类环境变量字段冲突与Deployment selector 不可变、Secret type 不可变不同。重建对象不能成为看到更新错误就先做的动作。

在原管理清单中明确清除旧字段

确认确实是客户端 apply 保留旧值后，可以在同一个变量条目中明确将旧字段设为 null。下面是容器 env 的局部示例，不是完整 Deployment：

env:
  - name: DB_USER
    value: null
    valueFrom:
      secretKeyRef:
        name: app-db-credentials
        key: username

保留正确的变量名和既有 Secret 引用，并合入原清单，不要用这段内容替换整个 env 列表。客户端 apply 的合并规则会清除明确设为 null 的字段，即使该字段未出现在上次 apply 注解中。

反向从 valueFrom 切回固定值时，需要明确清除旧的 valueFrom，并提供审定的字符串 value。若更新由 Helm、Terraform 或 GitOps 控制器提交，应检查它实际生成的补丁和字段管理方式，不能假定它与客户端 apply 使用完全相同的合并过程。通过原配置来源修正，避免另一个控制器马上写回旧设置。

先让服务器校验，再按正常流程更新

保存当前部署配置和恢复方式，核实 Secret 名称、键与发布策略。在最终清单上执行服务器端试运行，文件和空间需替换：

kubectl -n team-app apply --dry-run=server -f deployment.yaml

这会向服务器提交试运行请求，进行相应处理和校验，不保存该资源更新。通过不代表业务已使用新值，也不能证明 Secret 对应用有用。若仍报冲突，应继续检查最终条目和管理来源，不删除整个环境变量列表来试错。

校验通过后按原部署流程更新。Pod 模板变化会触发新一轮替换，已有进程不会就地换掉环境变量。确认新模板里旧固定值已经清除，Secret 引用正确，新的 Pod 就绪，应用完成原来的数据库访问；不需要把密码打印出来才能验收。

需要回退时，从原管理入口恢复审定的变量来源，并清除另一种来源字段。配置更新只能恢复后续 Pod 的启动输入，不能撤销更新期间已经产生的业务写入或凭据变更。