K8s 背后的键值存储 etcd：分布式系统为什么都用它？

GitHub 仓库

etcd-io/etcd

总 Stars

★ 52,614

今日新增

+128

主要语言

Go

查看 GitHub 项目

结论先说：因为分布式系统最难的就是“大家对同一份数据达成一致”，etcd 就是干这个的。etcd 今天日榜涨了 128 星，总星数 5.2 万，2026 年 11 月 7 日当天仍在更新。Kubernetes 把集群状态全存在它里面，它一倒，整个集群就失明。

它是什么

etcd 是一个分布式的可靠键值存储，用 Go 写成，基于 Raft 一致性算法。多个节点之间自动选主、自动同步，写进去的数据只要多数节点确认就不会丢。官方简介说它是“为分布式系统最关键的数据”准备的。

能干嘛

存配置、做服务发现、做分布式锁、做选主。K8s、CoreDNS 这些基建都把它当状态后端。自己做微服务需要一个可信的“公告板”，etcd 是标准答案之一。

适合谁

做云原生、K8s 运维、分布式后端的人。学 K8s 原理绕不开它，理解 etcd 等于理解了 K8s 一半的状态管理。

注意点

etcd 对磁盘 fsync 很敏感，跑在慢盘或虚拟化不稳定的环境容易出性能问题，生产部署要按官方建议配 SSD 与独立磁盘。备份也要定期做，丢了数据等于丢了集群的记忆。

小项目有必要用 etcd 吗？

没必要。单机配置用文件或 SQLite 就够了，etcd 是给“多节点必须一致”的场景准备的。先判断自己是不是真的需要分布式一致性，再决定上不上它。

站长点评：etcd 这种项目平时不显眼，但它是那种“出问题才知道它多重要”的基建。把它收进今天的深写档，是因为想提醒一句：学云原生别只学 K8s 的 YAML，底下的状态存储才是基本功。