前面我们学习了一些常用的资源对象的使用，但是单纯依靠这些资源对象，还不足以满足我们的日常需求，一个重要的需求就是应用的配置管理、敏感信息的存储和使用（如：密码、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，以降低泄露风险。
