2. etcd 架构解析：集群节点角色、gRPC API 接口、WAL 日志与快照机制
etcd 作为 Kubernetes 集群的“大脑”，其架构设计直接决定了集群的可靠性、一致性与性能。本节将深入解析 etcd 的核心组件：节点角色（Leader/Follower）、通信接口（gRPC API）以及持久化机制（WAL 日志与快照）。理解这些底层原理，是制定正确备份与恢复策略的前提。
2.1 集群节点角色：Leader 与 Follower
etcd 使用 Raft 共识算法 来保证数据一致性和高可用性。在一个 etcd 集群中，每个节点都处于以下三种角色之一：
| 角色 | 职责 | 关键行为 |
|---|---|---|
| Leader（领导者） | 处理所有客户端写入请求，并将日志复制到 Follower。 | 定期发送心跳（Heartbeat）维持权威；负责日志提交（Commit）。 |
| Follower（跟随者） | 被动接收并应用来自 Leader 的日志条目。 | 响应 Leader 和 Candidate 的请求；若超时未收到心跳，则发起选举。 |
| Candidate（候选者） | 在选举期间临时角色，用于竞选新 Leader。 | 向其他节点请求投票；获得多数票后晋升为 Leader。 |
运维要点： 在 3 节点集群中，最多允许 1 个节点故障；在 5 节点集群中，最多允许 2 个节点故障。Leader 选举需要多数节点（N/2+1）存活。
下图展示了 etcd 集群中 Leader 与 Follower 之间的日志复制与心跳交互流程：
2.2 gRPC API 接口
etcd v3 使用 gRPC 作为核心通信协议，所有客户端（包括 kube-apiserver）都通过 gRPC 与 etcd 交互。gRPC 基于 HTTP/2，支持双向流、多路复用和强类型接口定义。
2.2.1 主要 gRPC 服务
| 服务名称 | 主要 RPC 方法 | 功能描述 |
|---|---|---|
| KV | Put / Get / Delete / Txn | 核心键值读写操作，支持事务（Txn） |
| Watch | Watch | 监听键或前缀的变化，实现事件驱动 |
| Lease | Grant / Revoke / KeepAlive | 租约管理，用于 TTL 自动过期 |
| Cluster | MemberList / MemberAdd / MemberRemove | 集群成员管理 |
| Maintenance | Snapshot / Defrag / Status | 运维接口：快照、碎片整理、状态查询 |
备份相关：
Maintenance.Snapshot 是 etcdctl snapshot save 命令的底层实现，通过 gRPC 流式传输快照数据，是热备份的核心接口。
2.2.2 客户端连接示例
# 使用 etcdctl 通过 gRPC 与 etcd 交互
# 注意：v3 版本默认使用 gRPC，无需额外参数
export ETCDCTL_API=3
etcdctl --endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key \
put /testkey "Hello etcd"2.3 WAL 日志与快照（Snapshot）机制
etcd 的持久化由两个核心组件构成：WAL（Write-Ahead Log，预写日志） 和 Snapshot（快照）。两者协同工作，确保数据不丢失且能高效恢复。
2.3.1 WAL 日志
- 作用： 记录所有对 etcd 数据的变更操作（Put、Delete、事务等）。
- 写入策略： 每次写入操作先追加到 WAL 文件，再更新内存中的状态机。即使节点崩溃，重启后可通过重放 WAL 恢复数据。
- 文件结构： WAL 文件按段（Segment）存储，每个段文件大小达到阈值（默认 64MB）后创建新文件。
- 存储路径： 默认位于
/var/lib/etcd/member/wal/。
2.3.2 快照（Snapshot）
- 作用： 定期将 etcd 的完整数据状态持久化到磁盘，避免 WAL 无限增长。
- 触发条件： WAL 文件数量超过
--snapshot-count（默认 100,000 条日志）时自动触发。 - 文件结构： 快照文件为
.snap格式，存储在/var/lib/etcd/member/snap/。 - 恢复流程： 启动时先加载最新的快照，然后重放该快照之后的所有 WAL 日志。
备份关键点： 仅备份 WAL 文件是不够的，因为 WAL 可能包含大量历史日志。正确的备份策略是：定期创建快照（
etcdctl snapshot save），快照本身包含了完整的数据状态，恢复时无需重放大量 WAL。
下图展示了 WAL 日志与快照在 etcd 数据持久化与恢复中的协作关系：
2.4 架构总结
| 组件 | 核心作用 | 备份/恢复关联 |
|---|---|---|
| Leader/Follower | 保证强一致性与高可用 | 备份可在任意节点执行，但推荐在 Leader 或低负载节点 |
| gRPC API | 客户端与集群的通信桥梁 | Maintenance.Snapshot 是热备份的底层接口 |
| WAL 日志 | 记录所有增量变更 | 恢复时需配合快照使用，单独备份 WAL 效率低 |
| 快照 | 保存完整数据状态 | 备份的核心目标，恢复时作为基础数据源 |
实践建议： 在生产环境中，建议将
--snapshot-count 保持默认值（100,000），并定期使用 etcdctl snapshot save 手动创建快照备份。快照文件是恢复 etcd 集群最可靠、最高效的方式。