Skip to main content
Welcome — this lesson gives a concise, high-level overview of OpenShift architecture and how it extends Kubernetes for enterprise and developer workflows. You’ll learn the core components, how container images and builds flow through the platform, and which services maintain cluster state and security.
A presentation slide with a red-to-purple gradient background that reads "Red Hat OPENSHIFT Architecture" in large white letters. The word "OPENSHIFT" is centered and prominent with "Red Hat" above it.

​
Core concepts — Kubernetes primitives + OpenShift features

OpenShift is built on Kubernetes and inherits its core primitives for running containerized applications:
  • Containers — runtime instances of OCI-compatible images.
  • Container images — stored in registries (public or private), used to create containers.
  • Pods — the smallest deployable unit; one or more containers that share network and storage.
  • Controllers (Deployments, ReplicaSets, etc.) — manage the desired number of pod replicas.
  • Services — stable network endpoints to expose pods inside the cluster or externally.
OpenShift adds developer- and enterprise-focused features on top of Kubernetes:
  • Integrated web console and CLI for developers and operators.
  • Build and CI/CD primitives (BuildConfigs, ImageStreams, pipeline integrations) to import source, build images, and push them to a registry.
  • Project-based organization that extends Kubernetes namespaces with access controls and metadata.
Container images can come from public registries such as Docker Hub or from OpenShift’s integrated registry. The open-source upstream distribution, OKD (formerly Origin), may include a built-in registry for storing and serving images to the cluster.

​
Build & deployment flow (high level)

Developers typically follow this flow:
  1. Push or import source code into a repository integrated with OpenShift’s build system.
  2. A BuildConfig or pipeline builds the source into a container image.
  3. The image is pushed to the cluster registry (or an external registry).
  4. A Deployment or DeploymentConfig creates pods from the image.
  5. Services and Routes expose the application internally and externally.
  6. The control plane reconciles desired state, ensuring replicas and networking are maintained.
A stylized OpenShift/Kubernetes components diagram showing container registry, CI/CD, etcd, containers/pods, services and deployments with red 3D node blocks and icons. It maps images and containers through deployments/services to users.

​
Cluster control plane and data store

At the center of cluster state is etcd, a distributed key-value store that holds the desired and current state for Kubernetes and OpenShift resources. Typical control plane (master) components:
  • API server (kube-apiserver plus OpenShift aggregated APIs) — the central entry point for cluster operations and automation.
  • Controller manager — runs controllers that reconcile resources (replicas, endpoints, etc.).
  • Scheduler — decides which worker node should run a pod.
  • etcd — persistent datastore for all cluster state.
Worker (compute) nodes:
  • Run the node agent (kubelet) which manages pod lifecycle on each node.
  • Use a container runtime (for example, containerd or CRI-O) to run containers.
  • Host network plugins, CSI drivers, and other node-level services.

​
Security, identity, and access control

OpenShift integrates authentication and authorization on top of Kubernetes:
  • Authentication integrates with identity providers (LDAP, OAuth, etc.).
  • Role-Based Access Control (RBAC) defines permissions.
  • The web console and CLI require authentication; projects (namespaces) enforce scoped access.
A “project” in OpenShift is a Kubernetes namespace with added metadata and access controls. Use projects to organize resources by application, team, or environment and to apply project-level policies.

​
Quick reference table

Next steps: follow the hands-on lessons to set up an OpenShift cluster, create a project, build an application, and deploy it using the integrated build and registry. See you in the next lesson.

Watch Video