ConfigMap、Secret 与应用配置管理

这一节学习 Kubernetes 如何管理应用配置、密码、Token 等信息，以及配置更新后应用如何感知变化。

核心知识点：ConfigMap、Secret、环境变量注入、配置文件挂载、配置更新机制、敏感信息安全管理。

一、为什么需要 ConfigMap 和 Secret？#

假设你开发了一个 Go Web 服务，需要连接 PostgreSQL：

flowchart TB
    N0["应用程序"]
    N1["数据库地址：postgres.default.svc"]
    N2["数据库端口：5432"]
    N3["数据库名称：appdb"]
    N4["数据库用户名：appuser"]
    N5["数据库密码：******"]
    N0 --> N1
    N0 --> N2
    N0 --> N3
    N0 --> N4
    N0 --> N5

如果把这些配置直接写进 Docker 镜像，会带来几个问题：

• 开发、测试、生产环境的配置不同。
• 修改数据库地址就要重新构建镜像。
• 密码可能被提交到代码仓库。
• 同一镜像难以复用于不同环境。

Kubernetes 使用两种资源解决这个问题：

核心思想是：镜像负责程序，ConfigMap 和 Secret 负责配置，Pod 负责把配置交给程序使用。

二、ConfigMap：管理普通配置#

1. 创建 ConfigMap#

例如，应用需要配置数据库地址和日志级别。

1
apiVersion: v1
2
kind: ConfigMap
3
metadata:
4
  name: app-config
5
data:
6
  DB_HOST: "postgres.default.svc.cluster.local"
7
  DB_PORT: "5432"
8
  LOG_LEVEL: "info"
9
  app.properties: |
10
    server.port=8080
11
    app.name=order-service

应用配置：

1
kubectl apply -f configmap.yaml
2
kubectl get configmap
3
kubectl describe configmap app-config

ConfigMap 的 data 可以存放普通字符串，也可以存放多行配置文件内容。

2. 通过环境变量注入配置#

可以把 ConfigMap 中的值注入容器环境变量：

1
apiVersion: v1
2
kind: Pod
3
metadata:
4
  name: config-env-demo
5
spec:
6
  containers:
7
    - name: app
8
      image: busybox:1.36
9
      command: ["sh", "-c", "env | grep -E 'DB_HOST|DB_PORT|LOG_LEVEL'; sleep 3600"]
10
      envFrom:
11
        - configMapRef:
12
            name: app-config

执行：

1
kubectl apply -f config-env-demo.yaml
2
kubectl logs config-env-demo

你会看到 ConfigMap 中的键被注入为容器环境变量。

如果只需要其中一个键，可以使用 env.valueFrom.configMapKeyRef 单独引用。

注意： ConfigMap 必须与引用它的 Pod 位于同一个 Namespace。

3. 把 ConfigMap 挂载为配置文件#

有些应用读取的是配置文件，而不是环境变量。

例如，将 app.properties 挂载到 /etc/app/app.properties：

1
apiVersion: v1
2
kind: Pod
3
metadata:
4
  name: config-file-demo
5
spec:
6
  containers:
7
    - name: app
8
      image: busybox:1.36
9
      command: ["sh", "-c", "cat /etc/app/app.properties; sleep 3600"]
10
      volumeMounts:
11
        - name: config-volume
12
          mountPath: /etc/app
13
          readOnly: true
14
  volumes:
15
    - name: config-volume
16
      configMap:
17
        name: app-config
18
        items:
19
          - key: app.properties
20
            path: app.properties

运行：

1
kubectl apply -f config-file-demo.yaml
2
kubectl exec config-file-demo -- cat /etc/app/app.properties

这样，应用就能从文件中读取配置。

三、Secret：管理密码与敏感信息#

Secret 的使用方式和 ConfigMap 很相似，但用途不同。

1. 创建 Secret#

Secret 的 data 字段要求值采用 Base64 编码。

例如，原始密码为 demo-password，可以这样编码：

1
echo -n 'demo-password' | base64

然后创建：

1
apiVersion: v1
2
kind: Secret
3
metadata:
4
  name: db-secret
5
type: Opaque
6
data:
7
  DB_USERNAME: YXBwdXNlcg==
8
  DB_PASSWORD: ZGVtby1wYXNzd29yZA==

这里：

• YXBwdXNlcg== 解码后为 appuser。
• ZGVtby1wYXNzd29yZA== 解码后为 demo-password。

非常重要：Base64 不是加密。 任何能够读取这个 Secret 的人，都可以解码得到原始内容。

生产环境中不要将真实密码直接提交到 Git 仓库中的 YAML 文件。

可以使用命令行创建：

1
kubectl create secret generic db-secret \
2
  --from-literal=DB_USERNAME=appuser \
3
  --from-literal=DB_PASSWORD='replace-with-real-secret'

上面的密码仅为占位示例，实际使用时应通过安全的密钥管理流程注入。

2. 将 Secret 注入环境变量#

1
apiVersion: v1
2
kind: Pod
3
metadata:
4
  name: secret-env-demo
5
spec:
6
  containers:
7
    - name: app
8
      image: busybox:1.36
9
      command: ["sh", "-c", "echo configured; sleep 3600"]
10
      env:
11
        - name: DB_USERNAME
12
          valueFrom:
13
            secretKeyRef:
14
              name: db-secret
15
              key: DB_USERNAME
16
        - name: DB_PASSWORD
17
          valueFrom:
18
            secretKeyRef:
19
              name: db-secret
20
              key: DB_PASSWORD

容器中的应用可以通过环境变量读取用户名和密码，而不需要把密码写进镜像。

但要注意：环境变量可能被有权限的进程、调试工具或应用日志意外暴露，不能因为使用 Secret 就认为密码绝对安全。

3. Secret 的安全措施#

生产环境至少要考虑以下几点：

• 使用 RBAC 限制谁可以读取 Secret。
• 对 etcd 中的 Secret 配置静态加密。
• 避免把真实密码写入代码仓库、镜像或日志。
• 限制有权限创建 Pod 的用户，因为他们可能通过挂载 Secret 获取内容。
• 优先考虑外部密钥管理系统，并按需轮换密码和 Token。

Secret 默认使用 Base64 编码存储，并不等于默认已加密。

四、环境变量与文件挂载，应该怎么选？#

这是实际项目中非常重要的区别。

有两个容易踩坑的地方：

1. ConfigMap 或 Secret 通过环境变量注入后，修改资源不会自动修改已有进程的环境变量；通常需要重新创建 Pod 才能让新环境变量生效。
2. 使用普通卷挂载 ConfigMap 或 Secret 时，文件更新可能存在传播延迟，而且应用必须能够重新读取文件，才能真正应用新配置。

另外，如果通过 subPath 挂载 ConfigMap 或 Secret 的单个文件，该挂载不会自动接收后续更新。

五、ConfigMap 更新后，如何让应用生效？#

假设你修改了：

1
data:
2
  LOG_LEVEL: "debug"

Kubernetes 更新 ConfigMap 并不意味着应用程序一定立即切换到 debug 日志级别。

通常有三种方案：

• 重启 Pod：适用于通过环境变量读取配置的应用。
• 挂载文件并监听变更：应用监控文件变化后重新加载配置。
• 使用配置管理工具：例如通过 Helm、GitOps 或专门的配置更新机制触发滚动更新。

如果应用需要稳定、可审计的配置发布流程，可以使用 ConfigMap 管理普通配置，再配合 Deployment 的滚动更新和外部自动化系统控制发布。

六、本节总结#