etcd
The Raft-consensus key-value store that coordinates Kubernetes — small, watchable, linearizable.
etcd is a strongly consistent, distributed key-value store built on the Raft consensus algorithm. It stores small volumes of configuration and coordination data with MVCC revisions, supports range queries and atomic compare-and-swap, and pushes changes to watchers in real time. It is the control-plane datastore of Kubernetes.
Raft consensus
One leader per cluster term; writes commit only when a majority of nodes persist them — minority partitions reject writes rather than split the brain.
MVCC multi-version store
Keys keep their revision history in a backend B+tree; reads at a past revision are consistent snapshots, and compaction prunes old revisions.
Watch streams
Clients watch key ranges from any historical revision and receive every change event in order — the mechanism behind Kubernetes controllers.
Leases and TTLs
Keys attach to leases with TTLs; heartbeat renewals keep them alive, expiry deletes them — distributed locks and liveness come free.
Built for the control plane
etcd is deliberately not application storage: values are small, volumes are low, and correctness is absolute. Kubernetes stores cluster state in it — every API-object write, every leader election, every lease heartbeat flows through Raft.
Watch streams make controllers reactive: a Deployment controller watches for pod changes at a revision and receives events the moment they commit. Compaction prunes old revisions — too-aggressive compaction breaks slow watchers, too-late compaction grows the store.
Raft in one paragraph
Raft elects a leader per term; the leader takes a proposal, replicates it to followers, and commits once a majority persists. Linearizable reads go through the leader (or verify recency against it); historical reads use the MVCC snapshot at a chosen revision. Terms, log indices, and revisions are the only clock a consensus store needs.
Diagrams
[caption] etcd data volumes are small by design — the store is coordination, not application data.
A write proposes through the Raft leader, commits at majority persistence, applies to the MVCC store in revision order, and notifies watchers.
Keys keep revision history until compaction; compact prunes revisions older than the cluster compact revision.
[caption] Illustrative backend key/revision tree — etcd is tuned for small keys and many revisions.
Keys keep revision history until compaction; compact prunes revisions older than the cluster compact revision.