In Red Hat edge platforms: Choosing the right one for your use case, we discussed multiple options with Red Hat Device Edge. Now let's take a closer look at the topologies of Red Hat OpenShift and where each one fits. OpenShift brings full Kubernetes functionality to edge locations using server-class hardware. When used in conjunction with a central or public cloud environment, OpenShift extends your applications out to the edge—right alongside end users or data sources. It abstracts underlying hardware, operating systems, and networking in an opinionated fashion so developers can focus on writing code rather than managing edge infrastructure. We consider this a micro cloud at your edge locations.
Red Hat OpenShift
As an enterprise Kubernetes platform refined across a decade of data center and cloud deployments, OpenShift brings established operational patterns to edge environments. It started as a Platform-as-a-Service (PaaS) solution for private data centers, then extended its reach to a full-fledged application development platform across hybrid cloud environments. Driven initially by telecommunications providers modernizing cellular radio networks (ORAN), organizations now deploy OpenShift as a lightweight container platform across thousands of remote edge sites.
A key strength of OpenShift is that it integrates with a broad catalog of Red Hat add-ons and partner tools through the Operator Lifecycle Manager; for example, you can add software-defined storage, database workloads, and messaging middleware.
Another strength of all OpenShift topologies is their optional integrated virtualization capabilities. Using OpenShift Virtualization, the difference between containerized and virtualized workloads becomes much smaller. You manage and operate them the same way—via declarative Kubernetes APIs.
You can also create a hyperconverged architecture by running software-defined storage on the same nodes, ensuring data redundancy without dedicated storage hardware.
Before reviewing specific topologies, let's address the elephant in the server room: hardware footprint.
OpenShift cluster composable capabilities—size does matter at the edge
Many consider OpenShift resource-heavy—which might be true if you deploy the full platform with all its capabilities. If you look at the number of capabilities, the required resources are reasonable.
However, you have choices available at installation time. Over the last couple of years, we introduced and extended the concept of cluster capabilities. You can choose at installation time which capabilities you need, and drop the others as needed. If you need additional features later, you can add any capability as a Day 2 operation. Just be aware that once a capability has been added, it cannot be removed without reinstallation of the cluster.
The best example is the integrated web console: if your cluster is managed centrally, you don't need or want a local web console.
See the production documentation for a list of available capabilities.
My advice is to start by disabling nonessential capabilities using baselineCapabilitySet: none
to create a minimal cluster footprint, then selectively enable specific capabilities using additionalEnabledCapabilities:
as required by your application architecture while monitoring resource consumption.
Cluster capabilities are configurable for all available topologies. Time to take a closer look at them.
Single-node OpenShift
Single-node OpenShift is the full OpenShift experience, but on a single node. We like to think that it “acts and quacks like OpenShift.” Unlike Red Hat Device Edge (powered by MicroShift)—which starts with a minimal footprint and builds up—single-node OpenShift scales down the full OpenShift control plane by reducing component resource consumption and making capabilities optional. We recently reduced the minimum resource requirements of single-node OpenShift to 4 vCPUs (that's 2 cores with Hyper-Threading), 16 GB RAM, and 120 GB storage. As shown in Figure 1, single-node OpenShift packs all control plane and workload components onto a single node.
Strengths:
- Full OpenShift experience on a single node—looks and feels the same as your data center clusters
- Can scale out by adding worker nodes when compute demand increases (note: control plane remains a single point of failure)
- Quick edge server provisioning using image-based installation programs and updates
When to use:
- When you want the full OpenShift experience but do not require high availability
Trade-offs:
- No built-in high availability for the control plane; getting to an HA control plane currently requires reinstallation (though work is underway to support this as a Day 2 operation)
Example use cases:
- Telco Open Radio Access Network (ORAN) deployments
- Manufacturing when high availability is not required
- Aggregation of Internet of Things (IoT) devices, sensors, and cameras
- Remote locations that require small hardware, but not necessarily miniature
Management:
- Red Hat Advanced Cluster Management for platform, application, and policy lifecycles
- Red Hat Advanced Cluster Security to monitor risks and enforce policies across edge nodes
- Red Hat Ansible Automation Platform, especially for surrounding components like switches and routers
Two-node OpenShift with fencing
Two-node OpenShift with fencing uses hardware power management—historically referred to in Linux administration as STONITH (Shoot The Other Node In The Head)—to isolate a failing node and protect data integrity. As illustrated in Figure 2, a BMC agent manages fencing of the nodes.
When a node becomes unresponsive, the fencing agent powers it off via the Baseboard Management Controller (BMC), allowing the surviving node to safely take over workloads. This topology is ideal for edge locations where rack space or budget constraints make a third node impractical, while high availability is still required.
Strengths:
- High availability with only 2 nodes
- Smaller hardware footprint than compact 3-node clusters
- Fencing helps protect data integrity during node failures
- Lower hardware and power costs compared to 3-node compact clusters
When to use:
- When high availability is required but you can accommodate only 2 nodes (for example, due to space, power, or budget constraints)
- When reliable fencing infrastructure is available at the edge location
- When the workload profile does not justify a full 3-node compact cluster. This means a single node has enough capacity to run the full workload, while the second node is required only for high availability and fault tolerance. Be sure to get capacity planning right, which means planning for maximum 50% utilization per node. Be sure to recognize the difference between cores and threads when doing so.
Trade-offs:
- Can require manual intervention in certain failure scenarios—it lacks the automated quorum resilience of a 3-node cluster
- Longer failover times in the magnitude of several minutes. If software-defined storage is used, this usually means the workload is also not available because input/output (I/O) is blocked until recovery is completed.
- Software-defined storage solutions can use only replica 2, which has less redundancy and higher risk of data loss
- Transition to a standard 3-node control plane currently requires reinstallation (allowing this transition is on the roadmap)
- Adding worker nodes is currently not supported
Example use cases:
- Retail: Branch office back-of-store compute requiring HA in constrained spaces
- Industrial: Small manufacturing sites
- Healthcare: Remote clinics requiring always-on patient-facing applications
Management:
- Red Hat Advanced Cluster Management for platform, application, and policy lifecycles
- Red Hat Advanced Cluster Security to monitor risks and enforce policies across edge nodes
- Red Hat Ansible Automation Platform, especially for surrounding components like switches and routers
Two-node OpenShift with arbiter
Two-node OpenShift with arbiter achieves high availability using a lightweight arbiter node to maintain etcd quorum, instead of relying on hardware fencing. The arbiter node does not run regular workloads—it only participates in etcd leader election and quorum decisions. This means you get the resilience of a 3-node quorum with only 2 full-capacity control plane and worker nodes. The arbiter can be a minimal-spec machine at the same site, or it can be hosted remotely at a hub or datacenter location, provided network latency requirements for etcd are met.
Strengths:
- High availability and fast failover performance comparable to a 3-node compact cluster, without requiring hardware fencing agents
- Lightweight arbiter node for quorum—minimal resource requirements
- Arbiter can be hosted remotely at a hub site
- Reduced hardware cost compared to compact 3-node clusters
- Fits situations where the workload profile does not justify a full 3-node compact cluster. This means a single worker node has enough capacity to run the full workload, while the second worker node is required only for high availability and fault tolerance. Be sure to get capacity planning right, which means planning for maximum 50% utilization per node. Take into consideration the difference between cores and threads when doing so.
- Supports adding additional worker nodes as Day 2 operations, in case a load increase requires scale-out
When to use:
- Recommended default solution for 2-node deployments, due to its strong quorum-based high availability
- When high availability is needed but no fencing infrastructure (BMC) is available at the edge site
- When a lightweight remote arbiter can be co-located at a hub or datacenter
- When you want quorum-based HA without the operational overhead of managing fencing agents
- When the workload profile does not justify a full 3-node compact cluster
Trade-offs:
- Software-defined storage solutions can use only replica 2, which has less redundancy and higher risk of data loss
- Transition to a standard 3-node control plane currently requires reinstallation (allowing this transition is on the roadmap)
Example use cases:
- Telco: Remote cell sites or aggregation points where hardware fencing is impractical
- Retail: Remote offices or branch locations connected to a regional hub
- Industrial: Remote monitoring stations with a central operations center providing the arbiter
Management:
- Red Hat Advanced Cluster Management for platform, application, and policy lifecycles
- Red Hat Advanced Cluster Security to monitor risks and enforce policies across edge nodes
- Red Hat Ansible Automation Platform, especially for surrounding components like switches and routers
Multi-node OpenShift or 3-node compact clusters
A 3-node compact cluster is the standard baseline deployment for edge high availability, as illustrated in Figure 4. It provides resilient, high-availability, cloud-like compute services at your edge locations.
Strengths:
- High availability and Kubernetes resilience that can tolerate a single-node outage with little to no impact on the workload (be sure to get capacity planning right)
- In combination with a software-defined storage solution like Red Hat OpenShift Data Foundation, you get a high-density, software-defined hyperconverged solution: compute, network, and storage all in 3 standard servers, which could fit into 2U of rack space
When to use:
- Use this when you require high availability at the edge location and have the capacity (power, cooling, rack space) to host a 3-node cluster with the full OpenShift experience
Example use cases:
- Retailers love the 3-node compact cluster as a multipurpose configuration for the back rooms of their stores to operate a variety of store function workloads
- Energy and utilities: small supervisory control and data acquisition (SCADA) or grid control room solutions, for example, for a local distribution system operator (DSO)
- Manufacturing when high availability is required
- Training of machine learning (ML) models
- Larger remote facilities such as cruise ships, remote plants, and regional branch offices
Trade-offs:
- Investment costs, especially if the workload requires only 1 node
Management:
- Red Hat Advanced Cluster Management for platform, application, and policy lifecycles
- Red Hat Advanced Cluster Security to monitor risks and enforce policies across edge nodes
- Red Hat Ansible Automation Platform, especially for surrounding components like switches and routers
Conclusion
So whether your edge locations need a small form factor, high availability, or scalability, OpenShift has a topology that can accommodate it. And no matter which topology you choose, it is managed with the same tools and processes as any other OpenShift deployment—a natural extension of your hybrid cloud environment. Most importantly, every topology retains OpenShift's default security architecture, including automated updates, declarative policy enforcement, and hardened host operating system defaults.
Want to see it in action? Try single-node OpenShift in the no-cost Developer Sandbox. Explore our interactive topology demos for arbiter or fencing.
Ready to map these topologies to your physical footprint? Schedule an edge architecture workshop with Red Hat Consulting experts to evaluate your site constraints.