企业官网建设流程全解析

etcd

集群状态的权威存储

底座认知 · 第 05 篇

数据一致性、事务、watch 与快照备份

目 录

一、etcd 的定位

二、数据一致性：Raft 共识

三、etcd 的三大能力

3.1 事务

3.2 watch 机制

3.3 租约与分布式锁

四、etcd 快照与备份

4.1 快照保存

4.2 健康检查

4.3 恢复

五、性能与运维要点

一、etcd 的定位

etcd 是一个高可用的分布式键值存储，是 Kubernetes 集群的「唯一事实来源」（source of truth）。集群的所有期望状态与当前状态，最终都以键值形式保存在 etcd 中。

1. apiserver 是唯一读写 etcd 的组件
2. 丢失 etcd 数据 ≈ 丢失整个集群的配置与状态

生产环境 etcd 通常部署为 3 或 5 节点集群，内置在 Master 节点（kubeadm 默认堆叠模式）或独立部署。

二、数据一致性：Raft 共识

etcd 使用 Raft 共识算法保证多节点间的数据一致。核心要点：

1. 选主：集群选出一个 Leader，负责处理写入
2. 复制：写请求先到 Leader，复制到多数派（Quorum）节点成功后才提交
3. 容忍：3 节点可容忍 1 台故障，5 节点可容忍 2 台故障

理解 Quorum 对容量规划至关重要：奇数节点数、多数派存活才能继续写入。

三、etcd 的三大能力

3.1 事务

etcd 支持事务操作（compare-and-swap），可对多个键做原子性读改写，避免竞态。apiserver 依赖它实现资源版本的乐观锁（resourceVersion）。

3.2 watch 机制

客户端可以 watch 键的变更，获得实时通知。这是 K8s 的「事件驱动」基础——scheduler、kubelet 等通过 watch apiserver 转发的 etcd 变更来感知状态并做出反应。

3.3 租约与分布式锁

etcd 提供租约（lease）与分布式锁能力，K8s 的 leader 选举（如 controller-manager 选主）即基于此实现。

四、etcd 快照与备份

etcd 是最需要重点保护的数据，必须定期快照。以下是生产必备操作：

4.1 快照保存

对堆叠式 etcd（在 Master 上的静态 Pod），使用 etcdctl 命令在任一成员节点执行：

1. etcdctl --cacert=... --cert=... --key=... snapshot save /backup/etcd-snapshot.db
2. 生产建议：配合 crontab 定期执行，并异地保存

4.2 健康检查

1. etcdctl endpoint health --cluster：检查整个 etcd 集群健康
2. 注意：kubectl get componentstatuses 在 1.24+ 已废弃，勿再依赖

4.3 恢复

灾难恢复时，通过 snapshot restore 生成新 etcd 数据目录，再以恢复后的数据重新启动集群。恢复操作需谨慎，通常结合 kubeadm 的 etcd 相关流程进行。

五、性能与运维要点

1. 磁盘性能直接影响 etcd 写入延迟，生产建议使用 SSD
2. 控制 etcd 数据量：及时清理冗余资源，避免大对象频繁变更
3. 监控 etcd 的 leader 是否频繁切换、提交延迟是否升高
4. 备份文件需校验完整性，并定期演练恢复流程

下一篇《scheduler 与 controller-manager》，看控制面如何「决定该往哪调度」和「持续把状态拉回期望」。