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.
Top comments (0)