Kubernetes中Deployment的env字段直接写value仅适用于临时调试、CI/CD固定参数（如CI=true）或完全公开的开关类变量（如LOG_LEVEL=debug），因其易泄露敏感信息、难复用且无法热更新。
直接在 Deployment 的 env 字段里写死最简单，但生产环境几乎从不这么干——容易泄露敏感信息、难以复用、无法热更新。
env 字段直接写 value 适合什么场景
只适用于临时调试、CI/CD 流水线中的固定参数（比如 CI=true）、或完全公开的开关类变量（如 LOG_LEVEL=debug）。
-
name和value都是必填项，值会原样注入容器，不解析变量 - 如果值含空格或特殊字符，YAML 中必须加引号，否则解析失败
- 多个相同
name定义时，后定义的会覆盖前一个（Kubernetes 按 YAML 顺序处理） - 镜像中已有的同名环境变量会被此处定义的值覆盖
用 valueFrom 引用 ConfigMap 或 Secret 才是正解
绝大多数业务配置应走 valueFrom + configMapKeyRef 或 secretKeyRef，这是 Kubernetes 声明式配置的核心实践。
Kubernetes Security Posture Scorecard
下载
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
- ConfigMap 必须和 Deployment 在同一 namespace，否则引用失败，报错类似
configmap "my-config" not found -
configMapKeyRef.name和key都要严格匹配大小写和拼写，YAML 中无自动补全，手误极难排查 - Secret 中的值默认 Base64 编码，但
valueFrom会自动解码，你不需要在代码里再做base64.b64decode() - 如果 ConfigMap 或 Secret 尚未创建，Pod 会卡在
Pending状态，kubectl describe pod显示Failed to pull image类似误导信息，实际是 config lookup 失败
envFrom 批量导入要注意命名冲突
用 envFrom 可以把整个 ConfigMap 或 Secret 的所有 key 全部转成环境变量，省得逐个写 valueFrom，但风险也高。
- ConfigMap 中的 key 必须符合环境变量命名规范（只能含字母、数字、下划线，不能以数字开头），否则该 key 会被跳过且无提示
- 如果 ConfigMap 和 Secret 里有同名 key，Secret 的值会覆盖 ConfigMap 的值（Secret 优先级更高）
- 批量导入后，无法控制哪些变量生效、哪些被忽略，调试时容易混淆来源
- 不建议在生产 Deployment 中直接用
envFrom引用未经清洗的 ConfigMap，尤其当它由外部工具生成时
Python 应用里读取环境变量的坑
别假设 os.getenv("MY_VAR") 一定返回字符串——它可能返回 None，尤其当 ConfigMap key 不存在或引用路径写错时。
- 始终提供默认值：
os.getenv("DB_HOST", "localhost")，避免后续调用抛TypeError - 数值型变量（如端口）必须显式转换：
int(os.getenv("PORT", "8080"))，否则可能被当字符串拼接 - 敏感字段（如
API_TOKEN）不要打日志，哪怕只是print(os.environ)—— Pod 日志可能被采集到集中平台 - 如果用
dotenv库加载本地 .env 文件，注意它不会自动读取 Kubernetes 注入的环境变量，两者互不影响
真正麻烦的不是怎么写 YAML，而是当环境变量没生效时，你得一层层确认：ConfigMap 是否存在、是否在正确 namespace、key 名是否拼对、Deployment 是否已 rollout、容器进程是否真读到了——这些链路里任何一环断掉，printenv 都只会安静地显示空结果。
