用 Cilium 打通多集群网络：Azure Kubernetes Fleet Manager 的跨集群通信方案

预计阅读时间：9 分钟

管理多个 Kubernetes 集群时，最让人头疼的不是集群本身，而是集群之间的网络。服务跨集群调用、流量路由、安全策略——每一层都得自己搭桥。Azure Kubernetes Fleet Manager 现在引入了基于 Cilium 的跨集群网络，把这件事从"自己造路"变成了"直接上高速"。

为什么跨集群网络一直是痛点

多集群架构在大型组织中已经很常见：开发、预发布、生产各一套集群；不同区域各部署一套满足合规和数据驻留要求；甚至同一业务按团队拆分集群来降低爆炸半径。

但集群一旦拆开，Pod 之间要互相访问就变得复杂。常见做法是：

通过 VNet Peering + VPN 拼凑底层连通性
在每个集群入口部署 Ingress Controller，服务间走公网或内部 Ingress 暴露
用 Service Mesh（如 Istio 多集群模式）做上层流量管理

每一条路都需要大量手动配置，而且性能损耗不可忽视——加密隧道、NAT 转换、多次跳转，延迟叠加明显。

Cilium 跨集群网络的核心思路

Azure Kubernetes Fleet Manager 的方案直接在数据平面解决问题：用 Cilium 的 eBPF 能力，在内核层建立跨集群的网络身份和路由，Pod 跨集群通信不再绕经 Ingress 或隧道。

关键特性包括：

统一网络身份：跨集群的 Pod 拥有可路由的 IP 地址，集群间直接可达，无需 NAT
eBPF 数据平面：转发和策略执行在内核层完成，跳过传统 iptables 链路，性能更高
托管体验：Azure 负责 Cilium 的部署、升级和跨集群配置，用户不需要自己维护 CNI 插件和路由表
与 Fleet Manager 集成：跨集群网络作为 Fleet 的一个网络层能力，和已有的多集群工作负载调度、资源编排配合使用

这意味着，你在 Fleet 中定义的工作负载，可以像在同一集群内一样互相访问——底层网络由平台托底。

实践：在 Fleet 中启用跨集群网络

下面是一个可操作的端到端示例，展示如何创建启用 Cilium 跨集群网络的 Fleet，并部署跨集群可达的服务。

1. 创建 Fleet 并启用跨集群网络

# 先确保你安装了 Azure CLI 的 fleet 扩展
az extension add --name fleet

# 创建 Fleet 资源，启用 Cilium 跨集群网络
az fleet create \
  --name myFleet \
  --resource-group myRG \
  --location eastasia \
  --enable-cross-cluster-networking

# 将已有的 AKS 集群加入 Fleet（集群需已启用 Cilium CNI）
az fleet member create \
  --fleet-name myFleet \
  --member-name cluster-east \
  --resource-group myRG \
  --cluster-resource-group cluster-east-rg \
  --cluster-name cluster-east

az fleet member create \
  --fleet-name myFleet \
  --member-name cluster-west \
  --resource-group myRG \
  --cluster-resource-group cluster-west-rg \
  --cluster-name cluster-west

注意：加入 Fleet 的成员集群必须已经使用 Cilium 作为 CNI。如果你在创建新集群，可以这样做：

az aks create \
  --name cluster-east \
  --resource-group cluster-east-rg \
  --location eastasia \
  --network-plugin cilium \
  --network-plugin-mode overlay

overlay 模式让 Cilium 使用虚拟 IP 地址段，这是跨集群路由的基础——不同集群的 Pod CIDR 不会和 VNet 子网冲突。

2. 验证跨集群连通性

在 cluster-east 部署一个简单的 HTTP 服务：

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: echo-server
  namespace: demo
spec:
  replicas: 2
  selector:
    matchLabels:
      app: echo-server
  template:
    metadata:
      labels:
        app: echo-server
    spec:
      containers:
      - name: echo
        image: hashicorp/http-echo:0.2.3
        args: ["-text", "hello from east"]
        ports:
        - containerPort: 5678
---
apiVersion: v1
kind: Service
metadata:
  name: echo-server
  namespace: demo
spec:
  selector:
    app: echo-server
  ports:
  - port: 80
    targetPort: 5678

# 在 cluster-east 上部署
kubectl --context cluster-east apply -f deployment.yaml

然后在 cluster-west 上用临时 Pod 直接访问跨集群 Service IP：

# 获取 echo-server 的 ClusterIP（假设为 10.224.0.15）
kubectl --context cluster-east get svc echo-server -n demo

# 从 cluster-west 发起跨集群请求
kubectl --context cluster-west run test-curl \
  --image=curlimages/curl \
  --rm -it --restart=Never \
  -- curl -s http://10.224.0.15

如果跨集群网络已生效，你会看到 hello from east 的返回——Pod IP 跨集群直接可达，没有经过 Ingress 或 NAT。

3. 用 NetworkPolicy 控制跨集群流量

Cilium 的 NetworkPolicy 天然支持跨集群维度。你可以限制只有特定命名空间的 Pod 才能跨集群访问：

# networkpolicy.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-cross-cluster-demo
  namespace: demo
spec:
  podSelector:
    matchLabels:
      app: echo-server
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          cross-cluster-access: "true"
  ports:
  - port: 80
    protocol: TCP

kubectl --context cluster-east apply -f networkpolicy.yaml

# 给允许跨集群访问的命名空间打标签
kubectl --context cluster-east label namespace demo cross-cluster-access=true

落地前需要想清楚的几件事

集群规模和 CIDR 规划。跨集群网络要求每个集群的 Pod CIDR 不重叠。Overlay 模式下 Cilium 默认使用 10.244.0.0/16，但多集群场景下你需要为每个集群分配不同的 CIDR 段，或者启用更大范围的地址空间。创建集群时通过 --pod-cidr 参数指定。

延迟与物理距离。跨集群网络打通的是逻辑层路由，物理延迟仍然取决于集群所在的 Azure Region。如果 cluster-east 在东亚、cluster-west 在西欧，Pod 间 RTT 不会因为 Cilium 就消失。对延迟敏感的服务，仍然应该优先同区域部署。

不是所有场景都需要跨集群 Pod 直连。异步任务、事件驱动架构用消息队列（Event Hub、Kafka）解耦更合适。跨集群网络最适合的是同步调用、gRPC 交互、以及需要低延迟直接通信的场景。

升级节奏。Cilium 版本升级由 Azure 托管推进，但 Fleet 成员集群的 Cilium 版本需要保持一致才能确保跨集群路由正常。在 Fleet 管理面，升级会按 rollout 策略逐集群推进——建议在维护窗口内操作，并提前在非生产集群验证。

检查清单

上线前逐条确认：

✅ 所有成员集群已启用 Cilium CNI + Overlay 模式
✅ 各集群 Pod CIDR 不重叠
✅ 成员集群间 VNet 已配置 Peering（底层网络连通性是前提）
✅ Fleet 的跨集群网络功能已启用
✅ NetworkPolicy 已按最小暴露原则配置
✅ 生产集群的跨集群调用有延迟基线测试数据
✅ Cilium 版本升级策略已与 Fleet rollout 策略对齐

跨集群网络从"能凑合用"到"像单集群一样自然"，这是多集群架构走向成熟的关键一步。Azure 把 Cilium 的 eBPF 能力托管化，省去了自建和维护的负担，但网络规划、安全策略、延迟容忍度这些架构决策，仍然需要你自己拍板。