Router

routes

An OpenShift Origin administrator can deploy routers to nodes in an OpenShift Origin cluster, which enable routes created by developers to be used by external clients. The routing layer in OpenShift Origin is pluggable, and two available router plug-ins are provided and supported by default.

An OpenShift Origin route exposes a service at a host name, like www.example.com, so that external clients can reach it by name.

Routes are first-class objects that are HA-capable simply by scaling up your application component to two or more replicas. There is never a need to recreate your application or change its DNS entry.

Your administrator may have configured a DNS wildcard entry that will resolve to the OpenShift Origin node that is running the OpenShift Origin router.

Each route consists of a name (limited to 63 characters), a service selector, and an optional security configuration.

Router HA

Routers that have permission to view all of thelabelsin all projects can select routes to admit based on the labels. This is calledrouter sharding. This is useful when balancing incoming traffic load among a set of routers and when isolating traffic to a specific router. For example, company A goes to one router and company B to another.

Since a router runs on a specific node, when it or the node fails traffic ingress stops. The impact of this can be reduced by creating redundant routers on different nodes and using high availabilityto switch the router IP address when a node fails.

Router Plugin

Two available router plug-ins are provided and supported by default.

• HAProxy template router is the default plug-in.

  • The router’s container listens on the host network interface, unlike most containers that listen only on private IPs. The router proxies external requests for route names to the IPs of actual pods identified by the service associated with the route.

• The F5 router integrates with an existing F5 BIG-IP® system in your environment to synchronize routes.

Configure IP Failover

IP failover manages a pool of Virtual IP (VIP) addresses on a set of nodes.

https://docs.openshift.org/latest/dev_guide/expose_service/expose_internal_ip_router.html#expose-router-fail

Configuring the Router Service Account Permission

• Permission to specify host ports

  • Router service account must have permissions to a security context constraint (SCC) that allows it to specify host ports.

  • To add a 'hostnetwork' SCC to the router service account in the default namespace

    $ oc adm policy add-scc-to-user hostnetwork system:serviceaccount:default:router

• Permission to Access Labels

  • When namespace labels are used, for example in creating router shards, the service account for the router must havecluster-readerpermission.

    $ oadm policy add-cluster-role-to-user \
        cluster-reader \
        system:serviceaccount:default:router

Deploying the Router to a Labeled Node

To deploy the router to any node(s) that match a specifiednode label:

For example, if you want to create a router namedrouterand have it placed on a node labeled withregion=infra:

$ oc adm router router --replicas=1 --selector='region=infra' \
  --service-account=router

Duringadvanced installation, theopenshift_hosted_router_selectorandopenshift_registry_selectorAnsible settings are set toregion=infraby default. The default router and registry will only be automatically deployed if a node exists that matches theregion=infralabel.

Filtering Routes to Specific Routers

Using theROUTE_LABELSenvironment variable, you can filter routes so that they are used only by specific routers.

For example, if you have multiple routers, and 100 routes, you can attach labels to the routes so that a portion of them are handled by one router, whereas the rest are handled by another.

1. Aftercreating a router, use theROUTE_LABELSenvironment variable to tag the router:

   $ oc env dc/<router=name>  ROUTE_LABELS="key=value"

2. Add the label to the desired routes:

   oc label route <route=name>　key=value

3. To verify that the label has been attached to the route, check the route configuration:

   $ oc describe dc/<route_name>