CN110597623A - 容器资源分配方法、装置、计算机设备和存储介质 - Google Patents

Abstract

本申请涉及一种容器资源分配方法、装置、计算机设备和存储介质。该方法包括：获取业务系统的资源需求信息；业务系统包括多个目标应用；根据资源需求信息分配每个目标应用需要的容器资源；调用容器集群管理接口将分配的容器资源配置为系统集群；系统集群包括多个子系统集群；将不同目标应用部署在不同子系统集群中；监控是否存在一个子系统集群的运行负载超过阈值；若是，从运行负载小于阈值的子系统集群中分割容器资源，将分割的容器资源合并至运行负载超过阈值的子系统集群中，并将运行负载超过阈值的子系统集群中运行的任务调度至合并后的容器资源中继续执行。采用本方法能够减少资源浪费。

Description

容器资源分配方法、装置、计算机设备和存储介质

技术领域

本申请涉及计算机技术领域，特别是涉及一种容器资源分配方法、装置、计算机设备和存储介质。

背景技术

对于系统平台的部署，需要预先对系统平台的性能进行评估，以确定需要分配的物理资源配额。而传统方式中，人工在对待部署的系统平台进行主观粗略评估后，即确定需要分配的物理资源配额。为了避免物理资源不足对系统平台性能造成影响，常常会在初始评估的物理资源配额基础上额外分配一些物理资源，对于单一系统平台可以按照如此方式进行物理资源分配。随着待部署系统平台数量增加，势必会造成大规模的资源浪费。

发明内容

基于此，有必要针对上述技术问题，提供一种能够减少资源浪费的容器资源分配方法、装置、计算机设备和存储介质。

一种容器资源分配方法，所述方法包括：获取业务系统的资源需求信息；所述业务系统包括多个目标应用；根据所述资源需求信息分配每个所述目标应用需要的容器资源；调用容器集群管理接口将分配的容器资源配置为系统集群；所述系统集群包括多个子系统集群；将不同所述目标应用部署在不同子系统集群中；监控是否存在一个所述子系统集群的运行负载超过阈值；若是，从所述运行负载小于阈值的子系统集群中分割容器资源，将分割的容器资源合并至所述运行负载超过阈值的子系统集群中，并将所述运行负载超过阈值的子系统集群中运行的任务调度至合并后的容器资源中继续执行。

在一个实施例中，所述资源需求信息包括部署所述目标应用需要的服务项、应用项或数据项；所述根据所述资源需求信息分配每个所述目标应用需要的容器资源，包括：根据所述服务项的数量和类型，确定需要的第一容器的数量及第二容器的数量；根据所述应用项对应应用程序所需要的存储空间，计算所述第一容器所需的存储空间；根据预设的基础存储空间以及所述数据项对应数据所需要的存储空间，计算所述第二容器所需的存储空间。

在一个实施例中，所述将每个所述目标应用部署在相应子系统集群中，包括：获取所述目标应用的代码文件、部署配置信息和节点流转信息；根据所述部署配置信息对相应子系统集群中多个服务节点进行相同配置，使所述多个服务节点向所述目标应用提供相同的运行环境；根据所述节点流转信息对相应子系统集群中多个服务节点进行网络隔离配置，使所述多个服务节点采用不同的网络；基于所述代码文件创建对应的pod实例；根据所述节点流转信息将所述pod实例部署至一个服务节点，向相应节点终端发送验证通知；当接收到所述节点终端根据所述验证通知触发的节点同步请求时，将所述pod实例从当前的服务节点同步至另一个服务节点，返回所述相应节点终端发送验证通知的步骤，直至节点流转结束，完成对所述目标应用的部署。

在一个实施例中，所述将所述pod实例部署至一个服务节点，包括：通过对所述服务节点初始化在每个服务节点上部署容器管理代理；向一个所述服务节点中的容器管理代理发送容器部署请求；使所述容器管理代理根据所述容器部署请求在预设的容器仓库拉取所述pod实例对应的多个容器文件，并基于所述容器文件在相应服务节点进行pod实例部署。

在一个实施例中，所述从所述运行负载小于阈值的子系统集群中分割容器资源，包括：计算所述运行负载超过所述阈值的子系统集群对应的待补充资源配额；计算所述运行负载小于阈值的子系统集群对应的可分享资源配额；比较所述可分享资源配额是否大于或等于所述待补充资源配额；若是，调用容器集群管理接口从所述运行负载小于所述阈值的子系统集群中分割出与所述待补充资源配额相对应的容器资源。

在一个实施例中，所述从所述运行负载小于阈值的子系统集群中分割容器资源，包括：计算所述运行负载超过所述阈值的子系统集群对应的待补充资源配额；若所述运行负载小于阈值的子系统集群有多个，根据所述运行负载确定每个子系统集群对应的分享权重；根据所述分享权重及所述待补充资源配额，计算每个运行负载小于阈值的子系统集群分别对应的待分享资源配额；从每个所述运行负载小于阈值的子系统集群中分割出所述待分享资源配额的容器资源。

一种容器资源分配装置，所述装置包括：第一资源分配模块，用于获取业务系统的资源需求信息；所述业务系统包括多个目标应用；根据所述资源需求信息分配每个所述目标应用需要的容器资源；目标应用部署模块，用于调用容器集群管理接口将分配的容器资源配置为系统集群；所述系统集群包括多个子系统集群；将不同所述目标应用部署在不同子系统集群中；第二资源分配模块，用于监控是否存在一个所述子系统集群的运行负载超过阈值；若是，从所述运行负载小于阈值的子系统集群中分割容器资源，将分割的容器资源合并至所述运行负载超过阈值的子系统集群中，并将所述运行负载超过阈值的子系统集群中运行的任务调度至合并后的容器资源中继续执行。

一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现本申请任意一个实施例中提供的容器资源分配方法的步骤。

一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现本申请任意一个实施例中提供的容器资源分配方法的步骤。

上述容器资源分配方法、装置、计算机设备和存储介质，当接收到业务系统的资源需求信息时，可以根据所述资源需求信息分配每个所述目标应用需要的容器资源；调用容器集群管理接口将分配的容器资源配置为系统集群，可以将不同所述目标应用部署在系统集群中不同子系统集群；通过对每个子系统集群的运行负载进行监控，可以判断运行负载超过阈值；当一个或多个子系统集群的运行负载超过阈值时，可以从所述运行负载小于阈值的子系统集群中分割容器资源给所述运行负载超过阈值的子系统集群；将所述运行负载超过阈值的子系统集群中运行的任务调度至合并后的容器资源，可以保证运行负载小于阈值的子系统集群中任务的执行不受影响。由于动态监测各个子系统集群的运行负载，并基于监测结果弹性调整每个子系统集群拥有的容器资源，在业务系统内部进行容器资源自均衡，实现按需分配，可以减少资源浪费。

附图说明

图1为一个实施例中容器资源分配方法的应用场景图；

图2为一个实施例中容器资源分配方法的流程示意图；

图3为一个实施例中目标应用部署的步骤的流程示意图；

图4为一个实施例中容器资源分配装置的结构框图；

图5为一个实施例中计算机设备的内部结构图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

本申请提供的容器资源分配方法，可以应用于如图1所示的应用环境中。其中，终端102与服务器104通过网络进行通信。其中，终端102可以但不限于是各种个人计算机、笔记本电脑、智能手机、平板电脑和便携式可穿戴设备，服务器104可以用多个服务器组成的服务器集群来实现。终端102上安装了业务系统部署平台。当需要对业务系统进行部署时，用户可以基于终端102上的业务系统部署平台录入业务系统的资源需求信息。终端102将资源需求信息发送至服务器104。服务器104根据资源需求信息计算业务系统中每个目标应用分别需要的容器资源，根据需要的容器资源进行容器资源分配。服务器104调用容器集群管理接口将分配的每个目标应用对应的容器资源配置为一个子系统集群，将需要业务协作的多个目标应用对应的子系统集群配置为业务系统对应的系统集群。服务器104将多个目标应用分别部署在相应子系统集群中，并对目标应用在相应子系统集群的运行负载进行监控。服务器104比较每个子系统集群的运行负载是否超过阈值。若存在至少一个子系统集群的运行负载超过阈值，且存在至少一个子系统集群的运行负载小于阈值，则服务器104从运行负载小于阈值的子系统集群中分割容器资源，将分割的容器资源合并至运行负载超过阈值的子系统集群中，并将运行负载超过阈值的子系统集群中运行的任务调度至合并后的容器资源中继续执行。当全部子系统集群的运行负载超过阈值时，服务器104生成资源预警，将资源预警发送至终端102。上述容器资源分配过程，由于动态监测各个子系统集群的运行负载，并基于监测结果弹性调整每个子系统集群拥有的容器资源，在业务系统内部进行容器资源自均衡，实现按需分配，可以减少资源浪费。

在一个实施例中，如图2所示，提供了一种容器资源分配方法，以该方法应用于图1中的服务器为例进行说明，包括以下步骤：

步骤202，获取业务系统的资源需求信息；业务系统包括多个目标应用。

构成业务系统的多个目标应用交互协作，共同实现某项业务。例如，实现贷款业务的业务系统A包括风控子系统A1、记账子系统A2和账号管理子系统A3。针对要部署的业务系统，预先架构了对应的服务器。该服务器是多个服务器组成的服务器集群，记作物理集群。物理集群可以是基于kubernetes(K8S，容器编排引擎)等构建得到的。物理集群包括管理父节点、多个管理子节点和多个服务节点。

当需要对业务系统进行部署时，用户评估各个目标应用的用户量、流量等初始性能，根据评估结果预测对CPU、内存、带宽等资源的需求信息，可以基于终端上的业务系统部署平台录入业务系统的资源需求信息。终端根据资源需求信息生成系统部署请求，将系统部署请求发送至管理父节点。

步骤204，根据资源需求信息分配每个目标应用需要的容器资源。

步骤206，调用容器集群管理接口将分配的容器资源配置为系统集群；系统集群包括多个子系统集群。

管理父节点根据系统部署请求计算每个目标应用需要的容器资源，并根据需要的容器资源，将具有对应配额的容器资源的一个或多个服务节点配置为相应目标应用对应的子系统集群。管理父节点针对每个子系统集群配置对应的管理子节点。管理子节点用于对相应子系统集群进行资源监控和任务调度等。管理父节点将多个子系统集群配置为业务系统对应的系统集群，并从整体上对系统集群进行资源监控和任务调度等。

步骤208，将不同目标应用部署在不同子系统集群中。

步骤210，监控是否存在一个子系统集群的运行负载超过阈值。

管理父节点在业务系统内部进行容器资源自均衡。具体的，管理父节点按照预设时间频率对每个子系统集群的运行负载进行监控，得到每个子系统集群在多个时间节点的运行负载。管理父节点比较运行负载是否超过阈值。若超过阈值，将对应子系统集群标记为待补充集群；若小于阈值，将对应子系统集群标记为可分享集群。

步骤212，若是，从运行负载小于阈值的子系统集群中分割容器资源，将分割的容器资源合并至运行负载超过阈值的子系统集群中，并将运行负载超过阈值的子系统集群中运行的任务调度至合并后的容器资源中继续执行。

若在某个时间节点，业务集群既包含待补充集群，也包含可分享集群，则管理父节点将从可分享集群中划分部分容器资源至待补充集群中。例如，在前一时间节点，子系统集群A、B和C拥有的容器数量分别为10、15和20；在当前时间节点，监测到子系统集群A、B和C对应的运行负载依次为80％、40％和60％，此时子系统集群A的运行负载已经超过阈值64％，则可以通过配置从子系统集群B中分割2个容器，将分割出来的2个容器合并至子系统集群A中，将子系统集群A中的部分任务通过节点同步到合并得到容器中继续执行。

若在某个时间节点，业务集群仅包含待补充集群，换言之，全部子系统集群的运行负载超过阈值，则生成资源预警，将资源预警发送至终端，使用户根据终端展示资源预警对物理集群进行扩容等。

管理父节点按照上述方式持续监控关注业务系统性能，不断调整容器资源配额。容易理解，除了在业务系统内部进行容器资源自均衡，还可以按照上述方式在多个业务系统之间进行负载均衡处理。

本实施例中，当接收到业务系统的资源需求信息时，可以根据资源需求信息分配每个目标应用需要的容器资源；调用容器集群管理接口将分配的容器资源配置为系统集群，可以将不同目标应用部署在系统集群中不同子系统集群；通过对每个子系统集群的运行负载进行监控，可以判断运行负载超过阈值；当一个或多个子系统集群的运行负载超过阈值时，可以从运行负载小于阈值的子系统集群中分割容器资源给运行负载超过阈值的子系统集群；将运行负载超过阈值的子系统集群中运行的任务调度至合并后的容器资源，可以保证运行负载小于阈值的子系统集群中任务的执行不受影响。由于动态监测各个子系统集群的运行负载，并基于监测结果弹性调整每个子系统集群拥有的容器资源，在业务系统内部进行容器资源自均衡，实现按需分配，可以减少资源浪费。

在一个实施例中，资源需求信息包括部署目标应用需要的服务项、应用项或数据项；根据资源需求信息分配每个目标应用需要的容器资源，包括：根据服务项的数量和类型，确定需要的第一容器的数量及第二容器的数量；根据应用项对应应用程序所需要的存储空间，计算第一容器所需的存储空间；根据预设的基础存储空间以及数据项对应数据所需要的存储空间，计算第二容器所需的存储空间。

资源需求信息包括部署每个目标应用需要的服务项、应用项或数据项。其中，服务项可以是数据库、中间件、DNS(Domain Name System，域名系统)、文件存储系统等，应用项可以是模板应用、线上版本应用或指定版本应用等，数据项可以是用户数据或资产数据等用于不同类型测试的历史数据。

管理父节点根据资源需求信息计算需要的容器资源。具体的，管理父节点获取预先设定的服务项与容器数量的对应关系，根据该对应关系计算部署目标应用需要的容器数量。例如，可以设定每个服务项对应一个容器。服务器根据用户选定的服务项的类型，确定需要的容器的类型。服务项的类型可以是entry、app、redis、mysql等。根据容器类型，可以将容器区分为应用型的第一容器和服务型的第二容器。当服务项的类型为app时，对应容器类型可以是第一容器。对于其他类型的服务项，对应容器类型可以第二容器。管理父节点根据应用项的数量以及每个应用项对应应用程序所需存储空间，计算第一容器需要的存储空间。服务器根据默认配置的基础存储空间以及数据项对应数据所需要的存储空间，确定第二容器需要的存储空间。

本实施例中，用户只需基于部署需求录入对应的资源需求信息，服务器自动将资源需求信息转换为需要分配的容器资源，相比传统人工计算的方式，可以提高资源分配效率。

在一个实施例中，如图3所示，将每个目标应用部署在相应子系统集群中，即目标应用部署的步骤，包括：

步骤302，获取目标应用的代码文件、部署配置信息和节点流转信息。

为了更好的控制目标应用的质量和可靠性，在将应用程序部署至生产环境之前，开发人员及测试人员均会对目标应用进行多种测试。然而在实际操作中，常出现应用程序在测试环节运行良好，但上线发布至生产环境后却出现多种异常的现象。

终端包括第一终端和第二终端。第一终端可以是开发人员对应的终端，第二终端可以是测试人员对应的终端。为了解决上述问题，每个子系统集群对应的管理子节点将相应子系统集群中多个服务节点虚拟的划分为不同的部署环境。具体的，当目标应用的代码文件开发完成时，开发人员可以基于第一终端将目标应用的代码文件上传至代码仓库，并基于K8S Dasboard等用户界面对目标应用的部署配置信息和节点流转信息分别进行配置。其中，部署配置信息包括目标应用对应的容器部署参数，如端口号、volume映射(数据卷映射)等，还包括部署目标应用需要依赖的服务项、应用项及数据项等信息。节点流转信息包含基于物理集群中多个服务节点进行目标应用部署环境的虚拟划分的信息，以及多个服务节点之间进行数据流转的流程信息等。

管理子节点调用预设的代码监控接口，代码监控接口通过调用github指令(版本库格式变更监测)对代码仓库中目标应用对应的代码文件是否发生变更进行监控。

步骤304，根据部署配置信息对相应子系统集群中多个服务节点进行相同配置，使多个服务节点向目标应用提供相同的运行环境。

当监测到目标应用的代码文件发生变更时，管理子节点按照部署配置信息在相应子系统集群中多个服务节点上搭建不同的部署环境。部署环境包括开发环境、测试环境、生成环境等。换言之，管理子节点将子系统集群中多个服务节点虚拟的划分为不同的部署环境。例如，将其中的一个或多个服务节点(记作第一节点)划分为开发环境，将将其中的一个或多个服务节点(记作第二节点)划分为测试环境，将其中的一个或多个服务节点(记作第三节点)划分为生产环境。

步骤306，根据节点流转信息对相应子系统集群中多个服务节点进行网络隔离配置，使多个服务节点采用不同的网络。

管理子节点还根据节点流转信息对被划分为不同部署环境的多个服务节点进行网络配置。不同的服务节点采用不同的网络。例如，被划分为开发环境的服务节点可以采用开发人员对应的网络，被划分为测试环境的服务节点可以采用测试人员对应的网络等。需要说明的是，不同的部署环境除了连接的网络不同，其他配置参数相同，从而可以向目标应用提供相同的运行环境。容易理解，不同部署环境对应的服务节点也可以连接不同的数据库。

步骤308，基于代码文件创建对应的pod实例。

管理子节点启动预设的容器构建脚本，基于容器构建脚本自动对目标应用的代码文件进行代码性能检查以及编译等工作，生成可执行文件，并将可执行文件、及目标应用运行需要依赖的配置文件和其他需要的文件一并打包封装为目标镜像。容易理解，同一目标应用可能编译得到多个可执行文件，从而具有对应的多个目标镜像。管理子节点创建pod实例(物理集群的基本调度单元)，并基于pod实例运行目标应用对应的多个目标镜像。

步骤310，根据节点流转信息将pod实例部署至一个服务节点，向相应节点终端发送验证通知；当接收到节点终端根据验证通知触发的节点同步请求时，将pod实例从当前的服务节点同步至另一个服务节点，返回相应节点终端发送验证通知的步骤，直至节点流转结束，完成对目标应用的部署。

管理子节点根据节点流转信息将pod实例部署至第一节点，并向第一终端发送开发验证通知。当开发人员根据开发验证通知对pod实例进行开发验证时，可以基于第一终端向管理子节点发送第一验证请求。第一验证请求携带了第一节点标识。管理子节点根据第一节点标识向第一终端开通接入权限，使得开发人员可以在第一终端根据测试需求对第一节点中的pod实例进行性能测试，并在测试验证通过时触发第一节点同步请求。管理子节点根据第一节点同步请求将pod实例从第一节点同步至第二节点。

管理子节点向第二终端发送测试验证通知。当测试人员根据测试验证通知对pod实例进行测试验证时，可以按照上述方式申请对第二节点的接入权限，以对第二节点中的pod实例进行功能测试等，并在测试验证通过时触发第二节点同步请求。管理子节点根据第二节点同步请求将pod实例从第二节点同步至第三节点，完成对目标应用的部署。

值得说明的是，上述各个环节对pod实例的测试验证信息不会写入pod实例中，以保证不同服务节点之间同步的数据信息相同，进而可以减少不同部署环境之间的差异。此外，为了减少对服务资源的占用，在将当前服务节点中pod实例同步至下一个服务节点后，将pod实例从当前的服务节点删除。若开发验证失败或者测试验证失败，则将各个服务节点中的pod实例清理释放，返回步骤302，待开发人员对代码文件进行异常修复后重新进行目标应用部署。

本实施例中，通过将容器化集群中多个服务节点虚拟的划分为采用不同网络但能够向目标应用提供相同运行环境的多种部署环境，可以减少环境之间的差异，进而可以降低环境差异对目标应用带来的异常风险。此外，通过对目标应用代码文件进行变更监控，自动触发目标应用的流转部署，对于部署环境搭建、节点流转等工作均自动完成，可以大大减少人工介入，进而可以降低人为因素对目标应用带来的异常风险。

在一个实施例中，将pod实例部署至一个服务节点，包括：通过对服务节点初始化在每个服务节点上部署容器管理代理；向一个服务节点中的容器管理代理发送容器部署请求；使容器管理代理根据容器部署请求在预设的容器仓库拉取pod实例对应的多个容器文件，并基于容器文件在相应服务节点进行pod实例部署。

管理父节点根据需要的容器资源，筛选相匹配的服务节点。管理父节点预存了多种容器类型分别对应的初始化脚本。管理父节点根据容器类型，获取对应的初始化脚本，将获取到的初始化脚本发送至相应服务节点，对服务节点进行初始化。在第一容器上安装容器管理代理也是初始化的一部分。具体的，第一容器对应的初始化脚本包括容器管理代理程序。管理父节点将携带容器管理代理程序的初始化脚本发送至相应服务节点，使第一容器通过运行容器管理代理程序实现容器管理代理部署。

本实施例中，基于容器管理代理可以通过简单配置即可实现pod实例在不同服务节点之间的自动化部署和同步。

在一个实施例中，从运行负载小于阈值的子系统集群中分割容器资源，包括：计算运行负载超过阈值的子系统集群对应的待补充资源配额；计算运行负载小于阈值的子系统集群对应的可分享资源配额；比较可分享资源配额是否大于或等于待补充资源配额；若是，调用容器集群管理接口从运行负载小于阈值的子系统集群中分割出与待补充资源配额相对应的容器资源。

待补充资源额度及可分享资源额度分别可以是基于当前运行负载与阈值的差值，以及当前每个容器所承受的负载均值计算得到的。例如，可以将差值与负载均值的比值作为待补充资源额度。当差值与负载均值的比值为小数时，可以取整。在上述举例中，在当前时间节点，子系统集群A对应的待补充资源额度可以是(80％-64％)/(80％÷10)＝2；子系统集群B对应的可分享资源额度可以是(64％-40％)/(40％÷15)＝8；子系统集群C对应的可分享资源额度为(64％-60％)/(60％÷30)＝2。

若运行负载小于阈值的子系统集群有多个，管理父节点根据运行负载确定多个子系统集群的遍历顺序。例如，将运行负载最小的子系统集群确定为第一遍历顺序，将运行负载次小的子系统集群确定为第二遍历顺序，以此类推。管理父节点根据遍历顺序对具有可分享资源配额的子系统集群进行遍历，若第一遍历顺序的子系统集群对应的可分享资源配额大于或等于待补充资源配额，则调用容器集群管理接口从第一遍历顺序子系统集群中分割出与待补充资源配额相对应的容器资源。若第一遍历顺序的子系统集群对应的可分享资源配额小于待补充资源配额，则从第一遍历顺序子系统集群中分割出与其全部可分享资源配额(记作已分割资源配额)相对应的容器资源，并计算已分割资源配额与待补充资源配额的目标差值。管理父节点判断第二遍历顺序的子系统集群对应的可分享资源配额大于或等于目标差值。若第二遍历顺序的子系统集群对应的可分享资源配额大于或等于目标差值，则从第二遍历顺序子系统集群中分割出与目标差值相对应的容器资源。若第二遍历顺序的子系统集群对应的可分享资源配额小于目标差值，按照上述方式继续对第三遍历顺序的子系统集群进行遍历，直至分割得到的容器资源达到待补充资源配额。

在另一个实施例中，调用容器集群管理接口从运行负载小于阈值的子系统集群中分割出与待补充资源配额相对应的容器资源，包括：若运行负载小于阈值的子系统集群有多个，根据运行负载确定每个子系统集群对应的分享权重；根据分享权重及待补充资源配额，计算每个运行负载小于阈值的子系统集群分别对应的待分享资源配额；从每个运行负载小于阈值的子系统集群中分割出待分享资源配额的容器资源。

区别于上述容器资源分割方式，即便运行负载最小的子系统集群的可分享资源配额大于或等于待补充资源配额，无需从运行负载最小的单一子系统集群中分割容器资源，而是从多个具有可分享资源配额的子系统集群中分别分割一部分容器资源，可以减少对被分割容器资源的子系统集群的性能影响，不至于由于被分割大量容器资源而使其性能急剧下降。即便这种容器资源分割方式，在分割时也依然充分考虑运行负载，根据运行负载调整分割权重。

本实施例中，提供多种容器资源分割方式，基于简单的运算逻辑确定被分割容器资源的来源及配额，可以提高容器资源分割效率，进而提高容器资源分配效率。

应该理解的是，虽然图2和图3的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，图2和图3中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些子步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

在一个实施例中，如图4所示，提供了一种容器资源分配装置，包括：第一资源分配模块402、目标应用部署模块404和第二资源分配模块406，其中：

第一资源分配模块402，用于获取业务系统的资源需求信息；业务系统包括多个目标应用；根据资源需求信息分配每个目标应用需要的容器资源。

目标应用部署模块404，用于调用容器集群管理接口将分配的容器资源配置为系统集群；系统集群包括多个子系统集群；将不同目标应用部署在不同子系统集群中。

第二资源分配模块406，用于监控是否存在一个子系统集群的运行负载超过阈值；若是，从运行负载小于阈值的子系统集群中分割容器资源，将分割的容器资源合并至运行负载超过阈值的子系统集群中，并将运行负载超过阈值的子系统集群中运行的任务调度至合并后的容器资源中继续执行。

在一个实施例中，资源需求信息包括部署目标应用需要的服务项、应用项或数据项；第一资源分配模块402还用于根据服务项的数量和类型，确定需要的第一容器的数量及第二容器的数量；根据应用项对应应用程序所需要的存储空间，计算第一容器所需的存储空间；根据预设的基础存储空间以及数据项对应数据所需要的存储空间，计算第二容器所需的存储空间。

在一个实施例中，目标应用部署模块404还用于获取目标应用的代码文件、部署配置信息和节点流转信息；根据部署配置信息对相应子系统集群中多个服务节点进行相同配置，使多个服务节点向目标应用提供相同的运行环境；根据节点流转信息对相应子系统集群中多个服务节点进行网络隔离配置，使多个服务节点采用不同的网络；基于代码文件创建对应的pod实例；根据节点流转信息将pod实例部署至一个服务节点，向相应节点终端发送验证通知；当接收到节点终端根据验证通知触发的节点同步请求时，将pod实例从当前的服务节点同步至另一个服务节点，返回相应节点终端发送验证通知的步骤，直至节点流转结束，完成对目标应用的部署。

在一个实施例中，目标应用部署模块404还用于通过对服务节点初始化在每个服务节点上部署容器管理代理；向一个服务节点中的容器管理代理发送容器部署请求；使容器管理代理根据容器部署请求在预设的容器仓库拉取pod实例对应的多个容器文件，并基于容器文件在相应服务节点进行pod实例部署。

在一个实施例中，第二资源分配模块406还用于计算运行负载超过阈值的子系统集群对应的待补充资源配额；计算运行负载小于阈值的子系统集群对应的可分享资源配额；比较可分享资源配额是否大于或等于待补充资源配额；若是，调用容器集群管理接口从运行负载小于阈值的子系统集群中分割出与待补充资源配额相对应的容器资源。

在一个实施例中，第二资源分配模块406还用于计算运行负载超过阈值的子系统集群对应的待补充资源配额；若运行负载小于阈值的子系统集群有多个，根据运行负载确定每个子系统集群对应的分享权重；根据分享权重及待补充资源配额，计算每个运行负载小于阈值的子系统集群分别对应的待分享资源配额；从每个运行负载小于阈值的子系统集群中分割出待分享资源配额的容器资源。

关于容器资源分配装置的具体限定可以参见上文中对于容器资源分配方法的限定，在此不再赘述。上述容器资源分配装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

在一个实施例中，提供了一种计算机设备，该计算机设备可以是服务器，其内部结构图可以如图5所示。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口和数据库。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的数据库用于存储资源需求信息、运行负载的阈值等。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种容器资源分配方法。

本领域技术人员可以理解，图5中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现本申请任意一个实施例中提供的容器资源分配方法的步骤。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)或闪存。易失性存储器可包括随机存取存储器(RAM)或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双数据率SDRAM(DDRSDRAM)、增强型SDRAM(ESDRAM)、同步链路(Synchlink)DRAM(SLDRAM)、存储器总线(Rambus)直接RAM(RDRAM)、直接存储器总线动态RAM(DRDRAM)、以及存储器总线动态RAM(RDRAM)等。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

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

Claims (10)

1.一种容器资源分配方法，所述方法包括：

获取业务系统的资源需求信息；所述业务系统包括多个目标应用；

根据所述资源需求信息分配每个所述目标应用需要的容器资源；

调用容器集群管理接口将分配的容器资源配置为系统集群；所述系统集群包括多个子系统集群；

将不同所述目标应用部署在不同子系统集群中；

监控是否存在一个所述子系统集群的运行负载超过阈值；

若是，从所述运行负载小于阈值的子系统集群中分割容器资源，将分割的容器资源合并至所述运行负载超过阈值的子系统集群中，并将所述运行负载超过阈值的子系统集群中运行的任务调度至合并后的容器资源中继续执行。

2.根据权利要求1所述的方法，其特征在于，所述资源需求信息包括部署所述目标应用需要的服务项、应用项或数据项；所述根据所述资源需求信息分配每个所述目标应用需要的容器资源，包括：

根据所述服务项的数量和类型，确定需要的第一容器的数量及第二容器的数量；

根据所述应用项对应应用程序所需要的存储空间，计算所述第一容器所需的存储空间；

根据预设的基础存储空间以及所述数据项对应数据所需要的存储空间，计算所述第二容器所需的存储空间。

3.根据权利要求1所述的方法，其特征在于，所述将每个所述目标应用部署在相应子系统集群中，包括：

获取所述目标应用的代码文件、部署配置信息和节点流转信息；

根据所述部署配置信息对相应子系统集群中多个服务节点进行相同配置，使所述多个服务节点向所述目标应用提供相同的运行环境；

根据所述节点流转信息对相应子系统集群中多个服务节点进行网络隔离配置，使所述多个服务节点采用不同的网络；

基于所述代码文件创建对应的pod实例；

根据所述节点流转信息将所述pod实例部署至一个服务节点，向相应节点终端发送验证通知；当接收到所述节点终端根据所述验证通知触发的节点同步请求时，将所述pod实例从当前的服务节点同步至另一个服务节点，返回所述相应节点终端发送验证通知的步骤，直至节点流转结束，完成对所述目标应用的部署。

4.根据权利要求3所述的方法，其特征在于，所述将所述pod实例部署至一个服务节点，包括：

通过对所述服务节点初始化在每个服务节点上部署容器管理代理；

向一个所述服务节点中的容器管理代理发送容器部署请求；使所述容器管理代理根据所述容器部署请求在预设的容器仓库拉取所述pod实例对应的多个容器文件，并基于所述容器文件在相应服务节点进行pod实例部署。

5.根据权利要求1所述的方法，其特征在于，所述从所述运行负载小于阈值的子系统集群中分割容器资源，包括：

计算所述运行负载超过所述阈值的子系统集群对应的待补充资源配额；

计算所述运行负载小于阈值的子系统集群对应的可分享资源配额；

比较所述可分享资源配额是否大于或等于所述待补充资源配额；

若是，调用容器集群管理接口从所述运行负载小于所述阈值的子系统集群中分割出与所述待补充资源配额相对应的容器资源。

6.根据权利要求1所述的方法，其特征在于，所述从所述运行负载小于阈值的子系统集群中分割容器资源，包括：

计算所述运行负载超过所述阈值的子系统集群对应的待补充资源配额；

若所述运行负载小于阈值的子系统集群有多个，根据所述运行负载确定每个子系统集群对应的分享权重；

根据所述分享权重及所述待补充资源配额，计算每个运行负载小于阈值的子系统集群分别对应的待分享资源配额；

从每个所述运行负载小于阈值的子系统集群中分割出所述待分享资源配额的容器资源。

7.一种容器资源分配装置，所述装置包括：

第一资源分配模块，用于获取业务系统的资源需求信息；所述业务系统包括多个目标应用；根据所述资源需求信息分配每个所述目标应用需要的容器资源；

目标应用部署模块，用于调用容器集群管理接口将分配的容器资源配置为系统集群；所述系统集群包括多个子系统集群；将不同所述目标应用部署在不同子系统集群中；

第二资源分配模块，用于监控是否存在一个所述子系统集群的运行负载超过阈值；若是，从所述运行负载小于阈值的子系统集群中分割容器资源，将分割的容器资源合并至所述运行负载超过阈值的子系统集群中，并将所述运行负载超过阈值的子系统集群中运行的任务调度至合并后的容器资源中继续执行。

8.根据权利要求7所述的装置，其特征在于，所述资源需求信息包括部署所述目标应用需要的服务项、应用项或数据项；所述第一资源分配模块，还用于根据所述服务项的数量和类型，确定需要的第一容器的数量及第二容器的数量；根据所述应用项对应应用程序所需要的存储空间，计算所述第一容器所需的存储空间；根据预设的基础存储空间以及所述数据项对应数据所需要的存储空间，计算所述第二容器所需的存储空间。

9.一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至6中任一项所述方法的步骤。

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