CN106919445A - 一种在集群中并行调度容器的方法和装置 - Google Patents

Abstract

本发明涉及集群资源调度技术领域，提供在集群中并行调度容器的方法，调度器周期性的获取集群状态信息，所述集群状态信息包括集群中所有节点的资源信息和集群中所有容器的描述信息；所述容器的描述信息包括该容器的容器标识ID、该容器对资源的需求和该容器的部署节点标识ID；所述节点的资源信息包括该节点的标识ID和该节点拥有的资源数量；根据集群状态信息、所述调度器已调度的容器信息和其他调度器已调度的容器信息，将待部署的容器调度到集群中的节点上；其中，所述已调度的容器信息包括已调度的容器的容器ID和部署节点ID。通过上述方案，有效的降低了并行调度中资源冲突的问题。

Description

一种在集群中并行调度容器的方法和装置

技术领域

本发明涉及集群资源调度相关技术领域，尤其涉及一种在集群中并行调度容器的方法和装置。

背景技术

随着虚拟化技术的发展，越来越多的公司将自己的线上应用迀移到云平台上。容器(Container)作为一种轻量级的虚拟化技术，近年来发展迅速。容器技术为不同的应用程序创造了独立的运行环境，实现了资源隔离、配置与安全保障，能够满足应用按需分配的资源需求以及保证应用的隔离性和可用性。

为了满足大型应用的需求，实践中往往需要将很多容器部署在计算机集群(Cluster，以下简称集群)中进行统一管理并对外提供服务。容器集群管理工具目前有Google公司的Kubernetes，Docker公司的Docker Swarm，CloudFoundry公司的Diego等。以Kuberentes为例，Kubernetes是由Google开源的容器集群管理系统，为在分布式集群环境下大规模容器化的应用提供资源调度、部署运行、服务发现、弹性伸缩等功能。Kubernetes通过在线方式监控容器集群状态，判断容器运行状态是否符合用户的配置，以决定是否要创建或删除容器。

资源调度是容器集群管理系统需要解决的一个重要问题，资源调度是指为一个待部署的容器通过一定的规则在集群的众多节点中选择一个适合部署该容器的节点，调度器一般需要考虑待部署容器需要的资源(多少CPU、多少Memory、多少硬盘等)以及一些其它约束，例如是否需要部署在指定位置、是否需要把该容器与和它相同类型的其它容器分散部署在集群中等等。

图1是以Kubernetes为例的容器集群中的资源调度方案。其中，node为节点，节点可以是虚拟机也可以是物理机，一个节点上可以部署若干个容器，且每个节点上都有一个Agent。节点上的Agent用于管理部署在该节点上的所有容器，包括监控该节点的资源信息(如CPU、内存、磁盘空间等等)以及监控部署在该节点上的容器的运行状态(如运行中、挂起或者创建失败等)。Agent周期性的接受Master的轮询，向Master上报自身所在节点的资源信息和所有容器的运行状态。Master是容器集群管理系统的中心管理模块。Master可以是集群中的某一个节点，或若干个节点(处于高可用性的目的)。Master用于获取并保存集群整体的状态信息，该集群状态信息包括：所有节点的资源信息和所有容器的描述信息，其中，容器的描述信息包括对容器的部署对资源的需求和部署节点等。其中，部署节点在容器未被调度前为空(””)。调度器Scheduler周期性的从Master同步得到最新的集群状态信息，并基于最新的集群状态信息对待调度的容器进行调度。

为了加快调度的速度，包括Google在内的Omega系统提出并行调度的解决方案，也就是说系统中会存在多个调度器从Master获取集群的状态信息，并对待调度的容器进行调度。现有技术中，各调度器可以按照一定的规则来分配调度任务以保证每一个待调度的容器有且只有一个调度器为其选择部署节点。然而按照现在的调度机制可知，每个调度器都是周期性的从Master同步获取集群的状态信息，且都可以将自己负责的容器调度到集群中的任意节点上。这很可能会产生资源冲突，例如集群中仅有两个Node，Master保存的集群状态信息显示Node1剩余资源是{5CPU,10G内存}，Node2剩余资源是{4CPU，8G内存}，此时两个调度器同时开始调度各自的任务，Scheduler1调度的C1的资源需求为{3CPU，5G内存}，Scheduler2调度的C2的资源需求为{3CPU，6G内存}。如果两个调度器都希望把各自负责的容器放到更加空闲的节点上，那么Scheduler1和Scheduler2都会把Node1作为C1和C2的部署节点通知Master。Master在收到请求以后如果将C1和C2的部署节点都改为Node1的话，Node1上的Agent在实际执行的时候会发现资源不足，C1和C2必将有一个部署失败(先部署C1，则C2将部署失败；先部署C2的话，则C1将部署失败)。而实际上，C1和C2分别部署在Node1和Node2上是一个可行方案，但是并行调度器没有找到这个方案。由上可知，在并行调度系统中，亟需一种解决调度冲突的解决方案。

发明内容

本发明提供了一种在集群中并行调度容器的方法和设备，以解决并行调度中资源冲突的问题。

为达到上述目的，本发明的实施例采用如下技术方案：

第一方面，提供一种在集群中并行调度容器的方法，包括：调度器周期性的获取集群状态信息，所述集群状态信息包括集群中所有节点的资源信息和集群中所有容器的描述信息；其中，所述容器的描述信息包括该容器的容器标识ID、该容器对资源的需求和该容器的部署节点标识ID；所述节点的资源信息包括该节点的标识ID和该节点拥有的资源数量；根据所述集群状态信息Shared_Info、所述调度器已调度的容器信息Assumed_Local和其他调度器已调度的容器信息Assumed_Remote，将待部署的容器调度到集群中的节点上；其中，所述已调度的容器信息包括已调度的容器的容器ID和部署节点ID。由于频繁的获取集群状态信息会对系统中的性能产生很大的压力，所以现有技术中都是通过周期性的与系统中其他组件进行同步，以获取系统的集群状态信息。同步周期越长，各个调度器进行并行容器调度时，发生资源冲突的概率就越大。为了解决资源冲突的问题，有一种方法就是采用这种减小同步周期的方法。这种频繁的同步虽然能够一定程度上改善资源冲突的问题，但是频繁的同步，对Master造成了很大的性能负担，并且也不能完全杜绝资源冲突的问题。本发明实施例中，调度器做调度决策时，不仅依据从Master同步过来的集群状态信息，还考虑到了调度器自身已经调度的容器的信息和其他调度器已经调度的容器的信息，从而在不增加Master的负担的前提下，有效的降低了资源冲突的概率。

在一种可能的设计中，根据所述集群状态信息Shared_Info、所述调度器已调度的容器信息Assumed_Local和其他调度器已调度的容器信息Assumed_Remote，将待部署的容器调度到集群中的节点上，具体为：调度器根据所述Shared_Info、所述Assumed_Local和所述Assumed_Remote，生成当前决策信息Current_State；根据所述Current_State和预设的调度规则将待部署的容器调度到集群中的节点上。预设的调度规则可以是将容器调度到资源最充足的节点上。本发明实施例生成当前决策信息Current_State，并根据当前决策信息Current_State进行调度决策，有效的降低了资源冲突的概率。并且系统动态的维护一个当前决策信息Current_State，当需要调度容器时，直接查询该当前决策信息Current_State即可，不需要再根据所述Shared_Info、所述Assumed_Local和所述Assumed_Remote进行计算，从而加快了调度器的调度时间。

一种可能的设计中，调度器根据所述Shared_Info、所述Assumed_Local和所述Assumed_Remote，生成当前决策信息Current_State，具体为：当所述Shared_Info与所述Assumed_Local或者所述Assumed_Remote中关于某一个容器的部署节点有冲突时，以所述Assumed_Local或者所述Assumed_Remote为准，生成所述Current_State。因为不会有两个或者以上的调度器会对同一个容器进行调度，所以Assumed_Local和所述Assumed_Remote二者不会冲突。当前决策信息Current_State表征了当前集群中各个容器的真实调度情况，由于并行调度架构中调度器和Master之间的信息同步不是实时的，所以在同步周期间隙中，其他调度器(如Scheduler1)的调度结果在Scheduler2保存的群状态信息Shared_Info2中将无法体现；另外，由于调度器完成调度任务后，虽然将调度结果发送给Master了，但是该调度结果依然也无法在Scheduler2保存的群状态信息Shared_Info2中体现。所以仅根据集群状态信息，无法准确的进行容器调度。

一种可能的设计中，在所述获取集群状态信息之前，所述方法还包括：接收所述其他调度器发送的调度通告，所述其他调度器发送的调度通告包括容器ID和节点ID；将所述其他调度器发送的调度通告保存到所述Assumed_Remote中；在所述将待部署的容器调度到集群中的节点上之后，所述方法还包括：向所述其他调度器发送包含所述待部署的容器的容器ID和所述集群中的节点的节点ID的调度通告。所述Assumed_Remote用于保存其他调度器发送的调度通告，根据所述Assumed_Remote中保存的调度通告，调度器可以获知哪些容器已经被其他调度器进行调度，并部署在哪些节点上了，从而在为自身的容器调度做调度决策时，对此进行考虑，避免了并行调度时发生资源冲突。

第二方面，本发明实施例提供了一种计算机存储介质，用于储存为上述在集群中并行调度容器的装置所用的计算机软件指令，其包含用于执行上述方面所设计的程序。

第三方面，本发明实施例提供了在集群中并行调度容器的装置，该装置具有实现上述第一方面中在集群中并行调度容器的装置行为的功能。所述功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。所述硬件或软件包括一个或多个与上述功能相对应的模块。

在一个可能的设计中，在集群中并行调度容器的装置的结构中包括处理器和存储器，所述存储器用于存储支持装置执行上述方法的程序，所述处理器被配置为用于执行所述存储器中存储的程序。所述数据库处理设备还可以包括通信接口，用于数据库处理设备与其他设备或通信网络通信。

可选的，上述各方面所述的调度通告还包括该调度通告生成的时间。当调度器接收到该调度通告后，将该调度通告保存到自身的其他调度器已经调度的容器信息Assumed_Remote中，并监控Assumed_Remote中保存的所有调度通告是否超出生命周期，如果超过了生命周期，则确定该调度通告已经失效，进而删除该调度通告。通过对Assumed_Remote中保存的调度通告进行及时清理，可以有效的减轻设备的存储负担。

相较于现有技术，本发明提供的方案在调度决策时，除了依据集群状态信息外，还会获取调度器已调度的容器信息和其他调度器已调度的容器信息，从而在集群中并行调度容器时，避免出现资源冲突。

本发明的这些方面或其他方面在以下实施例的描述中会更加简明易懂。

附图说明

图1为现有技术中一种容器调度的系统架构图；

图2为本发明一实施例提供的集群中并行调度容器的运行架构；

图3为本发明一实施例提供的计算机设备示意图；

图4为本发明一实施例提供的一种在集群中并行调度容器的方法的流程示意图；

图5为本发明一实施例提供的在集群中并行调度容器的装置的结构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面结合附图对本发明具体实施例作进一步的详细描述。

图2描述了本发明一实施例涉及的在集群中并行调度容器的的系统架构。该并行调度容器的的系统架构包括调度器Scheduler 201(如Scheduler1和Scheduler2等)、中心管理器Master 202以及节点Node203(如Node1和Node2等)。Scheduler 201、Master 202以及Node 203建立通信连接。其中，节点可以是虚拟机也可以是物理机，一个节点上可以部署若干个容器，且每个节点上都有一个Agent 2031。节点上的Agent 2031用于管理部署在该节点上的所有容器，包括监控该节点的资源信息(如CPU、内存、磁盘空间等等)以及监控部署在该节点上的容器的运行状态(如运行中、挂起或者创建失败等)。Agent 2031周期性的接受Master 202的轮询，向Master 202上报自身所在节点的资源信息和所有容器的运行状态。Master 202是容器集群管理系统的中心管理模块。Master 202可以是集群中的某一个节点，或若干个节点(处于高可用性的目的)。Master 202用于获取并保存集群整体的状态信息，该集群状态信息包括：所有节点的资源信息和所有容器的描述信息，其中，容器的描述信息包括对容器的部署对资源的需求和部署节点等。其中，部署节点在容器未被调度前为空(””)。调度器Scheduler 201周期性的从Master 202同步得到最新的集群状态信息，并基于最新的集群状态信息对待调度的容器进行调度。各调度器可以按照一定的规则来分配调度任务以保证每一个待调度的容器有且只有一个调度器为其选择部署节点。

资源调度的含义即是为一个待部署的容器通过预设的调度规则在集群的众多节点中选择一个适合部署该容器的节点。调度器在进行资源调度时一般需要综合考虑待部署容器需要的资源(多少CPU、多少Memory、多少硬盘)以及集群中各个节点剩余的资源情况。

在本发明实施例中，当调度器完成调度后，将除了将调度结果(包含了容器的ID和部署节点的ID)发送给Master之外，还向其他调度器发送调度通告(包含了容器的ID和部署节点的ID)。每个调度器都会保存其他调度器发送的调度通告，当一个调度器需要做调度决策时，它不仅考虑从Master同步得到的集群状态信息和自身已调度的容器信息，还需要考虑从其他调度器接收到的调度通告。

为了加快调度速度，调度器完成调度将调度结果发送给Master之后，并不需要等待Master的响应确认，而是紧接着从调度下一个任务。由于调度器是周期性的从Master同步获取集群状态信息，所以不同的调度器在同步周期内可能完成了多个容器的调度，例如Scheduler1将C1_1部署到Node1，Scheduler2将C2_1部署到Node2，而这些调度信息在集群状态信息中并没有体现出来。当Scheduler1紧接着对容器C1_2进行调度时，除了考虑之前从Master同步过来的集群状态信息外，还需要考虑自身已调度的容器信息(将C1_1部署到Node1)和从其他调度器接收到的调度通告(将C2_1部署到Node2)，并基于此进行调度决策，将C1_2调度到合适的节点上。

通过上述方法，可以有效的避免并行调度中资源冲突的问题，提高了调度的效率。

需要说明的是，在并行调度架构中，不同的调度器可以在相同的时刻与Master 202进行数据同步，也可以在不同的时刻与Master 202进行数据同步，本发明不做限定，并且调度器的个数也不限定于2个，且节点的个数也不做限定。

如图3所示，图2中的调度器可以以图3中的计算机设备(或系统)的方式来实现。

图3所示为本发明实施例提供的计算机设备示意图。计算机设备300包括至少一个处理器301，通信总线302，存储器303以及至少一个通信接口304。

处理器301可以是一个通用中央处理器(CPU)，微处理器，特定应用集成电路(application-specificintegrated circuit，ASIC)，或一个或多个用于控制本发明方案程序执行的集成电路。

通信总线302可包括一通路，在上述组件之间传送信息。所述通信接口304，使用任何收发器一类的装置，用于与其他设备或通信网络通信，如以太网，无线接入网(RAN)，无线局域网(Wireless Local AreaNetworks，WLAN)等。

存储器303可以是只读存储器(read-only memory，ROM)或可存储静态信息和指令的其他类型的静态存储设备，随机存取存储器(random access memory，RAM)或者可存储信息和指令的其他类型的动态存储设备，也可以是电可擦可编程只读存储器(Electrically Erasable Programmable Read-Only Memory，EEPROM)、只读光盘(Compact Disc Read-Only Memory，CD-ROM)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器可以是独立存在，通过总线与处理器相连接。存储器也可以和处理器集成在一起。

其中，所述存储器303用于存储执行本发明方案的应用程序代码，并由处理器301来控制执行。所述处理器301用于执行所述存储器303中存储的应用程序代码。

在具体实现中，作为一种实施例，处理器301可以包括一个或多个CPU，例如图3中的CPU0和CPU1。

在具体实现中，作为一种实施例，计算机设备300可以包括多个处理器，例如图3中的处理器301和处理器308。这些处理器中的每一个可以是一个单核(single-CPU)处理器，也可以是一个多核(multi-CPU)处理器。这里的处理器可以指一个或多个设备、电路、和/或用于处理数据(例如计算机程序指令)的处理核。

在具体实现中，作为一种实施例，计算机设备300还可以包括输出设备305和输入设备306。输出设备305和处理器301通信，可以以多种方式来显示信息。例如，输出设备305可以是液晶显示器(liquidcrystal display，LCD),发光二级管(light emitting diode，LED)显示设备，阴极射线管(cathode raytube，CRT)显示设备，或投影仪(projector)等。输入设备306和处理器301通信，可以以多种方式接受用户的输入。例如，输入设备306可以是鼠标、键盘、触摸屏设备或传感设备等。

上述的计算机设备300可以是一个通用计算机设备或者是一个专用计算机设备。在具体实现中，计算机设备300可以是台式机、便携式电脑、网络服务器、掌上电脑(Personal Digital Assistant，PDA)、移动手机、平板电脑、无线终端设备、通信设备、嵌入式设备或有图3中类似结构的设备。本发明实施例不限定计算机设备300的类型。

如图2中的调度器可以为图3所示的设备，调度器的存储器中存储了一个或多个软件模块(例如：交互模块和处理模块等)。调度器可以通过处理器以及存储器中的程序代码来实现软件模块，实现在集群中并行的调度容器。

如图4所示，为本发明实施例提供的在集群中并行调度容器的方法流程示意图。为了便于说明，本发明实施例以图2所述的系统架构为例进行说明，需要说明的是，在实际系统中调度器、节点、Master的个数不限于图2中显示的个数。在本发明实施例中，集群由两个节点(Node1和Node2)组成，并且存在两个并行调度器(Scheduler1和Scheduler2)分别调度属于自己的调度任务，其中Scheduler1负责调度C1_1和C1_2，Scheduler2负责调度C2_1和C2_2。各容器的描述信息以及各节点的资源信息保存在Master中，且在T时刻时，分别如表2和表1所示。其中，节点的资源信息是Master通过与Agent进行通信获取的，容器的描述信息是Master接收创建容器的请求时生成的。

A1、调度器与Master进行同步，获取最新的集群状态信息；

Scheduler1、Scheduler2分别与Master进行信息同步，获取最新的集群状态信息，记为Shared_Info1和Shared_Info2，集群状态信息包含了集群中各个节点的资源信息以及集群中所有容器的描述信息，其中，节点的资源信息该节点的标识ID和该节点拥有的资源数量(例如CPU和内存等信息)；容器的描述信息包括容器的标识ID、资源需求(例如部署该容器需要多少CPU和内存等)以及部署节点标识ID。当容器还没有被调度时，则该容器的描述信息中的部署节点ID设置为“未部署”，例如可以设置为NA或者“”。

表1节点的资源信息：Table_Nodes

Node_ID	TotalCPU	TotalMemory
			Node 1	5	11G
Node 2	6	12G

表2容器的描述信息：Table_Containers

Container_ID	Node	CPU	Memory
				C1_1	“”	3	5G
C1_2	“”	2	5G
				C2_1	“”	3	5G
C2_2	“”	2	5G

需要说明的是，容器的描述信息是Master接收创建容器的请求时生成的，该创建请求可以是用户在客户端通过模板发起的，也可以是系统中其他组件，如弹性伸缩组件根据业务需要自动发起的。例如在Kubernetes中，表2中C1_1的模板可以是：

模板中的{spec:{containers:{resources:{requests:{cpu:3,memory:5G}}}}}代表了部署该容器的资源需求是3个CPU Core和5G的内存。本实施例中由于其他属性和调度无关，我们不做更多解释。需要说明的是，容器的创建请求在刚刚提交到Master后，其部署节点信息的值是空，这个值需要调度器通过调度来决定。

A2、Scheduler2调度容器C2_1；

Scheduler2根据集群状态信息Shared_Info2、Scheduler2已调度的容器信息Assumed_Local_2和其他容器已调度的容器信息Assumed_Remote_2，并基于预设的调度规则，将待部署的容器C2_1调度到Node2上。完成调度后，将调度结果保存到已调度容器信息Assumed_Local_2中，所述调度结果包括被调度的容器标识ID和部署节点标识ID，即{C2_1，Node2}。

A3、Scheduler2将调度结果发送给Master；

具体的，Scheduler2将C2_1的调度结果发送给Master，调度结果包括被调度的容器标识ID和部署节点标识ID，即{C2_1，Node2}，以便于Master根据调度结果更改容器C2_1的描述信息中的部署节点，即由“”改为Node2。

A4、Scheduler2向其他调度器发送调度通告；

所述调度通告包括被调度的容器标识ID和部署节点标识ID，即{C2_1，Node2}。可选的，还包括该调度通告生成的时间，例如{C2_1，Node2，time1}。当其他调度器接收到该调度通告时，即可以知道Node2上已经部署了容器C2_1，其他调度器在进行容器调度时，需要将此考虑进去。

A5、Scheduler1接收其他调度器发送的调度通告，并保存接收到的调度通告；Scheduler1调度容器C1_1；

Scheduler1接收其他调度器发送的调度通告，并保存接收到的调度通告，可选的，Scheduler1将调度通告保存在其他容器已调度的容器信息Assumed_Remote_1中。可选的，当接收其他调度器发送的调度通告中包括该调度通告生成的时间时，调度器可以根据该调度通告生成的时间确定该调度通告是否已经失效，如果该调度通告已经失效，则调度器将该调度通告从Assumed_Remote_1中删除。

Scheduler1根据集群状态信息Shared_Info1、Scheduler1已调度的容器信息Assumed_Local_1和其他容器已调度的容器信息Assumed_Remote1，并基于预设的调度规则，将待部署的容器C1_1调度到Node1上。完成调度后，将调度结果保存到已调度容器信息Assumed_Local_1中，所述调度结果包括被调度的容器标识ID和部署节点标识ID，即{C1_1，Node1}。

A6、Scheduler1将调度结果发送给Master；

具体的，Scheduler1将C1_1的调度结果发送给Master，调度结果包括被调度的容器标识ID和部署节点标识ID，即{C1_1，Node1}，以便于Master根据调度结果更改容器C1_1的描述信息中的部署节点，即由“”改为Node1。

A7、Scheduler1向其他调度器发送调度通告；

所述调度通告包括被调度的容器标识ID和部署节点标识ID，即{C1_1，Node1}，可选的，还包括该调度通告生成的时间，例如{C1_1，Node1，time2}。当其他调度器接收到该调度通告时，即可以知道在t ime2时，Node1上已经部署了容器C1_1，其他调度器在进行容器调度时，需要将此考虑进去。

以下将对上述各执行步骤进行详细说明。

本发明实施例中Scheduler调度容器的过程，可采用如下方式：

(1)Scheduler获取集群状态信息Shared_Info、Scheduler已调度的容器信息Assumed_Local和其他容器已调度的容器信息Assumed_Remote；

其中，集群状态信息Shared_Info由Scheduler周期性的与Master进行同步获得；Scheduler每完成一次调度，就会将调度结果保存至自身的已调度的容器信息Assumed_Local中，同时也会随时接受其他调度器发送的调度通告，并将接收到的调度通告保存到自身的其他调度器已调度的容器信息Assumed_Remote中。

(2)Scheduler根据集群状态信息Shared_Info、Scheduler已调度的容器信息Assumed_Local和其他容器已调度的容器信息Assumed_Remote，生成当前决策信息Current_State；

当前决策信息Current_State表征了当前集群中各个容器的真实调度情况，由于并行调度架构中调度器和Master之间的信息同步不是实时的，所以在同步周期间隙中，其他调度器(如Scheduler1)的调度结果在Scheduler2保存的群状态信息Shared_Info2中将无法体现；另外，由于调度器完成调度任务后，虽然将调度结果发送给Master了，但是该调度结果依然也无法在Scheduler2保存的群状态信息Shared_Info2中体现。所以仅根据集群状态信息，无法准确的进行容器调度。本发明实施例中，需要利用Scheduler已调度的容器信息Assumed_Local和其他容器已调度的容器信息Assumed_Remote对Scheduler保存的集群状态信息Shared_Info进行修正，得到当前决策信息Current_State。

需要说明的是，对Scheduler保存的集群状态信息Shared_Info进行修正，得到当前决策信息Current_State，具体可以是直接对集群状态信息Shared_Info进行修正，修正后得到的信息即是当前决策信息Current_State；当前决策信息Current_State也可以是对集群状态信息Shared_Info复制的副本进行修正得到的信息，而原先保存的集群状态信息Shared_Info并不改变，本发明实施例对当前决策信息Current_State的具体生成方式不做限定。

具体处理的方法可以是：凡是Shared_Info与Assumed_Local或者Assumed_Remote中关于容器部署节点信息有冲突的，以Assumed_Local或Assumed_Remote为准，同时，此二者不会冲突，因为不会有两个或者以上的调度器会对同一个容器进行调度。可选的，如果Assumed_Local或者Assumed_Remote中关于容器部署节点信息在Shared_Info中已经有体现，则调度器将Assumed_Local或者Assumed_Remote中关于容器部署节点信息删除，以减轻存储负担。

例如，Scheduler的Shared_Info中记录容器A和容器B的部署节点为空，而Assumed_Local中记录容器A在节点1上，Assumend_Remote中记录容器B在节点2上，则Scheduler生成的当前决策信息Current_State会记录容器A和容器B的部署节点分别是节点1和节点2。

再例如，Scheduler的Shared_Info中记录容器A和容器B的部署节点分别为节点1和节点2，且Assumed_Local中记录容器A在节点1上，Assumend_Remote中记录容器B在节点2上，则Scheduler生成的当前决策信息Current_State会记录容器A和容器B的部署节点分别是节点1和节点2，可选的，会删除Assumed_Local中记录容器A在节点1上的相关信息，和/或删除Assumend_Remote中记录容器B在节点2上的相关信息。

在本发明实施例中，由于系统刚上线，C2_1为Scheduler2执行的第一个调度任务，并且Scheduler2也没有收到过其他调度器发送的调度通告，所以Scheduler2已调度的容器信息Assumed_Local_2和其他容器已调度的容器信息Assumed_Remote2都为空，获取的集群状态信息Shared_Info2如表1和表2所示。由于Scheduler2已调度的容器信息Assumed_Local_2和其他容器已调度的容器信息Assumed_Remote2都为空，所以修正后得到的当前决策信息Current_State_2与Shared_Info2相同，如表1和表2所示。

(3)根据当前决策信息Current_State以及预设的调度规则，对待部署的容器进行调度。

具体的，系统中的调度器可以使用相同的调度策略，如把容器部署在剩余资源较多的节点上。可选的，在调度过程中，调度器首先将节点剩余资源不能满足容器需求的节点排除在后续部署节点之外，然后对所有符合部署条件的节点进行打分，打分规则可以如下：

节点分数＝(总可用CPU-已占用CPU-当前容器需求CPU)/总可用CPU+(总可用MEM-已占用MEM-当前容器需求MEM)/总可用MEM

其中节点的总可用CPU、总可用MEM、已占用CPU和已占用MEM都由当前决策信息Current_State确定。当前容器指正在被调度的容器。打分过后，得分最高的节点将被选为部署节点。

例如，Scheduler2调度C2_1时，则由表2可知当前容器需求CPU为3，当前容器需求MEM为5G，且集群中所有容器的部署节点都为空，所以每个节点的已占用CPU和已占用MEM都为0；由表1可知，节点1的总可用CPU为5、总可用MEM为11G；节点2的总可用CPU为6、总可用MEM为12G,，所以根据当前决策信息Current_State以及预设的调度规则，对各个节点打分为：

Node1：(5-0-3)/5+(11-0-5)/11＝0.94

Node2：(6-0-3)/6+(12-0-5)/11＝1.08

基于以上计算，Scheduler2将Node_2选择成为C2_1的部署节点，从而完成对容器C2_1的调度。

需要说明的是，上述流程中，当调度器完成调度后，会及时向Master发送调度结果以及向其他调度器发送调度通告。但是各个调度器执行调度任务的顺序是可以变化的，例如步骤A5可以是在A2之前发生或者是在A2之后发生。

可选的，在步骤A1之前，还包括步骤A11Master与集群中各个节点的Agent进行信息同步，获取集群中所有节点的资源信息。

可选的，本发明实施例中提及的调度通告中还包括该调度通告生成的时间。当接收到该调度通告后，将该调度通告保存到自身的其他调度器已经调度的容器信息Assumed_Remote中，并监控Assumed_Remote中保存的所有调度通告是否超出生命周期，如果超过了生命周期，则确定该调度通告已经失效，进而删除该调度通告。例如，可以设定系统中的调度通告的生存时间为T_eff，调度器对Assumed_Remote中的每一条调度通告进行监控，检查其已经存在的时间T_cid_exit＝T_now-T_cid，如果T_cid_exit大于T_eff则确定该调度通告已经失效，调度器则删除该条调度通告。需要说明的是，调度通告的生存时间为T_eff不小于调度器与Master的同步周期。通过在调度通告中增加调度通告生成的时间，并且根据调度通告生成的时间，对Assumed_Remote中保存的调度通告进行及时清理，可以有效的减轻设备的存储负担。

显然的是，同步周期越长，各个调度器进行并行容器调度时，发生资源冲突的概率就越大。现有技术中，为了解决资源冲突的问题，有一种方法就是采用这种减小同步周期的方法。这种频繁的同步虽然能够一定程度上改善资源冲突的问题，但是频繁的同步，对Master造成了很大的性能负担，并且也不能完全杜绝资源冲突的问题。本发明实施例中，调度器做调度决策时，不仅依据从Master同步过来的集群状态信息，还考虑到了调度器自身已经调度的容器的信息和其他调度器已经调度的容器的信息，从而在不增加Master的负担的前提下，有效的降低了资源冲突的概率。

本发明实施例还描述了上述方法实施例属于同一发明构思下的在集群中并行调度容器的装置。如图5所示，该装置器500包括：交互单元501和处理单元503。

其中，交互单元501，用于周期性的获取集群状态信息，所述集群状态信息包括集群中所有节点的资源信息和集群中所有容器的描述信息；其中，所述容器的描述信息包括该容器的容器标识ID、该容器对资源的需求和该容器的部署节点标识ID；所述节点的资源信息包括该节点的标识ID和该节点拥有的资源数量；处理单元503，用于根据所述集群状态信息Shared_Info、所述调度器已调度的容器信息Assumed_Local和其他调度器已调度的容器信息Assumed_Remote，将待部署的容器调度到集群中的节点上；其中，所述已调度的容器信息包括已调度的容器的容器ID和部署节点ID。

所述处理单元503根据所述集群状态信息Shared_Info、所述调度器已调度的容器信息Assumed_Local和其他调度器已调度的容器信息Assumed_Remote，将待部署的容器调度到集群中的节点上，具体为：根据所Shared_Info、所述Assumed_Local和所述Assumed_Remote，生成当前决策信息Current_State；根据所述Current_State和预设的调度规则将待部署的容器调度到集群中的节点上。

其中，根据所述Shared_Info、所述Assumed_Local和所述Assumed_Remote，生成当前决策信息Current_State，具体为：当所述Shared_Info与所述Assumed_Local或者所述Assumed_Remote中关于某一个容器的部署节点有冲突时，以所述Assumed_Local或者所述Assumed_Remote为准，生成所述Current_State。

所述交互单元501，还用于在获取集群状态信息之前，接收所述其他调度器发送的调度通告，所述其他调度器发送的调度通告包括容器ID和节点ID；

存储单元505，用于将所述其他调度器发送的调度通告保存到所述Assumed_Remote中；

所述交互单元501，还用于在所述将待部署的容器调度到集群中的节点上之后，向所述其他调度器发送包含所述待部署的容器的容器ID和所述集群中的节点的节点ID的调度通告。

其中，所述调度通告中还包括该调度通告生成的时间。

在本实施例中，装置500是以功能单元的形式来呈现。这里的“单元”可以指特定应用集成电路(application-specific integrated circuit，ASIC)，电路，执行一个或多个软件或固件程序的处理器和存储器，集成逻辑电路，和/或其他可以提供上述功能的器件。在一个简单的实施例中，本领域的技术人员可以想到装置500可以采用图3所示的形式。交互单元501、处理单元503和存储单元505可以通过图3的处理器和存储器来实现，具体的，交互单元501可以通过由处理器来执行交互模块来实现，处理单元503和存储单元505可以通过由处理器来执行处理模块来实现。

本发明实施例还提供了一种计算机存储介质，用于储存为上述图4所示的在集群中并行调度容器所用的计算机软件指令，其包含用于执行上述方法实施例所设计的程序。通过执行存储的程序，可以减小在集群中并行调度容器时的资源冲突问题。

尽管在此结合各实施例对本发明进行了描述，然而，在实施所要求保护的本发明过程中，本领域技术人员通过查看所述附图、公开内容、以及所附权利要求书，可理解并实现所述公开实施例的其他变化。在权利要求中，“包括”(comprising)一词不排除其他组成部分或步骤，“一”或“一个”不排除多个的情况。单个处理器或其他单元可以实现权利要求中列举的若干项功能。相互不同的从属权利要求中记载了某些措施，但这并不表示这些措施不能组合起来产生良好的效果。

本领域技术人员应明白，本发明的实施例可提供为方法、装置(设备)、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。计算机程序存储/分布在合适的介质中，与其它硬件一起提供或作为硬件的一部分，也可以采用其他分布形式，如通过Internet或其它有线或无线电信系统。

本发明是参照本发明实施例的方法、装置(设备)和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管结合具体特征及其实施例对本发明进行了描述，显而易见的，在不脱离本发明的精神和范围的情况下，可对其进行各种修改和组合。相应地，本说明书和附图仅仅是所附权利要求所界定的本发明的示例性说明，且视为已覆盖本发明范围内的任意和所有修改、变化、组合或等同物。显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (11)

1.一种在集群中并行调度容器的方法，其特征在于，包括：

调度器周期性的获取集群状态信息Shared_Info，所述集群状态信息包括集群中所有节点的资源信息和集群中所有容器的描述信息；其中，所述容器的描述信息包括该容器的容器标识ID、该容器对资源的需求和该容器的部署节点标识ID；所述节点的资源信息包括该节点的标识ID和该节点拥有的资源数量；

根据所述Shared_Info、所述调度器已调度的容器信息Assumed_Local和其他调度器已调度的容器信息Assumed_Remote，将待部署的容器调度到集群中的节点上；其中，所述已调度的容器信息包括已调度的容器的容器ID和部署节点ID。

2.如权利要求1所述的方法，其特征在于，所述根据所述集群状态信息Shared_Info、所述调度器已调度的容器信息Assumed_Local和其他调度器已调度的容器信息Assumed_Remote，将待部署的容器调度到集群中的节点上，具体为：

根据所述Shared_Info、所述Assumed_Local和所述Assumed_Remote，生成当前决策信息Current_State；

根据所述Current_State和预设的调度规则将待部署的容器调度到集群中的节点上。

3.如权利要求2所述的方法，其特征在于，所述根据所述Shared_Info、所述Assumed_Local和所述Assumed_Remote，生成当前决策信息Current_State，具体为：

当所述Shared_Info与所述Assumed_Local或者所述Assumed_Remote中关于某一个容器的部署节点有冲突时，以所述Assumed_Local或者所述Assumed_Remote为准，生成所述Current_State。

4.如权利要求1-3任一所述的方法，其特征在于，在所述获取集群状态信息之前，所述方法还包括：

接收所述其他调度器发送的调度通告，所述其他调度器发送的调度通告包括容器ID和节点ID；

将所述其他调度器发送的调度通告保存到所述Assumed_Remote中；

在所述将待部署的容器调度到集群中的节点上之后，所述方法还包括：

向所述其他调度器发送包含所述待部署的容器的容器ID和所述集群中的节点的节点ID的调度通告。

5.如权利要求4所述的方法，其特征在于，所述调度通告中还包括该调度通告生成的时间。

6.一种在集群中并行调度容器的装置，其特征在于，包括：

交互单元，用于周期性的获取集群状态信息，所述集群状态信息包括集群中所有节点的资源信息和集群中所有容器的描述信息；其中，所述容器的描述信息包括该容器的容器标识ID、该容器对资源的需求和该容器的部署节点标识ID；所述节点的资源信息包括该节点的标识ID和该节点拥有的资源数量；

处理单元，用于根据所述集群状态信息Shared_Info、所述调度器已调度的容器信息Assumed_Local和其他调度器已调度的容器信息Assumed_Remote，将待部署的容器调度到集群中的节点上；其中，所述已调度的容器信息包括已调度的容器的容器ID和部署节点ID。

7.如权利要求6所述的装置，其特征在于，所述处理单元根据所述集群状态信息Shared_Info、所述调度器已调度的容器信息Assumed_Local和其他调度器已调度的容器信息Assumed_Remote，将待部署的容器调度到集群中的节点上，具体为：

根据所Shared_Info、所述Assumed_Local和所述Assumed_Remote，生成当前决策信息Current_State；

根据所述Current_State和预设的调度规则将待部署的容器调度到集群中的节点上。

8.如权利要求7所述的装置，其特征在于，所述根据所述Shared_Info、所述Assumed_Local和所述Assumed_Remote，生成当前决策信息Current_State，具体为：

当所述Shared_Info与所述Assumed_Local或者所述Assumed_Remote中关于某一个容器的部署节点有冲突时，以所述Assumed_Local或者所述Assumed_Remote为准，生成所述Current_State。

9.如权利要求6-8任一所述的装置，其特征在于，所述交互单元，还用于在获取集群状态信息之前，接收所述其他调度器发送的调度通告，所述其他调度器发送的调度通告包括容器ID和节点ID；

存储单元，用于将所述其他调度器发送的调度通告保存到所述Assumed_Remote中；

所述交互单元，还用于在所述将待部署的容器调度到集群中的节点上之后，向所述其他调度器发送包含所述待部署的容器的容器ID和所述集群中的节点的节点ID的调度通告。

10.如权利要求9所述的装置，其特征在于，所述调度通告中还包括该调度通告生成的时间。

11.一种在集群中并行调度容器的调度器，其特征在于，包括：处理器和存储器，其中，

所述存储器中存有计算机可读程序；

所述处理器通过运行所述存储器中的程序，以用于完成上述权利要求1至5所述的方法。