1. 灾备基础：控制平面灾备的定义、重要性、常见灾备架构
1.1 控制平面灾备的定义
在 Kubernetes 集群中，控制平面（Control Plane） 是集群的“大脑”，负责管理集群状态、调度工作负载、响应 API 请求。控制平面灾备是指通过冗余部署、数据同步和故障切换机制，确保控制平面组件（如 kube-apiserver、etcd、kube-controller-manager、kube-scheduler）在发生故障时能够快速恢复或无缝接管，从而保障集群的持续可用性。
核心目标：当主控制平面节点发生硬件故障、网络分区、软件崩溃或计划内维护时，备用控制平面能够自动或手动接管，最小化 API 服务中断时间，避免 etcd 数据丢失或状态不一致。
1.2 控制平面灾备的重要性
控制平面是集群的单一故障点（Single Point of Failure, SPOF）。一旦控制平面不可用，整个集群将无法响应 API 请求、无法调度 Pod、无法执行滚动更新或扩缩容。下表总结了控制平面故障的影响范围：
| 故障组件 | 直接影响 | 业务后果 |
|---|---|---|
| kube-apiserver | 所有 kubectl/API 调用失败 | 运维人员无法管理集群，CI/CD 流水线中断 |
| etcd | 集群状态丢失或不可读写 | Pod 调度停止，新 Pod 无法创建，已有 Pod 可能被错误驱逐 |
| kube-controller-manager | 控制器循环停止 | Deployment、StatefulSet 等资源无法自动修复 |
| kube-scheduler | 新 Pod 无法分配到节点 | 扩容请求无法执行，业务负载无法增加 |
注意：即使 Worker 节点正常运行，控制平面故障也会导致集群“失明”——无法进行任何变更操作。对于生产环境，控制平面灾备是 SLA 达标的必要条件。
1.3 常见灾备架构概述
Kubernetes 控制平面的灾备架构主要分为两大类：主备架构（Active-Standby） 和 多活架构（Multi-Active）。下面通过架构图与对比表进行详细说明。
1.3.1 主备架构（Active-Standby）
主备架构下，同一时刻只有一个控制平面实例处于活跃状态（Active），处理所有 API 请求；备用实例（Standby）保持同步但处于待命状态。当主实例故障时，通过 VIP 浮动、DNS 切换或负载均衡器重定向，将流量切换到备用实例。
1.3.2 多活架构（Multi-Active）
多活架构下，多个控制平面实例同时处于活跃状态，通过前置负载均衡器分发请求。所有实例均能处理 API 请求，etcd 集群采用 Raft 共识算法保证数据一致性。多活架构通常部署在多个可用区（Availability Zone）中，实现跨 AZ 容灾。
1.4 主备 vs 多活架构对比
| 对比维度 | 主备架构 | 多活架构 |
|---|---|---|
| 资源利用率 | 备用实例闲置，资源浪费 | 所有实例均承载流量，利用率高 |
| 故障切换时间 | 30s ~ 5min（需检测+切换） | 秒级（负载均衡自动剔除故障节点） |
| 数据一致性 | 依赖 etcd 同步延迟，可能丢失少量数据 | Raft 强一致性，无数据丢失 |
| 部署复杂度 | 较低，2 个控制平面节点即可 | 较高，至少 3 个节点 + 跨 AZ 网络 |
| 运维成本 | 手动切换或简单自动化 | 需要负载均衡、健康检查、自动扩缩容 |
| 适用场景 | 中小规模集群、非关键业务 | 大规模生产集群、金融/医疗等强 SLA 场景 |
选型建议：对于本课程后续的 Kyverno 准入控制场景，多活架构是推荐选择。因为 Kyverno 作为准入 Webhook 需要与 kube-apiserver 紧密协作，多活架构能保证准入策略在控制平面故障时仍然持续生效，避免策略执行中断导致的安全风险。
1.5 灾备架构对 Kyverno 准入控制的影响
Kyverno 作为动态准入控制（Dynamic Admission Control）组件，其运行依赖于控制平面的可用性。不同灾备架构下，Kyverno 的部署和策略执行行为存在差异：
- 主备架构：Kyverno 通常部署在主控制平面节点上。当主备切换时，Kyverno Pod 需要重新调度到新的主节点，期间准入策略可能短暂失效。建议将 Kyverno 部署为 DaemonSet 或使用 PDB（PodDisruptionBudget）保障最小可用副本。
- 多活架构：Kyverno 可以部署为多副本 Deployment，每个副本挂载不同的控制平面实例。负载均衡器自动将准入请求分发到健康的 Kyverno 实例，实现策略执行的高可用。