下一篇：我为什么要走这种奇怪的路：
我尝试注入env的pod（pod）是由作业产生的，有数百个。在k8s中还有一个包含所有env的map。我这样做是为了避免手动声明数百个具有不同env变量的pod
我在k8s中有一个pod，在manifest中定义了env vars：
spec:
containers:
name: something
command: ["/bin/bash"]
args: ["-c", "sleep 60 && source ~/.bashrc && env | grep FOO"]
env:
- name: FOO
value: bar
- name: FOO2
value: bar2我还运行了另一个pod，其中设置了kubectl和rbac，并执行：
kubectl exec -i FIRST_POD_NAME -- bash -c "echo 'FOO=updated_bar' >> ~/.bashrc"第一个pod使用（sleep是为了确保其他pod有时间更新env vars的值）：
sleep 60 && source ~/.bashrc && env | grep FOO如命令和日志：
FOO=bar
FOO2=bar2但是当我手动输入pod（bash）并运行时：
env | grep FOO我看到FOO=updated_bar
我在这里遗漏了什么，以及如何更新这些env，以便pod在start cmd中使用它们？
2条答案
按热度按时间vzgqcmou1#
由于我找不到原因，我做了一个变通方案，所以如果有人需要做类似的事情：
helping pod只是将值附加到其他pod中的tmp文件：
在启动时，我读取了这个fire的值，并将其用作ENV：
这是一个很差的解决方案，但是可以将在pod map中声明的env导入到数百个pod中
j8yoct9x2#
环境变量在pod start本身上设置。它不需要任何睡眠。
有关kubernetes环境变量的更多信息：https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/
why am I looking for that strange way?为了回答这个问题，
1.我可以看到你在
kubectl exec -i FIRST_POD_NAME -- bash -c "echo 'FOO=updated_bar' >> ~/.bashrc"中缺少export关键字。如果您错过了导出，则变量将被视为shell variable而不是environmental variable，并且在source ~/.bashrc期间将忽略此更新的FOO变量。~/.bashrc文件是用户特定的。请在执行kubectl exec -i FIRST_POD_NAME -- bash -c "echo 'export FOO=updated_bar' >> ~/.bashrc"时比较start up和user_name期间的poduser_name。如果两个user_name's是不同的，那么。你会看到奇怪的行为。