环境变量在kubernetes中无法热更新，必须通过configmap/secret定义并引用后触发pod重建才能生效；secret用于敏感数据且同样需重建，kubeconfig则用于客户端配置动态化。
环境变量在 Kubernetes 集群中不能“实时热更新”到已运行的 Pod，但可以通过声明式资源 + 重启/重建机制实现动态分发与管理——关键不在“改变量”，而在“换配置后触发生效”。核心路径是：用 ConfigMap 或 Secret 定义变量 → 在 Pod 中引用 → 更新配置后滚动更新 Pod。
用 ConfigMap 实现非敏感配置的动态分发
ConfigMap 是管理环境变量最常用、最标准的方式。它把键值对存为集群资源，支持多环境复用和版本追溯。
- 创建 ConfigMap（如
app-config），内容可来自 YAML、目录或 literal 值：kubectl create configmap app-config --from-literal=LOG_LEVEL=debug --from-file=config.env - 在 Deployment 中通过
envFrom全量注入，或valueFrom.configMapKeyRef单个引用 - 更新 ConfigMap 后，不会自动刷新已有 Pod 的环境变量；需触发 Pod 重建（如修改 Deployment 的
spec.template.metadata.annotations加时间戳，或执行kubectl rollout restart）
用 Secret 管理敏感变量（密码、Token 等）
Secret 与 ConfigMap 使用方式一致，但数据默认 Base64 编码，且挂载时权限更严格（如只读文件模式）。适合数据库密码、API 密钥等。
- 创建 Secret：
kubectl create secret generic db-secret --from-literal=DB_USER=admin --from-literal=DB_PASS=123456 - 在容器 env 中引用：
envFrom: [{secretRef: {name: db-secret}}]，或单个字段引用 - 注意：Secret 也需 Pod 重建才能生效，不支持运行中注入
借助 KUBECONFIG 环境变量管理客户端连接配置
这是针对 Kubernetes Python 客户端、kubectl 等工具本身 的配置动态化，不是给业务 Pod 注入变量。
- 设置
KUBECONFIG指向多个配置文件路径（Linux/macOS 用冒号分隔）：export KUBECONFIG=~/.kube/dev.conf:~/.kube/prod.conf - 客户端会自动合并这些文件中的上下文、认证信息等，无需修改代码即可切换集群
- 配合
kubectx工具可快速切换当前上下文，提升多集群操作效率
进阶：用 envconsul 或 Admission Webhook 补足动态性短板
当业务要求“不重启也能更新变量”，需引入外部协调层：
- envconsul：在容器启动前从 Consul/Vault 拉取最新配置，生成环境变量再启动主进程。适用于需要秒级响应的场景
-
Admission Webhook：可在 Pod 创建时动态注入变量（如根据命名空间自动加
NAMESPACE环境变量），但无法用于 UPDATE 操作——Kubernetes 明确禁止在更新阶段修改 Pod spec 中的 env 字段 - 注意：这类方案增加了架构复杂度，应先评估是否真需绕过原生机制
