top of page
Search

OpenShift Architecture Reference: How Red Hat's Enterprise Kubernetes Platform Fits Together

virtualgendham
10 minutes ago
8 min read

In my first post, Learning Red Hat OpenShift, I covered why I picked OpenShift and what the platform promises. This post goes one level deeper: what is actually inside an OpenShift cluster, how the pieces talk to each other, and where the day-to-day tooling sits. I am using the architecture diagram below as the map for the article. Where a label on it has aged compared to Red Hat's current OpenShift Container Platform 4.x documentation (4.22 at the time of writing), I flag that in the section it belongs to.


Diagram supplied for this article. Not official Red Hat documentation.

1. The big picture

OpenShift is Red Hat's enterprise Kubernetes platform. Underneath it is still Kubernetes: the same API machinery, the same pod model, the same scheduler. What OpenShift adds is an opinionated, secure-by-default way to install, upgrade, run, and operate that Kubernetes on anything from bare metal to public cloud, plus the developer and operations tooling that a vanilla cluster leaves to you.

Three facts from the documentation frame everything else:

  • Control plane machines always run Red Hat Enterprise Linux CoreOS (RHCOS), an immutable, container-optimized operating system that OpenShift manages for you. Compute machines run RHCOS by default, with supported alternatives: RHEL compute machines on x86_64 in some installation types, and Windows Server compute nodes managed by the Windows Machine Config Operator for Windows container workloads.

  • The platform manages its own upgrades through Operators. The Cluster Version Operator (CVO) applies cluster updates, and the Machine Config Operator (MCO) rolls operating system and node configuration changes out across the fleet. The administrator stays in control: you choose an update channel, review the recommended update paths and precondition checks in the console, and approve the update. Checking add-on Operators for compatibility with the target version is part of that decision.

  • Almost everything in OpenShift is an Operator: a controller that watches custom resources and keeps some part of the platform in its desired state. That is why the diagram shows OperatorHub and Operators so prominently.

2. Users and access

The top band of the diagram lists who touches a cluster: developers, operators, admins, service accounts, applications, and CI/CD systems. All of them are authenticated and authorized before they reach cluster state, but not all the same way. Human users typically sign in through OpenShift's built-in OAuth server, which fronts an identity provider (LDAP, GitHub, OpenID Connect, or an enterprise SSO). Service accounts authenticate with tokens, and internal cluster components use client certificates. RBAC then decides what each identity may do.

Two ways in matter most day to day:

  • The web console, which splits into an Administrator perspective and a Developer perspective, so the platform team and the app team each get a view built for their job.

  • The oc CLI, which is kubectl plus OpenShift extras such as oc login, oc new-app, and build and route commands. kubectl works too, because the API is standard Kubernetes.

3. Control plane: the brain of the cluster

The control plane (the machines with the master role) runs the services that decide what the cluster should look like:

  • API server: the single entry point for cluster state. Every oc command, console action, and controller loop is an API call, and every call is authenticated and authorized before anything is persisted.

  • etcd: the distributed key-value store that holds all cluster state. If the API server is the front door, etcd is the memory. etcd needs quorum to survive failures, which is why a standard production cluster runs three control plane nodes: three voters tolerate one loss.

  • Scheduler: watches for pods with no node assigned and picks the best worker node based on resources, affinity rules, taints, and policy.

  • Controller manager: runs the control loops (replication, endpoints, node lifecycle, and more) that continuously push actual state toward desired state.

  • Admission controllers: intercept requests after authentication but before persistence, enforcing policies such as Security Context Constraints, quota, and image rules.

Three control plane nodes is the standard production shape, not the only one. Red Hat also supports compact three-node clusters, where the control plane machines also run workloads, single-node OpenShift for edge and far-edge sites, and hosted control planes, where control planes run as pods on a management cluster. The trade-offs are cost and footprint against high availability.

On top of the Kubernetes control plane, OpenShift runs its own Operators: the OpenShift API server and OpenShift controller manager add the platform-specific APIs (Routes, Builds, ImageStreams, Projects), and the ingress and authentication Operators wire in routers and OAuth.

4. Worker nodes: where applications run

Worker nodes (compute machines) run your workloads. Each one runs:

  • kubelet: the agent that accepts pod specs from the API server and keeps the containers running and healthy.

  • CRI-O: the container runtime. OpenShift uses CRI-O (not Docker) to pull images and run containers, with crun or runC doing the low-level container creation.

  • A service proxy and the OVN-Kubernetes components that wire pods into the cluster network.

OpenShift manages these machines declaratively through the Machine API. Compute machine sets define groups of worker machines on a cloud or virtualization provider and scale them up or down; machine config pools group nodes by role so the Machine Config Operator can apply configuration changes to them as a unit, draining and rebooting safely in stages. Control plane machine sets do the same for control plane machines on supported providers.

Projects (OpenShift's namespaces with extra guardrails) are the unit for sharing a cluster between teams. They give administrative isolation: each project gets its own RBAC, quotas, and policies. One nuance worth knowing: projects do not isolate network traffic by themselves. Pod-to-pod traffic across projects is open unless you add NetworkPolicy resources, so real multi-team isolation combines both.

5. Operators and cluster management

The bar under the worker nodes in the diagram is easy to overlook, but it is the most OpenShift-specific idea on the page. The Machine Config Operator, cluster management Operators, and core services keep the platform itself healthy. The Operator Lifecycle Manager (OLM) and OperatorHub handle discovery, installation, and updates of optional Operators, and each installed Operator then manages its own piece: monitoring, logging, ingress, storage, and so on.

During an update, the CVO orchestrates these Operators in a defined order, which is what makes OpenShift updates far more controlled than a hand-rolled Kubernetes upgrade. Controlled is not the same as automatic: the administrator picks the channel, reads the release notes and conditional update risks the console surfaces, verifies that installed Operators support the target version, and then starts the update.

6. Networking

OpenShift's default CNI plugin is OVN-Kubernetes, which builds a virtual overlay network for pods and services on top of Open vSwitch running on every node. It handles pod-to-pod traffic, Services (ClusterIP, NodePort, LoadBalancer), DNS, network policies, and egress IPs.

The one genuinely OpenShift-specific piece here is the Route. A Route is OpenShift's original answer to ingress: it exposes a service on a hostname, with optional TLS termination (edge, re-encrypt, or passthrough), and it predates the Kubernetes Ingress API. Standard Ingress objects work too, and the router (HAProxy-based, managed by the Ingress Operator) serves both.

7. Storage

OpenShift uses the standard Kubernetes storage model: PersistentVolumes (PVs) are the actual storage, PersistentVolumeClaims (PVCs) are what pods ask for, and StorageClasses with CSI drivers provision volumes dynamically on whatever infrastructure the cluster runs on, from vSphere datastores to AWS EBS to on-prem SAN.

For data protection, the supported tool is OADP (OpenShift API for Data Protection), Red Hat's packaging of Velero. OADP backs up and restores applications: namespace-scoped Kubernetes resources and their persistent volumes. It is application-level protection, not whole-cluster disaster recovery; etcd backup and platform recovery are separate documented procedures.

8. Security

Security is layered through the whole stack rather than bolted on:

  • RBAC with roles and role bindings controls who can do what, scoped per project.

  • Security Context Constraints (SCC) control what pods are allowed to do. By default OpenShift runs containers as a random non-root user ID, which is stricter than most Kubernetes distributions and the first thing that surprises people migrating apps.

  • Secrets and TLS are managed cluster-wide, with an internal CA and certificate rotation handled by Operators.

  • Image security comes from the internal registry, image policy controls, and optional scanning.

  • Audit logging and the Compliance Operator help with regulated environments, scanning the cluster against benchmarks such as CIS.

9. Developer tools and application lifecycle

The left side of the diagram covers how code becomes a running application:

  • Builds (BuildConfig) and ImageStreams are OpenShift's native build system, including Source-to-Image (S2I), which takes source code and produces a runnable container image without writing a Dockerfile.

  • Deployments roll the images out. One platform note for anyone following older tutorials: DeploymentConfig, OpenShift's original deployment object, has been deprecated since OpenShift 4.14. It still works and gets security fixes, but Red Hat recommends standard Kubernetes Deployment objects for new applications.

  • Services and Routes expose the app inside and outside the cluster, and ConfigMaps and Secrets feed it configuration.

  • OpenShift Dev Spaces provides a cloud-native, browser-based IDE, and there are VS Code extensions and the oc CLI tooling for local development.

10. DevOps and GitOps

On the delivery side, the diagram's boxes map to real Red Hat Operators:

  • OpenShift GitOps is Red Hat's supported Argo CD: you declare the desired state in Git, and Argo CD continuously syncs the cluster to match.

  • OpenShift Pipelines is Tekton: cloud-native, Kubernetes-style CI. Each pipeline is built from Tasks, and each Task runs in its own pod, with the steps as containers in that pod.

  • Helm and Kustomize are supported for packaging and templating, and all of this integrates with external CI/CD systems (Jenkins, GitHub Actions, GitLab) through standard APIs and webhooks.

11. Operations: monitoring, logging, and tracing

The operations column is where the platform has moved fastest, so two labels on the diagram deserve updates:

  • Monitoring is built in: a cluster-monitoring stack based on Prometheus and Alertmanager watches the platform itself, and you can enable monitoring for your own workloads. Dashboards live in the console's Observe section; the separate Grafana component that older releases shipped was removed from the monitoring stack in OpenShift 4.11.

  • Logging is now Red Hat OpenShift Logging 6: Vector is the collector, Loki (LokiStack) is the log store, and the Cluster Observability Operator provides visualization. The Fluentd collector shown on the diagram was removed in Logging 6; it survives only in older Logging 5 installations.

  • Tracing has changed too: the Jaeger-based distributed tracing platform, also shown on the diagram, was deprecated and removed from the Operator catalog in November 2025. The current stack is the Red Hat build of OpenTelemetry for collection plus the Tempo Operator for storage.

12. Platform services: the extended platform

Beyond the core, Red Hat ships optional layers as Operators:

  • Advanced Cluster Management (ACM) for managing many clusters from one control point.

  • OpenShift Virtualization (based on KubeVirt) for running virtual machines alongside containers, which is increasingly relevant for teams moving off traditional virtualization.

  • OpenShift Serverless (Knative) for event-driven, scale-to-zero workloads.

  • Hosted control planes for running control planes as pods on a management cluster, which cuts cost and provisioning time when you run many clusters.

  • An internal image registry, with Red Hat Quay as the standalone enterprise registry option.

13. Infrastructure: one platform, everywhere

The bottom band is the point of the whole exercise. The same platform, the same APIs, and the same tooling run on bare metal, VMware vSphere, AWS, Microsoft Azure, and Google Cloud, with integration into each environment's load balancers and storage. That consistency across on-prem and cloud is the "hybrid" in hybrid cloud platform: the operating model travels with you, even when the hardware changes.

14. Keeping the diagram honest

Diagrams freeze a fast-moving platform at one moment. Against the current documentation, the architecture this one shows (control plane, workers, Operators, the layered services) matches how OpenShift 4.x is actually built. The dated labels are the two called out above: Fluentd for logging (now Vector) and Jaeger for tracing (now OpenTelemetry plus Tempo). Treat any single diagram as a map of the concepts, and the version-specific documentation as the source of truth for the components.

References

Recent Posts

See All
Learning Red Hat OpenShift

OpenShift is Red Hat's enterprise application platform for building, deploying and managing containerized applications, with Kubernetes at its core. Kubernetes on its own handles container orchestrati

 
 
 

Comments

©2026 by GendhamCloud.

bottom of page