OpenShift Ingress vs Route

Learn the differences between Kubernetes Ingress and OpenShift Route, understand their architectures, routing mechanisms, TLS support, Spring Boot implementation, and enterprise best practices.

Introduction

One of the most common interview questions for OpenShift developers is:

What is the difference between Kubernetes Ingress and OpenShift Route?

Both Ingress and Route expose applications running inside a Kubernetes or OpenShift cluster to external users.

However, they are not the same.

Ingress is a standard Kubernetes resource.
Route is an OpenShift-specific resource built on top of Kubernetes.

If you're developing Spring Boot microservices on OpenShift, understanding when to use Ingress and when to use Route is essential.

Learning Objectives

By the end of this article, you will understand:

What is Kubernetes Ingress?
What is an OpenShift Route?
Ingress vs Route
Architecture comparison
Request flow
TLS termination
Spring Boot examples
Enterprise use cases
Best practices

What is Kubernetes Ingress?

Ingress is a Kubernetes API object that manages external HTTP and HTTPS traffic to Services inside a cluster.

An Ingress resource does not process traffic by itself.

It requires an Ingress Controller such as:

NGINX Ingress Controller
HAProxy Ingress
Traefik
Kong
AWS ALB Controller

Kubernetes Ingress Architecture

flowchart TD

User[Internet User]

DNS[DNS]

Ingress[Ingress Controller]

Service[ClusterIP Service]

Pod1[Spring Boot Pod 1]

Pod2[Spring Boot Pod 2]

User --> DNS
DNS --> Ingress
Ingress --> Service
Service --> Pod1
Service --> Pod2

The Ingress Controller performs routing.

What is an OpenShift Route?

A Route is an OpenShift-native resource that exposes a Service externally.

Unlike Kubernetes Ingress:

No additional controller installation is required.
OpenShift includes a built-in Router based on HAProxy.

OpenShift Route Architecture

flowchart TD

User[Internet User]

Route[OpenShift Route]

Service[ClusterIP Service]

Pod1[Spring Boot Pod 1]

Pod2[Spring Boot Pod 2]

User --> Route
Route --> Service
Service --> Pod1
Service --> Pod2

OpenShift automatically manages the Router.

High-Level Comparison

flowchart LR

subgraph Kubernetes

Ingress

IngressController

Service1[Service]

Pods1[Pods]

Ingress --> IngressController
IngressController --> Service1
Service1 --> Pods1

end

subgraph OpenShift

Route

Service2[Service]

Pods2[Pods]

Route --> Service2
Service2 --> Pods2

end

OpenShift simplifies external routing by eliminating the need to manage a separate Ingress Controller.

Request Flow Comparison

Kubernetes

sequenceDiagram

participant Browser

participant DNS

participant IngressController

participant Service

participant Pod

Browser->>DNS: Resolve Host

DNS->>IngressController: Forward Request

IngressController->>Service: Route Request

Service->>Pod: Forward Traffic

Pod-->>Browser: Response

OpenShift

sequenceDiagram

participant Browser

participant Route

participant Service

participant Pod

Browser->>Route: HTTPS Request

Route->>Service: Forward

Service->>Pod: Load Balance

Pod-->>Browser: Response

The request flow is shorter and easier to manage.

Ingress vs Route

Feature	Kubernetes Ingress	OpenShift Route
Platform	Kubernetes	OpenShift
Controller Required	Yes	No
Built-in Router	No	Yes
HTTP Routing	✅	✅
HTTPS Support	✅	✅
TLS Termination	Depends on Controller	Built-in
Simplicity	Medium	Easy
Enterprise Support	Depends	Red Hat

Spring Boot Architecture

flowchart LR
    BROWSER["Browser"]
    ROUTE["OpenShift Route"]
    SERVICE["Payment Service"]

    subgraph APP["Spring Boot Application"]
        POD1["Pod 1"]
        POD2["Pod 2"]
    end

    BROWSER --> ROUTE
    ROUTE --> SERVICE
    SERVICE --> POD1
    SERVICE --> POD2

This is the most common architecture in OpenShift.

Kubernetes Ingress YAML

apiVersion: networking.k8s.io/v1
kind: Ingress

metadata:
  name: payment-ingress

spec:

  rules:

  - host: payment.demo.com

    http:

      paths:

      - path: /

        pathType: Prefix

        backend:

          service:

            name: payment-service

            port:

              number: 80

OpenShift Route YAML

apiVersion: route.openshift.io/v1
kind: Route

metadata:
  name: payment-route

spec:

  host: payment.apps.demo.com

  to:

    kind: Service

    name: payment-service

Notice how Route configuration is simpler.

TLS Support

Kubernetes Ingress

Requires:

Certificates
Secrets
Controller configuration

flowchart LR
    BROWSER["Browser"]
    INGRESS["Ingress Controller"]
    SERVICE["Kubernetes Service"]
    POD["Application Pod"]

    BROWSER -- "HTTPS" --> INGRESS
    INGRESS --> SERVICE
    SERVICE --> POD

OpenShift Route

TLS is configured directly on the Route.

tls:
  termination: edge

Supported modes:

Edge
Passthrough
Re-encrypt

TLS Architecture

flowchart LR
    BROWSER["Browser"]
    ROUTE["OpenShift Route"]
    SERVICE["Service"]
    PODS["Spring Boot Pods"]

    BROWSER -- "HTTPS" --> ROUTE
    ROUTE --> SERVICE
    SERVICE --> PODS

Enterprise Banking Example

Suppose a banking platform exposes multiple APIs.

flowchart TD
    USERS["Customers"]
    ROUTE["OpenShift Route"]
    GATEWAY["API Gateway"]

    PAY["Payment Service"]
    ACC["Account Service"]
    LOAN["Loan Service"]

    PAYPODS["Payment Pods"]
    ACCPODS["Account Pods"]
    LOANPODS["Loan Pods"]

    USERS --> ROUTE
    ROUTE --> GATEWAY

    GATEWAY --> PAY
    GATEWAY --> ACC
    GATEWAY --> LOAN

    PAY --> PAYPODS
    ACC --> ACCPODS
    LOAN --> LOANPODS

The Route exposes only the API Gateway.

Internal services remain private.

Multi-Tenant Routing

flowchart LR
    INTERNET["Internet"]
    ROUTE["OpenShift Route"]

    BANK["Banking App"]
    INS["Insurance App"]
    HEALTH["Healthcare App"]

    INTERNET --> ROUTE
    ROUTE --> BANK
    ROUTE --> INS
    ROUTE --> HEALTH

A single OpenShift cluster can host multiple business applications.

Advantages of Ingress

Kubernetes standard
Cloud portable
Multiple controller choices
Advanced routing
Flexible annotations

Advantages of Route

Native OpenShift feature
Built-in HAProxy Router
Easier configuration
Integrated TLS
Enterprise support
Less operational overhead

When to Use Ingress?

Use Ingress when:

Running a standard Kubernetes cluster
Supporting multiple cloud providers
Using NGINX, Traefik, or Kong
Needing advanced routing features

When to Use Route?

Use Route when:

Running OpenShift
Deploying Spring Boot microservices
Wanting built-in HTTPS
Minimizing operational complexity
Using Red Hat-supported infrastructure

Common Mistakes

❌ Installing an external Ingress Controller unnecessarily in OpenShift.

❌ Exposing internal microservices directly.

❌ Using HTTP instead of HTTPS.

❌ Forgetting TLS certificates.

❌ Misconfiguring DNS records.

Best Practices

Use Routes for OpenShift-native applications.
Use HTTPS in every environment.
Expose only API Gateway services.
Keep internal services private.
Configure health probes.
Use custom domains for production.
Monitor Route metrics.
Store Route YAML in Git.

Summary

Ingress and Route solve the same problem but are designed for different platforms.

Key takeaways:

Kubernetes uses Ingress with an external Ingress Controller.
OpenShift uses Routes with a built-in HAProxy Router.
Routes simplify external access and TLS management.
Spring Boot applications on OpenShift typically use Routes instead of Ingress.
Choose the networking resource that matches your platform rather than trying to force one approach everywhere.

Interview Questions

What is Kubernetes Ingress?
What is an OpenShift Route?
What is the difference between Ingress and Route?
Does Ingress require an Ingress Controller?
Which Router does OpenShift use internally?
What TLS termination types are supported by OpenShift Routes?
Which is simpler to configure for OpenShift applications?
Can OpenShift support Kubernetes Ingress resources?
Why do enterprises often expose only an API Gateway?
When should you choose Ingress over Route?