4. 控制平面高可用概述：单点故障风险、高可用度量指标（RTO/RPO）、常见高可用模式（Active/Active, Active/Standby）
4.1 单点故障风险：控制平面为何是“阿喀琉斯之踵”
在 Multi-Cluster 架构中，控制平面（Control Plane）是集群的“大脑”，负责调度、API 响应、控制器循环与资源状态维护。一旦控制平面发生单点故障（Single Point of Failure, SPOF），整个集群将陷入“脑死亡”状态：
- API Server 不可用：kubectl、CI/CD 流水线、自动化运维工具全部无法与集群交互。
- 调度器与控制器停摆：Pod 无法被调度到新节点，Deployment、StatefulSet 等控制器无法执行扩缩容或故障恢复。
- etcd 数据丢失或分裂：作为集群状态存储的 etcd 一旦宕机，所有资源对象（ConfigMap、Secret、Service 等）将不可读，严重时导致数据永久丢失。
⚠️ 风险放大效应：在 Multi-Cluster 架构中，单个集群的控制平面故障可能通过联邦控制面（Federation Control Plane）或 Global Controller 传播，导致跨集群资源调度错乱、流量路由异常，甚至引发级联故障。
4.2 高可用度量指标：RTO 与 RPO
衡量控制平面高可用能力的两个核心指标是 RTO（Recovery Time Objective，恢复时间目标） 和 RPO（Recovery Point Objective，恢复点目标）。下表给出了 Multi-Cluster 场景下的典型参考值：
| 指标 | 定义 | Multi-Cluster 控制平面参考值 | 说明 |
|---|---|---|---|
| RTO | 从故障发生到控制平面完全恢复服务所允许的最大时间 | ≤ 5 分钟（生产级） ≤ 30 秒（关键业务级） |
包括故障检测、切换、数据一致性校验时间 |
| RPO | 故障发生时允许丢失的最大数据量（以时间窗口衡量） | ≤ 1 分钟（生产级） ≤ 0（关键业务级，零丢失） |
主要取决于 etcd 快照与 WAL 日志的同步策略 |
💡 设计原则：在 Multi-Cluster 架构中，RTO 与 RPO 的设定需要与业务连续性等级（BCL）对齐。例如，金融核心交易集群要求 RTO ≤ 30 秒、RPO = 0，而开发测试集群可放宽至 RTO ≤ 15 分钟、RPO ≤ 5 分钟。
4.3 常见高可用模式：Active/Active 与 Active/Standby
控制平面的高可用模式主要分为两类：Active/Active（双活） 和 Active/Standby（主备）。下面通过对比表格和架构图进行详细说明。
4.3.1 模式对比
| 特性 | Active/Active（双活） | Active/Standby（主备） |
|---|---|---|
| 运行实例数 | 多个控制平面实例同时处理请求 | 一个主实例处理请求，一个或多个备实例待命 |
| 资源利用率 | 高（所有实例均承载流量） | 低（备实例处于空闲或轻负载状态） |
| 故障切换时间 | 极短（秒级，无需切换，仅负载均衡剔除故障节点） | 较长（分钟级，需要检测、选举、数据同步） |
| 数据一致性 | 需要强一致性协议（如 Raft）保证多实例状态同步 | 主实例写入，备实例通过日志或快照异步/同步复制 |
| 适用场景 | 对 RTO 要求极高、需要水平扩展的 Multi-Cluster 联邦控制面 | 成本敏感、允许短暂切换窗口的单集群或边缘集群 |
4.3.2 Active/Active 架构示意
下图展示了 Multi-Cluster 控制平面采用 Active/Active 模式时的典型拓扑：
4.3.3 Active/Standby 架构示意
下图展示了 Active/Standby 模式下的控制平面拓扑：
4.4 模式选择建议
📌 决策矩阵：在 Multi-Cluster 架构中，推荐以下选择策略：
- 联邦控制面 / Global Controller：优先采用 Active/Active 模式，配合 etcd Raft 集群，实现跨地域多活，RTO < 5 秒。
- 单集群控制平面：采用 Active/Standby 模式（如 kubeadm 高可用部署），成本可控，RTO 可接受（1~5 分钟）。
- 边缘集群 / 资源受限环境：使用 Active/Standby 简化版，甚至单实例 + 定期备份，RTO/RPO 适当放宽。