OpenShift Routes vs Kubernetes Ingress — When to Use Each

The short answer¶

Routes are an OpenShift-native resource that predates Kubernetes Ingress. Ingress is the upstream Kubernetes standard. OpenShift supports both, but Routes offer more features out-of-the-box: fine-grained TLS control, router sharding, and passthrough TLS without needing a separate Ingress controller.

Creating a route¶

# Expose a service as a route (auto-generates hostname)
oc expose svc/my-service

# Specify the hostname
oc expose svc/my-service --hostname=app.example.com

# Check the route
oc get route my-service
# NAME         HOST/PORT             PATH   SERVICES     PORT   TERMINATION
# my-service   app.apps.cluster.com         my-service   8080

TLS termination modes¶

OpenShift Routes support three TLS strategies without requiring extra configuration:

Edge termination¶

TLS terminates at the router. Traffic between router and pod is plain HTTP.

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: my-app
spec:
  host: app.example.com
  to:
    kind: Service
    name: my-service
  port:
    targetPort: 8080
  tls:
    termination: edge
    insecureEdgeTerminationPolicy: Redirect

Passthrough¶

TLS is not terminated at the router. The encrypted stream reaches the pod. The app must serve TLS.

  tls:
    termination: passthrough

Re-encrypt¶

TLS terminates at the router and is re-encrypted toward the pod. Both connections use TLS.

  tls:
    termination: reencrypt
    destinationCACertificate: |
      -----BEGIN CERTIFICATE-----
      ...

Wildcard routes and router sharding¶

# Wildcard route — matches anything under *.apps.example.com
oc create route edge wildcard-app \
  --service=my-service \
  --wildcard-policy=Subdomain \
  --hostname=app.apps.example.com

Router sharding lets you dedicate specific routers to specific routes using labels:

# Label the route
metadata:
  labels:
    router: internal

# Configure the router to only serve matching labels
oc set env dc/router ROUTE_LABELS="router=internal"

Kubernetes Ingress on OpenShift¶

OpenShift's Ingress operator translates Ingress objects into Routes automatically:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-service
            port:
              number: 8080

# The Ingress controller creates a corresponding Route
oc get routes

When to use which¶

Key takeaways¶

• Routes are OpenShift-native and offer more TLS control with less configuration.
• OpenShift automatically converts Ingress objects to Routes, so both work.
• Use Routes when you need passthrough TLS, wildcard hostnames, or router sharding.
• Use Ingress when portability to other Kubernetes distributions matters.