CN115145695B

CN115145695B - 资源调度方法、装置、计算机设备和存储介质

Info

Publication number: CN115145695B
Application number: CN202211043991.2A
Authority: CN
Inventors: 周文凯; 郑艳涛; 刘超; 高伟; 范泽添; 周明伟; 俞星; 刘永超; 黄宁; 金昕
Original assignee: Zhejiang Dahua Technology Co Ltd
Current assignee: Zhejiang Dahua Technology Co Ltd
Priority date: 2022-08-30
Filing date: 2022-08-30
Publication date: 2022-12-06
Anticipated expiration: 2042-08-30
Also published as: CN115145695A

Abstract

本申请涉及一种资源调度方法、装置、计算机设备和存储介质，该方法应用于容器云平台，包括：获取Kubernetes集群中各工作节点中生成的CRD资源；响应于接收到的有状态应用的创建请求，基于记录的资源列表，在各工作节点中选择与有状态应用适配的至少一个目标节点；资源列表包括各工作节点的CRD资源、以及已记录的各工作节点已被分配且用于创建POD的资源情况；在至少一个目标节点的资源中，选择与有状态应用适配的目标资源；基于选择出的目标资源，在至少一个目标节点上创建用于承载有状态应用的POD。本申请能将各工作节点的资源情况记录在资源列表中，并基于资源列表进行调度，解决了资源分配与实际创建不一致的问题。

Description

资源调度方法、装置、计算机设备和存储介质

技术领域

本申请涉及云原生技术领域，特别是涉及一种资源调度方法、装置、计算机设备和存储介质。

背景技术

Kubernetes（简称 K8s）是一个开源的容器集群管理系统，能够提供容器编排，资源调度，弹性伸缩，部署管理和服务发现等一系列功能，使容器化应用的部署工作更加简单和高效。调度器（Scheduler）作为云原生K8s架构中的核心组件，其作用是对编排的应用合理分配资源，调度到合适的计算节点。

在K8s集群中可以通过资源配额的方式来管理各个团队或者用户可使用资源的额度，以确保不会使用超过其分配份额的集群资源。由于资源调度是k8s调度器分配节点的过程，在分配各种资源时，没有实现调度资源实时的更新，特别是在一些高并发的情况下，可能存在资源分配与实际创建不一致的问题。

针对相关技术中存在资源分配与实际创建不一致的问题，目前还没有提出有效的解决方案。

发明内容

在本实施例中提供了一种资源调度方法、装置、计算机设备和存储介质，以解决相关技术中存在资源分配与实际创建不一致的问题。

第一个方面，在本实施例中提供了一种资源调度方法，应用于容器云平台，所述容器云平台包括Kubernetes集群；所述集群包括主控节点和若干工作节点，所述主控节点包括扩展调度器；所述资源调度方法适用于所述扩展调度器；所述资源调度方法包括：

获取所述Kubernetes集群中各工作节点中生成的CRD资源；

响应于接收到的有状态应用的创建请求，基于记录的资源列表，在各工作节点中选择与有状态应用适配的至少一个目标节点；所述资源列表包括各工作节点的CRD资源、以及已记录的各工作节点已被分配且用于创建POD的资源情况；

在所述至少一个目标节点的资源中，选择与所述有状态应用适配的目标资源；

基于选择出的目标资源，在所述至少一个目标节点上创建用于承载所述有状态应用的POD。

在其中的一些实施例中，当所述CRD资源为本地磁盘时，每个工作节点上的Agent进程基于该工作节点上的配置文件生成该工作节点上的所述CRD资源；

当所述CRD资源为处理资源时，每个工作节点上的Agent进程获取该工作节点上的处理资源并进行资源转换得到该工作节点上的所述CRD资源。

在其中的一些实施例中，所述响应于接收到的有状态应用的创建请求，基于记录的资源列表，在各工作节点中选择与有状态应用适配的至少一个目标节点，包括：

根据所述创建请求中的存储需求，创建声明所述有状态应用的存储需求的PVC；

基于记录的资源列表，在各工作节点中选择适配所述存储需求的至少一个目标节点。

在其中的一些实施例中，所述PVC包括静态PVC和动态PVC；

所述动态PVC在所述POD创建之后，与所述目标资源进行绑定；

所述静态PVC在List-watch机制监控下创建后，直接与所述目标资源进行绑定。

在其中的一些实施例中，上述方法还包括：

在创建所述POD后，在所述资源列表中，添加并记录用于创建所述POD的所述目标资源。

在其中的一些实施例中，上述方法还包括：

在确定所述目标资源后，锁定所述目标资源。

在其中的一些实施例中，所述目标资源的确定过程包括Prefilter、Filter、Reserve/Unreserve以及Prebind阶段；

通过在所述Filter阶段进行扩展，以实现响应于接收到的有状态应用的创建请求，基于记录的资源列表，在各工作节点中选择与有状态应用适配的至少一个目标节点的步骤；

通过在所述Reserve/Unreserve阶段进行扩展，以实现在所述至少一个目标节点的资源中，选择与所述有状态应用适配的目标资源以及在确定所述目标资源后，锁定所述目标资源的步骤。

第二个方面，在本实施例中提供了一种资源调度装置，应用于容器云平台，所述容器云平台包括Kubernetes集群；所述集群包括主控节点和若干工作节点，所述主控节点包括扩展调度器；所述装置包括：资源上报模块、资源调度模块以及资源分配模块；

所述资源上报模块，用于获取所述Kubernetes集群中各工作节点中生成的CRD资源；

所述资源调度模块，用于响应于接收到的有状态应用的创建请求，基于记录的资源列表，在各工作节点中选择与有状态应用适配的至少一个目标节点；所述资源列表包括各工作节点的CRD资源、以及已记录的各工作节点已被分配且用于创建POD的资源情况；在所述至少一个目标节点的资源中，选择与所述有状态应用适配的目标资源；

所述资源分配模块，用于基于选择出的目标资源，在所述至少一个目标节点上创建用于承载所述有状态应用的POD。

第三个方面，在本实施例中提供了一种计算机设备，包括存储器、处理器以及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述第一个方面所述的资源调度方法。

第四个方面，在本实施例中提供了一种存储介质，其上存储有计算机程序，该程序被处理器执行时实现上述第一个方面所述的资源调度方法。

与相关技术相比，在本实施例中提供的资源调度方法、装置、计算机设备和存储介质，应用于容器云平台，所述容器云平台包括Kubernetes集群；所述集群包括主控节点和若干工作节点，所述主控节点包括扩展调度器；所述资源调度方法适用于所述扩展调度器；所述资源调度方法包括：获取所述Kubernetes集群中各工作节点中生成的CRD资源；响应于接收到的有状态应用的创建请求，基于记录的资源列表，在各工作节点中选择与有状态应用适配的至少一个目标节点；所述资源列表包括各工作节点的CRD资源、以及已记录的各工作节点已被分配且用于创建POD的资源情况；在所述至少一个目标节点的资源中，选择与所述有状态应用适配的目标资源；基于选择出的目标资源，在所述至少一个目标节点上创建用于承载所述有状态应用的POD，能够将各工作节点的资源情况记录在资源列表中，并基于资源列表进行调度，保证每次调度的资源是实时的，在分配的目标节点中创建POD，解决了资源分配与实际创建不一致的问题。

本申请的一个或多个实施例的细节在以下附图和描述中提出，以使本申请的其他特征、目的和优点更加简明易懂。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是一个实施例中资源调度方法的终端的硬件结构框图；

图2是一个实施例中Kubernetes集群的架构示意图；

图3是一个实施例中资源调度方法的流程图；

图4是一个优选实施例中资源调度方法的流程图；

图5是一个实施例中资源调度装置的结构框图。

图中：102、处理器；104、存储器；106、传输设备；108、输入输出设备；10、资源上报模块；20、资源调度模块；30、资源分配模块。

具体实施方式

为更清楚地理解本申请的目的、技术方案和优点，下面结合附图和实施例，对本申请进行了描述和说明。

除另作定义外，本申请所涉及的技术术语或者科学术语应具有本申请所属技术领域具备一般技能的人所理解的一般含义。在本申请中的“一”、“一个”、“一种”、“该”、“这些”等类似的词并不表示数量上的限制，它们可以是单数或者复数。在本申请中所涉及的术语“包括”、“包含”、“具有”及其任何变体，其目的是涵盖不排他的包含；例如，包含一系列步骤或模块（单元）的过程、方法和系统、产品或设备并未限定于列出的步骤或模块（单元），而可包括未列出的步骤或模块（单元），或者可包括这些过程、方法、产品或设备固有的其他步骤或模块（单元）。在本申请中所涉及的“连接”、“相连”、“耦接”等类似的词语并不限定于物理的或机械连接，而可以包括电气连接，无论是直接连接还是间接连接。在本申请中所涉及的“多个”是指两个或两个以上。“和/或”描述关联对象的关联关系，表示可以存在三种关系，例如，“A和/或B”可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。通常情况下，字符“/”表示前后关联的对象是一种“或”的关系。在本申请中所涉及的术语“第一”、“第二”、“第三”等，只是对相似对象进行区分，并不代表针对对象的特定排序。

在本实施例中提供的方法实施例可以在终端、计算机或者类似的运算装置中执行。比如在终端上运行，图1是本实施例的资源调度方法的终端的硬件结构框图。如图1所示，终端可以包括一个或多个（图1中仅示出一个）处理器102和用于存储数据的存储器104，其中，处理器102可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置。上述终端还可以包括用于通信功能的传输设备106以及输入输出设备108。本领域普通技术人员可以理解，图1所示的结构仅为示意，其并不对上述终端的结构造成限制。例如，终端还可包括比图1中所示更多或者更少的组件，或者具有与图1所示出的不同配置。

存储器104可用于存储计算机程序，例如，应用软件的软件程序以及模块，如在本实施例中的资源调度方法对应的计算机程序，处理器102通过运行存储在存储器104内的计算机程序，从而执行各种功能应用以及数据处理，即实现上述的方法。存储器104可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器104可进一步包括相对于处理器102远程设置的存储器，这些远程存储器可以通过网络连接至终端。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

传输设备106用于经由一个网络接收或者发送数据。上述的网络包括终端的通信供应商提供的无线网络。在一个实例中，传输设备106包括一个网络适配器（NetworkInterface Controller，简称为NIC），其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输设备106可以为射频（Radio Frequency，简称为RF）模块，其用于通过无线方式与互联网进行通讯。

容器云平台是依靠容器技术，结合云原生技术，采用容器、容器编排、服务网格，无服务等技术构建的一种轻量化PaaS平台，目标是支撑企业数字化，构建相应的数字云平台。Kubernetes（简称K8s）是一个开源的容器集群管理系统，属于容器云平台，能够提供容器编排，资源调度，弹性伸缩，部署管理和服务发现等一系列功能，使容器化应用的部署工作更加简单和高效。

图2是Kubernetes集群的架构示意图，如图2所示，Kubernetes集群中包括主控节点和工作节点，节点可以是虚拟机或物理机。POD（容器组）是Kubernetes集群中可以创建和管理调度的最小单元，一个POD里面可装载至少一个容器。

工作节点包括Kubelet（主控节点代理程序）、Proxy（网络代理程序）以及Docker（容器引擎），其中Kubelet用于在Node节点上执行主控节点安排的任务，它将每个POD转换成一组容器，用于管理本节点运行容器的生命周期，包括创建容器、POD挂载数据卷、下载Secret、获取容器和节点状态等工作；Proxy用于在Node节点上实现POD网络代理，负责为Service提供Cluster内部的服务发现、网络规划和负载均衡；Docker负责所有具体的映像下载和容器运行。

主控节点中包括API Server（集群统一入口）、Controller Manager（控制器管理程序）以及Scheduler（调度器），其中API Server作为各组件的协调者，提供认证、授权、访问控制、API注册和发现等机制，以RESTful API的方式提供接口服务，所有对象资源的增删改查和监听都由API Server处理后提交给Etcd 存储；Controller Manager负责控制器的管理，控制器和资源一一对应，控制器用于维护集群的状态，包括故障检测、自动扩展、滚动更新等常规后台任务；Scheduler调度器作为云原生K8s集群中的核心组件，其作用是对编排的应用合理分配资源，调度到合适的计算节点。

在K8s集群中可以通过资源配额的方式来管理各个团队或者用户可使用资源的额度，以确保不会使用超过其分配份额的集群资源。由于资源调度是k8s调度器分配工作节点的过程，在分配各种资源时，没有实现调度资源实时的更新，特别是在一些高并发的情况下资源比较紧张，由于缺乏对调度资源的维护，可能存在资源分配与实际创建不一致的问题。

为了解决以上问题，在以下实施例中提供了一种应用于上述容器云平台的资源调度方法，能够将各工作节点的资源情况记录在资源列表中，并基于资源列表进行调度，保证每次调度的资源是实时的，在分配的目标节点中创建POD，解决了资源分配与实际创建不一致的问题。

在本实施例中提供了一种资源调度方法，图3是本实施例中资源调度方法的流程图，如图3所示，该方法包括以下步骤：

步骤S310，获取Kubernetes集群中各工作节点中生成的CRD资源。

具体地，通过在Kubernetes集群中各工作节点部署Agent进程（代理进程）获取各工作节点中相应的CRD资源（CustomResource Definition，用户自定义资源）。Kubernetes主控节点中有原生调度器和扩展调度器，本实施例中方法适用于扩展调度器，扩展调度器可与原生调度器同时运行，主要用于调度工作节点的存储资源，比如本地磁盘资源、CPU处理资源、GPU处理资源等。其中，扩展调度器也会监控各工作节点上的CRD资源，CRD资源是静态的，只保持总大小，不会动态更新实际可用大小。

进一步地，扩展调度器负责将资源的相关属性记录在资源列表中，在部署需要相应可用资源的有状态应用时，基于资源列表中资源情况分配可用的相应资源。比如，在部署需要本地磁盘资源的有状态应用时，会从资源列表中记录的磁盘数据中分配可用的磁盘资源。

步骤S320，响应于接收到的有状态应用的创建请求，基于记录的资源列表，在各工作节点中选择与有状态应用适配的至少一个目标节点；资源列表包括各工作节点的CRD资源、以及已记录的各工作节点已被分配且用于创建POD的资源情况。

具体地，在需要为待调度POD申请可用资源时，用户提交给主控节点API Server的应用类型以有状态应用呈现，有状态应用的创建请求中包括相应的资源存储需求，同时指定了调度需要的PVC（Persistent Volume Claim，持久化卷声明），以通过PVC绑定可用资源，为有状态应用分配可用资源。

根据PVC中声明的存储需求，结合步骤S310中记录的资源列表，在扩展调度器的Filter（过滤）阶段筛选适配有状态应用的至少一个目标节点。其中，资源列表中包括通过上述各工作节点上Agent进程生成的静态CRD资源，以及已记录的工作节点已分配用于创建POD的资源情况，并且为有状态应用创建POD后，用于创建该POD的目标资源也会记录在资源列表中。

步骤S330，在至少一个目标节点的资源中，选择与有状态应用适配的目标资源。

具体地，在扩展调度器的Reserve（预留）阶段，根据步骤S320中筛选得到的至少一个目标节点中，进一步有状态应用对应PVC声明的存储需求，选择目标节点上合适的相应可用资源进行分配，得到与有状态应用适配的目标资源，通常是分配最空闲的资源，以保证资源能够均匀分配。

步骤S340，基于选择出的目标资源，在至少一个目标节点上创建用于承载有状态应用的POD。

具体地，根据选择出的目标资源，通过在目标资源上创建目录，并将目录挂载在POD的容器中，即可利用目标资源在至少一个目标节点中创建承载有状态应用的POD。

上述步骤中的本地磁盘作为存储的一种表现形式，指在本地提供存储服务的磁盘，按照存储介质可划分为固态类和机械类，固态类如固态驱动器（Solid State Drive，SSD），机械类如硬盘驱动器（Hard DiskDrive，HDD），其相对于ceph等远程存储具有高速稳定的特点。然而，Kubernetes原生调度器只关心应用的CPU、内存和GPU等资源的消耗，对本地磁盘的分配使用并不敏感。实际上，对于Mysql、Rabbitmq、Redis等中间件，选择固态类的本地磁盘作为后端存储更加有利于应用的运行。

上述步骤通过扩展调度器，能够将各工作节点的资源情况记录在资源列表中，并基于资源列表进行调度，保证每次调度的资源是实时的，在分配的目标节点中创建POD，解决了资源分配与实际创建不一致的问题。

进一步地，在资源列表中记录并更新被分配用于创建POD的资源情况，无需更新各工作节点上总体的静态的CRD资源，能够提高整体性能，减少更新CRD资源消耗的时间。同时还作为一种具有通用性的资源调度方法，不仅仅适用于本地磁盘资源，同样适用于CPU的NUMA以及GPU等处理资源。

在其中的一些实施例中，在通过Agent进程上报各工作节点的CRD资源中，在Kubernetes集群的各工作节点中部署Agent进程，Agent进程获取对应的可用资源并上报给主控节点的API Server，扩展调度器通过API Server获取各工作节点上的CRD资源。

当CRD资源为本地磁盘时，每个工作节点上的Agent进程基于该工作节点上的配置文件生成该工作节点上的CRD资源。

具体地，用户可以通过生成挂载路径，对一个块设备或者本地磁盘进行挂载，生成相应的文件系统目录，而在kubernetes集群中，有状态应用往往需要一个可用的存储资源，那么文件系统目录可以作为相应POD的挂载点。

Agent进程需通过扫描每个工作节点中的配置文件，并将配置文件转换为kubernetes集群可用的资源，也就是生成CRD资源，该CRD资源需要记录每一个磁盘的信息，例如，磁盘的大小、磁盘的类型（SSD和HDD）、磁盘的可用状态（健康程度）等。

其中，配置文件记录着磁盘的后续使用功能，配置文件具体如下：

[

{

"Disk":[

{

"diskLabel":"3"

}，

{

"diskLabel":"1"

}

]，

"diskTypeName":"LOCALPATH-HDD"

}，

{

"Disk":[

{

"diskLabel":"4"

}，

{

"diskLabel":"2"

}

]，

"diskTypeName":"LVM-HDD"

}

]，

其中Localpath表示本地磁盘、Lvm表示Lvm块设备，每个磁盘都会通过一个唯一的标识进行记录，也就相当于给磁盘打上相应的标签，保证磁盘不会发生变化。

当CRD资源为处理资源时，每个工作节点上的Agent进程获取该工作节点上的处理资源并进行资源转换得到该工作节点上的CRD资源。

具体地，Agent进程可以直接获取相应的CPU和GPU资源，并进行资源转换后进行上报，得到CRD资源。

扩展调度器获取并记录在资源列表中的CRD资源是静态的，只保持磁盘资源或处理资源的总大小，并不会实时更新CRD资源的可用大小。扩展调度器负责将CRD资源保存到调度器的资源列表中，其中也包括CRD资源记录的磁盘和CPU的相关信息，在部署需要本地磁盘或CPU等资源的有状态应用时，会根据资源列表分配可用的资源进行调度。

进一步地，可以将资源列表记录在扩展调度器的缓存中，相比于更新各工作节点上总体的CRD资源，能够减少动态更新的耗时，进而提升整体调度性能。

通过本实施例中在每个工作节点部署Agent进程以实现工作节点可用资源的上报，再通过扩展调度器监控各工作节点的CRD资源，并记录在资源列表中，以在部署需要相应资源的有状态应用时，根据记录的资源列表为有状态应用分配可用的磁盘、CPU或GPU资源。

在其中的一些实施例中，上述响应于接收到的有状态应用的创建请求，基于记录的资源列表，在各工作节点中选择与有状态应用适配的至少一个目标节点，包括以下步骤：

根据创建请求中的存储需求，创建声明有状态应用的存储需求的PVC；

基于记录的资源列表，在各工作节点中选择适配存储需求的至少一个目标节点。

具体地，在需要为待调度POD申请可用资源时，用户提交给API Server的应用类型以有状态应用即Statefulset呈现，有状态应用指定了调度需要的PV（Persistent VolumeClaim，持久化卷声明），即根据有状态应用的创建请求中的存储需求，创建相应的PVC，并且PVC中声明有该存储需求。

其中，PVC的Annotation中包括有以key1：value1形式表达的应用需求，原生PVC中包含有磁盘大小信息，而介质类型可通过原生PVC的StorageClass来指定，在StorageClass中，LOCAL-HDD代表需要HDD磁盘，LOCAL-SSD代表需要SSD磁盘。

在扩展调度器中通过插件扩展Filter阶段，根据资源列表中记录的各工作节点的CRD资源、以及各工作节点已被分配且用于创建POD的资源情况，对每一个PVC声明的存储需求进行计算，从资源列表的CRD资源中筛选出符合条件的工作节点，对于可能会筛选出多个符合条件的结果的情况，再对各工作节点进行评分，筛选出评分最高的节点作为与有状态应用适配的至少一个目标节点。

若将资源列表保存在扩展调度器的缓存中，以CRD资源为本地磁盘为例，从snapshot快照中获取缓存数据，缓存数据具体如下：

type NodeTopologyResource struct {

TopologyResourceInfo *v1.TopologyResourceInfo

Requested map[v1.ResourceType]map[v1.ResourceName]*resource.Quantity

Allocatable map[v1.ResourceType]map[v1.ResourceName]*resource.Quantity

Generation int64

}，

其中，TopologyResourceInfo是CRD资源，可以记录各种数据，这里主要是记录节点上每一块磁盘的挂载路径、大小以及介质等属性信息，Request记录缓存中磁盘资源的使用量情况，Allocatable记录磁盘资源的总量，Generation称为代，目的是为了更新snapshot，保证资源列表中每次调度的可用资源数据是实时的。

进一步地，在扩展调度器通过插件扩展的Reserve阶段，此时已经确定了至少一个目标节点，再进一步为有状态应用分配最合适的目标资源。

以本地磁盘为例，首先需要对目标节点上各磁盘的现有容器按照各容器缓存量进行排序，之后根据排序结果往目标节点中可以正常使用的各个磁盘上调度。调度过程中优先往空闲存储空间大的磁盘上调度容器缓存量小的容器，还需要考虑各个磁盘的均匀分配以及各个磁盘的单磁盘容器数限制，以保证节点上每一块磁盘可分配量方差最小。

最后，基于选择出的目标资源，在适配的至少一个工作节点上相应创建POD。

另外，在创建POD后，在资源列表中，添加并记录用于POD的目标资源，以将每次创建POD后，各工作节点中资源的分配和使用情况更新并记录在资源列表中，以在每次调度有状态应用时，能够根据实时更新的资源列表进行调度，减少延迟造成的分配和创建不一致的情况。

通过本实施例中根据有状态应用声明相应的PVC，以根据PVC的存储需求，结合记录的资源列表为有状态应用筛选和分配目标节点，进一步再选择得到目标资源，以在适配的至少一个工作节点上创建POD，减少分配与创建不一致问题。

在其中的一些实施例中，上述PVC包括静态PVC和动态PVC。

在K8s集群中，PV（PersistentVolume，持久卷）是对集群资源抽象后的表达，管理员通过创建PV提供存储功能。另一方面，用户创建PVC声明所需的存储资源，根据PVC（要求的存储大小和访问模式）来寻找PV，如果寻找到相匹配的PV，则将PVC和PV进行绑定，以实现PVC和资源的绑定，并将资源提供给相应的POD使用。

其中，动态PVC在POD创建之后，与适配的目标资源进行绑定。

在创建动态PVC后，该动态PVC处于未就绪状态，不与目标资源进行绑定，也就是不绑定相匹配的PV。当对应POD创建后，该动态PVC处于就绪状态，与目标资源进行绑定。

其中，静态PVC在List-watch机制监控下创建后，直接与目标资源进行绑定。

静态PVC并不依赖于POD调度，所以理论上调度器无法监控此类PVC的创建。List-watch（资源监听）机制是Kubernetes中的一种异步消息传递方式，通过List-watch机制监控到有静态PVC创建后，则该静态PVC直接与目标资源进行绑定，也就是寻找相匹配的PV进行绑定。

通过本实施例能够兼顾动态PVC和静态PVC的创建，并且将使用的目标资源都记录在资源列表中，以保证可用资源分配的准确性。

在其中的一些实施例中，上述目标资源的确定过程包括Prefilter、Filter、Reserve/Unreserve以及Prebind阶段。

其中，在Prefilter（预过滤）阶段校验PVC状态，在Prebind（预调度）阶段其具体功能与在原生调度器中的功能一致。

Kubernetes集群提供了在不改变原生调度器源码的基础上，通过实现相关插件来开发扩展调度器的方案。

通过在Filter阶段进行扩展，以实现上述实施例中响应于接收到的有状态应用的创建请求，基于记录的资源列表，在各工作节点中选择与有状态应用适配的至少一个目标节点的步骤。

通过在Reserve（预留）/Unreserve（释放预留）阶段进行扩展，以实现上述实施例中在至少一个目标节点的资源中，选择与有状态应用适配的目标资源的步骤。

进一步地，在确定目标资源后，锁定目标资源。

通过锁定目标资源，以在创建POD过程中，该目标资源不会被其他创建请求抢占，具体可以通过为该目标资源进行标记以实现锁定。

进一步地，如果最终在该目标资源中POD创建成功，则清除标记，并将该目标资源更新到资源列表中；如果最终POD创建失败，扩展调度器会调度Unreserve插件对标记的目标资源进行释放，释放预占用的目标资源，以节省存储空间。

通过本实施例中通过Kubernetes调度框架对Filter、Reserve以及Unreserve阶段进行扩展，能够不作侵入式改动，使其能适配以上实施例中本地磁盘、处理资源的调度分配。

下面通过优选实施例对本实施例进行描述和说明。

图4是本优选实施例的资源调度方法的流程图，如图4所示，该方法包括以下步骤：

步骤S410，获取各工作节点中的Agent进程获取对应的可用资源，并转换得到的CRD资源。

步骤S420，将CRD资源和已记录的各工作节点已被分配且用于创建POD的资源情况记录在资源列表中。

步骤S430，响应于接收到的有状态应用的创建请求，创建声明有创建请求中存储需求的PVC。

步骤S440，结合记录的资源列表，在各工作节点中选择适配存储需求的至少一个目标节点。

步骤S450，在至少一个目标节点的资源中，选择与有状态应用适配的目标资源并锁定该目标资源。

步骤S460，基于选择出的目标资源，在至少一个目标节点上创建用于承载有状态应用的POD，并将该目标资源记录在资源列表中。

需要说明的是，在上述流程中或者附图的流程图中示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

在本实施例中还提供了一种资源调度装置，该装置用于实现上述实施例及优选实施方式，已经进行过说明的不再赘述。以下所使用的术语“模块”、“单元”、“子单元”等可以实现预定功能的软件和/或硬件的组合。尽管在以下实施例中所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

图5是本实施例的资源调度装置的结构框图，如图5所示，该装置包括：资源上报模块10、资源调度模块20以及资源分配模块30。

资源上报模块10，用于获取Kubernetes集群中各工作节点中生成的CRD资源。

资源调度模块20，用于响应于接收到的有状态应用的创建请求，基于记录的资源列表，在各工作节点中选择与有状态应用适配的至少一个目标节点；资源列表包括各工作节点的CRD资源、以及已记录的各工作节点已被分配且用于创建POD的资源情况；在至少一个目标节点的资源中，选择与有状态应用适配的目标资源。

资源分配模块30，用于基于选择出的目标资源，在至少一个目标节点上创建用于承载有状态应用的POD。

通过本实施例中提供的装置，在扩展调度器中，能够将各工作节点的资源情况记录在资源列表中，并基于资源列表进行调度，保证每次调度的资源是实时的，在分配的目标节点中创建POD，解决了资源分配与实际创建不一致的问题。

需要说明的是，上述各个模块可以是功能模块也可以是程序模块，既可以通过软件来实现，也可以通过硬件来实现。对于通过硬件来实现的模块而言，上述各个模块可以位于同一处理器中；或者上述各个模块还可以按照任意组合的形式分别位于不同的处理器中。

在本实施例中还提供了一种计算机设备，包括存储器和处理器，该存储器中存储有计算机程序，该处理器被设置为运行计算机程序以执行上述任一项方法实施例中的步骤。

可选地，上述计算机设备还可以包括传输设备以及输入输出设备，其中，该传输设备和上述处理器连接，该输入输出设备和上述处理器连接。

需要说明的是，在本实施例中的具体示例可以参考上述实施例及可选实施方式中所描述的示例，在本实施例中不再赘述。

此外，结合上述实施例中提供的资源调度方法，在本实施例中还可以提供一种存储介质来实现。该存储介质上存储有计算机程序；该计算机程序被处理器执行时实现上述实施例中的任意一种资源调度方法。

应该明白的是，这里描述的具体实施例只是用来解释这个应用，而不是用来对它进行限定。根据本申请提供的实施例，本领域普通技术人员在不进行创造性劳动的情况下得到的所有其它实施例，均属本申请保护范围。

显然，附图只是本申请的一些例子或实施例，对本领域的普通技术人员来说，也可以根据这些附图将本申请适用于其他类似情况，但无需付出创造性劳动。另外，可以理解的是，尽管在此开发过程中所做的工作可能是复杂和漫长的，但是，对于本领域的普通技术人员来说，根据本申请披露的技术内容进行的某些设计、制造或生产等更改仅是常规的技术手段，不应被视为本申请公开的内容不足。

“实施例”一词在本申请中指的是结合实施例描述的具体特征、结构或特性可以包括在本申请的至少一个实施例中。该短语出现在说明书中的各个位置并不一定意味着相同的实施例，也不意味着与其它实施例相互排斥而具有独立性或可供选择。本领域的普通技术人员能够清楚或隐含地理解的是，本申请中描述的实施例在没有冲突的情况下，可以与其它实施例结合。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对专利保护范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请的保护范围应以所附权利要求为准。

Claims

1.一种资源调度方法，其特征在于，应用于容器云平台，所述容器云平台包括Kubernetes集群；所述集群包括主控节点和若干工作节点，所述主控节点包括扩展调度器；所述资源调度方法适用于所述扩展调度器；所述资源调度方法包括：

获取所述Kubernetes集群中各工作节点中生成的本地CRD资源；

响应于接收到的有状态应用的创建请求，基于记录的资源列表，在各工作节点中选择与所述有状态应用适配的至少一个目标节点；所述资源列表包括各工作节点的本地CRD资源、以及已记录的各工作节点已被分配且用于创建POD的资源情况；所述CRD资源是静态的，只保持总大小，不会动态更新实际可用大小；

所述目标资源的确定过程包括Prefilter阶段、Filter阶段、Reserve/Unreserve阶段以及Prebind阶段；

通过在所述Reserve/Unreserve阶段进行扩展，以实现在所述至少一个目标节点的资源中，选择与所述有状态应用适配的目标资源以及在确定所述目标资源后，锁定所述目标资源的步骤；

2.根据权利要求1所述的资源调度方法，其特征在于，当所述CRD资源为本地磁盘时，每个工作节点上的Agent进程基于该工作节点上的配置文件生成该工作节点上的所述CRD资源；

3.根据权利要求1所述的资源调度方法，其特征在于，所述响应于接收到的有状态应用的创建请求，基于记录的资源列表，在各工作节点中选择与有状态应用适配的至少一个目标节点，包括：

4.根据权利要求3所述的资源调度方法，其特征在于，所述PVC包括静态PVC和动态PVC；

所述动态PVC在所述POD创建之后，与所述目标资源进行绑定；

5.根据权利要求1所述的资源调度方法，其特征在于，还包括：

6.一种资源调度装置，其特征在于，应用于容器云平台，所述容器云平台包括Kubernetes集群；所述集群包括主控节点和若干工作节点，所述主控节点包括扩展调度器；所述装置包括：资源上报模块、资源调度模块以及资源分配模块；

所述资源上报模块，用于获取所述Kubernetes集群中各工作节点中生成的本地CRD资源；

所述资源调度模块，用于响应于接收到的有状态应用的创建请求，基于记录的资源列表，在各工作节点中选择与有状态应用适配的至少一个目标节点；所述资源列表包括各工作节点的本地CRD资源、以及已记录的各工作节点已被分配且用于创建POD的资源情况；所述CRD资源是静态的，只保持总大小，不会动态更新实际可用大小；在所述至少一个目标节点的资源中，选择与所述有状态应用适配的目标资源；

7.一种计算机设备，包括存储器和处理器，其特征在于，所述存储器中存储有计算机程序，所述处理器被设置为运行所述计算机程序以执行权利要求1至权利要求5中任一项所述的资源调度方法。

8.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至权利要求5中任一项所述的资源调度方法的步骤。