etcd
etcd is a distributed key-value store for configuration, service coordination, and other critical metadata. It keeps one consistent view of that data across a cluster, even when some members fail.
itCloud native tools and technologies | OpenSkills.info
Intro
etcd
etcd is a distributed key-value store for data that a system must agree on. It keeps configuration, coordination records, and other critical metadata in a flat key space. A cluster replicates changes with the Raft consensus algorithm.
The name joins /etc, the Unix configuration directory, with the letter d for distributed systems. The name also captures the intended role. etcd provides shared configuration and coordination data for systems that cannot tolerate two conflicting histories.
This course gives you a working mental model of the data, API, consistency, failure, and operating boundaries of etcd. It does not replace the version-specific installation and operations guides.
The problem etcd solves
A distributed control plane needs authoritative answers to questions such as:
- Which configuration is current?
- Which member owns a task?
- Which services are alive?
- What changed after a known point in time?
- Which update should succeed when two clients race?
A local file or single-process map cannot answer those questions across machines while surviving a failure. An ordinary cache can remain available by returning old values, but stale coordination data can create conflicting decisions.
etcd takes a different position. It favors a consistent history. When a cluster cannot reach a majority, it stops accepting updates instead of creating another writable history.
Kubernetes is the most common place many operators encounter etcd. Kubernetes stores API objects in etcd. That makes etcd availability and recoverability part of control-plane health.
A cluster is one logical store
An etcd cluster contains members. One member acts as the Raft leader, and the other voting members follow the replicated log. Clients can connect to any advertised client endpoint. The client library finds a usable endpoint and directs requests through the cluster.
Continue the course
This section is part of the paid course.
See pricing to subscribe, or log in if you already have access.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://etcd.io/
Supports
- etcd as a distributed, reliable key-value store for critical distributed-system data
- Raft-based replication and the role of etcdctl
- https://etcd.io/docs/v3.6/learning/why/
Supports
- Origin of the etcd name
- Metadata, configuration, service discovery, election, locking, and liveness use cases
- Preference for consistency over split-brain availability
- Comparison boundary with other key-value stores
- https://etcd.io/docs/v3.6/learning/data_model/
Supports
- Flat binary key space and lexical ranges
- Multiversion storage, revisions, key versions, and retained history
- Workload focus on infrequently updated data and reliable watches
- Compaction of older superseded revisions
- https://etcd.io/docs/v3.6/learning/api/
Supports
- gRPC service organization
- KV range, put, delete, and transaction operations
- Watch events and streams
- Lease grant and keep-alive behavior
- Auth, Cluster, and Maintenance service roles
- https://etcd.io/docs/v3.6/learning/api_guarantees/
Supports
- Durability and strict serializability of completed KV operations
- Revision ordering and transaction atomicity
- Watch ordering, reliability, delay, and compaction boundary
- Lease behavior and time-to-live semantics
- https://etcd.io/docs/v3.6/learning/design-client/
Supports
- Endpoint selection, retry, failover, and load-balancing concerns
- Preservation of consistency guarantees across client failures
- Unknown outcomes and at-most-once semantics for mutable operations
- https://etcd.io/docs/v3.6/learning/design-learner/
Supports
- Non-voting learner members
- Catch-up before promotion to a voting member
- Membership-change safety motivation
- https://etcd.io/docs/v3.6/learning/glossary/
Supports
- Official terminology for clients, clusters, members, leaders, followers, and revisions
- https://etcd.io/docs/v3.6/op-guide/failures/
Supports
- Follower and leader failure behavior
- Majority requirements and network partition behavior
- Client reconnection after member failure
- https://etcd.io/docs/v3.6/op-guide/maintenance/
Supports
- Periodic maintenance requirement
- Compaction, defragmentation, space quota, and storage alarms
- Snapshot backups and Raft log retention
- https://etcd.io/docs/v3.6/op-guide/recovery/
Supports
- Failure tolerance for N-member clusters
- Effect of permanent quorum loss
- Snapshot creation, verification, and restoration into a new cluster
- https://etcd.io/docs/v3.6/op-guide/monitoring/
Supports
- Health, debug, and metrics endpoints
- Prometheus-format monitoring and alerting
- Grafana dashboards for etcd metrics
- https://etcd.io/docs/v3.6/op-guide/security/
Supports
- Transport security for client and peer traffic
- Certificate-based authentication options
- https://etcd.io/docs/v3.6/op-guide/authentication/rbac/
Supports
- Users, roles, authentication, and key-range permissions
- Least-privilege access-control guidance
- https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/
Supports
- Kubernetes storage of cluster data in etcd
- Odd-member quorum guidance
- Operational importance of backup, TLS, and low-latency storage
- https://github.com/sindresorhus/awesome
Supports
- Discovery entry point for the curated Awesome Kubernetes list
- https://github.com/ramitsurana/awesome-kubernetes
Supports
- Discovery of Prometheus and Grafana as Kubernetes monitoring ecosystem projects relevant to etcd operation
- https://prometheus.io/docs/introduction/overview/
Supports
- Prometheus collection and querying of time-series metrics
- Alerting use for monitored systems
- https://grafana.com/docs/grafana/latest/fundamentals/
Supports
- Grafana dashboards and data-source visualization
- Operational exploration of collected metrics