ConfigMap用于非敏感配置，Secret专为敏感数据设计；二者均支持挂载为文件或环境变量，但需注意权限、热更新及安全实践。

ConfigMap 和 Secret 是 Kubernetes 中管理配置数据的核心机制，前者用于非敏感配置，后者专为密码、密钥等敏感信息设计。用对它们，能让你的应用更安全、更易维护，也避免把配置硬编码进镜像。

ConfigMap：存配置，不存秘密

ConfigMap 适合存放环境变量、配置文件内容、命令行参数等不需要加密的数据。它本身不提供加密，只是键值对的集合，可以挂载为文件或注入为环境变量。

常见创建方式有三种：

• 从字面量创建：kubectl create configmap app-config --from-literal=LOG_LEVEL=debug --from-literal=API_URL=https://api.example.com
• 从文件创建：kubectl create configmap nginx-conf --from-file=nginx.conf（会自动以文件名为 key）
• 从目录创建：kubectl create configmap app-cfg --from-file=./config/（目录下所有非隐藏文件都会成为 key）

在 Pod 中使用时，推荐挂载为文件（尤其配置文件），比环境变量更灵活，支持热更新（需应用自身支持重载）。注意：挂载后文件权限默认是 644，若容器内进程需要读写，可能要配合 securityContext 或 defaultMode 调整。

Secret：专管敏感数据，必须加密传输

Secret 的数据在 etcd 中以 base64 编码存储（不是加密！），真正安全靠的是访问控制（RBAC）和网络策略。Kubernetes 不会解密它，只是原样传递给 Pod。

创建 Secret 要求输入内容先做 base64 编码（或让 kubectl 自动处理）：

• 手动编码后创建：echo -n 'mypass' | base64，再写入 yaml；
• 更常用的是让 kubectl 处理：kubectl create secret generic db-secret --from-literal=DB_PASS=mypass --from-literal=DB_USER=admin；
• 从文件创建（如 TLS 秘钥）：kubectl create secret tls example-tls --cert=cert.pem --key=key.pem。

Secret 挂载到容器后，默认权限是 644，但文件属主是 root。如果容器以非 root 用户运行，需设置 runAsUser 并配合 fsGroup 或 defaultMode，否则可能读不到。

ConfigMap / Secret 的最佳实践

别把 ConfigMap 或 Secret 当作“配置中心”来动态改——它们变更后，Pod 内的挂载文件不会自动刷新（环境变量更不会），除非你触发滚动更新或用工具如 Reloader、k8s-sidecar 等辅助。

• 按用途拆分资源：比如 app-config、app-secrets、db-config，别堆在一个里；
• 避免在 Secret 中存大量数据（最大 1MB），大文件建议用外部存储（如 S3 + initContainer 下载）；
• Secret 数据不要写进 Git（哪怕 base64）；用 SealedSecret、SOPS 或外部密钥管理服务（如 HashiCorp Vault）增强安全性；
• 限制访问权限：通过 RBAC 控制哪些用户/ServiceAccount 能 get/watch ConfigMap 或 Secret。

快速验证是否生效

部署后别急着看日志，先进容器确认配置是否存在、权限是否正确：

• 检查挂载点：kubectl exec -it -- ls -l /etc/config/；
• 查看内容：kubectl exec -it -- cat /etc/config/app.conf；
• 查环境变量：kubectl exec -it -- env | grep LOG_LEVEL；
• 确认 Secret 解码无误（仅调试用）：kubectl get secret db-secret -o jsonpath='{.data.DB_PASS}' | base64 -d。