CN117729251A - 边缘计算设备、嵌入式设备、控制系统及其构建方法 - Google Patents

Abstract

本发明公开了一种边缘计算设备、嵌入式设备、控制系统及其构建方法，其中，控制系统包括：边缘计算设备，基于Kubernetes平台部署有多个节点和集群控制中心；在集群控制中心中部署有容器管理器；以及嵌入式设备，嵌入式设备基于LiteOS系统部署有对应的容器管理器代理，容器管理器代理用于与容器管理器进行交互通讯，将嵌入式设备构建为集群控制中心中的节点。本发明可以将运行LiteOS系统的嵌入式设备集成到边缘云集群，实现更强大的边缘云计算算力；这大大地降低了LiteOS系统的使用者部署边缘云的成本，以及有关IoT应用的开发成本。

Description

边缘计算设备、嵌入式设备、控制系统及其构建方法

技术领域

本发明涉及边缘计算技术领域，具体为边缘计算设备、嵌入式设备、控制系统及其构建方法。

背景技术

边缘计算(Edge Computing)是工业物联网最重要的相关技术之一，与云端计算相反，其分布式计算泛型更着重于将数据的存储与处理移至和实际应用更加接近的位置，边缘计算能够更有效地将边缘设备的计算和存储资源转化为工业世界中的生产力、产品和服务。

典型边缘计算形式有移动边缘计算(mobile edge computing,MEC)、微云计算(cloudlet)和雾计算(fogcomputing)。移动边缘计算的主导者是电信运营商，移动边缘计算中主要的边缘计算设备是位于通信基站侧的边缘服务器，边缘服务器通过核心网与云端相连，用户通过移动网络接入。其动机在于电信运营商的基站是移动互联网用户接入网络的最近的位置，在更加靠近基站的一侧部署计算设备有利于为用户提供更为便捷的计算服务，并可以拓展其业务维度，获得更多收益。

微云计算的主导者为云计算服务提供商，云计算服务提供商的服务器分布在全球范围内的几个地方，不同地理位置的用户可以就近地利用云服务。当云计算服务商进一步提高服务器的地理覆盖范围，在城市范围内提供更广泛的服务器分布时，这些服务器就形成了一个个小的微云。用户利用近端的微云计算可以获取更好的计算服务，云计算服务商也可以降低通信成本，阿里云、亚马逊云等都提供了类似的服务。

雾计算的主导者是以思科为代表的通信设备制造商，核心思想是利用如交换机、路由器等广泛分布的通信设备的闲置资源为用户提供更好的计算服务。不同于移动边缘计算中计算设备属于通信运营商、微云计算中计算设备属于云计算服务提供商。雾计算的最主要特点是其计算设备的所有者是多个不同的主体，雾计算中使用其他计算资源需要付费，贡献自己的计算资源又可以获得收益，因此，资源的贡献激励研究往往是雾计算所关注的。

然而，工业物联网方面的边缘计算研究相对较少，通常情况下，工业物联网设备配置较低、对软件功能的要求较低。但是基于工业物联网的边缘计算研究，将可以复用生产设备，可以大大提高已有设备的利用率，降低生产成本。

LiteOS系统是华为公司研发的一款国产自主研发的操作系统，更加适合当前世界格局下国家对边缘计算领域安全的需要。但是当前LiteOS的软件生态还非常薄弱，基于LiteOS系统的物联网嵌入式设备与边缘计算的结合仍是空白，针对这个问题研究基于LiteOS的虚拟集群控制系统，进一步的构建基于LiteOS的边缘云计算，对完善的国产自主操作系统生态意义重大。

发明内容

本发明的目的在于提供边缘计算设备、嵌入式设备、控制系统及其构建方法，以解决上述背景技术中提出的问题。

为实现上述目的，本发明提供如下技术方案：

一种边缘计算设备，基于Kubernetes平台部署有多个节点和集群控制中心；

在集群控制中心中，根据用户提供的第一配置文件，以virtual-kubele t库为基础构建有至少一个面向LiteOS开发的容器管理器，容器管理器用于实例化virtual-kubelet库提供的Provider功能接口，建立与嵌入式设备中基于LiteOS系统部署的容器管理器代理之间的交互通讯，将嵌入式设备构建为集群控制中心中的节点。

作为本发明进一步的方案，所述边缘计算设备部署有Linux系统。

作为本发明进一步的方案，所述的容器管理器代理通过启用远程过程调用传送协议作为服务端，所述容器管理器通过Golang标准库中的远程过程调用传送协议库作为客户端。

作为本发明进一步的方案，所述的容器管理器包括Provider对象、运行时服务客户端、镜像服务客户端、资源管理器以及CRIPod对象。

作为本发明进一步的方案，所述的集群控制中心采用RBAC权限模型作为鉴权方式，赋予容器管理器对Pod的创建、获取、查看、列表、删除权限以及对节点的创建、获取、查看、列表权限。

一种嵌入式设备，根据用户提供的第二配置文件，构建有基于LiteOS系统的容器管理器代理，容器管理器代理通过启用远程过程调用传送协议作为服务端，其用于与前述边缘计算设备中的容器管理器进行交互通讯，嵌入式设备根据容器管理器代理接收的请求，将自身构建为边缘计算设备中集群控制中心内部的虚拟节点。

一种控制系统，具体为基于LiteOS的虚拟集群控制系统，包括：

边缘计算设备，所述的边缘计算设备基于Kubernetes平台在边缘计算设备中部署多个节点和集群控制中心；

在集群控制中心中，根据用户提供的第一配置文件，以virtual-kubele t库为基础构建有至少一个容器管理器，容器管理器用于实例化virtual-kub elet库提供的Provider功能接口，建立与嵌入式设备中基于LiteOS系统部署的容器管理器代理之间的交互通讯；以及

嵌入式设备，所述的嵌入式设备根据用户提供的第二配置文件构建有基于LiteOS系统的容器管理器代理，容器管理器代理通过启用远程过程调用传送协议作为服务端，用于与容器管理器进行交互通讯，嵌入式设备根据容器管理器代理接收的请求，将自身构建为边缘计算设备中集群控制中心内部的虚拟节点。

一种控制系统构建方法，具体为基于LiteOS的虚拟集群控制系统构建方法，包括如下步骤：

基于Kubernetes平台在边缘计算设备中部署多个节点和集群控制中心，根据用户提供的第一配置文件，集群控制中心以virtual-kubelet库为基础构建至少一个面向LiteOS开发的容器管理器；

根据用户提供的第二配置文件在嵌入式设备中构建基于LiteOS系统的容器管理器代理；

容器管理器代理通过启用远程过程调用传送协议作为服务端，容器管理器通过Golang标准库中的远程过程调用传送协议库作为客户端，客户端与服务端之间建立交互通讯；

根据容器管理器代理接收的请求，嵌入式设备将自身构建为集群控制中心中的节点。

与现有技术相比，本发明的有益效果是：

1、本发明通过在边缘计算设备中部署构建多个节点和集群控制中心，在集群控制中心中构建有面向LiteOS开发的容器管理器，在基于LiteOS系统的嵌入式设备中部署构建对应的容器管理器代理，通过容器管理器代理与容器管理器之间的交互通讯，完成基于LiteOS构建的边缘云计算，将运行LiteOS系统的嵌入式设备集成到边缘云集群，可实现更强大的边缘云计算算力，拓展了边缘计算的边界；

2、通过这套集群控制系统，用户可以在集群中创建容器Pod，通过Kubernetes(边缘云)现有组件，提高程序的可用性；

3、通过与Kubernetes以及容器化技术的结合，边缘计算被拓展到运行LiteOS系统的嵌入式设备上，这大大地降低了LiteOS这一国产操作系统的使用者部署边缘云的成本，以及有关IoT应用的开发成本，提升了国家在IoT与边缘计算领域的竞争力。

附图说明

图1为本发明控制系统的架构示意图；

图2为本发明中容器管理器的类结构示意图；

图3为本发明中CRIPod对象的数据成员示意图；

图4为本发明中容器管理器与容器管理器代理配合更新Pod状态的流程示意图；

图5为本发明中创建Pod的流程示意图；

图6为本发明中删除Pod的流程示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

以下对本申请实施例中的部分用语进行解释说明，以便于本领域技术人员理解：

1、kubernetes：简称K8s，是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单并且高效，Kubernetes提供了应用部署，规划，更新，维护的一种机制。

2、Virtual Kubelet是Kubernetes kubelet的一个实现，它伪装成一个kubelet，用于将Kubernetes集群连接到其他API，允许Kubernetes节点由其他服务支持，例如无服务器容器平台。Kubernetes kubelet为每个Kubern etes节点(Node)实现Pod和容器操作。它们作为每个节点上的代理运行，无论该节点是物理服务器还是虚拟机，并在该节点上处理Pod/容器操作。ku belets将名为PodSpec的配置作为输入，并确保PodSpec中指定的容器正在运行且运行正常。从Kubernetes API服务器的角度来看，Virtual Kubelet看起来像普通的kubelet，但其关键区别在于它们在其他地方调度容器，例如：在云无服务器API中，而不是在节点上。

3、Pod是Kubernetes中最小的可部署单元，它可以包含一个或多个容器。在Kubernetes中，Pod是由Kubernetes API Server创建和管理的。Pod的创建过程可以分为以下几个步骤：验证请求参数、创建Pod Spec、创建Pod、分配IP地址、调度Pod、创建容器和管理容器。Pod的创建流程为：用户通过Kubernetes API Server创建一个Pod，KubernetesAPI Ser ver创建Pod Spec，并将其存储在etcd中，Kubernetes Controller Mana ger根据Pod Spec创建Pod，Kubernetes API Server为Pod分配IP地址，并将其存储在etcd中，Kubernetes核心组件Scheduler根据Pod的资源需求和节点资源状况，将Pod调度到一个合适的节点上，并将调度信息存储在etcd中，Kubernetes核心组件Kubelet在节点上创建容器，并将容器状态更新到Kubernetes API Server中，Kubernetes Kubelet定期检查容器状态，并根据需要重启容器。

4、集群是一种计算机系统，它通过一组松散集成的计算机软件和/或硬件连接起来高度紧密地协作完成计算工作。集群计算机系统中的单个计算机通常称为节点，各个节点之间通常通过局域网连接，但也有其它的可能连接方式。集群计算机系统通常用来改进单个计算机的计算速度和/或可靠性。

5、API：应用程序编程接口(英语：Application Programming Interfa ce，简称：API)，是一些预先定义的函数，目的是提供应用程序与开发人员基于某软件或硬件得以访问一组例程的能力，而又无需访问源码，或理解内部工作机制的细节。

6、CRI是一个插件接口，它使kubelet能够使用各种容器运行时，无需重新编译集群组件。CRI的核心机制是每个容器项目都可以自己实现一个CRI shim，自己处理CRI请求。这样一来，k8s就有了统一的容器抽象层，让更底层的容器运行时可以自由对接到k8s系统中。

CRI接口的定义可以分为两组：

RuntimeService：提供容器相关的操作。比如创建和启动容器，删除容器，执行exec命令等等；

ImageManagerService：提供容器镜像相关操作，如拉取镜像、删除镜像等。

7、JSONRPC，是一个无状态且轻量级的远程过程调用(RPC)传送协议，其传递内容透过JSON为主。相较于一般的REST透过网址(如GET/user)调用远程服务器，JSONRPC直接在内容中定义了欲调用的函数名称(如{"method":"getUser"})，这也令开发者不会陷于该使用PUT或者PATCH的问题之中。

实施例1：一种控制系统，如图1所示，具体为基于LiteOS的虚拟集群控制系统，包括：部署有Linux系统的边缘计算设备，所述的边缘计算设备基于Kubernetes平台在边缘计算设备中部署多个节点(node)和集群控制中心(master)；显然，集群控制中心(master)可具体包括现有技术中的控制器管理器(Controller Manager)、API服务器(API Server)、调度器(Scheduler)等，API服务器是Kubernetes集群控制平面的前端，处理来自用户和其它组件(如：kubelet组件、hrglet组件)的API请求，验证请求并将配置数据持久化；

在集群控制中心(master)中，根据用户提供的第一配置文件，以virtual-kubelet库为基础构建有至少一个容器管理器(hrglet)，容器管理器(hrglet)用于实例化virtual-kubelet库提供的Provider功能接口，建立与嵌入式设备中基于LiteOS系统部署的容器管理器代理(hrglet-agent)之间的交互通讯；

嵌入式设备，所述的嵌入式设备根据用户提供的第二配置文件构建有基于LiteOS系统的容器管理器代理(hrglet-agent)，容器管理器代理(hrgl et-agent)通过启用远程过程调用传送协议作为服务端，用于与容器管理器(hrglet)进行交互通讯，嵌入式设备根据容器管理器代理(hrglet-agent)接收的请求，将自身构建为边缘计算设备中集群控制中心(master)内部的虚拟节点(node)。

本发明实施例以virtual-kubelet库为基础构建容器管理器(hrglet)，将其作为集群控制中心(master)的代理，结合CRI和JSONRPC，构建与容器管理器(hrglet)通讯的容器管理器代理(hrglet-agent)，完成基于Lite OS构建的边缘云计算，将运行LiteOS系统的嵌入式设备集成到边缘云集群中，实现更强大的边缘云计算算力。

基于持久化数据维护边缘计算资源，由加入集群的且有相应权限的组件管理这些资源。本实施例由容器管理器(hrglet)维护节点资源，通过对容器的操作维护Pod资源。

CRI(Container Runtime Interface)是一种被广泛认可和使用的API，也作为管理容器的事实标准。因此，在LiteOS系统资源虚拟化方面，即容器化方面，应当同样使用CRI作为控制容器的方式，将LiteOS系统的嵌入式设备构建为节点。但是，集群控制中心(master)无法直接控制基于LiteOS系统的嵌入式设备创建Pod，本发明设计了容器管理器(hrglet)和容器管理器代理(hrglet-agent)，通过容器管理器(hrglet)和容器管理器代理(hrg let-agent)之间的交互通讯，使得集群控制中心(master)不仅能够控制LiteOS系统创建Pod，将LiteOS系统的嵌入式设备构建为节点，还能让其执行边缘计算。

具体地，容器管理器代理(hrglet-agent)与容器管理器(hrglet)通过服务器/客户端模式建立连接，容器管理器代理(hrglet-agent)具体可通过启用一个JSONRPC2.0执行服务端功能，而容器管理器(hrglet)通过Golang的标准库中的jsonrpc库作为客户端。

作为具体的方案，如图2所示，容器管理器包括Provider对象、运行时服务客户端(RuntimeServiceClient)、镜像服务客户端(ImageServiceClient)、资源管理器(ResourceManager)以及CRIPod对象。

其中，Provider对象这个结构体是程序的核心数据结构，它用于实现virtual-kubelet要求的接口。当一个新的Pod生成后，对应的Provider功能接口会被注册到Provider对象，鉴权成功后，调用Run函数，启动RuntimeServiceClient，即启动了对应的Pod。

其中，运行时服务客户端(RuntimeServiceClient)和镜像服务客户端(ImageServiceClient)是对CRI的封装，它们在Provider对象创建时根据用户提供的第一配置文件创建，所有的对容器有关的操作都经过这两个对象将操作发送到基于LiteOS系统的嵌入式设备上。

资源管理器(ResourceManager)是virtual-kubelet提供的用于辅助对Pod授权的组件。

CRIPod对象是本系统维护PodSandbox与Kubernetes中的Pod之间关联的数据结构，CRIPod对象用于维护一个从Pod的UID到一组容器和PodSandbox的状态的映射，CRIPod对象的数据成员如图3所示。Pod由一组应用容器组成，其中包含共有的环境和资源约束，在CRI里，这个环境被称为PodSandbox。

在每次与容器管理系统同步状态时，容器管理器(hrglet)都会先调用ListPodSandbox，从容器管理器代理(hrglet-agent)处获取所有的PodSandbox，然后，容器管理器(hrglet)依次调用PodSandboxStatus和ListContainers，从容器管理器代理(hrglet-agent)处获取每一个PodSandbox的状态，生成一个由CRIPod对象构成的列表，从而更新Pod状态，如图4所示。

由于容器管理器(hrglet)逻辑上并没有直接运行在控制平面的主机上。为了集群控制中心(master)能够管理作为节点的嵌入式设备及其内部的容器，本发明实施例采用RBAC(Role based Access Control)权限模型作为鉴权方式，赋予容器管理器(hrglet)对Pod的create、get、watch、list、delete权限以及对node的create、get、watch、list权限。

另外，为了满足virtual-kubelet的要求，进行Pod的创建，容器管理器(hrglet)还被赋予对secrets、services、configmaps的get、watch、list权限，这是因为Kubernetes需要对Pod授权。

作为进一步具体的方案，容器管理器(hrglet)的Provider功能接口可具体如下：

CreatePod：在接口被调用后，首先，更新所有的Pod的状态，然后，检查Pod是否已经存在，如果Pod已经存在，那么更新Pod的ID字段，并退出；否则调用CreatePodSandbox函数，容器管理器(hrglet)发起创建Pod的请求，容器管理器代理(hrglet-agent)接收到请求后，从第二配置文件(即本地配置文件)中获取Pod的配置，并向LiteOS系统发起资源请求，LiteOS系统根据Pod的配置创建一个PodSandbox，随后，对于Pod中的每一个容器，依次执行PullImage拉取镜像，然后，依次执行CreateContainer和StartContainer，在嵌入式设备上创建容器。如图5所示，其中在创建PodSandbox时，PodSandbox的UID被指定为Pod的UID，以用于匹配(Pod包含共有的环境和资源约束，在CRI里，这个环境被称为PodSandbox)。

DeletePod：在接口被调用后，首先，更新所有Pod的状态，然后，如果存在拥有对应ID的PodSandbox，那么，依次执行StopPodSandbox和RemovePodSandbox，容器管理器(hrglet)发起删除Pod的请求，LiteOS系统根据容器管理器代理(hrglet-agent)接收的请求，删除这个PodSandbox，如图6所示。

GetPod：在接口被调用后，首先，更新所有Pod的状态，然后，根据指定的name和namespace，查找返回对应的Pod。

GetPodStatus：和GetPod的实现相同，但是，返回的是Pod的Status字段。

GetPods：和GetPod的实现相同.，但是，返回所有的Pod。

ConfigureNode：通过JSONRPC调用容器管理器代理(hrglet-agent)的heart、numCPU、getSystemTotalMemory函数，然后，以numCPU、getSystem TotalMemory的返回值以及固定的配置信息更新节点状态。

NotifyPods：更新对象中的notifyPod成员。然后，启动一个goroutin e，每隔5s更新一次所有的Pod，然后，将这些Pod作为参数逐一传递给not ifyPod成员。

NotifyPods函数提供一个回调函数，实现者可以通过调用该回调函数更新Kubernetes集群中Pod的状态。

具体地，Hrglet-agent作为对CRI接口功能的补充，为hrglet代理，Hrglet-agent运行一个JSONRPC Server，根据客户端的调用，执行相应的操作，返回对应的数据。在hrglet-agent中，可具体实现如下功能：1)获取节点内存，2)获取节点CPU核心数，3)存活检测。

对于获取节点内存功能，通过LIBC提供的sysinfo获取系统数据，然后返回info.totalram*info.mem_unit(设定info为函数sysinfo的出参)。

对于获取节点CPU核心数功能，通过sysconf调用POSIX标准的syscon f获取CPU的核心数，调用方式是sysconf(_SC_NPROCESSORS_CONF)。

存活检测部分，仅回复一个空的响应体，以确定可用性。

对于LiteOS与Linux两系统的兼容，由于二者都支持libc和posix的API，因此，在本实施例中可以通用。

在更新Node状态时，基于JSONRPC_2.0协议，远程获取节点的状态。

作为服务端，在启动时，容器管理器代理(hrglet-agent)可将JSONRP C服务器监听的IP地址和端口号作为参数传递给应用。

在本实施例中，作为JSONRPC Server，Hrglet-agent通过启用一个JSO NRPC2.0服务端，hrglet通过Golang的标准库中的jsonrpc库作为客户端。

自实现的JSONRPC服务端复用httplib内部对TCP连接的封装，对C++的iostream的steambuf进行了自定义，以适配nlohmann的json库，实现了在一条TCP连接上传输JSON对象。

在JSONRPC服务器中，可具体实现4个函数execNotification_1_0、ex ecMethod_1_0、execNotification_2_0、execMethod_2_0，分别对应JSONRP C1.0和JSONRPC2.0中的函数调用和通知，服务器通过对JSON对象的解析，将调用加入到一个队列中，然后合适的线程会从队列中取出这个调用，如果这是函数调用，那么会在执行后将结果发送回调用方。

在更新节点状态时，基于JSON-RPC2.0协议，通过JSONRPC服务器，集群控制中心可远程获取节点的状态。JSONRPC服务器作为服务端，在启动时将JSON-RPC服务器监听的IP地址和端口号作为参数传递给客户端应用。

本发明的基于LiteOS的虚拟集群控制系统可以将运行LiteOS系统的嵌入式设备作为边缘计算的边缘节点，以构建边缘计算的边缘云层，拓展了边缘计算的边界。

通过这套集群控制系统，用户可以在集群中创建容器Pod，通过Kuberne tes(边缘云)现有组件，提高程序的可用性，用户可以编写一定的配置文件将一定数量的正常运行的Pod自动放置在可用的节点上。

基于Kubernetes，为每个LiteOS系统的嵌入式设备在Kubernetes中作为一个物理节点存在。通过与Kubernetes以及容器化技术的结合，边缘计算被拓展到运行LiteOS系统的嵌入式设备上，这大大地降低了LiteOS这一国产操作系统的使用者部署边缘云的成本，以及有关IoT应用的开发成本，提升了国家在IoT与边缘计算领域的竞争力。

本发明实施例构建的控制系统具体实施时，在控制平面，使用Linux的系统API。在数据平面，对于Linux主机，使用Linux系统API；对于LiteO S的嵌入式设备，使用POSIX接口和LIBC。

在Kubernetes的组件中，内部接口可具体使用kube-apiserver的REST ful接口进行交互；

在hrglet与容器管理引擎(Linux系统)之间，使用CRI作为其交互的接口。CRI的详细程序，见最后的CRI API参考(中文)和Kubelet Provide r API参考。

本发明的控制系统可在如下环境中工作。

Linux主机，版本Ubuntu 22.04，CPU不低于i3-6100，内存不少于8GB空闲空间。

LiteOS主机，版本LiteOS 5.0.0，STM32F429IG开发板，CPU核心数不少于2，内存不少于128MB。

本发明的控制系统经过验证，可以将一台运行LiteOS系统的嵌入式设备作为Kubernetes的节点使用。在部署容器的层面上减少了LiteOS系统与Li nux系统之间的差异。

实施例2：在前述技术方案基础上，还提出一种控制系统构建方法，具体为基于LiteOS的虚拟集群控制系统构建方法，包括如下步骤：

基于Kubernetes平台在边缘计算设备中部署多个节点和集群控制中心，根据用户提供的第一配置文件，集群控制中心以virtual-kubelet库为基础构建至少一个面向LiteOS开发的容器管理器；

根据用户提供的第二配置文件在嵌入式设备中构建基于LiteOS系统的容器管理器代理；

容器管理器代理通过启用远程过程调用传送协议作为服务端，所述容器管理器通过Golang标准库中的远程过程调用传送协议库作为客户端，客户端与服务端之间建立交互通讯；

根据容器管理器代理接收的请求，嵌入式设备将自身构建为集群控制中心中的节点。

实施例3：一种边缘计算设备，基于Kubernetes平台部署有多个节点和集群控制中心；

在集群控制中心中，根据用户提供的第一配置文件，以virtual-kubelet库为基础构建有至少一个面向LiteOS开发的容器管理器，容器管理器用于实例化virtual-kubelet库提供的Provider功能接口，建立与嵌入式设备中基于LiteOS系统部署的容器管理器代理之间的交互通讯，将嵌入式设备构建为集群控制中心中的节点。

实施例4：一种嵌入式设备，其特征在于，根据用户提供的第二配置文件，构建有基于LiteOS系统的容器管理器代理，容器管理器代理通过启用远程过程调用传送协议作为服务端，其用于与前述边缘计算设备中的容器管理器进行交互通讯，嵌入式设备根据容器管理器代理接收的请求，将自身构建为边缘计算设备中集群控制中心内部的虚拟节点。

CRI API参考(中文)

//运行时服务为远程容器运行时定义公开的API

service RuntimeService{

//Version返回运行时的名称、运行时的版本和运行时API的版本

rpc Version(VersionRequest)returns(VersionResponse){}

//创建并启动一个Pod级别的PodSandbox，运行时服务必须保证如果PodSandbox创建成功，那么它处于ready状态。

rpc RunPodSandbox(RunPodSandboxRequest)returns(RunPodSandboxResponse){}

//StopPodSandbox停止一切属于这个PodSandbox一部分的运行中的进程并归还被这个PodSandbox申请的网络资源(例如，IP地址)。

//如果这个PodSandbox中有任何运行中的容器，那么它们必须被强制终止。

//如果所有相关资源被回收，那么这次调用是无效的。Kubelet将会在调用RemovePodSandbox之前，调用StopPodSandbox至少一次。一旦不需要PodSandbox，它会急切地尝试回收资源，因此预期会多次调用StopPodSandbox。

rpc StopPodSandbox(StopPodSandboxRequest)returns(StopPodSandboxResponse){}

//RemovePodSandbox移除这个PodSandbox。如果在这个PodSandbox中有任何运行中的容器，他们一定会被强制终止并移除。

//如果这个PodSandbox已经被移除，那么这次调用是无效的且一定不会返回错误。

rpc RemovePodSandbox(RemovePodSandboxRequest)returns(RemovePodSandboxResponse){}

//PodSandboxStatus返回这个PodSandbox的状态。如果这个PodSandbox不存在，那么会返回一个错误。

rpc PodSandboxStatus(PodSandboxStatusRequest)returns(PodSandboxStatusResponse){}

//ListPodSandbox返回一个PodSandboxes的列表。

rpc ListPodSandbox(ListPodSandboxRequest)returns(ListPodSandboxResponse){}

//CreateContainer在指定的PodSandbox中创建一个新的容器。

rpc CreateContainer(CreateContainerRequest)returns(CreateContainerResponse){}

//StartContainer启动这个容器。

rpc StartContainer(StartContainerRequest)returns(StartContainerResponse){}

//StopContainer以一个宽限期(例如，超时)停止一个运行中的容器。

//如果这个容器已经被停止了，那么这次调用是无效的，且不会返回错误。

//在超过宽限期后，运行时一定会强制杀死这个容器。

rpc StopContainer(StopContainerRequest)returns(StopContainerResponse){}

//RemoveContainer移除这个容器，如果这个容器正在运行，那么这个容器会被强制移除。如果这个容器已经被移除了，那么这次调用是无效的，且不会返回错误。

rpc RemoveContainer(RemoveContainerRequest)returns(RemoveContainerResponse){}

//ListContainers列出过滤后的所有容器。

rpc ListContainers(ListContainersRequest)returns(ListContainersResponse){}

//ContainerStatus返回这个容器的状态，如果这个容器不存在，则会返回一个错误。

rpc ContainerStatus(ContainerStatusRequest)returns(ContainerStatusResponse){}

//UpdateContainerResources同步地更新这个容器的ContainerConfig(容器配置)。

//如果运行时未能成功完成更新所请求的资源的事物，则会返回一个错误。

rpcUpdateContainerResources(UpdateContainerResourcesRequest)returns(UpdateContainerResourcesResponse){}

//ReopenContainerLog请求运行时重新打开这个容器的stdout/stderr日志文件。这通常是在日志文件被轮换之后调用的。如果容器没有运行，容器运行时可以选择创建一个新的日志文件并返回nil，或者返回一个错误。一旦它返回错误，新的容器日志文件一定不会被创建。

rpc ReopenContainerLog(ReopenContainerLogRequest)returns(ReopenContainerLogResponse){}

//ExecSync同步地在容器中运行一个命令。

rpc ExecSync(ExecSyncRequest)returns(ExecSyncResponse){}

//Exec准备一个流的端点以期在容器中执行一个命令。

rpc Exec(ExecRequest)returns(ExecResponse){}

//Attach准备一个流的端点并附加到一个运行中的容器上。

rpc Attach(AttachRequest)returns(AttachResponse){}

//PortForward准备一个流的端点来转发PodSandbox的端口。

rpc PortForward(PortForwardRequest)returns(PortForwardResponse){}

//ContainerStats返回这个容器的统计数据，如果这个容器不存在，那么这个调用会返回一个错误。

rpc ContainerStats(ContainerStatsRequest)returns(ContainerStatsResponse){}

//ListContainerStats返回所有运行中的容器的统计数据。

rpc ListContainerStats(ListContainerStatsRequest)returns(ListContainerStatsResponse){}

//PodSandboxStats返回这个PodSandbox的统计数据。如果这个PodSandbox不存在，那么这个调用会返回一个错误。

rpc PodSandboxStats(PodSandboxStatsRequest)returns(PodSandboxStatsResponse){}

//ListPodSandboxStats返回与一个过滤器相匹配的PodSandbox的统计数据。

rpc ListPodSandboxStats(ListPodSandboxStatsRequest)returns(ListPodSandboxStatsResponse){}

//UpdateRuntimeConfig基于给定的请求更新运行时的配置。

rpc UpdateRuntimeConfig(UpdateRuntimeConfigRequest)returns(UpdateRuntimeConfigResponse){}

//Status返回运行时的状态。

rpc Status(StatusRequest)returns(StatusResponse){}

//CheckpointContainer核对一个容器

rpc CheckpointContainer(CheckpointContainerRequest)returns(CheckpointContainerResponse){}

//GetContainerEvents从CRI运行时获取容器事件。

rpc GetContainerEvents(GetEventsRequest)returns(streamContainerEventResponse){}

//ListMetricDescriptors获取将在ListPodSandboxMetrics中返回的度量指标的描述符。

//在启动时这个列表应是静态的：在添加或删除度量指标描述符时，要么客户端和服务器一起重启，要么它们不应该改变。换句话说，如果ListPodSandboxMetrics引用了一个在初始ListMetricDescriptors调用中没有描述的名称，那么该度量指标将不会被广播。

rpc ListMetricDescriptors(ListMetricDescriptorsRequest)returns(ListMetricDescriptorsResponse){}

//ListPodSandboxMetrics从CRI运行时中获取PodSandbox的度量指标。

rpc ListPodSandboxMetrics(ListPodSandboxMetricsRequest)returns(ListPodSandboxMetricsResponse){}

}

//ImageService定义用于管理镜像的公开API。

service ImageService{

//ListImages列出存在的镜像。

rpc ListImages(ListImagesRequest)returns(ListImagesResponse){}

//ImageStatus返回这个镜像的状态。如果这个镜像不存在，返回一个image设为nil的ImageStatusResponse响应。

rpc ImageStatus(ImageStatusRequest)returns(ImageStatusResponse){}

//PullImage拉取一个带有身份认证的镜像。

rpc PullImage(PullImageRequest)returns(PullImageResponse){}

//RemoveImage移除这个镜像。如果这个镜像已经被移除了，那么这次调用是无效的，且一定不会返回错误。

rpc RemoveImage(RemoveImageRequest)returns(RemoveImageResponse){}

//ImageFSInfo返回被用于存储镜像的文件系统的信息。

rpc ImageFsInfo(ImageFsInfoRequest)returns(ImageFsInfoResponse){}

Kubelet Provider API参考

//Provider contains the methods required to implement a virtual-kubelet provider.

//Errors produced by these methods should implement an interface from

//github.com/virtual-kubelet/virtual-kubelet/errdefs package in orderfor the

//core logic to be able to understand the type of failure.

type Provider interface{

node.PodLifecycleHandler

//GetContainerLogs retrieves the logs of a container by name from theprovider.

GetContainerLogs(ctx context.Context,namespace,PodName,containerNamestring,opts api.ContainerLogOpts)(io.ReadCloser,error)

//RunInContainer executes a command in a container in the Pod,copyingdata

//between in/out/err and the container's stdin/stdout/stderr.

RunInContainer(ctx context.Context,namespace,PodName,containerNamestring,cmd[]string,attach api.AttachIO)error

//ConfigureNode enables a provider to configure the node object that

//will be used for Kubernetes.

ConfigureNode(context.Context,*v1.Node)

}

type PodLifecycleHandler interface{

//CreatePod takes a Kubernetes Pod and deploys it within theprovider.

CreatePod(ctx context.Context,Pod*corev1.Pod)error

//UpdatePod takes a Kubernetes Pod and updates it within theprovider.

UpdatePod(ctx context.Context,Pod*corev1.Pod)error

//DeletePod takes a Kubernetes Pod and deletes it fromtheprovider.Once a Pod is deleted,the provider is

//expected to call the NotifyPods callback with a terminal Podstatuswhere all the containers are in a terminal

//state,as well as the Pod.DeletePod may be called multipletimes forthe same Pod.

DeletePod(ctx context.Context,Pod*corev1.Pod)error

//GetPod retrieves a Pod by name from the provider(can becached).

//The Pod returned is expected to be immutable,and may beaccessed

//concurrently outside of the calling goroutine.Therefore itisrecommended

//to return a version after DeepCopy.

GetPod(ctx context.Context,namespace,name string)(*corev1.Pod,error)

//GetPodStatus retrieves the status of a Pod by name fromtheprovider.

//The PodStatus returned is expected to be immutable,and maybeaccessed

//concurrently outside of the calling goroutine.Therefore itisrecommended

//to return a version after DeepCopy.

GetPodStatus(ctx context.Context,namespace,name string)(*corev1.PodStatus,error)

//GetPods retrieves a list of all Pods running on the provider(can becached).

//The Pods returned are expected to be immutable,and may beaccessed

//concurrently outside of the calling goroutine.Therefore itisrecommended

//to return a version after DeepCopy.

GetPods(context.Context)([]*corev1.Pod,error)

}。

Claims (8)

1.一种边缘计算设备，其特征在于，基于Kubernetes平台部署有多个节点和集群控制中心；

在集群控制中心中，根据用户提供的第一配置文件，以virtual-kubele t库为基础构建有至少一个面向LiteOS开发的容器管理器，容器管理器用于实例化virtual-kubelet库提供的Provider功能接口，建立与嵌入式设备中基于LiteOS系统部署的容器管理器代理之间的交互通讯，将嵌入式设备构建为集群控制中心中的节点。

2.根据权利要求1所述的边缘计算设备，其特征在于，所述边缘计算设备部署有Linux系统。

3.根据权利要求2所述的边缘计算设备，其特征在于，所述的容器管理器代理通过启用远程过程调用传送协议作为服务端，所述容器管理器通过Golang标准库中的远程过程调用传送协议库作为客户端。

4.根据权利要求3所述的边缘计算设备，其特征在于，所述的容器管理器包括Provider对象、运行时服务客户端、镜像服务客户端、资源管理器以及CRIPod对象。

5.根据权利要求4所述的边缘计算设备，其特征在于，所述的集群控制中心采用RBAC权限模型作为鉴权方式，赋予容器管理器对Pod的创建、获取、查看、列表、删除权限以及对节点的创建、获取、查看、列表权限。

6.一种嵌入式设备，其特征在于，根据用户提供的第二配置文件，构建有基于LiteOS系统的容器管理器代理，容器管理器代理通过启用远程过程调用传送协议作为服务端，其用于与权利要求1-5任一所述边缘计算设备中的容器管理器进行交互通讯，嵌入式设备根据容器管理器代理接收的请求，将自身构建为边缘计算设备中集群控制中心内部的虚拟节点。

7.一种控制系统，具体为基于LiteOS的虚拟集群控制系统，其特征在于，包括：

边缘计算设备，所述的边缘计算设备基于Kubernetes平台在边缘计算设备中部署多个节点和集群控制中心；

在集群控制中心中，根据用户提供的第一配置文件，以virtual-kubele t库为基础构建有至少一个容器管理器，容器管理器用于实例化virtual-kub elet库提供的Provider功能接口，建立与嵌入式设备中基于LiteOS系统部署的容器管理器代理之间的交互通讯；以及

嵌入式设备，所述的嵌入式设备根据用户提供的第二配置文件构建有基于LiteOS系统的容器管理器代理，容器管理器代理通过启用远程过程调用传送协议作为服务端，用于与容器管理器进行交互通讯，嵌入式设备根据容器管理器代理接收的请求，将自身构建为边缘计算设备中集群控制中心内部的虚拟节点。

8.一种控制系统构建方法，具体为基于LiteOS的虚拟集群控制系统构建方法，其特征在于，包括如下步骤：

基于Kubernetes平台在边缘计算设备中部署多个节点和集群控制中心，根据用户提供的第一配置文件，集群控制中心以virtual-kubelet库为基础构建至少一个面向LiteOS开发的容器管理器；

根据用户提供的第二配置文件在嵌入式设备中构建基于LiteOS系统的容器管理器代理；

容器管理器代理通过启用远程过程调用传送协议作为服务端，所述容器管理器通过Golang标准库中的远程过程调用传送协议库作为客户端，客户端与服务端之间建立交互通讯；

根据容器管理器代理接收的请求，嵌入式设备将自身构建为集群控制中心中的节点。