OpenShift – Architecture and Environment Introduction

Table of Contents

OpenShift – Architecture

OpenShift is a layered system wherein 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. Unlike the earlier version of OpenShift V2, the new version of OpenShift V3 supports containerized infrastructure. In this model, Docker helps in creation of lightweight Linux-based containers and Kubernetes supports the task of orchestrating and managing containers on multiple hosts.

and managing containers on multiple hosts.

OpenShift Container Platform Architecture

Components of OpenShift

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, we can have more than one master and multiple nodes, which ensures there is no point of failure in the setup.

Key Components of OpenShift Architecture

Kubernetes Master Machine Components

Etcd − It stores the configuration information, which can be used by each of the nodes in the cluster. It is a high availability key value store that can be distributed among multiple nodes. It should only be accessible by Kubernetes API server as it may have sensitive information. It is a distributed key value Store which is accessible to all.

API Server − Kubernetes is an API server which provides all the operation on cluster using the API. API server implements an interface which means different tools and libraries can readily communicate with it. A kubeconfig is a package along with the server side tools that can be used for communication. It exposes Kubernetes API”.

Controller Manager − This component is responsible for most of the collectors that regulate the state of the cluster and perform a task. It can be considered as a daemon which runs in a non-terminating loop and is responsible for collecting and sending information to API server. It works towards getting the shared state of the cluster and then make changes to bring the current status of the server to a desired state. The key controllers are replication controller, endpoint controller, namespace controller, and service account controller. The controller manager runs different kind of controllers to handle nodes, endpoint, etc.

Scheduler − It is a key component of Kubernetes master. It is a service in master which is responsible for distributing the workload. It is responsible for tracking the utilization of working load on cluster nodes and then placing the workload on which resources are available and accepting the workload. In other words, this is the mechanism responsible for allocating pods to available nodes. The scheduler is responsible for workload utilization and allocating a pod to a new node.

Kubernetes Node Components

Following are the key components of the Node server, which are necessary to communicate with the Kubernetes master.

Docker − The first requirement of each node is Docker which helps in running the encapsulated application containers in a relatively isolated but lightweight operating environment.

Kubelet Service − This is a small service in each node, which is responsible for relaying information to and from the control plane service. It interacts with etcd store to read the configuration details and Wright values. This communicates with the master component to receive commands and work. The kubelet process then assumes responsibility for maintaining the state of work and the node server. It manages network rules, port forwarding, etc.

Kubernetes Proxy Service − This is a proxy service which runs on each node and helps in making the services available to the external host. It helps in forwarding the request to correct containers. Kubernetes Proxy Service is capable of carrying out primitive load balancing. It makes sure that the networking environment is predictable and accessible but at the same time it is isolated as well. It manages pods on node, volumes, secrets, creating new containers health checkup, etc.

Integrated OpenShift Container Registry

OpenShift container registry is an inbuilt storage unit of Red Hat, which is used for storing Docker images. With the latest integrated version of OpenShift, it has come up with a user interface to view images in OpenShift internal storage. These registries are capable of holding images with specified tags, which are later used to build containers out of it.

Frequently Used Terms

Image − Kubernetes (Docker) images are the key building blocks of Containerized Infrastructure. As of now, Kubernetes only supports Docker images. Each container in a pod has its Docker image running inside it. When configuring a pod, the image property in the configuration file has the same syntax as the Docker command.

Project − They can be defined as the renamed version of the domain which was present in the earlier version of OpenShift V2.

Container − They are the ones which are created after the image is deployed on a Kubernetes cluster node.

Node − A node is a working machine in Kubernetes cluster, which is also known as minion for master. They are working units which can a physical, VM, or a cloud instance.

Pod − A pod is a collection of containers and its storage inside a node of a Kubernetes cluster. It is possible to create a pod with multiple containers inside it. For example, keeping the database container and web server container inside the pod.

Environment Setup

System Requirement
In order to set up enterprise OpenShift, one needs to have an active Red Hat account. As OpenShift works on Kubernetes master and node architecture, we need to set up both of them on separate machines, wherein one machine acts as a master and other works on the node. In order to set up both, there are minimum system requirements.

Master Machine Configuration
Following are the minimum system requirements for master machine configuration.

A base machine hosted either on physical, virtual, or on any of the cloud environment.

At least Linux 7 with the required packages on that instance.

2 CPU core.

At least 8 GB RAM.

30 GB of internal hard disk memory.

Node Machine Configuration
Physical or virtual base image as given for the master machine.
At least Linux 7 on the machine.
Docker installed with not below than 1.6 version.
1 CPU core.
8 GB RAM.
15 GB hard disk for hosting images and 15 GB for storing images.
Step by Step Guide to OpenShift Setup
In the following description, we are going to set up OpenShift lab environment, which can be later extended to a bigger cluster. As OpenShift requires master and node setup, we would need at least two machines hosted on either cloud, physical, or virtual machines.

Step 1 − First install Linux on both the machines, where the Linux 7 should be the least version. This can be done using the following commands if one has an active Red Hat subscription.

subscription-manager repos –disable = “*”
subscription-manager repos –enable = “rhel-7-server-rpms”
subscription-manager repos –enable = “rhel-7-server-extras-rpms”
subscription-manager repos –enable = “rhel-7-server-optional-rpms”
subscription-manager repos –enable = “rhel-7-server-ose-3.0-rpms”
yum install wget git net-tools bind-utils iptables-services bridge-utils
yum install wget git net-tools bind-utils iptables-services bridge-utils
yum install python-virtualenv
yum install gcc
yum install httpd-tools
yum install docker
yum update

Once we have all the above base packages installed in both of the machines, the next step would be to set up Docker on the respective machines.

Step 2 − Configure Docker so that it should allow insecure communication on the local network only. For this, edit the Docker file inside /etc/sysconfig. If the file is not present then you need to create it manually.

vi /etc/sysconfig/docker

OPTIONS = –selinux-enabled –insecure-registry 192.168.122.0/24
After configuring the Docker on the master machine, we need to set up a password-less communication between both the machines. For this, we will use public and private key authentication.

Step 3 − Generate keys on the master machine and then copy the id_rsa.pub key to the authorized key file of the node machine, which can be done using the following command.

ssh-keygen
ssh-copy-id -i .ssh/id_rsa.pub root@ose3-node.test.com

Click here to read more Q&A

Once you have all of the above setup in place, next is to set up OpenShift version 3 on the master machine.

Step 4 − From the master machine, run the following curl command.

sh <(curl -s https://install.openshift.com/ose)

The above command will put the setup in place for OSV3. The next step would be to configure OpenShift V3 on the machine.

If you cannot download from the Internet directly, then it could be downloaded from https://install.openshift.com/portable/oo-install-ose.tgz as a tar package from which the installer can run on the local master machine.

Once we have the setup ready, then we need to start with the actual configuration of OSV3 on the machines. This setup is very specific to test the environment for actual production, we have LDAP and other things in place.

Step 5 − On the master machine, configure the following code located under /etc/openshift/master/master-config.yaml

vi /etc/openshift/master/master-config.yaml

identityProviders:

  • name: my_htpasswd_provider
    challenge: true
    login: true
    provider:
    apiVersion: v1
    kind: HTPasswdPasswordIdentityProvider
    file: /root/users.htpasswd
    routingConfig:
    subdomain: testing.com
    Next, create a standard user for default administration.
htpasswd -c /root/users.htpasswd admin

Step 6 − As OpenShift uses Docker registry for configuring images, we need to configure Docker registry. This is used for creating and storing the Docker images after build.

Create a directory on the OpenShift node machine using the following command.

mkdir /images

Next, login to the master machine using the default admin credentials, which gets created while setting up the registry.

oc login

Username: system:admin
Switch to the default created project.

oc project default

Step 7 − Create a Docker Registry.

echo ‘{“kind”:”ServiceAccount”,”apiVersion”:”v1″,”metadata”:{“name”:”registry”}}’ | oc create -f –

Edit the user privileges.

oc edit scc privileged

users:

  • system:serviceaccount:openshift-infra:build-controller
  • system:serviceaccount:default:registry
    Create and edit the image registry.
oadm registry –service-account = registry —

config = /etc/openshift/master/admin.kubeconfig —
credentials = /etc/openshift/master/openshift-registry.kubeconfig —
images = ‘registry.access.redhat.com/openshift3/ose-${component}:${version}’ —
mount-host = /images
Step 8 − Create a default routing.

By default, OpenShift uses OpenVswitch as software network. Use the following command to create a default routing. This is used for load balancing and proxy routing. The router is similar to the Docker registry and also runs in a registry.

echo ‘{“kind”:”ServiceAccount”,”apiVersion”:”v1″,”metadata”:{“name”:”router”}}’ | oc create -f –

Next, edit the privileges of the user.

oc edit scc privileged

users:

  • system:serviceaccount:openshift-infra:build-controller
  • system:serviceaccount:default:registry
  • system:serviceaccount:default:router
oadm router router-1 –replicas = 1 —

credentials = ‘/etc/openshift/master/openshift-router.kubeconfig’ —
images = ‘registry.access.redhat.com/openshift3/ose-${component}:${version}’
Step 9 − Configure the DNS.

In order to handle URL request, OpenShift needs a working DNS environment. This DNS configuration is required to create a wild card, which is required to create DNS wild card that points to a router.

yum install bind-utils bind
systemctl start named
systemctl enable named

vi /etc/named.conf
options {listen-on port 53 { 10.123.55.111; };
forwarders {
10.38.55.13;
;
};

zone “lab.com” IN {
type master;
file “/var/named/dynamic/test.com.zone”;
allow-update { none; };
};
Step 10 − The final step would be to set up github server on OpenShift V3 master machine, which is optional. This can be done easily using the following sequence of commands.

yum install curl openssh-server
systemctl enable sshd
systemctl start sshd
firewall-cmd –permanent –add-service = http
systemctl reload firewalld
curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-
yum install gitlab-ce
gitlab-ctl reconfigure

Once the above setup is complete, you can verify by test and deploy applications, which

Click here to read more blogs
Click here to read more Latest Technology Questions and Answers

About Author


After years of Technical Work, I feel like an expert when it comes to Develop wordpress website. Check out How to Create a Wordpress Website in 5 Mins, and Earn Money Online Follow me on Facebook for all the latest updates.

Leave a Comment