4. 多集群与单集群故障域：单集群跨AZ部署 vs 多集群联邦部署的故障域差异
在Kubernetes集群架构设计中，故障域（Fault Domain）的划分方式直接决定了系统的可用性边界、资源隔离粒度以及运维复杂度。本章聚焦于两种主流部署模式——单集群跨可用区（AZ）部署与多集群联邦部署，从故障域定义、隔离能力、指标采集范围、告警分层策略四个维度进行系统性对比。
4.1 故障域的基本概念与粒度
故障域是指系统中一组共享同一故障风险组件的资源集合。在Kubernetes场景下，常见的故障域层级包括：
- 物理故障域：机架、电源、网络交换机、数据中心
- 逻辑故障域：集群、命名空间、节点池、AZ
- 控制面故障域：etcd成员、API Server实例、Controller Manager
单集群跨AZ部署与多集群联邦部署在故障域粒度上的核心差异如下表所示：
| 对比维度 | 单集群跨AZ部署 | 多集群联邦部署 |
|---|---|---|
| 故障域粒度 | AZ级别（物理隔离） | 集群级别（完全隔离） |
| 控制面共享 | 共享同一控制面 | 每个集群独立控制面 |
| AZ故障影响范围 | 部分节点/工作负载不可用 | 整个集群不可用 |
| 跨AZ网络延迟 | 通常1-5ms | 取决于集群间网络 |
| 资源统一调度 | 支持（通过拓扑分布约束） | 不支持（需联邦调度） |
| 运维复杂度 | 较低（单集群管理） | 较高（多集群管理） |
关键结论：单集群跨AZ部署适用于对延迟敏感、需要统一调度的场景；多集群联邦部署适用于需要完全故障隔离、跨地域部署或满足合规要求的场景。
4.2 单集群跨AZ部署的故障域特征
单集群跨AZ部署将同一个Kubernetes集群的工作节点分布在多个可用区中，控制面组件通常也采用跨AZ高可用部署。其故障域模型具有以下特征：
- 共享控制面：所有AZ共用同一套API Server、etcd、Controller Manager和Scheduler。控制面本身需要跨AZ部署以实现高可用。
- AZ作为拓扑域：通过
topology.kubernetes.io/zone标签标识节点所属AZ，Pod调度时可使用topologySpreadConstraints实现跨AZ分布。 - 网络扁平化：Pod跨AZ通信通常通过Overlay网络或云厂商VPC实现，延迟和带宽受限于AZ间互联。
- 存储依赖：有状态应用需使用跨AZ复制的持久卷（如AWS EBS跨AZ复制、GCP Persistent Disk区域级PD）。
以下SVG图展示了单集群跨AZ部署的故障域结构：
指标采集要点：单集群跨AZ部署中，指标采集需按AZ维度打标（
zone标签），以便在告警时能够快速定位故障AZ。建议使用kube-state-metrics的--metric-labels-allowlist参数暴露节点topology.kubernetes.io/zone标签。
4.3 多集群联邦部署的故障域特征
多集群联邦部署通过KubeFed（Kubernetes Federation）或类似机制将多个独立集群统一管理。每个集群拥有完全独立的控制面，故障域完全隔离。其核心特征包括：
- 控制面独立：每个集群拥有自己的API Server、etcd和调度器，一个集群的控制面故障不会影响其他集群。
- 联邦控制面：额外的联邦控制面负责跨集群的资源分发、调度和策略管理，但联邦控制面本身不承载工作负载。
- 集群间网络：通常通过VPN、专线或服务网格（如Istio多集群）实现跨集群通信，延迟较高（10-100ms+）。
- 资源隔离：每个集群拥有独立的节点、存储和网络资源，故障完全隔离。
以下SVG图展示了多集群联邦部署的故障域结构：
告警分层注意：多集群联邦部署中，每个集群的Prometheus实例独立采集和告警。联邦控制面应只负责跨集群的聚合告警（如全局SLO违反），而不应直接处理单个集群的节点级或Pod级告警，以避免告警风暴。
4.4 故障域差异对指标采集的影响
两种部署模式在指标采集范围、采集方式和数据聚合策略上存在显著差异：
| 采集维度 | 单集群跨AZ部署 | 多集群联邦部署 |
|---|---|---|
| 采集范围 | 单个Prometheus实例采集所有AZ | 每个集群独立Prometheus实例 |
| 指标标签 | 通过zone标签区分AZ |
通过cluster标签区分集群 |
| 数据聚合 | Prometheus内直接聚合（sum by (zone)） |
需Thanos/Cortex等全局视图聚合 |
| 采集压力 | 单Prometheus压力较大（需采集所有AZ） | 压力分散，每个Prometheus只采集本集群 |
| 跨AZ/集群指标 | 可直接查询跨AZ网络延迟 | 需额外探针或服务网格指标 |
| 指标存储 | 单存储后端（如Thanos接收端） | 多存储后端或联邦存储 |
4.5 故障域差异对告警分层的影响
告警分层策略需要根据故障域模型进行调整。以下是两种模式下的告警分层对比：
| 告警层级 | 单集群跨AZ部署 | 多集群联邦部署 |
|---|---|---|
| L0: 基础设施告警 | 节点级（NodeDown）+ AZ级（AZDown） |
集群级（ClusterDown）+ 节点级 |
| L1: 控制面告警 | etcd成员、API Server跨AZ可用性 | 每个集群独立控制面告警 |
| L2: 工作负载告警 | Pod跨AZ分布比例、AZ级资源不足 | 集群内Pod健康、集群间流量分布 |
| L3: 业务告警 | 全局SLO（跨AZ聚合） | 全局SLO（跨集群聚合） |
| 告警路由 | 按AZ路由到对应值班组 | 按集群路由到对应运维团队 |
| 告警抑制 | AZ故障时抑制该AZ内节点告警 | 集群故障时抑制该集群内所有告警 |
实践建议：
- 单集群跨AZ部署：使用
alertmanager的inhibit_rules实现AZ级告警抑制，例如当AZ整体不可用时，抑制该AZ内所有节点和Pod告警。 - 多集群联邦部署：使用
alertmanager的route按cluster标签分流，每个集群的告警发送到对应的接收器（如Slack频道、PagerDuty服务）。
4.6 故障域切换场景与指标采集策略
当故障域发生切换时（如AZ故障导致Pod迁移到其他AZ，或集群故障导致流量切换到其他集群），指标采集策略需要动态调整：
- 单集群跨AZ切换：
- Pod重新调度后，
zone标签自动更新，Prometheus通过kube-state-metrics自动感知。 - 需监控
kube_pod_status_phase和kube_pod_info指标，确保Pod在新AZ正常启动。 - 告警规则需包含
on(zone)分组，避免跨AZ的Pod状态误判。
- Pod重新调度后，
- 多集群联邦切换：
- 联邦控制面通过
ClusterSelector决定流量分发，指标采集需关注federation_cluster_status指标。 - 使用
thanos query或cortex实现跨集群指标查询，确保切换后全局视图一致。 - 告警规则需包含
cluster标签，支持按集群维度设置不同的阈值（如不同集群的节点规格不同）。
- 联邦控制面通过
指标采集配置示例：以下Prometheus配置展示了如何为单集群跨AZ部署添加zone标签：
# prometheus.yml
scrape_configs:
- job_name: 'kubernetes-nodes'
kubernetes_sd_configs:
- role: node
relabel_configs:
- source_labels: [__meta_kubernetes_node_label_topology_kubernetes_io_zone]
target_label: zone
- source_labels: [__meta_kubernetes_node_label_topology_kubernetes_io_region]
target_label: region4.7 总结：选择建议
根据业务需求选择故障域部署模式时，可参考以下决策矩阵：
| 业务需求 | 推荐模式 | 原因 |
|---|---|---|
| 低延迟跨AZ通信（<5ms） | 单集群跨AZ | 网络扁平化，Pod间通信延迟低 |
| 完全故障隔离 | 多集群联邦 | 控制面独立，一个集群故障不影响其他 |
| 统一资源调度 | 单集群跨AZ | 调度器可全局优化资源分配 |
| 跨地域部署（>100km） | 多集群联邦 | 避免跨地域网络延迟对控制面的影响 |
| 合规要求（数据本地化） | 多集群联邦 | 每个集群可独立控制数据存储位置 |
| 运维团队规模小 | 单集群跨AZ | 运维复杂度低，单集群管理 |
重要提醒：无论选择哪种模式，指标采集和告警分层策略都必须在架构设计阶段明确。单集群跨AZ部署的告警规则需考虑AZ维度，多集群联邦部署的告警规则需考虑集群维度。建议在部署前使用
promtool test rules验证告警规则的正确性。