4. etcd 核心机制：Raft 共识算法、Watch 机制、事务（Txn）与租约（Lease）

etcd 作为 Kubernetes 控制平面的唯一状态存储，其内部机制直接决定了集群的 数据一致性、事件响应速度 和 资源利用率。本章深入剖析 etcd 的四大核心支柱：Raft 共识算法、Watch 机制、事务（Txn）与租约（Lease），并阐明它们如何协同支撑 RPO 优化场景下的状态同步策略。

4.1 Raft 共识算法：强一致性的基石

Raft 是一种易于理解的分布式共识算法，etcd 使用它来保证集群中所有节点数据的一致性。Raft 将节点角色分为三种：Leader、Follower 和 Candidate。

• Leader：负责处理所有客户端请求，并将日志条目复制到 Follower。
• Follower：被动接收 Leader 的日志复制，并响应投票请求。
• Candidate：当 Follower 超时未收到 Leader 心跳时，发起选举。

Raft 通过 日志复制 和 Leader 选举 两个核心过程确保一致性。一个写请求必须被多数节点（Quorum）确认后才算提交成功，这保证了即使部分节点故障，数据也不会丢失。

4.2 Watch 机制：事件驱动的状态同步

Watch 机制是 etcd 实现 实时状态同步 的核心。客户端可以对特定的 key 或 key 前缀注册 Watch，当这些 key 发生变化（创建、更新、删除）时，etcd 会主动推送事件给客户端。

4.3 事务（Txn）：原子化条件操作

etcd 的事务（Txn）提供了一种 原子性比较-交换（CAS） 能力。它允许客户端在一个事务中执行多个操作，并且这些操作要么全部成功，要么全部失败。事务由 判断条件（Compare）、成功操作（Success） 和 失败操作（Failure） 三部分组成。

# 示例：原子性地更新 Pod 状态，仅当当前 Revision 匹配时
# 使用 etcdctl 模拟事务逻辑
etcdctl txn --interactive
compares:
  value("/registry/pods/default/my-pod/status") = "{\"phase\":\"Pending\"}"

success:
  put("/registry/pods/default/my-pod/status") = "{\"phase\":\"Running\"}"

failure:
  get("/registry/pods/default/my-pod/status")

事务机制在 RPO 优化中的关键作用：

• 防止状态覆盖： 多个控制器同时更新同一资源时，事务确保只有条件匹配的更新生效，避免“丢失更新”问题。
• 乐观并发控制： 通过比较 resourceVersion 或 modRevision，实现无锁的并发安全更新。
• 镜像拉取状态机： 在镜像拉取控制器中，使用事务原子性地将 Pod 状态从 “拉取中” 切换到 “拉取完成”，防止重复拉取。

4.4 租约（Lease）：分布式心跳与资源保活

租约（Lease）是 etcd 提供的一种 分布式时间租约 机制。客户端可以创建一个租约，并为其关联一个 TTL（生存时间）。只要客户端定期续约，租约就保持有效；一旦客户端故障停止续约，租约到期后关联的 key 会被自动删除。

4.5 四大机制协同：RPO 优化视角

在镜像拉取并发控制场景中，etcd 的四大机制形成一个完整的闭环：

1. 租约（Lease） 为每个正在拉取的镜像创建分布式锁，防止同一镜像被多个节点并发拉取。
2. 事务（Txn） 确保镜像拉取状态的原子性更新，避免状态覆盖或重复提交。
3. Watch 机制 实时推送镜像拉取完成事件，触发后续的 Pod 调度和容器启动流程。
4. Raft 共识 保证所有 etcd 节点上的状态数据一致，即使 Leader 切换也不会丢失关键状态。