CN116541134B - 多架构集群中容器的部署方法及装置 - Google Patents

Abstract

本申请实施例涉及计算机领域，具体提供了一种多架构集群中容器的部署方法及装置，该方法包括：获取各计算节点的可用算力，对多个可用算力进行标准化，得到多个标准算力；接收对多架构集群中容器进行部署的部署请求，部署请求包括工作负载信息；根据多个标准算力以及工作负载信息，确定分发策略，分发策略包括节点组的数量和各节点组所需的副本数，同一个节点组中计算节点的CPU架构相同；根据分发策略和工作负载信息，创建工作负载以及pod，并将pod创建请求发送至调度器，调度器确定绑定节点并发送绑定请求至绑定节点的代理组件，绑定节点为与pod绑定的计算节点。本申请解决一云多芯集群的部署方案无法充分利用集群整体算力的问题。

Description

多架构集群中容器的部署方法及装置

技术领域

本申请实施例涉及计算机领域，具体而言，涉及一种多架构集群中的部署方法、装置、计算机可读存储介质和多架构集群。

背景技术

一云多芯是指用一套云操作系统来管理不同架构的硬件服务器集群，在本文中特指同一个容器集群中的服务器采用多个厂商多种架构的CPU（Central Processing Unit，中央处理器）芯片，这些计算节点之间存在着在计算能力、存储能力之间的差异。

当前对于一云多芯集群，大部分厂商以及用户采用的部署方案还是传统的部署方案，即通过创建Deployment（部署）、Satefulset（有状态副本集），并设计对应的计算节点选择策略来限制pod的运行计算节点。这种部署方案无法充分利用多芯架构集群的整体算力。

发明内容

本申请实施例提供了一种多架构集群中的部署方法、装置、计算机可读存储介质和多架构集群，以至少解决相关技术中的一云多芯集群的部署方案无法充分利用集群的整体算力的问题。

根据本申请的一个实施例，提供了一种多架构集群中容器的部署方法，包括：获取各计算节点的可用算力，并对多个所述可用算力进行标准化，得到多个标准算力，其中，部分的所述计算节点的CPU架构不同；接收对多架构集群中容器进行部署的部署请求，所述部署请求包括工作负载信息；根据多个所述标准算力以及所述工作负载信息，确定分发策略，所述分发策略包括节点组的数量和各所述节点组所需的副本数，其中，同一个所述节点组中所述计算节点的CPU架构相同；根据所述分发策略和所述工作负载信息，创建所述工作负载以及pod，并将pod创建请求发送至调度器，使得所述调度器确定绑定节点并发送绑定请求至所述绑定节点的代理组件，所述绑定节点为与所述pod绑定的所述计算节点。

在一个示例性实施例中，所述工作负载信息包括副本总数，根据多个所述标准算力以及所述工作负载信息，确定分发策略，包括：按照各所述计算节点的CPU架构对多个所述计算节点分组，得到多个所述节点组，得到所述节点组的数量；根据多个所述标准算力，计算各所述节点组的标准算力和；根据多个所述标准算力和，确定多个所述节点组的副本分配比例；根据所述副本总数和所述副本分配比例，确定各所述节点组所需的副本数。

在一个示例性实施例中，根据多个所述标准算力和，确定多个所述节点组的副本分配比例，包括：计算多个所述标准算力和的总和，得到算力总和；确定各所述节点组的副本分配比例为所述标准算力和与所述算力总和之比，根据所述副本总数和所述副本分配比例，确定各所述节点组所需的副本数，包括：根据所述副本总数和所述副本分配比例，确定各所述节点组所需的副本数为所述副本总数与所述副本分配比例的乘积。

在一个示例性实施例中，对多个所述可用算力进行标准化，得到多个标准算力，包括：调取第一映射关系，所述第一映射关系为CPU架构与预设比例之间的映射关系，所述预设比例为所述CPU架构的计算节点标准算力与计算节点可用算力的比值；根据各所述CPU架构和所述第一映射关系，确定各所述计算节点对应的所述预设比例为目标比例；确定所述标准算力为所述计算节点的所述可用算力与对应的所述目标比例的乘积。

在一个示例性实施例中，获取各计算节点的可用算力，包括：实时接收各所述代理组件上报的CPU可用资源以及内存可用资源，得到所述可用算力。

在一个示例性实施例中，所述工作负载信息包括副本总数，根据所述分发策略和所述工作负载信息，创建所述工作负载以及pod，包括：根据所述工作负载信息和所述节点组的数量，创建节点组的数量的所述工作负载；根据所述分发策略和所述副本总数，创建所述副本总数的所述pod，所述pod的初始配置参数相同。

在一个示例性实施例中，所述部署请求还包括第二映射关系，所述第二映射关系为CPU架构与pod配置参数的映射关系，所述绑定请求包括所述初始配置参数，在将pod创建请求发送至调度器之后，所述方法还包括：将所述第二映射关系发送至差异化配装器，使得所述差异化配装器在拦截到所述绑定请求的情况下，根据所述绑定节点和所述第二映射关系重写所述绑定请求中的所述初始配置参数，之后发送至所述代理组件。

根据本申请的另一个实施例，提供了一种多架构集群中容器的部署方法，包括：在接收到pod创建请求的情况下，根据分发策略，从多个节点组中确定待分配的节点组，其中，所述pod为控制器根据所述分发策略和工作负载信息创建的，所述分发策略为控制器根据多个标准算力和工作负载信息确定的，所述分发策略包括所述节点组的数量和各所述节点组所需的副本数，同一个所述节点组中计算节点的CPU架构相同，所述控制器接收的部署请求包括所述工作负载信息，多个所述标准算力为所述控制器获取各所述计算节点的可用算力，并对多个所述可用算力进行标准化得到的；根据预设打分策略，对所述待分配的节点组中的各所述计算节点进行打分，确定分数最高的所述计算节点为所述pod的绑定节点，并发送对所述绑定节点和所述pod进行绑定的绑定请求至代理组件，以实现所述绑定节点与所述pod的绑定。

在一个示例性实施例中，在根据预设打分策略，对所述待分配的节点组中的各所述计算节点进行打分之前，所述方法还包括：将多个所述pod分别放入调度队列。

在一个示例性实施例中，根据预设打分策略，对所述待分配的节点组中的各所述计算节点进行打分，确定分数最高的所述计算节点为所述pod的绑定节点，并发送对所述绑定节点和所述pod进行绑定的绑定请求至代理组件，包括：步骤S1，从所述调度队列中读取一个所述pod；步骤S2，根据所述预设打分策略，对所述待分配的节点组中的各所述计算节点进行打分，确定所述分数最高的所述计算节点为所述pod的所述绑定节点；步骤S3，发送对所述绑定节点和所述pod进行绑定的绑定请求至代理组件；步骤S4，循环执行所述步骤S1、所述步骤S2以及所述步骤S3，直到完成所述待分配的节点组对应的所有的所述pod的绑定。

在一个示例性实施例中，在步骤S1之后，在步骤S2之前，所述方法还包括：步骤S5，根据所述pod的需求算力和各所述可用算力，确定待过滤的计算节点，并从所述待分配的节点组中去除所述待过滤的计算节点，得到多个过滤后节点，所述步骤S2包括：根据所述预设打分策略，对各所述过滤后节点进行打分，确定所述分数最高的所述过滤后节点为所述pod的所述绑定节点。

在一个示例性实施例中，根据预设打分策略，对所述待分配的节点组中的各所述计算节点进行打分，包括：获取所述待分配的节点组中各所述计算节点的以下至少部分参数：CPU使用率、内存使用率、存储空间大小以及现有任务执行进度，所述现有任务执行进度为所述计算节点执行完成现有任务所需的时长；根据预设权重，对所述待分配的节点组中各所述计算节点对应的所述至少部分参数进行加权求和，得到各所述计算节点的所述分数。

在一个示例性实施例中，所述工作负载信息包括副本总数，所述节点组的数量为所述控制器按照各所述计算节点的CPU架构对多个所述计算节点分组得到的多个所述节点组确定的，各所述节点组所需的副本数为所述控制器根据所述副本总数和各所述节点组的副本分配比例确定的，所述副本分配比例为所述控制器根据多个所述节点组的标准算力和确定的，所述标准算力和为所述控制器根据多个所述标准算力计算得到的。

在一个示例性实施例中，所述标准算力为所述控制器确定的所述计算节点的可用算力与对应的目标比例的乘积，所述目标比例为所述控制器根据各所述CPU架构和第一映射关系确定的各所述计算节点对应的预设比例，所述第一映射关系为所述控制器调取得到的所述CPU架构与所述预设比例之间的映射关系，所述预设比例为所述CPU架构的计算节点标准算力与计算节点可用算力的比值。

根据本申请的再一个实施例，提供了一种多架构集群中容器的部署方法，包括：接收控制器发送的第二映射关系，所述第二映射关系为CPU架构与pod配置参数的映射关系；拦截调度器发送的绑定请求，所述绑定请求为对绑定节点和所述pod进行绑定的请求信息，所述绑定节点为所述调度器根据预设打分策略，对待分配的节点组中的各计算节点进行打分确定的分数最高的所述计算节点，所述绑定请求包括初始配置参数，多个所述pod的初始配置参数相同，所述待分配的节点组为所述调度器在接收到pod创建请求的情况下，根据分发策略从多个节点组中确定的，所述分发策略为控制器根据多个标准算力和工作负载信息确定的，所述分发策略包括所述节点组的数量和各所述节点组所需的副本数，同一个所述节点组中计算节点的CPU架构相同，多个所述标准算力为所述控制器获取各所述计算节点的可用算力，并对多个所述可用算力进行标准化得到的；根据所述绑定节点和所述第二映射关系，对所述初始配置参数进行重写；将重写后的所述绑定请求发送至所述绑定节点的代理组件。

在一个示例性实施例中，根据所述绑定节点和所述第二映射关系，对所述初始配置参数进行重写，包括：根据所述绑定节点和所述第二映射关系，确定与所述绑定节点的CPU架构对应的所述pod配置参数为目标配置参数；根据所述目标配置参数，将所述初始配置参数重写为所述目标配置参数。

在一个示例性实施例中，所述pod配置参数包括以下至少部分：镜像信息、环境变量、所述pod的启动命令、所述pod的启动参数、所述pod的特权模式。

根据本申请的另一个实施例，提供了一种多架构集群中容器的部署装置，包括：获取单元，用于获取各计算节点的可用算力，并对多个所述可用算力进行标准化，得到多个标准算力，其中，部分的所述计算节点的CPU架构不同；第一接收单元，用于接收对多架构集群中容器进行部署的部署请求，所述部署请求包括工作负载信息；第一确定单元，用于根据多个所述标准算力以及所述工作负载信息，确定分发策略，所述分发策略包括节点组的数量和各所述节点组所需的副本数，其中，同一个所述节点组中所述计算节点的CPU架构相同；创建单元，用于根据所述分发策略和所述工作负载信息，创建所述工作负载以及pod，并将pod创建请求发送至调度器，使得所述调度器确定绑定节点并发送绑定请求至所述绑定节点的代理组件，所述绑定节点为与所述pod绑定的所述计算节点。

根据本申请的又一个实施例，还提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，其中，所述计算机程序被设置为运行时执行所述任一种方法实施例中的步骤。

根据本申请的又一个实施例，还提供了一种多架构集群，包括：多个计算节点，部分的所述计算节点的CPU架构不同；控制器，包括存储器、处理器以及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现任一种所述的方法的步骤；调度器，与所述控制器以及所述计算节点的代理组件分别通信连接，所述调度器用于执行任一种所述的方法的步骤；差异化配装器，与所述代理组件通信连接，所述差异化配装器用于执行任一种所述的方法的步骤。

通过本申请，首先对获取的各个计算节点的可用算力进行标准化，得到多个标准算力，部分的所述计算节点的CPU架构不同；然后，根据多个标准算力以及接收到的部署请求中的工作负载信息，确定包括节点组的数量和节点组所需的副本数的分发策略；最后，根据分发策略和工作负载信息，创建工作负载和pod，并发送pod创建请求给调度器，使得调度器调度pod与绑定节点进行绑定。本申请对不同CPU架构的可用算力标准化，再根据标准化后的标准算力确定各CPU架构对应的副本数，从而创建工作负载和pod，基于计算节点的标准算力为容器应用选择合适的容器节点，实现了对不同架构进行差异化的计算资源分配，从而保证了对一云多芯架构集群的整体算力的充分利用。

附图说明

图1是根据本申请实施例的多架构集群中容器的部署方法的一种流程图；

图2是根据本申请实施例的多架构集群中容器的部署方法的另一种流程图；

图3是根据本申请实施例的多架构集群中容器的部署方法的再一种流程图；

图4是根据本申请实施例的多架构集群中容器的部署装置的一种结构框图；

图5是根据本申请实施例的多架构集群中容器的部署装置的另一种结构框图；

图6是根据本申请实施例的多架构集群中容器的部署装置的再一种结构框图；

图7是根据本申请实施例的多架构集群的结构示意图；

图8是根据本申请实施例的多架构集群的资源模型的定义图。

其中，上述附图包括以下附图标记：

100、计算节点；101、控制器；102、调度器；103、差异化配装器。

具体实施方式

下文中将参考附图并结合实施例来详细说明本申请的实施例。

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。

为了便于描述，以下对本申请实施例涉及的部分名词或术语进行说明：

Kubernetes：简称为K8s，是一个可移植的、可扩展的开源平台，用于管理容器化的工作负载和服务，可促进声明式配置和自动化。k8s拥有一个庞大且快速增长的生态系统。k8s的服务、支持和工具广泛可用。

容器(Container)：是一种便携式、轻量级的操作系统级虚拟化技术。它使用命名空间(namespace)隔离不同的软件运行环境，并通过镜像自包含软件的运行环境，从而使得容器可以很方便的在任何地方运行。由于容器体积小且启动快，因此可以在每个容器镜像中打包一个应用程序。这种一对一的应用镜像关系拥有很多好处。容器的使用不需要与外部的基础架构环境绑定，完美解决了从开发到生产环境的一致性问题。容器同样比虚拟机更加透明，这有助于监测和管理，尤其是容器进程的生命周期由基础设施管理。每个应用程序用容器封装，管理容器部署就等同于管理应用程序部署。

正如背景技术中所介绍的，现有技术中一云多芯集群的部署方案无法充分利用集群的整体算力，为解决如上的技术问题，本申请的实施例提供了一种多架构集群中的部署方法、装置、计算机可读存储介质和多架构集群。

在本实施例中提供了一种架构集群中容器的部署方法，该方法应用于架构集群中的控制器，图1是根据本申请实施例的架构集群中容器的部署方法的流程图，如图1所示，该流程包括如下步骤：

步骤S102，获取各计算节点的可用算力，并对多个上述可用算力进行标准化，得到多个标准算力，其中，部分的上述计算节点的CPU架构不同；

具体地，上述计算节点为服务器，上述可用算力为计算节点当前可使用的算力，上述可用算力包括以下至少之一：上述计算节点的CPU可用资源、内存可用资源、GPU（Graphics Processing Unit，图形处理器）可用资源以及硬盘可用资源。上述CPU架构包括但不限于X86架构、ARM架构以及RISC架构等现有的CPU架构，比如，多个上述计算节点中，部分的上述计算节点为ARM架构，其他的上述计算节点为X86架构；再比如，多个上述计算节点中，部分的上述计算节点为ARM架构，部分的上述计算节点为X86架构，其他的上述计算节点为RISC架构。

步骤S104，接收对多架构集群中容器进行部署的部署请求，上述部署请求包括工作负载信息；

具体地，上述部署请求也是多架构集群的创建请求。上述工作负载信息为创建工作负载所用的信息，包括工作负载的基础信息，工作负载为Kubernetes上运行的程序，用于创建pod以及对容器应用进行编排。

步骤S106，根据多个上述标准算力以及上述工作负载信息，确定分发策略，上述分发策略包括节点组的数量和各上述节点组所需的副本数，其中，同一个上述节点组中上述计算节点的CPU架构相同；

具体地，一个上述节点组由CPU架构相同的多个计算节点组成，不同的节点组的CPU架构不同。副本为pod的副本。

步骤S108，根据上述分发策略和上述工作负载信息，创建上述工作负载以及pod，并将pod创建请求发送至调度器，使得上述调度器确定绑定节点并发送绑定请求至上述绑定节点的代理组件，上述绑定节点为与上述pod绑定的上述计算节点。

具体地，上述代理组件为Kubelet，Kubelet是kubernetes计算节点上的一个代理组件，运行在每个计算节点上。Pod是kubernetes中最小的资源管理组件，Pod也是最小化运行容器化应用的资源对象，一个Pod代表着集群中运行的一个进程，kubernetes中其他大多数组件都是围绕着Pod来进行支撑和扩展Pod功能的，例如，用于管理Pod运行的StatefulSet和Deployment等原生资源。

通过上述步骤，首先对获取的各个计算节点的可用算力进行标准化，得到多个标准算力，部分的上述计算节点的CPU架构不同；然后，根据多个标准算力以及接收到的部署请求中的工作负载信息，确定包括节点组的数量和节点组所需的副本数的分发策略；最后，根据分发策略和工作负载信息，创建工作负载和pod，并发送pod创建请求给调度器，使得调度器调度pod与绑定节点进行绑定。本申请对不同CPU架构的可用算力标准化，再根据标准化后的标准算力确定各CPU架构对应的副本数，从而创建工作负载和pod，基于计算节点的标准算力为容器应用选择合适的容器节点，实现了对不同架构进行差异化的计算资源分配，从而保证了对一云多芯架构集群的整体算力的充分利用。

并且，本申请简化了运维人员管理多架构集群的操作难度，运维人员在部署容器集群中不需要额外考虑各CPU架构节点间算力的差异，只需要设置对应的参数配置，即上述部署请求，本申请即可根据该部署请求为容器应用基于标准算力进行副本分发，简化了一云多芯容器集群的管理复杂度，增强了一云多芯容器集群下的可维护性以及易用性。

其中，上述步骤的执行主体可以为多架构集群中的控制器等，但不限于此。

步骤S102和步骤S104的执行顺序是可以互换的，即可以先执行步骤S104，然后再执行S102。

根据本申请的一些示例性实施例，上述工作负载信息包括副本总数，该副本总数为用户期望的部署所需的副本数，步骤S106：根据多个上述标准算力以及上述工作负载信息，确定分发策略的具体实现方式可以为：

步骤S1061：按照各上述计算节点的CPU架构对多个上述计算节点分组，得到多个上述节点组，得到上述节点组的数量；

步骤S1062：根据多个上述标准算力，计算各上述节点组的标准算力和；

具体地，通过将上述节点组中所有的上述标准算力加和，得到该节点组的标准算力和。

步骤S1063：根据多个上述标准算力和，确定多个上述节点组的副本分配比例；

步骤S1064：根据上述副本总数和上述副本分配比例，确定各上述节点组所需的副本数。

上述实施例中，先按照CPU架构的不同将多个计算节点分成CPU架构不同的多个节点组，每个节点组中至少包括一个计算节点；之后计算每个节点组的标准算力和；再根据多个标准算力和得到节点组之间的副本分配比例，并按照该副本分配比例给每个节点组分配pod，确定各个节点组的副本数，从而得到分配策略。这样可以进一步地保证为各节点组分配的副本数与其算力匹配，从而保证了对一云多芯架构集群的整体算力的充分利用。

为了进一步地解决现有一云多芯集群的部署方案无法充分利用集群的整体算力的问题，在另一些示例性实施例中，根据多个上述标准算力和，确定多个上述节点组的副本分配比例，包括：计算多个上述标准算力和的总和，得到算力总和；确定各上述节点组的副本分配比例为上述标准算力和与上述算力总和之比。将节点组的标准算力与算力总和之比作为该节点组的副本分配比例，也就是将节点组之间的算力比例作为了副本分配比例，进一步地保证了后续根据该副本分配比例分配的副本数与该节点组的整体算力匹配，可以充分利用该节点组的整体算力，进一步地实现了对各计算节点的算力的充分利用。

在此基础上，根据上述副本总数和上述副本分配比例，确定各上述节点组所需的副本数，包括：根据上述副本总数和上述副本分配比例，确定各上述节点组所需的副本数为上述副本总数与上述副本分配比例的乘积。

比如，ARM节点组的副本分配比例为2/5，X86节点组的副本分配比例为3/5，pod的副本总数为20，则为ARM节点组分配的副本数就是2/5×20=8个，为X86节点组分配的副本数就是3/5=12个。

由于CPU架构不同，各计算节点的算力是不同的，比如同样的16g内存，不同CPU架构的计算节点能达到的效果不一样，因此需要对计算节点的可用算力进行转换，该转换就是将计算节点的可用算力转换为标准算力。具体地，对多个上述可用算力进行标准化，得到多个标准算力，包括如下步骤：调取第一映射关系，上述第一映射关系为CPU架构与预设比例之间的映射关系，上述预设比例为上述CPU架构的计算节点标准算力与计算节点可用算力的比值；根据各上述CPU架构和上述第一映射关系，确定各上述计算节点对应的上述预设比例为目标比例；确定上述标准算力为上述计算节点的上述可用算力与对应的上述目标比例的乘积。对于不同CPU架构计算节点，从表征CPU架构与预设比例的第一映射关系中确定目标比例，将可用算力与该目标比例相乘，得到该计算节点的标准算力，可以较为简单快捷地实现不同架构计算节点的算力标准化。

其中，上述的第一映射关系为通过对不同CPU架构的计算节点的算力进行实验得到的。比如ARM架构对应的上述预设比例为1.2，那么在分配到ARM架构的节点时，原始数据中本来需要1核1g，由于是ARM架构的节点，需要更多的算力才能达到标准算力，此时就需要通过重写策略将1核1g，改为1.2核1.2g。

本申请中，获取各计算节点的可用算力，包括：实时接收各上述代理组件上报的CPU可用资源以及内存可用资源，得到上述可用算力。也就是说，接收各个计算节点的kubelet上报的该计算节点的CPU可用资源以及内存可用资源，作为该计算节点的可用算力。这样可以较为准确且快捷地获取到各个计算节点的可用算力。

另外，除了上述可用算力外，各个计算节点的kubelet还上报计算节点的CPU架构以及计算节点当前运行了多少个pod等信息。

根据本申请的又一些可选方案，上述工作负载信息包括副本总数，根据上述分发策略和上述工作负载信息，创建上述工作负载以及pod，包括：根据上述工作负载信息和上述节点组的数量，创建节点组的数量的上述工作负载，即上述共组负载的数量等于上述节点组的数量；根据上述分发策略和上述副本总数，创建上述副本总数的上述pod，上述pod的初始配置参数相同，即上述pod的数量等于上述副本总数。本实施例中，根据工作负载信息，创建上述节点组的数量个工作负载，以及根据分发策略，创建副本总数个pod，其中，创建的各个节点组的pod的初始配置参数相同，这样简化了pod的创建过程。

在实际的应用过程中，可以直接创建上述副本总数个上述pod，也可以通过上述工作负载创建上述pod。上述工作负载的创建方式支持界面创建和Yaml创建。创建的上述工作负载的类型包括以下至少之一：部署、有状态副本集、守护进程集（DaemonSet）、任务（Job）以及定时任务（CronJob），具体根据上述部署请求中的工作负载信息确定。

具体地，不同CPU架构的计算节点，对应pod的配置参数是不同的，上述实施例中在创建pod时未区分CPU架构，对pod进行了相同的参数配置，为了防止pod无法正常绑定到计算节点上，一些示例性实施例中，上述部署请求还包括第二映射关系，上述第二映射关系为CPU架构与pod配置参数的映射关系，上述绑定请求包括上述初始配置参数，在将pod创建请求发送至调度器之后，上述方法还包括：将上述第二映射关系发送至差异化配装器，使得上述差异化配装器在拦截到上述绑定请求的情况下，根据上述绑定节点和上述第二映射关系重写上述绑定请求中的上述初始配置参数，之后发送至上述代理组件。通过将第二映射关系发送给差异化配装器，使得差异化配装器根据绑定节点和第二映射关系重写pod的初始配置参数，以对不同架构计算节点上的pod进行定制化参数配置，从而保证pod的正常运作。

本申请中，上述pod配置参数包括以下至少部分：镜像信息、环境变量、上述pod的启动命令、上述pod的启动参数、上述pod的特权模式。

一种具体的实施例中，获取各计算节点的可用算力，包括：定时获取各上述计算节点的可用算力。本申请通过定时检测容器集群中各计算节点可用算力的变化，将可用算力转换为标准算力，并将各个架构的标准算力比例和转换为副本分配比例，在容器应用部署时基于多架构节点间容器应用的副本分配比例为容器应用选择合适的计算节点，进一步地保证了不同算力的计算节点的算力可以得到充分利用。

根据本申请的另一方面，提供了一种多架构集群中容器的部署方法，该方法应用于架构集群中的调度器，图2是根据本申请实施例的架构集群中容器的部署方法的流程图，如图2所示，该流程包括如下步骤：

步骤S202，在接收到pod创建请求的情况下，根据分发策略，从多个节点组中确定待分配的节点组，其中，上述pod为控制器根据上述分发策略和工作负载信息创建的，上述分发策略为控制器根据多个标准算力和工作负载信息确定的，上述分发策略包括上述节点组的数量和各上述节点组所需的副本数，同一个上述节点组中计算节点的CPU架构相同，上述控制器接收的部署请求包括上述工作负载信息，多个上述标准算力为上述控制器获取各上述计算节点的可用算力，并对多个上述可用算力进行标准化得到的；

具体地，该pod创建请求为控制器发出的请求信息。一个上述节点组由CPU架构相同的多个计算节点组成，不同的节点组的CPU架构不同。上述工作负载信息为创建工作负载所用的信息，包括工作负载的基础信息，工作负载为Kubernetes上运行的程序，用于创建pod以及对容器应用进行编排。

上述计算节点为服务器，上述可用算力为计算节点当前可使用的算力，上述可用算力包括以下至少之一：上述计算节点的CPU可用资源、内存可用资源、GPU可用资源以及硬盘可用资源。上述CPU架构包括但不限于X86架构、ARM架构以及RISC架构等现有的CPU架构。

步骤S204，根据预设打分策略，对上述待分配的节点组中的各上述计算节点进行打分，确定分数最高的上述计算节点为上述pod的绑定节点，并发送对上述绑定节点和上述pod进行绑定的绑定请求至代理组件，以实现上述绑定节点与上述pod的绑定。

具体地，上述待分配的节点组为需要分配该pod的上述节点组。上述预设打分策略可以为Kubernetes中预设的对计算节点进行打分的规则。上述代理组件为该绑定节点的代理组件，具体为Kubelet，Kubelet是kubernetes计算节点上的一个代理组件，运行在每个计算节点上。

通过上述步骤，在接收到pod创建请求时，首先确定待分配该pod的节点组；之后，根据预设打分策略，对该待分配的节点组中的各计算节点进行打分，确定绑定节点，并发送绑定请求给该绑定节点的代理组件，实现该绑定节点与pod的绑定，其中，同一个上述节点组中计算节点的CPU架构相同，pod为控制器根据分发策略和接收到的工作负载信息创建的，该分发策略为控制器根据多个标准算力和工作负载信息确定的，多个上述标准算力为上述控制器获取各上述计算节点的可用算力，并对多个上述可用算力进行标准化得到的。本申请根据分发策略通过预设打分策略从待分配的节点组中选择分数最高的绑定节点，使得pod与该绑定节点进行绑定，实现了将pod调度到当前最优的计算节点上。并且，该调度过程是基于分发策略进行的，该分发策略是控制器对不同CPU架构的可用算力标准化，再根据标准化后的标准算力确定的，实现了基于计算节点的标准算力为容器应用选择合适的容器节点，实现了对不同架构进行差异化的计算资源分配，从而保证了对一云多芯架构集群的整体算力的充分利用。

具体地，根据分发策略，从多个节点组中确定待分配的节点组的具体实现过程可以为：根据各节点组所需的副本数和已经分配的副本数，确定需要分配pod的节点组为节点组所需的副本数和已经分配的副本数的差值大于0的节点组；从需要分配pod的节点组中随机选择节点组作为上述待分配的节点组。

当然，在确定需要分配pod的节点组之后，也可以根据一些人为定义的规则从需要分配pod的节点组中按照规则选择节点组来作为上述待分配的节点组，本领域技术人员可以根据实际需求灵活设置上述的规则内容，比如该规则为从需要分配pod的节点组中选择差值最大或者最小的节点组作为上述待分配的节点组。

一种可选方案中，在根据预设打分策略，对上述待分配的节点组中的各上述计算节点进行打分之前，上述方法还包括：将多个上述pod分别放入调度队列。通过将上述pod放入调度队列，从调度队列中依次读取pod并进行pod绑定，可以加快调度器的响应速度。

具体地，可以在确定待分配的节点组之前，将所有创建且未绑定的上述pod放入上述调度队列中。也可以在确定待分配的节点组之后，将需要分配给该待分配的节点组的、所有创建且未绑定的pod放入调度队列中。

根据本申请的一些可选实施例，根据预设打分策略，对上述待分配的节点组中的各上述计算节点进行打分，确定分数最高的上述计算节点为上述pod的绑定节点，并发送对上述绑定节点和上述pod进行绑定的绑定请求至代理组件，包括：步骤S1，从上述调度队列中读取一个上述pod；步骤S2，根据上述预设打分策略，对上述待分配的节点组中的各上述计算节点进行打分，确定上述分数最高的上述计算节点为上述pod的上述绑定节点；步骤S3，发送对上述绑定节点和上述pod进行绑定的绑定请求至代理组件；步骤S4，循环执行上述步骤S1、上述步骤S2以及上述步骤S3，直到完成上述待分配的节点组对应的所有的上述pod的绑定。本实施例中，通过将pod加入调度队列中，通过循环执行读取pod和打分过程，来确定每个pod对应的绑定节点并进行pod绑定，进一步地实现了为每个待绑定的pod选择当前最优的计算节点。

另外，在确定待分配的节点组之前，将所有创建且未绑定的上述pod放入上述调度队列中的情况下，本申请可以先执行上述步骤S1，再执行步骤S202：根据分发策略，从多个节点组中确定上述pod对应的待分配的节点组，这种情况下，上述步骤S4包括：循环执行上述步骤S1、步骤S202、步骤S2以及步骤S3，直到完成所有的上述pod的绑定。

为了进一步地简化打分过程，进一步地保证可以较为快速地确定绑定节点，在一个示例性实施例中，在步骤S2之后，在步骤S3之前，上述方法还包括：步骤S5，根据上述pod的需求算力和各上述可用算力，确定待过滤的计算节点，并从上述待分配的节点组中去除上述待过滤的计算节点，得到多个过滤后节点，上述步骤S3包括：根据上述预设打分策略，对各上述过滤后节点进行打分，确定上述分数最高的上述过滤后节点为上述pod的上述绑定节点。本实施例先根据pod的需求算力和待分配的节点组中各个计算节点的可用算力，去除待过滤的计算节点，保证了后续进行打分计算的计算节点数量较少，可以较为快速地得到待分配的节点组中剩余计算节点的分数，从而可以较为快速地确定该pod的绑定节点。

其中，上述待过滤的计算节点为可用算力小于上述pod的需求算力的计算节点。

根据本申请的另一种示例性实施例，根据预设打分策略，对上述待分配的节点组中的各上述计算节点进行打分，包括：获取上述待分配的节点组中各上述计算节点的以下至少部分参数：CPU使用率、内存使用率、存储空间大小以及现有任务执行进度，上述现有任务执行进度为上述计算节点执行完成现有任务所需的时长；根据预设权重，对上述待分配的节点组中各上述计算节点对应的上述至少部分参数进行加权求和，得到各上述计算节点的上述分数。本实施例中，对CPU使用率、内存使用率、存储空间大小以及现有任务执行进度中至少部分进行加权求和，得到计算节点的分数，使得分数可以充分体现出上述计算节点当前的可用资源，从而进一步地保证为pod选择出当前最优的计算节点。

为了可以进一步地保证为各节点组分配的副本数与其算力匹配，从而保证了各个计算节点算力的充分利用，在一个示例性实施例中，上述工作负载信息包括副本总数，上述节点组的数量为上述控制器按照各上述计算节点的CPU架构对多个上述计算节点分组得到的多个上述节点组确定的，各上述节点组所需的副本数为上述控制器根据上述副本总数和各上述节点组的副本分配比例确定的，上述副本分配比例为上述控制器根据多个上述节点组的标准算力和确定的，上述标准算力和为上述控制器根据多个上述标准算力计算得到的。

由于CPU架构不同，各计算节点的算力是不同的，比如同样的16g内存，不同CPU架构的计算节点能达到的效果不一样，因此需要对计算节点的可用算力进行转换，该转换就是将计算节点的可用算力转换为标准算力。在一个示例性实施例中，上述标准算力为上述控制器确定的上述计算节点的可用算力与对应的目标比例的乘积，上述目标比例为上述控制器根据各上述CPU架构和第一映射关系确定的各上述计算节点对应的预设比例，上述第一映射关系为上述控制器调取得到的上述CPU架构与上述预设比例之间的映射关系，上述预设比例为上述CPU架构的计算节点标准算力与计算节点可用算力的比值。对于不同CPU架构计算节点，控制器从表征CPU架构与预设比例的第一映射关系中确定目标比例，将可用算力与该目标比例相乘，得到该计算节点的标准算力，可以较为简单快捷地实现不同架构计算节点的算力标准化。

其中，上述的第一映射关系为通过对不同CPU架构的计算节点的算力进行实验得到的。比如ARM架构对应的上述预设比例为1.2，那么在分配到ARM架构的节点时，原始数据中本来需要1核1g，由于是ARM架构的节点，需要更多的算力才能达到标准算力，此时就需要通过重写策略将1核1g，改为1.2核1.2g。

为了进一步地解决现有一云多芯集群的部署方案无法充分利用集群的整体算力的问题，具体地，上述副本分配比例为上述控制器将标准算力与算力总和相除得到的，上述算力总和为上述控制器计算多个上述标准算力和的总和得到的，上述节点组所需的副本数为上述控制器计算上述副本总数与上述副本分配比例的乘积得到的。控制器将节点组的标准算力与算力总和之比作为该节点组的副本分配比例，也就是将节点组之间的算力比例作为了副本分配比例，进一步地保证了后续根据该副本分配比例分配的副本数与该节点组的整体算力匹配，可以充分利用该节点组的整体算力，进一步地实现了对各计算节点的算力的充分利用。

比如，ARM节点组的副本分配比例为2/5，X86节点组的副本分配比例为3/5，pod的副本总数为20，则为ARM节点组分配的副本数就是2/5×20=8个，为X86节点组分配的副本数就是3/5=12个。

根据本申请的另一种可选实施例，上述工作负载的数量等于节点组的数量，节点组的数量的上述工作负载为上述控制器根据上述工作负载信息和上述节点组的数量创建的；上述pod的数量等于上述副本总数，上述pod的数量为根据上述分发策略和上述副本总数创建的，上述pod的初始配置参数相同。

在实际的应用过程中，上述副本总数个上述pod可以是控制器可以直接创建的，也可以通过上述工作负载创建的。上述工作负载的创建方式支持界面创建和Yaml创建。创建的上述工作负载的类型包括以下至少之一：部署、有状态副本集、守护进程集（DaemonSet）、任务（Job）以及定时任务（CronJob），具体根据上述部署请求中的工作负载信息确定。

另外，在发送对上述绑定节点和上述pod进行绑定的绑定请求至代理组件的过程中，上述绑定请求会被差异化配装器拦截，上述差异化配装器根据控制器发送的第二映射关系和上述绑定节点，重写上述绑定请求中的初始配置参数，再发送给代理组件，其中，上述第二映射关系为CPU架构与pod配置参数的映射关系，上述控制器接收到的部署请求中包括上述第二映射关系。由于不同CPU架构的计算节点，对应pod的配置参数是不同的，控制器在创建pod时未区分CPU架构，对pod进行了相同的参数配置，因此为了防止pod无法正常绑定到计算节点上，通过差异化配装器重写pod的初始配置参数，以对不同架构计算节点上的pod进行定制化参数配置，从而保证pod的正常运作。

具体地，上述pod配置参数包括以下至少部分：镜像信息、环境变量、上述pod的启动命令、上述pod的启动参数、上述pod的特权模式。

可选地，各上述计算节点的可用算力为上述控制器定时获取到的。本申请的控制器通过定时检测容器集群中各计算节点可用算力的变化，将可用算力转换为标准算力，并将各个架构的标准算力比例和转换为副本分配比例，在容器应用部署时基于多架构节点间容器应用的副本分配比例为容器应用选择合适的计算节点，进一步地保证了不同算力的计算节点的算力可以得到充分利用。

根据本申请的再一方面，还提供了一种多架构集群中容器的部署方法，该方法应用于架构集群中的差异化配装器，图3是根据本申请实施例的架构集群中容器的部署方法的流程图，如图3所示，该流程包括如下步骤：

步骤S302，接收控制器发送的第二映射关系，上述第二映射关系为CPU架构与pod配置参数的映射关系；

具体地，上述pod配置参数包括以下至少部分：镜像信息、环境变量、上述pod的启动命令、上述pod的启动参数、上述pod的特权模式。上述CPU架构包括但不限于X86架构、ARM架构以及RISC架构等现有的CPU架构。

步骤S304，拦截调度器发送的绑定请求，上述绑定请求为对绑定节点和上述pod进行绑定的请求信息，上述绑定节点为上述调度器根据预设打分策略，对待分配的节点组中的各计算节点进行打分确定的分数最高的上述计算节点，上述绑定请求包括初始配置参数，多个上述pod的初始配置参数相同，上述待分配的节点组为上述调度器在接收到pod创建请求的情况下，根据分发策略从多个节点组中确定的，上述分发策略为控制器根据多个标准算力和工作负载信息确定的，上述分发策略包括上述节点组的数量和各上述节点组所需的副本数，同一个上述节点组中计算节点的CPU架构相同，多个上述标准算力为上述控制器获取各上述计算节点的可用算力，并对多个上述可用算力进行标准化得到的；

具体地，该pod创建请求为控制器发出的请求信息。一个上述节点组由CPU架构相同的多个计算节点组成，不同的节点组的CPU架构不同。上述计算节点为服务器，上述可用算力为计算节点当前可使用的算力，上述可用算力包括以下至少之一：上述计算节点的CPU可用资源、内存可用资源、GPU可用资源以及硬盘可用资源。

步骤S306，根据上述绑定节点和上述第二映射关系，对上述初始配置参数进行重写；

步骤S308，将重写后的上述绑定请求发送至上述绑定节点的代理组件。

具体地，上述代理组件为该绑定节点的代理组件，具体为Kubelet，Kubelet是kubernetes计算节点上的一个代理组件，运行在每个计算节点上。

通过上述步骤，首先接收控制器发送的表征CPU架构与pod配置参数的映射关系的第二映射关系，然后拦截调度器发送的请求对绑定节点和上述pod进行绑定的绑定请求，再根据上述绑定节点和上述第二映射关系，对上述初始配置参数进行重写后发送给绑定节点的代理组件，实现绑定节点与pod的绑定，实现了对不同架构计算节点上的pod进行定制化参数配置，从而保证pod的正常运作，满足容器应用在不同架构下运行的差异化要求。并且，本申请的调度器根据分发策略通过预设打分策略从待分配的节点组中选择分数最高的绑定节点，使得pod与该绑定节点进行绑定，实现了将pod调度到当前最优的计算节点上。另外，该调度过程是基于分发策略进行的，该分发策略是控制器对不同CPU架构的可用算力标准化，再根据标准化后的标准算力确定的，实现了基于计算节点的标准算力为容器应用选择合适的容器节点，实现了对不同架构进行差异化的计算资源分配，从而保证了对一云多芯架构集群的整体算力的充分利用。

并且，本申请简化了运维人员管理多架构集群的操作难度，运维人员在部署容器集群中不需要额外考虑各CPU架构节点间算力的差异，只需要设置对应的参数配置，即上述部署请求，本申请即可根据该部署请求为容器应用基于标准算力进行副本分发以及pod参数的差异化配置，简化了一云多芯容器集群的管理复杂度，增强了一云多芯容器集群下的可维护性以及易用性。

为了进一步地避免pod无法正常绑定到计算节点上，在一个示例性实施例中，根据上述绑定节点和上述第二映射关系，对上述初始配置参数进行重写，包括：根据上述绑定节点和上述第二映射关系，确定与上述绑定节点的CPU架构对应的上述pod配置参数为目标配置参数；根据上述目标配置参数，将上述初始配置参数重写为上述目标配置参数。

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

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

图4是根据本申请实施例的多架构集群中容器的部署装置的结构框图，该装置应用于架构集群中的控制器，如图4所示，该装置包括：

获取单元11，用于获取各计算节点的可用算力，并对多个上述可用算力进行标准化，得到多个标准算力，其中，部分的上述计算节点的CPU架构不同；

具体地，上述计算节点为服务器，上述可用算力为计算节点当前可使用的算力，上述可用算力包括以下至少之一：上述计算节点的CPU可用资源、内存可用资源、GPU可用资源以及硬盘可用资源。上述CPU架构包括但不限于X86架构、ARM架构以及RISC架构等现有的CPU架构，比如，多个上述计算节点中，部分的上述计算节点为ARM架构，其他的上述计算节点为X86架构；再比如，多个上述计算节点中，部分的上述计算节点为ARM架构，部分的上述计算节点为X86架构，其他的上述计算节点为RISC架构。

第一接收单元12，用于接收对多架构集群中容器进行部署的部署请求，上述部署请求包括工作负载信息；

具体地，上述部署请求也是多架构集群的创建请求。上述工作负载信息为创建工作负载所用的信息，包括工作负载的基础信息，工作负载为Kubernetes上运行的程序，用于创建pod以及对容器应用进行编排。

第一确定单元13，用于根据多个上述标准算力以及上述工作负载信息，确定分发策略，上述分发策略包括节点组的数量和各上述节点组所需的副本数，其中，同一个上述节点组中上述计算节点的CPU架构相同；

具体地，一个上述节点组由CPU架构相同的多个计算节点组成，不同的节点组的CPU架构不同。副本为pod的副本。

创建单元14，用于根据上述分发策略和上述工作负载信息，创建上述工作负载以及pod，并将pod创建请求发送至调度器，使得上述调度器确定绑定节点并发送绑定请求至上述绑定节点的代理组件，上述绑定节点为与上述pod绑定的上述计算节点。

具体地，上述代理组件为Kubelet，Kubelet是kubernetes计算节点上的一个代理组件，运行在每个计算节点上。Pod是kubernetes中最小的资源管理组件，Pod也是最小化运行容器化应用的资源对象，一个Pod代表着集群中运行的一个进程，kubernetes中其他大多数组件都是围绕着Pod来进行支撑和扩展Pod功能的，例如，用于管理Pod运行的StatefulSet和Deployment等原生资源。

本申请的上述方案中，通过获取单元对获取的各个计算节点的可用算力进行标准化，得到多个标准算力，部分的上述计算节点的CPU架构不同；通过第一接收单元接收部署请求；通过第一确定单元根据多个标准算力接收到的部署请求中的工作负载信息，确定包括节点组的数量和节点组所需的副本数的分发策略；通过创建单元根据分发策略和工作负载信息，创建工作负载和pod，并发送pod创建请求给调度器，使得调度器调度pod与绑定节点进行绑定。本申请对不同CPU架构的可用算力标准化，再根据标准化后的标准算力确定各CPU架构对应的副本数，从而创建工作负载和pod，基于计算节点的标准算力为容器应用选择合适的容器节点，实现了对不同架构进行差异化的计算资源分配，从而保证了对一云多芯架构集群的整体算力的充分利用。

并且，本申请简化了运维人员管理多架构集群的操作难度，运维人员在部署容器集群中不需要额外考虑各CPU架构节点间算力的差异，只需要设置对应的参数配置，即上述部署请求，本申请即可根据该部署请求为容器应用基于标准算力进行副本分发，简化了一云多芯容器集群的管理复杂度，增强了一云多芯容器集群下的可维护性以及易用性。

根据本申请的一些示例性实施例，上述工作负载信息包括副本总数，该副本总数为用户期望的部署所需的副本数，上述第一确定单元具体包括：

分组模块，用于按照各上述计算节点的CPU架构对多个上述计算节点分组，得到多个上述节点组，得到上述节点组的数量；

计算模块，用于根据多个上述标准算力，计算各上述节点组的标准算力和；

具体地，通过将上述节点组中所有的上述标准算力加和，得到该节点组的标准算力和。

第一确定模块，用于根据多个上述标准算力和，确定多个上述节点组的副本分配比例；

第二确定模块，用于根据上述副本总数和上述副本分配比例，确定各上述节点组所需的副本数。

上述实施例中，先按照CPU架构的不同将多个计算节点分成CPU架构不同的多个节点组，每个节点组中至少包括一个计算节点；之后计算每个节点组的标准算力和；再根据多个标准算力和得到节点组之间的副本分配比例，并按照该副本分配比例给每个节点组分配pod，确定各个节点组的副本数，从而得到分配策略。这样可以进一步地保证为各节点组分配的副本数与其算力匹配，从而保证了对一云多芯架构集群的整体算力的充分利用。

为了进一步地解决现有一云多芯集群的部署方案无法充分利用集群的整体算力的问题，在另一些示例性实施例中，上述第一确定模块包括：计算子模块，用于计算多个上述标准算力和的总和，得到算力总和；第一确定子模块，用于确定各上述节点组的副本分配比例为上述标准算力和与上述算力总和之比。将节点组的标准算力与算力总和之比作为该节点组的副本分配比例，也就是将节点组之间的算力比例作为了副本分配比例，进一步地保证了后续根据该副本分配比例分配的副本数与该节点组的整体算力匹配，可以充分利用该节点组的整体算力，进一步地实现了对各计算节点的算力的充分利用。

在此基础上，上述第二确定模块包括：第二确定子模块，用于根据上述副本总数和上述副本分配比例，确定各上述节点组所需的副本数为上述副本总数与上述副本分配比例的乘积。

比如，ARM节点组的副本分配比例为2/5，X86节点组的副本分配比例为3/5，pod的副本总数为20，则为ARM节点组分配的副本数就是2/5×20=8个，为X86节点组分配的副本数就是3/5=12个。

由于CPU架构不同，各计算节点的算力是不同的，比如同样的16g内存，不同CPU架构的计算节点能达到的效果不一样，因此需要对计算节点的可用算力进行转换，该转换就是将计算节点的可用算力转换为标准算力。具体地，上述获取单元包括：调取模块，用于调取第一映射关系，上述第一映射关系为CPU架构与预设比例之间的映射关系，上述预设比例为上述CPU架构的计算节点标准算力与计算节点可用算力的比值；第三确定模块，用于根据各上述CPU架构和上述第一映射关系，确定各上述计算节点对应的上述预设比例为目标比例；第四确定模块，用于确定上述标准算力为上述计算节点的上述可用算力与对应的上述目标比例的乘积。对于不同CPU架构计算节点，从表征CPU架构与预设比例的第一映射关系中确定目标比例，将可用算力与该目标比例相乘，得到该计算节点的标准算力，可以较为简单快捷地实现不同架构计算节点的算力标准化。

其中，上述的第一映射关系为通过对不同CPU架构的计算节点的算力进行实验得到的。比如ARM架构对应的上述预设比例为1.2，那么在分配到ARM架构的节点时，原始数据中本来需要1核1g，由于是ARM架构的节点，需要更多的算力才能达到标准算力，此时就需要通过重写策略将1核1g，改为1.2核1.2g。

本申请中，上述获取单元包括：接收模块，用于实时接收各上述代理组件上报的CPU可用资源以及内存可用资源，得到上述可用算力。也就是说，接收各个计算节点的kubelet上报的该计算节点的CPU可用资源以及内存可用资源，作为该计算节点的可用算力。这样可以较为准确且快捷地获取到各个计算节点的可用算力。

另外，除了上述可用算力外，各个计算节点的kubelet还上报计算节点的CPU架构以及计算节点当前运行了多少个pod等信息。

根据本申请的又一些可选方案，上述工作负载信息包括副本总数，上述创建单元包括：第一创建模块，用于根据上述工作负载信息和上述节点组的数量，创建节点组的数量的上述工作负载，即上述共组负载的数量等于上述节点组的数量；第二创建模块，用于根据上述分发策略和上述副本总数，创建上述副本总数的上述pod，上述pod的初始配置参数相同，即上述pod的数量等于上述副本总数。本实施例中，根据工作负载信息，创建上述节点组的数量个工作负载，以及根据分发策略，创建副本总数个pod，其中，创建的各个节点组的pod的初始配置参数相同，这样简化了pod的创建过程。

在实际的应用过程中，可以直接创建上述副本总数个上述pod，也可以通过上述工作负载创建上述pod。上述工作负载的创建方式支持界面创建和Yaml创建。创建的上述工作负载的类型包括以下至少之一：部署、有状态副本集、守护进程集（DaemonSet）、任务（Job）以及定时任务（CronJob），具体根据上述部署请求中的工作负载信息确定。

具体地，不同CPU架构的计算节点，对应pod的配置参数是不同的，上述实施例中在创建pod时未区分CPU架构，对pod进行了相同的参数配置，为了防止pod无法正常绑定到计算节点上，一些示例性实施例中，上述部署请求还包括第二映射关系，上述第二映射关系为CPU架构与pod配置参数的映射关系，上述绑定请求包括上述初始配置参数，上述装置还包括：第一发送单元，用于在将pod创建请求发送至调度器之后，将上述第二映射关系发送至差异化配装器，使得上述差异化配装器在拦截到上述绑定请求的情况下，根据上述绑定节点和上述第二映射关系重写上述绑定请求中的上述初始配置参数，之后发送至上述代理组件。通过将第二映射关系发送给差异化配装器，使得差异化配装器根据绑定节点和第二映射关系重写pod的初始配置参数，以对不同架构计算节点上的pod进行定制化参数配置，从而保证pod的正常运作。

本申请中，上述pod配置参数包括以下至少部分：镜像信息、环境变量、上述pod的启动命令、上述pod的启动参数、上述pod的特权模式。

一种具体的实施例中，上述获取单元包括：第一获取模块，用于定时获取各上述计算节点的可用算力。本申请通过定时检测容器集群中各计算节点可用算力的变化，将可用算力转换为标准算力，并将各个架构的标准算力比例和转换为副本分配比例，在容器应用部署时基于多架构节点间容器应用的副本分配比例为容器应用选择合适的计算节点，进一步地保证了不同算力的计算节点的算力可以得到充分利用。

图5是根据本申请实施例的另一种多架构集群中容器的部署装置的结构框图，该装置应用于架构集群中的调度器，如图5所示，该装置包括：

第二确定单元21，用于在接收到pod创建请求的情况下，根据分发策略，从多个节点组中确定待分配的节点组，其中，上述pod为控制器根据上述分发策略和工作负载信息创建的，上述分发策略为控制器根据多个标准算力和工作负载信息确定的，上述分发策略包括上述节点组的数量和各上述节点组所需的副本数，同一个上述节点组中计算节点的CPU架构相同，上述控制器接收的部署请求包括上述工作负载信息，多个上述标准算力为上述控制器获取各上述计算节点的可用算力，并对多个上述可用算力进行标准化得到的；

具体地，该pod创建请求为控制器发出的请求信息。一个上述节点组由CPU架构相同的多个计算节点组成，不同的节点组的CPU架构不同。上述工作负载信息为创建工作负载所用的信息，包括工作负载的基础信息，工作负载为Kubernetes上运行的程序，用于创建pod以及对容器应用进行编排。

上述计算节点为服务器，上述可用算力为计算节点当前可使用的算力，上述可用算力包括以下至少之一：上述计算节点的CPU可用资源、内存可用资源、GPU可用资源以及硬盘可用资源。上述CPU架构包括但不限于X86架构、ARM架构以及RISC架构等现有的CPU架构。

打分单元22，用于根据预设打分策略，对上述待分配的节点组中的各上述计算节点进行打分，确定分数最高的上述计算节点为上述pod的绑定节点，并发送对上述绑定节点和上述pod进行绑定的绑定请求至代理组件，以实现上述绑定节点与上述pod的绑定。

具体地，上述待分配的节点组为需要分配该pod的上述节点组。上述预设打分策略可以为Kubernetes中预设的对计算节点进行打分的规则。上述代理组件为该绑定节点的代理组件，具体为Kubelet，Kubelet是kubernetes计算节点上的一个代理组件，运行在每个计算节点上。

本申请的上述方案中，在接收到pod创建请求时，通过第二确定单元确定待分配该pod的节点组；通过打分单元根据预设打分策略，对该待分配的节点组中的各计算节点进行打分，确定绑定节点，并发送绑定请求给该绑定节点的代理组件，实现该绑定节点与pod的绑定，其中，同一个上述节点组中计算节点的CPU架构相同，pod为控制器根据分发策略和接收到的工作负载信息创建的，该分发策略为控制器根据多个标准算力和工作负载信息确定的，多个上述标准算力为上述控制器获取各上述计算节点的可用算力，并对多个上述可用算力进行标准化得到的。本申请根据分发策略通过预设打分策略从待分配的节点组中选择分数最高的绑定节点，使得pod与该绑定节点进行绑定，实现了将pod调度到当前最优的计算节点上。并且，该调度过程是基于分发策略进行的，该分发策略是控制器对不同CPU架构的可用算力标准化，再根据标准化后的标准算力确定的，实现了基于计算节点的标准算力为容器应用选择合适的容器节点，实现了对不同架构进行差异化的计算资源分配，从而保证了对一云多芯架构集群的整体算力的充分利用。

具体地，上述第二确定单元具体包括：第五确定模块，用于根据各节点组所需的副本数和已经分配的副本数，确定需要分配pod的节点组为节点组所需的副本数和已经分配的副本数的差值大于0的节点组；选择模块，用于从需要分配pod的节点组中随机选择节点组作为上述待分配的节点组。

当然，在确定需要分配pod的节点组之后，也可以根据一些人为定义的规则从需要分配pod的节点组中按照规则选择节点组来作为上述待分配的节点组，本领域技术人员可以根据实际需求灵活设置上述的规则内容，比如该规则为从需要分配pod的节点组中选择差值最大或者最小的节点组作为上述待分配的节点组。

一种可选方案中，上述装置还包括：放入单元，用于将多个上述pod分别放入调度队列。通过将上述pod放入调度队列，从调度队列中依次读取pod并进行pod绑定，可以加快调度器的响应速度。

具体地，可以在确定待分配的节点组之前，将所有创建且未绑定的上述pod放入上述调度队列中。也可以在确定待分配的节点组之后，将需要分配给该待分配的节点组的、所有创建且未绑定的pod放入调度队列中。

根据本申请的一些可选实施例，上述打分单元包括：读取模块，用于步骤S1，从上述调度队列中读取一个上述pod；打分模块，用于步骤S2，根据上述预设打分策略，对上述待分配的节点组中的各上述计算节点进行打分，确定上述分数最高的上述计算节点为上述pod的上述绑定节点；发送模块，用于步骤S3，发送对上述绑定节点和上述pod进行绑定的绑定请求至代理组件；循环模块，用于步骤S4，循环执行上述步骤S1、上述步骤S2以及上述步骤S3，直到完成上述待分配的节点组对应的所有的上述pod的绑定。本实施例中，通过将pod加入调度队列中，通过循环执行读取pod和打分过程，来确定每个pod对应的绑定节点并进行pod绑定，进一步地实现了为每个待绑定的pod选择当前最优的计算节点。

另外，在确定待分配的节点组之前，将所有创建且未绑定的上述pod放入上述调度队列中的情况下，本申请可以先执行上述步骤S1，再执行步骤S202：根据分发策略，从多个节点组中确定上述pod对应的待分配的节点组，这种情况下，上述循环模块用于循环执行上述步骤S1、步骤S202、步骤S2以及步骤S3，直到完成所有的上述pod的绑定。

为了进一步地简化打分过程，进一步地保证可以较为快速地确定绑定节点，在一个示例性实施例中，上述装置还包括：第三确定单元，用于在步骤S2之后，在步骤S3之前，执行步骤S5，根据上述pod的需求算力和各上述可用算力，确定待过滤的计算节点，并从上述待分配的节点组中去除上述待过滤的计算节点，得到多个过滤后节点，上述发送模块还用于根据上述预设打分策略，对各上述过滤后节点进行打分，确定上述分数最高的上述过滤后节点为上述pod的上述绑定节点。本实施例先根据pod的需求算力和待分配的节点组中各个计算节点的可用算力，去除待过滤的计算节点，保证了后续进行打分计算的计算节点数量较少，可以较为快速地得到待分配的节点组中剩余计算节点的分数，从而可以较为快速地确定该pod的绑定节点。

其中，上述待过滤的计算节点为可用算力小于上述pod的需求算力的计算节点。

根据本申请的另一种示例性实施例，上述打分单元包括：第二获取模块，用于获取上述待分配的节点组中各上述计算节点的以下至少部分参数：CPU使用率、内存使用率、存储空间大小以及现有任务执行进度，上述现有任务执行进度为上述计算节点执行完成现有任务所需的时长；加权模块，用于根据预设权重，对上述待分配的节点组中各上述计算节点对应的上述至少部分参数进行加权求和，得到各上述计算节点的上述分数。本实施例中，对CPU使用率、内存使用率、存储空间大小以及现有任务执行进度中至少部分进行加权求和，得到计算节点的分数，使得分数可以充分体现出上述计算节点当前的可用资源，从而进一步地保证为pod选择出当前最优的计算节点。

为了可以进一步地保证为各节点组分配的副本数与其算力匹配，从而保证了各个计算节点算力的充分利用，在一个示例性实施例中，上述工作负载信息包括副本总数，上述节点组的数量为上述控制器按照各上述计算节点的CPU架构对多个上述计算节点分组得到的多个上述节点组确定的，各上述节点组所需的副本数为上述控制器根据上述副本总数和各上述节点组的副本分配比例确定的，上述副本分配比例为上述控制器根据多个上述节点组的标准算力和确定的，上述标准算力和为上述控制器根据多个上述标准算力计算得到的。

由于CPU架构不同，各计算节点的算力是不同的，比如同样的16g内存，不同CPU架构的计算节点能达到的效果不一样，因此需要对计算节点的可用算力进行转换，该转换就是将计算节点的可用算力转换为标准算力。在一个示例性实施例中，上述标准算力为上述控制器确定的上述计算节点的可用算力与对应的目标比例的乘积，上述目标比例为上述控制器根据各上述CPU架构和第一映射关系确定的各上述计算节点对应的预设比例，上述第一映射关系为上述控制器调取得到的上述CPU架构与上述预设比例之间的映射关系，上述预设比例为上述CPU架构的计算节点标准算力与计算节点可用算力的比值。对于不同CPU架构计算节点，控制器从表征CPU架构与预设比例的第一映射关系中确定目标比例，将可用算力与该目标比例相乘，得到该计算节点的标准算力，可以较为简单快捷地实现不同架构计算节点的算力标准化。

其中，上述的第一映射关系为通过对不同CPU架构的计算节点的算力进行实验得到的。比如ARM架构对应的上述预设比例为1.2，那么在分配到ARM架构的节点时，原始数据中本来需要1核1g，由于是ARM架构的节点，需要更多的算力才能达到标准算力，此时就需要通过重写策略将1核1g，改为1.2核1.2g。

为了进一步地解决现有一云多芯集群的部署方案无法充分利用集群的整体算力的问题，具体地，上述副本分配比例为上述控制器将标准算力与算力总和相除得到的，上述算力总和为上述控制器计算多个上述标准算力和的总和得到的，上述节点组所需的副本数为上述控制器计算上述副本总数与上述副本分配比例的乘积得到的。控制器将节点组的标准算力与算力总和之比作为该节点组的副本分配比例，也就是将节点组之间的算力比例作为了副本分配比例，进一步地保证了后续根据该副本分配比例分配的副本数与该节点组的整体算力匹配，可以充分利用该节点组的整体算力，进一步地实现了对各计算节点的算力的充分利用。

比如，ARM节点组的副本分配比例为2/5，X86节点组的副本分配比例为3/5，pod的副本总数为20，则为ARM节点组分配的副本数就是2/5×20=8个，为X86节点组分配的副本数就是3/5=12个。

根据本申请的另一种可选实施例，上述工作负载的数量等于节点组的数量，节点组的数量的上述工作负载为上述控制器根据上述工作负载信息和上述节点组的数量创建的；上述pod的数量等于上述副本总数，上述pod的数量为根据上述分发策略和上述副本总数创建的，上述pod的初始配置参数相同。

在实际的应用过程中，上述副本总数个上述pod可以是控制器可以直接创建的，也可以通过上述工作负载创建的。上述工作负载的创建方式支持界面创建和Yaml创建。创建的上述工作负载的类型包括以下至少之一：部署、有状态副本集、守护进程集（DaemonSet）、任务（Job）以及定时任务（CronJob），具体根据上述部署请求中的工作负载信息确定。

另外，在发送对上述绑定节点和上述pod进行绑定的绑定请求至代理组件的过程中，上述绑定请求会被差异化配装器拦截，上述差异化配装器根据控制器发送的第二映射关系和上述绑定节点，重写上述绑定请求中的初始配置参数，再发送给代理组件，其中，上述第二映射关系为CPU架构与pod配置参数的映射关系，上述控制器接收到的部署请求中包括上述第二映射关系。由于不同CPU架构的计算节点，对应pod的配置参数是不同的，控制器在创建pod时未区分CPU架构，对pod进行了相同的参数配置，因此为了防止pod无法正常绑定到计算节点上，通过差异化配装器重写pod的初始配置参数，以对不同架构计算节点上的pod进行定制化参数配置，从而保证pod的正常运作。

具体地，上述pod配置参数包括以下至少部分：镜像信息、环境变量、上述pod的启动命令、上述pod的启动参数、上述pod的特权模式。

可选地，各上述计算节点的可用算力为上述控制器定时获取到的。本申请的控制器通过定时检测容器集群中各计算节点可用算力的变化，将可用算力转换为标准算力，并将各个架构的标准算力比例和转换为副本分配比例，在容器应用部署时基于多架构节点间容器应用的副本分配比例为容器应用选择合适的计算节点，进一步地保证了不同算力的计算节点的算力可以得到充分利用。

图6是根据本申请实施例的多架构集群中容器的部署装置的结构框图，该装置应用于架构集群中的差异化配装器，如图6所示，该装置包括：

第二接收单元31，用于接收控制器发送的第二映射关系，上述第二映射关系为CPU架构与pod配置参数的映射关系；

具体地，上述pod配置参数包括以下至少部分：镜像信息、环境变量、上述pod的启动命令、上述pod的启动参数、上述pod的特权模式。上述CPU架构包括但不限于X86架构、ARM架构以及RISC架构等现有的CPU架构。

拦截单元32，用于拦截调度器发送的绑定请求，上述绑定请求为对绑定节点和上述pod进行绑定的请求信息，上述绑定节点为上述调度器根据预设打分策略，对待分配的节点组中的各计算节点进行打分确定的分数最高的上述计算节点，上述绑定请求包括初始配置参数，多个上述pod的初始配置参数相同，上述待分配的节点组为上述调度器在接收到pod创建请求的情况下，根据分发策略从多个节点组中确定的，上述分发策略为控制器根据多个标准算力和工作负载信息确定的，上述分发策略包括上述节点组的数量和各上述节点组所需的副本数，同一个上述节点组中计算节点的CPU架构相同，多个上述标准算力为上述控制器获取各上述计算节点的可用算力，并对多个上述可用算力进行标准化得到的；

具体地，该pod创建请求为控制器发出的请求信息。一个上述节点组由CPU架构相同的多个计算节点组成，不同的节点组的CPU架构不同。上述计算节点为服务器，上述可用算力为计算节点当前可使用的算力，上述可用算力包括以下至少之一：上述计算节点的CPU可用资源、内存可用资源、GPU可用资源以及硬盘可用资源。

重写单元33，用于根据上述绑定节点和上述第二映射关系，对上述初始配置参数进行重写；

第二发送单元34，用于将重写后的上述绑定请求发送至上述绑定节点的代理组件。

具体地，上述代理组件为该绑定节点的代理组件，具体为Kubelet，Kubelet是kubernetes计算节点上的一个代理组件，运行在每个计算节点上。

本申请的上述方案中，通过第二接收单元接收控制器发送的表征CPU架构与pod配置参数的映射关系的第二映射关系，通过拦截单元拦截调度器发送的请求对绑定节点和上述pod进行绑定的绑定请求，通过重写单元根据上述绑定节点和上述第二映射关系，对上述初始配置参数进行重写，通过第二发送单元将重写后的上述绑定请求发送给绑定节点的代理组件，实现绑定节点与pod的绑定，实现了对不同架构计算节点上的pod进行定制化参数配置，从而保证pod的正常运作，满足容器应用在不同架构下运行的差异化要求。并且，本申请的调度器根据分发策略通过预设打分策略从待分配的节点组中选择分数最高的绑定节点，使得pod与该绑定节点进行绑定，实现了将pod调度到当前最优的计算节点上。另外，该调度过程是基于分发策略进行的，该分发策略是控制器对不同CPU架构的可用算力标准化，再根据标准化后的标准算力确定的，实现了基于计算节点的标准算力为容器应用选择合适的容器节点，实现了对不同架构进行差异化的计算资源分配，从而保证了对一云多芯架构集群的整体算力的充分利用。

并且，本申请简化了运维人员管理多架构集群的操作难度，运维人员在部署容器集群中不需要额外考虑各CPU架构节点间算力的差异，只需要设置对应的参数配置，即上述部署请求，本申请即可根据该部署请求为容器应用基于标准算力进行副本分发以及pod参数的差异化配置，简化了一云多芯容器集群的管理复杂度，增强了一云多芯容器集群下的可维护性以及易用性。

为了进一步地避免pod无法正常绑定到计算节点上，在一个示例性实施例中，上述重写单元包括：第六确定模块，用于根据上述绑定节点和上述第二映射关系，确定与上述绑定节点的CPU架构对应的上述pod配置参数为目标配置参数；重写模块，用于根据上述目标配置参数，将上述初始配置参数重写为上述目标配置参数。

需要说明的是，上述各个模块是可以通过软件或硬件来实现的，对于后者，可以通过以下方式实现，但不限于此：上述模块均位于同一处理器中；或者，上述各个模块以任意组合的形式分别位于不同的处理器中。

本申请的实施例还提供了一种计算机可读存储介质，该计算机可读存储介质中存储有计算机程序，其中，该计算机程序被设置为运行时执行上述任一项方法实施例中的步骤。

在一个示例性实施例中，上述计算机可读存储介质可以包括但不限于：U盘、只读存储器（Read-Only Memory，简称为ROM）、随机存取存储器（Random Access Memory，简称为RAM）、移动硬盘、磁碟或者光盘等各种可以存储计算机程序的介质。

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

在一个示例性实施例中，上述电子设备还可以包括传输设备以及输入输出设备，其中，该传输设备和上述处理器连接，该输入输出设备和上述处理器连接。

本申请的实施例还提供了一种如图7所示的多架构集群，如图7所示，上述多架构集群包括：

多个计算节点100，部分的上述计算节点100的CPU架构不同；

具体地，上述计算节点包括代理组件，该代理组件具体可以为Kubelet，部分的上述计算节点上绑定有pod。

控制器101，包括存储器、处理器以及存储在上述存储器上并可在上述处理器上运行的计算机程序，上述处理器执行上述计算机程序时实现任一种上述的方法的步骤；

调度器102，与上述控制器101以及上述计算节点100的代理组件分别通信连接，上述调度器用于执行任一种上述的方法的步骤；

差异化配装器103，与上述代理组件通信连接，上述差异化配装器用于执行任一种上述的方法的步骤。

上述的多架构集群中，控制器对不同CPU架构的可用算力标准化，再根据标准化后的标准算力确定各CPU架构对应的副本数，从而创建工作负载和pod，基于计算节点的标准算力为容器应用选择合适的容器节点，实现了对不同架构进行差异化的计算资源分配，从而保证了对一云多芯架构集群的整体算力的充分利用；调度器根据分发策略通过预设打分策略从待分配的节点组中选择分数最高的绑定节点，使得pod与该绑定节点进行绑定，实现了将pod调度到当前最优的计算节点上；差异化配装器拦截调度器发送的绑定请求，再根据绑定节点和第二映射关系，对初始配置参数进行重写后发送给绑定节点的代理组件，使得绑定节点与pod绑定，实现了对不同架构计算节点上的pod进行定制化参数配置，满足了容器应用在不同架构下运行的差异化要求。

Kubelet在接收到重写后的上述绑定请求的情况下，根据重写后的配置参数启动pod。

另外，本申请的多架构集群简化了运维人员管理多架构集群的操作难度，运维人员在部署容器集群中不需要额外考虑各CPU架构节点间算力的差异，只需要设置对应的参数配置，即上述部署请求，本申请即可根据该部署请求为容器应用基于标准算力进行副本分发以及pod参数的差异化配置，简化了一云多芯容器集群的管理复杂度，增强了一云多芯容器集群下的可维护性以及易用性。

本申请的上述多架构集群中，在多芯场景部署容器应用时，控制器可以根据标准化后的算力为计算节点分配pod，调度器为pod调度最优计算节点进行绑定，差异化装配器自动对pod的配置参数进行定制化重写，从而不需要再为容器应用设置不同的节点调度策略与节点选择策略，降低了云平台维护成本。基于标准算力计算可分发节点，避免了不同计算节点因为算力差异导致的应用算力不一致的问题，使得计算节点的算力得到了充分利用，从而节省了算力成本。并且本申请实现了自动选择合适的计算节点，不需要设置对应的节点选择策略以及或节点亲和性策略。

本申请的上述多架构集群支持基于节点信息自动重载容器应用，不需要用户手工修改，支持阈值触发、智能触发、定时触发多种扩容策略。

具体的一种实施例中，上述多架构集群的资源模型定义图如图8所示。主要分为三部分，第一部分为工作负载的模型信息，用于创建、更新工作负载资源；第二部分为不同CPU架构计算节点下pod的差异化配置参数的模型信息，基于CPU架构的不同，为容器应用设置不同的镜像信息、环境变量等pod配置参数。第三部分为分发策略的模型信息，该部分通过对各计算节点的可用算力变化进行监听，基于工作负载中副本总数的要求（standardResource），以及预先设置的各节点算力与标准算力的比例，在分发前基于集群中的可使用CPU架构，设置分配不同的副本数。

本实施例中的具体示例可以参考上述实施例及示例性实施方式中所描述的示例，本实施例在此不再赘述。

显然，本领域的技术人员应该明白，上述的本申请的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本申请不限制于任何特定的硬件和软件结合。

以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (18)

1.一种多架构集群中容器的部署方法，其特征在于，包括：

获取各计算节点的可用算力，并对多个所述可用算力进行标准化，得到多个标准算力，其中，部分的所述计算节点的CPU架构不同；

接收对多架构集群中容器进行部署的部署请求，所述部署请求包括工作负载信息；

根据多个所述标准算力以及所述工作负载信息，确定分发策略，所述分发策略包括节点组的数量和各所述节点组所需的副本数，其中，同一个所述节点组中所述计算节点的CPU架构相同；

根据所述分发策略和所述工作负载信息，创建所述工作负载以及pod，并将pod创建请求发送至调度器，使得所述调度器确定绑定节点并发送绑定请求至所述绑定节点的代理组件，所述绑定节点为与所述pod绑定的所述计算节点，

所述工作负载信息包括副本总数，根据所述分发策略和所述工作负载信息，创建所述工作负载以及pod，包括：

根据所述工作负载信息和所述节点组的数量，创建节点组的数量的所述工作负载；

根据所述分发策略和所述副本总数，创建所述副本总数的所述pod，所述pod的初始配置参数相同，

所述部署请求还包括第二映射关系，所述第二映射关系为CPU架构与pod配置参数的映射关系，所述绑定请求包括所述初始配置参数，在将pod创建请求发送至调度器之后，所述方法还包括：

将所述第二映射关系发送至差异化配装器，使得所述差异化配装器在拦截到所述绑定请求的情况下，根据所述绑定节点和所述第二映射关系重写所述绑定请求中的所述初始配置参数，之后发送至所述代理组件。

2.根据权利要求1所述的方法，其特征在于，所述工作负载信息包括副本总数，根据多个所述标准算力以及所述工作负载信息，确定分发策略，包括：

按照各所述计算节点的CPU架构对多个所述计算节点分组，得到多个所述节点组，得到所述节点组的数量；

根据多个所述标准算力，计算各所述节点组的标准算力和；

根据多个所述标准算力和，确定多个所述节点组的副本分配比例；

根据所述副本总数和所述副本分配比例，确定各所述节点组所需的副本数。

3.根据权利要求2所述的方法，其特征在于，

根据多个所述标准算力和，确定多个所述节点组的副本分配比例，包括：计算多个所述标准算力和的总和，得到算力总和；确定各所述节点组的副本分配比例为所述标准算力和与所述算力总和之比，

根据所述副本总数和所述副本分配比例，确定各所述节点组所需的副本数，包括：根据所述副本总数和所述副本分配比例，确定各所述节点组所需的副本数为所述副本总数与所述副本分配比例的乘积。

4.根据权利要求2所述的方法，其特征在于，对多个所述可用算力进行标准化，得到多个标准算力，包括：

调取第一映射关系，所述第一映射关系为CPU架构与预设比例之间的映射关系，所述预设比例为所述CPU架构的计算节点标准算力与计算节点可用算力的比值；

根据各所述CPU架构和所述第一映射关系，确定各所述计算节点对应的所述预设比例为目标比例；

确定所述标准算力为所述计算节点的所述可用算力与对应的所述目标比例的乘积。

5.根据权利要求1至4中任一项所述的方法，其特征在于，获取各计算节点的可用算力，包括：

实时接收各所述代理组件上报的CPU可用资源以及内存可用资源，得到所述可用算力。

6.一种多架构集群中容器的部署方法，其特征在于，包括：

在接收到pod创建请求的情况下，根据分发策略，从多个节点组中确定待分配的节点组，其中，所述pod为控制器根据所述分发策略和工作负载信息创建的，所述分发策略为控制器根据多个标准算力和工作负载信息确定的，所述分发策略包括所述节点组的数量和各所述节点组所需的副本数，同一个所述节点组中计算节点的CPU架构相同，所述控制器接收的部署请求包括所述工作负载信息，多个所述标准算力为所述控制器获取各所述计算节点的可用算力，并对多个所述可用算力进行标准化得到的；

根据预设打分策略，对所述待分配的节点组中的各所述计算节点进行打分，确定分数最高的所述计算节点为所述pod的绑定节点，并发送对所述绑定节点和所述pod进行绑定的绑定请求至代理组件，以实现所述绑定节点与所述pod的绑定，

所述工作负载信息包括副本总数，所述工作负载的数量等于节点组的数量，所述节点组的数量的所述工作负载为根据所述工作负载信息和所述节点组的数量创建的，所述pod的数量等于所述副本总数，所述副本总数的所述pod为根据所述分发策略和所述副本总数创建的，所述pod的初始配置参数相同，

所述部署请求还包括第二映射关系，所述第二映射关系为CPU架构与pod配置参数的映射关系，所述绑定请求包括所述初始配置参数，所述绑定请求在发送至代理组件的过程中被差异化配装器拦截，并在所述差异化配装器根据所述绑定节点和所述第二映射关系重写所述绑定请求中的所述初始配置参数之后，发送至所述代理组件。

7.根据权利要求6所述的方法，其特征在于，在根据预设打分策略，对所述待分配的节点组中的各所述计算节点进行打分之前，所述方法还包括：

将多个所述pod分别放入调度队列。

8.根据权利要求7所述的方法，其特征在于，根据预设打分策略，对所述待分配的节点组中的各所述计算节点进行打分，确定分数最高的所述计算节点为所述pod的绑定节点，并发送对所述绑定节点和所述pod进行绑定的绑定请求至代理组件，包括：

步骤S1，从所述调度队列中读取一个所述pod；

步骤S2，根据所述预设打分策略，对所述待分配的节点组中的各所述计算节点进行打分，确定所述分数最高的所述计算节点为所述pod的所述绑定节点；

步骤S3，发送对所述绑定节点和所述pod进行绑定的绑定请求至代理组件；

步骤S4，循环执行所述步骤S1、所述步骤S2以及所述步骤S3，直到完成所述待分配的节点组对应的所有的所述pod的绑定。

9.根据权利要求8所述的方法，其特征在于，

在步骤S1之后，在步骤S2之前，所述方法还包括：步骤S5，根据所述pod的需求算力和各所述可用算力，确定待过滤的计算节点，并从所述待分配的节点组中去除所述待过滤的计算节点，得到多个过滤后节点，

所述步骤S2包括：根据所述预设打分策略，对各所述过滤后节点进行打分，确定所述分数最高的所述过滤后节点为所述pod的所述绑定节点。

10.根据权利要求6至9中任一项所述的方法，其特征在于，根据预设打分策略，对所述待分配的节点组中的各所述计算节点进行打分，包括：

获取所述待分配的节点组中各所述计算节点的以下至少部分参数：CPU使用率、内存使用率、存储空间大小以及现有任务执行进度，所述现有任务执行进度为所述计算节点执行完成现有任务所需的时长；

根据预设权重，对所述待分配的节点组中各所述计算节点对应的所述至少部分参数进行加权求和，得到各所述计算节点的所述分数。

11.根据权利要求6至9中任一项所述的方法，其特征在于，所述节点组的数量为所述控制器按照各所述计算节点的CPU架构对多个所述计算节点分组得到的多个所述节点组确定的，各所述节点组所需的副本数为所述控制器根据所述副本总数和各所述节点组的副本分配比例确定的，所述副本分配比例为所述控制器根据多个所述节点组的标准算力和确定的，所述标准算力和为所述控制器根据多个所述标准算力计算得到的。

12.根据权利要求6至9中任一项所述的方法，其特征在于，所述标准算力为所述控制器确定的所述计算节点的可用算力与对应的目标比例的乘积，所述目标比例为所述控制器根据各所述CPU架构和第一映射关系确定的各所述计算节点对应的预设比例，所述第一映射关系为所述控制器调取得到的所述CPU架构与所述预设比例之间的映射关系，所述预设比例为所述CPU架构的计算节点标准算力与计算节点可用算力的比值。

13.一种多架构集群中容器的部署方法，其特征在于，包括：

接收控制器发送的第二映射关系，所述第二映射关系为CPU架构与pod配置参数的映射关系；

拦截调度器发送的绑定请求，所述绑定请求为对绑定节点和所述pod进行绑定的请求信息，所述绑定节点为所述调度器根据预设打分策略，对待分配的节点组中的各计算节点进行打分确定的分数最高的所述计算节点，所述绑定请求包括初始配置参数，多个所述pod的初始配置参数相同，所述待分配的节点组为所述调度器在接收到pod创建请求的情况下，根据分发策略从多个节点组中确定的，所述分发策略为控制器根据多个标准算力和工作负载信息确定的，所述分发策略包括所述节点组的数量和各所述节点组所需的副本数，同一个所述节点组中计算节点的CPU架构相同，多个所述标准算力为所述控制器获取各所述计算节点的可用算力，并对多个所述可用算力进行标准化得到的；

根据所述绑定节点和所述第二映射关系，对所述初始配置参数进行重写；

将重写后的所述绑定请求发送至所述绑定节点的代理组件。

14.根据权利要求13所述的方法，其特征在于，根据所述绑定节点和所述第二映射关系，对所述初始配置参数进行重写，包括：

根据所述绑定节点和所述第二映射关系，确定与所述绑定节点的CPU架构对应的所述pod配置参数为目标配置参数；

根据所述目标配置参数，将所述初始配置参数重写为所述目标配置参数。

15.根据权利要求13或者14所述的方法，其特征在于，所述pod配置参数包括以下至少部分：镜像信息、环境变量、所述pod的启动命令、所述pod的启动参数、所述pod的特权模式。

16.一种多架构集群中容器的部署装置，其特征在于，包括：

获取单元，用于获取各计算节点的可用算力，并对多个所述可用算力进行标准化，得到多个标准算力，其中，部分的所述计算节点的CPU架构不同；

第一接收单元，用于接收对多架构集群中容器进行部署的部署请求，所述部署请求包括工作负载信息；

第一确定单元，用于根据多个所述标准算力以及所述工作负载信息，确定分发策略，所述分发策略包括节点组的数量和各所述节点组所需的副本数，其中，同一个所述节点组中所述计算节点的CPU架构相同；

创建单元，用于根据所述分发策略和所述工作负载信息，创建所述工作负载以及pod，并将pod创建请求发送至调度器，使得所述调度器确定绑定节点并发送绑定请求至所述绑定节点的代理组件，所述绑定节点为与所述pod绑定的所述计算节点，

所述工作负载信息包括副本总数，所述创建单元包括：

第一创建模块，用于根据所述工作负载信息和所述节点组的数量，创建节点组的数量的所述工作负载；

第二创建模块，用于根据所述分发策略和所述副本总数，创建所述副本总数的所述pod，所述pod的初始配置参数相同，

所述部署请求还包括第二映射关系，所述第二映射关系为CPU架构与pod配置参数的映射关系，所述绑定请求包括所述初始配置参数，所述装置还包括：

第一发送单元，用于在将pod创建请求发送至调度器之后，将所述第二映射关系发送至差异化配装器，使得所述差异化配装器在拦截到所述绑定请求的情况下，根据所述绑定节点和所述第二映射关系重写所述绑定请求中的所述初始配置参数，之后发送至所述代理组件。

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

18.一种多架构集群，其特征在于，包括：

多个计算节点，部分的所述计算节点的CPU架构不同；

控制器，包括存储器、处理器以及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现权利要求1至5中任一项所述的方法的步骤；

调度器，与所述控制器以及所述计算节点的代理组件分别通信连接，所述调度器用于执行权利要求6至12中任一项所述的方法的步骤；

差异化配装器，与所述代理组件通信连接，所述差异化配装器用于执行权利要求13至15中任一项所述的方法的步骤。