一种信息处理方法、控制节点及计算机可读存储介质

技术领域

本申请涉及信息处理领域，尤其涉及一种信息处理方法、控制节点及计算机可读存储介质。

背景技术

Kubernetes(容器编排系统)提供了大规模容器部署、编排与管理能力，可以被用来创建混合云、容器化中间件等；其中，在创建待创建的中间件时，通常是由容器编排系统根据待创建的中间件对应的需求信息和每个Node节点的状态信息，从多个Node节点中确定目标Node节点，之后在目标Node节点上创建待创建的中间件；但是，针对每一待创建的中间件均采用这种方式来确定目标Node节点，使得确定的目标Node节点的准确率低。

发明内容

为解决上述技术问题，本申请实施例期望提供一种信息处理方法、控制节点及计算机可读存储介质，解决了确定目标Node节点的准确率低的问题，提高了确定目标Node节点的准确率。

本申请的技术方案是这样实现的：

一种信息处理方法，应用于容器编排系统中的控制节点，所述方法包括：

接收用于创建中间件的创建请求，并基于所述创建请求确定待创建的中间件的类型；

在所述类型为第一类型且所述创建请求中未携带业务节点的标识的情况下，基于所述待创建的中间件对应的需求信息和所述容器编排系统的状态信息，从多个业务节点中确定用于创建所述待创建的中间件的目标业务节点；其中，所述业务节点为所述容器编排系统中除所述控制节点之外的节点；

在所述类型为第二类型的情况下，基于所述需求信息和每个业务节点的状态信息，从所述多个业务节点中确定所述目标业务节点；

控制在所述目标业务节点上创建所述待创建的中间件。

上述方案中，所述基于所述待创建的中间件对应的需求信息和所述容器编排系统的状态信息，从多个业务节点中确定用于创建所述待创建的中间件的目标业务节点，包括：

获取所述容器编排系统的状态信息；

基于所述需求信息和所述容器编排系统的状态信息，确定表征在每个业务节点上创建所述待创建的中间件后所述容器编排系统对应的状态值；其中，所述状态值表征所述容器编排系统的性能；

基于所述状态值从所述多个业务节点中确定所述目标业务节点。

上述方案中，获取所述容器编排系统的状态信息，包括：

在所述创建请求为目标周期内初始接收到的创建请求的情况下，确定所述容器编排系统的当前状态信息；

在所述创建请求为所述目标周期内非初始接收到的创建请求的情况下，获取所述容器编排系统的预测状态信息；其中，所述预测状态信息是预测得到的在上一次选定的业务节点上创建中间件后所述容器编排系统的状态信息。

上述方案中，所述基于所述需求信息和所述容器编排系统的状态信息，确定表征在每个业务节点上创建所述待创建的中间件后所述容器编排系统对应的状态值，包括：

基于目标时间窗口对多个所述创建请求进行分组，得到多组创建请求；

针对每组创建请求，基于每一创建请求中的需求信息和所述容器编排系统的状态信息，确定所述每一创建请求对应的多个状态值。

上述方案中，所述基于每一创建请求中的需求信息和所述容器编排系统的状态信息，确定所述每一创建请求对应的多个状态值，包括：

基于每一需求信息和所述容器编排系统的状态信息，预测在每个业务节点上创建所述待创建的中间件后所述容器编排系统的预测状态；

基于每个业务节点对应的所述预测状态，确定所述预测状态对应的状态值。

上述方案中，所述基于所述状态值从所述多个业务节点中确定所述目标业务节点，包括：

针对所述每一需求信息，从所述多个状态值中确定满足状态值条件的目标状态值；

确定所述目标状态值对应的业务节点为所述目标业务节点。

上述方案中，所述方法还包括：

在所述类型为第一类型，且所述创建请求中携带有所述标识的情况下，确定所述标识对应的业务节点为目标业务节点。

上述方案中，所述基于所述需求信息和每个业务节点的状态信息，从所述多个业务节点中确定所述目标业务节点，包括：

基于所述需求信息，从多个状态信息中确定满足状态条件的目标状态信息；

确定所述目标状态信息对应的业务节点为所述目标业务节点。

一种控制节点，所述控制节点包括：处理器、存储器和通信总线；

所述通信总线用于实现处理器和存储器之间的通信连接；

所述处理器用于执行存储器中的信息处理程序，以实现上述信息处理方法的步骤。

一种计算机可读存储介质，所述计算机可读存储介质存储有一个或者多个程序，所述一个或者多个程序可被一个或者多个处理器执行，以实现上述信息处理方法的步骤。

本申请实施例所提供的信息处理方法、控制节点及计算机可读存储介质，接收用于创建中间件的创建请求，并基于创建请求确定待创建的中间件的类型；在类型为第一类型且创建请求中未携带业务节点的标识的情况下，基于待创建的中间件对应的需求信息和容器编排系统的状态信息，从多个业务节点中确定用于创建待创建的中间件的目标业务节点；其中，业务节点为容器编排系统中除控制节点之外的节点；在类型为第二类型的情况下，基于需求信息和每个业务节点的状态信息，从多个业务节点中确定目标业务节点；控制在目标业务节点上创建待创建的中间件；如此，可以基于待创建的中间件的不同类型，采用不同的信息来确定目标业务节点，不再如相关技术中针对每一待创建的中间件都是基于需求信息和每一业务节点的状态信息来确定目标业务节点，提高了确定的目标业务节点的准确率。

附图说明

图1为本申请实施例提供的一种信息处理方法的流程示意图；

图2为本申请实施例提供的另一种信息处理方法的流程示意图；

图3为本申请实施例提供的一种Q-learning调度模块的结构示意图；

图4为本申请实施例提供的又一种信息处理方法的流程示意图；

图5为本申请实施例提供的一种控制节点的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。

应当理解，此处所描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

本申请实施例提供一种信息处理方法，该方法可以应用于容器编排系统中的控制节点，参照图1所示，该方法包括以下步骤：

步骤101、接收用于创建中间件的创建请求，并基于创建请求确定待创建的中间件的类型。

在本申请实施例中，容器编排系统可以简称为k8s；控制节点接收客户端发送的用于创建中间件的创建请求，并对创建请求进行解析，从创建请求中获取待创建的中间件的类型。其中，待创建的中间件的类型包括第一类型和第二类型；其中，第一类型为可以为单个pod；第二类型可以为多个pod。pod是可以在容器编排系统中创建和管理的最小的可部署的计算单元，pod是由至少一个容器组成的。其中，待创建的中间件也可以理解为待创建的容器化中间件。

需要说明的是，待创建的中间件的类型可以是创建请求中携带的，控制节点对创建请求进行解析后可以直接从创建请求中获取；待创建的中间件的类型还可以是控制节点对创建请求中的需求信息进行分析后得到的；需求信息为待创建的中间件对应的需求信息。

在一种可行的实现方式中，待创建的中间件可以为Redis、MongoDB、ElasticSearch、Kafka等容器化中间件。

步骤102、在类型为第一类型且创建请求中未携带业务节点的标识的情况下，基于待创建的中间件对应的需求信息和容器编排系统的状态信息，从多个业务节点中确定用于创建待创建的中间件的目标业务节点。

其中，状态信息可以是容器编排系统的当前状态信息，还可以是容器编排系统的预测状态信息。

在本申请实施例中，业务节点为k8s中除控制节点(Master节点)之外的Node节点；在类型为第一类型且创建请求中未携带业务节点的标识的情况下，则表明用户未指定业务节点来创建类型为单个pod的中间件，此时控制节点可以自主确定目标业务节点来创建待创建的中间件。其中，在确定目标业务节点时，控制节点可以基于需求信息和容器编排系统的状态信息，预测分别在每个业务节点上创建待创建的中间件后容器编排系统的预测状态，基于每个业务节点对应的预测状态，从多个业务节点中确定目标业务节点。

在一种可行的实现方式中，需求信息可以是创建待创建中间件时需要的中央处理器(Central Processing Unit，CPU)的数量、内存的大小和存储的大小。

需要说明的是，在步骤102之后可以执行步骤104。

步骤103、在类型为第二类型的情况下，基于需求信息和每个业务节点的状态信息，从多个业务节点中确定目标业务节点。

其中，业务节点为容器编排系统中除控制节点之外的节点。

在本申请实施例中，在类型为第二类型的情况下，可以对每个业务节点进行检测，获取每个业务节点的状态信息，并基于需求信息和每个业务节点的状态信息，对多个业务节点进行筛选得到目标业务节点。

需要说明的是，业务节点的状态信息包括业务节点的CPU剩余量、内存剩余量、存储剩余量、处理的业务类型和业务量等信息。

在一种可行的实现方式中，在类型为第二类型的情况下，控制节点可以根据需求信息和业务节点的状态信息，对多个业务节点进行筛选得到目标业务节点。

需要说明的是，在步骤103之后可以执行步骤104。

步骤104、控制在目标业务节点上创建待创建的中间件。

在本申请实施例中，在确定目标业务节点后，控制节点可以主动修改容器编排系统中用于调度节点的配置文件，以通过修改后的配置文件，控制在目标业务节点创建待创建的中间件；其中，该配置文件具体可以为values.yaml配置文件。

在一种可行的实现方式中，控制节点可以通过动态修改values.yaml配置文件中的Node Selector选项，配置在目标业务节点上创建待创建的中间件，并基于修改后的values.yaml配置文件控制在目标业务节点上创建待创建的中间件。

本申请实施例所提供的信息处理方法，接收用于创建中间件的创建请求，并基于创建请求确定待创建的中间件的类型；在类型为第一类型且创建请求中未携带业务节点的标识的情况下，基于待创建的中间件对应的需求信息和容器编排系统的状态信息，从多个业务节点中确定用于创建待创建的中间件的目标业务节点；其中，业务节点为容器编排系统中除控制节点之外的节点；在类型为第二类型的情况下，基于需求信息和每个业务节点的状态信息，从多个业务节点中确定目标业务节点；控制在目标业务节点上创建待创建的中间件；如此，可以基于待创建的中间件的不同类型，采用不同的信息来确定目标业务节点，不再如相关技术中针对每一待创建的中间件都是基于需求信息和每一业务节点的状态信息来确定目标业务节点，提高了确定的目标业务节点的准确率。

基于前述实施例，本申请实施例提供一种信息处理方法，参照图2所示，该方法包括以下步骤：

步骤201、控制节点接收用于创建中间件的创建请求，并基于创建请求确定待创建的中间件的类型。

需要说明的是，在步骤201之后可以执行步骤202、步骤205和步骤206中的任一步骤。

步骤202、在类型为第一类型且创建请求中未携带业务节点的标识的情况下，控制节点获取容器编排系统的状态信息。

在本申请实施例中，可以确定接收创建请求时的时间，并基于时间确定创建请求是否是在目标周期内接收到的第一个创建请求，根据确定结果采用不同的方式获取容器编排系统的状态信息；其中，容器编排系统的状态信息可以为容器编排系统的当前状态信息或容器编排系统的预测状态信息。

需要说明的是，步骤202可以通过步骤A1-A2来实现：

步骤A1、控制节点在创建请求为目标周期内初始接收到的创建请求的情况下，确定容器编排系统的当前状态信息。

在本申请实施例中，在确定创建请求是目标周期内接收到的第一个创建请求的情况下，可以获取容器编排系统中每一个业务节点的当前状态信息，并基于多个业务节点的当前状态信息确定容器编排系统的当前状态信息。

在一种可行的实现方式中，容器编排系统的当前状态信息可以为容器编排系统当前剩余的CPU的数量、内存的剩余量、存储的剩余量、输入/输出(Input/Output，IO)的使用量和负荷量等信息。

步骤A2、控制节点在创建请求为目标周期内非初始接收到的创建请求的情况下，获取容器编排系统的预测状态信息。

其中，预测状态信息是预测得到的在上一次选定的业务节点上创建中间件后容器编排系统的状态信息。

在本申请实施例中，在确定创建请求为目标周期内接收到的非第一个创建请求的情况下，确定预测得到在上一次选定的业务节点上创建中间件后容器编排系统的状态信息，得到预测状态信息。

在一种可行的实现方式中，创建请求是目标周期内接收到的第三个待创建请求，可以获取预测在第二个待创建请求选定的目标业务节点上，创建第二个待创建请求对应的待创建的中间件后容器编排系统的状态信息，得到预测状态信息。

步骤203、控制节点基于需求信息和容器编排系统的状态信息，确定表征在每个业务节点上创建待创建的中间件后容器编排系统对应的状态值。

其中，状态值表征容器编排系统的性能。

在本申请实施例中，可以预测在容器编排系统的状态处于状态信息对应的状态的情况下，分别在每一个业务节点上创建待创建的中间件后容器编排系统对应的状态值。

需要说明的是，步骤203可以通过步骤B1-B2来实现：

步骤B1、控制节点基于目标时间窗口对多个创建请求进行分组，得到多组创建请求。

其中，多个创建请求中的每一创建请求对应的待创建的中间件的类型均为第一类型，且每一创建请求中均不携带业务节点的标识。

在本申请实施例中，目标时间窗口的大小是由k8s中业务节点的数量决定的；时间窗口的大小等于业务节点的数量；可以按照接收时间对多个创建请求进行排序得到排序后的多个创建请求，按照目标时间窗口对排序后的多个创建请求进行切割，得到多组创建请求。

在一种可行的实现方式中，若k8s中业务节点的数量为6，则目标时间窗口的大小为6，当创建请求的数量为18时，18个创建请求被分为3组，每组创建请求的数量为6。

步骤B2、控制节点针对每组创建请求，基于每一创建请求中的需求信息和容器编排系统的状态信息，确定每一创建请求对应的多个状态值。

需要说明的是，目标周期内可以具有多组创建请求，也可以具有一组创建请求。

在本申请实施例中，针对每组创建请求中的每一创建请求而言，预测在容器编排系统的状态处于状态信息所对应的状态的情况下，分别在每一业务节点上创建该创建请求对应的待创建的中间件后容器编排系统的状态值，得到每一创建请求对应的多个状态值。

在一种可行的实现方式中，针对每组创建请求中的每一创建请求，容器编排系统中的业务节点的数量为5，5个业务节点分别为Node1节点、Node2节点、Node3节点、Node4节点和Node5节点；控制节点可以预测在容器编排系统的状态处于状态信息所对应的状态的情况下，在Node1节点上创建待创建的中间件后容器编排系统对应的状态值，得到Node1节点对应的状态值，之后按照同样的方式确定Node2节点对应的状态值、Node3节点对应的状态值、Node4节点对应的状态值和Node5节点对应的状态值。

需要说明的是，B2可以通过步骤b1-b2来实现：

步骤b1、控制节点基于每一需求信息和容器编排系统的状态信息，预测在每个业务节点上创建待创建的中间件后容器编排系统的预测状态。

在本申请实施例中，预测在容器编排系统的状态处于状态信息对应的状态的情况下，基于需求信息分别在每个业务节点上创建待创建的中间件后容器编排系统的预测状态。

在一种可行的实现方式中，目标周期内只有一组创建请求，该组创建请求中创建请求的数量为5，针对该组创建请求中的第一个创建请求，可以基于第一个创建请求中的需求信息和容器编排系统的当前状态信息，预测分别在每个业务节点上创建待创建的中间件后容器编排系统的预测状态，得到每个业务节点对应的预测状态；针对该创建请求中的第二个创建请求，可以先确定在第一个创建请求对应的目标业务节点上创建第一个创建请求所对应的待创建中间件后，容器编排系统的预测状态信息，并将该预测状态信息作为针对第二个创建请求时容器编排系统的状态信息，预测在容器编排系统处于该状态信息对应的状态的情况下，分别在每个业务节点上进行创建第二创建请求对应的待创建的中间件后容器编排系统的预测状态，得到每个业务节点对应的预测状态。

步骤b2、控制节点基于每个业务节点对应的预测状态，确定预测状态对应的状态值。

在本申请实施例中，针对每一创建请求，基于每个业务节点对应的预测状态，采用目标奖励函数计算预测状态对应的状态值。

步骤204、控制节点基于状态值从多个业务节点中确定目标业务节点。

在本申请实施例中，可以对多个状态值进行筛选得到目标状态值，并将目标状态值对应的业务节点作为目标业务节点。

需要说明的是，步骤204可以通过步骤C1-C2来实现：

步骤C1、控制节点针对每一需求信息，从多个状态值中确定满足状态值条件的目标状态值。

在本申请实施例中，状态值条件可以为状态值大于预设状态值，那么控制节点可以从多个状态值中确定大于预设状态值的状态值，并对大于预设状态值的状态值进行筛选得到目标状态值；状态值条件还可以为从多个状态值中选择最大状态值，那么控制节点可以从多个状态值中确定最大状态值作为目标状态值。

步骤C2、控制节点确定目标状态值对应的业务节点为目标业务节点。

其中，目标状态值可以表征容器编排系统的性能处于最优。

在一种可行的实现方式中，针对任一创建请求，当预测得到在Node3节点上创建该创建请求对应的待创建的中间件后容器编排系统的性能处于最优，则可以将Node3节点作为目标业务节点。

需要说明的是，在步骤204之后可以执行步骤208。

步骤205、在类型为第一类型，且创建请求中携带有标识的情况下，控制节点确定标识对应的业务节点为目标业务节点。

其中，标识可以是业务节点的编号，标识用于唯一指代业务节点。

在本申请实施例中，在待创建的中间件的类型为第一类型，创建请求中携带业务节点的编号“3”，则可以从多个业务节点中确定编号为3的业务节点为目标业务节点。

需要说明的是，在步骤205之后可以执行步骤208。

步骤206、在类型为第二类型，控制节点基于需求信息，从多个状态信息中确定满足状态条件的目标状态信息。

在本申请实施例中，在待创建的中间件为第二类型的情况下，从多个状态信息中确定与需求信息匹配的待选状态信息；在待选状态信息的数量为一个时，则将待选状态信息作为目标状态信息；在待选状态信息为多个时，则从多个待选状态信息中确定表征业务节点的状态最优的待选状态信息作为目标状态信息。

步骤207、控制节点确定目标状态信息对应的业务节点为目标业务节点。

在一种可行的实现方式中，若确定的目标状态信息为Node3节点的状态信息，则可以将Node3节点作为目标业务节点。

步骤208、控制节点控制在目标业务节点上创建待创建的中间件。

下述结合应用场景，对本申请实施例提供的信息处理方法进行详细的解释说明。

在本申请实施例中，依据不同类型的待创建的中间件对k8s性能的影响以及考虑长期回报，将确定目标Node节点的方式分为了两种，针对不同类型的待创建的中间件采用不同的方式来确定目标Node节点。下述对本申请实施例提出的信息处理架构进行解释说明。

其中，信息处理架构包括中间件类型判别模块、Node节点判别模块、配置模块、Q-learning调度模块、k8s调度模块、Node节点状态检测模块和策略执行模块。

其中，中间件类型判别模块：该模块的主要作用是对待创建的中间件的类型进行判别，若待创建的中间件的类型是单个Pod，则该模块与Q-learning调度模块交互，以实现基于待创建的中间件对应的需求信息和容器编排系统的状态信息，从多个业务节点中确定用于创建待创建的中间件的目标Node节点；若待创建的中间件类型是多个Pod，则该模块与k8s调度模块交互，以基于需求信息和每个业务节点的状态信息，从多个业务节点中确定目标Node节点。

Node节点判别模块：该模块的主要作用是判断待创建的中间件是否指定某个特定的Node节点来创建(即确定类型为第一类型的创建请求中是否携带有node节点的标识)，若是，则该模块与配置模块交互，以便实现在特定的Node节点上创建待创建的中间件。

配置模块：该模块的主要作用是通过动态修改values.yaml配置文件，通过NodeSelector选项完成在指定Node节点上创建待创建的中间件。配置模块可以与Q-learning调度模块进行交互，也可以与k8s调度模块进行交互，以在Q-learning调度模块或k8s调度模块确定目标Node节点后，通过动态修改values.yaml配置文件，来实现在确定的目标Node节点上创建待创建的中间件。

下述结合图3对Q-learning调度模块进行详细的解释说明。

如图3所示，在待创建的中间件的类型为单个pod，且未携带业务节点的标识的情况下，通过Q-learning调度模块中的学习模块采用Q-learning算法为待创建的中间件确定目标Node节点。如图3所示，Q-learning调度模块采用了强化学习模型设计，主要包含如下几个组成部分：系统环境(即k8s的状态信息)、智能体(Agent)、奖励函数(Reward)、状态函数(State)、选择策略(Action)。其中，智能体可以表示待创建的中间件；状态值可以通过奖励函数计算得到的奖励值来确定；状态函数用于计算在选择某一Node节点时k8s系统的状态；选择策略指的是选择一个Node节点。

如图3所示，智能体在当前时刻选择了一个Node节点，这便是智能体开始尝试k8s系统的状态(即k8s的环境)。智能体观察到了k8s的状态，并得到了一个特定的奖励值，该奖励值可能是正奖励，也可能是负奖励。智能体不断尝试与k8s的环境进行交互，在经过一定次数的尝试之后，智能体最终可以做出最优决策。(即从多个Node节点中确定目标Node节点)。

在一种可行的实现方式中，智能体为创建请求1中的待创建的中间件1，在k8s处于状态信息所对应的状态的情况下，待创建的中间件1选择了Node1节点，预测得到在Node1节点上创建待创建的中间件1后k8s对应的状态值，之后待创建的中间件1分别选择其它Node节点上，并预测在其它每一个Node节点上创建待创建的中间件1后k8s对应的状态值，最终可以得到针对该待创建的中间件1对应的多个状态值，从多个状态值中确定最大状态值，并将最大状态值对应的Node节点作为目标Node节点；当为创建请求1中待创建的中间件1确定Node3为目标Node节点时，需要获取预测的在Node3节点上创建待创建的中间件1后Node3节点的预测状态信息，并根据Node3的预测状态信息和其它Node节点的状态信息，得到预测的k8s的第一状态信息；当智能体为创建请求2中待创建的中间件2时，需要预测在k8s的状态处于第一状态信息所对应的状态时，在每个Node节点创建待创建的中间件2时Node节点对应的状态值。需要说明的是，待创建的中间件2在尝试选择Node节点3时，针对待创建的中间件2而言，Node3节点的初始状态信息为预测的在Node3节点上创建待创建的中间件1后Node3节点的状态信息

k8s调度模块：用于基于需求信息和每个Node节点的状态信息，从多个Node节点中确定目标Node节点。

Node节点状态检测模块的主要作用是确定Node节点的当前状态信息，并基于Node节点的当前状态信息确定k8s的当前状态信息。

策略执行模块的主要作用是执行在Q-Learning模块确定的目标Node节点上创建待创建的中间件。

下述对本申请实施例在信息处理架构上执行的信息处理方法进行详细的解释说明。

如图4所示，首先中间件类型判别模块对待创建的中间件的类型进行判别，若待创建的中间件的类型是单个Pod,则该模块与Q-learning调度模块交互，确定目标Node节点；若部署的中间件类型是多个Pod，则该模块与K8S调度模块交互，确定目标Node节点。

Q-learning调度模块可以接收到中间件类型判别模块传输的多个创建请求，其中，每个创建请求对应的待创建的中间件的类型均为第一类型，且未携带Node节点的标识，Q-learning调度模块可以对多个创建请求按照接收时间进行排序，并采用目标时间窗口N对排序后的多个创建请求进行分组，得到多组创建请求，并获取每个Node节点的状态信息，根据Q-learning算法训练得到Q值序列，选择最大Q值对应的Node节点为目标Node节点；Q值为状态值。在针对每一个创建请求确定目标Node节点后需要根据奖励函数更新r值序列，以更新Node节点的状态；其中，r值序列为奖励值序列；针对同一组的创建请求在为每一创建请求均确定到目标Node节点时，Q-learning调度模块将同一组内每个创建请求和每个创建请求对应的目标Node节点的标识发送至配置模块，并通过配置模块修改values.yaml配置文件，以通过中间件部署执行模块基于修改后values.yaml配置文件创建待创建的中间件。

在待创建的中间件的类型为第二类型的情况下，则将创建请求给到k8s调度模块，通过k8s调度模块采用k8s原生调度确定目标Node节点；其中，k8s原生调度为基于待创建的中间件对应的需求信息和每个Node节点的状态信息确定目标Node节点。

在待创建的中间件的类型为第一类型，且创建请求中携带Node节点的标识的情况下，确定目标Node节点为标识对应的Node节点。

下述对Q-learning调度模块所采用的Q-learning算法进行解释说明。

Q-Learning算法是强化学习的一个进阶版，它是一种无模型并且离策略的学习过程。Q-Learning作为无模型进阶版本强化学习，依靠的是Q值迭代来实现选择策。Q-Learning算法迭代的过程中，一般会按照Q值最大的方向进行选择。但也并不是每一步迭代都会遵循这个原则，Q-Learning算法会根据多次试验的结果，按照一定的概率分布，该分布会尽最大可能向Q值最大的方向进行。

基于Q-Learning的容器化中间件调度方法采用数值迭代求解方法来逼近最优值。待创建的中间件所处的复杂网络环境是一个有限状态的马尔可夫过程。当待创建的中间件从动作集合(多个Node节点)中选择某一Node节点之后，即选择某一个Node节点进行创建待创建的中间件，k8s会接受这个动作并发生状态转移，同时给这个决策一个奖励值。从某个Node节点得到的奖励值越大，那么之后再次选择该Node节点的概率就会增加。

具体地，可以将从多个Node节点中确定目标Node节点，描述成四元组。其中，S表示整个k8s中的Node节点；R(Reward)表示选择action(某一Node节点)后获得奖励值的一个矩阵。A(Action)表示根据k8s状态所选择下一个Node节点的行为；如表1所示，Q表示经过训练得到的Q矩阵(其中，一组创建请求对应一个Q矩阵)，可以表示智能体已经从经验中学到的知识；Q矩阵中的每一个元素，表示状态值；对于表中的每一行而言，表示的是针对一个待创建请求，每个Node节点对应的状态值，其中，max表示最大状态值。

表1Q矩阵示意图

如表1所示，针对待创建请求1而言，Node3表示为待创建请求1对应的待创建的中间件1确定的目标Node节点；针对待创建请求2而言，Node1表示在为待创建的中间件1确定Node3的基础上，为待创建请求2中的待创建的中间件2确定的目标Node节点。

计算Q值时所采用的奖励函数R如公式(1)所示：

其中，

其中α为补偿函数，其作用是当Node节点的内存，CPU，存储不能满足pod所需最小资源要求时，上式奖励值为一个较大的负值，表示该Node节点资源不能满足Pod所需最小资源。μ为加权函数。x可以表示内存(memory)、cpu和storage(存储)中的任一个。

按照一定的先验知识，给定奖励矩阵R(R中的元素表示选择某一node节点所赋予的奖励值)，并将Q矩阵初始化，通常将Q矩阵初始化为0矩阵。执行一个选路行为(Action)，观察奖励值和新的链路状态的变化情况。根据公式(2)，对Q值进行迭代更新。

Q(S,a)←Q(S,a)+α[r+γ*max(Q(S′,a′)-Q(S,a))] 公式(2)

其中，γ(也可以理解为衰减因子)表示阻尼系数，取值范围区间为[0,1)，Q(S,a)表示在k8s的状态为状态信息所对应的状态S下执行动作a后的Q值；Q(S′,a′)表示下一状态S′下执行动作a′后的Q值，r是当前状态S下执行动作a后的奖励(即下一个状态下的奖励r)，γ为折扣因子，α为学习效率，γ*max(Q(S′,a′)是后续状态的折扣奖励，γ*max(Q(S′,a′)-Q(S,a))构成了后续状态奖励的改善估计。根据公式(2)，对Q矩阵中的Q值进行迭代更新，直到S为最终状态(即为同一组的每个创建请求都确定到对应的目标业务节点)，得到训练完成的Q矩阵。根据训练完成的Q矩阵进行创建中间件。

需要说明的是，本实施例中与其它实施例中相同步骤和相同内容的说明，可以参照其它实施例中的描述，此处不再赘述。

本申请实施例所提供的信息处理方法，可以基于待创建的中间件的不同类型，采用不同的信息来确定目标业务节点，不再如相关技术中针对每一待创建的中间件都是基于需求信息和每一业务节点的状态信息来确定目标业务节点，提高了确定的目标业务节点的准确率。

基于前述实施例，本申请的实施例提供一种控制节点，该控制节点可以应用于图1～2对应的实施例提供的信息处理方法中，参照图5所示，该控制节点3可以包括：处理器31、存储器32和通信总线33，其中：

通信总线33用于实现处理器31和存储器32之间的通信连接；

处理器31用于执行存储器32中的信息处理程序，以实现以下步骤：

接收用于创建中间件的创建请求，并基于创建请求确定待创建的中间件的类型；

在类型为第一类型且创建请求中未携带业务节点的标识的情况下，基于待创建的中间件对应的需求信息和容器编排系统的状态信息，从多个业务节点中确定用于创建待创建的中间件的目标业务节点；其中，业务节点为容器编排系统中除控制节点之外的节点；

在类型为第二类型的情况下，基于需求信息和每个业务节点的状态信息，从多个业务节点中确定目标业务节点；

控制在目标业务节点上创建待创建的中间件。

在本申请的其他实施例中，处理器31用于执行存储器32中的信息处理程序的基于待创建的中间件对应的需求信息和容器编排系统的状态信息，从多个业务节点中确定用于创建待创建的中间件的目标业务节点，以实现以下步骤：

获取容器编排系统的状态信息；

基于需求信息和容器编排系统的状态信息，确定表征在每个业务节点上创建待创建的中间件后容器编排系统对应的状态值；状态值表征容器编排系统的性能；

基于状态值从多个业务节点中确定目标业务节点。

在本申请的其他实施例中，处理器31用于执行存储器32中的信息处理程序的获取容器编排系统的状态信息，以实现以下步骤：

在创建请求为目标周期内初始接收到的创建请求的情况下，确定容器编排系统的当前状态信息；

在创建请求为目标周期内非初始接收到的创建请求的情况下，获取容器编排系统的预测状态信息；其中，预测状态信息是预测得到的在上一次选定的业务节点上创建中间件后容器编排系统的状态信息。

在本申请的其他实施例中，处理器31用于执行存储器32中的信息处理程序的基于需求信息和容器编排系统的状态信息，确定表征在每个业务节点上创建待创建的中间件后容器编排系统对应的状态值，以实现以下步骤：

基于目标时间窗口对多个创建请求进行分组，得到多组创建请求；

针对每组创建请求，基于每一创建请求中的需求信息和容器编排系统的状态信息，确定每一创建请求对应的多个状态值。

在本申请的其他实施例中，处理器31用于执行存储器32中的信息处理程序的基于每一创建请求中的需求信息和容器编排系统的状态信息，确定每一创建请求对应的多个状态值，以实现以下步骤：

基于每一需求信息和容器编排系统的状态信息，预测在每个业务节点上创建待创建的中间件后容器编排系统的预测状态；

基于每个业务节点对应的预测状态，确定预测状态对应的状态值。

在本申请的其他实施例中，处理器31用于执行存储器32中的信息处理程序的基于状态值从多个业务节点中确定目标业务节点，以实现以下步骤：

针对每一需求信息，从多个状态值中确定满足状态值条件的目标状态值；

确定目标状态值对应的业务节点为目标业务节点。

在本申请的其他实施例中，处理器31用于执行存储器32中的信息处理程序，以实现以下步骤：

在类型为第一类型，且创建请求中携带有标识的情况下，确定标识对应的业务节点为目标业务节点。

在本申请的其他实施例中，处理器31用于执行存储器32中的信息处理程序的基于需求信息和每个业务节点的状态信息，从多个业务节点中确定目标业务节点，以实现以下步骤：

基于需求信息，从多个状态信息中确定满足状态条件的目标状态信息；

确定目标状态信息对应的业务节点为目标业务节点。

需要说明的是，本实施例中处理器所执行的步骤的具体实现过程，可以参照图1～2对应的实施例提供的信息处理方法中的实现过程，此处不再赘述。

本申请的实施例所提供的控制节点，可以基于待创建的中间件的不同类型，采用不同的信息来确定目标业务节点，不再如相关技术中针对每一待创建的中间件都是基于需求信息和每一业务节点的状态信息来确定目标业务节点，提高了确定的目标业务节点的准确率。

基于前述实施例，本申请的实施例提供一种计算机可读存储介质，该计算机可读存储介质存储有一个或者多个程序，该一个或者多个程序可被一个或者多个处理器执行，以实现图1～2对应的实施例提供的信息处理方法中的步骤。

需要说明的是，上述计算机可读存储介质可以是只读存储器(Read Only Memory，ROM)、可编程只读存储器(Programmable Read-Only Memory，PROM)、可擦除可编程只读存储器(Erasable Programmable Read-Only Memory，EPROM)、电可擦除可编程只读存储器(Electrically Erasable Programmable Read-Only Memory，EEPROM)、磁性随机存取存储器(Ferromagnetic Random Access Memory，FRAM)、快闪存储器(Flash Memory)、磁表面存储器、光盘、或只读光盘(Compact Disc Read-Only Memory，CD-ROM)等存储器；也可以是包括上述存储器之一或任意组合的各种电子设备，如移动电话、计算机、平板设备、个人数字助理等。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本申请各个实施例所描述的方法。

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

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

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

以上仅为本申请的优选实施例，并非因此限制本申请的专利范围，凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请的专利保护范围内。