一种容器调度方法、调度器及计算节点与流程

文档序号:21318065发布日期:2020-06-30 20:48阅读:189来源:国知局
一种容器调度方法、调度器及计算节点与流程

本申请涉及设备领域,尤其涉及一种容器调度方法、调度器及计算节点。



背景技术:

在容器系统中,调度器基于资源需求将容器调度到各个计算节点,当容器执行失败时,调度器将在当前计算节点上重启该容器,或者将该容器调度到其他计算节点上,而将其他容器调度到当前计算节点,以保证容器能够成功执行,数据处理继续进行。

而在容器执行失败时,调度器将该容器调度到其他计算节点时,并未获取其执行失败的原因,从而可能会出现多次执行失败的情况。



技术实现要素:

有鉴于此,本申请提供一种容器调度方法、调度器及计算节点,其具体方案如下:

一种容器调度方法,应用于调度器,包括:

在将第一容器调度至除第一计算节点外的第二计算节点时,基于存储的失败记录,发送问询信息至所述第二计算节点,以便所述第二计算节点确定在所述第二计算节点中所述第一容器是否能够执行第二事件,其中,所述失败记录至少包括:在所述第一计算节点中的所述第一容器执行第一事件执行失败的情况以及失败原因;

获取所述第二计算节点反馈的在所述第二计算节点中所述第一容器能够执行所述第二事件的反馈信息,将所述第一容器调度至所述第二计算节点。

进一步的,所述发送问询信息至所述第二计算节点,包括:

将所述问询信息发送至多个计算节点,所述多个计算节点至少包括第二计算节点。

进一步的,还包括:

对所述失败记录进行分析,若确定所述失败原因为非持续可解决原因,在确定所述非持续可解决原因消除时,删除所述失败记录,将所述第一容器调度至所述第一计算节点。

进一步的,所述第一计算节点中的所述第一容器执行所述第一事件失败的失败原因,至少包括:

所述第一容器的执行相关数据与所述第一计算节点的相关数据不匹配。

进一步的,所述第一容器的执行相关数据至少包括以下的一种:

所述第一容器的结构特征;或,所述第一容器的资源信息;或,所述第一容器执行需满足的条件信息。

进一步的,还包括:

获取所述第一计算节点发送的所述第一计算节点中的所述第一容器对所述第一事件执行失败的失败记录,并进行存储。

一种容器调度方法,应用于第一计算节点,包括:

若所述第一计算节点中的第一容器对第一事件执行失败,确定所述执行失败的失败原因;

将所述第一容器的失败记录发送至调度器,所述失败记录至少包括:所述第一计算节点中的所述第一容器执行所述第一事件失败的失败原因。

进一步的,所述将所述第一容器的失败记录发送至调度器,包括:

当确定所述执行失败的失败原因时,主动将所述第一容器的失败记录发送至所述调度器;

或,

当确定所述执行失败的失败原因时,发送失败提示至调度器,使所述调度器能够基于所述失败提示发送失败查询请求至所述第一计算节点;

获取所述失败查询请求,基于所述失败查询请求将所述第一容器的失败记录发送至所述调度器。

进一步的,还包括:

存储所述第一容器的失败记录。

一种容器调度方法,应用于第二计算节点,包括:

获取调度器发送的问询信息,基于所述问询信息确定在所述第二计算节点中第一容器是否能够执行第二事件;

若在所述第二计算节点中所述第一容器能够执行所述第二事件,发送反馈信息至所述调度器,以使所述调度器基于所述反馈信息将所述第一容器调度至所述第二计算节点;

接收处理指令,基于所述处理指令所述第一容器在所述第二计算节点中执行所述第二事件。

一种调度器,包括:

第一发送单元,用于在将第一容器调度至除第一计算节点外的第二计算节点时,基于存储的失败记录,发送问询信息至所述第二计算节点,以便所述第二计算节点确定在所述第二计算节点中所述第一容器是否能够执行第二事件,其中,所述失败记录至少包括:在所述第一计算节点中的所述第一容器执行第一事件执行失败的情况以及失败原因;

第一获取单元,用于获取所述第二计算节点反馈的在所述第二计算节点中所述第一容器能够执行所述第二事件的反馈信息,将所述第一容器调度至所述第二计算节点。

一种第一计算节点,包括:

确定单元,用于在所述第一计算节点中的第一容器对第一事件执行失败时,确定所述执行失败的失败原因;

第二发送单元,用于将所述第一容器的失败记录发送至调度器,所述失败记录至少包括:所述第一计算节点中的所述第一容器执行所述第一事件失败的失败原因。

一种第二计算节点,包括:

第二获取单元,用于获取调度器发送的问询信息,基于所述问询信息确定在所述第二计算节点中第一容器是否能够执行第二事件;

第三发送单元,用于在所述第二计算节点中所述第一容器能够执行所述第二事件时,发送反馈信息至所述调度器,以使所述调度器基于所述反馈信息将所述第一容器调度至所述第二计算节点;

执行单元,用于接收处理指令,基于所述处理指令所述第一容器在所述第二计算节点中执行所述第二事件。

一种存储介质,用于至少存储一组指令集;

所述指令集用于被调用并至少执行如上任一项的容器调度方法。

从上述技术方案可以看出,本申请公开的容器调度方法、调度器及计算节点,在将第一容器调度至除第一计算节点外的第二计算节点时,基于存储的失败记录,发送问询信息至第二计算节点,以便第二计算节点确定在第二计算节点中第一容器是否能够执行第二事件,失败记录至少包括:在第一计算节点中的第一容器执行第一事件执行失败的情况以及失败原因;获取第二计算节点反馈的在第二计算节点中第一容器能够执行第二事件的反馈信息,将第一容器调度至第二计算节点。本方案通过在将第一容器调度至第二计算节点时,依据存储的历史记录中的失败记录及失败原因,确定在第二计算节点中是否能够正常执行其对应的事件,这就避免了在对容器进行调度时,将容器调度至不能够正常执行相关事件的计算节点中,提高了容器调度的效率,降低了事件执行失败的概率。

附图说明

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

图1为本申请实施例公开的一种容器调度方法的流程图;

图2为本申请实施例公开的一种容器调度方法的流程图;

图3为本申请实施例公开的一种容器调度方法的流程图;

图4为本申请实施例公开的一种容器调度方法的流程图;

图5为本申请实施例公开的一种调度器的结构示意图;

图6为本申请实施例公开的一种第一计算节点的结构示意图;

图7为本申请实施例公开的一种第二计算节点的结构示意图。

具体实施方式

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

本申请公开了一种容器调度方法,应用于调度器,其流程图如图1所示,包括:

步骤s11、在将第一容器调度至除第一计算节点外的第二计算节点时,基于存储的失败记录,发送问询信息至第二计算节点,以便第二计算节点确定在第二计算节点中第一容器是否能够执行第二事件,失败记录至少包括:在第一计算节点中的第一容器执行第一事件执行失败的情况以及失败原因;

在容器调度系统中,调度器可以将多个容器调度至各个计算节点中,可以将多个容器调度至同一个计算节点中,也可以将多个容器分别调度至不同的计算节点中。在一个计算节点中每个容器分别执行事件,或者,在一个计算节点中多个容器协同协作执行事件。

当调度器将第一容器调度至第一计算节点时,第一容器在第一计算节点中执行第一事件,若在第一计算节点中的第一容器执行第一事件执行失败,则需要将第一容器调度至其他计算节点上,如第二计算节点,在将第一容器调度至第二计算节点中时,在第二计算节点中第一容器执行事件仍可能执行失败。

为了避免某一个容器在不同的计算节点上多次基于相同的原因执行失败,则需要在该容器第一次执行失败时,即获取其执行失败的失败原因,并将其执行失败的失败原因发送至调度器,以便调度器在对该容器进行调度时能够将该失败原因发送至其他计算节点上,以使其他计算节点能够确定若该容器在该计算节点内执行事件时能否克服该失败原因。

具体的,当调度器将第一容器调度至第一计算节点时,第一容器在第一计算节点中执行第一事件,若执行失败,则由第一计算节点进行分析,以确定在第一计算节点中第一容器执行第一事件执行失败的原因,在确定其原因后,将第一容器的失败记录发送至调度器,由调度器对失败记录进行存储。

或者,在第一计算节点将第一容器的失败记录发送至调度器的同时,第一计算节点将第一容器的失败记录进行存储,以便在调度器发送问询信息询问在第一计算节点中其他容器是否能够执行事件时,能够基于第一容器的失败记录确定其他容器是否能够成功执行。

具体的,第一计算节点可以基于第一容器的失败原因以及其他容器的执行相关特征确定两者是否有相关性,以及若有相关性,该相关性是否与第一容器的失败原因相关,从而确定第一计算节点中其他容器执行事件是否能够执行成功。

其中,失败记录不仅包括失败原因,还包括在第一计算节点中第一容器执行第一事件执行失败的事件,以确定该失败原因所对应的事件是在第一计算节点中执行第一事件失败。

另外,失败记录中还可以包括:失败时间,即在第一时刻或第一时段第一计算节点中第一容器执行第一事件执行失败,以便于其他计算节点基于该失败时间进行分析,以确定是否能够克服该失败原因。或者,确定第一容器的失败原因是否与其失败时间相关,若相关,在第一计算节点获取到调度器的问询信息询问第一计算节点中其他容器执行事件是否能够执行成功时,能够基于第一容器的失败时间确定第一计算节点中其他容器执行事件的时间是否与失败时间相关。

调度器在确定第一计算节点中第一容器执行第一事件执行失败时,不仅要存储其失败记录,还需要询问其他计算节点是否能够执行第一容器,具体的,在将第一容器调度至除第一计算节点外的第二计算节点时,基于存储的失败记录,发送问询信息至第二计算节点,以便第二计算节点确定在第二计算节点中第一容器是否能够执行第二事件。

其中,调度器可以将问询信息发送至多个计算节点,这多个计算节点中至少包括第二计算节点,以便获取多个计算节点的反馈信息,从而由调度器从能够克服该失败原因的多个计算节点中选择一个计算节点,使第一容器在选择的该计算节点中执行。

进一步的,第一计算节点将第一容器的失败记录发送至调度器,可以具体为:

当确定执行失败的失败原因时,第一计算节点主动将第一容器的失败记录发送至调度器,以便调度器能够在确定第一计算节点中第一容器执行事件失败时,能够同时获取其失败原因,从而便于在调度器对第一容器进行调度时,直接将失败原因发送至其他计算节点,以使其他计算节点能够基于该失败原因确定在其他计算节点中第一容器执行事件是否能够执行成功。

或者,当确定执行失败的失败原因时,发送失败提示至调度器,使调度器能够基于失败提示发送失败查询请求至第一计算节点,获取失败查询请求,基于失败查询请求将第一容器的失败记录发送至调度器。

当第一计算节点确定第一计算节点中第一容器执行第一事件执行失败时,直接发送失败提示到调度器,以使调度器能够明确第一计算节点中第一容器执行第一事件执行失败这一情况,此时,并不将失败原因同时发送至调度器。进一步的,可以在将失败提示发送到调度器的同时进行分析以确定失败原因,或者,确定第一计算节点中第一容器执行第一事件执行失败后,进行分析以确定失败原因,在确定失败原因后,发送失败提示到调度器。

当调度器获取到第一计算节点发送的失败提示后,调度器可以基于实际需求发送失败查询请求至第一计算节点,具体的,可以为:在需要将第一容器调度至其他计算节点时发送失败查询请求至第一计算节点,或者,在调度器获取到失败提示时,即发送失败查询请求至第一计算节点。

在第一计算节点获取到失败查询请求时,基于该失败查询请求将预先分析得到的第一容器的失败记录发送至调度器,或者,在第一计算节点获取到失败查询请求时,对第一计算节点中第一容器执行第一事件执行失败的失败原因进行分析,得到分析结果,之后将分析得到的失败原因发送至第一计算节点。

步骤s12、获取第二计算节点反馈的在第二计算节点中第一容器能够执行第二事件的反馈信息,将第一容器调度至第二计算节点。

第二计算节点获取到调度器发送的问询信息,会进行判断,其判断的是在第二计算节点中第一容器是否能够执行第二事件,其中,第二事件可以与第一事件相同,也可以与第一事件不同。如果第二计算节点确定在第二计算节点中第一容器能够执行第二事件,则发送反馈信息至调度器,以使调度器确定第二计算节点中第一容器能够执行第二事件。

调度器基于获取到的第二计算节点发送的反馈信息,可直接将第一容器调度至第二计算节点,以使第一容器在第二计算节点中执行第二事件。

本方案中,在第一容器在第一计算节点中执行第一事件执行失败后,调度器基于其失败记录发送问询信息至第一容器需要调度至的第二计算节点,只有在第二计算节点确定其能够使第一容器执行第二事件,才会将第一容器调度至第二计算节点,若第二计算节点发送的反馈信息是在第二计算节点中第一容器不能够执行第二事件,则不会将第一容器调度至第二计算节点,而是继续询问其他计算节点,从而最终确定能够使第一容器执行事件的计算节点,避免直接调度而使第一容器被调度至不能使其执行事件的计算节点中导致的由于相同的失败原因而执行事件执行失败的情况发生,提高了调度的成功率。

进一步的,若同时将问询信息发送至多个计算节点,多个计算节点中可能会有不少于两个计算节点反馈的信息中表明其能够使第一容器执行事件,此时,调度器可以直接将第一容器随机调度至某一个计算节点中,也可以基于第一容器执行的事件与计算节点的匹配度确定将第一容器调度至某一个计算节点中,还可以基于第一容器的其他相关信息确定将第一容器调度至某一个计算节点中。

本实施例公开的容器调度方法,在将第一容器调度至除第一计算节点外的第二计算节点时,基于存储的失败记录,发送问询信息至第二计算节点,以便第二计算节点确定在第二计算节点中第一容器是否能够执行第二事件,失败记录至少包括:在第一计算节点中的第一容器执行第一事件执行失败的情况以及失败原因;获取第二计算节点反馈的在第二计算节点中第一容器能够执行第二事件的反馈信息,将第一容器调度至第二计算节点。本方案通过在将第一容器调度至第二计算节点时,依据存储的历史记录中的失败记录及失败原因,确定在第二计算节点中是否能够正常执行其对应的事件,这就避免了在对容器进行调度时,将容器调度至不能够正常执行相关事件的计算节点中,提高了容器调度的效率,降低了事件执行失败的概率。

本实施例公开了一种容器调度方法,应用于调度器,其流程图如图2所示,包括:

步骤s21、获取第一计算节点发送的第一计算节点中的第一容器对第一事件执行失败的失败记录,并进行存储,其中,失败记录至少包括:在第一计算节点中的第一容器执行第一事件执行失败的情况以及失败原因;

步骤s22、对失败记录进行分析,确定失败原因是否为非持续可解决原因;

步骤s23、若确定失败原因为非持续可解决原因,在确定非持续可解决原因消除时,删除失败记录,将第一容器调度至第一计算节点;

在确定第一计算节点中第一容器对第一事件执行失败时,调度器获取其失败记录,并进行存储之后,对失败记录中的失败原因进行分析,以确定其失败原因是否为非持续可解决原因。

其中,非持续可解决原因为:随着资源信息的变化可能使得在第一计算节点中第一容器对第一事件能够执行成功,即该失败原因为非持续可解决原因,如:容器大小,其内部资源是可以变化的,如:由50g变化为100g,此时,若失败原因为容器资源大小不足,由于资源大小的变化,在第一计算节点中第一容器可能能够对第一事件执行成功。

持续不可解决原因为:无论资源信息如何变化,第一计算节点中第一容器执行第一事件都不能够执行成功,即该失败原因为持续不可解决原因,如:结构不匹配,例如:第一计算节点的内部结构为x86架构,而第一容器的结构为arm架构,此时,由于第一计算节点与第一容器的内部架构不匹配,那么,无论何时,第一计算节点中第一容器执行事件都会执行失败。

因此,在确定第一计算节点中第一容器执行第一事件执行失败时,需要首先确定其失败原因是否为非持续可解决原因,如果失败原因是非持续可解决原因,则只需要在确定该原因消除时,删除存储的该失败记录,并将第一容器再次调度至第一计算节点即可,此时,由于该失败原因已经消除,第一容器在第一计算节点中执行第一事件不再执行失败,是能够执行成功的。

若调度器中存储有失败记录,基于该失败记录,调度器不会将第一容器调度至第一计算节点;若调度器中存储的失败记录被删除后,调度器可以基于该删除操作,确定该失败原因已经消除,从而将第一容器调度至调度器删除的失败记录中记录的第一计算节点。

进一步的,第一计算节点中的第一容器执行第一事件失败的失败原因,至少包括:第一容器的执行相关数据与第一计算节点的相关数据不匹配。

将第一容器调度至第一计算节点,以使第一计算节点中第一容器执行事件,只有在第一容器的执行相关数据与第一计算节点的相关数据匹配时,第一容器才能够成功执行事件,若第一容器的执行相关数据与第一计算节点的相关数据不匹配,则在第一计算节点中第一容器是不能够执行事件的。

其中,第一容器的执行相关数据至少包括以下的一种:第一容器的结构特征,或,第一容器的资源信息,或,第一容器执行需满足的条件信息。

若第一容器的执行相关数据包括第一容器的结构特征,那么,在将第一容器调度至第一计算节点时,需要首先确定第一容器的结构特征与第一计算节点的结构特征匹配,如:第一容器的结构为arm架构,那么,第一计算节点的结构也为arm架构;

若第一容器的执行相关数据包括第一容器的资源信息,那么,在将第一容器调度至第一计算节点时,需要首先确定第一容器的资源信息与第一计算节点的资源信息匹配;

若第一容器的执行相关数据包括第一容器执行需满足的条件信息,那么,在将第一容器调度至第一计算节点时,需要首先确定第一计算节点能够保证第一容器执行需满足的条件信息。

若第一容器的执行相关数据仅包括以上的一项,则当该项不匹配时,第一计算节点中第一容器执行事件会执行失败,若第一容器的执行相关数据包括以上的至少两项,则在以上相关数据中任意一项不匹配时,第一计算节点中第一容器执行事件就会执行失败。

步骤s24、若确定失败原因为持续不可解决原因,在将第一容器调度至除第一计算节点外的第二计算节点时,基于存储的失败记录,发送问询信息至第二计算节点,以便第二计算节点确定在第二计算节点中第一容器是否能够执行第二事件;

步骤s25、获取第二计算节点反馈的在第二计算节点中第一容器能够执行第二事件的反馈信息,将第一容器调度至第二计算节点。

本实施例公开的容器调度方法,在将第一容器调度至除第一计算节点外的第二计算节点时,基于存储的失败记录,发送问询信息至第二计算节点,以便第二计算节点确定在第二计算节点中第一容器是否能够执行第二事件,失败记录至少包括:在第一计算节点中的第一容器执行第一事件执行失败的情况以及失败原因;获取第二计算节点反馈的在第二计算节点中第一容器能够执行第二事件的反馈信息,将第一容器调度至第二计算节点。本方案通过在将第一容器调度至第二计算节点时,依据存储的历史记录中的失败记录及失败原因,确定在第二计算节点中是否能够正常执行其对应的事件,这就避免了在对容器进行调度时,将容器调度至不能够正常执行相关事件的计算节点中,提高了容器调度的效率,降低了事件执行失败的概率。

本实施例公开了一种容器调度方法,应用于第一计算节点,其流程图如图3所示,包括:

步骤s31、若第一计算节点中的第一容器对第一事件执行失败,确定执行失败的失败原因;

步骤s32、将第一容器的失败记录发送至调度器,失败记录至少包括:第一计算节点中的第一容器执行第一事件失败的失败原因。

在容器调度系统中,调度器可以将多个容器调度至各个计算节点中,可以将多个容器调度至同一个计算节点中,也可以将多个容器分别调度至不同的计算节点中。在一个计算节点中每个容器分别执行事件,或者,在一个计算节点中多个容器协同协作执行事件。

当调度器将第一容器调度至第一计算节点时,第一容器在第一计算节点中执行第一事件,若在第一计算节点中的第一容器执行第一事件执行失败,则需要将第一容器调度至其他计算节点上,如第二计算节点,在将第一容器调度至第二计算节点中时,在第二计算节点中第一容器执行事件仍可能执行失败。

为了避免某一个容器在不同的计算节点上多次基于相同的原因执行失败,则需要在该容器第一次执行失败时,即获取其执行失败的失败原因,并将其执行失败的失败原因发送至调度器,以便调度器在对该容器进行调度时能够将该失败原因发送至其他计算节点上,以使其他计算节点能够确定若该容器在该计算节点内执行事件时能否克服该失败原因。

具体的,当调度器将第一容器调度至第一计算节点时,第一容器在第一计算节点中执行第一事件,若执行失败,则由第一计算节点进行分析,以确定在第一计算节点中第一容器执行第一事件执行失败的原因,在确定其原因后,将第一容器的失败记录发送至调度器,由调度器对失败记录进行存储。

或者,在第一计算节点将第一容器的失败记录发送至调度器的同时,第一计算节点将第一容器的失败记录进行存储,以便在调度器发送问询信息询问在第一计算节点中其他容器是否能够执行事件时,能够基于第一容器的失败记录确定其他容器是否能够成功执行。

具体的,第一计算节点可以基于第一容器的失败原因以及其他容器的执行相关特征确定两者是否有相关性,以及若有相关性,该相关性是否与第一容器的失败原因相关,从而确定第一计算节点中其他容器执行事件是否能够执行成功。

其中,失败记录不仅包括失败原因,还包括在第一计算节点中第一容器执行第一事件执行失败的事件,以确定该失败原因所对应的事件是在第一计算节点中执行第一事件失败。

另外,失败记录中还可以包括:失败时间,即在第一时刻或第一时段第一计算节点中第一容器执行第一事件执行失败,以便于其他计算节点基于该失败时间进行分析,以确定是否能够克服该失败原因。或者,确定第一容器的失败原因是否与其失败时间相关,若相关,在第一计算节点获取到调度器的问询信息询问第一计算节点中其他容器执行事件是否能够执行成功时,能够基于第一容器的失败时间确定第一计算节点中其他容器执行事件的时间是否与失败时间相关。

调度器在确定第一计算节点中第一容器执行第一事件执行失败时,不仅要存储其失败记录,还需要询问其他计算节点是否能够执行第一容器,具体的,在将第一容器调度至除第一计算节点外的第二计算节点时,基于存储的失败记录,发送问询信息至第二计算节点,以便第二计算节点确定在第二计算节点中第一容器是否能够执行第二事件。

进一步的,第一计算节点将第一容器的失败记录发送至调度器,可以具体为:

当确定执行失败的失败原因时,第一计算节点主动将第一容器的失败记录发送至调度器,以便调度器能够在确定第一计算节点中第一容器执行事件失败时,能够同时获取其失败原因,从而便于在调度器对第一容器进行调度时,直接将失败原因发送至其他计算节点,以使其他计算节点能够基于该失败原因确定在其他计算节点中第一容器执行事件是否能够执行成功。

或者,当确定执行失败的失败原因时,发送失败提示至调度器,使调度器能够基于失败提示发送失败查询请求至第一计算节点,获取失败查询请求,基于失败查询请求将第一容器的失败记录发送至调度器。

当第一计算节点确定第一计算节点中第一容器执行第一事件执行失败时,直接发送失败提示到调度器,以使调度器能够明确第一计算节点中第一容器执行第一事件执行失败这一情况,此时,并不将失败原因同时发送至调度器。进一步的,可以在将失败提示发送到调度器的同时进行分析以确定失败原因,或者,确定第一计算节点中第一容器执行第一事件执行失败后,进行分析以确定失败原因,在确定失败原因后,发送失败提示到调度器。

当调度器获取到第一计算节点发送的失败提示后,调度器可以基于实际需求发送失败查询请求至第一计算节点,具体的,可以为:在需要将第一容器调度至其他计算节点时发送失败查询请求至第一计算节点,或者,在调度器获取到失败提示时,即发送失败查询请求至第一计算节点。

在第一计算节点获取到失败查询请求时,基于该失败查询请求将预先分析得到的第一容器的失败记录发送至调度器,或者,在第一计算节点获取到失败查询请求时,对第一计算节点中第一容器执行第一事件执行失败的失败原因进行分析,得到分析结果,之后将分析得到的失败原因发送至第一计算节点。

本实施例公开的容器调度方法,若第一计算节点中的第一容器对第一事件执行失败,确定执行失败的失败原因,若第一容器的失败记录发送至调度器,失败记录至少包括:第一计算节点中的第一容器执行第一事件失败的失败原因。本方案中在确定第一计算节点中的第一容器对第一事件执行失败,就会确定其失败原因,并将其发送至调度器,以便调度器在对第一容器进行调度时,能够基于该失败原因进行调度,从而避免在将第一容器调度至其他计算节点时,由于同样的失败原因再次执行事件失败,这就避免了在对容器进行调度时,将容器调度至不能够正常执行相关事件的计算节点中,提高了容器调度的效率,降低了事件执行失败的概率。

本实施例公开了一种容器调度方法,应用于第二计算节点,其流程图如图4所示,包括:

步骤s41、获取调度器发送的问询信息,基于问询信息确定在第二计算节点中第一容器是否能够执行第二事件;

步骤s42、若在第二计算节点中第一容器能够执行第二事件,发送反馈信息至调度器,以使调度器基于反馈信息将第一容器调度至第二计算节点;

步骤s43、接收处理指令,基于处理指令第一容器在第二计算节点中执行第二事件。

第二计算节点获取到调度器发送的问询信息,会进行判断,其判断的是在第二计算节点中第一容器是否能够执行第二事件,其中,第二事件可以与第一事件相同,也可以与第一事件不同。如果第二计算节点确定在第二计算节点中第一容器能够执行第二事件,则发送反馈信息至调度器,以使调度器确定第二计算节点中第一容器能够执行第二事件。

调度器基于获取到的第二计算节点发送的反馈信息,可直接将第一容器调度至第二计算节点,以使第一容器在第二计算节点中执行第二事件。

本方案中,在第一容器在第一计算节点中执行第一事件执行失败后,调度器基于其失败记录发送问询信息至第一容器需要调度至的第二计算节点,只有在第二计算节点确定其能够使第一容器执行第二事件,才会将第一容器调度至第二计算节点,若第二计算节点发送的反馈信息是在第二计算节点中第一容器不能够执行第二事件,则不会将第一容器调度至第二计算节点,而是继续询问其他计算节点,从而最终确定能够使第一容器执行事件的计算节点,避免直接调度而使第一容器被调度至不能使其执行事件的计算节点中导致的由于相同的失败原因而执行事件执行失败的情况发生,提高了调度的成功率。

进一步的,若调度器同时将问询信息发送至多个计算节点,多个计算节点中可能会有不少于两个计算节点反馈的信息中表明其能够使第一容器执行事件,此时,调度器可以直接将第一容器随机调度至某一个计算节点中,也可以基于第一容器执行的事件与计算节点的匹配度确定将第一容器调度至某一个计算节点中,还可以基于第一容器的其他相关信息确定将第一容器调度至某一个计算节点中。

需要说明的是,第一计算节点与第二计算节点可以为同样的计算节点。例如:第一计算节点中第一容器执行第一事件执行失败,那么,调度器在对第一容器进行调度时,会发送问询信息至除第一计算节点外的其他计算节点,如:第二计算节点;第二计算节点中第二容器执行第三事件执行失败,那么,调度器在对第二容器进行调度时,会发送问询信息至除第二计算节点外的其他计算节点,如:第一计算节点。因此,无论是哪个计算节点,均会既有容器执行失败的情况,也会有被问询的情况。因此,本方案中的第一计算节点与第二计算节点仅作为区分,而并不表示真实含义。

本实施例公开的容器调度方法,获取调度器发送的问询信息,基于问询信息确定在第二计算节点中第一容器是否能够执行第二事件,若在第二计算节点中第一容器能够执行第二事件,发送反馈信息至调度器,以使调度器基于反馈信息将第一容器调度至第二计算节点,接收处理指令,基于处理质量第一容器在第二计算节点中执行第二事件。本方案在进行调度时,首先进行问询,以确定第二计算节点中第一容器是否能够执行第二事件,并在其能够执行第二事件时,才将第一容器调度至第二计算节点,这就避免了在对容器进行调度时,将容器调度至不能够正常执行相关事件的计算节点中,提高了容器调度的效率,降低了事件执行失败的概率。

本实施例公开了一种调度器,其结构示意如图5所示,包括:

第一发送单元51及第一获取单元52。

其中,第一发送单元51用于在将第一容器调度至除第一计算节点外的第二计算节点时,基于存储的失败记录,发送问询信息至第二计算节点,以便第二计算节点确定在第二计算节点中第一容器是否能够执行第二事件,其中,失败记录至少包括:在第一计算节点中的第一容器执行第一事件执行失败的情况以及失败原因;

第一获取单元52用于获取第二计算节点反馈的在第二计算节点中第一容器能够执行第二事件的反馈信息,将第一容器调度至第二计算节点。

在容器调度系统中,调度器可以将多个容器调度至各个计算节点中,可以将多个容器调度至同一个计算节点中,也可以将多个容器分别调度至不同的计算节点中。在一个计算节点中每个容器分别执行事件,或者,在一个计算节点中多个容器协同协作执行事件。

当调度器将第一容器调度至第一计算节点时,第一容器在第一计算节点中执行第一事件,若在第一计算节点中的第一容器执行第一事件执行失败,则需要将第一容器调度至其他计算节点上,如第二计算节点,在将第一容器调度至第二计算节点中时,在第二计算节点中第一容器执行事件仍可能执行失败。

为了避免某一个容器在不同的计算节点上多次基于相同的原因执行失败,则需要在该容器第一次执行失败时,即获取其执行失败的失败原因,并将其执行失败的失败原因发送至调度器,以便调度器在对该容器进行调度时能够将该失败原因发送至其他计算节点上,以使其他计算节点能够确定若该容器在该计算节点内执行事件时能否克服该失败原因。

具体的,当调度器将第一容器调度至第一计算节点时,第一容器在第一计算节点中执行第一事件,若执行失败,则由第一计算节点进行分析,以确定在第一计算节点中第一容器执行第一事件执行失败的原因,在确定其原因后,将第一容器的失败记录发送至调度器,由调度器对失败记录进行存储。

或者,在第一计算节点将第一容器的失败记录发送至调度器的同时,第一计算节点将第一容器的失败记录进行存储,以便在调度器发送问询信息询问在第一计算节点中其他容器是否能够执行事件时,能够基于第一容器的失败记录确定其他容器是否能够成功执行。

具体的,第一计算节点可以基于第一容器的失败原因以及其他容器的执行相关特征确定两者是否有相关性,以及若有相关性,该相关性是否与第一容器的失败原因相关,从而确定第一计算节点中其他容器执行事件是否能够执行成功。

其中,失败记录不仅包括失败原因,还包括在第一计算节点中第一容器执行第一事件执行失败的事件,以确定该失败原因所对应的事件是在第一计算节点中执行第一事件失败。

另外,失败记录中还可以包括:失败时间,即在第一时刻或第一时段第一计算节点中第一容器执行第一事件执行失败,以便于其他计算节点基于该失败时间进行分析,以确定是否能够克服该失败原因。或者,确定第一容器的失败原因是否与其失败时间相关,若相关,在第一计算节点获取到调度器的问询信息询问第一计算节点中其他容器执行事件是否能够执行成功时,能够基于第一容器的失败时间确定第一计算节点中其他容器执行事件的时间是否与失败时间相关。

调度器在确定第一计算节点中第一容器执行第一事件执行失败时,不仅要存储其失败记录,还需要询问其他计算节点是否能够执行第一容器,具体的,在将第一容器调度至除第一计算节点外的第二计算节点时,基于存储的失败记录,发送问询信息至第二计算节点,以便第二计算节点确定在第二计算节点中第一容器是否能够执行第二事件。

其中,调度器可以将问询信息发送至多个计算节点,这多个计算节点中至少包括第二计算节点,以便获取多个计算节点的反馈信息,从而由调度器从能够克服该失败原因的多个计算节点中选择一个计算节点,使第一容器在选择的该计算节点中执行。

进一步的,第一计算节点将第一容器的失败记录发送至调度器,可以具体为:

当确定执行失败的失败原因时,第一计算节点主动将第一容器的失败记录发送至调度器,以便调度器能够在确定第一计算节点中第一容器执行事件失败时,能够同时获取其失败原因,从而便于在调度器对第一容器进行调度时,直接将失败原因发送至其他计算节点,以使其他计算节点能够基于该失败原因确定在其他计算节点中第一容器执行事件是否能够执行成功。

或者,当确定执行失败的失败原因时,发送失败提示至调度器,使调度器能够基于失败提示发送失败查询请求至第一计算节点,获取失败查询请求,基于失败查询请求将第一容器的失败记录发送至调度器。

当第一计算节点确定第一计算节点中第一容器执行第一事件执行失败时,直接发送失败提示到调度器,以使调度器能够明确第一计算节点中第一容器执行第一事件执行失败这一情况,此时,并不将失败原因同时发送至调度器。进一步的,可以在将失败提示发送到调度器的同时进行分析以确定失败原因,或者,确定第一计算节点中第一容器执行第一事件执行失败后,进行分析以确定失败原因,在确定失败原因后,发送失败提示到调度器。

当调度器获取到第一计算节点发送的失败提示后,调度器可以基于实际需求发送失败查询请求至第一计算节点,具体的,可以为:在需要将第一容器调度至其他计算节点时发送失败查询请求至第一计算节点,或者,在调度器获取到失败提示时,即发送失败查询请求至第一计算节点。

在第一计算节点获取到失败查询请求时,基于该失败查询请求将预先分析得到的第一容器的失败记录发送至调度器,或者,在第一计算节点获取到失败查询请求时,对第一计算节点中第一容器执行第一事件执行失败的失败原因进行分析,得到分析结果,之后将分析得到的失败原因发送至第一计算节点。

第二计算节点获取到调度器发送的问询信息,会进行判断,其判断的是在第二计算节点中第一容器是否能够执行第二事件,其中,第二事件可以与第一事件相同,也可以与第一事件不同。如果第二计算节点确定在第二计算节点中第一容器能够执行第二事件,则发送反馈信息至调度器,以使调度器确定第二计算节点中第一容器能够执行第二事件。

调度器基于获取到的第二计算节点发送的反馈信息,可直接将第一容器调度至第二计算节点,以使第一容器在第二计算节点中执行第二事件。

本方案中,在第一容器在第一计算节点中执行第一事件执行失败后,调度器基于其失败记录发送问询信息至第一容器需要调度至的第二计算节点,只有在第二计算节点确定其能够使第一容器执行第二事件,才会将第一容器调度至第二计算节点,若第二计算节点发送的反馈信息是在第二计算节点中第一容器不能够执行第二事件,则不会将第一容器调度至第二计算节点,而是继续询问其他计算节点,从而最终确定能够使第一容器执行事件的计算节点,避免直接调度而使第一容器被调度至不能使其执行事件的计算节点中导致的由于相同的失败原因而执行事件执行失败的情况发生,提高了调度的成功率。

进一步的,若同时将问询信息发送至多个计算节点,多个计算节点中可能会有不少于两个计算节点反馈的信息中表明其能够使第一容器执行事件,此时,调度器可以直接将第一容器随机调度至某一个计算节点中,也可以基于第一容器执行的事件与计算节点的匹配度确定将第一容器调度至某一个计算节点中,还可以基于第一容器的其他相关信息确定将第一容器调度至某一个计算节点中。

进一步的,在获取到第一计算节点发送的第一计算节点中的第一容器对第一事件执行失败的失败记录,并进行存储时,对失败记录进行分析,确定失败原因是否为非持续可解决原因,若确定失败原因为非持续可解决原因,在确定非持续可解决原因消除时,删除失败记录,将第一容器调度至第一计算节点;若确定失败原因为持续不可解决原因,在将第一容器调度至除第一计算节点外的第二计算节点时,基于存储的失败记录,发送问询信息至第二计算节点,以便第二计算节点确定在第二计算节点中第一容器是否能够执行第二事件。

在确定第一计算节点中第一容器对第一事件执行失败时,调度器获取其失败记录,并进行存储之后,对失败记录中的失败原因进行分析,以确定其失败原因是否为非持续可解决原因。

其中,非持续可解决原因为:随着资源信息的变化可能使得在第一计算节点中第一容器对第一事件能够执行成功,即该失败原因为非持续可解决原因,如:容器大小,其内部资源是可以变化的,如:由50g变化为100g,此时,若失败原因为容器资源大小不足,由于资源大小的变化,在第一计算节点中第一容器可能能够对第一事件执行成功。

持续不可解决原因为:无论资源信息如何变化,第一计算节点中第一容器执行第一事件都不能够执行成功,即该失败原因为持续不可解决原因,如:结构不匹配,例如:第一计算节点的内部结构为x86架构,而第一容器的结构为arm架构,此时,由于第一计算节点与第一容器的内部架构不匹配,那么,无论何时,第一计算节点中第一容器执行事件都会执行失败。

因此,在确定第一计算节点中第一容器执行第一事件执行失败时,需要首先确定其失败原因是否为非持续可解决原因,如果失败原因是非持续可解决原因,则只需要在确定该原因消除时,删除存储的该失败记录,并将第一容器再次调度至第一计算节点即可,此时,由于该失败原因已经消除,第一容器在第一计算节点中执行第一事件不再执行失败,是能够执行成功的。

若调度器中存储有失败记录,基于该失败记录,调度器不会将第一容器调度至第一计算节点;若调度器中存储的失败记录被删除后,调度器可以基于该删除操作,确定该失败原因已经消除,从而将第一容器调度至调度器删除的失败记录中记录的第一计算节点。

进一步的,第一计算节点中的第一容器执行第一事件失败的失败原因,至少包括:第一容器的执行相关数据与第一计算节点的相关数据不匹配。

将第一容器调度至第一计算节点,以使第一计算节点中第一容器执行事件,只有在第一容器的执行相关数据与第一计算节点的相关数据匹配时,第一容器才能够成功执行事件,若第一容器的执行相关数据与第一计算节点的相关数据不匹配,则在第一计算节点中第一容器是不能够执行事件的。

其中,第一容器的执行相关数据至少包括以下的一种:第一容器的结构特征,或,第一容器的资源信息,或,第一容器执行需满足的条件信息。

若第一容器的执行相关数据包括第一容器的结构特征,那么,在将第一容器调度至第一计算节点时,需要首先确定第一容器的结构特征与第一计算节点的结构特征匹配,如:第一容器的结构为arm架构,那么,第一计算节点的结构也为arm架构;

若第一容器的执行相关数据包括第一容器的资源信息,那么,在将第一容器调度至第一计算节点时,需要首先确定第一容器的资源信息与第一计算节点的资源信息匹配;

若第一容器的执行相关数据包括第一容器执行需满足的条件信息,那么,在将第一容器调度至第一计算节点时,需要首先确定第一计算节点能够保证第一容器执行需满足的条件信息。

若第一容器的执行相关数据仅包括以上的一项,则当该项不匹配时,第一计算节点中第一容器执行事件会执行失败,若第一容器的执行相关数据包括以上的至少两项,则在以上相关数据中任意一项不匹配时,第一计算节点中第一容器执行事件就会执行失败。

本实施例公开的调度器,在将第一容器调度至除第一计算节点外的第二计算节点时,基于存储的失败记录,发送问询信息至第二计算节点,以便第二计算节点确定在第二计算节点中第一容器是否能够执行第二事件,失败记录至少包括:在第一计算节点中的第一容器执行第一事件执行失败的情况以及失败原因;获取第二计算节点反馈的在第二计算节点中第一容器能够执行第二事件的反馈信息,将第一容器调度至第二计算节点。本方案通过在将第一容器调度至第二计算节点时,依据存储的历史记录中的失败记录及失败原因,确定在第二计算节点中是否能够正常执行其对应的事件,这就避免了在对容器进行调度时,将容器调度至不能够正常执行相关事件的计算节点中,提高了容器调度的效率,降低了事件执行失败的概率。

本实施例公开了一种第一计算节点,其结构示意图如图6所示,包括:

确定单元61及第二发送单元62。

确定单元61用于在第一计算节点中的第一容器对第一事件执行失败时,确定执行失败的失败原因;

第二发送单元62用于将第一容器的失败记录发送至调度器,失败记录至少包括:第一计算节点中的第一容器执行第一事件失败的失败原因。

在容器调度系统中,调度器可以将多个容器调度至各个计算节点中,可以将多个容器调度至同一个计算节点中,也可以将多个容器分别调度至不同的计算节点中。在一个计算节点中每个容器分别执行事件,或者,在一个计算节点中多个容器协同协作执行事件。

当调度器将第一容器调度至第一计算节点时,第一容器在第一计算节点中执行第一事件,若在第一计算节点中的第一容器执行第一事件执行失败,则需要将第一容器调度至其他计算节点上,如第二计算节点,在将第一容器调度至第二计算节点中时,在第二计算节点中第一容器执行事件仍可能执行失败。

为了避免某一个容器在不同的计算节点上多次基于相同的原因执行失败,则需要在该容器第一次执行失败时,即获取其执行失败的失败原因,并将其执行失败的失败原因发送至调度器,以便调度器在对该容器进行调度时能够将该失败原因发送至其他计算节点上,以使其他计算节点能够确定若该容器在该计算节点内执行事件时能否克服该失败原因。

具体的,当调度器将第一容器调度至第一计算节点时,第一容器在第一计算节点中执行第一事件,若执行失败,则由第一计算节点进行分析,以确定在第一计算节点中第一容器执行第一事件执行失败的原因,在确定其原因后,将第一容器的失败记录发送至调度器,由调度器对失败记录进行存储。

或者,在第一计算节点将第一容器的失败记录发送至调度器的同时,第一计算节点将第一容器的失败记录进行存储,以便在调度器发送问询信息询问在第一计算节点中其他容器是否能够执行事件时,能够基于第一容器的失败记录确定其他容器是否能够成功执行。

具体的,第一计算节点可以基于第一容器的失败原因以及其他容器的执行相关特征确定两者是否有相关性,以及若有相关性,该相关性是否与第一容器的失败原因相关,从而确定第一计算节点中其他容器执行事件是否能够执行成功。

其中,失败记录不仅包括失败原因,还包括在第一计算节点中第一容器执行第一事件执行失败的事件,以确定该失败原因所对应的事件是在第一计算节点中执行第一事件失败。

另外,失败记录中还可以包括:失败时间,即在第一时刻或第一时段第一计算节点中第一容器执行第一事件执行失败,以便于其他计算节点基于该失败时间进行分析,以确定是否能够克服该失败原因。或者,确定第一容器的失败原因是否与其失败时间相关,若相关,在第一计算节点获取到调度器的问询信息询问第一计算节点中其他容器执行事件是否能够执行成功时,能够基于第一容器的失败时间确定第一计算节点中其他容器执行事件的时间是否与失败时间相关。

调度器在确定第一计算节点中第一容器执行第一事件执行失败时,不仅要存储其失败记录,还需要询问其他计算节点是否能够执行第一容器,具体的,在将第一容器调度至除第一计算节点外的第二计算节点时,基于存储的失败记录,发送问询信息至第二计算节点,以便第二计算节点确定在第二计算节点中第一容器是否能够执行第二事件。

进一步的,第一计算节点将第一容器的失败记录发送至调度器,可以具体为:

当确定执行失败的失败原因时,第一计算节点主动将第一容器的失败记录发送至调度器,以便调度器能够在确定第一计算节点中第一容器执行事件失败时,能够同时获取其失败原因,从而便于在调度器对第一容器进行调度时,直接将失败原因发送至其他计算节点,以使其他计算节点能够基于该失败原因确定在其他计算节点中第一容器执行事件是否能够执行成功。

或者,当确定执行失败的失败原因时,发送失败提示至调度器,使调度器能够基于失败提示发送失败查询请求至第一计算节点,获取失败查询请求,基于失败查询请求将第一容器的失败记录发送至调度器。

当第一计算节点确定第一计算节点中第一容器执行第一事件执行失败时,直接发送失败提示到调度器,以使调度器能够明确第一计算节点中第一容器执行第一事件执行失败这一情况,此时,并不将失败原因同时发送至调度器。进一步的,可以在将失败提示发送到调度器的同时进行分析以确定失败原因,或者,确定第一计算节点中第一容器执行第一事件执行失败后,进行分析以确定失败原因,在确定失败原因后,发送失败提示到调度器。

当调度器获取到第一计算节点发送的失败提示后,调度器可以基于实际需求发送失败查询请求至第一计算节点,具体的,可以为:在需要将第一容器调度至其他计算节点时发送失败查询请求至第一计算节点,或者,在调度器获取到失败提示时,即发送失败查询请求至第一计算节点。

在第一计算节点获取到失败查询请求时,基于该失败查询请求将预先分析得到的第一容器的失败记录发送至调度器,或者,在第一计算节点获取到失败查询请求时,对第一计算节点中第一容器执行第一事件执行失败的失败原因进行分析,得到分析结果,之后将分析得到的失败原因发送至第一计算节点。

本实施例公开的第一计算节点,若第一计算节点中的第一容器对第一事件执行失败,确定执行失败的失败原因,若第一容器的失败记录发送至调度器,失败记录至少包括:第一计算节点中的第一容器执行第一事件失败的失败原因。本方案中在确定第一计算节点中的第一容器对第一事件执行失败,就会确定其失败原因,并将其发送至调度器,以便调度器在对第一容器进行调度时,能够基于该失败原因进行调度,从而避免在将第一容器调度至其他计算节点时,由于同样的失败原因再次执行事件失败,这就避免了在对容器进行调度时,将容器调度至不能够正常执行相关事件的计算节点中,提高了容器调度的效率,降低了事件执行失败的概率。

本实施例公开了一种第二计算节点,其结构示意图如图7所示,包括:

第二获取单元71,第三发送单元72及执行单元73。

其中,第二获取单元71用于获取调度器发送的问询信息,基于问询信息确定在第二计算节点中第一容器是否能够执行第二事件;

第三发送单元72用于在第二计算节点中第一容器能够执行第二事件时,发送反馈信息至调度器,以使调度器基于反馈信息将第一容器调度至第二计算节点;

执行单元73用于接收处理指令,基于处理指令第一容器在第二计算节点中执行第二事件。

第二计算节点获取到调度器发送的问询信息,会进行判断,其判断的是在第二计算节点中第一容器是否能够执行第二事件,其中,第二事件可以与第一事件相同,也可以与第一事件不同。如果第二计算节点确定在第二计算节点中第一容器能够执行第二事件,则发送反馈信息至调度器,以使调度器确定第二计算节点中第一容器能够执行第二事件。

调度器基于获取到的第二计算节点发送的反馈信息,可直接将第一容器调度至第二计算节点,以使第一容器在第二计算节点中执行第二事件。

本方案中,在第一容器在第一计算节点中执行第一事件执行失败后,调度器基于其失败记录发送问询信息至第一容器需要调度至的第二计算节点,只有在第二计算节点确定其能够使第一容器执行第二事件,才会将第一容器调度至第二计算节点,若第二计算节点发送的反馈信息是在第二计算节点中第一容器不能够执行第二事件,则不会将第一容器调度至第二计算节点,而是继续询问其他计算节点,从而最终确定能够使第一容器执行事件的计算节点,避免直接调度而使第一容器被调度至不能使其执行事件的计算节点中导致的由于相同的失败原因而执行事件执行失败的情况发生,提高了调度的成功率。

进一步的,若调度器同时将问询信息发送至多个计算节点,多个计算节点中可能会有不少于两个计算节点反馈的信息中表明其能够使第一容器执行事件,此时,调度器可以直接将第一容器随机调度至某一个计算节点中,也可以基于第一容器执行的事件与计算节点的匹配度确定将第一容器调度至某一个计算节点中,还可以基于第一容器的其他相关信息确定将第一容器调度至某一个计算节点中。

需要说明的是,第一计算节点与第二计算节点可以为同样的计算节点。例如:第一计算节点中第一容器执行第一事件执行失败,那么,调度器在对第一容器进行调度时,会发送问询信息至除第一计算节点外的其他计算节点,如:第二计算节点;第二计算节点中第二容器执行第三事件执行失败,那么,调度器在对第二容器进行调度时,会发送问询信息至除第二计算节点外的其他计算节点,如:第一计算节点。因此,无论是哪个计算节点,均会既有容器执行失败的情况,也会有被问询的情况。因此,本方案中的第一计算节点与第二计算节点仅作为区分,而并不表示真实含义。

本实施例公开的第二计算节点,获取调度器发送的问询信息,基于问询信息确定在第二计算节点中第一容器是否能够执行第二事件,若在第二计算节点中第一容器能够执行第二事件,发送反馈信息至调度器,以使调度器基于反馈信息将第一容器调度至第二计算节点,接收处理指令,基于处理质量第一容器在第二计算节点中执行第二事件。本方案在进行调度时,首先进行问询,以确定第二计算节点中第一容器是否能够执行第二事件,并在其能够执行第二事件时,才将第一容器调度至第二计算节点,这就避免了在对容器进行调度时,将容器调度至不能够正常执行相关事件的计算节点中,提高了容器调度的效率,降低了事件执行失败的概率。

本实施例公开了一种存储介质,用于至少存储一组指令集,其中,指令集用于被调用并至少执行如上所述任一项所述的容器调度方法。

本说明书中各个实施例采用递进的方式描述,每个实施例重点说明的都是与其他实施例的不同之处,各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言,由于其与实施例公开的方法相对应,所以描述的比较简单,相关之处参见方法部分说明即可。

专业人员还可以进一步意识到,结合本文中所公开的实施例描述的各示例的单元及算法步骤,能够以电子硬件、计算机软件或者二者的结合来实现,为了清楚地说明硬件和软件的可互换性,在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本申请的范围。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块,或者二者的结合来实施。软件模块可以置于随机存储器(ram)、内存、只读存储器(rom)、电可编程rom、电可擦除可编程rom、寄存器、硬盘、可移动磁盘、cd-rom、或技术领域内所公知的任意其它形式的存储介质中。

对所公开的实施例的上述说明,使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的,本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下,在其它实施例中实现。因此,本申请将不会被限制于本文所示的这些实施例,而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1