Configuring your application routes

When your cluster is provisioned, a cloud-specific load balancer is created to route application traffic into the cluster. The domain for your load balancer is configured to route application traffic via http(s)://*.<cluster-id>.<shard-id>.p[0-9] The <shard-id> is a random four-character string assigned to your cluster at creation time.

If you want to use custom domain names for your application routes, OpenShift Dedicated supports CNAME records in your DNS configuration that point to elb.apps.<cluster-id>.<shard-id>.p[0-9] While elb is recommended as a reminder for where this record is pointing, you can use any string for this value. You can create these CNAME records for each custom route you have, or you can create a wildcard CNAME record. For example:

*    CNAME

This allows you to create routes like and without having to update your DNS every time.

Customers with configured private connections to the cluster have the option of requesting a second application router, so that application routes can be configured as internal-only or externally available. The domain for this router will be identical to the first, with the exception of using apps2 instead of the apps subdomain used by the default router. All application routes are always exposed on the default, apps router. If you create your second application router without any label matching configured, then all application routes would also be exposed on the apps2 router. If you provide a label match configuration for your second application router, then you must specify this label on each route that you wish to be exposed on the second application router.

Red Hat’s recommendation for two application routers is to set the default router as private, and leave the additional application router as public with a label match similar to route=external to help make it clear what would happen to that route.

Using the Red Hat recommendation, in order to expose a new, external route for an existing service, apply the label route=external and manually define a host name that uses the apps2 domain instead of the default apps domain:

$ oc expose service <service-name> -l route=external --name=<custom-route-name> --hostname=<custom-hostname>.apps2.<cluster-id>.<shard-id>

Alternatively, you can use a custom domain:

$ oc expose service <service-name> -l route=external --name=<custom-route-name> --hostname=<custom-domain>

Exposing TCP services

OpenShift Dedicated routes expose applications by proxying traffic through HTTP/HTTPS(SNI)/TLS(SNI) to pods and services. A LoadBalancer service creates an AWS Elastic Load Balancer (ELB) for your OpenShift Dedicated cluster, enabling direct TCP access to applications exposed by your LoadBalancer service.

LoadBalancer services require an additional purchase. Contact your sales team if you are interested in using LoadBalancer services for your OpenShift Dedicated cluster.

Checking your LoadBalancer Quota

By purchasing LoadBalancer services, you are provided with a quota of LoadBalancers available for your OpenShift Dedicated cluster.

$ oc describe clusterresourcequota loadbalancer-quota
Name:       loadbalancer-quota
Labels:     <none>
Resource        Used    Hard
--------        ----    ----
services.loadbalancers  0   4

Exposing TCP service

You can expose your applications over an external LoadBalancer service, enabling access over the public Internet.

$ oc expose dc httpd-example --type=LoadBalancer --name=lb-service
service/lb-service created

Creating an internal-only TCP service

You can alternatively expose your applications internally only, enabling access only through AWS VPC Peering or a VPN connection.

$ oc expose dc httpd-example --type=LoadBalancer --name=internal-lb --dry-run -o yaml | awk '1;/metadata:/{ print "  annotations:\n \"true\"" }' | oc create -f -
service/internal-lb created

Enabling LoadBalancer access logs

You may, optionally, create an S3 bucket within your own AWS account, and configure the LoadBalancer service to send access logs to this S3 bucket at predefined intervals.


You must first create the S3 bucket within your own AWS account, in the same AWS region that your OpenShift Dedicated cluster is deployed. This S3 bucket can be configured with all public access blocked, including system permissions. Once your S3 bucket is created, you must attach a policy to your bucket as outlined by AWS.

Configuring the LoadBalancer service

Update and apply the following annotations to your service YAML definition, prior to creating the object in your cluster.

  name: my-service
    # Specifies whether access logs are enabled for the load balancer "true"
    # The interval for publishing the access logs. You can specify an interval of either 5 or 60 (minutes). "60"
    # The name of the Amazon S3 bucket where the access logs are stored "my-bucket"
    # The logical hierarchy you created for your Amazon S3 bucket, for example `my-bucket-prefix/prod`
    # This must match the prefix specified in the S3 policy "my-bucket-prefix/prod"

Creating the LoadBalancer service

Once the annotations have been saved into a YAML file, you can create it from the command line:

$ oc create -f loadbalancer.yml
service/my-service created

Using your TCP Service

Once your LoadBalancer service is created, you can access your service by using the URL provided to you by OpenShift Dedicated. The LoadBalancer Ingress value is a URL unique to your service that remains static as long as the service is not deleted. If you prefer to use a custom domain, you can create a CNAME DNS record for this URL.

$ oc describe svc lb-service
Name:                     lb-service
Namespace:                default
Labels:                   app=httpd-example
Annotations:              <none>
Selector:                 name=httpd-example
Type:                     LoadBalancer
LoadBalancer Ingress:
Port:                     <unset>  8080/TCP
TargetPort:               8080/TCP
NodePort:                 <unset>  31409/TCP
Endpoints:                <none>
Session Affinity:         None
External Traffic Policy:  Cluster