OpenShift Routes Explained

Learn how OpenShift Routes expose Spring Boot applications to external users, understand Route architecture, TLS termination, Route types, and production best practices.

Introduction

When a Spring Boot application is deployed to OpenShift, it runs inside Pods that are only accessible within the cluster.

Even after creating a Service, the application is still not accessible from the Internet because a Service only provides internal cluster communication.

To expose an application externally, OpenShift introduces a resource called a Route.

A Route provides a public URL, performs HTTP/HTTPS routing, supports TLS termination, and forwards requests to the appropriate Service.

Unlike standard Kubernetes, which primarily uses Ingress, OpenShift offers Routes as a native and simplified solution for exposing applications.

Learning Objectives

By the end of this article, you will understand:

What is an OpenShift Route?
Why Routes are required
Route architecture
Route vs Service
Route vs Kubernetes Ingress
Route types
TLS termination
Spring Boot implementation
Enterprise networking
Best practices

Application Networking Before Route

Without a Route, only internal applications can access the Service.

flowchart LR
    A[Payment Service]
    --> B[Payment Pod 1]

    A --> C[Payment Pod 2]

External users cannot reach the application.

Application Networking With Route

A Route exposes the Service outside the cluster.

flowchart LR
    A[Browser]

    --> B[OpenShift Route]

    --> C[ClusterIP Service]

    --> D[Spring Boot Pod 1]

    C --> E[Spring Boot Pod 2]

The Route acts as the public entry point.

What is an OpenShift Route?

An OpenShift Route is a resource that exposes an internal Service to external users.

It provides:

Public URL
DNS
HTTP routing
HTTPS routing
SSL/TLS termination
Load balancing

Think of a Route as an enterprise reverse proxy managed by OpenShift.

Route Architecture

flowchart TD

User[Internet User]

Route[OpenShift Route]

Service[ClusterIP Service]

Pod1[Spring Boot Pod 1]

Pod2[Spring Boot Pod 2]

DB[(PostgreSQL)]

User --> Route

Route --> Service

Service --> Pod1

Service --> Pod2

Pod1 --> DB

Pod2 --> DB

Every external request follows this path.

Request Flow

sequenceDiagram

participant User

participant Route

participant Service

participant Pod

participant SpringBoot

participant Database

User->>Route: HTTPS Request

Route->>Service: Forward Request

Service->>Pod: Load Balance

Pod->>SpringBoot: Process Request

SpringBoot->>Database: Query

Database-->>SpringBoot: Response

SpringBoot-->>User: HTTP Response

Route vs Service

Route	Service
External Access	Internal Access
Public URL	Cluster DNS
HTTP/HTTPS	TCP/UDP
Internet Traffic	Internal Traffic
TLS Support	No TLS Termination

Relationship:

Browser
    ↓
Route
    ↓
Service
    ↓
Pods

Route vs Kubernetes Ingress

OpenShift Route	Kubernetes Ingress
Native OpenShift Feature	Kubernetes Resource
Simple Configuration	Requires Ingress Controller
Built-in Router	External Controller
TLS Built-in	Depends on Controller
Developer Friendly	More Flexible

OpenShift internally uses HAProxy-based Routers to implement Routes.

Route Types

OpenShift supports four Route types:

Edge
Passthrough
Re-encrypt
Insecure (HTTP)

Edge Termination

SSL is terminated at the OpenShift Router.

flowchart LR

Browser

--> HTTPS

--> Router

--> HTTP

--> Service

--> Pod

Use Case:

Most web applications
Spring Boot REST APIs
Internal enterprise portals

Passthrough Termination

The encrypted traffic reaches the application without being decrypted by the Router.

flowchart LR
    BROWSER["Browser"]
    ROUTER["OpenShift Router"]
    POD["Spring Boot Pod"]

    BROWSER -- "HTTPS encrypted" --> ROUTER
    ROUTER -- "HTTPS still encrypted" --> POD

Use Case:

Banking
Financial systems
Mutual TLS

Re-encrypt Termination

The Router decrypts and then encrypts traffic again before forwarding it.

flowchart LR
    CLIENT["Browser"]
    HTTPS1["HTTPS"]
    ROUTER["OpenShift Router"]
    HTTPS2["HTTPS (New TLS Session)"]
    SERVICE["Service"]
    POD["Spring Boot Pod"]

    CLIENT --> HTTPS1
    HTTPS1 --> ROUTER
    ROUTER --> HTTPS2
    HTTPS2 --> SERVICE
    SERVICE --> POD

Use Case:

Highly secure enterprise applications

Route YAML Example

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

metadata:
  name: payment-route

spec:

  host: payment.apps.demo.com

  to:
    kind: Service
    name: payment-service

  port:
    targetPort: 8080

Create Route:

oc apply -f route.yaml

Verify Routes

List all Routes.

oc get routes

Example:

NAME            HOST

payment-route   payment.apps.demo.com

Describe Route

oc describe route payment-route

Useful information:

Host
Target Service
TLS
Labels
Events

Create Route Using CLI

Expose an existing Service.

oc expose service payment-service

OpenShift automatically creates a Route.

Enterprise Banking Example

A banking platform contains multiple microservices.

flowchart TD
    CUSTOMER["Customer"]
    ROUTE["Banking Route"]
    GATEWAY["API Gateway Service"]

    PAYMENT["Payment Service"]
    ACCOUNT["Account Service"]
    CUSTOMERAPI["Customer Service"]

    PAYPODS["Payment Pods"]
    ACCPODS["Account Pods"]
    CUSTPODS["Customer Pods"]

    CUSTOMER --> ROUTE
    ROUTE --> GATEWAY

    GATEWAY --> PAYMENT
    GATEWAY --> ACCOUNT
    GATEWAY --> CUSTOMERAPI

    PAYMENT --> PAYPODS
    ACCOUNT --> ACCPODS
    CUSTOMERAPI --> CUSTPODS

The Route exposes only the API Gateway while internal services remain private.

Multi-Service Architecture

flowchart LR

Browser

--> Route

Route

--> Gateway

Gateway

--> Payment

Gateway

--> Loan

Gateway

--> Customer

Payment --> PaymentDB[(Payment DB)]

Loan --> LoanDB[(Loan DB)]

Customer --> CustomerDB[(Customer DB)]

This is a common enterprise microservices architecture.

TLS Configuration

Enable HTTPS.

tls:

  termination: edge

Supported values:

edge
passthrough
reencrypt

Route Load Balancing

One Route can distribute traffic across multiple Pods.

flowchart TD

Route

--> Service

Service

--> Pod1

Service

--> Pod2

Service

--> Pod3

Service

--> Pod4

Traffic is automatically balanced.

Route and Rolling Deployment

During deployment, the Route continues forwarding requests.

flowchart LR

Users

--> Route

Route

--> Service

Service

--> PodV1

Service

--> PodV2

Users experience zero downtime.

Common Issues

Route Not Accessible

Verify:

oc get routes

Ensure the Route exists.

Service Not Found

Check:

oc get svc

Verify the Route points to the correct Service.

404 Error

Possible causes:

Incorrect host
Wrong Service name
Missing Pods

TLS Errors

Verify:

Certificates
Route termination
Browser trust

Best Practices

Always use HTTPS.
Use Edge termination unless stronger security is required.
Use meaningful Route names.
Keep Routes under source control.
Expose only API Gateway services.
Never expose internal databases.
Enable health probes.
Monitor Route metrics.
Use custom domains for production.

Advantages

Easy external access
Automatic DNS integration
Built-in SSL support
Load balancing
Zero-downtime deployments
Native OpenShift feature
Simplified networking
Enterprise-ready

Summary

Routes are one of OpenShift's most valuable networking features.

Key takeaways:

A Route exposes an internal Service to external users.
Services handle internal networking, while Routes provide Internet access.
OpenShift supports Edge, Passthrough, and Re-encrypt TLS termination.
Routes integrate with Services to provide load balancing and high availability.
Most Spring Boot applications use Edge termination for secure HTTPS access.
Routes simplify networking compared to managing Kubernetes Ingress resources directly.

Interview Questions

What is an OpenShift Route?
Why do we need Routes if Services already exist?
What is the difference between a Route and a Service?
How does a Route expose a Spring Boot application?
What are the different TLS termination types?
What is Edge termination?
When should Passthrough termination be used?
What is the difference between Route and Kubernetes Ingress?
How do you create a Route using the OpenShift CLI?
What are the best practices for exposing production applications?