简单地说，在kube条款，你不能。
Linux进程的环境是在进程启动时建立的，当然没有Kube工具可以实现这样的目标。例如，如果您对部署进行更改（我假设您使用它来创建Pod），它将滚动底层的Pod。
现在，也就是说，在Is there a way to change the environment variables of another process in Unix?下报告了一个涉及到使用GDB的非常笨拙的解决方案
另外，请记住，即使您可以这样做，仍然有应用程序逻辑需要监视此类更改，而不是像现在这样，在启动期间仅从envs评估配置。

这对我很有效
kubectl set env RESOURCE/NAME KEY_1=VAL_1 ... KEY_N=VAL_N
在此查看官方文档
运行时pod的另一种方法是进入Pod命令行并更改运行时中的变量RUN kubectl exec -it <pod_name> -- /bin/bash Then Run export VAR1=VAL1 && export VAR2=VAL2 && your_cmd

我不知道有什么方法可以做到这一点，我想不出真实的世界的情况下，这是太有意义。
通常，您必须重新启动进程才能让它注意到更改的环境变量，而最简单的方法就是重新启动pod。
最接近我们想要的解决方案是创建一个deployment，然后使用kubectl edit（kubectl edit deploy/name）修改它的环境变量，保存后启动一个新的pod，终止旧的pod。

Kubernetes的设计方式是，对Pod的任何更改都应该通过配置重新部署。如果您对已经部署的Pod进行干扰，最终可能会出现难以调试的怪异集群。
如果确实需要，可以使用kubectl exec在运行pod中运行其他命令，但建议仅用于调试目的。

kubectl exec -it <pod_name> export VARIABLENAME=<thing>

如果您根据文档使用Helm 3〉：

自动滚动部署

通常情况下，ConfigMap或Secrets作为配置文件注入容器中，或者存在需要滚动pod的其他外部依赖项更改。根据应用程序的不同，如果使用后续helm升级更新这些内容，则可能需要重新启动，但如果部署规范本身没有更改，则应用程序将继续使用旧配置运行，从而导致部署不一致。
sha 256 sum函数可用于确保部署的注解部分在其他文件更改时更新：

kind: Deployment 
spec: 
  template:
    metadata:
      annotations:
        checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum }} 
[...]

如果您总是想滚动部署，可以使用与上面类似的注解步骤，而不是替换为随机字符串，这样它就会始终更改并导致部署滚动：

kind: Deployment 
spec:   
  template:
    metadata:
      annotations:
        rollme: {{ randAlphaNum 5 | quote }} 
[...]

这两种方法都允许您的部署利用内置的更新策略逻辑来避免停机。
注意：在过去我们推荐使用--recreate-pods标志作为另一个选项。这个标志在Helm 3中被标记为不推荐使用，而支持上面更声明性的方法。

从外部改变很难。但是从内部改变很容易。你在pod中运行的应用程序可以改变它。只要反对API改变环境变量。

您可以将configmap与卷一起使用，随时更新环境变量。
参考：https://itnext.io/how-to-automatically-update-your-kubernetes-app-configuration-d750e0ca79ab