控制平面架构概览：API Server、etcd、Controller Manager、Scheduler 的灾备角色
Kubernetes 控制平面由四个核心组件构成：API Server、etcd、Controller Manager 和 Scheduler。在灾备场景下，每个组件的故障模式、恢复策略以及对 RPO（恢复点目标）的影响各不相同。理解这些组件的灾备角色，是设计对齐 RPO 的准入控制策略的前提。
核心组件灾备角色总览
| 组件 | 状态类型 | 灾备关键属性 | RPO 敏感度 | 典型故障影响 |
|---|---|---|---|---|
| API Server | 无状态 | 水平扩展、负载均衡 | 低（仅丢失运行中请求） | 控制面不可用，已有 Pod 继续运行 |
| etcd | 有状态（强一致） | Raft 共识、快照、WAL | 极高（决定集群状态恢复点） | 集群状态丢失或脑裂 |
| Controller Manager | 无状态（Leader 选举） | Leader 选举、重入队 | 低（控制器可重调和重试） | 控制器循环中断，状态收敛延迟 |
| Scheduler | 无状态（Leader 选举） | 调度队列、绑定记录 | 中（未绑定 Pod 需重新调度） | 新 Pod 无法调度，已调度 Pod 不受影响 |
关键结论：etcd 是控制平面灾备的“单点真相”，其 RPO 直接决定了整个集群的恢复点。其他三个组件均为无状态或通过 Leader 选举实现高可用，灾备重点在于快速重建而非数据恢复。
API Server：无状态的流量入口
API Server 是控制平面的唯一入口，所有组件和用户的请求都经过它。它本身不持久化任何状态，所有数据都存储在 etcd 中。灾备设计要点：
- 水平扩展：通过前置负载均衡器（如 HAProxy、Nginx）实现多副本，单实例故障不影响整体可用性。
- 缓存机制：API Server 维护本地缓存（watch cache），故障重启后缓存丢失，但可从 etcd 重新加载。
- RPO 对齐：API Server 的 RPO 几乎为零——它不产生持久化数据，丢失的仅是在故障瞬间正在处理但未写入 etcd 的请求。
etcd：有状态的强一致数据存储
etcd 是控制平面的“心脏”，存储所有集群状态（Pod、Service、ConfigMap、Secret 等）。它使用 Raft 共识算法保证强一致性。灾备设计要点：
- Raft 集群：典型部署为 3 或 5 节点，容忍少数节点故障（3 节点容忍 1 个，5 节点容忍 2 个）。
- 快照与 WAL：定期快照（snapshot）和预写日志（WAL）是实现 RPO 的核心机制。快照频率决定了最大数据丢失窗口。
- RPO 敏感度：etcd 的 RPO 直接等于集群状态的恢复点。例如，每 30 分钟做一次快照，则故障时最多丢失 30 分钟的状态变更。
最佳实践：生产环境建议将 etcd 快照周期设置为 5-15 分钟，并配合 WAL 归档实现接近零 RPO。跨可用区部署 etcd 节点可同时提升可用性和灾备能力。
Controller Manager 与 Scheduler：无状态的 Leader 选举组件
这两个组件通过 Leader 选举机制实现高可用，同一时刻只有一个实例处于 Active 状态。灾备设计要点：
- Leader 选举：基于 etcd 的租约（Lease）机制，故障时备用实例在租约过期后自动接管。
- 重入队与重试：Controller Manager 的控制器在故障恢复后，会重新同步集群状态并重试失败的操作。Scheduler 的调度队列在故障时可能丢失未调度的 Pod，但调度器重启后会重新从 API Server 获取待调度 Pod 列表。
- RPO 对齐：这两个组件的 RPO 敏感度较低。Controller Manager 的丢失操作可通过重调修复；Scheduler 丢失的绑定记录可通过重新调度恢复，但可能引入短暂的调度延迟。
控制平面灾备架构图
下图展示了控制平面核心组件在灾备场景下的数据流与故障隔离边界：
灾备角色对比矩阵
下表从灾备设计的五个关键维度对比四个组件：
| 灾备维度 | API Server | etcd | Controller Manager | Scheduler |
|---|---|---|---|---|
| 数据持久化 | 无 | 有（Raft + 快照） | 无 | 无 |
| 故障切换方式 | 负载均衡摘除 | Raft Leader 切换 | Leader 选举 | Leader 选举 |
| 切换时间 (RTO) | 秒级（健康检查） | 秒级（Leader 选举） | 秒级（租约过期） | 秒级（租约过期） |
| 数据丢失风险 | 运行中请求 | 快照间隔内变更 | 控制器重试队列 | 未调度 Pod 队列 |
| 灾备恢复策略 | 重建实例 + 重新加载缓存 | 快照恢复 + WAL 回放 | 启动新实例 + 全量同步 | 启动新实例 + 重新调度 |
常见误区：不要将 Controller Manager 和 Scheduler 的 Leader 选举机制等同于 etcd 的 Raft 共识。Leader 选举仅保证单实例活跃，不保证数据一致性；etcd 的 Raft 共识保证所有节点数据强一致。灾备测试时，必须分别验证这两种机制的故障切换行为。
灾备准入的 RPO 对齐要点
基于上述角色分析，控制平面灾备准入的 RPO 对齐应遵循以下原则：
- 以 etcd 为锚点：所有组件的 RPO 对齐最终都归结为 etcd 的恢复点。准入控制策略必须首先定义 etcd 的快照频率和 WAL 保留策略。
- 无状态组件快速重建：API Server、Controller Manager、Scheduler 的灾备重点在于 RTO（恢复时间目标），而非 RPO。准入测试应验证这些组件在故障后能否在预期时间内恢复服务。
- 状态依赖链：Controller Manager 和 Scheduler 依赖 API Server 访问 etcd 数据。如果 etcd 恢复点落后，这些组件将基于过时状态运行，可能导致状态不一致。准入测试必须包含“etcd 回滚后组件行为验证”场景。
- 跨组件 RPO 一致性：灾备演练时，应同时验证所有组件的恢复点是否对齐。例如，etcd 恢复到 T0 时刻，API Server 缓存、Controller Manager 的 informer 缓存、Scheduler 的调度队列也必须回退到对应状态。