运行于容器/Pod的程序配置能否存入Deployment YAML而非ConfigMap YAML？

完全可以，K8s从来没有强制要求容器配置必须独立拆成ConfigMap的YAML，你尝试把配置直接写在Deployment里的思路完全符合原生设计，唯一的问题是你给出的示例有不少语法和结构错误，实际跑不起来。

你给出的示例存在的硬伤 #

• 结构层级错配：Deployment的Pod模板规约必须放在spec.template.spec路径下，你现在的写法嵌套了两层spec，导致容器定义的位置根本不被K8s识别
• YAML语法错误：列表项的键名-name 连字符后面没有加空格，不符合YAML解析规则，K8s会把它识别成普通字段而非列表项
• 缺失必备字段：没有写Deployment必备的selector匹配规则、Pod模板的标签、容器的名称和镜像地址，就算语法修正了也会被API server直接拒绝

修正后的可运行示例如下：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:alpine
          env:
            - name: "MyConfigKey"
              value: "MyConfigValue"

直接在Deployment内嵌配置的适用边界 #

这类硬编码配置最适合简单的键值对场景：也就是你示例里这种环境变量形式的配置，只要值没有敏感性、不需要跨工作负载复用，直接写在Deployment里完全没问题，少写一个ConfigMap资源，少维护一个YAML文件。
如果要把配置作为独立文件挂载进容器（比如nginx的主配置文件、Java应用的application.yml），实际操作中没法完全绕开ConfigMap——K8s没有提供直接在Deployment里定义整块文件类配置的内嵌通道，文件类配置的挂载必须依托ConfigMap、Secret这类专门的配置资源做载体。

和单独使用ConfigMap的取舍 #

• 适合直接内嵌在Deployment的场景：
  • 配置项数量少，就是零散的几个环境变量
  • 配置仅给当前这一个Deployment使用，没有其他工作负载需要复用同一份值
  • 配置本身变更频率极低，不需要独立的变更、版本管控流程
  • 注意：如果配置涉及敏感信息，哪怕内嵌也不要直接明文写值，建议用Secret引用，避免明文泄露风险
• 适合单独拆成ConfigMap的场景：
  • 配置是结构化的整块文件，不是零散的键值对
  • 同一份配置要给多个Deployment、Job、StatefulSet复用，避免重复抄写
  • 配置需要独立更新，不想每次改配置都要连带修改整个Deployment的定义、触发滚动重建

内容的提问来源于stack exchange，提问作者Evgeny Benediktov