etcd一致性架构与Kubernetes存储集群运维 - 第1节
1.1 什么是 etcd
etcd 是一个分布式、高可用的键值（Key-Value）存储系统，由 CoreOS 团队使用 Go 语言开发并开源。它基于 Raft 共识算法 实现数据强一致性，并提供了可靠的 Watch 机制和租约（Lease）管理能力。在云原生生态中，etcd 是 Kubernetes 控制平面的核心数据存储组件，负责保存集群的全部状态信息。
核心特性：
- 强一致性： 基于 Raft 算法，保证所有节点数据一致。
- 高可用： 支持集群模式（通常 3 或 5 节点），容忍部分节点故障。
- 键值存储： 提供简单的 KV API，支持 TTL 和 Watch。
- 可靠 Watch： 客户端可以监听 key 的变化，实现事件驱动。
1.2 etcd 在 K8s 中的核心地位
在 Kubernetes 架构中，etcd 是唯一的有状态组件，承载着整个集群的“真相来源”（Source of Truth）。所有 API 对象的创建、更新、删除操作，最终都会持久化到 etcd 中。如果 etcd 不可用，Kubernetes 集群将无法进行任何状态变更，但已运行的 Pod 和 Service 仍会继续工作。
关键事实： Kubernetes 本身是无状态的，它的所有状态都委托给 etcd 管理。etcd 的稳定性直接决定了 K8s 集群的可靠性。
下图展示了 etcd 在 Kubernetes 控制平面中的位置与数据流向：
1.3 etcd vs 传统数据库
etcd 虽然具备数据存储能力，但其设计哲学与 MySQL、PostgreSQL 等传统关系型数据库有本质区别。etcd 更关注分布式环境下的 一致性 和 可用性，而非复杂查询或事务处理。
| 对比维度 | etcd | 传统数据库（MySQL/PostgreSQL） |
|---|---|---|
| 数据模型 | 分层键值（KV），支持目录结构 | 关系表（Table），支持 SQL 查询 |
| 一致性 | 强一致性（Raft 共识） | 通常为最终一致性或可配置 |
| 查询能力 | 基于前缀/范围的简单查询，不支持 SQL | 复杂 SQL 查询、JOIN、聚合 |
| 事务支持 | 单 key 或有限的多 key 事务（基于版本号） | 完整 ACID 事务 |
| Watch 机制 | 原生支持，实时推送变更事件 | 通常需要轮询或触发器 |
| 典型场景 | 服务发现、配置管理、分布式锁 | 业务数据存储、报表分析 |
| 存储引擎 | BoltDB（嵌入式 KV 引擎） | InnoDB、MyISAM 等 |
选型建议： 不要用 etcd 存储业务数据或大文件。etcd 的默认存储限制为 2GB（可调整），且不适合频繁的大数据量写入。它专为小数据量、高一致性、高可靠性的元数据场景设计。
下图从架构层面对比 etcd 与传统数据库的差异：