3. IDP 架构概览：平台工程 IDP 的典型架构
内部开发者平台（IDP）通常采用三面架构：控制面、数据面与租户面。这种分层设计不仅明确了平台工程团队与业务开发团队的职责边界，更是故障域隔离策略的核心依据。理解各组件在故障域中的分布，是制定集群升级边界测试方案的前提。
3.1 三面架构定义与职责
| 架构面 | 核心职责 | 典型组件 | 故障域归属 |
|---|---|---|---|
| 控制面 | 平台策略管理、组件编排、配置下发 | Backstage、Crossplane、ArgoCD、Vault | 全局故障域（跨集群/区域） |
| 数据面 | 工作负载运行、数据持久化、网络代理 | Kubernetes 集群、Istio Sidecar、Prometheus | 本地故障域（单集群/可用区） |
| 租户面 | 应用部署、配置注入、服务暴露 | Deployment、Service、ConfigMap、HPA | 命名空间级故障域（租户隔离） |
关键原则：控制面组件应部署在独立的“管理集群”中，与数据面集群形成物理或逻辑隔离。租户面资源仅存在于数据面集群的命名空间内，平台工程团队不应直接操作租户面资源。
3.2 典型 IDP 架构组件分布图
下图展示了 IDP 三面架构中各组件的逻辑分布与故障域边界。控制面组件集中部署在管理集群，数据面组件分散在多个业务集群，租户面资源则被限制在各自的命名空间内。
3.3 各组件在故障域中的分布策略
故障域隔离的核心目标是：一个故障域内的组件失效，不应扩散至其他故障域。下表详细说明了各组件在故障域中的分布策略与隔离机制。
| 组件 | 所属架构面 | 故障域分布策略 | 隔离机制 |
|---|---|---|---|
| Backstage | 控制面 | 多副本跨可用区部署 | DNS 轮询 + 健康检查 |
| Crossplane | 控制面 | 管理集群内主备模式 | Leader Election |
| ArgoCD | 控制面 | 多实例分片管理集群 | ApplicationSet + 集群 Secret |
| Vault | 控制面 | 跨数据中心集群 | Raft 共识 + 自动解封 |
| Kubernetes API Server | 数据面 | 单集群内 HA | 负载均衡 + etcd 集群 |
| Istio Sidecar | 数据面 | 每个 Pod 独立注入 | Sidecar 容器隔离 |
| Prometheus | 数据面 | 每个集群独立部署 | Thanos 全局视图（只读） |
| 租户 Deployment | 租户面 | 限定命名空间 | NetworkPolicy + RBAC |
3.4 故障域隔离的边界测试要点
集群升级故障域边界测试的核心关注点：
- 控制面升级：管理集群升级时，数据面集群不应感知任何中断。验证 ArgoCD 连接、Crossplane 资源同步是否正常。
- 数据面升级：单个 K8s 集群升级期间，该集群内的租户工作负载应平滑迁移或优雅降级，不影响其他集群的租户。
- 租户面隔离：升级过程中，租户 A 的命名空间资源变更不应影响租户 B 的服务可用性。
- 跨域通信：控制面到数据面的 API 调用（如 Backstage 触发部署）在升级期间应具备超时重试与熔断机制。
3.5 故障域隔离的典型反模式
以下反模式在 IDP 架构中应严格避免，它们会破坏故障域边界，导致升级时的级联故障。
| 反模式 | 问题描述 | 正确做法 |
|---|---|---|
| 控制面组件直接访问租户面资源 | Backstage 直接修改租户命名空间中的 ConfigMap | 通过 ArgoCD Application 声明式同步 |
| 数据面组件依赖控制面实时可用 | Istio 控制面依赖管理集群的 Vault 实时解密 | 使用本地缓存 + 异步同步策略 |
| 租户面资源跨命名空间硬编码 | 租户 A 的 Deployment 直接引用租户 B 的 Service | 通过 Service Mesh 的虚拟服务进行跨命名空间路由 |
| 共享 etcd 集群 | 多个数据面集群共用同一个 etcd 集群 | 每个数据面集群独立部署 etcd |