Networking | Getting started | OpenShift Dedicated 4

Configuring your application routes
Exposing TCP services

Configuring your application routes

When your cluster is provisioned, an AWS elastic load balancer (ELB) is created to route application traffic into the cluster. The domain for your ELB is configured to route application traffic via http(s)://*.<shard-id>.<cluster-id>.p1.openshiftapps.com. 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>.p1.openshiftapps.com. 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:

*.openshift.example.com    CNAME    elb.apps.my-example.a1b2.p1.openshiftapps.com

This allows you to create routes like app1.openshift.example.com and app2.openshift.example.com without having to update your DNS every time.

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 service-loadbalancers
Name:       service-loadbalancers
Labels:     <none>
Annotations:    <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 exposed

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    service.beta.kubernetes.io/aws-load-balancer-internal: 0.0.0.0/0" }' | oc create -f -
service/internal-lb exposed

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
IP:                       10.120.182.252
LoadBalancer Ingress:     a5387ba36201e11e9ba901267fd7abb0-1406434805.us-east-1.elb.amazonaws.com
Port:                     <unset>  8080/TCP
TargetPort:               8080/TCP
NodePort:                 <unset>  31409/TCP
Endpoints:                <none>
Session Affinity:         None
External Traffic Policy:  Cluster

Neworking