OpenStack is an open-source IaaS platform for building and managing cloud infrastructure—mainly compute, storage, networking, identity, and images—across a datacenter. OpenShift is an open-source PaaS focused on building, deploying, and managing containerized applications, built around Kubernetes and developer workflows.
What OpenStack does
OpenStack gives you the building blocks of a cloud: virtual machines, networks, volumes, load balancers, and related control services. It is typically used by operators who want to create private clouds or manage large-scale infrastructure under their own control. In practice, it sits closer to the hardware and virtualization layer than an application platform does.
What OpenShift does
OpenShift is designed for running applications on containers, with strong emphasis on deployment, scaling, and day-to-day developer experience. It provides opinionated tooling around Kubernetes so teams can ship apps more consistently, with less manual cluster administration. It is more application-centric than infrastructure-centric.
Main differences
How they relate
They are not direct competitors in every sense; they solve different layers of the stack and can be used together. A common pattern is to run OpenShift on infrastructure provided by OpenStack, especially in private-cloud environments. In that setup, OpenStack supplies the virtualized infrastructure, while OpenShift handles the container platform above it.
Red Hat OpenStack Platform (RHOSP)
Red Hat’s main OpenStack product is Red Hat OpenStack Platform (RHOSP), its enterprise distribution of OpenStack for building private or public IaaS clouds on Red Hat Enterprise Linux. It provides the usual OpenStack cloud services for compute, storage, networking, identity, images, and a web-based admin interface.
Red Hat is also moving that stack into a newer form factor called Red Hat OpenStack Services on OpenShift (RHOSO), where the OpenStack control plane runs on OpenShift and the data plane remains on RHEL-managed infrastructure. In practical terms, RHOSP is Red Hat’s classic OpenStack implementation, while RHOSO is the newer OpenStack-on-OpenShift architecture.
How to think about it
- RHOSP = Red Hat’s traditional OpenStack distribution for cloud infrastructure.
- RHOSO = the next-generation Red Hat approach that hosts OpenStack services on OpenShift/Kubernetes.
- RDO = the community-supported Fedora/RHEL-derivative OpenStack distribution associated with Red Hat’s ecosystem, but not the enterprise-supported product.
A simple shorthand: if someone says “Red Hat OpenStack,” they usually mean RHOSP unless they specifically mention OpenShift, in which case they mean RHOSO.
OpenShift Components
OpenShift is built from a control plane, worker nodes, and several platform services that make Kubernetes easier to run in production. At a high level, the major pieces are the API/control components, the workload nodes, the networking and routing layer, storage, and the developer/operator-facing services.
Core platform pieces
- Control plane / master nodes: Run the cluster management components that keep the desired state of the cluster, schedule workloads, and coordinate everything else.
- API server: The front door for all cluster requests and automation.
- etcd: The distributed key-value store that holds cluster state and configuration.
- Scheduler: Assigns pods to nodes based on available resources and constraints.
- Controller manager: Reconciles actual state with desired state across the cluster.
Workload nodes
- Worker nodes: Host application pods and run user workloads.
- Infra nodes: Often used for platform services such as logging, monitoring, registry, and routing so those services are isolated from app workloads.
- Node runtime components: On each node, OpenShift relies on the container runtime and kubelet-style node services to run and manage containers.
Networking and access
- Services: Provide stable virtual endpoints for pods and internal load balancing.
- Routes / router: Expose applications externally and direct incoming traffic to the right service.
- Networking layer: Connects pods and nodes across the cluster and supports application communication.
Platform services
- Container registry: Stores and distributes container images for builds and deployments.
- Web console: Browser-based UI for managing the cluster and applications.
- Build and deployment tooling: Includes source-to-image and other app delivery workflows in many OpenShift setups.
- Storage / persistence: Persistent volumes and storage backends for stateful applications.
Security and governance
- RBAC: Controls who can access and modify resources.
- SCCs: OpenShift’s security context constraints, which add tighter pod security controls.
- Authentication and authorization: Integrated identity and access handling for cluster operations.
Simple mental model
Think of OpenShift as Kubernetes plus a lot of opinionated enterprise plumbing: the control plane decides, the workers run apps, the router exposes them, the registry stores images, and the security layers constrain what can run. In diagrams, you’ll often see it described as infrastructure, service, and routing layers sitting on top of the cluster nodes.
In a modern OpenShift 4 cluster, the cleanest way to think about it is as a control plane, worker nodes, and usually infrastructure nodes that host platform services separately from app workloads.
OpenShift 4 layout
- Control plane nodes: Run the core cluster services, and in OpenShift 4 they use Red Hat CoreOS for the control plane machines.
- Worker nodes: Run application pods and user workloads.
- Infrastructure nodes: Commonly host routing, registry, monitoring, and logging so those services do not compete with application workloads.
Control plane services
The control plane includes the API server, etcd, scheduler, and controllers that manage cluster state and workload placement. In OpenShift 4, these services are managed as part of the platform rather than hand-installed components, which is a big shift from older OpenShift deployment models.
Platform services
OpenShift 4 typically includes an integrated web console, image registry, ingress/router layer, and built-in operators that manage cluster and application services. A major OpenShift idea is that many capabilities are delivered as operators, which automate installation, upgrades, and lifecycle management for platform components.
What makes it different
Compared with plain Kubernetes, OpenShift 4 adds opinionated defaults for security, networking, ingress, and platform lifecycle management. That is why you often see it described as Kubernetes plus the full enterprise platform around it, not just a container orchestrator.
Mental model
A simple picture is: control plane decides, worker nodes run apps, infra nodes carry shared services, and operators keep the platform healthy. That structure is what makes OpenShift 4 feel more integrated and managed than a vanilla Kubernetes cluster.