CN113110938A - 一种资源分配方法、装置、计算机设备及存储介质 - Google Patents

Abstract

本申请实施例公开了一种资源分配方法、装置、计算机设备及存储介质。该方法包括：确定满足当前待调度应用所需资源请求量的目标服务器节点；确定通过设备插件分配的已分配处理资源；根据已分配处理资源确定目标服务器节点的资源分配信息；基于资源分配信息从目标服务器节点的处理资源中确定目标处理资源，并为待调度应用分配目标处理资源。可以保证服务器中的处理资源的隔离以及应用程序的正常运行。

Description

一种资源分配方法、装置、计算机设备及存储介质

技术领域

本申请涉及计算机技术领域，具体涉及一种资源分配方法、装置、计算机设备及存储介质。

背景技术

随着云计算的发展，容器技术得到了普遍应用。基于应用容器引擎(例如Docker)和容器调度平台(例如Kubernetes)的容器云也逐渐成为云平台建设的基座，容器技术能够加速软件的部署。伴随着人工智能技术的大规模落地，将深度学习应用部署在Kubernetes平台上提供服务也逐渐成为一种趋势，深度学习应用往往需要图形处理器(GraphicsProcessing Unit，GPU)资源。

相关技术中，在现有基于Kubernetes的架构下，Kubernetes会根据Deployment(用于管理无状态应用)下的调度单元(例如Pod)申请的GPU数量情况去筛选出GPU节点，当绑定到节点后，相应节点上的设备插件会根据GPU使用情况分配GPU设备，然后由Kubelet(负责维护容器的生命周期)根据设备插件返回的分配信息来创建容器并挂载GPU设备。

在对相关技术的研究和实践中，本申请的发明人发现，现有技术中，由于现有的调度器和设备插件的GPU视图只有一个，当集群中存在多个插件来调度GPU设备时，就可能存在不同GPU应用的Pod分别被不同设备插件分配了同一GPU设备，这样就会使得同一GPU设备上存在多个应用，造成多个应用之间算力和存储资源的竞争，从而影响应用程序的正常运行。

发明内容

本申请实施例提供一种资源分配方法、装置、计算机设备及存储介质，可以保证服务器中的处理资源的隔离以及应用程序的正常运行。

本申请实施例提供了一种资源分配方法，包括：

确定满足当前待调度应用所需资源请求量的目标服务器节点；

确定通过所述设备插件分配的已分配处理资源；

根据所述已分配处理资源确定所述目标服务器节点的资源分配信息；

基于所述资源分配信息从所述目标服务器节点的处理资源中确定目标处理资源，并为所述待调度应用分配所述目标处理资源。

相应的，本申请实施例还提供了一种资源分配装置，包括：

第一确定单元，用于确定满足当前待调度应用所需资源请求量的目标服务器节点；

第二确定单元，用于确定通过所述设备插件分配的已分配处理资源；

第三确定单元，用于根据所述已分配处理资源确定所述目标服务器节点的资源分配信息；

分配单元，用于基于所述资源分配信息从所述目标服务器节点的处理资源中确定目标处理资源，并为所述待调度应用分配所述目标处理资源。

在一些实施例中，第三确定单元包括：

第一获取子单元，用于获取所述目标服务器节点中的处理资源；

第一确定子单元，用于根据所述已分配处理资源，以及所述目标服务器节点中的处理资源，确定所述目标服务器节点中已被分配的处理资源，得到所述资源分配信息。

在一些实施例中，分配单元包括：

第二确定子单元，用于基于所述资源分配信息从所述目标服务器节点的处理资源中确定未分配处理资源；

选取子单元，用于从所述未分配处理资源中选取待调度应用所需资源请求量的处理资源，得到所述目标处理资源。

在一些实施例中，第一确定单元包括：

第三确定子单元，用于确定满足当前待调度应用所需资源请求量的候选服务器节点；

第四确定子单元，用于基于所述待调度应用的应用类型从所述候选服务器节点中确定目标服务器节点。

在一些实施例中，第三确定子单元具体用于：

获取每一服务器节点中处理资源的剩余量；

确定处理资源的剩余量大于或者等于所述资源请求量的服务器节点，得到所述候选服务器节点。

在一些实施例中，第三确定子单元具体还用于：

获取空闲处理资源的剩余存储空间，以及所述待调度应用的申请存储空间，所述空闲处理资源为处理资源的剩余量大于或者等于所述资源请求量的服务器节点中的处理资源；

确定空闲处理资源的剩余存储空间大于或者等于所述申请存储空间的服务器节点，得到所述候选服务器节点。

在一些实施例中，第四确定子单元具体用于：

获取所述应用类型对应的处理资源类型的优先级信息；

根据所述优先级信息从所述候选服务器节点中确定所述目标服务器节点。

在一些实施例中，第四确定子单元具体还用于：

获取所述应用类型对应的处理资源类型的优先级信息；

若所述候选服务器中存在同一优先级别的多个候选服务器节点时，获取所述多个候选服务器节点的负载信息；

根据所述负载信息从所述多个候选服务器节点中选择负载最小的服务器节点，得到所述目标服务器节点。

相应的，本申请实施例还提供了一种计算机设备，包括存储器，处理器及存储在储存器上并可在处理器上运行的计算机程序，其中，处理器执行本申请实施例任一提供的资源分配方法。

相应的，本申请实施例还提供了一种存储介质，存储介质存储有多条指令，指令适于处理器进行加载，以执行如上的资源分配方法。

本申请实施例在确定当前待调度应用对应的目标服务器节点后，在为该待调度应用分配GPU资源时，获取集群中每个设备插件对GPU资源的分配信息，从而得到目标服务器节点中真正空闲的GPU资源，最后将目标服务器节点中的空闲GPU资源分配给待调度应用，避免了多个应用重复占用相同GPU资源、影响程序运行的问题，确保为每一应用合理分配GPU资源，可以保证服务器中的处理资源的隔离以及应用程序的正常运行。

附图说明

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

图1为本申请实施例提供的一种资源分配方法的流程示意图。

图2为本申请实施例提供的一种服务器节点筛选示意图。

图3为本申请实施例提供的一种Kubelet与设备插件的交互过程示意图。

图4为本申请实施例提供的另一种资源分配方法的流程示意图。

图5为本申请实施例提供的一种调度预选阶段的流程示意图。

图6为本申请实施例提供的一种调度优选阶段的流程示意图。

图7为本申请实施例提供的一种处理资源分配的流程示意图。

图8为本申请实施例提供的一种资源分配装置的结构框图。

图9为本申请实施例提供的计算机设备的结构示意图。

具体实施方式

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

本申请实施例提供一种资源分配方法、装置、存储介质及计算机设备。具体地，本申请实施例的资源分配方法可以由计算机设备执行，其中，该计算机设备可以为服务器等设备。服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器。

例如，该计算机设备可以是服务器，该服务器可以确定满足当前待调度应用的资源请求量的目标服务器节点；获取每一设备插件的分配信息，并根据分配信息确定目标服务器节点的资源分配信息，设备插件用于对服务器节点中的处理资源进行分配；根据资源分配信息从目标服务器节点的处理资源中确定目标处理资源，并为待调度应用分配所述目标处理资源。

基于上述问题，本申请实施例提供第一种资源分配方法、装置、计算机设备及存储介质，可以保证服务器中的处理资源的隔离以及应用程序的正常运行。

以下分别进行详细说明。需说明的是，以下实施例的描述顺序不作为对实施例优选顺序的限定。

本申请实施例提供一种资源分配方法，该方法可以由终端或服务器执行，本申请实施例以资源分配方法由服务器执行为例来进行说明。

如图1所示，图1为本申请实施例提供的一种资源分配方法的流程示意图。该资源分配方法的具体流程可以如下：

101、确定满足当前待调度应用所需资源请求量的目标服务器节点。

其中，待调度应用指的是需要部署在资源分配系统上运行的应用。资源分配系统可以为Kubernetes平台，在Kubernetes系统中，应用是与业务相关的概念，比如，一个网页(Web)服务、一个训练任务都可以称为应用，技术上可以用Kubernetes中的Deployment、Statefulset(有状态任务)或Job(批任务)这些资源来描述。

具体的，Kubernetes(常简称为K8S)是用于提供跨主机集群的自动化部署、运行、扩展和管理容器化应用程序的开源系统。Kubernetes的基本调度单元为Pod，Pod是可以创建和管理Kubernetes计算的最小可部署单元。

其中，Pod由一个或者多个容器组成(例如Docker容器)，这多个容器共享容器存储、网络和容器运行配置项。Pod中的容器总是被同时调度，有共同的运行环境。Pod可以通过Deployment创建，在Kubernetes中，Deployment用于统一描述一组Pod的资源类型，包含零到多个Pod副本，这些副本规格在Deployment中定义，在Deployment对象中会写明容器的镜像，容器的版本，容器要部署的数量等信息。

在一些实施例中，由于应用在技术上通常由Kubernetes中的Deployment、Statefulset或Job来定义，而Deployment、Statefulset或Job这些资源又是由Pod组成的，被调度的又是Pod，所以可以理解为Pod就是应用。

其中，资源请求量指的是待调度应用申请的处理器设备数量，比如，当前待调度应用申请的处理器设备数量可以为5，则资源请求量为：5。

其中，服务器节点，也即Node，指的是Kubernetes集群中的服务器节点，Pod在服务器节点上运行。

在一些实施例中，为了提高对服务器节点的筛选效率，步骤“确定满足当前待调度应用所需资源请求量的目标服务器节点”，可以包括以下操作：

确定满足当前待调度应用所需资源请求量的候选服务器节点；

基于待调度应用的应用类型从候选服务器节点中确定目标服务器节点。

其中，候选服务器节点指的是多个服务器节点中，存在空闲处理器设备且满足待调度应用申请的处理器设备数量的服务器节点。

在一些实施例中，为了快速从多个服务器节点中确定候选服务器节点，步骤“确定满足当前待调度应用所需资源请求量的候选服务器节点”，可以包括以下流程：

获取每一服务器节点中处理资源的剩余量；

确定处理资源的剩余量大于或者等于资源请求量的服务器节点，得到候选服务器节点。

其中，处理资源也即服务器节点中的处理器设备，用于对待调度任务进行处理等。比如，处理器设备可以为GPU设备。

具体的，可以对每一服务器节点中处理资源的占用情况进行统计，得到每一服务器节点中处理资源的占用量，再通过计算，可以得到每一服务器节点中处理资源的剩余量。然后，将剩余量与待调度应用的处理资源申请量进行比较，就可以筛选出来满足待调度应用申请条件的候选服务器节点。

例如，服务器节点可以包括：节点1和节点2。节点1中处理资源总量可以为：8，检测到节点2上所有Pod的处理资源的使用量可以为：5，则节点1处理资源的剩余量可以为：3；节点2中处理资源总量可以为：8，检测到节点2上所有Pod的处理资源的使用量可以为：8，则节点2处理资源的剩余量可以为：0。此时，当调度一个资源申请量为2的Pod时，就会筛选出节点1，因为节点2中处理资源的剩余量已经为0，无法满足Pod申请量。

在一些实施例中，为了保证为待调度任务分配到有效的服务器节点，步骤“确定处理资源的剩余量大于或者等于资源请求量的服务器节点，得到候选服务器节点”，可以包括以下操作：

获取空闲处理资源的剩余存储空间，以及待调度应用的申请存储空间；

确定空闲处理资源的剩余存储空间大于或者等于申请存储空间的服务器节点，得到候选服务器节点。

其中，空闲处理资源为处理资源的剩余量大于或者等于所述资源请求量的服务器节点中的处理资源。

其中，在计算机中，物理地址的集合称为物理空间，也称存储空间，即某个存储设备的总容量，如256MB的内存、128MB的U盘、80GB的硬盘等。存储空间可以为内存或者显存，其中，内存(Memory)也被称为内存储器，其作用是用于暂时存放处理器中的运算数据，以及与硬盘等外部存储器交换的数据。计算机中所有程序的运行都是在内存中进行的，因此内存的性能对计算机的影响非常大。只要计算机在运行中，处理器就会把需要运算的数据调到内存中进行运算，当运算完成后处理器再将结果传送出来，内存的运行也决定了计算机的稳定运行。显存，也被叫做帧缓存，它的作用是用来存储显卡芯片处理过或者即将提取的渲染数据。如同计算机的内存一样，显存是用来存储要处理的图形信息的部件。

比如，服务器节点包括：节点1、节点2以及节点3。其中，服务器节点节点1中处理资源的剩余量可以为4、节点2中处理资源的剩余量可以为2，节点3中处理资源的剩余量可以为5，待调度任务所需资源请求量可以为3。可以确定处理资源的剩余量大于或者等于资源请求量的服务器节点为：节点1和节点3。

进一步的，可以确定节点1中存在4个空闲处理资源，节点3中存在5个空闲处理资源，然后获取节点1和节点3中每一空闲处理资源的剩余存储空间，如：节点1的4个空闲处理资源的剩余存储空间分别为：2GB(计算机存储单位)、3GB、2GB、3GB；节点3的5个空闲处理资源的剩余存储空间分别为：5GB、3GB、4GB、3GB，当前待调度应用的申请存储空间可以为3GB，且申请的处理资源的数量为3，则可以确定处理资源的剩余量大于或者等于待调度应用所需资源请求量，且空闲处理资源的剩余存储空间大于或者等于待调度应用申请存储空间的服务器节点为节点3，也即候选服务器节点。

其中，待调度应用的应用类型可以通过不同处理资源类型对该待调度应用的处理优先级进行定义，比如，处理资源类型可以包括GPU处理资源，若通过GPU处理资源对该待调度应用的处理优先级别最高(也即处理效率最快)，则可以确定待调度应用的应用类型为GPU应用类型。

在一些实施例中，为了提高对不同类型应用分配对应的处理资源，步骤“基于待调度应用的应用类型从候选服务器节点中确定目标服务器节点”，可以包括以下操作：

获取所述应用类型对应的处理资源类型的优先级信息；

根据所述优先级信息从所述候选服务器节点中确定所述目标服务器节点。

其中，资源优先级信息指的是应用类型对应的处理资源的优先级别表，比如，应用类型可以为第一应用类型，获取第一应用类型的处理资源类型的优先级信息表：第一类型处理资源>第二类型处理资源，也就是说，当同时存在第一类型处理资源和第二类型处理资源时，会优先为第一应用类型的应用分配第一类型处理资源，当不存在第一类型处理资源时，会为第一应用类型的应用分配第二类型处理资源。

当所述待调度应用的应用类型为第一应用类型时，从所述候选服务器节点中根据第一应用类型的处理资源类型的优先级信息以及候选服务器中的处理资源类型，为待调度应用选取候选服务器节点，得到所述目标服务器节点。

其中，第一应用类型可以包括多种类型，比如，GPU应用类型等。

在本申请实施例中，待调度应用可以为人工智能技术中的深度学习应用，将深度学习应用部署在Kubernetes平台上提供服务时，可以优选选择GPU处理资源对应用进行处理，保证深度学习应用的处理效率。则本申请实施例中，第一应用类型可以为GPU类型。

在一些实施例中，步骤“根据所述优先级信息从所述候选服务器节点中确定所述目标服务器节点”，包括以下操作：

若所述候选服务器中存在同一优先级别的多个候选服务器节点时，获取所述多个候选服务器节点的负载信息；

根据所述负载信息从所述多个候选服务器节点中选择负载最小的服务器节点，得到所述目标服务器节点。

其中，应用类型可以为GPU应用类型，那么GPU应用类型对应的候选服务器节点可以为包括有GPU处理资源的候选服务器节点。

例如，候选服务器节点可以包括：第一候选服务器节点、第二候选服务器节点、第三候选服务器节点以及第四候选服务器节点。其中，第一候选服务器节点中包括GPU处理资源，第二候选服务器节点中不包括GPU处理资源，第三候选服务器节点中包括GPU处理资源，第四候选服务器节点中不包括GPU处理资源，则可以确定第一应用类型也即GPU应用类型对应的候选服务器节点为第一候选服务器节点，第三候选服务器节点。

其中，负载信息指的是服务器节点中的处理资源的占用情况，比如，服务器节点中包括8个处理资源，检测到有5个处理资源正在被使用，则表示该服务器节点的负载信息为：5个处理资源正在被使用。

由于候选服务器节点中的处理资源的数量都是满足待调度应用的处理资源的申请量，那么，为了减小处理器的工作负荷，可以从待调度的应用类型对应的候选服务器节点中选择负载信息最小，也即被使用处理资源数量最少的候选服务器节点，从而可以确定目标服务器节点。

例如，待调度应用的应用类型可以GPU应用类型，候选服务器节点中包括GPU处理资源的候选服务器节点为：第一候选服务器节点和第三候选服务器节点。获取到第一候选服务器节点的负载信息为：5个处理资源被使用，以及第三候选服务器节点的负载信息为：7个处理资源被使用，则可以确定负载最小的候选服务器节点为第一候选服务器节点，则可以确定第一候选服务器节点为目标服务器节点，以使从目标服务器节点的处理资源中为待调度应用分配处理资源。

请参阅图2，图2为本申请实施例提供的一种服务器节点筛选示意图。在图2中，服务器节点可以包括：节点1、节点2、节点3、节点4、节点5、节点6，通过调度预选，将存在空闲处理资源且满足Pod对处理资源请求量的所有服务器节点筛选出来，得到候选服务器节点包括：节点1、节点3、节点4、节点6；进一步的，通过调度优选，对候选服务器节点进行打分，比如，可以根据候选服务器节点的负载信息对候选服务器节点进行打分，按照得分高低对候选服务器节点进行排序，排序后的候选服务器节点为：节点3、节点1、节点4、节点6，最后选择得分最高的候选服务器节点也即节点3，得到目标服务器节点。

102、确定通过设备插件分配的已分配处理资源。

其中，设备插件用于对服务器节点中的处理资源进行分配,设备插件也即DevicePlugin，是Kubernetes提供的一个设备插件框架，用来支持GPU、FPGA(Field-ProgrammableGate Array，现场可编程门阵列)和高性能NIC(network interface controller，网络接口控制器)等第三方设备，只要根据Device Plugin的接口实现一个特定设备的插件，就能实现Kubernetes对设备的管理。

具体的，在Kubernetes系统中，通过Kubelet调用设备插件来为Pod分配处理资源。Kubelet负责维护Pod中容器的生命周期，例如为容器分配设备、启动容器等。

Device plugin实际上是简单的gRPC server，需要实现以下两个方法ListAndWatch和Allocate。其中，ListAndWatch：Kubelet会调用ListAndWatch做设备发现和状态更新(比如设备变得不健康)；

Allocate：当Kubelet创建要使用该设备的容器时，Kubelet会调用Allocate执行设备相应的操作并且通知Kubelet初始化容器所需的设备，卷和环境变量的配置。

请参阅图3，图3为本申请实施例提供的一种Kubelet与设备插件的交互过程示意图。在设备插件启动时，设备插件以gRPC的形式向Kubelet注册，同时提供设备插件的监听Unix Socket，API版本号和设备名称(比如http://nvidia.com/gpu)。Kubelet将会把这些设备暴露到服务器节点状态中，以Extended Resource(扩展的资源)的要求发送到APIserver中，后续调度器会根据这些信息进行调度。

设备插件启动后，Kubelet会建立一个到设备插件的listAndWatch长连接，当设备插件检测到某个设备不健康的时候，就会主动通知Kubelet。此时如果这个设备处于空闲状态，Kubelet就会将其挪出可分配列表；如果该设备已经被某个Pod使用，Kubelet就会将该Pod杀掉。设备插件启动后可以利用Kubelet的socket持续检查Kubelet的状态，如果Kubelet重启，设备插件也会相应的重启，并且重新向Kubelet发起注册。

首先，获取设备插件的分配信息，分配信息包括通过设备插件进行分配的处理资源，比如，通过设备插件A为应用A分配处理资源A，则会在设备插件A的Checkpoint文件中记录：为应用A分配处理资源A，其中，Checkpoint文件保存的就是处理资源的分配信息。

当确定待调度应用的目标服务器节点后，可以根据待调度应用申请的处理资源的逻辑类型，确定待调度应用对应的目标设备插件。在定义待调度应用时，会在Yaml文件中描述该待调度应用申请处理资源的个数，比如“a.com/gpu:1”、“b.com/gpu:2”。

其中，a.com/gpu，b.com/gpu分别表示不同逻辑类型的处理资源，不同逻辑类型的处理资源可以通过不同的设备插件为其进行分配。

例如，PodA申请“a.com/gpu:2”，表示PodA申请2张a.com/gpu类型的GPU处理资源；PodB申请“b.com/gpu:3”，表示PodB申请3张b.com/gpu类型的GPU处理资源。a.com/gpu类型对应的设备插件可以为插件A，b.com/gpu对应的设备插件可以为插件B，则可以通过插件A为PodA分配2张a.com/gpu类型的GPU处理资源，通过插件B为PodB分配3张b.com/gpu类型的GPU处理资源。

103、根据已分配处理资源确定目标服务器节点的资源分配信息。

在一些实施例中，为了得到目标服务器节点准确的资源分配信息，步骤“根据已分配处理资源确定目标服务器节点的资源分配信息”，可以包括以下操作：

获取目标服务器节点中的处理资源；

根据已分配处理资源，以及目标服务器节点中的处理资源，确定目标服务器节点中已被分配的处理资源，得到资源分配信息。

由于每个设备插件的checkpoint文件中记录的是该设备插件分配的处理资源。比如，在服务器节点中，设备插件可以包括插件A，插件B和插件C，插件A的分配信息包括：为应用A分配处理资源A；插件B的分配信息包括：为应用B分配处理资源B；插件C的分配信息包括：为应用C分配处理资源C，各个插件之间互相隔离，信息不互通，使得通过某个设备插件为应用分配处理资源时，可能会将其他设备插件已分配的处理资源重复分配给该应用，影响应用的正常运行。

因此，本申请方案中，在通过设备插件为待调度应用分配处理资源之前，会先获取各个设备插件的分配信息，对所有插件的分配信息进行整合，得到服务器节点中所有已被分配的处理资源，也即已被分配处理资源。

进一步的，将目标服务器节点中的处理资源与已被分配处理资源进行比较，判断已被分配处理资源中是否存在目标服务器节点中的处理资源。若已被分配处理资源中存在目标服务器节点中的处理资源，则可以确定目标服务器中已被分配的处理资源，得到目标服务器节点的资源分配信息。

例如，从各个设备插件的分配信息中可以确定已被分配处理资源包括：第一处理资源，第二处理资源，第三处理资源和第四处理资源，目标服务器节点中包括：第一处理资源，第二处理资源，第三处理资源、第四处理资源，第五处理资源和第六处理资源。则可以确定目标服务器节点中的已被分配处理资源为第一处理资源，第二处理资源，第三处理资源和第四处理资源，得到目标服务器节点的资源分配信息。

104、根据资源分配信息从目标服务器节点的处理资源中确定目标处理资源，并为待调度应用分配目标处理资源。

在一些实施例中，为了提高对待调度应用的处理效率，步骤“基于所述资源分配信息从所述目标服务器节点的处理资源中确定目标处理资源”，可以包括以下操作：

基于所述资源分配信息从所述目标服务器节点的处理资源中确定未分配处理资源；

从所述未分配处理资源中选取待调度应用所需资源请求量的处理资源，得到所述目标处理资源。

例如，目标服务器节点中处理资源包括：第四处理资源，第五处理资源和第六处理资源；目标服务器节点的资源分配信息包括：已分配处理资源为第四处理资源，则可以确定未被分配的处理资源为第五处理资源和第六处理资源，也即候选处理资源，然后从候选处理资源中为待调度应用分配目标处理资源。

在一些实施例中，为了提高应用处理效率，步骤“从候选处理资源中选取待调度应用对应资源请求量的处理资源”，可以包括以下操作：

获取每一候选处理资源的剩余存储空间；

根据剩余存储空间大小对候选处理资源进行排序，得到排序后候选处理资源；

获取待调度应用的申请存储空间；

确定大于申请存储空间且与申请存储空间差值最小的剩余存储空间对应的候选处理资源；

在排序后候选处理资源中，从候选处理资源依次获取所述资源请求量的候选处理资源。

例如，候选处理资源可以包括第一候选处理资源，第二候选处理资源、第三候选处理资源和第四候选处理资源。获取到第一候选处理资源的剩余存储空间为2GB(Gigabyte，千兆字节，计算机的一种存储单位)，第二候选处理资源的剩余存储空间为6GB、第三候选处理资源的剩余存储空间为4GB，第四候选处理资源的剩余存储空间为5GB。

进一步的，根据候选处理资源的剩余存储空间大小，对所有候选处理资源进行排序，按照由大到小的顺序进行排序，得到排序后候选处理资源为：第二候选处理资源、第四候选处理资源、第三候选处理资源、第一候选处理资源。

其中，待调度应用的申请存储空间指的是运行该待调度应用需要的存储空间大小，比如，待调度应用的申请存储空间可以为3GB。

进一步的，从候选处理资源中选择剩余存储空间大于待调度应用的申请存储空间且与待调度应用的申请存储空间的差值最小的候选处理资源，为第三候选处理资源，然后，从排序后候选处理资源中从第三候选处理资源开始依次选取待调度应用的资源请求量的候选处理资源。

例如，待调度应用的资源请求量可以为2，排序后候选处理资源为：第二候选处理资源、第四候选处理资源、第三候选处理资源、第一候选处理资源，其中，剩余存储空间大于待调度应用的申请存储空间且与待调度应用的申请存储空间的差值最小的候选处理资源为第三候选处理资源，则从第三候选处理资源开始，依次选择第三候选处理资源，第四候选处理资源，得到目标处理资源。

通过上述确定目标处理资源的方式，可以为待调度应用分配到合适的处理资源，在满足对待调度应用正常处理的情况下，节省其他剩余存储空间更大的处理资源，为后续需要更大申请存储空间的应用节省处理资源。

在一些实施例中，在步骤“为所述待调度应用分配所述目标处理资源”之后，还可以包括以下步骤：

更新目标服务器节点的资源分配信息；

基于更新资源分配信息后的目标服务器节点为下一个待调度应用分配处理资源。

比如，目标服务器节点中已被分配的处理资源包括：第一处理资源和第二处理资源，当前为待调度应用分配了目标服务器节点中的第三处理资源和第四处理资源，则对目标服务器节点的分配信息进行更新，得到更新后的资源分配信息为：已被分配处理资源包括第一处理资源、第二处理资源、第三处理资源和第四处理资源。

进一步的，将更新后的资源分配信息进行存储，当为下一个待调度应用分配该目标服务器节点的处理资源时，可以根据该目标服务器节点更新后的处理资源进行处理资源的分配，节省时间。

本申请实施例公开了一种资源分配方法，该方法包括：确定满足当前待调度应用所需资源请求量的目标服务器节点；确定通过设备插件分配的已分配处理资源；根据已分配处理资源确定目标服务器节点的资源分配信息；基于资源分配信息从目标服务器节点的处理资源中确定目标处理资源，并为待调度应用分配目标处理资源。本申请实施例在确定当前待调度应用对应的目标服务器节点后，在为该待调度应用分配GPU资源时，获取集群中每个设备插件对GPU资源的分配信息，从而得到目标服务器节点中真正空闲的GPU资源，最后将目标服务器节点中的空闲GPU资源分配给待调度应用，避免了多个应用重复占用相同GPU资源、影响程序运行的问题，确保为每一应用合理分配GPU资源，可以保证服务器中的处理资源的隔离以及应用程序的正常运行。

根据上述介绍的内容，下面将举例来进一步说明本申请的资源分配方法。请参阅图4，图4为本申请实施例提供的另一种资源分配方法的流程示意图，具体流程可以如下：

201、对服务器节点进行调度预选，得到满足当前应用的资源请求量的候选服务器节点。

在本申请实施例中，资源分配方法可以应用于Kubernetes系统中为申请GPU资源的当前应用分配合适的GPU资源。

当接收到当前应用的资源分配请求时，首先可以对所有服务器节点进行调度预选。具体的，在预选过程中，可以将存在空闲GPU且满足当前应用对GPU资源请求量的所有服务器节点筛选出来,可以记为{节点1，节点2，…节点N}，从而可以得到候选服务器节点。

具体地，对于每个服务器节点，可以统计每一服务器节点上所有应用使用的GPU数量之和。比如，将所有“a.com/gpu”、“b.com/gpu”等GPU使用量之和统计出来，若存在剩余GPU且满足当前应用请求条件的服务器节点，则可以将该服务器节点确定为候选服务器节点。

例如，当前应用请求的GPU资源量可以为6，服务器节点可以包括：节点1、节点2以及节点3；检测到当前节点1的剩余GPU剩余量可以为4，当前节点2的剩余GPU剩余量可以为9，以及当前节点3的剩余GPU剩余量可以为10，则可以确定节点2和节点3为候选服务器节点。

请参阅图5，图5为本申请实施例提供的一种调度预选阶段的流程示意图。

首先，获取所有服务器节点以及待调度Pod，其中，服务器节点可以包括：节点1，节点2，节点3，节点4；待调度Pod也即当前应用。

其中，在预选阶段，调度器根据Scheduler Extender(扩展调度器插件，一种扩展K8S调度器的方式，本质上是一个Web服务，可以自定义实现调度的预选和优选两个过程)提供的Web服务地址，将当前待调度的Pod和服务器节点列表传递给Scheduler Extender。

当Scheduler Extender接收到调度预选请求后，首先可以判断当前应用是否为GPU应用。具体的，Scheduler Extender可以根据Pod Yaml(是一种标记语言，可读性高，实质上是一种通用的数据串行化格式)文件中的资源字段名，如果存在如“a.com/gpu:2”、“b.com/gpu:1”等字段，则为GPU应用，否则为非GPU应用。

比如，若判定当前应用为非GPU应用，则Scheduler Extender可以不进行任何处理，直接将原参数的服务器节点列表返回。

或者，若判定当前应用为GPU应用，则Scheduler Extender需要遍历参数中的服务器节点列表，判断每个服务器节点是否为GPU节点，GPU节点指的是具有GPU设备的服务器节点。若检测出服务器节点不是GPU节点，则可以将该服务器节点直接淘汰掉；若检测出服务器节点为GPU节点，则可以统计该服务器节点上所有运行的Pod使用的GPU资源量，即PodYaml中形如“a.com/gpu:1”、“b.com/gpu：2”的GPU使用量之和，从而可以计算、过滤出存在空闲GPU且满足Pod对GPU资源申请量的节点，得到候选服务器节点，比如，候选服务器节点可以为：节点1，节点2，节点3。之后，可以将候选服务器节点返回至调度器。

202、对候选服务器节点进行调度优选，从候选服务器节点中确定目标服务器节点。

其中，调度优选优指的是对经过调度预选过滤后的候选服务器节点进行打分，进而筛选出得分最高的候选服务器节点，从而可以得到目标服务器节点，也即当前应用绑定的节点。

具体的，在本申请实施例中，可以通过当前应用的应用类型来为候选服务器节点进行打分。其中，应用类型可以包括GPU应用等，GPU应用指的是使用GPU资源的应用。

若当前应用为GPU应用，则可以为GPU节点打分相同。若当前应用为非GPU应用，则会将非GPU节点打高分，将GPU节点打低分，使得GPU节点尽可能多的调度GPU应用，将非GPU应用调度到没有GPU的其它节点上，加快GPU应用的运行处理效率，可以提高GPU资源利用率。

请参阅图6，图6为本申请实施例提供的一种调度优选阶段的流程示意图。

首先，获取经过预选阶段筛选得到的候选服务器节点，以及待调度Pod，其中，候选服务器节点可以包括：节点1，节点2，…节点N；待调度Pod也即当前应用。

其中，在优选阶段，调度器根据配置的Scheduler Extender的Web服务地址，将预选阶段过滤后的节点列表传递给Scheduler Extender。当Scheduler Extender接收到请求后，首先判断当前应用是否为GPU应用，方法是根据Pod Yaml文件中的资源字段名，如果存在如“a.com/gpu:2”、“b.com/gpu:1”等字段，则为GPU应用，否则为非GPU应用。

具体的，若当前应用为非GPU应用，则Scheduler Extender将CPU节点打高分，即优先调度到CPU节点上。CPU节点指的是不具有GPU设备的服务器节点。

若当前应用为GPU应用，则Scheduler Extender将GPU节点打高分，即优先调度到GPU节点上。

例如，对于非GPU应用，也就是没有申请GPU的Pod，比如只申请CPU和内存，若经过预选后筛选出来的节点既有GPU节点，也有非GPU节点，那么我们可以将非GPU节点分数给1，将GPU节点分数给0，这样可以尽量把GPU节点留给GPU应用。因为如果非GPU应用都调度到GPU节点把节点上的CPU、内存资源都占满了，即便该节点还有空闲的GPU，后面的GPU应用也无法调度到该GPU节点了，因为Pod的CPU、内存和GPU资源申请量必须同时都要满足才行。

203、通过目标服务器节点为当前应用分配GPU。

当Pod绑定到目标服务器节点后，对于不同类型的GPU应用，Kubelet会调用不同的Device Plugin来为Pod分配空闲的GPU。

例如，“a.com/gpu”对应“Device Plugin A”，“b.com/gpu”对应“Device PluginB”，那么当Pod申请“a.com/gpu:1”时，Kubelet就会调用Device Plugin A给Pod分配1张GPU；当Pod申请“b.com/gpu:2”时，Kubelet就会调用Device Plugin B给Pod分配2张GPU。并将分配信息写入各自的Checkpoint文件中。

请参阅图7，图7为本申请实施例提供的一种处理资源分配的流程示意图。

首先，Kubelet调用Device Plugin的Allocate接口，并传入Kubelet分配给容器的GPU ID列表。

当Device Plugin收到资源分配请求后，分别读取Kubelet和Device Plugin的Checkpoint文件内容，对获取到的所有分配信息进行合并，得到当前目标服务器节点的真实分配信息devsUsage。

进一步的，从devsUsage中判断Kubelet分配的GPU ID(GPU编号)是否已被分配。若该GPU ID对应的GPU设备未被分配，则将该GPU设备分配给当前当前Pod中的容器；若该GPUID对应的GPU设备已被分配，则根据真实分配信息devsUsage确定目标服务器节点未被分配的所有GPU设备，从所有未被分配的GPU中筛选数量满足当前应用的资源申请量的空闲GPU设备。为当前应用分配GPU设备。

最后，将本次分配信息更新到Device Plugin的Checkpoint文件中。比如，将具体的分配信息如环境变量、GPU挂载点、注解等返回给Kubelet。

本申请实施例公开了一种资源分配方法，该方法包括：对服务器节点进行调度预选，得到满足当前应用的资源请求量的候选服务器节点，对候选服务器节点进行调度优选，从候选服务器节点中确定目标服务器节点，通过目标服务器节点为当前应用分配GPU。本申请实施例通过在Pod调度阶段和分配GPU阶段自定义GPU设备的调度方法，可以支持Kubernetes集群下多插件管理GPU设备的场景，避免了应用重复占用相同GPU设备、影响程序运行的问题，实现了不同设备插件之间对GPU资源使用状况的相互感知，确保应用的正常运行处理。

为便于更好的实施本申请实施例提供的资源分配方法，本申请实施例还提供一种基于上述资源分配方法的资源分配装置。其中名词的含义与上述资源分配方法中相同，具体实现细节可以参考方法实施例中的说明。

请参阅图8，图8为本申请实施例提供的一种资源分配装置的结构框图，该装置包括：

第一确定单元301，用于确定满足当前待调度应用所需资源请求量的目标服务器节点；

第二确定单元302，用于确定通过所述设备插件分配的已分配处理资源；

第三确定单元303，用于根据所述已分配处理资源确定所述目标服务器节点的资源分配信息；

分配单元304，用于基于所述资源分配信息从所述目标服务器节点的处理资源中确定目标处理资源，并为所述待调度应用分配所述目标处理资源。

在一些实施例中，第三确定单元303可以包括：

第一获取子单元，用于获取所述目标服务器节点中的处理资源；

第一确定子单元，用于根据所述已分配处理资源，以及所述目标服务器节点中的处理资源，确定所述目标服务器节点中已被分配的处理资源，得到所述资源分配信息。

在一些实施例中，分配单元304可以包括：

第二确定子单元，用于基于所述资源分配信息从所述目标服务器节点的处理资源中确定未分配处理资源；

选取子单元，用于从所述未分配处理资源中选取待调度应用所需资源请求量的处理资源，得到所述目标处理资源。

在一些实施例中，第一确定单元301可以包括：

第三确定子单元，用于确定满足当前待调度应用所需资源请求量的候选服务器节点；

第四确定子单元，用于基于所述待调度应用的应用类型从所述候选服务器节点中确定目标服务器节点。

在一些实施例中，第三确定子单元具体可以用于：

获取每一服务器节点中处理资源的剩余量；

确定处理资源的剩余量大于或者等于所述资源请求量的服务器节点，得到所述候选服务器节点。

在一些实施例中，第三确定子单元具体还可以用于：

获取空闲处理资源的剩余存储空间，以及所述待调度应用的申请存储空间，所述空闲处理资源为处理资源的剩余量大于或者等于所述资源请求量的服务器节点中的处理资源；

确定空闲处理资源的剩余存储空间大于或者等于所述申请存储空间的服务器节点，得到所述候选服务器节点。

在一些实施例中，第四确定子单元具体可以用于：

获取所述应用类型对应的处理资源类型的优先级信息；

根据所述处理资源类型的优先级

信息从所述候选服务器节点中确定所述目标服务器节点。

在一些实施例中，第四确定子单元具体还可以用于：

获取所述应用类型对应的处理资源类型的优先级信息；

若所述候选服务器中存在同一优先级别的多个候选服务器节点时，获取所述多个候选服务器节点的负载信息；

根据所述负载信息从所述多个候选服务器节点中选择负载最小的服务器节点，得到所述目标服务器节点。

本申请实施例公开了一种资源分配装置，通过第一确定单元301确定满足当前待调度应用所需资源请求量的目标服务器节点，第二确定单元302确定通过设备插件分配的已分配处理资源，第三确定单元303根据已分配处理资源确定目标服务器节点的资源分配信息，分配单元304基于资源分配信息从目标服务器节点的处理资源中确定目标处理资源，并为待调度应用分配目标处理资源。以此，可以提高服务器中的处理资源的分配效率。

相应的，本申请实施例还提供一种计算机设备，该计算机设备可以为服务器。如图9所示，图9为本申请实施例提供的计算机设备的结构示意图。该计算机设备400包括有一个或者一个以上处理核心的处理器401、有一个或一个以上计算机可读存储介质的存储器402及存储在存储器402上并可在处理器上运行的计算机程序。其中，处理器401与存储器402电性连接。本领域技术人员可以理解，图中示出的计算机设备结构并不构成对计算机设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

处理器401是计算机设备400的控制中心，利用各种接口和线路连接整个计算机设备400的各个部分，通过运行或加载存储在存储器402内的软件程序和/或模块，以及调用存储在存储器402内的数据，执行计算机设备400的各种功能和处理数据，从而对计算机设备400进行整体监控。

在本申请实施例中，计算机设备400中的处理器401会按照如下的步骤，将一个或一个以上的应用程序的进程对应的指令加载到存储器402中，并由处理器401来运行存储在存储器402中的应用程序，从而实现各种功能：

确定满足当前待调度应用的资源请求量的目标服务器节点；获取每一设备插件的分配信息，并根据分配信息确定目标服务器节点的资源分配信息，设备插件用于对服务器节点中的处理资源进行分配；根据资源分配信息从目标服务器节点的处理资源中确定目标处理资源，并为待调度应用分配所述目标处理资源。

以上各个操作的具体实施可参见前面的实施例，在此不再赘述。

可选的，如图9所示，计算机设备400还包括：触控显示屏403、射频电路404、音频电路405、输入单元406以及电源407。其中，处理器401分别与触控显示屏403、射频电路404、音频电路405、输入单元406以及电源407电性连接。本领域技术人员可以理解，图9中示出的计算机设备结构并不构成对计算机设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

触控显示屏403可用于显示图形用户界面以及接收用户作用于图形用户界面产生的操作指令。触控显示屏403可以包括显示面板和触控面板。其中，显示面板可用于显示由用户输入的信息或提供给用户的信息以及计算机设备的各种图形用户接口，这些图形用户接口可以由图形、文本、图标、视频和其任意组合来构成。可选的，可以采用液晶显示器(LCD，Liquid Crystal Display)、有机发光二极管(OLED，Organic Light-EmittingDiode)等形式来配置显示面板。触控面板可用于收集用户在其上或附近的触摸操作(比如用户使用手指、触笔等任何适合的物体或附件在触控面板上或在触控面板附近的操作)，并生成相应的操作指令，且操作指令执行对应程序。可选的，触控面板可包括触摸检测装置和触摸控制器两个部分。其中，触摸检测装置检测用户的触摸方位，并检测触摸操作带来的信号，将信号传送给触摸控制器；触摸控制器从触摸检测装置上接收触摸信息，并将它转换成触点坐标，再送给处理器401，并能接收处理器401发来的命令并加以执行。触控面板可覆盖显示面板，当触控面板检测到在其上或附近的触摸操作后，传送给处理器401以确定触摸事件的类型，随后处理器401根据触摸事件的类型在显示面板上提供相应的视觉输出。在本申请实施例中，可以将触控面板与显示面板集成到触控显示屏403而实现输入和输出功能。但是在某些实施例中，触控面板与触控面板可以作为两个独立的部件来实现输入和输出功能。即触控显示屏403也可以作为输入单元406的一部分实现输入功能。

在本申请实施例中，通过处理器401执行游戏应用程序在触控显示屏403上生成图形用户界面，图形用户界面上的虚拟场景中包含至少一个技能控制区域，技能控制区域中包含至少一个技能控件。该触控显示屏403用于呈现图形用户界面以及接收用户作用于图形用户界面产生的操作指令。

射频电路404可用于收发射频信号，以通过无线通信与网络设备或其他计算机设备建立无线通讯，与网络设备或其他计算机设备之间收发信号。

音频电路405可以用于通过扬声器、传声器提供用户与计算机设备之间的音频接口。音频电路405可将接收到的音频数据转换后的电信号，传输到扬声器，由扬声器转换为声音信号输出；另一方面，传声器将收集的声音信号转换为电信号，由音频电路405接收后转换为音频数据，再将音频数据输出处理器401处理后，经射频电路404以发送给比如另一计算机设备，或者将音频数据输出至存储器402以便进一步处理。音频电路405还可能包括耳塞插孔，以提供外设耳机与计算机设备的通信。

输入单元406可用于接收输入的数字、字符信息或用户特征信息(例如指纹、虹膜、面部信息等)，以及产生与用户设置以及功能控制有关的键盘、鼠标、操作杆、光学或者轨迹球信号输入。

电源407用于给计算机设备400的各个部件供电。可选的，电源407可以通过电源管理系统与处理器401逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。电源407还可以包括一个或一个以上的直流或交流电源、再充电系统、电源故障检测电路、电源转换器或者逆变器、电源状态指示器等任意组件。

尽管图9中未示出，计算机设备400还可以包括摄像头、传感器、无线保真模块、蓝牙模块等，在此不再赘述。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

由上可知，本实施例提供的计算机设备，通过确定满足当前待调度应用所需资源请求量的目标服务器节点；确定通过设备插件分配的已分配处理资源；根据已分配处理资源确定目标服务器节点的资源分配信息；基于资源分配信息从目标服务器节点的处理资源中确定目标处理资源，并为待调度应用分配目标处理资源。可以保证服务器中的处理资源的隔离以及应用程序的正常运行。

本领域普通技术人员可以理解，上述实施例的各种方法中的全部或部分步骤可以通过指令来完成，或通过指令控制相关的硬件来完成，该指令可以存储于一计算机可读存储介质中，并由处理器进行加载和执行。

为此，本申请实施例提供一种计算机可读存储介质，其中存储有多条计算机程序，该计算机程序能够被处理器进行加载，以执行本申请实施例所提供的任一种资源分配方法中的步骤。例如，该计算机程序可以执行如下步骤：

确定满足当前待调度应用所需资源请求量的目标服务器节点；

确定通过设备插件分配的已分配处理资源；

根据已分配处理资源确定目标服务器节点的资源分配信息；

基于资源分配信息从目标服务器节点的处理资源中确定目标处理资源，并为待调度应用分配目标处理资源。

以上各个操作的具体实施可参见前面的实施例，在此不再赘述。

其中，该存储介质可以包括：只读存储器(ROM，Read Only Memory)、随机存取记忆体(RAM，Random Access Memory)、磁盘或光盘等。

由于该存储介质中所存储的计算机程序，可以执行本申请实施例所提供的任一种资源分配方法中的步骤，因此，可以实现本申请实施例所提供的任一种资源分配方法所能实现的有益效果，详见前面的实施例，在此不再赘述。

以上对本申请实施例所提供的一种资源分配方法、装置、存储介质及计算机设备进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (11)

1.一种资源分配方法，应用于资源分配系统，其特征在于，所述资源分配系统包括多个服务器节点和多个设备插件，所述设备插件用于对所述服务器节点中的处理资源进行分配，所述方法包括：

确定满足当前待调度应用所需资源请求量的目标服务器节点；

确定通过所述设备插件分配的已分配处理资源；

根据所述已分配处理资源确定所述目标服务器节点的资源分配信息；

基于所述资源分配信息从所述目标服务器节点的处理资源中确定目标处理资源，并为所述待调度应用分配所述目标处理资源。

2.根据权利要求1所述的方法，其特征在于，所述根据所述已分配处理资源确定所述目标服务器节点的资源分配信息，包括：

获取所述目标服务器节点中的处理资源；

根据所述已分配处理资源，以及所述目标服务器节点中的处理资源，确定所述目标服务器节点中已被分配的处理资源，得到所述资源分配信息。

3.根据权利要求1或2所述的方法，其特征在于，所述基于所述资源分配信息从所述目标服务器节点的处理资源中确定目标处理资源，包括：

基于所述资源分配信息从所述目标服务器节点的处理资源中确定未分配处理资源；

从所述未分配处理资源中选取待调度应用所需资源请求量的处理资源，得到所述目标处理资源。

4.根据权利要求1所述的方法，其特征在于，所述确定满足当前待调度应用所需资源请求量的目标服务器节点，包括：

确定满足当前待调度应用所需资源请求量的候选服务器节点；

基于所述待调度应用的应用类型从所述候选服务器节点中确定目标服务器节点。

5.根据权利要求4所述的方法，其特征在于，所述确定满足当前待调度应用所需资源请求量的候选服务器节点，包括：

获取每一服务器节点中处理资源的剩余量；

确定处理资源的剩余量大于或者等于所述资源请求量的服务器节点，得到所述候选服务器节点。

6.根据权利要求5所述的方法，其特征在于，所述确定处理资源的剩余量大于或者等于所述资源请求量的服务器节点，得到所述候选服务器节点，包括：

获取空闲处理资源的剩余存储空间，以及所述待调度应用的申请存储空间，所述空闲处理资源为处理资源的剩余量大于或者等于所述资源请求量的服务器节点中的处理资源；

确定空闲处理资源的剩余存储空间大于或者等于所述申请存储空间的服务器节点，得到所述候选服务器节点。

7.根据权利要求4所述的方法，其特征在于，所述基于所述待调度应用的应用类型从候选服务器节点中确定目标服务器节点，包括：

获取所述应用类型对应的处理资源类型的优先级信息；

根据所述优先级信息从所述候选服务器节点中确定所述目标服务器节点。

8.根据权利要求7所述的方法，其特征在于，所述根据所述优先级信息从所述候选服务器节点中确定所述目标服务器节点，包括：

若所述候选服务器中存在同一优先级别的多个候选服务器节点时，获取所述多个候选服务器节点的负载信息；

根据所述负载信息从所述多个候选服务器节点中选择负载最小的服务器节点，得到所述目标服务器节点。

9.一种资源分配装置，其特征在于，所述装置包括：

第一确定单元，用于确定满足当前待调度应用所需资源请求量的目标服务器节点；

第二确定单元，用于确定通过所述设备插件分配的已分配处理资源；

第三确定单元，用于根据所述已分配处理资源确定所述目标服务器节点的资源分配信息；

分配单元，用于基于所述资源分配信息从所述目标服务器节点的处理资源中确定目标处理资源，并为所述待调度应用分配所述目标处理资源。

10.一种计算机设备，包括存储器，处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述程序时实现如权利要求1至8任一项所述的资源分配方法。

11.一种存储介质，其特征在于，所述存储介质存储有多条指令，所述指令适于处理器进行加载，以执行权利要求1至8任一项所述的资源分配方法。

Images