2.5 Kubernetes etcd Architecture
Kubernetes etcd Architecture explains how etcd manages cluster state and ensures data consistency through a distributed, scalable, and secure design.
Kubernetes etcd Architecture is the specific internal structure of etcd as a distributed, consensus-based key-value store, describing how its consensus protocol, storage engine, and watch mechanism are arranged to provide the strongly consistent, durable state store that the rest of the Kubernetes control plane depends on.
Consensus Layer Architecture
Leader-Based Replication
etcd is architected around a leader-based consensus protocol, in which one member of the etcd cluster is elected leader and is responsible for accepting writes, replicating them to follower members, and only acknowledging a write once a quorum of members has durably recorded it.
Quorum as a Structural Requirement
Because writes require acknowledgment from a quorum of members, etcd's architecture calls for an odd number of members, ensuring that a majority can always be unambiguously determined even if some members become unreachable.
Storage Engine Architecture
A Multi-Version, Append-Oriented Store
Beneath its consensus layer, etcd is architected around a storage engine that retains multiple historical versions of each key rather than only the latest value, enabling clients to read consistent snapshots at specific revisions and enabling the watch mechanism to replay changes from a defined starting point.
Revision Numbers as a Structural Ordering Mechanism
Every write to etcd is architected to increment a global revision counter, giving every change a strict, cluster-wide ordering that downstream consumers, including the Kubernetes API server, rely on to detect conflicts and to resume watches accurately after a disconnection.
Watch Mechanism Architecture
Streaming Change Notifications
etcd is architected to support long-lived watch connections, through which a client can subscribe to changes affecting a specific key or range of keys and receive a stream of events as those changes occur, rather than needing to poll for updates.
Foundation for the Kubernetes API Server's Own Watches
This underlying watch architecture in etcd is what the Kubernetes API server builds its own watch functionality on top of, translating etcd-level change events into the higher-level object change notifications that controllers throughout the cluster depend on.
Deployment Architecture Within a Cluster
A Dedicated, Isolated Role
etcd is architecturally treated as a distinct component from the rest of the control plane, often deployed on its own dedicated machines in larger clusters, reflecting its heightened sensitivity to latency and its critical role as the cluster's sole authoritative data store.
No Direct Access from Outside the API Server
Within the broader cluster architecture, etcd is positioned so that only the API server communicates with it directly; no other control plane component or worker node component is architected to access etcd independently.