Openshift 3.x requires:
- Red Hat Enterprise Linux 7 subscription
- Red Hat Openshift subscription
- DNS - all cluster nodes require name resolution, and at least two records are required, one for the Openshift API, and a wildcard domain for all published applications. We have provided an example using Public DNS service from CloudFlare as an example.
- TLS certificates provided for both the API server and wildcard certificate for the default app subdomain used with the router. For more information, see Openshift documentation. If a custom certificate is not provided, self-signed certificates are generated.
- For HA, an external load balancer is required. See this documentation for more details.
- Shared Storage, either NFS or GlusterFS. GlusterFS may be provisioned with Openshift 3.x as part of the Openshift Container Storage offering.
Depending on the cloud platform, you may require different infrastructure. Review the System Requirements from the Openshift documentation.
Before following the rest of this documentation, it may be helpful to brush up on general Kubernetes knowledge. IBM has published a tutorial here.
Openshift internally expects that all hostnames of cluster nodes are internally resolvable from each other.
Internal DNS names
For example, the following DNS setup may be used, where
cluster.jkwong.xyz is the subdomain:
||internal endpoint for API, used by cluster nodes to register|
The internal API endpoint should be an A or CNAME record that points at a load balancer that forwards requests to the master nodes running the control plane using a round-robin algorithm. All cluster nodes will register themselves to the server to this endpoint using the domain name. During installation, this may be provided as
openshift_master_cluster_hostname in the ansible inventory file.
External DNS names
It is optional whether the cluster administrator wishes to expose the internal cluster domain to an external DNS server, but in many cases the cluster domain is used here so worker nodes are fully resolvable outside of the cluster as well.
For external clients, Openshift expects that clients can resolve the hostname of the API server in order to manage Openshift, and application clients can resolve the hostname of the wildcard subdomain.
||external endpoint for API, used by clients to manage Openshift|
||external wildcard domain for apps, used by clients to connect to workloads running in the platform such as Cloud Paks|
The Openshift application console is available on
api.cluster.jkwong.xyz and is specified by
openshift_master_cluster_public_hostname. It is very important to get this right as the web console uses the URL here as a redirect for OAuth clients and the address cannot be changed easily. The DNS record points at an externally routable address to a load balancer that forwards traffic to the master nodes.
The wildcard app subdomain is a default domain name for routes that do not have an explicit hostname defined. In our example, the Openshift cluster console is served at
console.apps.cluster.jkwong.xyz. The DNS record points at an externally routable address to a load balancer that forwards traffic to where the Openshift router is running, typically the