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，以降低泄露风险。