Loading post…
Red HatDaniel FroehlichExplainer
Matching OpenShift edge topologies to your physical footprint
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.
Source and freshness
- Source
- developers.redhat.com
- Published
- Added to Yomu
Summaries are generated from the original by a language model. Check the original before relying on it.
Keep reading
Related reading
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
The best engineering reads, once a week
One useful email. Unsubscribe anytime.