Session
Surviving the Split-Brain: Solving the 2-Node Kubernetes Quorum Problem with GitOps at the Edge
In traditional cloud data centers, ensuring Kubernetes High Availability (HA) relies on a strict majority to maintain etcd quorum. But what happens at the far edge, where physical space, cooling, and hardware constraints restrict organizations to deploying just two nodes per site?
In a standard 2-node Kubernetes topology, a network partition (a "split-brain") causes an immediate loss of quorum. The API server becomes unresponsive, new pods cannot be scheduled, and operators are effectively blinded. While standard enterprise solutions rely on "Fence and Recover" strategies that forcefully reboot isolated nodes to protect data consistency, this approach is often a dealbreaker for mission-critical industrial environments that require continuous, "Active-Active" local availability.
In this talk, I will share a real-world architectural case study on how to build a resilient, 2-node edge appliance that survives its own network failures. We will explore:
- The fundamental conflict between the Raft consensus algorithm and industrial edge uptime requirements.
- Why attempting to run an unfenced, clustered etcd across two nodes carries severe supportability and data corruption risks.
- How to break the traditional cluster paradigm by deploying a "1+1 Redundant Architecture" using independent, lightweight nodes (such as Red Hat Device Edge / MicroShift).
- How to seamlessly tie these independent nodes together using VRRP (Keepalived) for fast, 3-second traffic failover, and a declarative GitOps agent (ArgoCD) to guarantee configuration consistency without a shared database.
Attendees will leave with a practical blueprint for shifting from centralized control planes to a "Shared Nothing" architecture, leveraging GitOps to guarantee continuous local availability and automated recovery at the far edge.
Arthur Oliveira
Red Hat, Senior Partner Technical Account Manager
Vila Nova de Gaia, Portugal
Links
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top