容器CPU资源调度与隔离方法和装置、存储介质及电子设备

技术领域

本发明涉计算机技术领域，具体而言，涉及一种容器CPU资源调度与隔离方法和装置、存储介质及电子设备。

背景技术

Kubernetes是目前业界最主流、应用最广泛的的开源容器计算平台，其允许用户简单高效地在一批通用基础设施节点上部署容器应用，并提供了一套应用部署、规划、更新、维护的全生命周期管理机制，以满足不同的实际需求。

然而原生Kubernetes将每个节点上的资源作为一个整体来看待。在排除掉为系统预留的资源之后，节点上的所有剩余资源都被Kubernetes纳入一个单独的可调度资源池，调度器在为容器pod选择节点时，是以这个可调度资源池的总空余量来评估的；而当pod在节点上运行时，整个可调度池的资源都是可以被使用的，无法进行精确的绑核或隔离控制。

针对上述原生Kubernetes的资源管理与调度机制无法满足不同类型的pod对CPU资源的精确隔离需求的问题，目前尚未提出有效的解决方案。

发明内容

本发明实施例提供了一种容器CPU资源调度与隔离方法和装置、存储介质及电子设备，以至少解决原生Kubernetes的资源管理与调度机制无法满足不同类型的pod对CPU资源的精确隔离需求的问题。

根据本发明的一个方面，提供了一种容器CPU资源调度与隔离方法，包括：

容器编排引擎规划并创建资源池，并令各节点将自身CPU资源按资源池进行划分；容器编排引擎获取容器创建信息；其中，所述容器创建信息包含期望进入的资源池标签；容器编排引擎根据所述资源池标签以及各节点对应的资源池的状态，确定出目标节点；容器编排引擎发送容器创建指令至所述目标节点的执行代理模块，以使所述执行代理模块创建容器并将所述容器与所述资源池对应的CPU核进行绑定。

根据本发明的另一个方面，提供了一种容器CPU资源调度与隔离方法，包括：当前节点上的执行代理模块接收容器编排引擎发送的容器创建指令，其中，上述容器创建指令携带需要创建容器的配置数据以及待绑定的资源池的配置信息，上述配置信息包含资源池标签；上述执行代理模块根据上述容器创建指令，调用业务执行的节点上的容器运行时接口CRI创建容器并根据上述资源池标签确定出对应的CPU核索引；将上述资源池标签和对应的CPU核索引发送至上述CRI,以使CRI将上述容器与上述资源池对应的CPU核进行绑定；执行代理模块发送容器创建结果信息至上述容器编排引擎的调度器。

根据本发明的另一个方面，提供了一种容器CPU资源调度与隔离装置，包括：第一创建单元，用于创建资源池，并令各节点将自身CPU资源按资源池进行划分；获取单元，用于获取容器创建信息；其中，所述容器创建信息包含期望进入的资源池标签；确定单元，用于根据所述资源池标签以及各节点对应的资源池的状态，确定出目标节点；发送单元，用于容器编排引擎发送容器创建指令至所述目标节点的执行代理模块，以使所述执行代理模块创建容器并将所述容器与所述资源池对应的CPU核进行绑定。

根据本发明的另一个方面，提供了一种CPU资源调度与隔离装置，包括：接收单元，用于接收容器编排引擎发送的容器创建指令，其中，所述容器创建指令携带需要创建容器配置数据以及待绑定的资源池的配置信息，所述配置信息包含资源池标签；第二创建单元，用于根据所述容器创建指令，调用业务执行的节点上的容器运行时接口CRI创建容器并将所述容器与所述资源池对应的CPU核进行绑定；第一发送单元，用于将所述资源池标签和对应的CPU核索引发送至所述CRI,以使多少CRI将所述容器与所述资源池对应的CPU核进行绑定；第二发送单元，用于发送任务创建结果信息至所述容器编排引擎的调度器。

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

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

通过本发明实施例，采用了调度器从容器编排引擎获取容器的创建指令；其中，上述创建指令携带上述容器期望进入的资源池标签以及资源需求量；根据当前各节点对应的资源池的状态信息，选择与上述资源池标签和资源需求量匹配的目标节点；在上述目标节点上创建上述容器的方式；由于根据当前各节点对应的资源池的状态信息，选择与上述资源池标签和资源需求量匹配的目标节点，可以精确控制容器绑定的CPU资源以及允许以资源池为单位进行评估调度，而且能够更灵活与精确的对CPU资源管控与隔离的技术效果。

附图说明

图1是根据本发明实施例的容器CPU资源调度与隔离方法的通信设备的硬件结构框图；

图2是根据本发明实施例的一种容器CPU资源调度与隔离方法的流程图；

图3是根据本发明实施例的另一种容器CPU资源调度与隔离方法的流程图；

图4是根据本发明实施例的一种容器CPU资源调度与隔离方法的节点调度状态示意图；

图5是根据本发明实施例的一种容器CPU资源调度与隔离方法的节点运行进程示意图；

图6是根据本发明实施例的一种容器CPU资源调度与隔离方法的节点CPU资源池示意图；

图7是根据本发明实施例的一种容器CPU资源调度与隔离系统的架构示意图；

图8是根据本发明实施例的另一种容器CPU资源调度与隔离方法的流程图；

图9是根据本发明实施例的又一种容器CPU资源调度与隔离方法的流程图；

图10是根据本发明实施例的另一种容器CPU资源调度与隔离方法的流程图；

图11是根据本发明实施例的又一种容器CPU资源调度与隔离方法的流程图；

图12是根据本发明实施例的又一种容器CPU资源调度与隔离方法的流程图；

图13是根据本发明实施例的一种容器CPU资源调度与隔离方法的节点资源划分示意图；

图14是根据本发明实施例的另一种容器CPU资源调度与隔离方法的节点资源划分示意图；

图15是根据本发明实施例的另一种容器CPU资源调度与隔离方法的节点资源划分示意图；

图16是根据本发明实施例的一种容器CPU资源调度与隔离装置的结构示意图；

图17是根据本发明实施例的另一种容器CPU资源调度与隔离装置的结构示意图。

具体实施方式

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

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

本申请实施例中所提供的方法实施例可以在移动终端、计算机终端或者类似的运算装置中执行。以运行在移动终端上为例，图1是本发明实施例的一种容器CPU资源调度与隔离方法的移动终端的硬件结构框图。如图1所示，移动终端可以包括一个或多个(图1中仅示出一个)处理器102(处理器102可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置)和用于存储数据的存储器104，其中，上述移动终端还可以包括用于通信功能的传输设备106以及输入输出设备108。本领域普通技术人员可以理解，图1所示的结构仅为示意，其并不对上述移动终端的结构造成限定。例如，移动终端还可包括比图1中所示更多或者更少的组件，或者具有与图1所示不同的配置。

存储器104可用于存储计算机程序，例如，应用软件的软件程序以及模块，如本发明实施例中的容器CPU资源调度与隔离方法对应的计算机程序，处理器102通过运行存储在存储器104内的计算机程序，从而执行各种功能应用以及数据处理，即实现上述的方法。存储器104可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器104可进一步包括相对于处理器102远程设置的存储器，这些远程存储器可以通过网络连接至移动终端。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

传输装置106用于经由一个网络接收或者发送数据。上述的网络具体实例可包括移动终端的通信供应商提供的无线网络。在一个实例中，传输装置106包括一个网络适配器(Network Interface Controller，简称为NIC)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输装置106可以为射频(Radio Frequency，简称为RF)模块，其用于通过无线方式与互联网进行通讯。

图2是根据本发明实施例的容器CPU资源调度与隔离方法的流程图，如图2所示，该流程包括如下步骤：

S202，容器编排引擎规划并创建资源池，并令各节点将自身CPU资源按资源池进行划分；；

S204，容器编排引擎获取容器创建信息；其中，所述容器创建信息包含期望进入的资源池标签；

S206，容器编排引擎根据所述资源池标签以及各节点对应的资源池的状态，确定出目标节点；

S208，容器编排引擎发送容器创建指令至所述目标节点的执行代理模块，以使所述执行代理模块创建容器并将所述容器与所述资源池对应的CPU核进行绑定。

在申请实施例中，容器编排引擎可以包括Kubernetes平台，这里的容器可以为Kubernetes所能管理的最小业务抽象单元pod，一个pod可以包含一个或多个容器。资源池标签可以为将多个CPU进行划分得到的不同的资源池的名称，资源需求量可以为所占用CPU的时长，在此不做任何限定。

通过本发明实施例，采用了调度器从容器编排引擎获取容器的创建指令；其中，上述创建指令携带上述容器期望进入的资源池标签以及资源需求量；根据当前各节点对应的资源池的状态信息，选择与上述资源池标签和资源需求量匹配的目标节点；在上述目标节点上创建上述容器的方式；由于根据当前各节点对应的资源池的状态信息，选择与上述资源池标签和资源需求量匹配的目标节点，可以精确控制容器绑定的CPU资源以及允许以资源池为单位进行评估调度，而且能够更灵活与精确的对CPU资源管控与隔离的技术效果。

在一个或多个实施例中，上述步骤S202，上述容器编排引擎规划并创建资源池，并令各节点将自身CPU资源按照资源池进行划分之前，包括：

将上述各节点对应的CPU资源进行分配得到分配结果；其中，上述分配结果用于为上述容器编排引擎所属的节点创建资源池；

获取节点配置文件，其中，上述节点配置文件中记录有节点资源池配置信息；

获取注册节点的列表，存储并初始化上述注册节点的资源池使用状态信息；

当上述调度器获取到当前所有节点的配置信息后，向各节点对应的执行代理模块发送资源池初始化指令；其中，上述资源池初始化指令用于使上述执行代理模块将节点上的CPU核划分为若干标签CPU组，并将上述标签CPU组匹配不同的资源池。

在一个或多个实施例中，步骤S206，容器编排引擎根据所述资源池标签以及各节点对应的资源池的状态，确定出目标节点，包括：

所述容器编排引擎根据当前各节点对应的资源池的状态信息，选择与所述资源池标签和资源需求量匹配的目标节点。

在一个或多个实施例中，容器编排引擎根据当前各节点对应的资源池的状态信息，选择与上述资源池标签和资源需求量匹配的目标节点，包括：

根据当前各节点对应的资源池的状态信息从上述当前各节点中筛选候选目标节点；其中，每个上述节点包括CPU资源和内存资源，上述资源池包含不同标签CPU组的资源量；

在筛选出候选目标节点的情况下，上述调度器从上述候选目标节点中确定出满足非CPU资源的调度的目标节点，并在上述目标节点上创建容器并将上述容器与上述资源池对应的CPU核进行绑定。

在一个或多个实施例中，上述方法还包括：调度器从容器编排引擎中获取新增节点的请求消息，其中，上述请求消息中携带上述新增节点对应的执行代理模块的访问接口信息；

上述调度器向上述新增节点的执行代理模块发送资源池初始化指令，其中，上述初始化指令包含需要创建的一个或多个资源池的参数，上述资源池参数包括资源池标签和CPU组；

上述调度器收到上述新增节点的执行代理模块发送的资源池创建成功消息时，上述调度器在数据库中存储上述新增节点的资源池状态信息。

在一个或多个实例中，上述容器CPU资源调度与隔离方法还包括：在未筛选出候选目标节点的情况下，上述调度器将上述创建指令对应的创建任务挂起或终止。

在一个或多个实例中，上述调度器从上述候选目标节点中确定出满足非CPU资源的调度的目标节点之后，上述容器CPU资源调度与隔离方法还包括：上述调度器扣减接入的目标节点对应的容器所耗费的资源，并更新接入节点对应资源池的资源状态。

图3是根据本发明实施例的容器CPU资源调度与隔离方法的流程图，如图3所示，该流程包括如下步骤：

S302，当前节点上的执行代理模块从调度器接收容器的创建指令，其中，上述容器创建指令携带需要创建容器配置数据以及待绑定的资源池的配置信息，上述配置信息包含资源池标签；

S304，上述执行代理模块根据上述容器创建指令，调用业务执行的节点上的容器运行时接口CRI创建容器并根据上述资源池标签确定出对应的CPU核索引；

S306，将上述资源池标签和对应的CPU核索引发送至上述CRI,以使上述CRI将上述容器与上述资源池对应的CPU核进行绑定；

S308，执行代理模块发送容器创建结果信息至上述调度器。

通过本发明实施例，采用了当前节点上的执行代理模块接收容器编排引擎发送的容器创建指令，其中，上述容器创建指令携带需要创建容器的配置数据以及待绑定的资源池的配置信息，上述配置信息包含资源池标签；上述执行代理模块根据上述容器创建指令，调用业务执行的节点上的容器运行时接口CRI创建容器并根据上述资源池标签确定出对应的CPU核索引；将上述资源池标签和对应的CPU核索引发送至上述CRI,以使上述CRI将上述容器与上述资源池对应的CPU核进行绑定；执行代理模块发送容器创建结果信息至上述容器编排引擎的调度器；由于根据当前各节点对应的资源池的状态信息，选择与上述资源池标签和资源需求量匹配的目标节点，可以精准的对CPU资源绑定与隔离，精确控制容器绑定的CPU资源以及允许以资源池为单位进行评估调度，而且能够更灵活与精确的对CPU资源管控与隔离的技术效果。

在一个或多个实施例中，上述当前节点上的执行代理模块从接收容器调度器编排引擎发送的容器创建指令之前，还包括:

在上述代理节点接入上述容器编排引擎后，接收上述容器编排引擎的调度器发送的资源池初始化指令；

根据上述初始化指令将上述节点上的CPU核划分为若干标签CPU组，并将标签CPU组匹配不同的资源池；

执行代理模块发送资源池初始化结果信息至上述调度器。

在一个或多个实施例中，上述根据上述初始化指令将上述代理节点上的CPU资源划分为若干组包括：利用Linux内核的cgroup子系统，根据上述资源池的配置要求建多个CPU组，其中，每个CPU组中包括预设的CPU核。

Kubernetes是目前业界最主流、应用最广泛的的开源容器计算平台，其允许用户简单高效地在一批通用基础设施节点上部署容器应用，并提供了一套应用部署、规划、更新、维护的全生命周期管理机制，以满足不同的实际需求。

Pod是Kubernetes所能管理的最小业务抽象单元，一个pod内可以包含一个或多个容器。用户会根据实际需求编写业务编排蓝图，其中会要求创建一个或多个业务Pod。蓝图提交给Kubernetes后，Kubernetes内置的原生调度器会评估其所管辖的所有节点，综合各个节点的可用资源、Pod的资源需求以及其他一些因素，最终决定要将Pod建立在哪一个节点上。Kubernetes的调度器通过持续不断的监控各个节点以及所有Pod的运行状况，来保证所有节点的资源能充分地被利用，同时不会出现部分节点负荷过载、或是部分Pod无法获得其所需资源的现象。

如图4所示，调度器需要持续监控各个节点上当前的可用资源；调度器需要尽可能保证所有节点承载的工作负荷基本均衡；创建新Pod时，调度器需要根据Pod的资源需求并结合各节点的可用资源与工作负荷,决定Pod在哪一个节点上创建。

对于每一个节点，其可用资源有若干种类型，但一般评估的主要对象是CPU与内存：

CPU一般以CPU时间/秒作为衡量单位，比如一个8核节点，在1秒的时间范围内总共可用的CPU资源就是8(如果以毫秒作为计量单位就是8000)；而内存则是直接以大小作为衡量单位，比如一个节点上有16G内存，那么总共的最大可用内存就是16G。

Pod在建立时会消耗一部分CPU和内存资源(在蓝图中可以声明)，这些消耗的资源会从节点总资源量中扣除。如果一个节点的当前可用资源已经无法满足一个Pod的需求，Kubernetes调度器将不会让Pod建立在这个节点上，而是会另寻其他资源充足的节点。如果当前所有节点的可用资源都不满足条件，该Pod的建立过程会被挂起，调度器会持续监控所有节点的资源状况，等待某个节点资源可用时再执行Pod的建立。

对于节点上的某类资源，Kubernetes是将其作为一个整体来看待的。特别是对于CPU，虽然一个节点上可能存在多个CPU核，但调度器在工作时是将其作为一个CPU时间资源池来进行调度的，并不会区分资源具体归属于哪一个核。

对于一个运行了了多个Pod的节点，其在某个时刻内、特定的CPU核上承载了哪个Pod的进程是不确定的。举例来说，对于0号核，在时刻1可能运行的是Pod A的进程，在时刻2运行的可能是Pod B的进程，其他核也都是类似的情况。如图5所示：上述Pod进程在不同的CPU核之间调度并不是由Kubernetes实现的，而是由节点操作系统的内核调度器实现的。操作系统的内核调度器要完成的任务是将节点上运行的所有进程均衡地分配给所有的CPU核，以尽可能充分利用所有的CPU资源。从这个角度来看，内核调度器与Kubernetes的调度器是非常类似的，只是它们调度的对象层次不同：Kubernetes调度器是负责将Pod调度到合适的节点上，尽可能使所有节点的负荷保持均衡；而内核调度器是负责在某个特定节点上将所有的Pod进程合理地分配到所有的CPU核上，尽可能使所有的CPU核在所有时刻都被充分利用并保持负荷均衡。

一个节点不仅仅只会运行Pod，操作系统核心进程与Kubernetes的管理进程也会消耗一定的资源。如果调度器在计算节点资源时没有预留一部分给系统进程和Kubernetes管理进程，就可能导致Pod进程会抢占这些关键进程的资源，导致节点工作异常。为此，Kubernetes专门提供了系统资源预留参数，允许系统管理员预留一部分资源给系统进程与管理进程，Kubernetes会将这部分资源从调度器的可见范围内排除掉，从而确保Pod不会占用这部分资源。以CPU资源为例，如图6所示，节点上的CPU资源被划分成三块，其中为Pod所预留的资源被称为可分配池，可分配池内不包含为系统或Kubernetes自身管理进程所预留的资源，因此在该节点上运行的POD决不会占用预留的CPU资源。

在实际的场景中，可能会存在某些关键核心业务(比如电信业务或视频实时处理业务)，它们对处理时间和响应时延的稳定性要求极高，一次线程抢占导致的上下文切换就会对其性能产生明显的影响。因此这类业务往往有独占CPU核的需求，其甚至会明确指定要独占特定编号的CPU核，不允许其他任何进程使用这些核。

现实中还存在另一种常见的需求：即用户希望不同类型的POD在资源使用和分配上存在一定程度的隔离保护。举例来说，如果一个节点上同时存在3个A类POD和3个B类POD，那么当A类POD中的一个出现异常(比如死循环)导致占用了过多的CPU资源时，只有A类POD会受到影响，B类POD不会受到任何影响。

很显然，原生Kubernetes是无法满足上述两个隔离需求的，Kubernetes将每个节点上的资源作为一个整体来看待。在排除掉为系统预留的资源之后，节点上的所有剩余资源都被Kubernetes纳入一个单独的可调度资源池，调度器在为POD选择节点时，是以这个可调度资源池的总空余量来评估的；而当POD在节点上运行时，整个可调度池的资源都是可以被使用的，无法进行精确的绑核或隔离控制。

为了解决上述问题，在一应用实施例中，提供了一种容器CPU资源调度与隔离方法，在上述方法中适用环境要求如下：使用Kubernetes对容器应用进行管理的环境；如图7所示，本申请还提供了一种容器CPU资源调度与隔离装置，包括：模块A:接口服务器(APIServer)，模块B:数据库，模块C:容器运行时；模块D:增强调度器，模块D:执行代理模块(kubelet)；其中：

模块A负责提供用户交互界面以及功能接口。用户可以通过该模块提供的界面或接口来对Kubernetes集群进行管理与配置，同时建立并管理各类业务Pod和相关对象。

模块B统一负责Kubernetes系统内部管理与状态数据的存取和持久化工作。其会存储从模块A输入的用户配置数据，并向模块A返回用户查询的数据集；其也会存储从模块D返回的节点状态与资源状况信息，并响应后续模块D发出的数据查询请求。

模块C运行在节点上，负责接受模块E发出的请求，在节点上创建、删除或配置容器与镜像，并响应容器状态查询请求。

模块D负责维护所有节点的资源状态信息、所有Pod的调度判决、向模块E发送执行指令等工作。

模块E运行在节点上，负责接受并响应模块D发出的指令，初始化节点上的各个资源池，与模块C交互、对容器进行生命周期管理和CPU绑核。

在本申请实施例中，调度器的关键功能是对所有节点的多个CPU资源池进行统一评估调度，并根据POD的需求为其选择合适的节点；而执行代理模块运行在节点上，负责根据调度器的指令创建资源池和POD，并在容器创建时将两者绑定。

在一个可选的实施例中，如图8所示，上述容器CPU资源调度与隔离方法包括：S802：读取配置，获取节点资源池配置信息，具体地，环境在部署前，用户应预先规划好特定规格节点上资源池的配置，并将配置信息记录在对应的配置文件中。增强调度器启动时会读取配置文件，从而知晓期望中的节点资源池配置信息。

S804：获取节点列表，初始化节点资源状态，具体地，增强调度器从Kubernetes内置的数据库中获取注册的节点列表，并在数据库中记录并初始化这些节点的资源池使用状态信息。在系统刚启动时，节点列表可能为空，但新增节点的纳管动作会触发调度器的节点新增流程，从而完成初始化动作。

S806：向节点发送资源初始化指令，具体地，当调度器已获知当前被纳管的所有节点信息后，其向各节点的执行代理程序发送资源池初始化指令。执行代理应根据指令，将节点上的CPU核划分为若干组，纳入不同的资源池，以备后续创建POD时使用。

在一个可选的实施例中，如图9所示，上述容器CPU资源调度与隔离方法包括：

S902：收到新增节点，具体地，增强调度器从Kubernetes其他管理服务中获取新节点被纳管的消息，得到新节点的执行代理程序的访问接口信息。

S904：向节点发送资源池初始化指令，具体地，增强调度器向新节点的执行代理程序发送资源池初始化指令，其中包含需要创建的一个或多个资源池详情(资源池标签和包含的CPU核索引等等)。

S906：判断资源池初始化是否成功，具体地：如果执行代理程序回复资源池创建成功，则继续执行步骤S908；如果失败,则进入步骤S910，则重新发送创建指令并继续等待。

S908：更新节点状态信息,增强调度器在数据库中记录该新节点的资源池状态信息。

在一个可选的实施例中，如图10所示，上述容器CPU资源调度与隔离方法包括：

S1002：增强调度器从Kubernetes其他管理服务中获取CPU资源调度消息。

S1004：增强调度器从CPU资源调度消息中获取CPU资源调度的具体参数，其中包含Pod希望进入的资源池标签以及资源需求量(如果没有配置这些参数则取默认值)。

S1006：增强调度器评估所有节点对应资源池的资源状况，根据Pod希望进入的资源池标签以及资源需求量，结合数据库中维护的当前各节点对应资源池的状态信息，筛选接入节点。

S1008：如果能够选出目标节点，转入步骤S1010；如果无法选出任何节点，则直接中止流程，转入步骤S1018；该Pod的创建会被挂起。

S1010：评估其他限制项；

S1012:如果能够选出一批可选节点，增强调度器将在这批节点的基础上执行Kubernetes原生调度器的调度逻辑再次进行过滤，这一步骤主要为了完成其他非CPU资源(如内存、端口等)的调度筛选。如果筛无法选出任何节点，转入步骤S1018，则直接中止流程，该Pod的创建会被挂起。

S1014：向选择节点发送创建pod指令；能够得到一个最终的接入候选节点。增强调度器向该节点的执行代理程序发送指令，其中包含待创建Pod的详细信息，让执行代理程序在节点上创建Pod并进行资源池绑定。

S1016，更新节点资源池状态信息。增强调度器需要更新数据库中接入节点对应资源池的资源状态，从中扣减掉接入Pod所耗费的资源。

步骤S1018，中止流程，该Pod的创建会被挂起。

在一个可选的实施例中，如图11所示，上述容器CPU资源调度与隔离方法包括：

S1102：执行代理程序读取初始配置启动，向Kubernetes控制节点注册所在节点，该步骤与Kubernetes原生执行代理程序(Kubelet)行为相同。

S1104执行代理所在节点被Kubernetes纳管后，增强调度器会发来资源池初始化指令。

S1106：执行代理需要根据指令将节点上的CPU资源划分为若干组，归属于不同的资源池对象。有多种方法可以将CPU分组，最常见的方法是利用Linux内核的cgroup子系统，根据资源池的配置要求，建立多个cpuset，每个cpuset中包含指定的CPU核。

S1108：无论资源池初始化成功还是失败，执行代理程序都应向增强调度器汇报，并结束整个流程。

在一个可选的实施例中，如图12所示，上述容器CPU资源调度与隔离方法包括：

S1202：某个节点上的执行代理程序从增强调度器收到创建Pod指令，其中包含需要创建容器配置数据，以及希望绑定的资源池等信息。

S1204：读取创建Pod指令包含需要创建容器配置数据，以及希望绑定的资源池等信息。

S1206：执行代理根据创建指令，调用节点上的容器运行时接口(ContainerRuntime Interface，简称CRI)创建容器。在创建时，其会根据资源池标签查到对应的cpuset索引，并将容器进程绑定到对应的cpuset上。

S1208：无论容器创建成功还是失败，执行代理程序都应向增强调度器反馈创建结果，并结束整个流程。

基于上述实施例，在一应用实施例中，假定存在一个Kubernetes环境，其有3个节点，所有节点都有8个CPU核。在原生Kubernetes的资源管理机制下，系统任意节点的一种可能的初始资源划分状况如图13所示：

在图13中，该环境为操作系统进程预留了1.5个核，为Kubernetes自身管理进程预留了2个核，为Pod预留了4.5个核；原生的资源分配机制只支持一个Pod预留组(可分配池)；原生的资源预留机制是通过可用的CPU时间来进行划分的(如预留1.5个核的含义是在100ms内可以使用150ms的CPU时间)，因此不同预留组内的进程是有可能被分配到相同的CPU核上进行调度的(这就可能会导致资源争抢)；某一时刻下，不同预留组内的进程运行在哪一个CPU核上是不确定的。图13中显示的位置仅为一种示例，在此不做任何限定。

在一个实施例的执行环境中，如图14所示，该环境为操作系统进程预留了1个核，为Kubernetes自身管理进程预留了2个核，为Pod组A预留了2个核，为Pod组B预留了3个核。增强的资源分配机制支持多个Pod预留组(多个可分配池)。增强方案是通过创建多个cpuset来将CPU核精确地与预留组绑定，用户可以任意指定CPU核与预留组之间的映射关系。从图14中可以看到，Pod预留B组与CPU 3、4、5绑定，所有纳入Pod预留B组的Pod进程就只会运行在CPU 3、4、5上。其它预留组的情况与之相同。在本实施例中，不同预留组内的进程运行在哪一个CPU核(或是哪一个范围内)在任意时刻下都是确定的。

在一实施例中，假定当前容器CPU资源调度与隔离系统已运行了一段时间，各节点的资源状况如图15所示，此时，用户需要创建一个新的Pod，增强调度器会读取Pod蓝图中的资源组和其他资源需求相关参数，结合各个节点当前的资源状况进行判决，选择一个最合适的节点来创建Pod。

在一实施例中，Pod指明希望归属预留组A，对CPU资源的最小需求是120ms。在这种情况下，增强调度器遍历所有的节点，发现只有节点0的资源状况能够满足要求；在其他资源判决都通过后，调度器向节点0的执行代理发送创建Pod命令，同时将节点0的Pod预留A组资源扣减120ms(剩余60ms)。

在一实施例中，Pod指明希望归属预留组B，对CPU资源的最小需求是60ms。在这种情况下，增强调度器遍历所有的节点，发现节点1、2的资源状况都能够满足要求，但节点1的资源比节点2的更为宽松(240>100)，因此优选结果为节点1；在其他资源判决都通过后，调度器向节点1的执行代理发送创建Pod命令，同时将节点1的Pod预留B组资源扣减60ms(剩余180ms)。

在一实施例中，Pod指明希望归属预留组A，对CPU资源的最小需求是200ms。在这种情况下，增强调度器遍历所有的节点，发现没有任何节点能够满足要求，于是直接结束判决，挂起Pod的创建流程。

在一实施例中，某个归属于预留组A的Pod成功地在节点0上创建后运行出现了异常，导致其耗尽了CPU 0和CPU 1上的所有时间(这些CPU核属于预留组A)，此时归属于预留组B的Pod不受其影响，操作系统进程和Kubernetes管理进程也不受其影响，归属于预留组B的Pod创建调度过程仍然可以正常进行。

在pod的创建阶段，执行代理会调用节点上的容器运行时接口来创建容器。当前业界主流的容器运行时均支持在创建容器时指定cpuset，因此执行代理只需将增强调度器提供的cpu参数传递给容器运行时接口即可实现容器与指定cpu核的绑定。

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

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

图16是根据本发明实施例的容器CPU资源调度与隔离装置的结构框图，如图16所示，该装置包括：

第一创建单元1602，用于创建资源池，并令各节点将自身的CPU资源按资源池进行划分；

获取单元1604，用于获取容器创建信息；其中，所述容器创建信息包含期望进入的资源池标签；

确定单元1606，用于根据所述资源池标签以及各节点对应的资源池的状态，确定出目标节点；

发送单元1608，用于容器编排引擎发送容器创建指令至所述目标节点的执行代理模块，以使所述执行代理模块创建容器并将所述容器与所述资源池对应的CPU核进行绑定。

在本发明实施例中，容器编排引擎可以包括Kubernetes平台，这里的容器可以为Kubernetes所能管理的最小业务抽象单元pod，一个pod可以包含一个或多个容器。资源池标签可以为将多个CPU进行划分得到的不同的资源池的名称，资源需求量可以为所占CPU的容量大小和占用CPU的时长，在此不做任何限定。

通过本发明实施例，采用了调度器从容器编排引擎获取容器的创建指令；其中，上述创建指令携带上述容器期望进入的资源池标签以及资源需求量；根据当前各节点对应的资源池的状态信息，选择与上述资源池标签和资源需求量匹配的目标节点；在上述目标节点上创建上述容器的方式；由于根据当前各节点对应的资源池的状态信息，选择与上述资源池标签和资源需求量匹配的目标节点，可以精准的对CPU资源绑定与隔离，进而达到精确控制容器绑定的CPU资源以及允许以资源池为单位进行评估调度，而且能够更灵活与精确的对CPU资源管控与隔离的技术效果。

图17是根据本发明实施例的容器CPU资源调度与隔离装置的结构框图，如图17所示，该装置包括：

接收单元1702，用于接收容器编排引擎发送的容器创建指令，其中，上述容器创建指令携带需要创建容器配置数据以及待绑定的资源池的配置信息，上述配置信息包含资源池标签；

第二创建单元1704，用于根据所述容器创建指令，调用业务执行的节点上的容器运行时接口CRI创建容器并根据所述资源池标签确定出对应的CPU核索引；

第一发送单元1706，用于将所述资源池标签和对应的CPU核索引发送至所述CRI,以使多少CRI将所述容器与所述资源池对应的CPU核进行绑定；

第二发送单元1708，用于发送任务创建结果信息至所述容器编排引擎的调度器。

通过本发明实施例，采用了当前节点上的执行代理模块从调度器接收容器的创建指令，其中，上述创建指令携带需要创建容器配置数据以及待绑定的资源池信息，上述资源此信息包含资源池标签；上述执行代理模块根据上述创建指令，调用业务执行的节点上的容器运行时接口CRI创建容器；其中，上述CRI根据资源池标签确定出上述节点对应的CPU设置索引，并将上述容器进程绑定到对应的CPU设置索引；执行代理模块发送任务创建结果信息至上述调度器；由于根据当前各节点对应的资源池的状态信息，选择与上述资源池标签和资源需求量匹配的目标节点，可以精准的对CPU资源绑定与隔离，进而达到了提高CPU资源利用率的效果。

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

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

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

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

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

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

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

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