3、架构模式总览：单体控制平面 vs 分布式控制平面 vs 分层控制平面
在深入故障注入与隔离验证之前，必须建立对控制平面架构模式的统一认知。不同的架构模式决定了故障传播半径、隔离粒度以及恢复复杂度。本节从单体（Monolithic）、分布式（Distributed）和分层（Hierarchical）三种经典模式出发，对比其控制平面组件间的耦合关系与故障域边界。
3.1 三种架构模式的核心特征对比
| 维度 | 单体控制平面 | 分布式控制平面 | 分层控制平面 |
|---|---|---|---|
| 组件部署 | 所有控制器、调度器、API Server 运行在同一进程或同一节点 | 每个控制组件独立部署，可跨节点运行 | 按层级划分：全局层、区域层、叶子层，每层独立部署 |
| 故障域半径 | 单点故障导致整个控制平面不可用 | 单个组件故障仅影响其管辖范围 | 层级间故障隔离，上层故障影响下层，下层故障不扩散至上层 |
| 状态一致性 | 强一致性（单点 etcd 或单副本） | 最终一致性（多 etcd 节点 + Raft） | 层级内强一致，层级间最终一致 |
| 扩展性 | 水平扩展困难，受限于单节点资源 | 组件级水平扩展，按需增加副本 | 层级独立扩展，全局层可小规模，叶子层可大规模 |
| 典型场景 | 开发/测试环境、边缘小集群 | 生产级 Kubernetes 集群（多 master） | 多集群联邦、跨区域管理、大规模边缘计算 |
关键结论： 故障域划分的粒度与架构模式直接相关。单体模式故障域 = 整个集群；分布式模式故障域 = 单个组件；分层模式故障域 = 单个层级。隔离测试策略必须基于所选模式设计。
3.2 单体控制平面架构
单体控制平面将所有核心组件（API Server、Controller Manager、Scheduler、etcd）打包在单一进程或紧密耦合的节点组中。这是最原始的架构形态，常见于小型测试集群或早期 Kubernetes 部署。
隔离测试注意： 在单体架构中，对 API Server 注入延迟故障将同时阻塞 Controller Manager 和 Scheduler 的通信，因为所有组件共享同一进程空间或网络栈。故障注入点单一，但影响范围覆盖整个控制平面。
3.3 分布式控制平面架构
分布式控制平面将各组件解耦为独立进程，每个组件可独立部署、独立扩缩容。这是生产级 Kubernetes 的标准部署模式，通常采用多副本 API Server + 多节点 etcd 集群（Raft 共识）。
隔离测试优势： 分布式架构允许对单个 API Server 或 Scheduler 进行故障注入，而不影响其他副本。例如，对节点 1 的 API Server 注入 5 秒延迟，节点 2 和节点 3 的 API Server 仍可正常处理请求。故障域被限制在单个组件实例内。
3.4 分层控制平面架构
分层控制平面在分布式基础上引入层级抽象，常见于多集群联邦（KubeFed）、边缘计算（KubeEdge、OpenYurt）或大规模区域管理场景。每层拥有独立的控制平面组件，层与层之间通过 API 网关或消息队列进行松耦合通信。
3.5 故障域划分对比总结
三种架构模式在故障注入测试中的关键差异体现在以下方面：
- 单体模式： 故障注入点少，但每次注入都会影响整个控制平面。适合验证“全损恢复”场景，不适合精细化隔离测试。
- 分布式模式： 故障注入点分散，可针对单个组件副本进行。适合验证“部分降级”场景，如 etcd 单节点故障、API Server 单副本延迟。
- 分层模式： 故障注入可跨层级进行。适合验证“层级隔离”场景，如叶子层网络分区时全局层是否仍能管理其他叶子层。
课程实验建议： 本课程后续章节的故障注入实验将基于分布式控制平面架构（3 节点 etcd + 3 副本 API Server）进行。分层架构的隔离测试将在第 18 章“多集群联邦故障注入”中单独展开。
3.6 架构选择对隔离测试策略的影响
| 测试维度 | 单体模式策略 | 分布式模式策略 | 分层模式策略 |
|---|---|---|---|
| 故障注入目标 | 整个控制平面进程 | 单个组件实例 | 单个层级或层级间通信 |
| 观察指标 | 集群完全恢复时间 | 组件级可用性、请求成功率 | 层级间同步延迟、跨层请求成功率 |
| 恢复验证 | 进程重启后全功能恢复 | 组件副本切换后功能恢复 | 层级重建或重新注册后功能恢复 |
| 典型故障类型 | OOM、进程崩溃、节点宕机 | 网络延迟、丢包、证书过期 | 网络分区、消息队列积压、API 版本不兼容 |