Dabbaghi.com

In OpenShift, a Route is an object that exposes a service to traffic coming from outside the cluster. OpenShift manages routing through a built-in component called the HAProxy-based Router. It watches for Route objects and automatically configures itself to forward traffic to the right service.

A simple example

Imagine you have a web application called my-app running as a Service on port 8080. Here is how you expose it with a Route:

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: my-app-route
spec:
  host: my-app.dabbaghi.com   # the public hostname
  to:
    kind: Service
    name: my-app              # the Service to forward to
  port:
    targetPort: 8080
  tls:
    termination: edge          # HTTPS at the router, HTTP to pod

Once you apply this, OpenShift automatically makes https://my-app.dabbaghi.com available. You do not need to configure a load balancer or install anything extra.

TLS options in Routes

Routes have built-in TLS support with three termination modes:

Edge:

TLS ends at the router. Traffic to the pod is plain HTTP.

Passthrough:

TLS is handled by the pod itself. Router passes encrypted traffic directly.

Re-encrypt:

TLS ends at the router, then a new TLS connection is made to the pod.

Comparing Routes with Kubernetes Ingress

If you have worked with plain Kubernetes, you know Ingress. It serves the same purpose — exposing services to external traffic — but the design is different.

Route:

OpenShift-native resource. Built-in router included. Works immediately after cluster setup with no extra configuration.

Built-in TLS ready Simple YAML

Ingress:

Standard Kubernetes resource. Requires a separate Ingress controller (nginx, Traefik, etc.) to be installed and configured.

Controller needed Portable Flexible

Side-by-side YAML comparison

Here is the same use case — expose a service at a hostname with HTTPS — written both ways:

OpenShift Route

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

Kubernetes Ingress

kind: Ingress
apiVersion: networking.k8s.io/v1
metadata:
  name: my-app-ingress
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
spec:
  ingressClassName: nginx          # must specify your controller
  tls:
    - hosts: [my-app.dabbaghi.com]
      secretName: my-app-tls       # cert must exist as a Secret
  rules:
    - host: my-app.dabbaghi.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: my-app
                port:
                  number: 8080

The Route version is noticeably shorter. The Ingress version requires you to reference a controller class and manage TLS certificates manually as Kubernetes Secrets.

If you are on OpenShift and do not need to run the same manifests on a plain Kubernetes cluster, Routes are the simpler and faster choice. You get TLS, hostname generation, and traffic management with very little YAML.

If you need portability — for example, deploying to both OpenShift and a managed Kubernetes service — Ingress is the better path. OpenShift also supports Ingress objects, so both can coexist in the same cluster.

OpenShift 4.x actually converts Ingress objects into Routes automatically behind the scenes. So if your team writes Ingress YAML, OpenShift still uses its Router to serve traffic.