3. 多集群 etcd 架构设计:Hub-Spoke 架构、Global Discovery Service、跨集群网络拓扑

在多集群管理场景中,etcd 作为 Kubernetes 控制面的核心数据存储,其架构设计直接决定了跨集群调度的可靠性、一致性与性能。本章深入剖析三种核心架构模式:Hub-Spoke 架构、Global Discovery Service 以及跨集群网络拓扑,帮助 SRE 与平台工程师构建高可用的多集群 etcd 基础设施。

3.1 Hub-Spoke 架构:中心化控制与边缘自治

Hub-Spoke 是多集群 etcd 管理中最经典的拓扑模式。一个中心集群(Hub)承载全局控制面与元数据,多个工作集群(Spoke)运行各自独立的 etcd 集群,并通过 Hub 进行统一注册、监控与策略下发。

核心设计原则:
  • Hub 集群:部署 Global Discovery Service、跨集群调度器、全局 RBAC 与审计日志。etcd 集群建议 5 节点,使用 SSD 与独立网络。
  • Spoke 集群:每个 Spoke 拥有独立的 etcd 集群(3 或 5 节点),仅与 Hub 进行元数据同步,不直接暴露给其他 Spoke。
  • 数据流:Spoke 定期向 Hub 上报心跳、资源水位与事件;Hub 通过 watch 机制将全局策略、服务发现信息推送到 Spoke。
Hub-Spoke 多集群 etcd 架构拓扑 Hub 集群 Global Discovery Service etcd 5 节点 Spoke 集群 A etcd 3 节点 Spoke 集群 B etcd 3 节点 Spoke 集群 C etcd 3 节点 架构说明: • Hub 集群通过 gRPC watch 向 Spoke 推送全局策略与服务发现变更。 • Spoke 集群仅与 Hub 通信,Spoke 之间无直接数据面连接,降低网络复杂度。 • 每个 Spoke 可独立扩缩容,Hub 故障不影响 Spoke 已有工作负载。

3.2 Global Discovery Service:跨集群服务注册与发现

Global Discovery Service(GDS)是 Hub-Spoke 架构中的核心组件,负责维护所有集群的 etcd 端点、版本、健康状态与负载信息。GDS 本身基于 etcd 实现,提供强一致性的服务注册表。

功能模块 说明 关键指标
端点注册 Spoke 集群启动时向 GDS 注册其 etcd 客户端端点列表 注册延迟 < 500ms
健康探测 GDS 定期对每个 Spoke 的 etcd 端点执行健康检查 探测间隔 5s,超时 2s
负载报告 Spoke 上报当前 etcd 的 QPS、延迟 P99、存储大小 上报周期 30s
策略下发 Hub 通过 GDS 将全局租户配额、备份策略分发到 Spoke 下发延迟 < 1s
最佳实践:GDS 的 etcd 集群应与 Hub 控制面 etcd 分离部署,避免全局元数据与业务数据互相干扰。建议 GDS 使用独立的 3 节点 etcd 集群,配置更高的租约 TTL(默认 60s)以应对网络抖动。
Global Discovery Service 交互流程 Global Discovery Service Hub 控制面 Spoke 集群 A Spoke 集群 B Spoke 集群 C 策略下发 健康探测 / 策略推送 注册 / 心跳 健康探测 / 策略推送 GDS 关键流程: 1. Spoke 启动时向 GDS 注册 etcd 端点与版本信息。 2. GDS 定期探测 Spoke 健康状态,异常节点自动摘除。 3. Hub 通过 GDS 将全局策略(租户配额、备份计划)下发到所有 Spoke。

3.3 跨集群网络拓扑:延迟、带宽与故障域

跨集群网络拓扑直接影响 etcd 的 Raft 协议性能与数据同步延迟。设计时需综合考虑物理距离、网络带宽、故障域隔离等因素。

3.3.1 网络拓扑模型对比

拓扑模型 延迟特征 带宽要求 故障隔离 适用场景
同 Region 多 AZ < 2ms 低(1 Gbps) AZ 级 生产核心集群
跨 Region 专线 5-20ms 中(10 Gbps) Region 级 灾备、全局调度
跨云混合 20-100ms 高(100 Gbps+) 云厂商级 多云联邦、边缘

3.3.2 网络拓扑设计原则

  • Raft 成员分布:etcd 集群的所有成员应部署在同一网络故障域内(如同 AZ),避免跨 AZ 的 Raft 心跳延迟导致 Leader 频繁选举。
  • Hub-Spoke 网络:Hub 与 Spoke 之间建议使用专用 VPN 或专线连接,确保带宽 > 1 Gbps,延迟 < 10ms。
  • GDS 网络:GDS 应部署在 Hub 集群所在网络,所有 Spoke 通过稳定的网络路径访问 GDS,避免 NAT 或代理引入额外抖动。
  • 故障域隔离:每个 Spoke 的 etcd 集群应跨多个物理机架或 AZ 部署,但不要跨 Region,以平衡可用性与性能。
常见陷阱:将 etcd 集群成员分散在跨 Region 网络中。Raft 协议对网络延迟高度敏感,跨 Region 延迟超过 20ms 时,Leader 选举时间可能从 50ms 飙升到 5s 以上,导致控制面频繁抖动。务必使用 etcd --experimental-peer-skip-client-san-verification 等参数前充分测试网络延迟。

3.3.3 网络拓扑示例:同 Region 多 AZ 部署

# 网络拓扑参数示例
region: "us-east-1"
azs:
  - name: "us-east-1a"
    etcd_nodes:
      - etcd-0
      - etcd-1
  - name: "us-east-1b"
    etcd_nodes:
      - etcd-2
      - etcd-3
  - name: "us-east-1c"
    etcd_nodes:
      - etcd-4

# Hub 集群网络配置
hub_network:
  cidr: "10.0.0.0/16"
  gds_endpoint: "gds.hub-cluster.svc.cluster.local:2379"
  spoke_access: "vpn-gateway"

# Spoke 集群网络配置
spoke_network:
  cidr: "10.1.0.0/16"
  hub_access: "vpn-tunnel"
  etcd_peer_port: 2380
  etcd_client_port: 2379