EdgeMesh 1.8.0 版本发布，支持跨子网边边、跨边云服务通信
01
项目背景
Kubernetes管理的节点通常位于数据中心，具有资源充足、网络拓扑简单的特点，可以部署大型应用；但是在边缘场景下，节点往往是离散分布，位于不同的子网中，同时单个边缘节点资源受限，无法承载复杂的应用，KubeEdge应运而生。
KubeEdge基于Kubernetes构建，是一款使能边缘计算的开放平台，将容器化应用编排能力扩展到边缘的节点和设备，并为云和边缘之间的网络、应用部署和元数据同步提供基础架构支持。
Kubernetes中通过Service关联一组相关的Pod应用并进行服务暴露，通过KubeProxy、CoreDNS组件完成Service的服务发现与流量转发，通过CNI插件如flannel、calico完成Pod间的跨主机通信。但是在边缘场景下，在边缘节点上直接部署KubeProxy、CoreDNS和CNI插件存在以下问题：
-
资源占用：边缘节点资源规格较低，KubeProxy、CoreDNS和CNI插件需要占用较多的资源。 -
网络通信：CNI插件正常工作需要节点之间三层可达，边缘节点通常离散式分布，不满足这一条件，直接访问Service，一旦请求被分发到不同子网的pod上，会出现访问失败的现象。
EdgeMesh的定位是KubeEdge用户数据面轻量化的通讯组件，完成节点之间网络的Mesh，在边缘复杂网络拓扑上的节点之间建立P2P通道，并在此通道上完成边缘集群中流量的管理和转发，最终为用户KubeEdge集群中的容器应用提供与Kubernetes Service一致的服务发现与流量转发体验。
02
应用场景
在边缘计算场景下，应用间的服务发现与流量转发可以划分为以下三种场景：
场景一：子网内边边服务发现与流量转发
子网内边边服务发现与流量转发是EdgeMesh最先支持的特性，为同一个局域网内的边缘节点上的应用提供服务发现与流量转发能力。
智慧园区是典型的边缘计算场景。在同一个园区内，节点位于同一个子网中，园区中的摄像头、烟雾报警器等端侧设备将数据上传到节点上的应用，节点上的应用需要互相的服务发现与流量转发。这种场景下的用户使用流程如下：
-
如上图所示，EdgeNode1和EdgeNode2位于同一个子网中，用户在EdgeNode1上部署了一个Video Server，用于对外提供摄像头采集上来的视频流，并通过标准的Kubernetes Service形式暴露出来，比如video.cluster.local.service。
-
用户在同一个子网内的EdgeNode2上，通过video.cluster.local.service的形式对该Server发起访问，希望获取视频流信息并进行分析处理。
-
位于EdgeNode2上的EdgeMesh-Agent对域名进行解析，并对该访问进行流量劫持。
-
EdgeNode1上的EdgeMesh-Agent与Video Server建立连接， Client与Video Server之间的数据通过EdgeMesh-Agent进行中转，从而获取视频流信息。
场景二：跨子网边边服务发现与流量转发
跨子网边边服务发现与流量转发是EdgeMesh1.8.0版本支持的特性，为位于不同子网内的边缘节点上的应用提供服务发现与流量转发能力。
智慧园区场景中，不同的园区之间通常需要共享一些信息，比如车库停车位数量、视频监控数据等，不同的园区通常位于不同的子网中，因此需要跨子网节点间的服务发现与流量转发能力。这种场景下的用户使用流程如下：
-
如上图所示，EdgeNode1与EdgeNode2位于不同的子网中，用户在EdgeNode1上部署了一个Park Server，用于实时提供园区内停车位的使用情况，并通过标准的Kubernetes Service形式暴露出来，比如park.cluster.local.service。
-
EdgeNode2希望可以获取EdgeNode1所在园区的停车位使用情况，从而为车主提供更全面的停车信息。当位于EdgeNode2上的client以service域名的方式发起访问时，流量会被EdgeMesh-Agent劫持，但是因为EdgeNode1与EdgeNode2位于不同的子网中，两个节点上的EdgeMesh-Agent不能够直接建立连接，因此会出现获取停车位使用信息失败的情况。
场景三：跨边云服务发现与流量转发
跨边云服务发现与流量转发是EdgeMesh1.8.0版本支持的特性，为位于云上和边缘节点上的应用提供服务发现与流量转发能力。下面介绍边访问云的情形，云访问边会遇到和边访问云同样的问题，这里不做赘述。
智慧园区场景中，园区入口需要对访问人员进行人脸识别去决定是否放行，受限于边侧算力，通常会在边侧进行人脸数据的采样，并将采样的数据上传到云端进行运算，因此需要跨边云的服务发现与流量转发。这种场景下的用户使用流程如下：
-
如上图所示，CloudNode1和EdgeNode2分别位于云上和边缘，用户在CloudNode1上部署了一个Face Server，对边侧上报上来的人脸数据进行处理，并返回是否放行的结果，Face Server通过标准的Kubernetes Service形式暴露出来，比如face.cluster.local.service。 -
在边缘侧的EdgeNode2上，用户通过face.cluster.local.service的形式对该Face Server发起访问并上报人脸数据，希望获得是否放行的结果。 -
位于EdgeNode2上的EdgeMesh-Agent对该域名进行解析，并对该访问进行劫持，因为CloudNode1和EdgeNode2位于不同的子网中，两个节点上的EdgeMesh-Agent不能够直接建立连接，因此会出现无法获取是否放行结果的情况。
03
EdgeMesh工作原理
云端是标准的Kubernetes集群，可以使用任意CNI网络插件，比如Flannel、Calico；可以部署任意Kubernetes原生组件，比如Kubelet、KubeProxy；同时云端部署KubeEdge云上组件CloudCore，边缘节点上运行KubeEdge边缘组件EdgeCore，完成边缘节点向云上集群的注册。
EdgeMesh包含两个组件：EdgeMesh-Server和每个节点上的EdgeMesh-Agent。
EdgeMesh-Server工作原理：
-
EdgeMesh-Server运行在云上节点，具有一个公网IP，监听来自EdgeMesh-Agent的连接请求，并协助EdgeMesh-Agent之间完成UDP打洞，建立P2P连接； -
在EdgeMesh-Agent之间打洞失败的情况下，负责中继EdgeMesh-Agent之间的流量，保证100%的流量中转成功率。
EdgeMesh-Agent工作原理：
-
EdgeMesh-Agent的DNS模块，是内置的轻量级DNS Server，完成Service域名到ClusterIP的转换。 -
EdgeMesh-Agent的Proxy模块，负责集群的Service服务发现与ClusterIP的流量劫持。 -
EdgeMesh-Agent的Tunnel模块，在启动时，会建立与EdgeMesh-Server的长连接，在两个边缘节点上的应用需要通信时，会通过EdgeMesh-Server进行UDP打洞，尝试建立P2P连接，一旦连接建立成功，后续两个边缘节点上的流量不需要经过EdgeMesh-Server的中转，进而降低网络时延。
04
核心优势
1）跨子网边边/边云服务通信：无论应用部署在云上，还是在不同子网的边缘节点，都能够提供通Kubernetes Service一致的使用体验。
2）低时延：通过UDP打洞，完成EdgeMesh-Agent之间的P2P直连，数据通信无需经过EdgeMesh-Server中转。
3）轻量化：内置DNS Server、EdgeProxy，边缘侧无需依赖CoreDNS、KubeProxy、CNI插件等原生组件。
4）非侵入：使用原生Kubernetes Service定义，无需自定义CRD，无需自定义字段，降低用户使用成本。
5）适用性强：不需要边缘站点具有公网IP，不需要用户搭建VPN，只需要EdgeMesh-Server部署节点具有公网IP且边缘节点可以访问公网。
网站: https://kubeedge.io
EdgeMesh Github地址：https://github.com/kubeedge/edgemesh
