“Red Hat® OpenShift® container platform offers a consistent hybrid cloud foundation for building and scaling containerized applications.” – openshift.com
If You have never worked in a hybrid cloud environment or build containerised applications before, chances are the statement leaves you none the wiser. In that case, this article is for You!
To better understand what Red Hat OpenShift really is, let us consult Wikipedia: “OpenShift is a family of containerization software developed by Red Hat.” In other words, OpenShift originally describes a set of containerization software products developed by a company called Red Hat – an IBM subsidiary since 2019.
Red Hat® OpenShift® Container Platform
The Red Hat® OpenShift® Container Platform is at the heart of the RedHat OpenShift ecosystem. It is effectively a container orchestration platform based on Kubernetes, that makes the lives of IT operators and developers easier, hence enhancing their productivity. That is achieved via a variety of tools. One major point is the standardization of their communication and alignment with each other via the use of containers, which are key to enable the portability of applications between both vendors and different environment, like between development and production environments. The platform is polyglot, supporting several technologies, allowing a wide adoption of one set of processes, rather than having different processes for different technologies, hereby significantly reducing the workload required to keep applications stable
Next, let us dive into what containers are and how the Container Platform is designed.
What is Containerization?
“A container is a unit of software that packages up code and all its dependencies, so the application runs quickly and reliably from one computing environment to another. A Docker container image is a lightweight, standalone, executable package of software that includes everything needed to run an application: code, runtime, system tools, system libraries and settings.” – Docker.com
Much like a shipping container in a port, an application container enables developers to easily transfer software from one environment to another. The idea is, that you develop code on your machine, describe how to deploy the code on a server and add that description to the project repository in a configuration file which can be compared with an application.properties file for Java projects. Once the project deployment description is set and done, the target environment will be able to build and deploy the application using the configurations specified in the file in the project path. There are more benefits to containerized software, but for now, that is what you need to know. The next section will elaborate where containers are part of the OpenShift architecture.
OpenShift is a hybrid cloud solution that runs on RHCOS (RedHat Core OS) and RHEL (RedHat Enterprise Linux). It is supported on public and private clouds and supports full-stack automation with both Installer Provisioned Infrastructure (IPI) and User Provisioned Infrastructure (UPI). Following is a list of essential components to understand the OpenShift architecture:
OpenShift consists Nodes, which are RHEL or RHCOS instances that have OpenShift installed. There are 2 types of Nodes: Worker Nodes that run end-user applications and Master nodes that manage Kubernetes Clusters, which means they orchestrate the worker nodes.
Master nodes are installed on RHCOS. Their main tasks are the orchestration and scheduling of worker nodes and the monitoring and maintenance of states with the OpenShift environment. In most cases, three master nodes are required for high availability.
Containers are the runtimes that where OCI (Open Container Initiative) compliant images are run. An image is effectively an application binary. Each Worker Node can run one or many containers.
We learned already that one Node can run one or several containers. In OpenShift, groups of containers may share a context or resources like volumes and IP addresses.
These groups of containers are called pods and constitute the smallest defined compute unit that can be deployed and managed, or orchestrated. A pod as such can be described as a meta object that wraps containers. In a non-containerized application landscape, pods may refer to applications that are executed on the same physical or virtual host.
Pods would usually run in an environment like a project, or namespace. They can either run to completion like builder or deployment pods, or they can continue running applications.
A Service is a set of pods with a defined access policy. Services provide permanent IP addresses and host names to ensure stable communication between applications irrespective or the creation and destruction of pods during scaling. The service information gets injected into containers to facilitate the discovery. They are part of allowing internal load balancing between applications.
Labels are key-value pairs that are part of a pods meta data. They allow organizing and grouping objects that are otherwise arbitrarily related, to make it possible for services to reference them as a group.
Etcd is the distributed key value data store for application and environment state information as well as RBAC (Role-based access control) rules.
Core OpenShift Components
The Core OpenShift Components are the main differentiator between OpenShift and Kubernetes. It contains an Operator Lifecycle Manager (OLM) that keeps workloads, middleware and other up to date. Its Web Console provides a customizable User interface for the Cluster Management. The OpenShift Infrastructure Services are a selection of system management services that provide monitoring, logging, OS tuning, Software Defined Networking (SDN), DNS and Kubelet.
The OpenShift Master Services provide the API endpoint for all system administration and deployment interactions. All requests are SSL encrypted and handled via Role based access control (RBAC). An Integration with identity management systems such as LDAP and OAuth are possible. A system level access to OpenShift nodes for users is therefore not needed.
The Masters monitor the pod health and can scale them based on the CPU utilization rate. If pods fail, the master automatically restarts pods that failed or exited. In the meantime, they route traffic to healthy pods to maintain the component availability.