| 编辑推荐: |
本文介绍了一种边缘基础设施，它支持边缘节点的调度服务，与云中的虚拟机相同，并考虑了边缘环境特殊字符,希望对您有所帮助
。
本文来自于CSDN，由火龙果软件Alice编辑、推荐。 |
|
摘要
在本文中，我们为Edge-cloud通信和执行环境引入了Edge基础架构（KubeEdge），我们将其视为云基础架构的扩展。此边缘基础架构允许Edge采用现有云服务和云开发模型，并提供边缘和云之间的无缝通信。KubeEdge包括一个名为KubeBus的网络协议栈，一个分布式边缘元数据存储/同步服务和一个应用程序编排服务。KubeBus旨在拥有自己的OSI第2/3/4层协议实现，支持将云端的边缘节点和虚拟机连接为一个VPN，并为不同租户的边缘集群提供通用的多租户管理/数据平面。在Cloud和Edge中运行的服务在KubeBus之上相互通信，具有容错性和高可用性。KubeEdge中的Edge元数据服务提供边缘元数据存储和服务，以在云和Edge之间同步元数据，以支持边缘节点脱机方案。KubeEdge包括Kubernetes
[1]扩展，以便Kubernetes可以管理Edge Nodes以及Cloud中的VM，并部署/管理Edge
Nodes的应用程序。
1 介绍
随着边缘设备的增加，我们更希望很多任务在本地执行，而不是上传到云数据中心。我们需要一种新型的计算范式，它能够在网络的边缘执行任务，它就是边缘计算。而在近几年，随着物联网的发展，边缘计算模型变得越来越重要。
在Edge计算中，最初在云中运行的服务部署到Edge环境，并与其他Edge服务和云服务协作。Edge服务调度，生命周期管理和监控可以从Cloud完成。例如，之前的研究[3]通过扩展现有平台和优化的WAN环境算法推动了数据中心的计算。除了常见的数据处理这样的数据过滤和聚合之外，AI过程也从数据中心推送到Edge，比如最近的研究[4]“在神经网络层的粒度上划分移动设备和数据中心之间的DNN计算”。
“云计算是基于TCP / IP的高级开发和计算机技术的集成，如快速微处理器，巨大的内存，高速网络和可靠的系统架构。”[云计算的特征]。有成熟的商业云计算基础设施来管理云应用程序。例如，IaaS基础设施OpenStack，Amazon
EC2; 容器化应用管理系统Kubernetes [1]，docker swarm。
现有的云计算基础架构可能不会直接应用于Edge环境。这是因为Edge环境与云环境不同，涉及网络连接/拓扑，网络带宽和相对受限的计算资源。例如，一个典型的Edge场景是多个Edge节点和云通过广域网（WAN）连接。边缘节点在NAT后面的专用网络中运行，因此在云上运行的TCP客户端无法连接到在Edge上运行的TCP服务;
此外，Edge和Cloud之间的网络可能不稳定，在Edge运行的服务需要能够脱机运行; 边缘节点和云之间的带宽小于云，并且更昂贵;
最后，一些边缘节点具有约束计算资源，例如仅128 MB内存。
Edge基础架构基于以下3个组件：
KubeBus将边缘节点和虚拟机连接为VPN，并将一个多租户管理/数据平面连接到所有租户的边缘集群;
EdgeMetadataService，支持Cloud和Edge之间的元数据存储和Edge和a-synchronization元数据;
Kubernetes扩展，支持边缘应用程序部署和生命周期管理。
该基础架构适用于将基于微服务的应用程序从Cloud扩展到Edge。
本文的其余部分安排如下。第2节讨论边缘计算基础设施的相关工作; 第3节介绍了KubeEdge的架构和设计;
第4节KubeBus的实验结果; 第5节讨论未来的工作; 第6节总结了论文。
2 相关工作
在物联网（IoT）时代，全球部署了数十亿个传感器和执行器。为了管理物联网设备并使用云计算资源处理来自它们的数据，云提供商提供的物联网平台包括Azure物联网平台，AWS
IoT和Google IoT解决方案。物联网平台使用诸如Mqtt [9]或AMQP之类的发布/订阅代理来处理物联网设备和云服务之间的通信通道，例如Azure
IoT中心。
物联网设备数量巨大，物联网数据太大，无法容纳互联网带宽发送到云端。云提供商发布Edge平台，如AWS
GreenGrass [5]和Azure IOT Edge [6]，以管理Edge端的IoT应用程序执行和IoT数据处理以及Cloud和Edge之间的数据传输。例如，GreenGrass将AWS
Lambda函数环境扩展到Edge，以便Edge应用程序可以作为Lambda函数部署到Edge并在Edge中进行管理。在AWS
GreenGrass中，Edge服务通过Pub / Sub消息相互通信并与Cloud服务进行通信。Azure
IoT Edge还具有Edge Hub，可将IoT Hub的功能扩展到Edge，并为Edge服务提供Pub
/ Sub通信。在这个模型中，通过为物联网设备设计的类似通道，基于Pub / Sub sematic的中心云边缘节点通信。从Central
Cloud的角度来看，Edge节点被视为一种特殊的IoT设备。
服务，每个服务都在自己的进程中运行，并与轻量级机制通信，通常是HTTP资源API。要将基于Micro-service的云应用程序扩展到Edge，一个应用程序的部分小型服务将部署在Edge
Nodes中。边缘服务应该与云中的相同RPC以及其他云服务相互通信。为实现此目标，Edge平台需要提供与云相同的执行环境。在环境中，无论服务是在Edge还是Cloud中运行，服务都可以在一个集群中相互通信。此外，微服务应在Edge节点和具有相同部署基础架构的云之间自由调度。
发布/订阅协议可能不适合将微服务从Cloud扩展到Edge。由于跨微服务RPC可能不是发布/订阅协议，因此基于发布/订阅协议的边缘计算基础结构中运行的服务需要重构以满足基础结构要求。
KubeEdge为Cloud和Edge环境构建了一个同构执行环境。它解决了KubeBus的边缘节点连接拓扑问题，它将端口中的边缘节点，虚拟机和容器网络连接为VPN;
它还包括一个Kubernetes扩展，可将Kubernetes功能扩展到Edge环境，以便Edge服务可以像Cloud一样部署到Edge;
KubeEdge通过EdgeMetadataService减轻Edge与云的不稳定连接，EdgeMetadataService在Edge提供元数据存储，在Cloud和Edge之间提供元数据同步。下一节将为他们提供详细设计。
3 架构和设计
图1 KubeEdge架构
KubeEdge提供了一个多租户的Edge基础设施。就像图1中所描述的那样，在云数据中心一侧，它包括多租户的管理/数据平面，并且还有多个租户的集群。多租户的管理/数据平面包括云中心的KubeBus以及租户管理功器。一个租户集群包括在边缘区域运行的一个或多个边缘节点，以及在云中运行的一个Kubernetes集群。Kubernetes集群包括Kubernetes主机和多个虚拟机。Kubernetes
master将vm和边缘节点都作为正常的Kubernetes节点。
每个边缘节点中都运行一个KubeEdge代理。KubeEdge代理包括提供边缘网络接入的KubeBus、提供边缘连接元数据存储和同步服务的EdgeMetadataService;以及管理Edge应用程序生命周期的AppEngine。AppEngine是运行在Edge上的轻量级Kubelet。
在云区域，对于每个租户的Kubernetes集群，在一个VM节点上运行一个KubeBus虚拟路由器，路由边缘节点子网与VM子网/容器网络子网之间的流量;KubeMaster中还运行着一个EdgeController，用于在KubeMaster和edge节点之间交换边缘服务配置和状态。
3.1 KubeBus
在KubeEdge环境中，一个服务既可以调度到云上的VM当中，也可以调度到边缘节点，边缘节点的服务使用与云环境相同的RPC与其他服务通信。KubeBus是为了解决边缘服务与云服务之间的通信问题而设计的，边缘服务运行在边缘节点上，而云服务运行在云环境中的容器网络上。KubeBus还支持针对多个租户的单个管理/数据平面，并提供Http。从边缘节点发布WebService。
3.1.1 Edge Node VPN
KubeBus的第一个功能是连接在边缘虚拟私有网络中的边缘节点。在一个典型的边缘环境中，不同的边缘节点运行在不同的私有网络中，没有公共IP地址，只能通过NAT连接到云端，两个边缘节点之间没有直接的网络连接。两个边缘节点的通信需要通过KubeBus@Cloud进行路由。KubeBus是3层的覆盖网络。如图2所示，KubeBus通过TCP连接实现OSI网络模型的L2和L3。KubeBus数据链路层在Edge节点和KubeBus@
cloud之间创建一个或多个长期运行的TCP连接。KubeBus还包括一个TUN接口，它接受来自操作系统内核的IP包。IP包通过L3和L2传递到KubeBus@Cloud，然后KubeBus@Cloud通过长期运行的TCP连接路由到目标边缘节点。
图2 KubeBus VPN通信
3.1.2 将边缘节点VPN与容器网络连接
KubeBus的第二个功能是使Edge服务运行在与运行在VM网络或容器网络(如flannel)中的云应用程序相同的网络中。
图3 KubeBus Edge/VM/container 网络VPN
在KubeEdge环境中，有3个子网络。同属于一个租户的所有边缘节点属于一个Edge节点子网，这个子网是KubeBus创建的VPN网络，如3.1.1所示;在VM集群中，所有VM都属于VM子网;VM集群中运行的所有容器都属于容器子网。KubeBus将它们作为单个VPN连接。
如图3所示，安装了一个KubeBus虚拟路由器代理在VM集群中的一个VM上。KubeBus虚拟路由器代理包括KubeBus网络协议栈，在边缘节点子网和VM子网下充当路由器。由于VM子网可以访问容器子网，当在每个VM节点和边缘节点中配置正确的路由时，边缘节点子网最终连接到容器子网(注意:对于具有地址过滤策略的集群，需要额外的覆盖)。
3.1.3 多租户管理/数据平面和服务发布
KubeEdge是一个多租户基础设施。不同租户的边缘节点由多租户管理/数据平面管理。一方面，所有租户的管理/数据平面服务与边缘节点之间存在通信;另一方面,不同租户之间的边缘节点应当隔离。和现在的VPN解决方案不同，KubeBus构建一个KubeBus堆栈构建Http层
,使边缘节点之间的通信和多租户管理/数据平面。根据网络服务运行在边缘节点可以从平面管理/数据访问服务,反之亦然。除此之外，在Edge节点上运行的Http
web服务也可以通过多租户管理/数据平面发布到Internet上。它对于某些客户场景非常有用。例如,一个边缘节点与摄像机可以发布Http视频流作为Http
WebService 发送到KubeBus并且暴露到多租户管理/数据平面,然后等互联网浏览器的Http客户端可以得到视频流从Http
WebService边缘节点上运行。
图4 KubeBus Http协议栈
如图4所示，通过KubeBus的不可靠网络层3，构建了连接可靠的KubeBus传输层4。KubeBus
L4提供与TCP相同的API接口。如听/接受/连接/断开连接。在KubeBus L4上，运行着2个“Http反向代理”:KubeBus客户机代理和KubeBus服务器代理。
KubeBus客户端代理监听TCP端口，当接收到Http客户端请求时，通过KubeBus L4可靠连接将请求转发给KubeBus服务器代理;
KubeBus服务器代理在KubeBus L4上侦听，当收到由KubeBus客户端转发的HTTP请求后，它将依次转发请求目标本地Http
WebService。之后，Http响应将通过服务器代理和客户端代理返回到Http客户端。
使用KubeBus客户机和服务器代理，构建了另一个“KubeBus之上的Http层”。运行在云或边缘节点上的Http
web服务可以注册到KubeBus，并且Http客户端可以从云、边缘节点或Internet来访问服务。
来自云或不同边缘节点的不同租户的Http web服务可以注册到KubeBus。一个web服务被标识为<Tenant
ld, Edge节点名，WebServiceName>。租约是租户的全局标识符;边缘节点名是租户范围内唯一的边缘节点名;Web服务名称是节点级别的惟一服务名称，KubeBus使用全局标识符URL模式来标识Htp
Web服务(如图5所示)。
3.2 边缘元数据服务
由于到云的边缘节点是WAN连接的，所以连接可能是不可靠的并且带宽低和价格昂贵。
为了解决广域网的可靠问题，边服务是要求自动运行。边缘的服务即使是边缘节点也需要重新成功运行重启后离线。因此，边缘服务的配置需要在边缘节点中保持持久性，当边缘结点和云中心的连接恢复之后，配置可以从云同步到网络边缘；
为了解决广域网的低带宽问题，数据为同步配置传输的卷应被减到最小。因此,增量同步比完整快照更合适。不仅配置需要从云传送到边缘，边缘服务的状态也需要从边缘传送到云。
边缘元数据服务是为这两个需求而构建的。边缘元数据服务包括在边缘端运行的元数据存储和同步服务(SyncService)，在云端也有相应的元数据存储。将边缘服务的配置写到云端元数据存储中，使配置更改过程作为异步过程进行。即使边缘脱机，写操作仍然成功;当边缘节点和云之间的网络连接恢复后，Sync服务从云元数据存储请求自上次成功同步以来的配置更改，并将其写入本地元数据存储。同步最终应该是一致的。因此元数据存储需要支持原子写和增量检索。
KubeEdge选择Etcd[8]作为元数据存储。这是因为Etcd支持事务性写，并且有多个版本并发控制API接口来检索增量更改，即基于修订的Get/Watch方法。
图6 配置同步算法
从云到边缘的配置同步算法如图6所示。同步过程是一个循环。循环有3个步骤。首先，从边缘节点本地Etcd存储中读取上一次成功同步的最后一个同步修订(LSR);第二，LSR后的更改和新修订来自云Etcd
Store;最后，将修改的内容和新的修改内容写入边缘节点本地Etcd存储区。写中的新修订将在下一次循环迭代中成为LSR。该算法在同步过程崩溃的任何时刻都能实现最终的一致性和原子性。因为只有更改的数据需要同步，同步所消耗的带宽被最小化。边缘到云的服务状态同步算法与之相似。
3.3 Kubernetes 边缘扩展
在每个节点上运行一个代理(Kubelet)。它从KubeMaster获取应用程序配置，管理应用程序生命周期，并向KubeMaster报告应用程序的状态。Kubernetes边缘扩展是为了解决边缘环境中WAN网络连接的特定特性而设计的。它将Kubelet分为两部分:EdgeController在云端运行，AppEngine在边缘节点运行。EdgeController用代表边缘节点向KubeMaster索取应用配置;然后通过EdgeMetadataService将更改后的配置传递给AppEngine;之后，AppEngine将基于存储在EdgeMetadataService中的应用程序配置来处理应用程序生命周期。AppEngine还将通过EdgeMetadataService和EdgeController向KubuMaster报告应用程序状态。由于云和Edge之间的数据交换是建立在EdgeMetadataService上的，所以可以在异步模型中完成，只需要传递更改即可节省带宽。
4 实验
我们在测试环境中评估了KubeEdge的性能，如图7所示。KubeMaster和VM1/VM2在一个子网中运行，Edgel和Edge2在不同的子网中运行。他们都是通过互联网连接到KubeBus@Cloud的。KubueBus@Cloud在AWS的一个中央虚拟机中运行。
图 7 实验性能测试环境
我们用Ping测试了它们之间的网络延迟。测试结果如图8所示。
在这里插入图片描述从结果可以看出，边缘与vm之间的延迟主要来自internet延迟。KubeBus对延迟的影响非常小。
基于此，我们比较了边缘节点和VM之间的部署延迟。我们只测量KubeMaster获取部署请求和Kubelet/AppEngine获取结果之间的延迟。VM的延迟约为2秒，而边缘的Edee延迟为3秒。我们可以看到Edse对部署延迟的影响的延迟是可以接受的。硬件的配置信息如下所示：
图9 硬件配置
KubeEdge作为云的扩展构建了一个基本的边缘基础设施。它假设边缘节点需要通过云进行通信。事实上，边缘节点之间可能是直接连接的，而边缘节点可以作为集群工作，即使与云中心断开连接也是如此。计划使用以下特性来增强启用边缘集群的功能。
1.边缘网络：KubeBus为边缘节点和云中的容器网络创造了一个VPN环境。在当前的模型当中，边缘节点间的连接将通过KubeBus@Cloud进行。两个边缘节点之间可能存在直接连接。例如，边缘节点可能具有公共IP地址，以便另一个边缘节点可以直接创建到它的TCP连接;2个边缘节点也可以建立基于TCP洞穿技术的直接连接;或者两个边缘节点之间可能存在专用连接。通过直接连接，边缘网络拓扑结构将是一个非集中式网格网络。KubeBus需要支持边缘网骆的创建，如TCP穿孔和高效的包路由等。
2.去中心化的边缘元数据服务:边缘网络将是一个去中心化的边缘网格网络。当与云的连接不可用时，边缘节点之间的连接可能仍然有效，边缘节点之间仍应相互协作，高效工作。在边缘网格网络中，为了实现边缘节点之间的元数据交换，需要对边缘节点进行去中心化的EdgeMetadataService。例如，边节点可以通过连接到另一个边节点来连接边网格网络。在decentraledgemetadataservice支持下，云脱机时，到新边缘节点的路由应该传播到其他边缘节点。
3.去中心化边缘集群:基于边缘网格网络，当中心云作为一个集群脱机时，边缘节点需要自主工作。考虑到网络拓扑、资源限制和预先配置的任务优先级，在一个边缘节点上运行的服务可以重新调度到其他节点上，以实现负载均衡、可靠性。为了实现这一目标，需要对边缘集群进行去中心化。
5 conclusion
随着更多的数据从边缘端生成，更多原本在云中执行的计算将被推送到边缘端。边缘环境在网络拓扑、连接和性能方面与云不同。边缘基础设施是推动云计算高效边缘的关键。本文提出了KubeEdge作为一种边缘基础设施。基础设施被认为是云基础设施的扩展。它通过将云中的边缘节点和VM作为单个集群连接起来，构建了与云类似的边缘执行环境。它可以替代现有的基于发布/订阅的边缘基础设施。
|
