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

2021-11-01 09:40:50 浏览数 (1)

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 节点。

代码语言:javascript复制
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,背后只有努力与热爱

欢迎关注「腾源会」公众号,期待你的「在看」哦~

0 人点赞