📚 课程目录第2章 etcd架构与数据模型

2. etcd 架构基础：Raft 协议简介、etcd 集群节点角色、数据存储模型

etcd 是 Kubernetes 控制平面的“状态中枢”，所有集群资源（Pod、Service、ConfigMap 等）的最终一致性都依赖 etcd 的分布式共识与存储模型。理解 etcd 的架构基础，是进行压测沙盘资源变更与一致性复核的前提。

2.1 Raft 协议简介

Raft 是一种易于理解的分布式共识算法，etcd 使用它来保证集群中多个节点之间的数据一致性。Raft 将共识问题分解为三个核心子问题：领导者选举（Leader Election）、日志复制（Log Replication）和安全性（Safety）。

  核心原则：Raft 保证在任意时刻，集群中最多只有一个有效的领导者（Leader）。所有写请求必须由 Leader 处理，Leader 将操作封装为日志条目，复制到大多数节点（Quorum）后，才视为提交（Committed）。

Raft 协议关键阶段

阶段	触发条件	核心行为	一致性保证
领导者选举	Follower 在选举超时内未收到 Leader 心跳	Follower → Candidate → 请求投票 → 获得多数票 → Leader	每个任期（Term）最多一个 Leader
日志复制	Leader 收到客户端写请求	追加日志 → 并行发送 AppendEntries RPC → 等待多数确认 → 提交 → 应用到状态机	已提交的日志在所有节点上顺序一致
安全性	选举限制、日志匹配、提交规则	只有拥有最新已提交日志的节点才能成为 Leader；Leader 不会覆盖已提交的日志	状态机安全性：所有节点按相同顺序执行相同命令

压测启示：Raft 的多数派写入机制决定了 etcd 的写入延迟受网络往返和磁盘 fsync 影响。在沙盘压测中，如果集群节点数为 3，每次写入需要至少 2 个节点确认；节点数为 5 时，需要 3 个节点确认。节点越多，故障容忍度越高，但写入延迟可能略有增加。

2.2 etcd 集群节点角色

etcd 集群中的每个节点在 Raft 协议基础上承担不同角色。角色会随着集群状态动态转换，但始终遵循 Raft 的选举与复制规则。

节点角色对比

角色	职责	状态	对压测的影响
Leader	处理所有客户端读写请求；管理日志复制；发送心跳	活跃，定期发送心跳	写请求必须经过 Leader；Leader 节点负载最高
Follower	被动接收 Leader 的日志复制；处理只读请求（可配置）；参与选举投票	被动等待指令	可分担读请求（需开启 Read-Only 模式）；写请求转发给 Leader
Candidate	选举过渡角色；向其他节点请求投票	短暂，选举结束后消失	选举期间集群不可写入（短暂不可用）

注意：在压测沙盘中，如果 Leader 节点因资源争用（CPU/磁盘 IO）导致心跳超时，会触发重新选举。频繁的 Leader 切换会显著降低写入吞吐量，并可能导致 K8s 资源变更的短暂“抖动”。建议在压测前确保 etcd 集群有足够的资源余量。

2.3 数据存储模型

etcd 的数据模型围绕 Key-Value 存储，并在此基础上提供了 Watch（监听）和 Lease（租约）机制，这些是 K8s 实现资源变更感知和自动清理的基础。

2.3.1 Key-Value 存储

etcd 将数据存储为扁平的键值对，但支持按前缀（Prefix）进行目录式组织。K8s 将所有资源对象存储在 /registry 前缀下，例如：

/registry/pods/default/nginx-pod-12345
/registry/services/default/my-service
/registry/configmaps/kube-system/kube-dns

每个 Key 对应一个 Value（通常是序列化的 Protobuf 或 JSON），并关联一个全局递增的 Revision（版本号），用于实现 MVCC 和 Watch。

2.3.2 Watch 机制

Watch 是 etcd 提供给客户端的“订阅”能力。客户端可以监听某个 Key 或某个前缀，当该 Key 或前缀下的数据发生变化（创建、更新、删除）时，etcd 会实时推送事件给客户端。K8s 的 Informer 机制正是基于此实现资源变更的实时感知。

Watch 事件类型：

PUT：Key 被创建或更新
DELETE：Key 被删除

每个事件都携带变更后的 Key-Value 数据以及对应的 Revision，客户端可以根据 Revision 判断事件顺序。

2.3.3 Lease 机制

Lease（租约）是一种“心跳保活”机制。客户端创建一个 Lease 并设置 TTL（生存时间），然后可以将多个 Key 绑定到该 Lease 上。只要客户端持续续约（KeepAlive），Lease 就不会过期；一旦客户端停止续约（例如节点宕机），Lease 到期后，etcd 会自动删除所有绑定在该 Lease 上的 Key。

K8s 利用 Lease 实现 Node 心跳和 Pod 的优雅删除。例如，当 Node 失联时，其对应的 Lease 过期，K8s 控制平面会标记该 Node 为 NotReady，并驱逐其上的 Pod。

2.4 小结：etcd 架构与 K8s 一致性复核的关系

Raft 协议保证了 etcd 集群内部的数据一致性，是 K8s 资源变更最终一致性的基础。
节点角色决定了压测时的负载分布和故障场景（Leader 切换）。
Key-Value + Watch + Lease 构成了 K8s 资源感知、状态同步和自动清理的完整链路。
在沙盘压测中，通过比对 etcd 的 Revision 序列、Watch 事件顺序和 Lease 过期行为，可以复核 K8s 资源变更的一致性。