OpenShift Architecture

5 min readApr 24, 2021

OpenShift is a layered system designed to expose underlying Docker-formatted container image and Kubernetes concepts as accurately as possible, with a focus on easy composition of applications by a developer.

What is OpenShift

Red Hat OpenShift Container Platform unites developers and IT operations on a single platform to build, deploy, and manage applications consistently across hybrid cloud and multi-cloud infrastructures.

OpenShift Container Platform — platform as a service built around docker containers orchestrated and managed by Kubernetes on a foundation of Red Hat Enterprise Linux.

OpenShift helps businesses achieve greater value by delivering modern and traditional applications with shorter development cycles and lower operating costs.

What are the features of OpenShift?

Multi-Environment support.
One-click deployment.
Responsive web console.
Standardized workflow for developers.
Rest API support.
Support for remote SSH login to the application.
In-built database services.
Automatic application scaling.
The facility of support for release management and continuous integration.
IDE integration.

OpenShift Architecture

This is high level diagram of OpenShift cluster infrastructure. OpenShift is a layered system where in each layer is tightly bound with the other layer using Kubernetes and Docker cluster. The architecture of OpenShift is designed in such a way that it can support and manage Docker containers, which are hosted on top of all the layers using Kubernetes.

One of the key components of OpenShift architecture is to manage containerized infrastructure in Kubernetes. Kubernetes is responsible for Deployment and Management of infrastructure. In any Kubernetes cluster normally, we can have more than one master and multiple worker nodes, which ensures there is no point of failure in the setup.

OpenShift run on choice of our infrastructure. There is no lock for the infrastructure. It can be physical server , virtual server , private cloud or public cloud. Other wise we can combine these options together. For example couple of physical servers ,couple of virtual servers ,some of the servers are running in private cloud , some are running in public cloud with different region.

So now we will discuss components of the OpenShift cluster.

Master Node

A master node (Control Plane) is a node which controls and manages a set of worker nodes. Master node components, including the API server controller, Data store (etcd) ,Scheduler and management & replication.

API/ Authentication Server -Everything is based on the api communication. If you are a developer or if you are Custer administrator does not mean anything to the OpenShift Custer, you will directly communicate with the API and api will forward the request for the authentication first. If the authentication match successfully ,then you allow to do ,what ever the policy allowing you to do in the OpenShift cluster.

Data store -What every you have inside OpenShift cluster ,everything store inside the Data store , We call that ETCD. ETCD is the key-value store for OpenShift Container Platform, which persists the state of all resource objects. We can backup ETCD data regular.

Let say OpenShift cluster have 6 worker node, 2 master node that data will store in the Data store.
If you are running dot net core application inside 4 pods ,it will have that information inside the data store.

Scheduler -The scheduler is a monolithic component of Kubernetes. It is a control plane process which assigns Pods to Nodes.

Management and Replication -A replication controller ensures that a specified number of replicas of a pod are running at all times. If pods exit or are deleted, the replication controller acts to instantiate more up to the defined number and also the number of replicas desired, which can be adjusted at run time.

Let assume my dot net application run on the four pods ,then user will request to scale up to the six pods .That request first come to master node ,then api ,api check the authentication if the authentication success then it will check the data store. Currently my application run on four pods ,now user request to scale up six pods ,that mean cluster needs to create another two pods. Then the management and replication services do the creating of the other two pods.

Worker Node

A worker node is used to handle application related workload. A Pod always runs on a Node.

A Node is a worker machine in Kubernetes and may be either a virtual or a physical machine, depending on the cluster. Each Node is managed by the Master node in the cluster.

A Node can have multiple pods, and the Kubernetes master automatically handles scheduling the pods across the worker Nodes in the cluster.

The pod is consist of the docker images.

The docker image run on the docker container inside the Pod.

Each pod can have multiple docker containers running inside.

Persistent Storage

It is important to have persistent storage because containers are ephemeral, which means when they are restarted or deleted, any saved data is lost. Therefore, persistent storage prevents any loss of data and allows the use of stateful applications (RabbitMQ , ELK , Redis).

Image Registry

Images are going to be register form here. When we are running new application that particular image does not found from the node ,it will fetch that images from the image registry deploy that image to the container. OpenShift provides an integrated Docker registry. A registry contains a collection of one or more image repositories, which contain one or more tagged images.

Whenever a new image is pushed to the integrated registry, the registry notifies OpenShift about the new image then OpenShift react to new images, creating new builds and deployments.

Routing Layer

After deploy the application to the container ,user can create route form the OpenShift ,and then internet users can access that application from the internet.

Highly-Available OpenShift Cluster

The below diagram depicts the architecture of the environment for the production setup. It consists of 3 Masters and multiple Nodes. We further subdivide the nodes into two groups. Three of them(Yellow) get designated to run OpenShift’s router, image registry and other infrastructure services. We refer to these as Infrastructure Nodes. The other nodes (blue) will run the actual application workloads. We call these Application Nodes or Compute Nodes. In order to designate which nodes will do which job, we assign labels to them, which will be used by the OpenShift/Kubernetes scheduler to assign certain workload types to each (i.e. “infra” workloads vs “primary” workloads). See the sample inventory file at the bottom of this doc to see how those labels are assigned.