VPC 与 Cilium ClusterMesh:多集群组网的地基与上层建筑

VPC 是公有云上通过逻辑隔离为你划出的一块"私有网段+自管路由"的虚拟网络,而 Cilium ClusterMesh 解决的是多个 Kubernetes 集群之间的 Pod IP 直连、跨集群服务发现、跨集群 NetworkPolicy 与负载均衡问题;跨集群通信通常通过 VPC Peering/专线打通底层网络后,由 Cilium ClusterMesh、Submariner 等方案组网;集群与机房并非一一对应,常见是"单机房多集群(隔离/灰度)""多机房单集群(同城双活)"和"多机房多集群(异地容灾)"三种模式按容灾等级选择;混合云场景下则建议用"专线 + VPN 主备链路 + 路由器统一打通 CIDR"的思路,把公有云 VPC 与私有化机房做成一张可路由的大内网。

先看两个概念在定位上的差异:

维度 VPC Cilium ClusterMesh
层级 IaaS 层的逻辑网络 Kubernetes 集群间的 CNI 组网
作用范围 单云账号内/跨 VPC 多个 K8s 集群之间的 Pod/Service
核心能力 私网 CIDR、路由表、子网、安全组、VPN/专线 扁平 Pod IP 直连、Global Service、跨集群网络策略
前置依赖 无 各集群节点网络互通 + PodCIDR 不重叠

一、VPC:公有云中的逻辑隔离私有网络

VPC 的本质是在公有云多租户共享的基础设施上,为每个租户划出一块逻辑隔离的私有网络空间,实现"多租户物理共享、逻辑独占"的效果。

  • 网络隔离:你可以自定义私有 IP 网段(CIDR)、划分子网、配置路由表、安全组和网络 ACL,模拟传统数据中心网络;
  • 连接能力:对内通过 VPC Peering / Transit Gateway / 云企业网(CEN)实现 VPC 互通;对外通过 Internet 网关上公网,通过 VPN 网关或物理专线(Direct Connect / 高速通道)与私有化 IDC 打通;
  • 与 K8s 的关系:一个 Kubernetes 集群的节点(含 Pod 所在的虚拟机/裸金属)通常部署在一个 VPC 的若干子网内,Pod 网络可以走 VPC 原生路由(如 AWS ENI、GCP Alias IP),也可以走 Overlay 隧道与 VPC 解耦。

简言之,VPC 是集群的"地基",决定节点之间 L3 是否可达、Pod CIDR 能否被底层路由感知。

二、Cilium ClusterMesh 解决的核心问题

多集群 Kubernetes 通常是为了故障隔离、地理分布、按业务拆分等原因引入,但传统网络模型在跨集群场景下,服务发现、网络分段、策略执行、负载均衡都会失效。ClusterMesh 把 Cilium 的 eBPF 数据面扩展到多个集群,提供了一个"多集群即一张网"的方案,具体解决四类痛点:

  1. 跨集群 Pod-to-Pod 直连:所有集群共享扁平 IP 地址空间,Pod 之间直接通信,无需网关或代理;隧道模式下基于 VXLAN/Geneve,原生路由模式(Native Routing)则依赖底层 VPC/BGP 路由 Pod CIDR;
  2. 跨集群服务发现与负载均衡:通过 service.cilium.io/global: "true" 注解,把不同集群中同名同 namespace 的 Service 合并为一个 Global Service,自动跨集群负载均衡到所有 backend;
  3. 集群感知的网络策略:CiliumNetworkPolicy 可基于标签匹配远端集群的 Pod,实现跨集群的微分段与零信任;
  4. 高可用与故障转移:多 Region/多 AZ 部署时,一个集群故障可切换到另一个集群的 Global Service backend,保障服务持续可用;也支持共享型基础服务(DNS、日志、密钥)跨集群复用。

架构上,每个集群运行一个 clustermesh-apiserver Pod,内含三个容器:

  • etcd:通过 mTLS 向远端暴露本地状态;
  • apiserver:把本地 K8s/Cilium 状态写入 etcd;
  • kvstoremesh:把远端集群状态同步到本地。

集群间为只读同步,一个集群故障不会扩散到其他集群的 etcd。

两个常被忽视的边界条件:一是 maxConnectedClusters 默认为 255,可通过 Helm 提升到 511,但只能在建 mesh 前设定且所有集群必须一致;二是所有集群的 Pod CIDR 必须全局不重叠,Cilium 版本差异不能超过一个 minor 版本。

三、跨集群网络通信:底层打通 + 上层组网

跨集群通信实际分两层:先解决"节点网络可达"的底层路由,再解决"Pod/Service 编排"的上层组网。

3.1 底层连通的几种方式(同一云内 vs 跨云/跨机房)

底层方案 适用场景 特点
VPC Peering 同云同区域 延迟约 1–2ms,配置简单,但路由表需手工加 Pod CIDR
Transit Gateway / 云企业网 CEN 多 VPC + 多 IDC 统一互联 集中路由,支持跨地域
WireGuard / IPsec 隧道 跨云、跨机房、无专线 走公网加密,跨区域延迟 20–50ms
运营商专线 / Direct Connect 生产级混合云 低延迟、高带宽、稳定,可叠加 BGP 动态路由

3.2 上层组网方案对比(以 Pod 直连/服务发现为目标)

方案 核心机制 优点 局限
Cilium ClusterMesh eBPF 数据面 + clustermesh-apiserver 控制面 无网关直连、NetworkPolicy 跨集群生效、性能接近单集群 全互联拓扑、依赖 Cilium CNI、集群数有上限
Submariner IPsec/VXLAN 隧道 + 各集群 gateway 节点 不绑定特定 CNI,社区中立 经过 gateway 转发,多一跳性能损耗
Calico BGP RR 节点间 BGP 路由反射 原生路由无封装开销、吞吐高 需底层网络支持 BGP,云厂商 VPC 路由条目有限制
Istio Multi-Primary / East-West Gateway 七层服务网格 灰度、流量治理能力强 只打通 Service 层,Pod IP 不直连,链路长

Cilium ClusterMesh 的跨集群通信链路可概括为:

1
2
3
4
5
6
7
Pod A (Cluster 1)
  ↓ 本地 Cilium Agent eBPF 程序查 ipcache
  ↓ 命中远端 Endpoint (来自 clustermesh-apiserver 同步)
  ↓ 隧道模式:封装 VXLAN 发往 Cluster 2 节点
     原生路由模式:直接按底层 VPC/BGP 路由 Pod CIDR
  ↓ Cluster 2 节点 eBPF 解封装/收包
  → Pod B (Cluster 2)

跨集群访问 Service 时,Cilium 把两个集群同名 Service 的 backend 合并成 EndpointSlice,负载均衡时可选择本地优先或全局随机。

隧道 vs 原生路由的取舍:VXLAN 每包额外 50 字节开销,在 1500 字节 MTU 下吞吐下降 10–20%,可通过开启 Jumbo Frame 缓解;原生路由模式无封装开销,但要求底层网络能路由所有集群的 Pod CIDR(如云厂商 VPC 或自建 BGP)。

四、集群和机房的对应关系:三种模式按容灾等级选择

Kubernetes 官方明确支持单集群跨多个可用区(AZ)部署,控制面组件(API Server、etcd、scheduler)可复制到至少 3 个 zone,通过 node label + topology spread 实现工作负载跨 zone 分布。但是否跨机房、是否多集群,取决于容灾目标与运维成本。

模式 架构 优点 局限 适用场景
多机房单集群 节点/控制面分布多机房 部署简单、运维成本低、无跨集群复杂性 机房间需高带宽低延迟互联(Stretch 集群 RTT 建议 <5ms,最大 10ms) 同城双机房、机房由同一云厂商提供、追求"单集群体验"
单机房多集群 每个机房/业务域独立集群 故障域隔离、支持不同版本灰度、安全合规隔离 需解决跨集群服务发现、全局负载、数据同步 多租户隔离、开发/生产/测试隔离、同一机房不同业务线
多机房多集群 每机房一个或多个集群 集群级容灾、异地容灾、故障切换 投入最大,需全局 LB、配置同步、双份基础设施 异地多活、金融/监管强制灾备、地理分布式业务

多机房单集群在单机房故障时,剩余机房的控制面节点可完成 Leader 选举,工作节点继续运行,是同城双活的轻量实现;而多集群方案则具备集群级备份能力,某集群升级或故障时可快速将流量切换到其他集群。

一个务实的混合策略是:对实时性要求高的服务在多集群对等部署(复制模式),对实时性要求较低的服务单副本部署、故障时在另一个集群快速重建,通过全局负载均衡按路径特征路由。

五、公有云 + 私有集群的混合组网

混合云的典型诉求是"核心数据库/有状态服务在私有 IDC,弹性业务在公有云",关键是解决链路选型、CIDR 规划、路由统一、高可用四个问题。

5.1 底层链路:专线 + VPN 双链路主备

  • 主链路(专线):物理专线(如运营商 MPLS 或云厂商 Direct Connect / 高速通道)接入云上的虚拟边界路由器(VBR)或全域接入网关(DGW),提供低延迟、高带宽、稳定的内网级通信;
  • 备链路(VPN):IPsec VPN 网关走公网加密隧道,成本低、开通快,专线故障时秒级自动切换,提升网络可靠性;
  • 统一路由平面:把 VPC、VBR、VPN 都挂到一个企业路由器/转发路由器(TR/CEN/Transit Gateway)上,用 BGP 动态路由分发网段,BFD 快速检测链路故障,避免手工切换。

5.2 混合云多集群的推荐落地路径

  1. 网段规划:所有集群的 Pod CIDR、Service CIDR 与 IDC 网段全局不重叠,从 10.0.0.0/8 中统一分配,避免"连上了但不通"的常见根因;
  2. 链路打通:IDC 与云上 VPC 通过专线+VPN 主备互联,云上多 VPC 之间用 Peering 或 CEN;确保所有集群的节点之间网络可达,并放通 Cilium 防火墙端口(如 VXLAN 8472/UDP、Geneve 6081/UDP、health 端口等);
  3. 组网方案选型:云内集群可走 VPC Peering + Native Routing 性能最佳;跨云/跨机房集群可走 VXLAN 隧道 + IPsec/WireGuard 加密,或专线 + ClusterMesh 全互联;对吞吐敏感的生产负载建议专线 + 原生路由,对隔离/安全要求高的金融场景建议 VXLAN + Cilium NetworkPolicy 微分段;
  4. 上层编排:用 Karmada 之类的多集群管理平台做统一的应用下发与调度——它是 CNCF 毕业项目,兼容 K8s 原生 API,支持集群亲和性、多集群拆分/再平衡、Region/AZ/Cluster/Provider 多维高可用调度,能统一纳管公有云、私有化、边缘集群。

5.3 架构选型建议与常见坑

选型上可粗略判断:

  • 同城/同云、追求性能 → VPC Peering + Native Routing;
  • 跨云/跨机房、追求简单 → VXLAN 隧道 + IPsec/WireGuard;
  • 生产级混合云 → 专线+VPN 主备 + Karmada 统一编排 + Cilium ClusterMesh 跨集群组网。

落地时高频踩坑的几件事值得提前规避:

  1. CIDR 冲突是生产环境约 60% 跨集群故障的根因,务必在集群初始化时就用 kOps 等工具指定不重叠的 CIDR;
  2. MTU 问题:VXLAN 封装后有效 MTU 降低,跨云公网隧道常出现分片,建议两端统一调整 MTU 或开启巨帧;
  3. 集群规模:ClusterMesh 默认上限 255,超过需提前规划,且全互联拓扑下集群数量不宜过多;
  4. 版本一致性:所有集群 Cilium 版本差不能超过一个 minor 版本,否则 mesh 建立失败。

小结

把全文收拢成一句话:VPC 决定"地基能不能通",ClusterMesh 决定"多集群怎么组成一张网",机房/容灾模式决定"要几个集群、放在哪里",混合云则是在这三维约束下做链路与 CIDR 的统一规划。

  • VPC 层:私网 CIDR、路由表、专线/VPN 是一切的前提,Pod CIDR 能否被底层路由感知决定了上层组网能选哪条路;
  • 组网层:ClusterMesh(eBPF 直连、Global Service、跨集群策略)适合追求性能与策略统一且已用 Cilium 的团队;Submariner 胜在 CNI 中立;Calico BGP RR 胜在无封装;Istio 只解决 Service 层;
  • 容灾层:多机房单集群(同城双活)、单机房多集群(隔离/灰度)、多机房多集群(异地多活)按 RTT 预算与容灾等级选,实时性要求高的服务对等复制、要求低的单副本+故障重建;
  • 落地层:CIDR 全局不重叠、MTU 两端一致、集群数与版本提前规划——四个坑里 CIDR 冲突独占约 60%,在集群初始化那天就要规划好。

延伸资源