---

Introduction

After understanding the basics of OpenShift and how it differs from Kubernetes, the next step is to understand how OpenShift works internally.

Whenever a developer pushes code or deploys a Spring Boot application, multiple OpenShift components work together behind the scenes to build, deploy, scale, and expose the application to users.

Understanding the architecture helps developers troubleshoot deployment issues, optimize performance, and design cloud-native applications.

---

Learning Objectives

By the end of this article, you will understand:

• OpenShift architecture
• Control Plane and Worker Nodes
• Cluster components
• Request flow
• Application deployment flow
• High-level networking
• Enterprise deployment architecture
• Real-world use cases

---

High-Level OpenShift Architecture

An OpenShift cluster consists of two major parts:

• Control Plane (Master Nodes) – Manages the cluster.
• Worker Nodes – Runs your applications.

flowchart TD

Users --> Route

Route --> Service

Service --> Pods

Pods --> Worker1
Pods --> Worker2

Worker1 --> ControlPlane
Worker2 --> ControlPlane

ControlPlane --> API
ControlPlane --> Scheduler
ControlPlane --> ETCD
ControlPlane --> Controller

The Control Plane acts as the brain of the cluster, while Worker Nodes execute your applications.

---

OpenShift Cluster Overview

flowchart LR
    DEV["Developer"]
    GIT["Git Repository"]
    PIPE["Tekton / Jenkins Pipeline"]
    REG["OpenShift Image Registry"]

    subgraph OCP["OpenShift Cluster"]
        DEPLOY["Deployment"]
        PODS["Application Pods"]
        SVC["Service"]
        ROUTE["Route"]
    end

    USER["Browser"]

    DEV --> GIT
    GIT --> PIPE
    PIPE --> REG
    REG --> DEPLOY
    DEPLOY --> PODS
    PODS --> SVC
    SVC --> ROUTE
    ROUTE --> USER

Deployment begins when a developer commits code and ends when users access the application through a Route.

---

OpenShift Architecture Layers

Application Layer
-----------------
Spring Boot
React
Node.js
Python

Container Layer
---------------
Container Images
Pods

Platform Layer
--------------
OpenShift

Infrastructure Layer
--------------------
Worker Nodes
Control Plane

Cloud Layer
-----------
AWS
Azure
GCP
VMware
Bare Metal

Each layer has a specific responsibility, making the platform modular and scalable.

---

Control Plane Components

The Control Plane manages the entire cluster.

It consists of:

• API Server
• Scheduler
• Controller Manager
• etcd

These components ensure applications are deployed correctly and remain healthy.

---

API Server

The API Server is the entry point for all OpenShift operations.

Responsibilities:

• Receives deployment requests
• Validates requests
• Stores cluster state
• Communicates with other components

Example:

oc apply -f deployment.yaml
        │
        ▼
API Server

Every OpenShift command ultimately communicates with the API Server.

---

Scheduler

The Scheduler decides where new Pods should run.

It evaluates:

• Available CPU
• Available Memory
• Node Health
• Resource Requests
• Affinity Rules

flowchart TD
    POD["New Pod"]
    SCHED["Kubernetes Scheduler"]

    subgraph WORKERS["Worker Nodes"]
        N1["Worker Node 1"]
        N2["Worker Node 2"]
        N3["Worker Node 3"]
    end

    POD --> SCHED
    SCHED --> N1
    SCHED --> N2
    SCHED --> N3

The Scheduler selects the best Worker Node for the Pod.

---

Controller Manager

The Controller Manager continuously monitors the cluster.

Responsibilities:

• Replace failed Pods
• Scale Deployments
• Maintain desired state

Example:

Desired Pods = 3

Current Pods = 2

Controller Manager creates a new Pod automatically.

---

etcd

etcd is the cluster database.

It stores:

• Deployments
• Pods
• Services
• ConfigMaps
• Secrets
• Cluster configuration

Think of etcd as the "brain memory" of OpenShift.

---

Worker Nodes

Worker Nodes execute application workloads.

Each Worker Node contains:

• kubelet
• CRI-O
• Pods
• Containers

flowchart TD

WorkerNode

--> kubelet

--> CRI-O

--> Pod1

--> Pod2

Pod1 --> Container

Pod2 --> Container

---

Pod Architecture

A Pod is the smallest deployable unit.

flowchart TD

Pod

--> SpringBootApp

--> JVM

--> Dependencies

--> Container

A Deployment may create multiple identical Pods for high availability.

---

Application Request Flow

sequenceDiagram

participant User

participant Route

participant Service

participant Pod

participant SpringBoot

participant Database

User->>Route: HTTP Request

Route->>Service: Forward Request

Service->>Pod: Load Balance

Pod->>SpringBoot: Execute

SpringBoot->>Database: Query

Database-->>SpringBoot: Response

SpringBoot-->>User: HTTP Response

This is the standard request lifecycle in most OpenShift applications.

---

Deployment Workflow

flowchart LR
    DEV["Developer"]
    GIT["Git Repository"]
    PIPE["CI/CD Pipeline"]
    REG["OpenShift Image Registry"]

    subgraph CLUSTER["OpenShift Cluster"]
        DEPLOY["Deployment"]
        PODS["Pods"]
        SERVICE["Service"]
        ROUTE["Route"]
    end

    USER["End User"]

    DEV --> GIT
    GIT --> PIPE
    PIPE --> REG
    REG --> DEPLOY
    DEPLOY --> PODS
    PODS --> SERVICE
    SERVICE --> ROUTE
    ROUTE --> USER

Every production deployment follows a similar workflow.

---

Enterprise Banking Architecture

Imagine an online banking platform.

flowchart LR
    CUSTOMER["Customer"]
    API["API Gateway"]
    ACCOUNT["Account Service"]
    PAYMENT["Payment Service"]
    KAFKA["Kafka"]
    NOTIFY["Notification Service"]
    DB[("Database")]

    CUSTOMER --> API
    API --> ACCOUNT
    ACCOUNT --> PAYMENT
    PAYMENT --> KAFKA
    KAFKA --> NOTIFY
    NOTIFY --> DB

Each microservice runs inside its own Pod.

OpenShift provides:

• Auto-scaling
• Self-healing
• Secure networking
• Rolling updates

---

How Components Work Together

flowchart TD
    DEV["Developer"]

    subgraph CONTROL["Control Plane"]
        API["API Server"]
        SCHED["Scheduler"]
    end

    subgraph WORKER["Worker Node"]
        POD["Application Pod"]
        SVC["Service"]
    end

    ROUTE["OpenShift Route"]
    USER["End User"]

    DEV --> API
    API --> SCHED
    SCHED --> POD
    POD --> SVC
    SVC --> ROUTE
    ROUTE --> USER

This illustrates the journey from deployment request to user access.

---

High Availability

OpenShift ensures applications remain available even if a Pod fails.

flowchart LR

Service

--> Pod1

--> Pod2

--> Pod3

Pod2 -. Failure .-> Controller

Controller --> NewPod

NewPod --> Service

The Controller automatically recreates failed Pods.

---

Auto Scaling

When application traffic increases, OpenShift can create additional Pods.

flowchart LR

Users

--> HighTraffic

HighTraffic --> HPA

HPA --> Pod1

HPA --> Pod2

HPA --> Pod3

HPA --> Pod4

This improves application performance during peak usage.

---

Advantages of OpenShift Architecture

• Modular design
• High availability
• Self-healing
• Horizontal scaling
• Secure by default
• Enterprise monitoring
• Rolling deployments
• Zero-downtime updates

---

Real-World Use Cases

OpenShift architecture is widely used in:

• Banking payment platforms
• Insurance claim processing
• Healthcare systems
• Retail e-commerce
• Telecommunications
• Logistics applications
• AI and Machine Learning platforms
• SaaS products

---

Best Practices

• Keep Pods stateless whenever possible.
• Use ConfigMaps for configuration.
• Store credentials in Secrets.
• Define CPU and memory requests.
• Configure health probes.
• Monitor cluster health.
• Use namespaces to isolate environments.
• Enable Horizontal Pod Autoscaler (HPA).

---

Summary

In this article, you learned the overall architecture of an OpenShift cluster and how its core components work together.

Key takeaways:

• The Control Plane manages the cluster.
• Worker Nodes run application Pods.
• The API Server handles all cluster requests.
• The Scheduler selects the best Worker Node for new Pods.
• The Controller Manager maintains the desired state.
• etcd stores cluster configuration and metadata.
• Services and Routes expose applications to users.
• OpenShift provides built-in scalability, self-healing, and enterprise-grade security.

---

Interview Questions

1. What are the two main parts of an OpenShift cluster?
2. What is the role of the API Server?
3. Why is etcd important?
4. What does the Scheduler do?
5. What is the Controller Manager responsible for?
6. What runs on Worker Nodes?
7. How does OpenShift achieve self-healing?
8. What is the difference between a Pod and a Deployment?
9. How does a request reach a Spring Boot application?
10. How does OpenShift support high availability?

---