k8s-配置管理

前面我们学习了一些常用的资源对象的使用，但是单纯依靠这些资源对象，还不足以满足我们的日常需求，一个重要的需求就是应用的配置管理、敏感信息的存储和使用（如：密码、Token 等）、容器运行资源的配置、安全管控、身份认证等等。

ConfigMap 是 Kubernetes 中用于管理应用非敏感配置数据 （如配置文件、环境变量、命令行参数）的资源对象，它能有效实现配置信息与容器镜像的解耦，提升应用的可移植性。

以下是 ConfigMap 的核心要点，帮助你快速理解：

ConfigMap核心价值

ConfigMap 的核心价值在于将应用的配置信息从容器镜像中分离出来，使得配置的修改和更新无需重新构建镜像，增强了应用的灵活性和可维护性。

创建 ConfigMap

ConfigMap 支持多种创建方式，以适应不同场景：

在 Pod 中使用 ConfigMap

创建好的 ConfigMap 主要有两种方式供 Pod 使用：

1.作为环境变量

将 ConfigMap 中的键值对注入为容器内部的环境变量。这种方式适合传递单个配置值。

env:
- name: LOG_LEVEL # 容器内的环境变量名
  valueFrom:
    configMapKeyRef:
      name: app-config # 引用的ConfigMap名称
      key: log_level   # ConfigMap中的键

2.作为文件挂载（更常用）

将整个 ConfigMap 或其中特定键的内容挂载到容器内的指定路径，成为一个或多个配置文件。这种方式非常适合应用需要读取标准配置文件（如 nginx.conf、my.cnf）的场景。

volumes:
- name: app-config-volume
  configMap:
    name: app-config # 指定要挂载的ConfigMap
volumeMounts:
- name: app-config-volume
  mountPath: "/etc/app/config" # 配置文件在容器内的挂载路径

重要特性与注意事项

|-------------|------------------------------------------------------------------------------------------|
| 特性/注意事项 | 说明 |
| 动态更新 | 以文件挂载 方式使用的 ConfigMap，Kubernetes 会自动更新Pod内的文件内容（非立即生效，有短暂延迟）。但需要应用自身支持配置热重载才能生效。 |
| 命名空间 | ConfigMap 是命名空间级别的资源，Pod 只能引用同一命名空间下的 ConfigMap。 |
| 大小限制 | 单个 ConfigMap 的数据量限制通常为 1MiB。 |
| 数据安全 | ConfigMap 数据以明文存储 。切勿 用于存储密码、API密钥等敏感信息。敏感信息应使用 Secret​ 对象管理。 |

实用技巧

• 使用 subPath挂载 ：当只需要将 ConfigMap 中的某一个配置项 挂载到容器内一个已存在目录的特定文件 ，且不希望覆盖整个目录时，可以使用 subPath字段。

• 不可变 ConfigMap ：可以通过设置 immutable: true将 ConfigMap 变为不可变对象，这可以防止意外修改，提升安全性并减少 API 服务器的负载。

Secret

Secret 是 Kubernetes 中专门用于存储和管理敏感信息（如密码、API 令牌、SSH 密钥等）的资源对象。下面这张表格清晰地展示了它与 ConfigMap 的核心区别，帮你快速把握其定位。

|----------|-----------------------------|------------------------|
| 特性 | Secret | ConfigMap |
| 用途 | 存储敏感信息（密码、令牌、密钥） | 存储非敏感配置（普通参数、配置文件） |
| 存储方式 | 数据经过 Base64 编码（非加密） | 明文存储 |
| 安全考量 | 建议配合 RBAC ​ 和静态加密使用 | 权限控制相对宽松 |
| 典型场景 | 数据库密码、API 密钥、TLS 证书 | 应用配置文件、命令行参数 |

主要类型

Secret 有多种内置类型，以适应不同场景：

• Opaque ：最常用的通用类型，用于存储任意用户定义的敏感数据（如用户名、密码）。不指定类型时默认为此类型。

• kubernetes.io/dockerconfigjson ：用于存储私有 Docker 镜像仓库的认证信息。使用 kubectl create secret docker-registry命令创建。

• kubernetes.io/tls ：用于存储 TLS 证书（tls.crt）和私钥（tls.key），常用于 Ingress 等场景。使用 kubectl create secret tls命令创建。

• kubernetes.io/service-account-token：由 Kubernetes 自动创建，用于服务账户（ServiceAccount）的身份认证令牌。

• kubernetes.io/basic-auth：用于存储基本身份认证所需的用户名和密码。

• kubernetes.io/ssh-auth：用于存储 SSH 身份认证所需的私钥。

创建方式

法一：用 kubectl命令行（最便捷）

1. 从字面值创建：适用于简单的键值对。

kubectl create secret generic my-secret \
  --from-literal=username=admin \
  --from-literal=password='S!B\*d$zDsb='

2.从文件创建：适用于证书、密钥文件。

echo -n "admin" > ./username.txt
echo -n "password123" > ./password.txt
kubectl create secret generic my-secret \
  --from-file=./username.txt \
  --from-file=./password.txt

法二：通过 YAML 清单（易于版本控制）

Secret 资源包含 data和 stringData字段：

• data字段中的值必须是 Base64 编码的字符串。

• stringData字段是为了方便，允许直接写入明文字符串，创建时 Kubernetes 会自动将其编码后存入 data字段。如果同一个键在 data和 stringData中都有指定，stringData的值优先级更高。

  apiVersion: v1
  kind: Secret
  metadata:
  name: mysecret
  type: Opaque
  data:
  # 值是经过 Base64 编码的
  encoded-secret: MWYyZDFlMmU2N2Rm
  stringData:
  # 直接写入明文，创建后会自动编码存入 data 字段
  plaintext-secret: "This is a secret"

重要安全提示与最佳实践

• Base64 编码不是加密 ：Secret 数据默认仅用 Base64 编码，在 ETCD 中是明文存储的。任何有 API 访问权限的人都可能解码获取原始数据。

• 启用静态加密 ：为保障生产环境安全，务必为 Kubernetes 集群的 ETCD 数据启用静态加密 (Encryption at Rest)，这样 Secret 在 ETCD 中才是加密状态。

• 使用 RBAC ：通过**基于角色的访问控制 (RBAC)**​ 严格限制对 Secret 的访问权限，遵循最小权限原则。

• 限制 Secret 对特定容器的访问：通过合理配置 Pod 和安全上下文，可以限制 Secret 仅对必要的容器可见。

• 考虑不可变 Secret ：对于不需要修改的 Secret，可以设置 immutable: true。这能防止意外修改，并提升 API 服务器性能。

• 谨慎使用环境变量：如前所述，优先选择文件挂载方式而非环境变量来使用 Secret，以降低泄露风险。