SuperEdge 和 FabEdge 联合在边缘 K8s 集群支持原生 Service 云边互访和 PodIP 直通
一、背景
在边缘计算的场景下，边缘节点和云端为单向网络，从云端节点无法直接访问边缘节点，导致了以下的问题：
云端无法访问边缘端的 service
边访问云端 service 需要以 nodeport 的形式
云边端 podIp 无法直通
2021 年 8 月 2 日，博云正式开源 FabEdge 边缘网络方案。FabEdge 主要解决边缘计算场景下，容器网络配置管理复杂、网络割裂互不通信、缺少服务发现、缺少拓扑感知能力、无法提供就近访问等难题。为了使用户无感知单向网络带来的的差异，SuperEdge 研发团队与 FabEdge 社区合作，实现在云边 podIp 直通。
二、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 的访问，不再赘述。
三、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 节点。
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 的通信
四、展望
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 研发团队
腾讯云容器中心边缘计算团队
往期阅读推荐
Believe in Open Source 2021.08.04 加入
腾源会是腾讯云成立的汇聚开源项目、开源爱好者、开源领导者的开放社区，致力于帮助开源项目健康成长、开源爱好者能交流协助、开源领导者能发挥领袖价值，让全球开源生态变得更加繁荣。
评论