1. 多集群拓扑基础
1.1 多集群架构概述
随着企业业务规模增长与云原生技术普及，单一 Kubernetes 集群在资源容量、故障隔离、地域分布、环境隔离等方面逐渐暴露出局限性。多集群架构应运而生，其核心目标是通过将工作负载分散到多个集群中，实现更高的可用性、弹性与运维效率。
多集群架构的核心驱动力：
- 故障域隔离：单个集群故障不影响全局业务。
- 资源弹性：跨集群调度，突破单集群节点上限。
- 地域就近访问：降低延迟，满足数据本地化要求。
- 环境与租户隔离：开发/测试/生产环境物理分离，多租户边界清晰。
- 合规与容灾：满足跨区域数据主权与灾难恢复需求。
在多集群拓扑中，控制面与数据面的分离程度决定了架构的复杂度与灵活性。常见的多集群拓扑模式包括 Hub-Spoke（中心辐射）与 Federation（联邦）两种。
1.2 Hub-Spoke 与 Federation 模式对比
| 对比维度 | Hub-Spoke 模式 | Federation 模式 |
|---|---|---|
| 控制面位置 | 中心 Hub 集群集中管理 | 每个集群拥有独立控制面，通过联邦层协调 |
| 资源同步 | Hub 推送配置到 Spoke，Spoke 状态回传 | 联邦控制平面双向同步，支持跨集群资源分发 |
| 网络拓扑 | Spoke 集群通常通过 VPN/专线连接 Hub | 集群间网络对等，通常需要扁平网络或服务网格 |
| 故障影响范围 | Hub 故障影响全局调度，Spoke 可独立运行 | 联邦层故障不影响单个集群自治 |
| 典型场景 | 边缘计算、分支站点、统一策略管控 | 跨区域服务发现、全局负载均衡、统一资源视图 |
| Helm 适配难度 | 较低，Hub 作为 Helm 发布中心 | 较高，需处理多集群 Chart 差异化与冲突 |
选型建议：若企业以统一管控、策略下沉为主要目标，优先选择 Hub-Spoke；若需要跨集群服务发现与全局资源编排，Federation 模式更合适。实际生产环境中，两者可混合使用。
1.3 多集群网络拓扑设计原则
多集群网络是拓扑的骨架，直接影响应用连通性、安全边界与运维复杂度。以下是核心设计原则：
- 网络平面分离：管理网络与业务网络严格隔离，避免控制面流量被业务流量干扰。
- 跨集群通信加密：所有跨集群流量必须使用 mTLS 或 IPSec 加密，防止中间人攻击。
- 服务发现统一：通过全局 DNS、服务网格或联邦 DNS 实现跨集群服务名解析。
- 带宽与延迟可预测：Hub-Spoke 模式下，Hub 集群需具备足够的带宽与冗余；Federation 模式下，集群间链路应满足 SLA。
- 租户网络隔离：每个租户拥有独立的网络命名空间或 VPC，跨集群时通过隧道或 Overlay 网络隔离。
- 可观测性覆盖：网络流量、延迟、丢包率需纳入统一监控，便于快速定位跨集群网络问题。
常见误区：多集群网络设计时，容易忽略控制面流量与业务流量的带宽争抢。建议为控制面流量设置独立的 QoS 队列或专用链路，避免大规模 Helm 发布或状态同步时影响业务稳定性。
1.4 多集群拓扑与 Helm 的关联
Helm 作为 Kubernetes 的包管理工具，在多集群场景下承担着跨集群 Chart 分发、差异化配置注入、版本一致性保障等关键角色。理解多集群拓扑基础，是后续实现租户配额校准的前提——只有明确了集群间的控制关系与网络边界，才能准确地将租户资源配额映射到每个集群的 Helm Release 中。