Kubernetes配置：ConfigMap与Secret管理

理解ConfigMap与Secret及使用场景

ConfigMap与Secret是Kubernetes中解耦应用代码与配置的核心资源对象。两者在数据结构上均采用键值对（Key-Value）形式，但定位截然不同：ConfigMap专用于存储非敏感配置，如数据库连接串、日志级别或应用参数；Secret则专门用于管理密码、TLS证书、Token等敏感信息。在数据组织上，Secret默认会对Value进行Base64编码，但这仅是格式转换而非加密。配置注入通常有三种主流思路：一是通过环境变量（Environment Variables）直接注入容器进程，适合读取简单键值；二是通过命令行参数（Command/Args）传递，常用于覆盖容器默认启动参数；三是通过Volume挂载为容器内的文件或目录，适合注入多行配置、证书文件或需要动态刷新的场景。合理选择注入方式能显著提升应用的可移植性与安全性。

创建并注入ConfigMap与Secret

创建ConfigMap与Secret可通过命令行或声明式YAML实现。使用kubectl create configmap app-config --from-literal=LOG_LEVEL=info可快速生成；Secret则使用kubectl create secret generic db-creds --from-literal=username=admin --from-literal=password=123456，注意其底层会自动进行Base64编码。在YAML中，可通过data字段定义明文，Secret也可使用stringData字段避免手动编码。注入Pod时，环境变量方式需在containers.env中配置valueFrom.configMapKeyRef或secretKeyRef；Volume挂载则需在volumes定义configMap或secret，并在volumeMounts指定挂载路径。需特别强调：Secret的Base64编码仅用于传输兼容，任何具备kubectl get secret权限的用户均可通过echo <value> | base64 -d还原明文，因此绝不能将其等同于加密存储。

验证配置读取与更新生效

配置注入后需严格验证。使用kubectl describe pod <pod-name>可查看Events与Env部分，确认资源引用是否成功；通过kubectl exec -it <pod-name> -- env可打印容器内实际生效的环境变量；若采用Volume挂载，可执行kubectl exec -it <pod-name> -- cat /etc/config/app.conf核对文件内容。关于更新生效机制，两者存在本质差异：环境变量在容器启动时一次性注入，后续ConfigMap/Secret的变更不会自动同步至已运行的容器，必须执行kubectl rollout restart deployment/<name>重建Pod才能生效；而Volume挂载的文件由kubelet定期同步（默认约1分钟），应用若具备动态重载配置能力，则无需重启即可感知变更。若业务强依赖环境变量更新，建议在CI/CD流水线中集成自动触发滚动更新的逻辑。

安全管理与常见避坑

实际运维中常遇配置陷阱：将Secret明文提交至Git仓库导致凭证泄露；RBAC权限配置过宽使非授权Namespace可读取敏感数据；误将Base64视为加密而放松管控；更新配置后未重启Pod导致业务仍读取旧值；以及YAML中key拼写错误引发CreateContainerConfigError。规避策略需多管齐下：首先，启用etcd静态加密（EncryptionConfiguration）确保Secret落盘安全；其次，严格遵循最小权限原则，通过Role与RoleBinding限制Secret的get/list权限；第三，引入Sealed Secrets或External Secrets Operator对接HashiCorp Vault、AWS Secrets Manager等外部密钥管理系统，实现凭证的集中管控与自动轮转；最后，在CI/CD环节加入配置校验脚本，并采用GitOps模式进行版本追踪，从源头杜绝配置漂移与人为失误。