We deliberately do without an introductory article about the importance of OpenShift and the advantages over a native Cubernet installation. There are enough articles about this on the net and Red Hat also writes about it:

Anyone who has ever needed a high-available Openshift installation for tests or demos, or simply wants to try out how such an environment behaves without much effort, is in the right place here.

For a customer demo we have fully automated the installation of an Openshift 3.11 installation based on the Microsoft OpenShift Container Platform Deployment Template (!

The link to the scripts and the manual can be found at the end of this article. But first we want to give an overview of the components of the installation in as few words as possible (a more detailed description can be found in the official documentation (

Component description

The following components will be deployed by our script

  • 3 Master Nodes
  • 2 Infrastructure Nodes
  • 2 Application Nodes
  • 1 Bastion host
  • Shared Storage / Persistent Storage
  • Load balancer for the applications
  • Load balancer for the master nodes

The following picture depicts the schematic connections of the components:


Master Nodes

The master manages the nodes of the cluster and determines which pods run on which nodes. The master node contains the control instances including the API server, the controller manager server and ETCD.

Application Nodes

The application nodes provide the runtime environment for containers.

Infrastructure Nodes

The Infrastructure Nodes run internally required components such as the Registry, Prometheus and Hawkular metrics as well as Elastic Search, Fluentd and Kibana(EFK) for aggregated logging.

Bastion host

The bastion host manages all installation processes, running the ansible scripts and provides secure access inside the OpenShift cluster network.

Shared Storage / Persistent Storage

For many application containers, as well as for the monitoring and logging containers mentioned above, non-volatile storage is required. In Azure we use Azure's storage, of course, but there are many other options (

Load balancer for the applications

A load balancer is required to direct application traffic to the correct node on which the pod is currently running. In our case the one from Azure.

Load balancer für die OpenShift Master Nodes

In order to distribute the requests to the master nodes, a load balancer is also required here.

The scripts

The scripts are available in our GitHub Repo The installation instructions can be found in the enclosed readme file.

If you should have problems with the use or suggestions for improvement, please contact us in the comments.

P.S. If this is still too much effort, we recommend the project Minishift ( With it you can install a working Openshift installation on your notebook.