2. etcd 基础回顾：架构、Raft 协议、键值存储模型与 Watch 机制
在深入多集群压测与 PVC 一致性复核之前，必须重新夯实 etcd 的核心原理。etcd 是 Kubernetes 控制平面的“状态中枢”，所有集群资源（Pod、PVC、ConfigMap 等）的声明式数据均持久化在 etcd 中。理解其架构与协议，是诊断数据不一致、设计压测沙盘的前提。
2.1 etcd 整体架构
etcd 采用 分层模块化 设计，从上到下依次为：
- Client 层：提供 gRPC API（v3 协议），支持 KV、Watch、Lease、Lock 等操作。
- Raft 层：共识引擎，负责日志复制、Leader 选举、成员变更。
- 存储层：基于 BoltDB（现为 bbolt）的持久化 KV 存储，支持 MVCC 与事务。
- 网络层：Peer 间通信（Raft 消息）与 Client 通信分离。
关键认知： Kubernetes 的 API Server 是 etcd 的唯一客户端。所有资源变更（如 PVC 扩容、PV 绑定）都通过 API Server 转换为 etcd 的
Put / Txn 操作。
2.2 Raft 协议核心机制
Raft 是 etcd 保证数据一致性的基石。它通过 Leader 强领导模型 简化共识过程，核心流程如下：
| 阶段 | 角色 | 关键行为 | 超时/触发条件 |
|---|---|---|---|
| Leader 选举 | Follower → Candidate → Leader | 发起 RequestVote，获得多数票 | Election Timeout (随机 150~300ms) |
| 日志复制 | Leader → Follower | AppendEntries 心跳 + 日志条目 | Leader 收到 Client 写请求 |
| 提交确认 | Leader 主导 | 多数节点写入后标记 committed | Leader 收到多数 AppendEntries 响应 |
| 安全保证 | 所有节点 | 只选日志最新的节点；不提交旧 Term 日志 | Leader 变更时触发 |
压测启示： 当 etcd 集群出现网络分区或磁盘 I/O 抖动时，Leader 频繁切换会导致写入延迟飙升。在 PVC 一致性复核场景中，若压测期间发生 Leader 切换，可能出现“写成功但未提交”的中间状态，需通过
--consistency=c 线性化读取验证。
2.3 键值存储模型与 MVCC
etcd v3 摒弃了 v2 的目录式层级结构，采用 扁平的键值模型，所有数据存储在一个有序的 B+Tree 中。核心概念：
- Key-Value：Key 是字节数组，Value 是任意二进制数据。Kubernetes 中 Key 格式为
/registry/<resource>/<namespace>/<name>。 - Revision：全局单调递增的版本号，每次写操作（Put/Delete）都会生成新的 Revision。MVCC 通过 Revision 实现历史版本查询。
- Compact：定期压缩历史版本，释放存储空间。Kubernetes 默认每 5 分钟执行一次自动压缩。
| 概念 | 说明 | Kubernetes 场景示例 |
|---|---|---|
| Key | 唯一标识，有序存储 | /registry/persistentvolumeclaims/default/my-pvc |
| Value | Protobuf 序列化的资源对象 | PVC 的完整 Spec + Status |
| CreateRevision | Key 首次创建时的 Revision | 用于判断 PVC 是否被重建 |
| ModRevision | Key 最近一次修改的 Revision | 用于乐观锁（资源冲突检测） |
| Version | Key 被修改的次数（从 1 开始） | 每次 Update 递增 |
一致性复核陷阱： 压测过程中，PVC 的
ModRevision 可能因频繁更新而快速递增。若复核脚本仅比较 ModRevision 是否一致，可能误判“版本不同即数据不一致”。正确做法是反序列化 Value 后比对 Spec 与 Status 中的关键字段（如 capacity.storage、accessModes）。
2.4 Watch 机制
Watch 是 etcd 实现事件驱动架构的核心，也是 Kubernetes 控制器模式的基础。API Server 通过 Watch 监听资源变化，实时更新缓存并触发 reconciliation。
Watch 工作流程：
- Client 发起
Watch(key, start_revision)请求，建立 gRPC 长连接。 - etcd 从
start_revision开始，扫描事件历史（若未压缩）并实时推送后续变更。 - 事件类型：
PUT（创建/更新）、DELETE（删除）。 - 每个事件包含：
Key、Value、Type、Revision。
压测沙盘中的 Watch 应用： 在 PVC 一致性复核工具中，可以利用 Watch 机制实时捕获 PVC 的变更事件，与压测脚本的预期变更进行比对。若 Watch 事件丢失或顺序错乱，说明 etcd 或 API Server 存在性能瓶颈。
2.5 本章小结
etcd 作为 Kubernetes 的“单一事实来源”，其架构与协议直接决定了集群的可靠性与一致性。在后续的压测沙盘构建与 PVC 一致性复核中，以下知识点将反复出现：
- Raft 日志复制 是写入延迟的瓶颈，压测时需监控 Leader 心跳与提案耗时。
- MVCC 与 Revision 是数据版本追踪的基础，复核脚本需正确解析
ModRevision与Value内容。 - Watch 机制 是实时捕获变更的关键，压测中需验证事件是否完整、顺序是否正确。