Understanding Distributed Consensus in etcd and Kubernetes - Laura Frank, CloudBees
summary
Explains Raft as etcd’s consensus mechanism, shows quorum = floor(n/2)+1 so a 5-node group needs 3 votes and tolerates one failure, and describes leader election, randomized timeouts and split-vote recovery. Shows log replication, committed vs uncommitted entries and that etcd stores snapshots and WAL under /var/lib/etcd/member for backups. Demonstrates using Docker Swarm’s raft tooling and the --force-new-cluster restore path; live demo mostly succeeds but Wi‑Fi interrupts final steps. quorum = n/2 + 1 --force-new-cluster
AI-written summary · about
chapters (9)
- 0:00Introduction to Raft
- 1:20Distributed consensus
- 3:26What is Raft
- 6:23Raft responsibilities
- 8:20Understanding quorum
- 13:35Leader election process
- 20:36Log replication mechanics
- 25:22Raft log recovery
- 30:43Handling quorum loss
related talks
47mDistributed Systems: When Democracy and Computer Science Come Together
47mUnderstanding Raft Consensus
40mDeep Dive: etcd
44mCluster Consensus: When Aeron Met Raft
41mThe Raft Consensus Algorithm
46mEtcd 101: The Parts They Don't Teach You
01h 32mHow to Reach Consensus with Paper, Pencil and the Raft Algorithm
38mTowards consensus on distributed consensus #bbuzz