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

63 阅读 0 评论 42 点赞

我是靠谱客的博主傲娇苗条，最近开发中收集的这篇文章主要介绍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上进行解包