3. IDP平台架构中的故障域设计：控制平面与数据平面的故障域分离、多集群故障域映射
在平台工程IDP（Internal Developer Platform）中，故障域（Failure Domain）设计是保障平台韧性与合规性的核心基础。控制平面与数据平面的分离不仅是架构原则，更是故障隔离的物理与逻辑边界。多集群环境下的故障域映射则决定了故障影响范围与恢复策略的有效性。
3.1 控制平面与数据平面的故障域分离
IDP平台架构中，控制平面负责策略下发、配置管理、API网关、认证授权等管控逻辑；数据平面负责实际的工作负载运行、数据存储与流量转发。两者必须部署在独立的故障域中，避免单点故障扩散。
| 维度 | 控制平面 | 数据平面 |
|---|---|---|
| 故障域粒度 | 独立可用区（AZ）或独立物理集群 | 跨AZ或跨Region分布 |
| 网络隔离 | 管理网络VPC，严格ACL | 业务网络VPC，弹性伸缩 |
| 存储依赖 | etcd/数据库集群，跨AZ冗余 | 分布式存储（如Ceph/Longhorn） |
| 故障影响范围 | 控制平面故障仅影响调度与变更，不影响已有工作负载 | 数据平面故障影响业务连续性 |
| 恢复策略 | 主备切换或冷启动 | Pod自动迁移、流量切换 |
合规审计要点： 控制平面与数据平面的故障域分离必须体现在架构文档与变更审批记录中。审计时需验证：控制平面故障是否导致数据平面工作负载中断？是否存在共享的底层基础设施（如同一物理宿主机、同一网络交换机）？
下图展示了控制平面与数据平面在故障域上的分离设计：
3.2 多集群故障域映射模型
在大型IDP平台中，多集群部署是常态。故障域映射需要将物理基础设施（机房、机架、电源、网络）与逻辑集群（Kubernetes集群、服务网格集群）进行关联，形成可审计的故障域拓扑。
3.2.1 故障域映射层级
- 物理层故障域： 数据中心 → 机房 → 机架 → 物理服务器 → 虚拟机/容器
- 逻辑层故障域： Region → Availability Zone → 集群 → 节点池 → 工作负载
- 控制平面故障域： 管理集群 → 控制平面组件 → etcd成员
- 数据平面故障域： 业务集群 → 命名空间 → 工作负载 → Pod
最佳实践： 每个Kubernetes集群应至少跨3个可用区部署控制平面节点，数据平面节点应均匀分布在至少2个可用区。故障域映射表应作为变更审批的必填附件。
下图展示了多集群环境下的故障域映射关系：
3.3 故障域隔离的合规审计检查项
在审批记录复核过程中，以下检查项必须逐条验证：
| 检查项编号 | 检查内容 | 合规要求 | 审计证据 |
|---|---|---|---|
| FD-001 | 控制平面与数据平面是否部署在不同可用区 | 必须分离 | 集群拓扑图、AZ分布表 |
| FD-002 | etcd集群是否跨AZ部署 | 至少3个AZ | etcd成员列表、AZ标签 |
| FD-003 | 业务工作负载是否跨AZ分布 | 至少2个AZ | Pod拓扑分布约束、调度策略 |
| FD-004 | 是否存在共享物理基础设施的风险 | 无共享机架/电源 | 物理资产清单、机架映射表 |
| FD-005 | 故障域变更是否经过审批 | 变更记录完整 | 变更审批单、影响分析报告 |
风险提示： 如果控制平面与数据平面共享同一物理机架或网络交换机，一旦该机架发生电源故障或网络中断，将同时导致控制平面不可用和数据平面工作负载中断，形成单点故障。此类设计在合规审计中将被判定为严重不符合项。
3.4 故障域隔离的演练验证方法
在IDP故障域隔离演练中，建议采用以下验证方法：
- 混沌工程注入： 模拟单个可用区故障，验证控制平面是否仍能调度、数据平面工作负载是否自动迁移。
- 网络分区测试： 断开控制平面与数据平面之间的网络连接，验证已有工作负载是否持续运行。
- etcd成员故障： 逐个停止etcd成员，验证集群是否仍能正常读写。
- 物理机架断电： 在测试环境模拟单个机架断电，验证故障域映射是否生效。
- 审批记录回溯： 每次演练后，将故障域映射的实际表现与审批记录中的设计进行比对，记录偏差。
审计复核要点： 演练结束后，必须生成《故障域隔离验证报告》，报告中需包含：演练场景、预期行为、实际行为、偏差分析、改进措施。该报告将作为下一次变更审批的前置条件。