OpenShift V3中MySQL环境变量未自动填充，跨服务访问问题求助

刚看完你的问题，结合你最终找到的解决办法，整理了一套完整的排查和解决思路，帮你和其他踩坑的开发者理清逻辑：

你在OpenShift容器中部署MySQL服务后，遇到了几个核心连接问题：

• Java服务通过.properties文件里的${MYSQL_SERVICE_HOST}占位符，无法读取OpenShift自动注入的X_SERVICE_HOST/X_SERVICE_PORT类环境变量
• 之前能用的Cluster IP连接方式突然失效
• 导入MySQL的Secret成功获取了用户名、密码，但没拿到主机名和端口信息
• 尝试创建名为MYSQL的大写服务失败

1. OpenShift服务环境变量的核心规则 #

OpenShift确实会自动给集群内的服务生成环境变量，但有几个容易踩坑的点：

• 变量命名是小写服务名转全大写+下划线，比如你的MySQL服务如果叫mysql（小写），生成的变量就是MYSQL_SERVICE_HOST和MYSQL_SERVICE_PORT
• 如果服务名带连字符，会转成下划线，比如mysql-db会变成MYSQL_DB_SERVICE_HOST
• 你创建大写MYSQL服务失败是因为OpenShift的资源命名规范：服务名称只能包含小写字母、数字和连字符，不允许用大写

2. Cluster IP连接失效的常见原因 #

之前能用的Cluster IP突然用不了，大概率是这几种情况：

• MySQL服务被重新部署，Cluster IP被动态分配了新值（OpenShift默认给服务分配动态Cluster IP，除非你手动指定静态IP）
• MySQL服务的后端Pod未就绪，导致Endpoint状态异常，Cluster IP无法路由到实际的数据库Pod
• 命名空间的Network Policy限制了其他服务访问MySQL的3306端口

3. Secret里为什么没有主机名和端口？ #

Secret默认只存储MySQL的用户名、密码这类敏感配置，主机名和端口属于服务的网络配置，不会存在Secret中——这些信息只能通过OpenShift自动注入的服务环境变量获取，或者直接使用服务的DNS名称（比如同命名空间下直接用mysql，跨命名空间用mysql.你的命名空间.svc.cluster.local）

4. 你的最终解决方案：修复MySQL连接URL格式 #

你提到问题根源是连接URL存在多余的/，比如可能写成了jdbc:mysql://${MYSQL_SERVICE_HOST}//database_name（多了一个斜杠）。这种格式错误会导致即便环境变量已经正确注入，Java程序也无法正确解析主机地址，进而出现连接失败的假象。正确的URL格式应该是：

jdbc:mysql://${MYSQL_SERVICE_HOST}:${MYSQL_SERVICE_PORT}/database_name

以后再遇到类似问题，可以用这些方法快速排查：

• 进入Java服务的Pod内部，执行env命令，直接查看所有环境变量，确认MYSQL_SERVICE_HOST和MYSQL_SERVICE_PORT是否存在
• 在Java代码里临时打印环境变量值（比如System.out.println(System.getenv("MYSQL_SERVICE_HOST"))），排查是不是.properties文件的占位符解析出了问题
• 尝试用服务的DNS名称（比如同命名空间下直接写mysql）代替环境变量，测试连接是否正常

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