如何在Kubernetes/Openshift集群设置全局环境变量供所有POD访问

完全可以实现全局默认配置自动注入 + 单DeploymentConfig按需覆盖的需求，以下是3种生产环境常用的落地方案：

方案1：使用内置PodPreset（轻量场景首选） #

PodPreset是Kubernetes/OpenShift原生提供的Pod配置预注入能力，完美适配你的需求：

• 首先在集群公共命名空间（如openshift-config）下创建PodPreset资源，预定义STS校验接口地址、JWT公钥等配置，支持以环境变量、ConfigMap/Secret挂载的形式注入
• 可通过label选择器控制生效范围，默认匹配所有需要注入配置的Web应用Pod，也可设置排除规则跳过不需要注入的工作负载
• 原生支持覆盖逻辑：如果DeploymentConfig中已经定义了同名环境变量或挂载配置，PodPreset的全局配置会自动被优先级更高的工作负载配置覆盖
• OpenShift 4.x默认已开启PodPreset API，低版本需要在kube-apiserver启动参数中添加settings.k8s.io/v1alpha1=true启用
• 配置示例：

apiVersion: settings.k8s.io/v1alpha1
kind: PodPreset
metadata:
  name: global-sts-config
  namespace: openshift-config
spec:
  selector:
    matchExpressions:
      # 标记了sts-config-inject: disabled的Pod会跳过注入
      - key: sts-config-inject
        operator: NotIn
        values: ["disabled"]
  env:
    - name: STS_VALIDATION_ENDPOINT
      value: "https://sts-internal.company.com/api/validate"
    # 公钥建议存Secret，这里用valueFrom引用全局Secret的对应key即可
    - name: JWT_ES256_PUBLIC_KEY
      valueFrom:
        secretKeyRef:
          name: global-sts-secret
          key: es256-public-key

方案2：全局ConfigMap/Secret + CI/CD模板（兼容性最优） #

适合对集群准入配置权限有限、已经有统一CI/CD部署流程的场景：

• 在公共命名空间下创建存储全局STS配置的ConfigMap（存接口地址）和Secret（存公钥），开放所有业务命名空间的只读权限
• 在公司统一的应用部署模板（如Helm公共模板、Kustomize基础层）中默认添加引用该全局ConfigMap/Secret的环境变量配置
• 单个应用如果需要自定义配置，只需要在自己的DeploymentConfig中定义同名环境变量，即可覆盖模板的默认全局配置
• 优势：不需要修改集群层面的准入规则，兼容性最好，不易出现集群升级后的适配问题

方案3：自定义Mutating Admission Webhook（复杂规则场景首选） #

如果需要更灵活的注入规则（比如按命名空间等级、应用业务线注入不同环境的STS配置），可以自定义开发轻量的准入Webhook：

• 在Webhook逻辑中实现默认注入逻辑，检测到Pod已存在同名STS相关配置时自动跳过注入，保留应用侧的覆盖能力
• 支持更复杂的匹配逻辑，比如只给运行Web应用的命名空间注入、灰度推送新的STS配置等

注意事项 #

• 敏感配置如JWT公钥建议存储在Secret中，不要以明文形式写在配置文件里
• 建议给全局STS配置加版本标识，后续配置变更时可以平滑灰度切换，避免全集群影响
• 配置注入的匹配规则尽量收敛，避免给数据库、中间件等不需要STS配置的工作负载注入无关内容

内容的提问来源于stack exchange，提问作者Sam D.