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

BoCloud博云

关注

发布于: 刚刚

文 | SuperEdge 研发团队

FabEdge 研发团队

腾讯云容器中心边缘计算团队

背景

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

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

为了使用户无感知单向网络带来的差异，FabEdge 与 SuperEdge 合作，实现在云边 podIp 直通。

SuperEdge 介绍

1.1 什么是 SuperEdge ?

SuperEdge 是 Kubernetes 原生的边缘容器方案，它将 Kubernetes 强大的容器管理能力扩展到边缘计算场景中，针对边缘计算场景中常见的技术挑战提供了解决方案，如：单集群节点跨地域、云边网络不可靠、边缘节点位于 NAT 网络等。这些能力可以让应用很容易地部署到边缘计算节点上，并且可靠地运行。SuperEdge 可以很方便地把分布在各处的计算资源放到一个 Kubernetes 集群中管理，包括但不限于：边缘云计算资源、私有云资源、现场设备，打造属于您的边缘 PaaS 平台。

SuperEdge 支持所有 Kubernetes 资源类型、API 接口、使用方式、运维工具，无额外的学习成本。也兼容其他云原生项目，如：Promethues，使用者可以结合其他所需的云原生项目一起使用。

1.2 项目特性

SuperEdge 具有如下特性:

Kubernetes 原生：SuperEdge 以无侵入的方式将 Kubernetes 强大的容器编排、调度能力拓展到边缘端，其原生支持 Kubernetes，完全兼容 Kubernetes 所有 API 及资源，无额外学习成本；
边缘自治：SuperEdge 提供 L3 级边缘自治能力，当边缘节点与云端网络连接不稳定或处于离线状态时，边缘节点可以自主工作，化解了网络不可靠所带来的不利影响；
分布式节点健康监测：SuperEdge 是业内首个提供边缘侧健康监测能力的开源容器管理系统。SuperEdge 能在边缘侧持续守护进程，并收集节点的故障信息，实现更加快速和精准的问题发现与报告。此外，其分布式的设计还可以实现多区域、多范围的监测和管理；
内置边缘编排能力：SuperEdge 能够自动部署多区域的微服务，方便管理运行于多个地区的微服务。同时，网格内闭环服务可以有效减少运行负载，提高系统的容错能力和可用性；
内网穿透：SuperEdge 能够保证 Kubernetes 节点在有无公共网络的情况下都可以连续运行和维护，并且同时支持传输控制协议（TCP）、超文本传输协议（HTTP）、超文本传输安全协议（HTTPS）和 SSH 协议。

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 文档¹。

3.2 验证场景

3.2.1 云端 pod 访问边缘端 pod

3.2.1.1 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 上进行解包。

3.2.1.2 cloud-1 上的 pod 访问边缘端 edge-1 上的 pod

cloud-1 上的 pod，由于不需要通过 flannel 的网络将请求转发到 cloud-1 ，因此 pod 的请求不会经过 cloud-1 的 flannel.1

3.2.2 edge-1 上的 pod 访问 edge-2 上的 pod

由于 edge-1 和 edge-2 在同一个 community ，FabEdge 会在节点之间建立 ipsec vpn 隧道，边缘节点 pod 之间的请求，会通过 ipsec vpn 隧道进行转发。

3.3 验证结果

3.3.1 云端访边缘端