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

腾讯云原生

收录于话题

SuperEdge 研发团队
FabEdge 研发团队
腾讯云容器中心边缘计算团队

背景

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

云端无法访问边缘端的 service
边访问云端 service 需要以 nodeport 的形式
云边端 podIp 无法直通

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

FabEdge 介绍

架构图

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

FabEdge 包括三个主要组件：

Operator：运行在云端任何节点，监听 Node 等资源的变化，为其它 FabEdge 组件维护证书，隧道等配置，并保存到相应 configmap/secret；同时负责 Agent 的生命周期管理，包括创建/删除等。
Connector：运行在云端选定节点，使用 Operator 生成的配置，负责云端隧道的管理，负责在云端和边缘节点之间转发流量。
Agent：运行在边缘节点，使用 Operator 生成的配置，负责本节点的隧道，路由，iptables 规则的管理。
原理图

以上图环境为例，一共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 直通方案验证

验证的环境

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

验证场景

云端 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 隧道进行转发。

验证结果

云端访边缘端

边缘端 pod 的部署方式	云端 pod 的部署方式	测试项	测试结果
hostnetwork	podIp	cloud-1 访问edge-1	通过
		cloud-1 访问edge-2	通过
		cloud-1 访问clusterIp	通过
podIp	hostnetwork	apiserver 访问service	通过
		apiserver 访问edge-1	通过
		apiserver 访问edge-2	通过
	podIp	cloud-1访问edge-1	通过
		cloud-1访问edge-2	通过
		cloud-1访问clusterIp	通过
		cloud-2 访问edge-1	通过
		cloud-2访问edge-2	通过
		cloud-2访问clusterIp	通过
	hostnetwork	cloud-1 访问edge-1	通过
		cloud-1 访问edge-2	通过
		cloud-1 访问clusterIp	通过
		cloud-2 访问edge-1	通过
		cloud-2 访问edge-2	通过
		cloud-2 访问clusterIp	通过

边缘端访云端

云端 pod 的部署方式	边缘端 pod 的部署方式	测试项	测试结果
podIp	hostnetwork	edge-1 访问cloud-1	通过
		edge-1 访问cloud-2	通过
		edge-1 访问clusterIp	通过
		edge-2 访问cloud-1	通过
		edge-2 访问cloud-2	通过
		edge-2 访问clusterIp	通过
	podIp	edge-1 访问cloud-1	通过
		edge-1 访问cloud-2	通过
		edge-1 访问clusterIp	通过
		edge-2 访问cloud-1	通过
		edge-2 访问cloud-2	通过
		edge-2 访问clusterIp	通过
hostNetwork	podIp	edge-1 访问cloud-1	通过
		edge-1 访问cloud-2	通过
		edge-1 访问clusterIp	通过
		edge-2 访问cloud-1	通过
		edge-2 访问cloud-2	通过
		edge-2 访问clusterIp	通过

边缘端互访

被访问的边缘端 pod 部署方式	发起请求的 pod 的部署方式	测试项	测试结果
hostNetwok	podIp	edge-2 访问edge-1	通过
		edge-2 访问clusterIp	通过
		edge-1 访问edge-2	通过
		edge-1 访问clusterIp	通过
podIp	podIp	edge-2 访问edge-1	通过
		edge-2 访问clusterIp	通过
		edge-1 访问edge-2	通过
		edge-1 访问clusterIp	通过
	hostnetwork	edge-1 访问edge-2	通过
		edge-1 访问clusterIp	通过
		edge-2 访问edge-1	通过
		edge-2 访问clusterIp	通过

结论

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

使用 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】

往期精选推荐