What You Should Know about Etcd v3
summary
etcd v3 replaces the REST surface with gRPC namespace and requires using put instead of set, so old v2 keys and new v3 keys live separately; the keyspace is flat so use prefix and range queries not ls-style directories. Snapshots include cryptographic hashes and support a working snapshot restore flow demonstrated live. Quorum rules favor odd clusters (3 vs 9 tradeoffs: latency and sync cost), 1 MB per request and default 2 GB storage (configurable to 8 GB), and a tested upgrade path from 2.3 to 3.0 used by Kubernetes 1.6.
AI-written summary · about
chapters (12)
- 0:00Etcd v3 intro
- 4:46Etcd v3 upgrade mistakes
- 8:51Etcd v3 API changes
- 10:56Flattened key space
- 15:11Tracking key history
- 17:34Optimal Etcd cluster size
- 20:15Recovering Etcd cluster
- 22:24Etcd v3 storage limits
- 24:52Byzantine fault tolerance
- 26:14Etcd v2 to v3 upgrade
- 28:44Etcd cluster fire drills
- 32:00Q&A
related talks
32metcd V3.6.0 and etc...
32mSIG etcd Maintainer Track Talk
38metcd in 2026: Enhancements, V3.7 Roadmap...
28mHow CoreOS sees the container industry
43mSelf-hosted, Scale, and Federation with Kubernetes v1.4 and Beyond
23mThe Secret Recipe of etcd
19mDr etcd; or; How I Learned to Stop Worrying and Love the Datastore - Nick Young, VMware
26mDon't Let Your Kubernetes Cluster Go Wild: Ensuring Etcd Reliability