CN114900449A - 一种资源信息管理方法、系统及装置 - Google Patents

Abstract

本发明公开了一种资源信息管理方法，所述方法包括：在多个所述监控端中确定主监控端，通过所述主监控端对各个被监控节点进行监听，以获取各个所述被监控节点的资源状态，其中，多个所述监控端和各个所述被监控节点位于目标边缘集群中；判断各个所述被监控节点中任意一个目标节点是否发生资源变动事件，若所述目标节点发生资源变动事件，则生成资源变动消息；将所述资源变动消息发送至所述服务端，以使得所述服务端基于所述资源变动消息生成目标存储数据，并使得所述平台数据库存储所述目标存储数据。本申请提供的技术方案，可以高效方便的查看边缘节点的资源信息。

Description

一种资源信息管理方法、系统及装置

技术领域

本发明涉及互联网技术领域，特别涉及一种资源信息管理方法、系统及装置。

背景技术

随着云计算的快速发展，虚拟化、网络化、分布式技术在云计算中得到越来越多的应用，容器云应运而生。容器云可以理解为云上的容器技术服务，其将客户的云业务运行在容器中。容器云通常包括多个边缘集群，一个中心集群，边缘集群运行客户的云业务，中心集群负责节点资源的统一调度和管理。

随着业务量的增加，边缘集群的数量也越来越多，为提高边缘集群的管理效率，一种途径是根据边缘节点的资源信息，例如节点的资源使用情况，进行资源调度，这就要求中心集群可以实时获取边缘节点的资源使用情况。现实场景中，中心集群可以通过调用命令查看边缘节点的资源信息。但是，当边缘节点数量较多时，中心集群通过调用命令逐个查看边缘节点的资源信息，效率很低，而且时效性差。

鉴于此，有必要提供一种资源信息管理方法、系统及装置以解决上述不足。

发明内容

本申请的目的在于提供一种资源信息管理方法、系统及装置，可以高效方便的查看边缘节点的资源信息。

为实现上述目的，本申请一方面提供一种资源信息管理方法，所述方法应用于边缘容器管理平台中，所述边缘容器管理平台至少包括服务端、平台数据库和多个监控端，所述方法包括：在多个所述监控端中确定主监控端，通过所述主监控端对各个被监控节点进行监听，以获取各个所述被监控节点的资源状态，其中，所述多个监控端和各个所述被监控节点位于目标边缘集群中；判断各个所述被监控节点中任意一个目标节点是否发生资源变动事件，若所述目标节点发生资源变动事件，则生成资源变动消息；将所述资源变动消息发送至所述服务端，以使得所述服务端基于所述资源变动消息生成目标存储数据，并使得所述平台数据库存储所述目标存储数据。

为实现上述目的，本申请另一方面还提供一种资源信息管理系统，所述资源信息管理系统至少包括服务端、平台数据库和主监控端，其中，所述主监控端，用于对各个被监控节点进行监听，以获取各个所述被监控节点的资源状态，其中，所述主监控端和各个所述被监控节点位于目标边缘集群中，以及，判断各个所述被监控节点中任意一个目标节点是否发生资源变动事件，若所述目标节点发生资源变动事件，则生成资源变动消息，并将所述资源变动消息发送至所述服务端；所述服务端，用于接收所述资源变动消息，并基于所述资源变动消息生成目标存储数据，以及，将所述目标存储数据发送至所述平台数据库；所述平台数据库，用于存储所述目标存储数据。

为实现上述目的，本申请另一方面还提供一种资源信息管理装置，所述装置包括存储器和处理器，所述存储器用于存储计算机程序，当所述计算机程序被所述处理器执行时，实现上述资源信息管理方法。

由此可见，本申请提供的技术方案，在边缘容器管理平台中引入服务端、平台数据库和多个监控端，其中，服务端位于中心集群，监控端位于边缘集群，监控端连接服务端。监控端监听所属边缘集群中各个边缘节点的资源变化情况，当边缘节点发生资源变动时，监控端即将资源变动信息上报同步到服务端，从而保证信息上报的时效性。同时，边缘集群部署有多个监控端，当主监控端出现故障时可以自动切换到其它备用监控端，从而保证信息上报的稳定性。进一步的，服务端在接收到资源变动信息后，可以将其转换为特定的数据格式，并写入平台数据库，如此，既可以防止资源信息丢失，也方便后期查看边缘节点的资源信息。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施方式中边缘容器管理平台的架构示意图；

图2本申请实施方式中资源信息管理方法的流程图；

图3是本申请实施方式中资源信息管理系统的功能模块示意图；

图4是本申请实施方式中资源信息管理装置的结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。

随着云计算的快速发展，虚拟化、网络化、分布式技术在云计算中得到越来越多的应用，容器云应运而生。容器云属于PaaS(即平台即服务)模式，在这种交付模式中云端集中托管软件及其相关的数据，软件仅需透过互联网，而无需通过安装即可使用，其可以理解为云上的容器技术服务，其将客户的云业务运行在容器中。容器云通常包括多个边缘集群，一个中心集群，其中边缘集群运行客户的云业务，中心集群负责节点资源的统一调度和管理。

随着业务量的增加，边缘集群的数量也越来越多，如何管理好边缘节点的业务分配，保证不同容量的边缘节点可以分配到合适的业务量，一种可实现的方法是根据边缘节点的资源信息，例如节点的资源使用情况，进行资源调度。这种调度方法要求中心集群可以实时获取边缘节点的资源使用情况，现实场景中，中心集群可以通过调用命令查看边缘节点的资源信息。但是，当边缘节点数量较多时，中心集群通过调用命令逐个查看边缘节点的资源信息，效率很低，而且时效性差。同时，由于边缘节点的资源经常变动，并且边缘节点的资源信息种类繁多，在边缘集群规模庞大的情况下，如何存储海量的资源信息，并快速查找所需的资源信息将面临较大的挑战。

因此，如何对边缘节点的资源信息进行管理，以高效方便的查看边缘节点的资源信息，便成为本领域亟待解决的问题。

本申请提供的技术方案可以解决上述不足。

为方便后续描述并清楚的对本申请进行说明，以下首先对本申请可能用到的概念做简单的说明。

k8s：全称kubernetes，k8s是一种容器编排管理工具，k8s集群由Master节点和Node节点组成。Master节点指的是集群控制节点，其负责管理和控制整个集群。在Master节点上主要运行着如下组件：apiserver组件，负责对外提供kubernetes的API服务，Master节点上的其它组件通过调用apiserver组件提供的接口来实现各自的功能；scheduler组件，负责监听apiserver组件的新建pod副本信息，按照预定的调度策略将pod实例调度到相应的节点上；contronller-manager组件，负责维护管理整个集群的状态，例如故障检测、自动扩展、滚动更新等，controller-manager组件通过调用apiserve组件监控节点的资源状态。

边缘容器管理平台：面向边缘计算场景，基于Kubernetes容器编排技术而开发设计的边缘容器管理平台。本方案定义的边缘容器管理平台为k8s-edge边缘容器管理平台，它基于Kubernetes构建，并为网络、应用程序部署以及云与边缘之间的元数据同步提供核心基础架构支持，k8s-edge由云端(CloudCore)和边缘端(EdgeCore)组成。

Redis:一种key-value存储系统，它可以用作数据库、缓存和消息中间件。

如图1所示，为本申请实施方式中边缘容器管理平台的架构示意图。

在本实施方式中，边缘容器管理平台至少包括一个中心集群、一个平台数据库和多个边缘集群，中心集群中存在至少一个服务端，每一个边缘集群中都存在多个监控端和多个边缘节点，其中，边缘节点用于部署云业务，监控端用于监控其所属集群中各个边缘节点的资源状态，即监控端和其监控的边缘节点位于同一个边缘集群中。

各个边缘集群分别与中心集群通信连接，监控端监听边缘节点的资源变化情况，当发生资源创建、更新、删除时，监控端可以立即将资源变动情况上报同步到服务端，从而保证信息上报的时效性。同时，每一个边缘集群中都存在多个监控端，多个监控端互为备份，当其中一个监控端出现故障时，可以自动切换至其它监控端，从而保证资源变动信息上报的稳定性。

当服务端接收到资源变动信息后，服务端可以将其写入平台数据库，如此既可以防止数据丢失，也方便后期查看。进一步的，服务端在将资源变动信息写入平台数据库时，可以将资源变动信息转换为预设的数据存储结构，例如将其转换为Redis数据存储结构，从而使得在资源种类繁多、集群数量大的情况下，后期也可以高效、方便地查看边缘集群的资源变动情况。

如图2所示，为本申请实施方式中资源信息管理方法的流程图，所述方法应用于边缘容器管理平台中，所述边缘容器管理平台至少包括服务端、平台数据库和多个监控端，所述方法可以包括以下步骤。

S101：在多个所述监控端中确定主监控端，通过所述主监控端对各个被监控节点进行监听，以获取各个所述被监控节点的资源状态，其中，所述多个监控端和各个所述被监控节点位于目标边缘集群中。

在本实施方式中，对于任意一个边缘集群(为便于叙述，将其命名为目标边缘集群)，由于目标边缘集群中存在多个监控端，为实现监控程序的高可用性，并降低监控程序对系统资源的消耗，可以首先在上述多个监控端中确定主监控端，由主监控端对目标边缘集群中的各个边缘节点(即被监控节点)进行监听，从而获取各个被监控节点的资源状态。

在实际应用中，操作人员可以将监控端程序部署在多个pod实例中，然后利用反亲和策略将多个pod实例分别部署在不同的物理节点上，从而保证监控程序可以在多个物理节点上运行。具体的，操作人员可以使用pod反亲和硬策略,确保具有相同lable的pod实例一定不能调度到同一物理节点上。此时，一个pod实例便对应一个物理节点，每一个运行有监控程序的物理节点便成为一个监控端。进一步的，运行有监控程序的各个pod实例互相感知，从而使得多个pod实例可以通过分布式资源锁机制在多个物理节点中选出主监控端，主监控端上运行的监控程序负责监听所属边缘集群(即目标边缘集群)的资源变动情况。同时，主监控端上运行的监控程序与中心集群的服务端保持通信联系。当目标边缘集群的资源情况发生变化时，例如发生增加、删除、修改操作时，主监控端上运行的监控程序可以将上述资源变化情况生成资源变动消息，并将该资源变动消息发送至服务端。

在一个实施方式中，当生成多个监控端后，操作人员可以通过分布式资源锁机制在多个监控端中选举出主监控端。以k8s为例，通过设置启动参数leader-elect＝true，从而使得正常状况下scheduler或controller-manager组件的多个副本中只有一个是处于业务逻辑运行状态，其它副本则不断的尝试去获取资源锁，以竞争成为主监控端。在竞争资源锁时，各个副本首先会尝试获取资源锁，在获取资源锁时会检测对应的annotations中是否存在，如果不存在则当前资源锁没有被持有。如果检测到资源锁不存在，则直接进行资源锁的创建，如果创建成功则表明当前节点获取资源锁，该节点则成为主监控端，执行主监控端的回调逻辑。如果正在运行的主监控端因为某种原因导致当前进程退出，或者资源锁丢失，则由其它副本竞争资源锁，以成为新的主监控端，继而执行业务逻辑。

通过分布式资源锁机制，当主监控端发生异常，例如其所在的机器出现故障或者发生网络异常等情况时，上述多个监控端将重新选择出新的主监控端，由新的主监控端监听目标边缘集群的资源变动情况，并由新的主监控端与中心集群的服务端建立通信联系，从而保证资源变动消息上报的稳定性，避免因某个机器故障，导致整个资源变动消息上报的中断。

为确保主监控端可以将资源变动消息及时可靠的发送至服务端，可以进一步检测主监控端与服务端的连接情况。在一个实施方式中，在确定主监控端之后，主监控端可以判断自身是否已经与服务端成功建立了通信连接。具体的，主监控端可以主动向服务端发送心跳信号，通过服务端的回复情况判断双方之间是否已经成功建立通讯链路。如果主监控端判断自身未与服务端成功建立通信连接，那么主监控端可以释放资源锁，由其它监控端去竞争资源锁，从而在多个监控端中选举出新的主监控端。关于在多个监控端中选举出新的主监控端的过程，可以参考前文关于分布式资源锁机制的内容，此处不再赘述。

在一个实施方式中，当主监控端确定自身已经与服务端成功建立通信连接后，主监控端可以对目标边缘集群中的各个被监控节点进行监听，从而获取各个被监控节点的资源状态。具体的，各个被监控节点首先向主监控端注册各自的节点信息，从而使得各个被监控节点被纳入主监控端的监控范围。同时，各个被监控节点监听本节点的资源状态，并将资源状态上报至主监控端，如此，主监控端便可以获取各个被监控节点的资源状态。在实际应用中，可以在边缘容器管理平台中引入Whale缓存框架，从而在本地缓存各个边缘节点的资源状态信息。各个被监控节点中任意一个节点(即目标节点)可以监听并获取本机的资源状态信息，然后主监控端通过调用apiserve组件获取目标节点的资源状态信息。以采用k8s部署的集群为例，目标节点获取的资源状态信息为kubernetes原生的数据结构，上述资源状态信息包括pod、service、deployment、configmap、pvc等类型，比如service类型信息，其包含了service ip、service port、service协议等信息。当主监控端获取到目标节点的资源状态信息后，主监控端可以将上述资源状态信息存入集群缓存中，这样目标节点的资源状态信息便可以同步到纳管的目标边缘集群中。

S102：判断各个所述被监控节点中任意一个目标节点是否发生资源变动事件，若所述目标节点发生资源变动事件，则生成资源变动消息。

在本实施方式中，当主监控端确定自身已经与服务端成功建立通信连接后，主监控端可以对其监听获得的目标节点的资源状态信息进行解析，从而判断目标节点是否发生资源变动事件。举例说明，假设客户在目标节点上创建了一个新的pod实例，此时目标节点会产生一个“add”事件，并将该事件上报存储至集群缓存中。主监控端通过调用apiserve组件可以从集群缓存中读取到上述“add”事件，然后主监控端可以对上述“add”事件进行解析，进而判断目标节点发生了资源变动事件。

当主监控端判断目标节点发生资源变动事件后，主监控端可以生成资源变动消息，并将该资源变动消息封装为http报文发送至服务端。进一步的，主监控端在发送资源变动消息时，可以将项目名称、自身集群的名称、命名空间、资源类型和资源名称等信息封装到http报文中，一并发送。

在一个实施方式中，当主监控端生成资源变动消息之后，主监控端可以为资源变动消息生成追踪标识，并将追踪标识与资源变动消息进行绑定，即一个资源变动消息唯一对应一个追踪标识，追踪标识的具体形式可以为主监控端随机生成的数值。当主监控端将追踪标识与资源变动消息进行绑定后，主监控端可以将追踪标识添加在资源变动消息中，例如，主监控端可以将追踪标识一并封装到http报文中，如此，追踪标识将随着资源变动消息传输至服务端。如果操作人员无法在服务端查找到资源变动消息，操作人员便可以通过查询日志，查找与资源变动消息相对应的追踪标识，进而通过追踪标识分析资源变动消息的传输路径，从而确定资源变动消息在哪个环节丢失。

S103：将所述资源变动消息发送至所述服务端，以使得所述服务端基于所述资源变动消息生成目标存储数据，并使得所述平台数据库存储所述目标存储数据。

在本实施方式中，当主监控端将资源变动消息发送至服务端后，服务端可以对上述资源变动消息进行解析，从而获取资源变动消息中包含的资源变动信息。进一步的，服务端可以按照预设格式将上述资源变动信息转换为目标存储数据。

在实际应用中，服务端可以首先解析上述资源变动消息，从而获取该资源变动消息中的属性信息和数值信息，其中，上述属性信息至少包括项目名称、集群名称、资源类型和资源名称中的一者或多者，然后，服务端可以根据预设的格式转换策略，将上述属性信息和上述数值信息转换为目标存储数据。具体的，目标存储数据可以为“key：value”格式，其中，key结构至少包括：“项目名称”-“集群名称”-“资源类型”-“资源名称”等信息，其内容为属性信息，value内容为数值信息。

举例说明，目标存储数据为PREFIX:{cluster}:{ns}:{kind}：{name}，变量说明：

PREFIX：为项目名、状态，方便区分不同的项目；

{cluster}：集群名称，需要外部保证集群名不重复；

{ns}：命名空间，用于区别用户；

{kind}：资源类型，.e.g：deployment、daemonset...；

{name}：资源名称；

Value为具体的数据内容。

在集群数量较多的情况下，通过将资源变动消息转换为目标存储数据，可以快速查找xx集群的信息，或xx集群xx资源。

在一个实施方式中，当服务端将资源变动消息转换为目标存储数据后，服务端可以将将目标存储数据发送至平台数据库，从而使得平台数据库可以存储目标存储数据，平台数据库的具体形式可以为Redis数据库。

在实际应用中，为防止Redis数据库存储的数据量过大，导致可用存储容量不足。在一个实施方式中，当平台数据库存储目标存储数据之后，平台数据库可以为目标存储数据设置缓存过期时间，然后平台数据库可以基于缓存过期时间判断目标存储数据是否过期，如果目标存储数据过期，那么平台数据库可以删除目标存储数据。例如，平台数据库可以为目标存储数据设置5分钟的缓存过期时间，如果目标存储数据在平台数据库中超过5分钟没有更新，那么平台数据库可以自动删除目标存储数据。

在一个实施方式中，边缘容器管理平台还可以为目标边缘集群设置集群资源过期策略，以刷新整个集群资源信息在平台数据库中的存储时间。例如，边缘容器管理平台可以将目标边缘集群的集群资源过期策略设置为10分钟，当目标边缘集群满足上述过期策略时，即每间隔10分钟，主监控端将向各个被监控节点发送资源更新指令，从而获取各个被监控节点反馈的更新后的资源状态。然后，主监控端将把上述更新后的资源状态发送至服务端，服务端在接收到上述更新后的资源状态后，可以将其转换为“key：value”格式，并将上述“key：value”格式的数据发送至平台数据库，最终平台数据库将使用该“key：value”格式的数据更新目标边缘集群的资源信息。

为便于理解，下文结合实际应用场景对本申请涉及的资源信息管理方法进行说明。

第一步：假设目标边缘集群A有10台机器，采用k8s部署，其中master属性的机器有3台，上述3台机器分别运行一个监控程序，并采用kubernetes tools/leaderelection包提供的选主逻辑。

第二步：3个监控端启动，去竞争kubernetes的资源锁”lock_example”，如果资源锁不存在，则创建资源锁。第一个拿到或者创建资源锁的监控端成为主监控端，其它客户端等待资源锁的释放。

第三步：主监控端连接中心集群的服务端，如果连接失败，则释放资源锁，由其它监控端获取；如果连接成功，主监控端监听集群的kubernetes资源变动。假设，客户创建了一个pod实例，kubernetes系统会产生一个“add”事件，主监控端监听到这个事件，则将该资源变动事件封装成http报文发送到服务端，这里的事件内容，是pod的信息，主监控端可以把事件内容、集群名称等信息放在http报文的负载里。

第四步：服务端接收到主监控端的报文后，对报文进行解析，得到“add”事件，并把事件内容、集群名称等信息整理未“key：value”格式，此处的Key为“project1:cluster1:user1:pod：podName1”，内容为pod的编排信息，project为项目名称，可以通过主监控端传递。

第五步：服务端将上述“key：value”信息发送至Redis数据库，Redis数据库可以对上述“key：value”信息进行存储。

第六步：如果边缘集群删除、更新了一个事件，这个事件传递到服务端，再由服务端传递到Redis数据库。Redis数据库则可以删除、更新相应的信息。

第七步：每隔5分钟，目标边缘集群会针对现有的全部资源产生一个update事件，主监控端再把上述事件传递到服务端，最终Redis数据库对目标边缘集群的资源信息进行更新。

请参阅图3，本申请还提供一种资源信息管理系统，所述资源信息管理系统至少包括服务端、平台数据库和主监控端，其中，

所述主监控端，用于对各个被监控节点进行监听，以获取各个所述被监控节点的资源状态，其中，所述主监控端和各个所述被监控节点位于目标边缘集群中，以及，判断各个所述被监控节点中任意一个目标节点是否发生资源变动事件，若所述目标节点发生资源变动事件，则生成资源变动消息，并将所述资源变动消息发送至所述服务端；

所述服务端，用于接收所述资源变动消息，并基于所述资源变动消息生成目标存储数据，以及，将所述目标存储数据发送至所述平台数据库；

所述平台数据库，用于存储所述目标存储数据。

在一个实施方式中，所述资源信息管理系统还包括多个监控端，多个所述监控端通过分布式资源锁机制选举出所述主监控端。

在一个实施方式中，所述主监控端，还用于判断是否与所述服务端成功建立通信连接，若未与所述服务端成功建立通信连接，则释放资源锁。

在一个实施方式中，所述主监控端对各个被监控节点进行监听包括：

各个所述被监控节点向所述主监控端注册节点信息，以使得各个所述被监控节点纳入所述主监控端监控范围；

各个所述被监控节点监听本节点的资源状态，并将所述资源状态上报至所述主监控端。

在一个实施方式中，所述服务端基于所述资源变动消息生成目标存储数据包括：

解析所述资源变动消息，以获取所述资源变动消息中的属性信息和数值信息，其中，所述属性信息至少包括项目名称、集群名称、资源类型和资源名称中的一者或多者；

根据预设的形式转换策略，将所述属性信息和所述数值信息转换为所述目标存储数据。

在一个实施方式中，所述平台数据库，还用于为所述目标存储数据设置缓存过期时间，判断所述目标存储数据是否过期，若所述目标存储数据过期，则删除所述目标存储数据。

请参阅图4，本申请还提供一种资源信息管理装置，所述装置包括存储器和处理器，所述存储器用于存储计算机程序，当所述计算机程序被所述处理器执行时，可以实现如上述的资源信息管理方法。具体地，在硬件层面，该装置可以包括处理器、内部总线和存储器。所述存储器可以包括内存以及非易失性存储器。处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行。本领域普通技术人员可以理解，图4所示的结构仅为示意，其并不对上述装置的结构造成限定。例如，所述装置还可包括比图4中所示更多或者更少的组件，例如还可以包括其他的处理硬件，如GPU(Graphics Processing Unit，图像处理器)，或者对外通信端口等。当然，除了软件实现方式之外，本申请并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等。

本实施方式中，所述的处理器可以包括中央处理器(CPU)或图形处理器(GPU)，当然也可以包括其他的具有逻辑处理能力的单片机、逻辑门电路、集成电路等，或其适当组合。本实施方式所述的存储器可以是用于保存信息的记忆设备。在数字系统中，能保存二进制数据的设备可以是存储器；在集成电路中，一个没有实物形式的具有存储功能的电路也可以为存储器，如RAM、FIFO等；在系统中，具有实物形式的存储设备也可以叫存储器等。实现的时候，该存储器也可以采用云存储器的方式实现，具体实现方式，本说明书不做限定。

需要说明的是，本说明书中的资源信息管理装置，具体的实现方式可以参照方法实施方式的描述，在此不作一一赘述。

由此可见，本申请提供的技术方案，在边缘容器管理平台中引入服务端、平台数据库和多个监控端，其中，服务端位于中心集群，监控端位于边缘集群，监控端连接服务端。监控端监听所属边缘集群中各个边缘节点的资源变化情况，当边缘节点发生资源变动时，监控端立即将资源变动信息上报同步到服务端，从而保证信息上报的时效性。同时，边缘集群部署有多个监控端，当主监控端出现故障时可以自动切换到其它备用监控端，从而保证信息上报的稳定性。进一步的，服务端在接收到资源变动信息后，可以将其转换为特定的数据格式，并写入平台数据库，如此，既可以防止资源信息丢失，也方便后期查看边缘节点的资源信息。同时，中心集群的其它程序，比如资源调度器或者管理页面，在获取边缘资源信息的时候，可以直接调用服务端程序，再由后者去平台数据库获取资源信息，其它程序不需要感知平台数据库，不需要了解平台数据库的查询命令，只需将其想要获取的资源信息发送给服务端程序即可，这样操作更简单、更高效。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件来实现。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。

以上所述仅为本发明的较佳实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种资源信息管理方法，其特征在于，所述方法应用于边缘容器管理平台中，所述边缘容器管理平台至少包括服务端、平台数据库和多个监控端，所述方法包括：

在多个所述监控端中确定主监控端，通过所述主监控端对各个被监控节点进行监听，以获取各个所述被监控节点的资源状态，其中，多个所述监控端和各个所述被监控节点位于目标边缘集群中；

判断各个所述被监控节点中任意一个目标节点是否发生资源变动事件，若所述目标节点发生资源变动事件，则生成资源变动消息；

将所述资源变动消息发送至所述服务端，以使得所述服务端基于所述资源变动消息生成目标存储数据，并使得所述平台数据库存储所述目标存储数据。

2.根据权利要求1所述的方法，其特征在于，在多个所述监控端中确定主监控端包括：

将监控程序部署在多个pod实例中，并利用反亲和策略将多个所述pod实例分别部署在不同的物理节点上，以生成多个所述监控端；

通过分布式资源锁机制在多个所述监控端中选举出所述主监控端。

3.根据权利要求2所述的方法，其特征在于，在多个所述监控端中确定主监控端之后，所述方法还包括：

判断是否与所述服务端成功建立通信连接，若未与所述服务端成功建立通信连接，则释放资源锁，以在多个所述监控端中选举出新的主监控端。

4.根据权利要求1所述的方法，其特征在于，通过所述主监控端对各个被监控节点进行监听包括：

各个所述被监控节点向所述主监控端注册节点信息，以使得各个所述被监控节点纳入所述主监控端的监控范围；

各个所述被监控节点监听本节点的资源状态，并将所述资源状态上报至所述主监控端。

5.根据权利要求1所述的方法，其特征在于，在生成资源变动消息之后，所述方法还包括：

为所述资源变动消息生成追踪标识，其中，所述追踪标识与所述资源变动消息相绑定；

将所述追踪标识添加在所述资源变动消息中，以通过所述追踪标识分析所述资源变动消息的传输路径。

6.根据权利要求1所述的方法，其特征在于，所述服务端基于所述资源变动消息生成目标存储数据包括：

解析所述资源变动消息，以获取所述资源变动消息中的属性信息和数值信息，其中，所述属性信息至少包括项目名称、集群名称、资源类型和资源名称中的一者或多者；

根据预设的格式转换策略，将所述属性信息和所述数值信息转换为所述目标存储数据。

7.根据权利要求1所述的方法，其特征在于，所述平台数据库存储所述目标存储数据之后，所述方法还包括：

所述平台数据库为所述目标存储数据设置缓存过期时间；

所述平台数据库判断所述目标存储数据是否过期，若所述目标存储数据过期，则删除所述目标存储数据。

8.根据权利要求1所述的方法，其特征在于，所述方法还包括：

设置集群资源过期策略；

当所述目标边缘集群满足所述过期策略时，所述主监控端向各个所述被监控节点发送资源更新指令，以获取各个所述被监控节点反馈的更新后的资源状态。

9.一种资源信息管理系统，其特征在于，所述资源信息管理系统至少包括服务端、平台数据库和主监控端，其中，

所述主监控端，用于对各个被监控节点进行监听，以获取各个所述被监控节点的资源状态，其中，多个所述主监控端和各个所述被监控节点位于目标边缘集群中，以及，判断各个所述被监控节点中任意一个目标节点是否发生资源变动事件，若所述目标节点发生资源变动事件，则生成资源变动消息，并将所述资源变动消息发送至所述服务端；

所述服务端，用于接收所述资源变动消息，并基于所述资源变动消息生成目标存储数据，以及，将所述目标存储数据发送至所述平台数据库；

所述平台数据库，用于存储所述目标存储数据。

10.一种资源信息管理装置，其特征在于，所述装置包括存储器和处理器，所述存储器用于存储计算机程序，当所述计算机程序被所述处理器执行时，实现如权利要求1至8中任一权利要求所述的方法。

Images