【etcd】生产全景：缺口、五轴坐标系与 16 篇路线
内容提要
本文介绍etcd生产内核系列文章，聚焦Raft共识、WAL持久化、MVCC存储、Watch同步和Lease TTL五条排障坐标系。文章指出常见问题如proposal卡顿、follower读stale、Watch追赶OOM等，并规划16篇阅读路线，强调K8s apiserver与etcd的耦合关系，为运维排障提供系统化框架。
延伸解读
五轴坐标系的价值
文章提出用五条轴（Raft共识、WAL持久化、MVCC存储、Watch同步、Lease TTL）来划分etcd排障问题，每条轴都有明确的核对锚点和失败表象。这种划分帮助运维人员快速定位问题所在层，避免盲目操作。例如，遇到"no leader"优先查Raft轴，而"database space exceeded"则落在MVCC轴。这种系统化方法比单纯依赖etcdctl命令更有效。
committed与applied的区分
文章强调Raft的committed index与MVCC的applied index并不总是同步，二者可能分叉。committed只代表日志被多数派确认，而applied才表示数据真正写入存储。因此，Raft指标健康不代表存储层无问题。排障时需分别监控这两个指标，避免将Raft lag误认为apply lag，或反之。
单Raft组的扩展性限制
etcd采用单Raft组设计，所有key共享同一份日志，这带来全局Revision全序，但也限制了水平扩展。与TiKV的Multi-Raft相比，etcd无法通过增加节点线性提升写吞吐。文章指出，这种设计是K8s resourceVersion语义的基础，但也是写吞吐和磁盘容量的硬顶。选型时需权衡一致性与扩展性。
版本锚定的重要性
文章明确将机制叙述锚定在etcd v3.5.33（源码tag），并强调不以/latest文档冒充。这是因为不同版本的行为可能有差异，如v3.6/v3.7的变更。运维时需注意版本差异，避免将新版本特性误用于旧版本。文章还提醒不要伪造etcdctl输出，确保排障依据真实。
Q&A
etcd 生产环境常见的故障有哪些？
常见的故障包括 proposal 卡顿、follower 读 stale、Watch 追赶 OOM、no leader、quota 超限、ErrCompacted、Lease TTL 漂移等。
etcd 排障五轴坐标系是什么？
五轴坐标系包括：Raft 共识与成员、WAL/持久化与恢复、MVCC/存储与容量、Watch/客户端同步、Lease/TTL 与语义。每轴对应可核对锚点和失败表象。
etcd 中 Raft lag 和 apply lag 有什么区别？
Raft lag 指 committed index 与最新日志的差距，apply lag 指 applied index 与 committed index 的差距。两者不能混为一个指标，因为 committed 不等于 applied。
etcd 的 MVCC 和 ZooKeeper 的 Watch 机制有何不同？
etcd v3 的 MVCC 保留历史版本直到 compaction，支持从任意 revision 重放 Watch；而 ZooKeeper 的 Watch 是一次性的，不保留历史版本。
etcd 中 Watch 客户端从旧 revision 追赶时为什么会触发 ErrCompacted？
当客户端请求的 revision 早于 compaction 保留的版本时，MVCC 已删除该历史版本，因此返回 ErrCompacted，强制客户端全量重同步。
etcd 的 Lease KeepAlive 不经过 Raft，Leader 切换时对 TTL 有何影响？
KeepAlive 不经过 Raft，Leader 切换时 lessor 的时钟语义可能受影响，导致 TTL 漂移，可能造成锁提前释放或 Node NotReady 漂移。
Kubernetes apiserver 与 etcd 的耦合体现在哪些方面？
apiserver 将 etcd 的 Revision 暴露为 resourceVersion，controller 的 resync 和 Watch 断连重连依赖 MVCC 和 Watch 轴，Node Lease 落在 Lease 轴。控制面故障常表现为 apiserver 超时或 503。
etcd 的 16 篇阅读路线中，针对 no leader 症状应该优先读哪些篇目？
若症状是 no leader，优先读第 2、3、15 篇；若是 ErrCompacted，优先读第 4、9、13、15 篇；若是 Node Lease 漂移，优先读第 10、13、15 篇。
