Troubleshoot OpenShift Networking¶

Introduction¶

OpenShift networking troubleshooting starts with pod placement, service endpoints, DNS, and NetworkPolicy. OVN-Kubernetes also makes namespace and pod labels important for policy-driven traffic.

Symptoms¶

Typical symptoms include failed pods, route errors, denied requests, unhealthy operators, or command errors that repeat after retries.

Common Causes¶

• Creating a default deny policy without allow rules.
• Matching namespace labels that do not exist.
• Testing from a pod that has different labels than production traffic.

Step 1: Check the Current Status¶

oc get networkpolicy -n app

oc describe networkpolicy allow-web-to-api -n app

oc get pods -n app --show-labels

oc rsh deploy/web -n app curl -sS http://api:8080/health

Example output:

NAME               POD-SELECTOR   AGE
allow-web-to-api   app=api        12m

OK

Step 2: Inspect Logs and Events¶

oc get networkpolicy -n app

oc get endpoints api -n app

oc rsh deploy/web -n app -- curl -v http://api:8080/health

Step 3: Verify Configuration¶

Compare the object selectors, service account, image reference, route target, or operator status with the failing symptom. In OpenShift, events often show the exact admission, scheduling, pull, SCC, or route reason.

Example YAML¶

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-web-to-api
spec:
  podSelector:
    matchLabels:
      app: api
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: web
      ports:
        - protocol: TCP
          port: 8080

Step 4: Apply the Fix¶

Apply the smallest targeted fix: correct the selector, update the route or service port, link the pull secret, grant the specific RBAC or SCC permission, or repair the unhealthy operator dependency.

Step 5: Confirm the Problem Is Resolved¶

Run the verification commands again and confirm the status, events, and user-facing test all agree.

Common Mistakes¶

• Creating a default deny policy without allow rules.
• Matching namespace labels that do not exist.
• Testing from a pod that has different labels than production traffic.

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¶

• Openshift Must Gather Guide
• Troubleshoot Openshift Events
• Openshift Troubleshooting Checklist

Summary¶

Troubleshoot OpenShift Networking requires matching the symptom to the OpenShift object that owns it. Use oc status commands, events, logs, and focused verification so the fix is tied to evidence.