---
title: "Matching OpenShift edge topologies to your physical footprint"
description: "Red Hat OpenShift topologies are mapped to edge-site constraints such as hardware footprint, availability, rack space, power, and workload needs. It is presented as a micro cloud that brings full Kubernetes functionality to server-class edge hardware, with optional virtualization and software-defined storage. Cluster capabilities can be minimized with baselineCapabilitySet: none and selectively enabled later, although added capabilities cannot be removed without reinstalling. Options span single-node OpenShift, which requires 4 vCPUs, 16 GB RAM, and 120 GB storage, two-node designs using fencing or an arbiter, and three-node compact clusters for resilient high availability. Each topology retains shared management and security practices, so selection depends on the physical footprint, failure tolerance, and scale required at the site."
---

# Matching OpenShift edge topologies to your physical footprint

[Red Hat](https://yomu.fyi/company/red-hat) · Daniel Froehlich · Sep 18, 2026

**Type:** Explainer

## Summary

Red Hat OpenShift topologies are mapped to edge-site constraints such as hardware footprint, availability, rack space, power, and workload needs. It is presented as a micro cloud that brings full Kubernetes functionality to server-class edge hardware, with optional virtualization and software-defined storage. Cluster capabilities can be minimized with baselineCapabilitySet: none and selectively enabled later, although added capabilities cannot be removed without reinstalling. Options span single-node OpenShift, which requires 4 vCPUs, 16 GB RAM, and 120 GB storage, two-node designs using fencing or an arbiter, and three-node compact clusters for resilient high availability. Each topology retains shared management and security practices, so selection depends on the physical footprint, failure tolerance, and scale required at the site.

## Context

The article compares OpenShift deployment topologies for edge locations, from single-node installations to two-node configurations with fencing or an arbiter and three-node compact clusters. It connects each option to hardware constraints, availability requirements, workload patterns, and operational trade-offs.

## Approach / What changed

Use OpenShift cluster capabilities to create a smaller installation by setting baselineCapabilitySet: none, then enable required capabilities with additionalEnabledCapabilities. Select a topology according to the site footprint and availability needs: single-node for a smaller non-HA deployment, two-node fencing or arbiter configurations for constrained HA deployments, and three-node compact clusters for resilient high availability.

## Takeaways

- Single-node OpenShift has a stated minimum of 4 vCPUs, 16 GB RAM, and 120 GB storage, but its control plane remains a single point of failure.
- Two-node OpenShift can provide high availability with fencing or an arbiter; fencing protects data integrity by powering off an unresponsive node, while an arbiter supports quorum-based decisions.
- Three-node compact clusters are the standard edge baseline for high availability and can combine compute, networking, and software-defined storage in three servers.

## FAQ

### What happens if an OpenShift capability is added after installation?

Capabilities can be added later as a Day 2 operation. Once added, a capability cannot be removed without reinstalling the cluster.

### When should a two-node deployment use fencing?

Fencing is appropriate when high availability is required, only two nodes can fit, and reliable fencing infrastructure is available. A BMC agent can power off an unresponsive node so the surviving node can safely take over workloads.

### Why choose a three-node compact cluster instead of a smaller topology?

A three-node compact cluster provides resilient high availability and can tolerate a single-node outage with little to no workload impact. It requires enough power, cooling, and rack space for three servers and may cost more when the workload needs only one node.

**Tags:** [Edge Computing](https://yomu.fyi/topic/edge-computing), [High Availability](https://yomu.fyi/topic/high-availability), [Kubernetes](https://yomu.fyi/topic/kubernetes), [OpenShift](https://yomu.fyi/topic/openshift), [Virtualization](https://yomu.fyi/topic/virtualization)

- Source: [Red Hat](https://developers.redhat.com/articles/2026/09/18/matching-openshift-edge-topologies-your-physical-footprint)
- Source URL: https://developers.redhat.com/articles/2026/09/18/matching-openshift-edge-topologies-your-physical-footprint
- Ingested by Yomu: 2026-09-18T15:00:16.144Z

[Read original post](https://developers.redhat.com/articles/2026/09/18/matching-openshift-edge-topologies-your-physical-footprint)