Comprehensive Guide to etcd: Overview, Architecture, Installation, and Usage

etcd is an open‑source, highly available distributed key‑value store originally created by CoreOS in 2013, built on the Raft consensus algorithm and implemented in Go, and it serves as a fundamental component in many cloud‑native systems, especially Kubernetes.

Key characteristics include simple installation with an HTTP API, SSL support for security, high read throughput (over 2 k reads per second per instance), and strong consistency guaranteed by Raft.

Core terminology explained: Raft, Node, Member, Cluster, Peer, Client, WAL, snapshot, Proxy, Leader, Follower, Candidate, Term, Index, etc., providing a clear vocabulary for understanding etcd’s operation.

Architecture consists of four main modules: the HTTP Server handling API and peer communication, the Store implementing transactional logic, the Raft module ensuring consensus, and the Write‑Ahead Log (WAL) for persistent storage. A typical request flow is HTTP Server → Store → Raft (if state changes) → replication to followers.

Typical application scenarios include service registration and discovery, message publish/subscribe, load balancing, deployment coordination, distributed locks, distributed queues, and cluster monitoring with leader election.

Installation and deployment instructions cover both single‑node and multi‑node cluster setups. For a three‑node cluster, the guide shows host configuration, yum installation commands, and detailed etcd.conf settings such as data directory, peer/client URLs, heartbeat, election timeout, and snapshot count.

Basic command‑line usage is illustrated with examples wrapped in etcdctl commands, e.g., etcdctl set /testdir/testkey "Hello world" , etcdctl get /testdir/testkey , etcdctl mkdir testdir , etcdctl rm /testdir/testkey , etcdctl watch /testdir , and member management commands like etcdctl member add and etcdctl member remove . Options for TTL, recursive operations, and sorting are also described.

Backup and snapshot procedures are provided, showing how to create a backup with etcdctl backup --data-dir /var/lib/etcd --backup-dir /home/etcd_backup and how to take a v3 snapshot using etcdctl snapshot save mysnapshot.db .

Conclusion emphasizes that etcd is best suited for read‑heavy, write‑light workloads such as configuration management and service discovery, stores only the latest 1 000 events by default, and typically requires auxiliary tools for full service‑discovery automation.