Once your OpenShift Dedicated cluster is configured and ready to use, you can access it through the following paths:
Cluster ID: The unique cluster name provided by the customer during provisioning. It is lowercase, and only contains letters, numbers, and hyphens.
Console URL: The OpenShift Dedicated URL for the web console.
API URL: The OpenShift Dedicated URL for the OpenShift and Kubernetes REST API.
Registry URL: The OpenShift Dedicated URL for the private
registry. In addition to containing all images used by OpenShift Dedicated,
docker push can be used directly on the registry.
Metrics API URL: The OpenShift Dedicated URL for the Hawkular Metrics API.
Logging URL: The OpenShift Dedicated URL for the aggregate logging Kibana interface.
If an authentication callback URL is necessary, you can configure it with:
Additional information about your cluster, including usage, subscription information, and past and upcoming maintenance is available at https://dedicated.openshift.com.
If a virtual private cloud (VPC) peering connection was requested, the VPC peering request is initiated from the Red Hat OpenShift AWS account. First, accept the peering request , and then configure the Route Tables:
Log into your AWS Web Console.
Select the Route Table for your VPC (VPC → Route Tables).
Select the Routes tab.
Enter the Dedicated Cluster VPC CIDR block in the Destination text box.
Enter the Peering Connection ID in the Target text box.
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
<shard-id> is a
four-character string that is communicated to you after initial provisioning.
If you want to use custom domain names for your application routes, you should
set up a CNAME record in your DNS host to point to
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.1234.my-example.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.
Customers with configured VPC peering or VPN connections have the option of
requesting a second ELB, so that application routes can be configured as
internal-only or externally available. The domain for this ELB will be identical
to the first, with a different
<shard-id> value. By default, application
routes are handled by the internal-only router. To expose an application or
service externally, you must create a new route with a specific label,
To expose a new route for an existing service, apply the label
and define a host name that contains the secondary, public router shard ID:
$ oc expose service <service-name> -l route=external --name=<custom-route-name> --hostname=<custom-hostname>.<shard-id>.<cluster-id>.openshiftapps.com
Alternatively, you can use a custom domain:
$ oc expose service <service-name> -l route=external --name=<custom-route-name> --hostname=<custom-domain>
Access the status portal at https://status-dedicated.openshift.com. You can also subscribe to notifications via email, SMS, or RSS by changing your preferences in the status portal.
If you have questions about your environment or need to open a support ticket, you can open or view a support case in the Red Hat Customer Portal.
You can download the OpenShift Dedicated command line tools from your cluster’s web console. For help getting started with command line tools, see the Get Started with the CLI guide. You can also visit the Getting Started Guide for developers.
Dedicated administrators should view the Cluster Administration Overview for detailed information on available roles and permissions. This section also includes important topics such as managing quotas and configuring service accounts.
If your cluster has been configured with the NetworkPolicy SDN, OpenShift Dedicated administrators are able to create and modify NetworkPolicy objects. NetworkPolicy, by default, allows traffic communication between projects. Denying traffic between projects can be enabled by the creation of two NetworkPolicy objects.