etcd 运维避坑：从集群大小选择到备份策略

etcd 运维避坑：从集群大小选择到备份策略

基础设施不需要漂亮话。

etcd 是 Kubernetes 的核心依赖——所有集群状态都存在 etcd 里。但 etcd 的运维经验在团队里往往是最薄弱的：大家更关注 Pod、Service、Deployment，很少深入理解 etcd 的运行机制。直到 etcd 出问题导致整个集群不可用，才发现没有备份、没有监控、没有应急预案。这篇文章从集群架构到备份恢复，把 etcd 运维中最容易踩的坑全部列出来。

一、背景：etcd 为什么需要专门运维

etcd 是分布式 KV 存储，用 Raft 协议保证一致性。它对磁盘 IO、网络延迟和内存使用都有严格要求。Kubernetes 集群的每个操作（创建 Pod、更新 ConfigMap、扩容 Deployment）都会产生 etcd 写入。一个中等规模的集群（500 个 Node，5000 个 Pod）每秒可能有几十到上百次写入。etcd 的性能瓶颈不是 CPU，而是磁盘延迟——Raft 协议要求每次写入都持久化到 WAL（Write-Ahead Log），磁盘 IO 延迟直接决定写入吞吐。

二、架构设计：四个最常见的坑

坑1：节点数量不是越多越好

有人以为 5 个节点比 3 个节点更可靠。Raft 协议的写入需要多数节点确认——3 节点集群需要 2 个确认，5 节点集群需要 3 个确认。节点越多，每次写入的确认延迟越高（跨节点通信需要网络往返）。而且 5 节点集群的容错能力是 2 个节点故障（允许 2 个节点不可用），3 节点集群的容错能力是 1 个节点故障。如果你需要容忍 2 个节点故障，确实需要 5 个节点；但大多数生产集群只需要 3 个节点就够了。

修复方案：默认用 3 节点集群。只有以下场景才考虑 5 节点：跨 3 个可用区部署（每个可用区 1~2 个节点，需要容忍 1 个可用区完全不可用）、合规要求多副本冗余。7 个节点及以上几乎没有必要——延迟太高，运维复杂度太大。

坑2：奇数节点是 Raft 要求不是建议

Raft 的多数确认机制决定了集群节点必须是奇数：3、5、7。4 个节点集群的容错能力和 3 个节点集群一样（只允许 1 个节点故障），但写入需要 3 个确认而不是 2 个——延迟更高但没有更多容错能力。6 个节点同理——容错能力和 5 个节点一样，但确认数更多。

修复方案：集群节点数必须是奇数。这是 Raft 协议的要求，不是最佳实践建议。如果你想在两个可用区各放 2 个节点，再加 1 个仲裁节点在第三个可用区，总共 5 个节点。不要搞出 4 个节点的集群。

坑3：跨可用区部署网络延迟影响写入

etcd 节点分布在 3 个可用区，每个可用区 1 个节点。跨可用区的网络延迟通常是 1~3ms（同区域内），但 Raft 写入需要多数节点确认——最慢的那个节点决定了整体写入延迟。如果某个可用区的网络抖动导致延迟从 2ms 跳到 50ms，整个 etcd 的写入吞吐会骤降。

修复方案：同区域内跨可用区延迟小于 5ms 时可以跨可用区部署。跨区域（延迟大于 10ms）不要部署 etcd——用多集群方案代替跨区域 etcd。监控每个 etcd 节点的网络延迟，设定延迟告警阈值（如 P99 > 10ms）。

坑4：etcd 和 API Server 不要混部

etcd 和 kube-apiserver 跑在同一个节点上。API Server 处理请求时会大量访问 etcd，产生高频率的读写 IO。如果 etcd 和 API Server 共享磁盘和 CPU，IO 争抢会导致 etcd 的 WAL 写入延迟升高——这个延迟直接传导到所有 Kubernetes 操作。

修复方案：etcd 独占节点。至少独占磁盘——etcd 使用独立 SSD（NVMe 优先），API Server 使用另一个磁盘。内存和 CPU 也建议隔离。etcd 节点不需要太多 CPU（2~4 核够用），但磁盘 IO 必须稳定。

三、性能调优：四个关键坑

坑5：磁盘 IO 是瓶颈不是 CPU

etcd 的性能瓶颈在磁盘 WAL 写入。Raft 要求每次写入先持久化 WAL 再确认。如果磁盘 IO 延迟不稳定（SSD 偶尔出现 10ms 以上的写延迟），etcd 的写入吞吐会剧烈波动。我们实测发现：磁盘写延迟从 1ms 波动到 10ms 时，etcd 写入吞吐从 1000 ops/s 降到 100 ops/s。

修复方案：etcd 使用 NVMe SSD 或高性能 SSD。避免使用网络存储（EBS、Ceph）——它们的 IO 延迟比本地 SSD 高 5~10 倍。监控磁盘 IO 告警——etcd_disk_wal_fsync_duration_seconds 的 P99 超过 10ms 就告警。

坑6：没有调 quota-backend-bytes

etcd 默认的存储空间限制是 2GB（quota-backend-bytes 默认值）。大多数 Kubernetes 集群的数据量在几个月内就会超过 2GB。超过限制后 etcd 拒绝所有写入，集群进入只读状态——无法创建 Pod、无法更新 ConfigMap、无法做任何操作。

修复方案：根据集群规模设置合理的 quota-backend-bytes。5000 个 Pod 的集群通常需要 4~8GB。设置值要比实际数据量留 50% 余量。同时设置 db_size 告警——当存储使用超过 quota 的 80% 时告警，不要等到满了才发现。

坑7：compaction 不及时空间无限增长

etcd 的历史版本数据不会自动删除——每次修改都会产生一个新版本，旧版本保留供 watch 和回滚使用。不做 compaction 的话，数据文件会无限增长，几个月后从 2GB 增长到 20GB。

修复方案：定期执行 compaction 和 defrag：

# 压缩到当前revision
etcdctl compact $(etcdctl endpoint status –write-out=json | python3 -c "import sys,json; print(json.load(sys.stdin)[0]['Status']['revision'])")

# 清理碎片
etcdctl defrag

或者设置 auto-compaction-mode=periodic 和 auto-compaction-retention=1h，每小时自动压缩 1 小时前的历史版本。注意：defrag 会暂时阻塞该节点的读写，需要逐个节点执行，不要同时 defrag 所有节点。

坑8：auto-compaction-mode 设错导致性能骤降

auto-compaction-mode 有两个值：periodic（按时间压缩）和 revision（按版本数压缩）。periodic 模式每 N 小时压缩一次，适合写入量稳定的集群。revision 模式每 N 个 revision 压缩一次，适合写入量波动大的集群。如果写入量大的集群用了 periodic 模式且 retention 设得过长（如 24h），一次压缩可能删除百万条历史记录，压缩过程持续数秒，期间写入延迟飙升。

修复方案：写入量大的集群用 revision 模式，每 1000 或 5000 个 revision 做一次压缩。写入量稳定的集群用 periodic 模式，retention 设 1~2 小时。压缩策略上线前要在测试集群验证性能影响。

四、备份恢复：四个最致命的坑

坑9：没有定期备份

最常见也最致命的坑。etcd 没有备份，集群出问题后只能从头重建——所有 Deployment、Service、ConfigMap、Secret 全部丢失。

修复方案：每天至少一次全量备份：

etcdctl snapshot save /backup/etcd-snapshot-$(date +%Y%m%d).db \\
–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

备份文件要存储到远程位置（S3、NFS 等），不要存在 etcd 本机。备份脚本用 CronJob 或系统 cron 执行，不要靠人手动执行。

坑10：备份没有验证可恢复性

做了备份但从来没有验证恢复流程。真正需要恢复时发现：备份文件损坏、证书过期、恢复命令参数不对、恢复后 Kubernetes API 不通。验证缺失的备份等于没有备份。

修复方案：每季度在测试环境做一次恢复演练——用真实备份文件恢复一个测试 etcd 集群，验证 Kubernetes API 正常可用。恢复演练的步骤和命令要写成操作手册，和备份文件一起存储。

坑11：单节点恢复后集群数据不一致

3 节点集群中有 2 个节点数据损坏，用第 3 个节点的备份恢复另外 2 个节点。恢复后 3 个节点的数据 revision 不一致——恢复的节点从备份的 revision 开始，存活节点已经到了更高的 revision。Raft 协议试图同步数据时出现冲突，集群无法达成一致。

修复方案：恢复时所有节点用同一份备份文件，确保起始 revision 一致。恢复顺序：先停掉所有 etcd 节点和 API Server → 清除所有节点的数据目录 → 用同一份备份恢复所有节点 → 启动 etcd 集群 → 启动 API Server。不要只恢复部分节点然后指望 Raft 自动同步。

坑12：恢复时 API Server 没停导致新数据写入

恢复过程中 API Server 没有停掉，仍然向 etcd 写入数据。恢复完成后新写入的数据和恢复的数据混在一起，集群状态不一致。

修复方案：恢复前停掉所有 kube-apiserver 进程。恢复完成后先验证 etcd 数据一致性，确认没问题后再启动 API Server。恢复过程中 Kubernetes 集群完全不可用，需要提前通知业务方。

五、监控告警：四个不可忽略的坑

坑13：只监控进程存活不看磁盘延迟

进程在运行但磁盘 IO 延迟已经飙升到 50ms——etcd 的写入吞吐降到极低水平，Kubernetes 集群的操作全部变慢。但监控只看进程存活，没有告警。

修复方案：必须监控的 etcd 指标清单：

坑14：db_size 告警阈值设得太晚

db_size 告警设到 quota 的 95% 才触发。从 80% 到 95% 可能只需要几天（集群增长快），留给运维的反应时间不够。

修复方案：告警分两级：80% 发 warning 告警，提醒运维做 compaction 或扩容；90% 发 critical 告警，要求立即处理。95% 就太晚了——剩余空间可能只够几个小时的使用量。

坑15：慢查询没跟踪导致级联故障

某些大范围查询（如 kubectl get pods –all-namespaces）会在 etcd 产生慢查询，占用大量 IO 和 CPU。多个慢查询同时执行可能导致 etcd 响应变慢，API Server 超时重试，进一步加重 etcd 负载——级联故障。

修复方案：设置 max-request-bytes 限制单次请求大小（默认 1.5MB，可以降到 512KB 减少慢查询风险）。监控 etcd_server_slow_read_index_count——慢查询数量增加时告警。限制 Kubernetes API 的 list 请求频率——用 ResourceVersion 做 watch 而不是反复 list。

坑16：Leader 切换频繁没告警

etcd Leader 频繁切换意味着 Raft 协议不稳定——节点之间的通信有问题（网络延迟、磁盘 IO 抖动、内存压力）。每次 Leader 切换都会暂停写入，频繁切换导致写入吞吐大幅下降。

修复方案：etcd_server_leader_changes_seen_total 每小时超过 3 次就告警。频繁 Leader 切换的原因排查顺序：磁盘 IO 延迟 → 网络延迟 → 内存压力 → CPU 占用。优先修复磁盘问题——大多数 Leader 切换是磁盘 IO 不稳定导致的。

六、避坑全景图和总结

etcd 运维避坑的核心规律：磁盘 IO 是一切的根基。etcd 的写入性能、Leader 稳定性、集群可用性都直接依赖磁盘 IO 延迟。解决了磁盘问题（NVMe SSD、独占节点、IO 延迟告警），其他问题（compaction、备份、监控）才有解决的基础。不要在磁盘用网络存储的时候去调 compaction 参数——那是在错误的地基上优化上层逻辑。一句话：etcd 运维的第一步不是看文档，而是看磁盘 IO 监控。