<commit_before>= Routing
{product-author}
{product-version}
:data-uri:
:icons:
:experimental:
:toc: macro
:toc-title:

toc::[]

== Overview
Routers provide external DNS mapping and load balancing to
link:kubernetes_model.html#service[services] over protocols that pass
distinguishing information directly to the router. Routers support the following
protocols:

- HTTP
- HTTPS
- WebSockets
- TLS with SNI

NOTE: WebSocket traffic uses the same route conventions and supports the same
TLS termination types as other traffic.

The router uses the service selector to watch the endpoints that support the
service, bypassing its logic and replacing it with the router's own. Routers
subscribe to a configuration and automatically update themselves with any
changes. Router may be containerized or virtual, converting any changes to API
calls to another system, such as *F5*.

Other capabilities exist to load-balance a service within a cluster. These
services are exposed via a configurable link relation between different
services, and ensure a set of services can be available.
link:../using_openshift/deployments.html[Deployments] can use these services as
local proxies for each host, or reuse the shared routing infrastructure.

As an OpenShift administrator, you can configure routers in your instance. This
allows developers to then set the route types for their projects.

== Route Types
Routes can be either secure or unsecure. Secure routes provide the ability to
use different types of TLS termination to serve certificates to the client.
Routers support link:#edge-termination[edge],
link:#passthrough-termination[passthrough], and
link:#re-encryption-termination[re-encryption] termination.

To create a secure route, specify the TLS termination of the route in a JSON
file.

.An Unsecure Route
====

----
{
    "kind": "Route",
    "apiVersion": "v1beta1",
    "metadata": {
        "name": "route-unsecure"
    },
    "id": "route-unsecure",
    "host": "www.example.com",
    "serviceName": "hello-nginx"
}
----
====

.A Secure Route Using Edge Termination
====

----
{
    "metadata": {
        "name": "route-edge"
    },
    "id": "route-edge",
    "apiVersion": "v1beta1",
    "kind": "Route",
    "host": "www.example.com",
    "serviceName": "hello-nginx",
    "tls": {
        "termination": "edge",
        "certificate": "CERT TEXT OMITTED FOR READABILITY",
        "key": "CERT TEXT OMITTED FOR READABILITY",
        "caCertificate": "CERT TEXT OMITTED FOR READABILITY"
     }
}
----
====

.An Unsecure Route with a Path:
====

----
{
    "kind": "Route",
    "apiVersion": "v1beta1",
    "metadata": {
        "name": "route-unsecure"
    },
    "id": "route-unsecure",
    "host": "www.example.com",
    "path": "/test",
    "serviceName": "hello-nginx"
}
----

====

IMPORTANT: While both secure and unsecure routes are possible with an OpenShift instance, Red Hat recommends a secure routing service.

== Path Based Routes
Path based routes specify a path component that can be compared against a URL. This implies that the traffic for the route is HTTP based. Routers should match routes based on the most specific path to the least. However, this depends on your implementation. For example:

*  For a route with www.example.com/test:
** www.example.com/test should be accessible
** www.example.com should not be accessible
*  For routes with www.example.com/test and www.example.com:
** www.example.com/test should be accessible
** www.example.com should be accessible
*  For routes with www.example.com:
** www.example.com/test should be accessible (matched by the host, not the route)
** www.example.com should be accessible

== Securing Routes
You can create a secure route to your pods by specifying the TLS termination of
the route and, optionally, providing certificates.

NOTE: Currently, TLS termination in OpenShift Beta relies on SNI for serving
custom certificates. Any non-SNI traffic received on port 443 has TLS
termination with a generic certificate. In the future, the ability to create
custom front ends within the router will allow all traffic to serve custom
certificates.

By default, OpenShift routes are unsecure, but can be set to any of the
following three types of secure TLS termination.

[[edge-termination]]
*Edge Termination*
<commit_msg>edits to example link format<commit_after>= Routing
{product-author}
{product-version}
:data-uri:
:icons:
:experimental:
:toc: macro
:toc-title:

toc::[]

== Overview
Routers provide external DNS mapping and load balancing to
link:kubernetes_model.html#service[services] over protocols that pass
distinguishing information directly to the router. Routers support the following
protocols:

- HTTP
- HTTPS
- WebSockets
- TLS with SNI

NOTE: WebSocket traffic uses the same route conventions and supports the same
TLS termination types as other traffic.

The router uses the service selector to watch the endpoints that support the
service, bypassing its logic and replacing it with the router's own. Routers
subscribe to a configuration and automatically update themselves with any
changes. Router may be containerized or virtual, converting any changes to API
calls to another system, such as *F5*.

Other capabilities exist to load-balance a service within a cluster. These
services are exposed via a configurable link relation between different
services, and ensure a set of services can be available.
link:../using_openshift/deployments.html[Deployments] can use these services as
local proxies for each host, or reuse the shared routing infrastructure.

As an OpenShift administrator, you can configure routers in your instance. This
allows developers to then set the route types for their projects.

== Route Types
Routes can be either secure or unsecure. Secure routes provide the ability to
use different types of TLS termination to serve certificates to the client.
Routers support link:#edge-termination[edge],
link:#passthrough-termination[passthrough], and
link:#re-encryption-termination[re-encryption] termination.

To create a secure route, specify the TLS termination of the route in a JSON
file.

.An Unsecure Route
====

----
{
    "kind": "Route",
    "apiVersion": "v1beta1",
    "metadata": {
        "name": "route-unsecure"
    },
    "id": "route-unsecure",
    "host": "www.example.com",
    "serviceName": "hello-nginx"
}
----
====

.A Secure Route Using Edge Termination
====

----
{
    "metadata": {
        "name": "route-edge"
    },
    "id": "route-edge",
    "apiVersion": "v1beta1",
    "kind": "Route",
    "host": "www.example.com",
    "serviceName": "hello-nginx",
    "tls": {
        "termination": "edge",
        "certificate": "CERT TEXT OMITTED FOR READABILITY",
        "key": "CERT TEXT OMITTED FOR READABILITY",
        "caCertificate": "CERT TEXT OMITTED FOR READABILITY"
     }
}
----
====

.An Unsecure Route with a Path:
====

----
{
    "kind": "Route",
    "apiVersion": "v1beta1",
    "metadata": {
        "name": "route-unsecure"
    },
    "id": "route-unsecure",
    "host": "www.example.com",
    "path": "/test",
    "serviceName": "hello-nginx"
}
----

====

IMPORTANT: While both secure and unsecure routes are possible with an OpenShift instance, Red Hat recommends a secure routing service.

== Path Based Routes
Path based routes specify a path component that can be compared against a URL. This implies that the traffic for the route is HTTP based. Routers should match routes based on the most specific path to the least. However, this depends on your implementation. For example:

*  For a route with _www.example.com/test_:
** _www.example.com/test_ should be accessible
** _www.example.com_ should not be accessible
*  For routes with _www.example.com/test_ and _www.example.com_:
** _www.example.com/test_ should be accessible
** _www.example.com_ should be accessible
*  For routes with _www.example.com_:
** _www.example.com/test_ should be accessible (matched by the host, not the route)
** _www.example.com_ should be accessible

== Securing Routes
You can create a secure route to your pods by specifying the TLS termination of
the route and, optionally, providing certificates.

NOTE: Currently, TLS termination in OpenShift Beta relies on SNI for serving
custom certificates. Any non-SNI traffic received on port 443 has TLS
termination with a generic certificate. In the future, the ability to create
custom front ends within the router will allow all traffic to serve custom
certificates.

By default, OpenShift routes are unsecure, but can be set to any of the
following three types of secure TLS termination.

[[edge-termination]]
*Edge Termination*

{'fraction_non_alphanumeric': 0.09296395038831576, 'fraction_numerical': 0.002318303002202388, 'mean_word_length': 3.995946728430805, 'pattern_counts': {'":': 54, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 26, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '781168', 'n_tokens_mistral': 2468, 'n_tokens_neox': 2338, 'n_words': 1054}