When the Edge Can’t Afford a Third Node: A Storage Solution for Two-Node Kubernetes C...
summary
Shows a concrete two-node pattern that keeps Ceph running: deploy Rook-Ceph with a single floating MON, store that MON’s state on a DRBD-backed block device, and enforce node isolation with Pacemaker fencing/Redfish. Claims: replica count drops from three to two (20 GB stored instead of 30 GB) but failure tolerance still survives one node loss. Demo kills a node non‑gracefully, DRBD resync and MON reschedule complete within minutes, and reads/writes continue.
AI-written summary · about
chapters (22)
- 0:00Edge storage challenges
- 1:22Rook-Ceph overview
- 2:04Edge clusters and constraints
- 3:29Rook-Ceph with Kubernetes
- 4:11Ceph requirements and limits
- 5:15Ceph MONs and quorum
- 6:18Two-node Ceph challenges
- 8:02Split-brain with fencing
- 9:44DRBD for MON state
- 11:51Two-node solution architecture
- 12:12Floating MON and DRBD
- 13:16Demo setup
- 15:01Deploying with Rook-Ceph
- 16:26Testing node failure
- 17:35Recovery and IO verification
- 19:43Data safety comparison
- 21:24Pacemaker fencing failures
- 23:29Disk corruption alerts
- 24:50DRBD real-time replication
- 26:36Floating MON in HA
- 28:40Kubernetes API recovery
- 29:21Q&A
related talks
30mWhatever Can Go Wrong, Will Go Wrong – Rook/Ceph and Storage Failures
35mBest Practices of Production-Grade Rook/Ceph Cluster
46mKubernetes Stateful Application Disaster Recovery with Zero Data Loss
35mDeploy Ceph in Kubernetes: Rook Deep Dive
29mReliable and Cost-Effective: Open Storage Strategies for Kubernetes
37mBuilding a Storage Cluster with Kubernetes
31mRook: Intro and Deep Dive With Ceph
35mDisaster Recovery of Stateful Applications in a Multi-Cluster Environment