1. 课程导论：etcd在分布式系统中的核心地位、Leader选举超时与节点重建的典型故障场景、课程目标与学习路径
1.1 etcd 在分布式系统中的核心地位
etcd 是云原生生态中事实上的分布式一致键值存储系统，由 CoreOS 开源并捐赠给 CNCF。它基于 Raft 共识算法 实现强一致性，是 Kubernetes、OpenStack、Cloud Foundry 等大规模分布式系统的“控制面数据库”。
核心定位：etcd 不存储业务数据，而是存储集群的元数据、配置信息、服务发现记录和分布式锁状态。一旦 etcd 集群出现故障，整个上层系统将陷入不可用或数据不一致的严重状态。
etcd 在分布式架构中承担以下关键角色：
| 角色 | 说明 | 典型场景 |
|---|---|---|
| 配置中心 | 存储集群全局配置，支持 Watch 机制实时推送变更 | Kubernetes 的 ConfigMap、Service 信息 |
| 服务发现 | 服务注册与健康检查，客户端通过 etcd 获取可用端点 | 微服务注册中心、DNS 服务发现 |
| 分布式锁 | 基于 Lease 和 Revision 实现排他锁与读写锁 | 选主、任务调度、资源互斥访问 |
| 元数据存储 | 存储集群拓扑、资源对象状态、版本号 | Kubernetes 的 Pod、Deployment、Node 对象 |
1.2 Leader 选举超时与节点重建的典型故障场景
在生产环境中，etcd 集群最常见的两类故障是 Leader 选举超时 和 节点重建异常。它们往往相互关联，且对上层系统影响巨大。
场景一：Leader 选举超时
当 etcd 集群的 Leader 节点因网络分区、磁盘 I/O 抖动、CPU 饥饿或内存压力而无法及时向 Follower 发送心跳时，Follower 会触发选举超时，发起新一轮 Leader 选举。如果选举过程因网络延迟、节点间时钟偏差或日志不一致而反复失败，集群将进入“无 Leader”状态，所有写操作和一致性读操作全部阻塞。
典型表现：Kubernetes API Server 报错
etcdserver: request timed out，kubectl 命令无法执行，Pod 调度停滞，集群处于“脑裂”边缘。
场景二：节点重建异常
节点重建通常发生在硬件故障、容器重启、版本升级或误操作删除成员之后。重建过程涉及数据同步、Raft 日志追赶和成员关系重新建立。常见问题包括：
- 数据目录损坏：旧数据文件残留导致启动失败
- 集群成员冲突：新节点 ID 与已有记录不匹配
- 快照恢复失败：快照文件过大或版本不兼容
- 网络地址变更：重建后 peer URL 与集群记录不一致
1.3 课程目标与学习路径
本课程通过 沙盘压测环境 模拟真实故障，帮助学员掌握 etcd 集群的故障排查与恢复能力。课程不局限于理论讲解，而是以“故障注入 → 现象观察 → 根因分析 → 修复验证”的闭环方式展开。
| 课程目标 | 具体能力 | 对应章节 |
|---|---|---|
| 理解 Raft 选举机制 | 掌握 Leader 选举超时的触发条件、超时参数调优、选举日志解读 | 第 2-5 章 |
| 掌握节点重建流程 | 能够安全移除故障节点、重建数据目录、重新加入集群 | 第 6-10 章 |
| 压测环境搭建 | 使用 chaos-mesh / tc 工具模拟网络延迟、磁盘故障、CPU 压力 | 第 11-15 章 |
| 故障排查方法论 | 熟练使用 etcdctl、etcdutl、metrics、日志分析工具定位问题 | 第 16-22 章 |
| 生产级恢复方案 | 制定备份策略、快照恢复、跨数据中心容灾方案 | 第 23-30 章 |
学习路径建议：先通读第 1-5 章建立 Raft 选举的理论基础，再进入第 6-10 章动手操作节点重建，最后通过第 11-30 章的压测沙盘实战巩固排查能力。每章末尾的“沙盘实验”环节建议在真实或虚拟环境中复现。
本课程适合以下学员：
- SRE / 运维工程师：需要管理生产 etcd 集群，应对突发故障
- Kubernetes 管理员：希望深入理解控制面存储层的稳定性保障
- 分布式系统开发者：想要掌握 Raft 实现细节和故障注入测试方法
- 架构师：设计高可用 etcd 部署方案，评估容灾能力