Kubernetes通过Volume挂载ConfigMap文件注入环境变量时MySQL Pod启动报错

两种ConfigMap的使用方式存在本质差异，从根源上决定了配置能不能被应用识别：

• 此前使用的envFrom、单独指定env.valueFrom.configMapKeyRef的注入方式，是K8s内置的能力，会直接把ConfigMap中的键值对转换为容器PID 1进程可读取的进程级环境变量。MySQL、WordPress的官方镜像启动脚本本身就是设计为读取这些环境变量完成初始化校验的，因此这种方式可以正常生效。
• 本次使用的“ConfigMap作为Volume挂载”的方式，只是把ConfigMap的每一个键映射为容器文件系统中的静态文本文件，对应你的配置来说，挂载到/etc/env路径下后，目录内只会出现wordpress.conf、mysql.conf两个普通文本文件。K8s、容器运行时、应用启动脚本都不会自动把这两个文件的内容解析导出为进程环境变量，这些配置值从始至终都只是磁盘上的字符串，没有被传递给应用主进程。

报错正是来自于这个逻辑断层：MySQL启动脚本做初始化校验时，遍历自己能拿到的进程环境变量，找不到MYSQL_RANDOM_ROOT_PASSWORD这类必填的初始化参数，因此抛出“数据库未初始化且未指定密码配置”的错误。哪怕进入Pod手动执行source /etc/env/mysql.conf导出变量，这些变量也只会存在于临时shell会话中，无法传递给已经启动流程中的MySQL主进程，解决不了问题。

• 如果坚持要保留“把配置作为文件挂载”的形式，需要在容器启动流程中提前增加加载配置、导出环境变量的步骤，以MySQL容器为例，可以修改Deployment中容器的启动命令：

  command: ["/bin/bash", "-c", "source /etc/env/mysql.conf && docker-entrypoint.sh mysqld"]
  

  WordPress容器也需要在启动前对应加载自身的配置文件，才能让文件内的配置真正作用于应用进程。
• 更贴合官方镜像设计逻辑的做法，是把同一个ConfigMap里分属两个应用的配置拆分出来，通过envFrom分别注入对应容器的环境变量中，和你之前验证过可正常工作的逻辑保持一致，减少额外的启动步骤配置。
• 需要注意区分“应用环境变量”和“应用配置文件”两类配置的适用挂载场景：如果是要给MySQL传递my.cnf格式的运行时参数，才适合把ConfigMap挂载到/etc/mysql/conf.d/这类MySQL镜像默认会主动读取的配置路径下，不适合把环境变量格式的内容做成挂载文件指望被应用自动识别。

内容的提问来源于stack exchange，提问作者Kevin