etcd

一、现象或背景 我在一个 3 节点自建 K8s（1.28.9 + containerd 1.6.24，节点 16C64G，内核 5.15.0-91，cgroup v2）里把 etcd 拆到独立节点单独管，数据目录在本地 NVMe。业务侧 r

背景 我在一个 3 节点自建 K8s（1.28.9 + containerd 1.6.24，节点 16C64G，内核 5.15.0-91，cgroup v2）里把 etcd 拆到独立节点单独管，数据目录在本地 NVMe。业务侧 revisi

【背景】 做了 10 年分布式系统（一致性协议 + 消息中间件为主），最近复盘了一起线上事故：某节点 NTP 跳变 +42ms（不是回拨，是前跳），导致 etcd 租约判定该节点「心跳超时」，leader 被抢占；与此同时，同一集群的 Ka

【背景】 3 节点自建 K8s 1.28（containerd 1.6），etcd 数据在本地 SSD（/var/lib/etcd）。运维脚本每天 "etcdctl snapshot save /backup/etcd/etcd-$(dat

【背景】 我负责一套生产 etcd 集群（v3.5.6，3 节点，跨 2 可用区），承载 K8s 1.28 的 etcd 后端 + 自研 2 个 Go 服务（直连 etcd 做配置中心）。当前 TLS 配置： - etcd server："

结论先行 etcd 数据目录「只涨不缩」，绝大多数不是写入量大，而是两件事没人管：一是 "compaction" 没跟上（历史 revision 一直堆着），二是 "defrag" 从未执行（被删除的 revision 只标记不回收，物理空

结论先行 分布式锁/租约的"生死"记在 server 的钟上，"续命的节奏"却记在 client 的墙钟上。当 NTP 一次回拨把客户端本地时钟往回拽 12 秒，server 认为租约已过期把锁让给了别人，而旧持有者还以为自己持有——这个"