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,背后只有努力与热爱
欢迎关注「腾源会」公众号,期待你的「在看」哦~