跨云网络与联邦网络：从 VPC Peering 到 Network Fabric

你的业务跑在 AWS 上，合规系统部署在私有云，新收购的团队用的是 Azure。三个 Kubernetes 集群各自运行良好，但当业务需要它们互相调用时，你发现了一个残酷的现实：集群之间的网络，完全不通。

跨云网络不是简单的”打通一条隧道”就能解决的问题。不同云厂商的 VPC 模型、CNI 实现、IP 地址分配策略都有本质差异。在这些差异之上，还要叠加 Service 发现、负载均衡、安全策略、故障切换等高层需求。这是一个从 L2 到 L7 的全栈挑战。

本文要做的事：

梳理跨云网络基础设施层：VPC Peering、Transit Gateway、Cloud Interconnect 的工作原理与适用场景
深入对比三大云厂商的 CNI 实现：AWS VPC CNI、Azure CNI、GKE Dataplane v2
解析三种主流联邦网络方案：Submariner、Cilium ClusterMesh、Istio Multi-Network
分析 Service Mesh 在多云场景中的角色：统一流量管理、跨云 mTLS、地理感知路由
完整案例：设计一个 AWS + Azure + 私有云的三云 K8s 联邦网络

本文基于 Kubernetes 1.30, Cilium 1.16, Istio 1.22, Submariner 0.18。 云平台版本：AWS EKS 1.30, AKS 1.30, GKE 1.30 (Dataplane v2)。

一、跨云网络基础设施层

在讨论 Kubernetes 层面的联邦网络之前，必须先理解底层的云网络互联方式。所有跨云通信最终都要落到这一层。

VPC Peering：最简单的起点

VPC Peering 在两个 VPC 之间建立直连网络路径，流量不经过公网，延迟低、带宽高。

VPC A (10.1.0.0/16)  <---  VPC Peering  --->  VPC B (10.2.0.0/16)
      |                                              |
  Route Table:                                   Route Table:
  10.2.0.0/16 -> pcx-xxx                         10.1.0.0/16 -> pcx-xxx

核心特点：

不可传递性：VPC A 与 B Peering，B 与 C Peering，A 不能通过 B 到达 C
CIDR 不能重叠：两端的地址空间必须完全不同
跨区域支持：AWS 和 GCP 都支持跨 Region 的 VPC Peering，但带宽和延迟会增加
路由条目限制：每个 VPC 的路由表条目有上限（AWS 默认 50 条，可提升）

# 创建 Peering 连接
aws ec2 create-vpc-peering-connection \
  --vpc-id vpc-aaaa1111 \
  --peer-vpc-id vpc-bbbb2222 \
  --peer-region us-west-2

# 接受请求并在两端添加路由
aws ec2 accept-vpc-peering-connection --vpc-peering-connection-id pcx-xxxx
aws ec2 create-route --route-table-id rtb-aaaa \
  --destination-cidr-block 10.2.0.0/16 --vpc-peering-connection-id pcx-xxxx
aws ec2 create-route --route-table-id rtb-bbbb \
  --destination-cidr-block 10.1.0.0/16 --vpc-peering-connection-id pcx-xxxx

VPC Peering 的局限在于不可传递性。N 个 VPC 需要 N*(N-1)/2 条 Peering，在多云场景下迅速变得不可管理。

Transit Gateway：Hub-and-Spoke 中心化

AWS Transit Gateway（TGW）和 Azure Virtual WAN 充当中心路由器，所有 VPC/VNET 只需连接到这个中心节点。

                    +---------------------+
                    |  Transit Gateway    |
                    |  (Hub Router)       |
                    +-----+----+----+----+
                          |    |    |
              +-----------+    |    +-----------+
              |                |                |
        VPC A (10.1.x)  VPC B (10.2.x)  VPC C (10.3.x)

TGW 的核心优势：

传递性路由：A 通过 TGW 可以到达 C，无需直接 Peering
集中路由管理：所有路由规则在一个地方维护
支持 VPN 和 Direct Connect：可以将私有云通过 Site-to-Site VPN 或专线接入
路由分段：通过 Route Table Association 和 Propagation 实现网络隔离

Cloud Interconnect / ExpressRoute / Direct Connect

对于生产级跨云互联，各云厂商都提供了专线接入方案：

云厂商	专线产品	带宽范围	延迟特性
AWS	Direct Connect	1-100 Gbps	稳定低延迟
Azure	ExpressRoute	50 Mbps-100 Gbps	SLA 保障
GCP	Cloud Interconnect	10-200 Gbps	99.99% SLA

跨云互联的典型拓扑是通过 Equinix 等 Colocation 数据中心将多条专线汇聚，由 BGP 承担核心路由交换职责，各云网络前缀通过 BGP 通告实现全网可达。

各云厂商网络特性差异

特性	AWS	Azure	GCP
网络基本单元	VPC	VNET	VPC
子网跨 AZ	不跨	不跨	跨 Region
默认 Pod 网络	VPC 内 ENI IP	Overlay 或 VNET IP	GKE Alias IP
路由表限制	50（可提升到 1000）	400	不限
Network Policy	Calico / Cilium 插件	Azure NPM / Cilium	Dataplane v2 (内置)
最大节点数/集群	5000	5000	15000
Pod CIDR 方式	ENI 二级 IP	节点子网分配	Alias IP Range

这些差异直接影响联邦网络设计。例如 AWS VPC CNI 的 Pod IP 是 VPC 可路由的，而 Azure CNI Overlay 的 Pod IP 在 VNET 外不可路由——跨云通信必须经过 NAT 或隧道。

二、云厂商 CNI 深度对比

CNI 实现的差异是跨云网络最大的挑战之一。每个云厂商的 CNI 都深度集成了自家的网络基础设施，Pod 的 IP 分配、路由逻辑、性能特征在不同云之间完全不同。

AWS VPC CNI：ENI 直接分配 Pod IP

AWS VPC CNI 直接从 VPC 子网中给每个 Pod 分配一个 ENI（Elastic Network Interface）二级 IP。

EC2 实例 (m5.xlarge)
├── ENI-0 (Primary)    : 10.1.1.100 (Node IP)
│   ├── Secondary IP   : 10.1.1.101 -> Pod A
│   ├── Secondary IP   : 10.1.1.102 -> Pod B
│   └── Secondary IP   : 10.1.1.103 -> Pod C
├── ENI-1 (附加)       : 10.1.1.110
│   ├── Secondary IP   : 10.1.1.111 -> Pod D
│   └── Secondary IP   : 10.1.1.112 -> Pod E
└── ENI-2 (附加)       : 10.1.1.120
    └── Secondary IP   : 10.1.1.121 -> Pod F

关键机制：

ipamd 守护进程：在每个节点上运行，预分配 ENI 和 IP，维护”温热”IP 池
WARM_ENI_TARGET / WARM_IP_TARGET：控制预分配策略，避免 IP 分配延迟
实例类型限制：如 m5.xlarge 最多 4 个 ENI，每个 15 个 IP，即最多 58 个 Pod

优势：Pod IP 是 VPC 原生可路由的——安全组可直接引用 Pod IP，VPC Flow Logs 能看到 Pod 级流量，跨 VPC Peering 无需 NAT。劣势：IP 消耗巨大，Pod 密度受限于 ENI/IP 限制。可通过 Prefix Delegation（每个 ENI slot 分配 /28 前缀）缓解 IP 消耗问题。

Azure CNI：Overlay vs Transparent

Azure 提供两种 CNI 模式。Transparent 模式：Pod 从 VNET 子网分配真实 IP，类似 AWS VPC CNI。Overlay 模式：Pod 使用独立的 Overlay 地址空间（如 100.64.0.0/10），节点间通过内核路由封装。

特性	Transparent	Overlay
Pod IP 来源	VNET 子网	独立 Overlay CIDR
VNET 内可路由	是	否（需要 NAT）
IP 消耗	高（与 Pod 数成正比）	低（仅消耗节点 IP）
最大 Pod/节点	受子网大小限制	250（默认）
跨云通信	直接路由	需要网关/隧道

# 创建使用 Overlay CNI 的 AKS 集群
az aks create --resource-group myRG --name myAKS \
  --network-plugin azure --network-plugin-mode overlay \
  --pod-cidr 100.64.0.0/10 \
  --network-policy cilium --network-dataplane cilium

对于跨云场景，Overlay 模式的 Pod IP 在 VNET 之外不可路由，跨云通信必须经过 NAT 或通过 Submariner/Cilium ClusterMesh 建立隧道。

GKE Dataplane v2：基于 Cilium 的原生实现

GKE Dataplane v2 用 eBPF 替代了传统的 kube-proxy iptables/ipvs 转发，提供更高性能和可观测性。

GKE Node (Dataplane v2)
├── Cilium Agent (eBPF programs loaded into kernel)
├── Pod A: 10.4.0.5 (Alias IP from VPC)
├── Pod B: 10.4.0.6 (Alias IP)
└── eBPF Maps: CT, LB, Policy, Tunnel

核心特点：

Alias IP Range：每个节点分配一个 Pod CIDR，IP 通过 VPC Alias IP 分配
无 kube-proxy：Service 转发完全由 eBPF 处理
内置 Network Policy：不需要额外安装 Calico 等插件
可观测性：通过 Hubble 提供 L3/L4/L7 流量观测

跨云影响：Pod IP 通过 Alias IP 在 VPC 内可路由，但跨 VPC 需要 Peering；内置 Cilium 使 ClusterMesh 配置更自然；eBPF 策略可与多集群策略统一管理。

三大 CNI 对比总结

+------------------+-------------------+---------------------+-------------------+
|                  | AWS VPC CNI       | Azure CNI Overlay   | GKE Dataplane v2  |
+------------------+-------------------+---------------------+-------------------+
| IP 分配          | ENI Secondary IP  | Overlay CIDR        | Alias IP Range    |
| VPC/VNET 可路由  | 是                | 否                  | 是                |
| 数据面           | iptables/eBPF     | iptables/Cilium     | eBPF (Cilium)     |
| Pod 密度限制     | ENI/IP per 实例   | 250/节点            | Alias IP 范围     |
| IP 消耗          | 高                | 低                  | 中                |
| 跨云 NAT 需求    | 不需要            | 需要                | 不需要            |
| Network Policy   | 需要插件          | NPM/Cilium          | 内置              |
+------------------+-------------------+---------------------+-------------------+

三、联邦网络架构

有了底层网络互联和对各云 CNI 的理解，现在进入 Kubernetes 层面的联邦网络方案。核心问题是：让不同集群中的 Pod 能够像在同一个集群中一样通信和发现彼此。

Submariner：跨云隧道网关

Submariner 是 CNCF 沙箱项目，在每个集群中选定 Gateway 节点，通过 IPSec 或 WireGuard 隧道连接各集群。

Cluster A (AWS)                      Cluster B (Azure)
+-------------------+                +-------------------+
| Pod 10.1.2.10     |                | Pod 100.64.0.5    |
| Route Engine      |                | Route Engine      |
| Gateway Node      |----IPSec------>| Gateway Node      |
+-------------------+                +-------------------+
        |                                    |
    Broker (集中式服务发现)

Submariner 的组件：

Gateway Engine：建立和维护 IPSec/WireGuard 隧道
Route Agent：配置路由规则，将远程集群 CIDR 指向 Gateway 节点
Broker：集中式元数据交换，各集群通过它交换 Endpoint 和 Service 信息
Lighthouse：跨集群 Service Discovery（ServiceImport/ServiceExport CRD）
Globalnet：处理 CIDR 重叠，为重叠的 Pod/Service CIDR 分配全局唯一 IP

# 部署 Broker 并将各集群加入
subctl deploy-broker --kubeconfig broker-kubeconfig
subctl join --kubeconfig aws-kubeconfig broker-info.subm \
  --clusterid cluster-aws --cable-driver libreswan
subctl join --kubeconfig azure-kubeconfig broker-info.subm \
  --clusterid cluster-azure --cable-driver libreswan

跨集群 Service Discovery：

# 在 AWS 集群中导出 Service
apiVersion: multicluster.x-k8s.io/v1alpha1
kind: ServiceExport
metadata:
  name: payment-api
  namespace: production
---
# Azure 集群中 Lighthouse DNS 自动解析：
# payment-api.production.svc.clusterset.local -> AWS 的 payment-api ClusterIP
# 流量通过 Submariner 隧道到达 AWS

Globalnet 处理 CIDR 重叠：当两个集群的 Pod/Service CIDR 相同时，为每个集群分配 Global CIDR（如 242.0.0.0/16 和 242.1.0.0/16），在隧道两端做 SNAT/DNAT。

Cilium ClusterMesh：跨 VPC 的 eBPF 互联

Cilium ClusterMesh 不依赖独立 Gateway 节点，而是让所有节点的 Cilium Agent 直接共享跨集群状态。

Cluster A (AWS)                      Cluster B (GKE)
+-------------------+                +-------------------+
| Cilium Agent      |                | Cilium Agent      |
| Local etcd -------+--- sync -------+-- Local etcd      |
| eBPF Datapath     |<-- direct ---->| eBPF Datapath     |
+-------------------+                +-------------------+

核心机制：

etcd 同步：各集群 Cilium etcd 将 Endpoint 和 Identity 信息同步给其他集群
全局 Identity：跨集群的安全身份统一（基于 Label）
直接路由或隧道：底层可达用原生路由，否则用 VXLAN/Geneve
全局 Service：一个 Service 可以有跨集群的后端 Pod

# 启用 ClusterMesh 并连接两个集群
cilium clustermesh enable --context aws-cluster
cilium clustermesh enable --context gke-cluster
cilium clustermesh connect --context aws-cluster \
  --destination-context gke-cluster

# 全局 Service 配置
apiVersion: v1
kind: Service
metadata:
  name: order-service
  namespace: production
  annotations:
    service.cilium.io/global: "true"
    service.cilium.io/shared: "true"
spec:
  selector:
    app: order-service
  ports:
  - port: 8080
    targetPort: 8080

ClusterMesh 优势：无中心 Gateway 瓶颈、统一 Network Policy、eBPF 高性能、Identity-based 安全。限制：Pod CIDR 不能重叠（无 Globalnet）、所有集群必须用 Cilium、底层需节点间可达。

Istio Multi-Primary / Multi-Network

Istio 在 L7 层面解决跨集群通信，不直接处理 L3/L4 互联，而是通过 East-West Gateway 在 Service Mesh 层面桥接不同网络。

两个关键维度：控制面拓扑（Primary-Remote 或 Multi-Primary）和网络拓扑（Single-Network 或 Multi-Network）。跨云场景最适合 Multi-Primary + Multi-Network：

AWS Cluster                              Azure Cluster
+----------------------------+           +----------------------------+
| istiod (Primary)           |           | istiod (Primary)           |
| Root CA: shared            |           | Root CA: shared            |
| Pod A -> Envoy Sidecar     |           | Pod D -> Envoy Sidecar     |
| East-West Gateway (LB)  --+--> mTLS --+--> East-West Gateway (LB)  |
+----------------------------+           +----------------------------+

安装要点：

# 1. 生成共享 Root CA 和各集群中间 CA
make -f tools/certs/Makefile.selfsigned.mk root-ca
make -f tools/certs/Makefile.selfsigned.mk cluster-aws-cacerts
make -f tools/certs/Makefile.selfsigned.mk cluster-azure-cacerts

# 2. 各集群创建 CA Secret
kubectl create secret generic cacerts -n istio-system --context aws-cluster \
  --from-file=cluster-aws/ca-cert.pem --from-file=cluster-aws/ca-key.pem \
  --from-file=cluster-aws/root-cert.pem --from-file=cluster-aws/cert-chain.pem

# 3. 安装 Istio（各集群指定 meshID, clusterName, network 和 East-West Gateway）
istioctl install --context aws-cluster -f aws-istio.yaml

# 4. 暴露服务并交换 Remote Secret
kubectl apply --context aws-cluster -f samples/multicluster/expose-services.yaml
istioctl create-remote-secret --context aws-cluster \
  --name cluster-aws | kubectl apply --context azure-cluster -f -
istioctl create-remote-secret --context azure-cluster \
  --name cluster-azure | kubectl apply --context aws-cluster -f -

四、Service Mesh 在多云中的角色

联邦网络解决了”能不能通”的问题，Service Mesh 解决的是”怎么通得好”。在多云环境中提供三个关键能力。

统一流量管理

不同云上的服务可能有不同的版本、容量、健康状态。Service Mesh 提供统一的流量管理抽象：

# 跨云流量分配：80% AWS，20% Azure
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: payment-service
  namespace: production
spec:
  hosts:
  - payment-service.production.svc.cluster.local
  http:
  - route:
    - destination:
        host: payment-service.production.svc.cluster.local
        subset: aws
      weight: 80
    - destination:
        host: payment-service.production.svc.cluster.local
        subset: azure
      weight: 20
---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: payment-service
  namespace: production
spec:
  host: payment-service.production.svc.cluster.local
  trafficPolicy:
    outlierDetection:
      consecutive5xxErrors: 3
      interval: 30s
      baseEjectionTime: 60s
  subsets:
  - name: aws
    labels:
      topology.istio.io/cluster: cluster-aws
  - name: azure
    labels:
      topology.istio.io/cluster: cluster-azure

当某个 Region 故障时，可通过 kubectl patch virtualservice 在几秒内将全部流量切到另一个云。

跨云 mTLS 身份

Istio 通过 SPIFFE 为每个工作负载提供统一加密身份：

spiffe://cluster.local/ns/<namespace>/sa/<service-account>

只要两个集群共享同一 Root CA，SPIFFE 身份就互信，所有跨云通信通过 mTLS 加密和认证：

# 零信任策略：只允许 order-service 调用 payment-api
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: payment-api-policy
  namespace: production
spec:
  selector:
    matchLabels:
      app: payment-api
  action: ALLOW
  rules:
  - from:
    - source:
        principals:
        - "cluster.local/ns/production/sa/order-service"
    to:
    - operation:
        methods: ["POST"]
        paths: ["/api/v1/payments/*"]

无论 order-service 跑在 AWS 还是 Azure，只要 SPIFFE 身份匹配即可访问，不需要维护 IP 白名单。

地理感知路由

Istio 的 Locality-Aware Routing 优先选择地理上最近的后端，避免不必要的跨区域调用：

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: user-service
  namespace: production
spec:
  host: user-service.production.svc.cluster.local
  trafficPolicy:
    outlierDetection:
      consecutive5xxErrors: 3
      interval: 10s
    loadBalancer:
      localityLbSetting:
        enabled: true
        distribute:
        - from: "us-east-1/*"
          to:
            "us-east-1/*": 80
            "eastus/*": 15
            "on-prem/*": 5
        failover:
        - from: us-east-1
          to: eastus
        - from: eastus
          to: us-east-1

来自 AWS 的请求 80% 发到本地，15% 到 Azure，5% 到私有云。如果本地后端全部不健康，自动 Failover 到对端。

五、案例研究：三云联邦网络设计

把所有知识整合起来，设计一个完整的三云 K8s 联邦网络。

架构需求

假设你是一家金融科技公司的平台架构师：

AWS：主要业务集群，核心交易系统（EKS，us-east-1）
Azure：合规与风控系统，金融监管要求（AKS，East US）
私有云：敏感数据处理，自有机房（kubeadm + Cilium，北京 DC）
三个集群的服务需要互相调用，需要统一安全策略和可观测性
总 Pod 规模：AWS 2000+，Azure 500+，私有云 300+

网络规划

第一步确保 CIDR 不重叠：

AWS (EKS):
  VPC/Pod CIDR:   10.1.0.0/16  (VPC CNI, Pod IP = VPC IP)
  Service CIDR:   172.20.0.0/16

Azure (AKS):
  VNET CIDR:      10.2.0.0/16
  Pod CIDR:       100.64.0.0/16  (Azure CNI Overlay)
  Service CIDR:   172.21.0.0/16

私有云 (kubeadm):
  DC Network:     10.3.0.0/16
  Pod CIDR:       10.3.128.0/17  (Cilium native routing)
  Service CIDR:   172.22.0.0/16

基础设施互联层

AWS <-> Azure:   ExpressRoute + Direct Connect (Equinix IX), 10 Gbps, ~5ms
AWS <-> 私有云:  Direct Connect + MPLS, 1 Gbps, ~30ms
Azure <-> 私有云: ExpressRoute + MPLS, 1 Gbps, ~35ms
备用: 各对之间 IPSec VPN 提供冗余

BGP 路由：AWS TGW（AS 64512）宣告 10.1.0.0/16，Azure Route Server（AS 64513）宣告 10.2.0.0/16，私有云路由器（AS 64514）宣告 10.3.0.0/16。

Kubernetes 联邦网络层

采用 Cilium ClusterMesh + Istio Multi-Primary 组合：

Cilium ClusterMesh：L3/L4 跨集群 Pod 互联和 Network Policy
Istio Multi-Primary Multi-Network：L7 流量管理、mTLS、可观测性

选择理由：三个集群都可使用 Cilium CNI；底层已通过专线互通，无需 Submariner 隧道层；Cilium eBPF 数据面性能优于 IPSec。若无专线互通（只能走公网），则 Submariner 的 IPSec 隧道是更好选择。

实施步骤

# Step 1: 三集群安装 Cilium（统一版本）
cilium install --context aws-cluster \
  --set cluster.name=cluster-aws --set cluster.id=1 \
  --set ipam.mode=eni --set tunnel=disabled --set routingMode=native

cilium install --context azure-cluster \
  --set cluster.name=cluster-azure --set cluster.id=2 \
  --set ipam.mode=azure --set tunnel=vxlan

cilium install --context onprem-cluster \
  --set cluster.name=cluster-onprem --set cluster.id=3 \
  --set ipam.mode=cluster-pool \
  --set ipam.operator.clusterPoolIPv4PodCIDRList=10.3.128.0/17 \
  --set tunnel=disabled --set routingMode=native

# Step 2: 启用 ClusterMesh 并建立三对连接
cilium clustermesh enable --context aws-cluster --service-type LoadBalancer
cilium clustermesh enable --context azure-cluster --service-type LoadBalancer
cilium clustermesh enable --context onprem-cluster --service-type NodePort
cilium clustermesh connect --context aws-cluster --destination-context azure-cluster
cilium clustermesh connect --context aws-cluster --destination-context onprem-cluster
cilium clustermesh connect --context azure-cluster --destination-context onprem-cluster

# Step 3: 安装 Istio Multi-Primary Multi-Network
# 生成共享 Root CA，各集群安装 Istio 并配置 East-West Gateway，交换 Remote Secret
# 详见第三节 Istio 安装步骤

故障域与容灾

故障级别          影响范围              恢复策略
─────────────────────────────────────────────────────────────
单 Pod/节点故障   服务实例/节点 Pod     K8s 自动重启/重调度
单 AZ 故障        该 AZ 所有节点        跨 AZ 调度 + Service 摘除
单集群故障        整个云的服务          Istio 流量切换到其他云
专线故障          两云直连              BGP 切换到备用 VPN

# Istio 自动 Failover
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: critical-service
  namespace: production
spec:
  host: critical-service.production.svc.cluster.local
  trafficPolicy:
    outlierDetection:
      consecutive5xxErrors: 2
      interval: 10s
      baseEjectionTime: 30s
      maxEjectionPercent: 100
    loadBalancer:
      localityLbSetting:
        enabled: true
        failover:
        - from: us-east-1
          to: eastus
        - from: eastus
          to: us-east-1
        - from: on-prem
          to: us-east-1

六、性能与安全考量

跨云延迟优化

延迟分解 (AWS us-east-1 -> Azure East US):
基础网络 (Direct Connect):  ~2-5 ms
IPSec/VXLAN 封装:           ~0.5-1 ms
Envoy Sidecar (两端):       ~1-2 ms
mTLS 握手 (首次):           ~2-5 ms (后续连接复用)
East-West Gateway:          ~0.5-1 ms
总计: ~6-14 ms (首次), ~4-9 ms (后续)

优化策略：启用 HTTP/2 连接复用减少 mTLS 握手开销；使用 Cilium WireGuard 加密替代 IPSec（更低 CPU 开销）；通过 Locality-Aware Routing 减少跨云调用。

统一安全策略

多云安全需要多层协同：L3/L4（Cilium Network Policy）做端口级访问控制和 Identity-based 策略；L7（Istio AuthorizationPolicy）做 HTTP 方法/路径控制和 JWT 验证；基础设施层（安全组/NSG）做节点隔离和 Gateway 端口规则。

# Cilium L3/L4 + L7 策略：限制跨云通信到指定端口和路径
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: restrict-cross-cloud
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: payment-api
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: order-service
        io.cilium.k8s.policy.cluster: cluster-azure
    toPorts:
    - ports:
      - port: "8080"
        protocol: TCP
      rules:
        http:
        - method: POST
          path: "/api/v1/payments"

七、可观测性：跨云的统一视图

跨云环境的可观测性是被低估的挑战。当请求从 AWS 经 Azure 到达私有云时，需要端到端的追踪能力。

分布式追踪

Istio 自动为经过 Envoy 的请求注入追踪 Header。结合 OpenTelemetry Collector 将三个云的追踪数据汇聚到统一后端：

# OTel Collector 配置（各集群部署，添加 cloud.provider 和 cluster.name 属性）
apiVersion: v1
kind: ConfigMap
metadata:
  name: otel-collector-config
data:
  config.yaml: |
    receivers:
      otlp:
        protocols:
          grpc:
            endpoint: 0.0.0.0:4317
    processors:
      batch:
        timeout: 5s
      attributes:
        actions:
        - key: cloud.provider
          value: "aws"
          action: upsert
        - key: k8s.cluster.name
          value: "cluster-aws"
          action: upsert
    exporters:
      otlp:
        endpoint: "tempo.observability.svc:4317"
    service:
      pipelines:
        traces:
          receivers: [otlp]
          processors: [batch, attributes]
          exporters: [otlp]

统一指标

使用 Prometheus Federation 或 Thanos 聚合三个集群的指标：

# 跨云延迟 PromQL
istio_request_duration_milliseconds_bucket{
  source_cluster="cluster-aws",
  destination_cluster="cluster-azure"
}

# 跨云错误率
sum(rate(istio_requests_total{response_code=~"5.."}[5m])) by (source_cluster, destination_cluster)
/ sum(rate(istio_requests_total[5m])) by (source_cluster, destination_cluster)

八、常见陷阱与最佳实践

CIDR 规划不当

这是跨云网络中最常见的错误。一旦集群部署完成，Pod CIDR 几乎不可能修改。在项目初期就规划全局地址空间：10.0.0.0/8 内按 /16 分段分配各集群，172.16.0.0/12 内按 /16 给 Service CIDR。

DNS 解析链路

跨集群 DNS 解析容易出问题。确保 CoreDNS 配置了正确的转发规则：

# CoreDNS：将 clusterset.local 查询转发到 Lighthouse DNS
apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns
  namespace: kube-system
data:
  Corefile: |
    .:53 {
        errors
        health
        kubernetes cluster.local in-addr.arpa ip6.arpa {
          pods insecure
          fallthrough in-addr.arpa ip6.arpa
        }
        forward . /etc/resolv.conf
        cache 30
        loop
        reload
    }
    clusterset.local:53 {
        forward . 10.96.0.100
    }

MTU 不一致

不同云的 MTU 不同（AWS 9001 Jumbo Frame，Azure 1500），叠加隧道封装后进一步缩小（IPSec -50，VXLAN -50，WireGuard -60）。建议统一设置 Pod MTU 为各链路最小值：

cilium install --set mtu=1400

关于 MTU 调优的更多细节，参见 MTU 调优。

九、方案选型决策树

面对这么多方案，如何选择？

Q1: 所有集群在同一云厂商内？ -> 是: 云原生方案 | 否: Q2
Q2: 底层网络已互通？ -> 否: Submariner（自带 IPSec/WireGuard 隧道） | 是: Q3
Q3: 所有集群可用 Cilium？ -> 是: Cilium ClusterMesh | 否: Q4
Q4: 需要 L7 流量管理？ -> 是: Istio Multi-Primary Multi-Network | 否: Submariner + Lighthouse

推荐组合:
  生产级多云: Cilium ClusterMesh (L3/L4) + Istio (L7)
  快速验证:   Submariner（全栈方案，部署简单）
  单云多集群: 云原生方案 + Service Mesh

十、总结

跨云网络不是一个可以”一键解决”的问题。它需要在基础设施层、CNI 层、联邦网络层、Service Mesh 层逐层构建，每一层都有自己的权衡。

回顾核心要点：

基础设施层：VPC Peering 解决两两互联，Transit Gateway 解决 Hub-and-Spoke 拓扑，专线解决生产级带宽和延迟
CNI 层：AWS VPC CNI 的 Pod IP 是 VPC 原生路由的，Azure CNI Overlay 需要 NAT，GKE Dataplane v2 基于 Cilium 提供最完整的 eBPF 能力
联邦网络层：Submariner 适合快速打通，Cilium ClusterMesh 适合追求性能和统一策略，Istio Multi-Network 在 L7 层面提供最丰富的流量管理
Service Mesh 层：统一流量管理、跨云 mTLS 零信任、地理感知路由是三个核心价值
实践层面：CIDR 规划必须前置，MTU 必须统一，DNS 转发链路必须可靠，可观测性必须端到端

在多集群网络一文中，我们讨论了同一云内的多集群互联。本文将视野扩展到了跨云场景，这是 Kubernetes 网络领域最复杂的挑战之一。

下一步，你可以从一个 Submariner 的两集群 PoC 开始，验证基本的跨集群连通性，然后逐步引入 Cilium ClusterMesh 和 Istio，构建生产级的多云联邦网络。

参考资料：

Submariner 官方文档

Cilium ClusterMesh 文档

Istio Multi-Cluster 安装指南

AWS VPC CNI 插件文档

Azure CNI Overlay 文档

GKE Dataplane v2 概述

SPIFFE 规范

目录