2. 多集群架构基础：集群联邦、Hub-Spoke架构、跨集群网络连通性、多集群统一管理面
在构建服务目录平台容量水位巡检系统时，单一集群无法满足跨地域、跨可用区的高可用与弹性扩展需求。多集群架构是解决这一问题的核心基础。本章将系统阐述四种关键的多集群架构模式与能力：集群联邦、Hub-Spoke 架构、跨集群网络连通性以及多集群统一管理面。理解这些基础概念，是后续设计水位巡检数据传输链路的前提。
2.1 集群联邦（Cluster Federation）
集群联邦是一种将多个独立 Kubernetes 集群统一抽象为一个逻辑集群的架构模式。它允许用户通过一个控制平面（Federation Control Plane）跨集群部署应用、管理配置、实现服务发现与流量调度。
核心价值：联邦机制解决了多集群场景下的“配置漂移”与“资源碎片化”问题，确保服务目录平台在多个集群中的水位巡检 Agent 配置保持一致。
2.1.1 联邦架构组件
| 组件 | 职责 | 在巡检场景中的作用 |
|---|---|---|
| Federation API Server | 提供联邦资源的 CRUD 接口 | 定义统一的巡检任务模板与调度策略 |
| Cluster Registry | 管理成员集群的元数据与连接信息 | 维护各集群的 API Server 地址、证书、区域标签 |
| Federation Controller | 将联邦资源同步到成员集群 | 确保每个集群都部署了水位巡检 DaemonSet |
| DNS / Service Discovery | 跨集群的服务名解析 | 让巡检数据采集器能发现远端集群的 Prometheus |
2.1.2 联邦同步策略
- Push 模式：联邦控制面主动将资源推送到所有成员集群。适用于配置变更频繁、需要强一致性的场景。
- Pull 模式：成员集群定期从联邦控制面拉取最新资源。适用于网络隔离或防火墙限制较多的环境。
- 双向同步：结合 Push 与 Pull，联邦控制面下发初始配置，成员集群可上报状态或局部调整。
实践建议：对于水位巡检这类数据采集任务，推荐使用 Push 模式 下发巡检 Agent 配置，确保所有集群在短时间内获得一致的采集规则与阈值。
2.2 Hub-Spoke 架构
Hub-Spoke 是一种中心辐射型拓扑，广泛应用于多集群管理、网络互联与数据传输场景。在服务目录平台中，通常将中心集群作为 Hub，负责统一调度、数据汇聚与策略下发；各业务集群作为 Spoke，负责本地执行与数据采集。
2.2.1 Hub-Spoke 与联邦的对比
| 维度 | 集群联邦 | Hub-Spoke |
|---|---|---|
| 控制模型 | 对等联邦，所有集群可互为控制面 | 中心化控制，Hub 为唯一管理入口 |
| 数据流向 | 双向同步，资源在集群间复制 | 单向或双向，数据通常汇聚到 Hub |
| 适用规模 | 中小规模（10~50 集群） | 大规模（50~500+ 集群） |
| 网络要求 | 集群间需要全互联或 Mesh 网络 | Spoke 只需单向访问 Hub |
| 巡检场景适配 | 适合配置同步与跨集群服务发现 | 适合数据采集、汇聚与集中告警 |
架构选择提示：如果服务目录平台需要跨集群实时查询水位数据（如 Prometheus 联邦查询），建议采用 Hub-Spoke 架构；如果主要目标是统一管理巡检 Agent 的配置与版本，集群联邦 更为直接。
2.3 跨集群网络连通性
多集群架构的落地离不开可靠的网络连通性。水位巡检数据传输要求低延迟、高吞吐、安全加密。以下是三种主流的跨集群网络方案对比。
| 方案 | 原理 | 延迟 | 安全性 | 运维复杂度 | 推荐场景 |
|---|---|---|---|---|---|
| VPN / 专线 | 通过 IPSec 或云专线打通 VPC | 低（5~20ms） | 高（加密传输） | 中 | 同云厂商、同地域集群 |
| Service Mesh | Sidecar 代理跨集群服务间通信 | 中（增加 2~5ms 代理开销） | 高（mTLS 加密） | 高 | 需要细粒度流量控制与可观测性 |
| CNI 多集群插件 | 如 Cilium Cluster Mesh、Submariner | 低（接近本地网络） | 中（支持加密） | 中 | 大规模 Pod IP 直接通信 |
2.3.1 网络连通性检查清单
- Pod CIDR 不重叠：确保各集群的 Pod 网段、Service 网段不冲突，否则路由无法正常工作。
- DNS 解析：配置跨集群 DNS 服务（如 CoreDNS 联邦），使 Spoke 集群能解析 Hub 集群的服务名。
- 防火墙规则：开放必要的端口（如 6443 用于 API Server，10250 用于 kubelet 指标采集）。
- 带宽与 QoS：水位巡检数据通常为时序指标，单次传输量小但频率高，需保证控制面带宽不被数据面挤占。
巡检数据传输优化：推荐使用 gRPC 双向流 或 Kafka 跨集群 MirrorMaker 作为数据传输通道，配合压缩算法（如 Snappy）减少网络开销。
2.4 多集群统一管理面
统一管理面是运维人员与多集群系统交互的入口。它屏蔽了底层集群的差异，提供一致的 API、UI 与策略引擎。在服务目录平台中，统一管理面需要集成以下能力：
- 集群注册与生命周期管理：支持一键接入新集群、集群健康检查、版本升级。
- 策略引擎：定义全局巡检策略（如采集频率、保留周期、告警阈值），并自动下发到所有集群。
- 全局视图与拓扑：展示所有集群的水位概览、异常分布、资源利用率热力图。
- 审计与合规：记录所有跨集群操作日志，满足内部审计与合规要求。
2.4.1 统一管理面与数据传输的关系
统一管理面不仅是运维入口，更是数据传输的“控制枢纽”：
- 策略驱动采集：管理面定义的数据采集策略（如采集哪些指标、采样频率）直接决定了 Spoke 集群 Agent 的行为。
- 数据路由规则：管理面维护一份全局路由表，指示 Spoke 集群将水位数据发送到哪个 Hub 集群或数据中台。
- 异常重试与补偿：当数据传输链路中断时，管理面负责触发重试机制或切换备用通道，确保数据不丢失。
关键设计原则：统一管理面应保持 控制面与数据面分离。管理面只负责策略下发与状态监控，不参与实际的数据传输路径，避免成为性能瓶颈或单点故障。