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

1. Overview

etcd is an open‑source, highly‑available distributed key‑value database initiated by CoreOS in 2013. It implements the Raft consensus algorithm ( raft ) and is written in Go. The article lists its characteristics—simplicity, security, speed, reliability—and defines key terminology such as Raft, Node, Member, Cluster, Peer, Client, WAL, snapshot, Proxy, Leader, Follower, Candidate, Term, and Index.

2. Architecture and Analysis

The etcd architecture consists of four main components:

HTTP Server: handles API requests and inter‑node communication.

Store: implements transaction logic, data indexing, and event handling.

Raft: core consensus module ensuring strong consistency.

WAL (Write‑Ahead Log): persistent storage with snapshots and entries.

A typical request flow passes through the HTTP Server to the Store, then to Raft for log replication and finally to the WAL for persistence.

3. Application Scenarios

Service registration and discovery – front‑end and back‑end services can register themselves in etcd and discover peers.

Message publish/subscribe – etcd can act as a lightweight message broker.

Load balancing – multiple service instances register in etcd, which provides IP/port information for load‑balancing.

Deployment coordination – etcd notifies services of state changes and orchestrates rollouts.

Distributed lock – etcd elects a single node to hold a lock among competitors.

Distributed queue – etcd creates ordered keys to implement queues.

Cluster monitoring and leader election – Raft ensures a leader is elected and monitors node health.

4. Installation and Deployment

Both single‑node and cluster deployments are covered. For a single node, the binary can be installed via yum or compiled from source. Example yum installation commands:

hostnamectl set-hostname etcd-1
wget http://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
rpm -ivh epel-release-latest-7.noarch.rpm
yum -y install etcd
systemctl enable etcd

Cluster deployment requires at least three nodes. Host entries are added to /etc/hosts , and each node receives a tailored /etc/etcd/etcd.conf configuration (data directory, peer/client URLs, node name, heartbeat, election timeout, snapshot count, etc.). After configuring, start the service with systemctl start etcd and verify status with systemctl status etcd .

Cluster health can be checked using:

etcdctl member list
etcdctl cluster-health

5. Basic Operations

Common etcdctl commands are demonstrated:

set – set a key value (e.g., etcdctl set /testdir/testkey "Hello world" ).

mk – create a key only if it does not exist.

mkdir – create a directory.

rm – delete a key or directory (with --recursive ).

update – modify an existing key.

get – retrieve a key’s value.

ls – list keys under a directory.

watch – monitor changes to a key.

backup – backup the data directory.

member – list, add, or remove cluster members.

Examples include setting TTL, swapping values, creating ordered keys for queues, and using etcdctl --endpoints with snapshot commands.

6. Summary

etcd stores only the most recent 1000 events, making it suitable for read‑heavy, write‑light scenarios such as configuration management and service discovery. Compared with ZooKeeper, etcd is simpler to use but often requires auxiliary tools (e.g., registrator, confd) for full service‑discovery automation. Currently, there is no official graphical UI for etcd.

References

https://github.com/etcd-io/etcd

https://www.hi-linux.com/posts/40915.html

https://cizixs.com/2016/08/02/intro-to-etcd/

https://juejin.cn/post/6844903970461351944

https://www.infoq.cn/article/coreos-analyse-etcd/