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