etcd 在 K8s 中扮演什么角色？为什么说它是集群的命门？

结论：etcd 是 K8s 唯一的持久化存储——集群的全部状态（Pod、Service、ConfigMap、Secret、RBAC、节点注册）以 KV 形式存在 etcd 里，API Server 是唯一与 etcd 交互的组件，其他组件都通过 API Server 读写和 watch。etcd 挂了，集群状态不可读写，控制面瘫痪（运行中的工作负载暂不受影响但无法调度、扩缩、自愈）。

展开：设计要点：1）一致性模型——etcd 基于 Raft，写需要多数派确认，所以集群规模取奇数（3 或 5），容忍 (n-1)/2 个节点故障；2）watch 机制——K8s 的声明式控制循环（controller 监听资源变化）底层就是 etcd 的 watch，API Server 做了一层缓存和事件分发；3）性能边界——默认 2GB 存储上限（可调至 8GB），对象大小建议 <1MB，大规模集群要控制 ConfigMap/Secret 体积和事件风暴（大量 ENDPOINTS 更新是经典杀手）。运维命门：定期快照备份（etcdctl snapshot save）、关注磁盘延迟（WAL fsync 慢会拖垮整个集群的写延迟）、压缩历史版本与碎片整理（defrag）。易错点：1）Secret 在 etcd 默认仅 base64 不是加密，需要配置 EncryptionConfiguration 才是落盘加密；2）跨版本升级要按 etcd 官方路径走，快照恢复是集群灾难恢复的核心手段。

追问方向：Raft 的选主与日志复制流程、API Server 的缓存层（watch cache）如何减轻 etcd 压力。