OpenShift Pod Running, but the Application Is Unreachable? Check the Service Port

Ramatech Innovations — Sat, 24 Oct 2026 12:11:28 +0000

A Pod showing Running does not prove that users can reach its application. One possible cause is a mismatch between the application's listening port and the Service's targetPort.

The example

Assume the application listens on TCP port 8080 and the Service exposes port 80. The Service incorrectly forwards traffic to port 80 on the selected Pods.

This is one possible diagnosis, not a conclusion to apply to every connectivity failure.

1. Inspect before changing anything

Replace the example namespace and resource names with your own:

oc get pods -n demo -l app=web -o wide
oc get service web -n demo -o yaml
oc get deployment web -n demo -o yaml
oc get endpointslices -n demo -l kubernetes.io/service-name=web

Confirm that the Service selector matches the intended Pods and inspect endpoint readiness. Check the application's actual listening port using its configuration and logs. Declaring a containerPort does not, by itself, make an application listen on that port.

2. Recognize the mismatch

The incorrect part of the Service could look like this:

ports:
  - name: http
    port: 80
    targetPort: 80

Here, port is the Service port; targetPort is the destination port on the selected Pods. They do not have to be identical.

3. Correct the source configuration

If the application actually listens on 8080, the corresponding Service configuration should be:

ports:
  - name: http
    port: 80
    targetPort: 8080

These YAML blocks are fragments, not complete Service manifests. Preserve the selector and other fields. Update the manifest in your source repository and deploy through your normal change process. Where a controller manages the Service, change its source configuration rather than relying on a manual edit that may be reverted.

4. Verify from inside the cluster

From an existing diagnostic Pod with curl installed:

oc exec -n demo <diagnostic-pod> -- curl -v --connect-timeout 5 http://web:80/

The example assumes that the diagnostic Pod is in the same namespace as the Service. Use a path with a known expected application response. An HTTP error response and a connection timeout are different outcomes; interpret the result rather than treating every non-200 response as a networking failure.

If the request still fails, investigate the application bind address, Pod readiness, Service selectors and NetworkPolicies. For external access, separately inspect the OpenShift Route, its selected Service port and any TLS configuration.

Takeaway

Check each connection separately: application listener, Pod readiness, Service selection, port mapping and external routing. Avoid changing multiple layers at once without evidence.

Reference

Kubernetes: Debug Services

DEV Community: Ramatech Innovations