OpenShift Route无法连接Pod返回503错误问题排查求助

已确认的配置错误 #

• Service选择器配置错误：你提供的Service配置中，spec.selector错误添加了type: ClusterIP字段，而你的Deployment创建的Pod只有app: app-elastic标签，二者不匹配，导致Service没有关联到任何后端Pod，直接触发Router返回503错误。
  修正方案：删除Service spec.selector下的type: ClusterIP配置，仅保留app: app-elastic即可，type: ClusterIP是Service自身的类型字段，不应放在选择器中。
• Elasticsearch TLS协议不匹配：你当前Route使用edge TLS终止模式，Router解密HTTPS请求后，会以HTTP明文的方式转发到后端Service对应的Pod端口。你之前用相同配置部署Spring Boot正常，是因为Spring Boot默认8080端口是HTTP协议，适配该转发逻辑；但Elasticsearch 7.14.0默认开启安全配置，9200端口默认使用HTTPS协议，拒绝HTTP请求，即使Service匹配正确也会返回503。
  修正方案二选一：
  1. 将Route的TLS终止模式改为passthrough，直接将HTTPS请求透传给ES，由ES自身完成TLS解密，同时注意需要配置ES的证书信任逻辑；
  2. 关闭Elasticsearch的默认TLS配置，修改ES启动参数添加-e xpack.security.enabled=false -e xpack.security.http.ssl.enabled=false，让9200端口使用HTTP协议。

进一步排查思路 #

如果修改上述配置后仍然报错，可以按照以下步骤逐层排查：

1. 先确认Service关联的后端Endpoint是否正常：执行命令oc get endpoints app-elastic-svc -n app-test，查看输出中是否有Pod的IP+9200端口，如果没有说明Pod标签和Service选择器仍然不匹配。
2. 确认Pod内ES的端口协议：进入Pod执行curl -v http://localhost:9200和curl -kv https://localhost:9200，确认哪个能正常返回，对应调整Route的TLS终止模式。
3. 集群内直接访问Service验证连通性：找一个同命名空间的测试Pod，执行curl http://app-elastic-svc:8080（如果ES开TLS就用curl -k https://app-elastic-svc:8080），确认能否拿到ES的响应，如果拿不到说明Service到Pod的链路存在问题。
4. 查看Router日志定位错误：执行oc logs -n openshift-ingress <router-pod-name> | grep app-elastic-route，查看Router转发请求时的具体报错信息，是找不到后端还是握手失败。
5. 验证Route配置是否生效：执行oc describe route app-elastic-route -n app-test，确认Route关联的Service、端口、TLS配置都和预期一致。

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