直接回答：etcd 存 K8s 全部集群状态，是强一致的 Raft 集群（通常 3/5 节点）：多数派（quorum）存活才能写。etcd 挂了 API server 立即只读（新调度、扩缩、更新全停），正在跑的 Pod 不受影响但控制面瘫痪——所以是命门。常见故障：磁盘慢导致心跳超时脑裂、磁盘写满（2GB 默认配额）触发告警停写、quorum 丢失（3 节点挂 2）、证书过期。
展开解析：故障展开：慢盘是第一杀手——WAL fsync 慢（P99 超 10ms 即警报）导致 leader 心跳超时频繁重选，症状是 API 间歇性超时、controller 重连风暴，治理是 etcd 独立 SSD（建议 NVMe）加 disk iostat 监控 wal_fsync_duration；配额满——历史版本堆积（K8s 频繁更新的对象产生大量 revision），space quota 超 2GB 进 maintenance 模式只读，处理是 etcdctl compact 压缩历史加 defrag 碎片整理，然后解除告警，长期配 --auto-compaction-retention；quorum 丢失——3 节点挂 2 只剩单节点，集群不可用，恢复靠 etcdctl snapshot restore 从备份重建（所以定期快照备份是底线纪律，snapshot save 加 status 验证）；证书——kubeadm 集群 etcd 证书默认一年，过期 API server 连不上 etcd，报 x509 错误。监控金指标：has_leader、leader_changes_seen（频繁变化=不稳定）、wal_fsync/backend_commit 延迟、db 大小、网络对等延迟。变更纪律：etcd 扩缩容一次动一个节点（保 quorum）；升级逐节点滚动；任何维护前打快照。托管 K8s（EKS/GKE）把 etcd 收走了，但理解这些对排查 API 慢、控制面抖动仍必需——病灶常在 etcd。
追问方向：为什么 etcd 集群推荐奇数节点？compact 与 defrag 的分工与顺序？
（约 500 字）