Route vs Ingress on OpenShift Container Platform (OCP)

Introduction

When deploying applications on OpenShift Container Platform (OCP), exposing services to external users requires either Routes or Ingress. Both provide external access to workloads, but they differ in implementation, configuration, and flexibility. This article explores the key differences between Routes and Ingress, helping you choose the right approach for your application needs.

What is a Route in OpenShift?

A Route is an OpenShift-specific resource that provides external access to services running within the cluster. OpenShift Routes leverage the built-in HAProxy-based router to expose applications to the outside world.

Features of OpenShift Routes:

  • Layer 7 (HTTP/HTTPS) Load Balancing: Routes support HTTP, HTTPS, and TLS termination.
  • Path-Based Routing: Different applications can be served based on URL paths.
  • Custom Certificates: Routes allow custom TLS certificates for secure communication.
  • Wildcard Subdomains: You can define wildcard routes (e.g., *.apps.example.com).
  • Sticky Sessions: Supports session persistence using cookies.

Creating a Route:

A Route can be created using oc expose or by defining a Route YAML manifest:

1
2
3
4
5
6
7
8
9
10
11
12
apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: my-app-route
spec:
  to:
    kind: Service
    name: my-app-service
  port:
    targetPort: http
  tls:
    termination: edge

What is an Ingress in OpenShift?

Ingress is a standard Kubernetes resource used to manage external access to services within a cluster. Unlike Routes, which rely on the OpenShift router, Ingress controllers (e.g., Nginx, Traefik, or OpenShift’s HAProxy) handle traffic based on Ingress rules.

Features of Ingress:

  • Works Across Kubernetes and OpenShift: Ingress is Kubernetes-native and works across multiple platforms.
  • TLS Support: Supports secure communication using secrets for TLS certificates.
  • Multiple Ingress Controllers: OpenShift supports its HAProxy-based Ingress controller but can also use Nginx, Traefik, or Istio.
  • More Advanced Routing: Ingress allows advanced traffic management, such as redirects and rewrites.

Creating an Ingress:

A basic Ingress resource can be defined in YAML as follows:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ingress
spec:
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-app-service
            port:
              number: 80
  tls:
  - hosts:
    - myapp.example.com
    secretName: my-app-tls

Can You Use Ingress on OpenShift?

Yes, OpenShift supports Ingress, and you can use it instead of Routes. However, there are some considerations:

1. Using OpenShift’s Default Ingress Controller

  • OCP 4+ includes an Ingress Controller managed via the IngressController CRD in OpenShift’s openshift-ingress-operator namespace.
  • You can create Ingress resources like in a standard Kubernetes cluster.

Example Ingress YAML on OpenShift:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ingress
spec:
  rules:
  - host: myapp.apps.ocp-cluster.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-app-service
            port:
              number: 80
  tls:
  - hosts:
    - myapp.apps.ocp-cluster.com
    secretName: my-app-tls

2. Deploying a Custom Ingress Controller

If you want a different Ingress controller (e.g., Nginx, Traefik, Istio), you need to deploy it manually:

1
oc apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/main/deploy/static/provider/cloud/deploy.yaml

Then, configure your Ingress objects to use this controller.

Key Differences Between Route and Ingress

Feature Route Ingress
Platform OpenShift only Kubernetes & OpenShift
Controller OpenShift HAProxy router Various Ingress controllers
TLS Termination Built-in with OpenShift Uses Secrets for TLS certificates
Wildcard Domains Supported Not supported by default
Session Affinity Built-in via cookies Needs custom annotations
Custom Load Balancing Supported via HAProxy tuning Varies based on Ingress controller
Path-Based Routing Supported Supported

When to Use Route vs Ingress

  • Use Route if:

    • You are working in a pure OpenShift environment.
    • You need native OpenShift features like wildcard routes or sticky sessions.
    • You want built-in HAProxy load balancing and automatic TLS.

  • Use Ingress if:

    • You need a Kubernetes-native solution that works across platforms.
    • You want flexibility in choosing an Ingress controller (e.g., Nginx, Traefik, Istio).
    • You require more complex traffic management beyond OpenShift’s Route capabilities.

Conclusion

Both Route and Ingress play vital roles in exposing applications on OpenShift. If you need OpenShift-native features like wildcard domains and built-in TLS, Routes are the better choice. However, if you are working across Kubernetes environments or need advanced traffic control, Ingress provides more flexibility.

Understanding these differences helps you make an informed decision when designing network exposure strategies on OpenShift.