具体实施方式
下面结合附图和具体实施例对本发明作进一步说明,以使本领域的技术人员可以更好地理解本发明并能予以实施。
本申请在具体实施方式中参照附图来详细描述本申请的各种示例性实施例。应注意到:除非另外具体说明,否则在这些实施例中阐述的部件和步骤的相对布置、数字表达式和数值不限制本申请的保护范围。
以下对至少一个示例性实施例的描述实际上仅仅是说明性的,决不作为对本申请及其应用或使用的任何限制。对于相关领域普通技术人员已知的技术、方法和设备可能不作详细讨论,但在适当情况下,所述技术、方法和设备应当被视为说明书的一部分。
本申请中示出和讨论的所有例子中,任何具体值应被解释为仅仅是示例性的,而不是作为限制。因此,示例性实施例的其它例子可以具有不同的值。应注意到:相似的标号和字母在下面的附图中表示类似项,因此,一旦某一项在一个附图中被定义,则在随后的附图中不需要对其进行进一步讨论。
本申请提供的一种云边协同方法,包括:
建立云端和边缘节点之间的消息传输机制;
基于在所述云端设置的K8S,和在所述边缘节点上设置的kebulet,修正所述kebulet实现通过所述消息传输机制连接所述边缘节点到所述K8S;
根据所述消息传输机制,将通过EdgeDeviceManager收集的下发数据在所述云和边缘节点之间同步。
本申请通过设置的同步机制,可以实现统一管理调度所有边缘设备,实现数据同步,包括边缘节点、终端路由、边缘应用、消息路由等管理;同时支持类型异构资源,LinuxOS基于裸机/虚拟机ARM/X86/RISCVGPU/DPU/FPGA/SmartNIC;并且实现支持边缘离线模式,缘端在断网环境下实现自治,拥有与管控端连接、同步、检验等能力。
本申请实现方法安全可靠,当组件故障时,可以快速更新、隔离,并且具体弹性扩容的能力。
图1是本申请中云边协同流程示意图。
请参照图1所示,S101建立云端和边缘节点之间的消息传输机制。
所述云端是指云服务、云计算等,是一种集合分布式、并行计算、网络存储、虚拟化以及内容分发等特点的网络技术。所述云服务可以通过需求进行资源分配,易扩展是其核心属性之一,因此通过云服务可以提高计算能力的同时,还可节省计算资源。
图2是本申请中云边协同架构示意图。
请参照图2所示,所述云端与客户端相连,通过中间的路由设备,将数据准确的在所述云端与客户端之间进行传输,这其中,基于所述客户端的需求,所述云端将建立虚拟机,并基于所述客户端需求对数据进行处理,存储等。所述虚拟机的建立是唯一指向特定的客户端的,当有不同客户端时,则在所述云端将建立不同的虚拟机,实现数据的处理与存储。
本申请中,所述客户端是指服务的客户端,例如移动设备中安装的软件,而不是指一个移动设备或者桌面电脑。因此所述一个终端设备可以运行多个所述客户端,进而在所述云端建立多个所述虚拟机。所述云端可以是一个或者多个,基于用户的选择和设置,或者基于客户端的默认实现连接。
所述云端通过路由设备准确的与所述客户端进行数据交互,这其中,所述用户端附近将设置有边缘节点,该边缘节点用于实现部分所述云端的功能,以提高所述对所述客户端的响应能力。
在本申请中,所述边缘节点部署在距离所述客户端最近的位置,既所述客户端在与所述云端建立联系时,与距离最近的该云端所属边缘节点进行连接。所述边缘节点与所述云端连接,基于客户端请求,所述边缘节点从所述云端请求数据。
所述云端和边缘节点之间的不稳定网络会导致边缘节点频繁断开。如果云端或边缘节点重新启动或脱机一段时间,可能导致发送到边缘节点的消息丢失,这些消息无法到达到客户端。
基于此,本申请中,在所述云端和边缘节点之间搭建一个云端与边缘节点之间可靠的消息传递机制。基于所述消息传递机制之上,实现其它能力。在本申请中,所述消息传递机制可以是消息队列(Message Queue,MQ),基于消息队列的数据传输,可以保证消息传递的可靠性。
所述消息队列是基础数据结构中“先进先出”的一种数据结构。具体的,所述消息队列将要传输的数据(消息)放在队列中,用队列机制来实现消息传递。
所述消息队列中间件是分布式系统中重要的组件,主要实现解耦,异步消息,流量削锋等功能,实现高性能,高可用,可伸缩和最终一致性架构。
解耦:指业务需要多个模块共同实现,或者一条消息有多个系统需要对应处理,只需要主业务完成以后,发送一条MQ,其余模块消费MQ消息,即可实现业务,降低模块之间的耦合。
异步:主业务执行结束后从属业务通过MQ,异步执行,减低业务的响应时间,提高用户体验。
削峰:高并发情况下,业务异步处理,提供高峰期业务处理能力,避免系统瘫痪。
在本申请中,所述云端存储了需要同步到边缘资源的最新版本,该资源已经成功地发送到边缘。当云端正常重新启动或启动时,它将检查K8s里资源对应的ResourceVersion以避免发送旧消息。
在本申请中,所述K8S是Kubernetes组件的简称,该组件是一个开源的Linux容器自动化运维平台,用于消除容器化应用程序在部署、伸缩时涉及到的诸多手动操作。可以将多台主机组合成集群来运行 Linux 容器,而Kubernetes可以帮助简单高效地管理集群。构成这些集群的主机还可以跨越公有云、私有云以及混合云。
所述K8s要求用户在update请求中提交的对象必须带有ResourceVersion,也就是说在提交 update 的数据必须先来源于 K8s 中已经存在的对象。因此,一次完整的update 操作流程包括:
从 K8s 中拿到一个已经存在的对象;
基于所述对象进行修改,例如将 Deployment 中的 replicas 做增减,或是将image 字段修改为一个新版本的镜像;
将修改后的对象通过 update 请求提交给 K8s;
此时,kube-apiserver会校验用户 update 请求提交对象中的resourceVersion要和当前 K8s 中这个对象最新的resourceVersion一致,才能接受本次 update。否则,K8s会拒绝请求,并告诉用户发生了版本冲突(Conflict)。
请参照图1所示,S102基于在所述云端设置的K8S,和在所述边缘节点上设置的kebulet,修正所述kebulet实现通过所述消息传输机制连接所述边缘节点到所述K8S。
本申请中,Kubelet是kubernetes工作节点上的一个代理组件,运行在每个节点上。Kubelet是工作节点上的主要服务,定期从kube-apiserver组件接收新的或修改的Pod规范,并确保Pod及其容器在期望规范下运行。同时该组件作为工作节点的监控组件,向kube-apiserver汇报主机的运行状况。
本申请中,所述修正所述kebulet实际上是指对所述kebulet的参数进行配置,以实现保证系统进程的预留资源。
具体的,在边缘节点部署类似kebulet的服务,便于云端的K8S集群统一调度管理。但边缘节点不能直连K8S的apiserver(因为云边网络不稳定等原因),这里的数据传递需要走上面的Message Queue。所以需要修改kubelet的逻辑,同时为了兼容多种赋值的边缘节点机器,kubelet的兼容性也要更强。
在本申请中,所述kebulet还用于初始化验证,基于工作人员的设置查询组件运行状态,保证连接服务的稳定。
具体的,当启动服务时,首先启动所述kebulet组件,该kebulet进行状态查询、日志查询,完成查询后所述kebulet组件将关闭,然后启动服务。
所述kebulet组件还连接有状态判断组件,该状态判断组件可以实现基于当前服务运行环境进行状态判断,为所述kebulet组件进行状态查询进行查询标的的生成,所述状态判断组件设置有多个判断单元,具体可以根据实际工作需求进行设置,每个所述状态判断单元独立运行并将结果由所述状态判断组件统一,生成字符,以提供给所述kebulet组件进行状态查询。
图3是本申请中状态判断组件结构示意图。
请参照图3所示,所述状态判断组件包括状态判断单元101、状态判断单元102到状态判断单元103,每个所述状态判断组件连接到所述状态库104,每个所述状态判断单元用于一项参数的判断,并将判断结果发送到所述状态库104,所述状态库可以提高给所述kebulet组件状态查询的标的。
本申请中,所述每个状态判断单元可以设置为分数判断方式和是否判断方式,具体的,判断方式可用如下公式进行表示:
1、分数:
2、是否:
在上述公式中,所述是指每个所述状态判断单元中的数据,所述i是指状态判断单元的序号,可以根据实际情况进行确定,所述n是读取的历史数据个数,所述j是所述历史数据的序号,所述D是指每个历史数据,所述F是设定的阈值,所述F基于每个是不同的。
在上述的每个状态判断单元中,将判断结果进行输出,例如,所述分数可以输出为#,所述是否输出可以是#01/02。进一步的,每个所述状态判断单元输出的数据还添加有时间标签。
输出后所述状态库将基于每个所述状态判断单元添加的时间标签进行结构抽取,并集合全部所述结果进行判断。
具体的,该判断可由如下公式进行:
在上面的公式中,所述表示选择或者,具体为当所述状态判断单元采用分数判断时采用,所述状态判断单元采用是否判断时,则采用。所述是对所述或者的判断规则,所述判断规则是可以根据实际情况进行设定的。
预先的,对所述可的值进行定义,基于所述定义可以有所述kebulet组件进行状态读取。进一步的,通过自建的云端组件实现存储元数据或 Volume 等信息到边缘,实现云、边节点的配置状态的同步。
边缘节点,支持边缘离线模式,边缘端在断网环境下实现自治,拥有与管控端连接、同步、检验等能力。将本地元数据持久化,在本地保存云、边通信的所有数据,实现调用数据直接从本地获取,避免网络频繁交互。在离线时,本地数据依然发挥作用。
支持多类型异构资源,Linux OS 基于裸机/虚拟机 ARM / X86 / RISCVGPU /DPU / FPGA / SmartNIC。实现从云端直接登录运行的边缘节点容器,提供回滚、监控、报警等功能。支持容器与微服务,具有高兼容性与可扩展性。
请参照图1所示,S103根据所述消息传输机制,将通过EdgeDeviceManager收集的下发数据在所述云和边缘节点之间同步。
EdgeDeviceManager(边缘管理设备)是一个在不同类型网络间传送数据的物理设备。其不负责收集网络路由信息,它只是使用在网络层获得的路由信息。
在本申请中,通过所述EdgeDeviceManager可以将收集的下发数据在所述云和边缘节点之间同步。
具体的,对于边缘设备(Devices)的管理,通过 Edge Device Manager 收集下发数据,然后通过 Message Queue 在云边之间同步。设备信息在云端的存储,通过 K8S 的CRD 实现。
基于上述内容提供的途径,用户就可以通过在云端操作K8S相关资源,达到统一管理边缘端容器和设备。
工作流程如下:
对于部署容器服务:在云端通过kubectl apply 应用到边缘节点,Message Queue会把 POD 信息同步到边缘的 Edge Kubelet。
对于设备数据同步:设备产生数据,通过 Message Queue 同步到云端,云端再把数据同步到K8S的 CR 里,用户通过K8S的接口查看相关数据。
本申请还提供一种云边协同装置,包括设置模块401、修改模块402、同步模块403。
图4是本申请中云边协同装置示意图。
请参照图4所示,设置模块401,用于建立云端和边缘节点之间的消息传输机制。
所述云端是指云服务、云计算等,是一种集合分布式、并行计算、网络存储、虚拟化以及内容分发等特点的网络技术。所述云服务可以通过需求进行资源分配,易扩展是其核心属性之一,因此通过云服务可以提高计算能力的同时,还可节省计算资源。
图2是本申请中云边协同架构示意图。
请参照图2所示,所述云端与客户端相连,通过中间的路由设备,将数据准确的在所述云端与客户端之间进行传输,这其中,基于所述客户端的需求,所述云端将建立虚拟机,并基于所述客户端需求对数据进行处理,存储等。所述虚拟机的建立是唯一指向特定的客户端的,当有不同客户端时,则在所述云端将建立不同的虚拟机,实现数据的处理与存储。
本申请中,所述客户端是指服务的客户端,例如移动设备中安装的软件,而不是指一个移动设备或者桌面电脑。因此所述一个终端设备可以运行多个所述客户端,进而在所述云端建立多个所述虚拟机。所述云端可以是一个或者多个,基于用户的选择和设置,或者基于客户端的默认实现连接。
所述云端通过路由设备准确的与所述客户端进行数据交互,这其中,所述用户端附近将设置有边缘节点,该边缘节点用于实现部分所述云端的功能,以提高所述对所述客户端的响应能力。
在本申请中,所述边缘节点部署在距离所述客户端最近的位置,既所述客户端在与所述云端建立联系时,与距离最近的该云端所属边缘节点进行连接。所述边缘节点与所述云端连接,基于客户端请求,所述边缘节点从所述云端请求数据。
所述云端和边缘节点之间的不稳定网络会导致边缘节点频繁断开。如果云端或边缘节点重新启动或脱机一段时间,可能导致发送到边缘节点的消息丢失,这些消息无法到达到客户端。
基于此,本申请中,在所述云端和边缘节点之间搭建一个云端与边缘节点之间可靠的消息传递机制。基于所述消息传递机制之上,实现其它能力。在本申请中,所述消息传递机制可以是消息队列(Message Queue,MQ),基于消息队列的数据传输,可以保证消息传递的可靠性。
所述消息队列是基础数据结构中“先进先出”的一种数据结构。具体的,所述消息队列将要传输的数据(消息)放在队列中,用队列机制来实现消息传递。
所述消息队列中间件是分布式系统中重要的组件,主要实现解耦,异步消息,流量削锋等功能,实现高性能,高可用,可伸缩和最终一致性架构。
解耦:指业务需要多个模块共同实现,或者一条消息有多个系统需要对应处理,只需要主业务完成以后,发送一条MQ,其余模块消费MQ消息,即可实现业务,降低模块之间的耦合。
异步:主业务执行结束后从属业务通过MQ,异步执行,减低业务的响应时间,提高用户体验。
削峰:高并发情况下,业务异步处理,提供高峰期业务处理能力,避免系统瘫痪。
在本申请中,所述云端存储了需要同步到边缘资源的最新版本,该资源已经成功地发送到边缘。当云端正常重新启动或启动时,它将检查 K8s 里资源对应的ResourceVersion以避免发送旧消息。
在本申请中,所述K8S是Kubernetes组件的简称,该组件是一个开源的Linux容器自动化运维平台,用于消除容器化应用程序在部署、伸缩时涉及到的诸多手动操作。可以将多台主机组合成集群来运行 Linux 容器,而Kubernetes可以帮助简单高效地管理集群。构成这些集群的主机还可以跨越公有云、私有云以及混合云。
所述K8s要求用户在update请求中提交的对象必须带有ResourceVersion,也就是说在提交 update 的数据必须先来源于 K8s 中已经存在的对象。因此,一次完整的update 操作流程包括:
从 K8s 中拿到一个已经存在的对象;
基于所述对象进行修改,例如将 Deployment 中的 replicas 做增减,或是将image 字段修改为一个新版本的镜像;
将修改后的对象通过 update 请求提交给 K8s;
此时,kube-apiserver会校验用户 update 请求提交对象中的resourceVersion要和当前 K8s 中这个对象最新的resourceVersion一致,才能接受本次 update。否则,K8s会拒绝请求,并告诉用户发生了版本冲突(Conflict)。
请参照图4所示,修改模块402,用于基于在所述云端设置的K8S,和在所述边缘节点上设置的kebulet,修正所述kebulet实现通过所述消息传输机制连接所述边缘节点到所述K8S。
本申请中,Kubelet是kubernetes工作节点上的一个代理组件,运行在每个节点上。Kubelet是工作节点上的主要服务,定期从kube-apiserver组件接收新的或修改的Pod规范,并确保Pod及其容器在期望规范下运行。同时该组件作为工作节点的监控组件,向kube-apiserver汇报主机的运行状况。
本申请中,所述修正所述kebulet实际上是指对所述kebulet的参数进行配置,以实现保证系统进程的预留资源。
具体的,在边缘节点部署类似kebulet的服务,便于云端的K8S集群统一调度管理。但边缘节点不能直连K8S的apiserver(因为云边网络不稳定等原因),这里的数据传递需要走上面的Message Queue。所以需要修改kubelet的逻辑,同时为了兼容多种赋值的边缘节点机器,kubelet的兼容性也要更强。
在本申请中,所述kebulet还用于初始化验证,基于工作人员的设置查询组件运行状态,保证连接服务的稳定。
具体的,当启动服务时,首先启动所述kebulet组件,该kebulet进行状态查询、日志查询,完成查询后所述kebulet组件将关闭,然后启动服务。
所述kebulet组件还连接有状态判断组件,该状态判断组件可以实现基于当前服务运行环境进行状态判断,为所述kebulet组件进行状态查询进行查询标的的生成,所述状态判断组件设置有多个判断单元,具体可以根据实际工作需求进行设置,每个所述状态判断单元独立运行并将结果由所述状态判断组件统一,生成字符,以提供给所述kebulet组件进行状态查询。
图3是本申请中状态判断组件结构示意图。
请参照图3所示,所述状态判断组件包括状态判断单元101、状态判断单元102到状态判断单元103,每个所述状态判断组件连接到所述状态库104,每个所述状态判断单元用于一项参数的判断,并将判断结果发送到所述状态库104,所述状态库可以提高给所述kebulet组件状态查询的标的。
本申请中,所述每个状态判断单元可以设置为分数判断方式和是否判断方式,具体的,判断方式可用如下公式进行表示:
1、分数:
2、是否:
在上述公式中,所述是指每个所述状态判断单元中的数据,所述i是指状态判断单元的序号,可以根据实际情况进行确定,所述n是读取的历史数据个数,所述j是所述历史数据的序号,所述D是指每个历史数据,所述F是设定的阈值,所述F基于每个是不同的。
在上述的每个状态判断单元中,将判断结果进行输出,例如,所述分数可以输出为#,所述是否输出可以是#01/02。进一步的,每个所述状态判断单元输出的数据还添加有时间标签。
输出后所述状态库将基于每个所述状态判断单元添加的时间标签进行结构抽取,并集合全部所述结果进行判断。
具体的,该判断可由如下公式进行:
在上面的公式中,所述表示选择或者,具体为当所述状态判断单元采用分数判断时采用,所述状态判断单元采用是否判断时,则采用。所述是对所述或者的判断规则,所述判断规则是可以根据实际情况进行设定的。
预先的,对所述可的值进行定义,基于所述定义可以有所述kebulet组件进行状态读取。进一步的,通过自建的云端组件实现存储元数据或 Volume 等信息到边缘,实现云、边节点的配置状态的同步。
边缘节点,支持边缘离线模式,边缘端在断网环境下实现自治,拥有与管控端连接、同步、检验等能力。将本地元数据持久化,在本地保存云、边通信的所有数据,实现调用数据直接从本地获取,避免网络频繁交互。在离线时,本地数据依然发挥作用。
支持多类型异构资源,Linux OS 基于裸机/虚拟机 ARM / X86 / RISCVGPU /DPU / FPGA / SmartNIC。实现从云端直接登录运行的边缘节点容器,提供回滚、监控、报警等功能。支持容器与微服务,具有高兼容性与可扩展性。
请参照图4所示,同步模块403,用于根据所述消息传输机制,将通过EdgeDeviceManager收集的下发数据在所述云和边缘节点之间同步。
EdgeDeviceManager(边缘管理设备)是一个在不同类型网络间传送数据的物理设备。其不负责收集网络路由信息,它只是使用在网络层获得的路由信息。
在本申请中,通过所述EdgeDeviceManager可以将收集的下发数据在所述云和边缘节点之间同步。
具体的,对于边缘设备(Devices)的管理,通过 Edge Device Manager 收集下发数据,然后通过 Message Queue 在云边之间同步。设备信息在云端的存储,通过 K8S 的CRD 实现。
基于上述内容提供的途径,用户就可以通过在云端操作K8S相关资源,达到统一管理边缘端容器和设备。
工作流程如下:
对于部署容器服务:在云端通过kubectl apply 应用到边缘节点,Message Queue会把 POD 信息同步到边缘的 Edge Kubelet。
对于设备数据同步:设备产生数据,通过 Message Queue 同步到云端,云端再把数据同步到K8S的 CR 里,用户通过K8S的接口查看相关数据。
本申请是参照根据本申请实施例的方法、装置(系统)、和计算机程序产品的流程图和/或方框图来描述的。
应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
尽管已描述了本申请的优选实施例,但本领域内的技术人员一旦得知了基本创造性概念,则可对这些实施例作出另外的变更和修改。所以,所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。
显然,本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样,倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内,则本申请也意图包含这些改动和变型在内。