etcd 在 Kubernetes 中的核心地位：集群状态存储、数据一致性与集群可用性
在 Kubernetes 集群架构中，etcd 是唯一的有状态组件，承担着整个集群“大脑”的角色。它不仅是所有 API 对象的持久化存储后端，更是保障集群一致性与可用性的基石。理解 etcd 的核心地位，是设计灾备策略的前提。
2.1 核心职责：集群状态的唯一权威来源
Kubernetes 的所有资源对象——Pod、Service、ConfigMap、Secret、Deployment、Node 等——在创建、更新或删除时，都会通过 API Server 序列化为键值对写入 etcd。etcd 是集群状态的唯一权威来源（Source of Truth）。任何组件（Scheduler、Controller Manager、Kubelet）的状态变更，最终都必须与 etcd 中的记录对齐。
关键事实： 如果 etcd 数据丢失或损坏，Kubernetes 集群将无法恢复其已知状态，等同于集群“失忆”。即使所有工作节点和容器镜像完好，也无法重建原有的服务拓扑、网络策略或配置信息。
2.2 数据一致性：Raft 共识算法保障
etcd 使用 Raft 共识算法 来保证分布式环境下的数据强一致性。在 etcd 集群中，所有写操作必须经过多数节点（Quorum）确认后才算提交。这一机制直接决定了集群的容错能力和可用性边界。
| 集群节点数 | 最大容忍故障数 | Quorum 要求 | 灾备含义 |
|---|---|---|---|
| 3 | 1 | 2/3 | 单节点故障不影响写入，但需尽快修复 |
| 5 | 2 | 3/5 | 可容忍两个节点同时故障，适合跨可用区部署 |
| 7 | 3 | 4/7 | 更高容错，但写入延迟增加，通常不推荐 |
灾备红线： 当 etcd 集群失去 Quorum（例如 3 节点集群中 2 个节点同时宕机），集群将进入只读模式，无法执行任何写操作（包括 Pod 调度、Deployment 滚动更新、ConfigMap 变更）。此时必须通过备份恢复或重建集群来恢复写入能力。
2.3 集群可用性的依赖链
Kubernetes 控制平面的所有核心组件都直接依赖 etcd 的可用性。一旦 etcd 出现性能抖动或故障，整个控制平面将连锁反应。
2.4 灾备视角下的核心地位总结
从灾备准入的工程视角来看，etcd 的核心地位可以归纳为以下三个不可替代的维度：
- 数据持久性： 集群的“记忆”全部存储在 etcd 中，没有 etcd 备份，就没有灾备恢复的起点。
- 一致性边界： Raft 的 Quorum 机制决定了集群在故障场景下的读写可用性，灾备方案必须围绕 Quorum 设计。
- 恢复依赖： 任何灾备恢复流程（集群迁移、故障切换、数据回滚）的第一步，都是恢复 etcd 数据。
工程建议： 在灾备准入评审中，etcd 的备份恢复演练应作为一票否决项。如果团队无法在限定时间内从备份中恢复 etcd 并验证集群状态正确，则该灾备方案不应被批准上线。