两种注入方式的代价
把配置注入容器有两条路：环境变量与挂载卷。环境变量简单直观，但取值变化时必须重建 Pod 才生效；卷挂载支持热更新，kubelet 会定期把新内容同步到挂载点，但存在几个细节坑：用 subPath 挂载的单个文件不接收更新、挂载目录会遮蔽镜像中的原有文件、文件权限与只读属性都需要显式考虑。选型应跟着组件行为走。
基本信息
| 环境变量 | 支持单个键与批量导入，改值后必须重建 Pod 才生效 |
|---|---|
| 挂载卷 | 以文件形式呈现，内容更新约在一分钟级同步到挂载点 |
| subPath 限制 | 用 subPath 挂载的单个文件不会收到更新 |
| 权限与只读 | 注意文件权限设置，并以只读方式挂载避免应用误写 |
| 目录覆盖 | 挂载到镜像中已存在的目录会遮蔽该目录原有内容 |
| 选型原则 | 启动参数与开关用环境变量，配置文件与证书用挂载卷 |
方式对照
| 维度 | 环境变量 | 挂载卷 |
|---|---|---|
| 更新生效 | 需重建 Pod | 内容约一分钟级同步 |
| 使用难度 | 简单直觉 | 涉及挂载路径与权限 |
| 热更新支持 | 不支持 | 支持，但应用需重新读取 |
| subPath 陷阱 | 无 | subPath 挂载不接收更新 |
| 适用场景 | 启动参数与功能开关 | 配置文件与证书轮转 |
典型使用场景
- 启动参数、功能开关、外部服务地址用环境变量注入
- 应用的 YAML 或 JSON 配置文件通过挂载卷提供
- TLS 证书与私钥以只读方式挂载，配合轮转流程
- 配置中心下发的渲染结果落到共享卷，供多个容器读取
- 批量导入一批配置项时注意键名规则与格式限制
挂载示例
挂载示例
volumes:
- name: conf
configMap:
name: app-conf
- name: tls
secret:
secretName: app-example-tls
containers:
- name: app
image: registry.example.com/team/app:1.2.3
volumeMounts:
- { name: conf, mountPath: /etc/app, readOnly: true } # 配置文件目录
- { name: tls, mountPath: /etc/tls, readOnly: true } # 证书目录
证书轮转常选挂载卷加应用热加载：内容同步后由应用重新读取即可生效，不需要重建 Pod。对于需要重载信号的进程（如 nginx），可以配合自动重载类工具，让配置或证书更新后触发一次平滑重载。
两个高频坑：把配置挂载到镜像中已有文件的目录上会遮蔽原有内容，启动脚本找不到依赖文件；用 subPath 挂载单个文件时内容永远不会更新，热更新的承诺落空却没有任何报错。