SuperEdge 和 FabEdge 联合在边缘 K8s 集群支持原生 Service 云边互访和 PodIP 直通

PART ONE

背景

在边缘计算的场景下，边缘节点和云端为单向网络，从云端节点无法直接访问边缘节点，导致了以下的问题：

• 云端无法访问边缘端的 service

• 边访问云端 service 需要以 nodeport 的形式

• 云边端 podIp 无法直通

2021 年 8 月 2 日，博云正式开源 FabEdge 边缘网络方案。FabEdge 主要解决边缘计算场景下，容器网络配置管理复杂、网络割裂互不通信、缺少服务发现、缺少拓扑感知能力、无法提供就近访问等难题。为了使用户无感知单向网络带来的的差异，SuperEdge 研发团队与 FabEdge 社区合作，实现在云边 podIp 直通。

PART TWO

FabEdge 介绍

2.1 架构图

FabEdge 在 SuperEdge 的基础上，建立了一个基于 IPSec 隧道的，三层的数据转发面，使能云端和边缘端 POD 通过 IP 地址直接进行通讯，包括普通的 POD 和使用了 hostnework 的 POD，以及通过 ClusterIP 访问 Service，不论 Service 的 Endpoint 在云端或边缘端。

FabEdge 包括三个主要组件：

• Operator：运行在云端任何节点，监听 Node 等资源的变化，为其它 FabEdge 组件维护证书，隧道等配置，并保存到相应 configmap/secret；同时负责 Agent 的生命周期管理，包括创建/删除等。

• Connector：运行在云端选定节点，使用 Operator 生成的配置，负责云端隧道的管理，负责在云端和边缘节点之间转发流量。

• Agent：运行在边缘节点，使用 Operator 生成的配置，负责本节点的隧道，路由，iptables 规则的管理。

2.2 原理图

以上图环境为例，一共4个节点，两个云端的节点：node1， node2， 两个边缘节点：edge1， edge2。node1和 node2 运行 Flannel，它们之间会有一个 flannel 管理的 VXLAN 的隧道。edge1 和 edge2 由 FabEdge 管理，会建立到运行 Connector 的节点 node1 的 IPSec 的隧道。

同时，edge1 和 edge2 加入了同一个 FabEdge 的 Community， 因此它们之间会有一条直连的 IPSec 隧道。在边缘节点上，POD 接入一个 Linux 的网桥，获取一个全局唯一的 IP 地址。

几种典型的访问场景如下：

• 边缘 POD 访问云端的 POD， 比如 c1（蓝色虚线）, 流量从源 pod 发出，经过网桥，经过路由，iptables 规则，xfrm 策略，进入 IPSec 隧道，到达云端 Connector 节点 node1，到达目标 pod。

• 边缘 POD 访问边缘的 POD， 比如 c2（红色虚线）, 流量从源 pod 发出，经过网桥，经过路由，iptables 规则，xfrm 策略，进入 IPSec 隧道，到达边缘节点 edge2，到达目标 pod。

• 边缘 POD 访问云端的 POD， 比如 c3（紫色虚线）, 流量从 pod 发出，经过网桥，经过路由，iptables 规则，xfrm 策略，进入 IPSec 隧道，到达云端 Connector 节点，再经过一次路由转发，使用 Flannedl 的  VXLAN 隧道，到达目标节点 node2，到达目标 pod。

• 云端 POD 访问云端的 POD， 比如 c4（绿色虚线），仍然有 Flannel 管理，通过 VXLAN 到达目标 pod，这个过程和 FabEdge 无关。

• POD 访问 Service，经过本地 kube-proxy 管理的 iptables NAT 后，等同于 POD 到 POD 的访问，不再赘述。

PART THREE

FabEdge 与 SuperEdge 结合实现 Service 互访和 podIp 直通方案验证

3.1 验证的环境

在 SuperEdge 边缘独立集群中添加4个节点，2个节点（cloud-1和cloud-2）在云端和 master 节点在同一内网，2个节点（edge-1和edge-2）在边缘端。将 cloud-1 节点作为 connector 节点，将 edge-1 和 edge-2 加入 community。具体的搭建过程，请参照 FabEdge文档[1]。

3.2 验证场景

云端 pod 访问边缘端 pod

cloud-2 上的 pod 访问边缘端 edge-1 上的 pod

FabEdge 在 edge-1 节点的 node 资源写入 cloud-1 的节点的内网 IP 和 flannnel.1 网卡的 mac 地址，将 edge-1 伪装成 cloud-1 节点。

metadata:
  annotations:
    flannel.alpha.coreos.com/backend-data: '{"VtepMAC":"cloud-1 flannel.1 mac"}'
    flannel.alpha.coreos.com/backend-type: vxlan
    flannel.alpha.coreos.com/kube-subnet-manager: "true"
    flannel.alpha.coreos.com/public-ip: cloud-1 内网ip

• cloud-2上的pod访问cloud-1上的pod请求，首先经过cni0网桥，根据路由规则，将请求转发到flannel.1上，由flannel.1对请求信息进行封包，由于FabEdge将edge-1节点伪装成cloud-1节点，因此flannel.1会将封包之后的请求信息发送到cloud-1节点。

• cloud-1节点在接收到请求包之后，会在本节点的flannel.1对请求包进行解包，然后将请求通过ipsec vpn隧道转发到edge-1节点。edge-1节点在收到包之后根据路由规则将请求包发送br-fabedge网桥，然后再转发到pod中。

• 回包路径与请求包路径一样，响应消息到达cloud-1之后，先在flannel.1上进行封包，然后发送到cloud-2上，在flannel.1上进行解包

cloud-1 上的 pod 访问边缘端 edge-1 上的 pod

cloud-1 上的 pod，由于不需要通过 flannel 的网络将请求转发到 cloud-1，因此pod的请求不会经过 cloud-1 的 flannel.1。

edge-1 上的 pod 访问 edge-2 上的 pod

由于 edge-1 和 edge-2 在同一个 community，FabEdge 会在节点之间建立 ipsec vpn 隧道，边缘节点 pod 之间的请求，会通过 ipsec vpn 隧道进行转发。

3.3 验证结果

云端访边缘端

边缘端访云端

边缘端互访

3.4 结论

根据以上的测试结果可以得出以下的结论：

• 使用 FabEdge 可以实现云边端 service 互访

• 使用 FabEdge 可以实现云边 podIp 直通

• 使用 FabEdge 不影响边缘节点间 pod 的通信

PART FOUR

展望

SuperEdge 和 FabEdge 已完成了一期的集成工作，社区有不少小伙伴对这个联合方案感兴趣。两个开源社区主要研发团队也一直在推进合作，近期腾讯云和博云建立了开源技术合作关系，并且博云加入到腾讯云原生加速器项目中，双方将会进一步加强合作，为开源社区贡献优秀的开源项目。

后续 FabEdge 和 SuperEdge  还会找更多的边缘网络场景进行互相合作，确定会进行的一些 TODO 如下：

• SuperEdge 支持更多的 CNI，包括 Calico、Cilium 等。

• SuperEdge NodeUnit 和 FabEdge Community 自动同步标签，简化边边通讯流程

• 支持 FabEdge Connector的HA/HPA，以便网络的稳定性和高可性的支持

欢迎持续关注 SuperEdge 和 FabEdge 对边缘网络方面的支持。

参考资料

[1]FabEdge文档: https://github.com/FabEdge/fabedge/blob/Release-v0.3-beta/docs/integrate-with-superedge.md

本文转载自：腾讯云原生 公众号

作者：SuperEdge 研发团队

FabEdge 研发团队

腾讯云容器中心边缘计算团队

  往期阅读推荐

• CNCF Sandbox 再添“新将”！云原生边缘容器开源项目 SuperEdge 正式入选

• 如何评价一个开源项目（一）--活跃度

• 腾讯程序员不寻常的三年

• 我的9年开源之路：395 Patch、20+Feature，背后只有努力与热爱
  

欢迎关注「腾源会」公众号，期待你的「在看」哦～👇