Day 48: etcd and why it needs Raft and odd-numbered quorums
etcd: the source of truth, and why it needs Raft
etcd is a distributed key-value store, and it is *the* single source of truth for the entire cluster's state — every object (Pods, Deployments, Secrets, everything) is a key in etcd. If etcd is lost with no backup, the cluster's state is gone.
This is Phase 7, applied
etcd uses Raft (Day 43) internally to keep its replicas consistent — this is why etcd clusters are deployed with an odd number of members (typically 3 or 5, per Day 44's quorum math), and why "etcd quorum lost" is one of the most serious possible cluster incidents: without a Raft majority, etcd can't safely accept writes, and neither can the rest of the cluster.
ETCDCTL_API=3 etcdctl endpoint health --cluster
ETCDCTL_API=3 etcdctl member listBecause every single API server read/write ultimately touches etcd, etcd's performance directly bounds the whole cluster's responsiveness — this is why etcd is typically run on fast local SSDs and why very large clusters (thousands of nodes) need careful etcd tuning.
Key terms
- etcd
- Kubernetes's distributed, Raft-backed key-value store holding all cluster state.
- etcd quorum
- The majority of etcd members required to accept writes — lost quorum means the cluster cannot make changes.
A 3-member etcd cluster loses 2 members simultaneously. What happens to the Kubernetes cluster?
