Kubernetes（OpenShift）跨命名空间Pod间请求返回Null问题

核心问题拆解 #

1. 外部URL路由访问的SSL错误 #

OpenShift路由是为外部流量设计的，内部Pod访问时会遇到两个常见问题：

• 路由的SSL证书通常绑定外部域名，内部访问时请求的域名/IP与证书CN不匹配，触发SSL验证失败；
• 流量绕经外部入口再返回内部，网络路径冗余，还可能触发集群的防火墙或安全策略限制。

2. 内部服务名访问的异常 #

你遇到的「无错误但响应Null」「no route to host」问题，大概率和以下几点相关：

• 服务配置不匹配：
  检查服务的端口映射是否正确：执行oc get service servicename -n projectname -o yaml，确认spec.ports里的port是8080，targetPort和Pod容器的监听端口完全一致（注意是数字端口还是端口名称）。如果服务的port不是8080，访问8080自然会出现「no route to host」。
• 服务端应用的HOST校验：
  这很可能是你提到的「HOST字段设为外部URL而非集群主机」的问题——如果服务端应用配置了仅允许外部域名作为HOST头访问，那么用内部服务名发起请求时，请求的HOST头是servicename.projectname.svc.cluster.local:8080，服务端会拒绝处理并返回空响应。
• 客户端代码问题：
  若curl http://servicename.projectname.svc.cluster.local:8080/能拿到正常响应，但你的HttpClient返回Null，说明代码里没正确读取响应体（比如只发送了请求但没调用读取响应的方法）。

解决步骤 #

• 优先用内部服务名通信：
  1. 在发起请求的Pod内执行curl http://servicename.projectname.svc.cluster.local:8080/，验证基础连通性和响应内容；
  2. 若服务端有HOST校验，在HttpClient请求中手动设置Host头为外部URL域名，再用内部服务名地址发起请求；
  3. 核对服务与Pod的端口映射，确保服务的port和targetPort与应用监听端口一致；
  4. 检查目标Pod的状态：确认Pod处于Running且READY状态（oc get pods -n projectname）。
• 若必须走外部路由：
  将路由的SSL证书导入客户端Pod的信任存储（比如Java应用的cacerts），或临时关闭SSL验证（仅测试用，生产环境禁止）。

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