Services and Routes

Hello — welcome to this lesson. In this article we’ll cover Services and Routes in OpenShift, recap the core Kubernetes concepts, and show how Services and Routes work together to expose and load-balance applications. You’ll learn when to use a Service, how Services map to pods, and how Routes expose Services to external users with TLS and traffic-splitting options.

What is a Service?

A Service in OpenShift (and Kubernetes) is a stable network endpoint that provides access to a set of pods. Services decouple clients from pod IPs so you can update or replace pods without changing application configuration. Common uses:

Front-end → back-end communication through a Service
Back-end → data-processing components
Exposing an application to end users using a Route
Accessing external data stores via Service-backed connectors

Each Service receives:

an internal ClusterIP (used for intra-cluster connectivity),
DNS entries,
a selector that matches pod labels,
a port (clients use this),
and a targetPort (the port on the pod/container).

Services are linked to pods using label selectors. Example selector:

selector:
  deploymentconfig: simple-webapp-docker

Service details (selectors, service port, targetPort) are visible in the OpenShift web console.

A presentation slide titled "Service" showing a diagram and UI details for a Kubernetes/OpenShift service named simple-webapp-docker (selector deploymentconfig=simple-webapp-docker) with IP 172.30.85.124 and port 8080. It illustrates user traffic flowing to the service and down to the underlying containers/pods.

A Service selector matches pod labels. The targetPort can be a number or a named port defined in the pod/container spec. Using a Service decouples clients from pod IPs and enables rolling updates without breaking connectivity.

Useful oc commands:

# List services in the current project
oc get svc

# Describe a Service to view selector, ports, and endpoints
oc describe svc simple-webapp-docker

# Expose a DeploymentConfig or Service via a Route (see Routes section for details)
oc expose svc/simple-webapp-docker --hostname=`www.somewebapp.com`

Table — key Service fields and meaning:

Field	Meaning	Example
`selector`	Labels used to select backend pods	`deploymentconfig=simple-webapp-docker`
`port`	Port that clients talk to on the Service	`8080`
`targetPort`	Port on the pod/container receiving traffic	`8080` or named port like `http`
`ClusterIP`	Internal IP for intra-cluster communication	`172.30.85.124`

Routes — exposing Services externally

A Route maps a hostname (for example www.somewebapp.com) to a Service and acts like a reverse proxy (e.g., HAProxy). Routes can provide:

load balancing,
TLS termination,
path-based routing (depending on router),
traffic splitting for A/B tests or staged rollouts.

Load-balancing algorithms available in OpenShift Routes:

Source (default) — session affinity by client IP (sticky sessions)
Round Robin — evenly distributes requests
Least Connections — routes to the backend with the fewest active connections

TLS and insecure traffic policies are configured in the Route’s Security/TLS settings. You can terminate TLS at the router (edge), re-encrypt to the backend, or passthrough TLS depending on your needs.

A slide titled "Route - Security" showing a left-side flow diagram of users accessing a webapp URL through a Route to a Service and backend pods, and a right-side screenshot of a security/TLS settings panel (TLS termination and insecure traffic options).

When configuring TLS termination, ensure certificates and keys are stored and rotated securely. If you allow Insecure Traffic, understand whether HTTP is accepted, redirected to HTTPS, or rejected to avoid exposing sensitive data.

Quick example — create a simple edge-terminated route using oc:

oc expose svc/simple-webapp-docker --hostname=`www.somewebapp.com` \
  --name=`simple-webapp-route` --port=8080

If you need more control, create a Route YAML and apply it with oc apply -f route.yaml.

Traffic splitting (A/B testing, canary, staged rollouts)

Routes support splitting traffic across multiple Services so you can:

run A/B tests,
shift a percentage of traffic to a canary version,
gradually roll out new functionality.

In the OpenShift console, the Alternate Services or split-traffic UI lets you add another Service and set weight percentages. Changing the slider updates the traffic distribution between Services.

A diagram titled "Route — Split Traffic" showing users hitting https://www.somewebapp.com being routed and split between two backend services (with IPs and port 8080) for A/B testing. On the right is an "Alternate Services" UI panel with a split-traffic option and a slider setting service weights (50/50).

Adjusting service weights makes it easy to run experiments and shift traffic based on metrics. Table — Services vs Routes at a glance:

Resource	Purpose	Examples / Notes
Service	Stable in-cluster endpoint that load-balances to pods	`ClusterIP`, `port`, `targetPort`, label selector
Route	Exposes a Service externally via a hostname	TLS termination, load balancing, traffic splitting

Example Service and Route YAML

Service (simplified):

apiVersion: v1
kind: Service
metadata:
  name: simple-webapp-docker
spec:
  selector:
    deploymentconfig: simple-webapp-docker
  ports:
    - protocol: TCP
      port: 8080
      targetPort: 8080

Route (edge TLS termination, simplified):

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: simple-webapp-route
spec:
  host: www.somewebapp.com
  to:
    kind: Service
    name: simple-webapp-docker
  port:
    targetPort: 8080
  tls:
    termination: edge
    insecureEdgeTerminationPolicy: Redirect

Links and references

OpenShift Routes documentation: https://docs.openshift.com
Kubernetes Services overview: https://kubernetes.io/docs/concepts/services-networking/service/
Router and HAProxy concepts: https://docs.openshift.com/container-platform/latest/networking/routes/route-configuration.html

Let’s move to the demo on Services and Routes.

Introduction

Pre-Requisite - Docker and Kubernetes

Getting Started with OpenShift

OpenShift Concepts - Projects and Users

Concepts - Builds and Deployments

Networks, Services, Routes and Scaling

Storage, Templates and Catalog

Conclusion and APPENDIX

Services and Routes

What is a Service?

Routes — exposing Services externally

Traffic splitting (A/B testing, canary, staged rollouts)

Example Service and Route YAML

Links and references

Watch Video

​What is a Service?

​Routes — exposing Services externally

​Traffic splitting (A/B testing, canary, staged rollouts)

​Example Service and Route YAML

​Links and references

Watch Video

What is a Service?

Routes — exposing Services externally

Traffic splitting (A/B testing, canary, staged rollouts)

Example Service and Route YAML

Links and references