OpenShift Ingress Operator Explained¶
Introduction¶
OpenShift Routes publish a Service through the cluster router. Route troubleshooting should confirm the route host, service target, endpoints, TLS termination mode, and router events.
When You Need This¶
Use this when traffic does not reach an OpenShift application, TLS behavior is unclear, DNS fails inside the cluster, or NetworkPolicy changes affect pod communication.
Key Objects and Commands¶
oc get route web -n app
oc describe route web -n app
oc get service web -n app
oc get endpoints web -n app
curl -Ik https://web-app.apps.ocp.example.com
Example output:
NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD
web web-app.apps.ocp.example.com web 8080 edge None
Step-by-Step Configuration¶
- Confirm the project and object names.
- Check route, service, endpoint, pod, and policy status.
- Apply only the network change that matches the failed layer.
Example YAML¶
apiVersion: route.openshift.io/v1
kind: Route
metadata:
name: web
spec:
host: web-app.apps.ocp.example.com
to:
kind: Service
name: web
port:
targetPort: 8080
tls:
termination: edge
Verification¶
oc get route web -n app
oc get endpoints web -n app
curl -Ik https://web-app.apps.ocp.example.com
Troubleshooting¶
Follow the path from client to route, route to service, service to endpoint, endpoint to pod, and pod to container port.
Common Mistakes¶
- Debugging the route before checking service endpoints.
- Using edge TLS when the backend expects passthrough TLS.
- Forgetting that route hostnames must be unique unless wildcard policy is configured.
Quick Checklist¶
- Confirm the active project.
- Inspect the exact object named in the error.
- Read recent events.
- Apply one focused fix.
- Verify status after the change.
Related Guides¶
Summary¶
OpenShift Ingress Operator Explained is easier to troubleshoot when each network layer is verified separately instead of treating every failure as a router problem.