基于异构硬件的统一资源池化容器调度引擎及其调度方法

技术领域

本发明涉及容器调度领域，具体涉及一种基于异构硬件的统一资源池化容器调度引擎及其调度方法。

背景技术

在容器技术快速发展的今天，云计算领域的基础技术已跨入了新的发展方向，各大主流厂商都在储备云原生相关的技术。而容器调度引擎是其中最核心的一项技术，目前市面上主流的容器调度引擎为美国谷歌公司的Kubernetes。开发或运维人员可以通过Kubernetes来部署、管理、运维容器实例，通过调度引擎平台，极大简化了运维工作复杂度，不需要再像传统虚拟化运维一样进入到具体业务进程中，才能操作运维操作。

在kubernetes中一般资源分为cpu(处理器)、memory(内存)、和其他自定义资源，资源分布在不同的节点上，由kubernetes这个调度引擎统一管理即分配和释放资源，但是如果集群中的设备存在多种不兼容的架构例如amd64和arm64，会导致集群部署十分的困难，而且在使用过程中会造成调度的pod因为镜像的问题不能使用，产生错误，而且arm64架构的机器一般性能较弱，应用的执行会比较缓慢，所以在kubernetes中，一般不同的架构分成了不同的集群用来处理完全不相关的业务，这也造成了多集群的管理困难，以及一些相关联的业务不能很好的结合，即使在集群中使用标签的方式区分开不同的机器，也会使得启动实用的时候执行额外的操作，这都是运维和开发人员所棘手的事情。

发明内容

本发明的目的是提供一种基于异构硬件的统一资源池化容器调度引擎及其调度方法，能够解决异构环境下的容器调度问题，并能屏蔽掉架构的差异，让用户得到极佳的体验。

本发明解决其技术问题，采用的技术方案是：

本发明首先提出一种基于异构硬件的统一资源池化容器调度引擎，包括核心组件、对外提供访问的客户端组件和外部依赖部分；

所述核心组件，包括核心服务器、资源控制器和节点客户端，所述核心服务器，用于对外提供操作所有数据的api以及对接数据库，所述资源控制器，用于监听所有数据的变化以及用于进行相关的资源操作，所述资源调度器，用于控制集群中的资源使用及用于分配容器到各个节点及节点客户端；

所述客户端组件，包括CLI命令行客户端，用于使用命令行的方式操作集群和Web客户端；

所述外部依赖部分，包括一致性组件、授权认证服务组件、容器网络实现组件、容器运行实现+镜像分发服务组件和容器存储实现组件。

作为优选，所述节点包括节点信息，所述节点信息包括处理器、内存和磁盘信息。

另外，本发明还提出一种基于异构硬件的统一资源池化容器调度引擎的调度方法，包括如下步骤：

步骤1、容器调度引擎收到创建应用的请求，生成对应应用的应用副本控制器；

步骤2、应用副本控制器查询当前应用在集群中的状态，并使该状态与应用声明的状态符合；

步骤3、资源调度器对比应用的副本的资源要求及节点的架构要求，并对所有节点进行评分；

步骤4、资源调度器根据最高的评分将应用的副本分配到与该最高的评分对应的节点上；

步骤5、节点客户端收到应用的副本被调度的信息，若应用的副本被调度到该节点客户端的节点上，则创建应用的副本的需求，并启动容器；

步骤6、节点客户端监听到容器的状态，当容器被删除时则创建出对应的容器，当容器的状态不健康时则更新集群中该应用的副本的资源状态。

作为优选，步骤1之前，还包括：容器调度引擎监控节点，当有节点加入新的集群时，记录节点的信息，并且实时监控节点资源的使用情况，所述节点信息包括处理器、内存和磁盘信息。

具体的是，步骤2中，若当前应用在集群中的状态与应用声明的状态不符合，则应用副本控制器通过创建应用的副本或者删除应用的副本，使该状态与应用声明的状态符合。

具体的是，步骤3中，当对所有节点进行评分时，根据节点的空余资源大小对节点进行评分，当节点的空余资源越多时，该节点的评分越高。

具体的是，步骤5中，所述应用的副本的需求包括存储卷的挂载、网络的创建以及容器的资源限制。

具体的是，步骤6中，当应用的副本配有健康检查时，如果健康检查不通过，则尝试重新启动容器。

本发明的有益效果是，通过上述基于异构硬件的统一资源池化容器调度引擎及其调度方法，用户在使用本发明提供的产品时，可以使用产品提供的安装工具轻松的实现集群创建修改，支持不同架构同时安装，在集群的创建修改方面体验有了极大的提升，并且，本发明能够解决异构环境下的容器调度问题，并能屏蔽掉架构的差异，让用户得到极佳的体验。

附图说明

图1为本发明实施例1提供的基于异构硬件的统一资源池化容器调度引擎的整体架构图；

图2为本发明实施例2提供的基于异构硬件的统一资源池化容器调度引擎的调度方法的流程图。

具体实施方式

下面结合附图及实施例，详细描述本发明的技术方案。

实施例1

本实施例提供一种基于异构硬件的统一资源池化容器调度引擎，其整体结构图见图1，其中，该容器调度引擎包括核心组件、对外提供访问的客户端组件和外部依赖部分；其中：核心组件，包括核心服务器、资源控制器和节点客户端，核心服务器，用于对外提供操作所有数据的api以及对接数据库，资源控制器，用于监听所有数据的变化以及用于进行相关的资源操作，资源调度器，用于控制集群中的资源使用及用于分配容器到各个节点及节点客户端；客户端组件，包括CLI命令行客户端，用于使用命令行的方式操作集群和Web客户端；外部依赖部分，包括一致性组件、授权认证服务组件、容器网络实现组件、容器运行实现+镜像分发服务组件和容器存储实现组件。这里，节点会包括节点信息，节点信息可以包括处理器、内存和磁盘信息等。

本实施例中，容器调度引擎会统一管理集群中的所有资源，当应用创建的时候由容器调度引擎决定应用的创建在哪一个节点上，并且由容器调度引擎维护这个应用的状态，当应用不正常时容器调度引擎会尝试修复这个应用；当用户启动应用的时候，在页面或者配置文件中填入参数，具体的调度交由容器调度引擎处理，容器调度引擎会获取镜像的信息，判断它适合在哪些节点上运行，对于有多种架构的镜像，即可在多种节点上运行，用户不需要关心怎么去控制容器的创建和销毁。

实施例2

本实施例提供一种基于异构硬件的统一资源池化容器调度引擎的调度方法，其流程图见图2，其中，该方法包括如下步骤：

步骤1、容器调度引擎收到创建应用的请求，生成对应应用的应用副本控制器。

步骤2、应用副本控制器查询当前应用在集群中的状态，并使该状态与应用声明的状态符合；

其中，若当前应用在集群中的状态与应用声明的状态不符合，则应用副本控制器通过创建应用的副本或者删除应用的副本，使该状态与应用声明的状态符合，以期望来获得正确的状态。

步骤3、资源调度器对比应用的副本的资源要求及节点的架构要求，并对所有节点进行评分；

当对所有节点进行评分时，根据节点的空余资源大小对节点进行评分，一般来说，当节点的空余资源越多时，该节点的评分越高。

步骤4、资源调度器根据最高的评分将应用的副本分配到与该最高的评分对应的节点上，这个节点肯定是满足应用的需求的，在资源和机器架构上都能保证机器的正常运行。

步骤5、节点客户端收到应用的副本被调度的信息，若应用的副本被调度到该节点客户端的节点上，则创建应用的副本的需求，并启动容器；

其中，应用的副本的需求包括存储卷的挂载、网络的创建以及容器的资源限制。

步骤6、节点客户端监听到容器的状态，当容器被删除时则创建出对应的容器，当容器的状态不健康时则更新集群中该应用的副本的资源状态；

这里，当应用的副本配有健康检查时，如果健康检查不通过，则尝试重新启动容器。

实际应用中，步骤1之前，还可以包括：容器调度引擎监控节点，当有节点加入新的集群时，记录节点的信息，并且实时监控节点资源的使用情况，其中，节点信息可以包括处理器、内存和磁盘信息等。

实施例3

本实施例中，调度只有amd64架构的镜像应用，其调度过程具体如下：

a、创建一个有3台amd64和3台arm64机器的集群，打开容器调度引擎的web界面，选择创建应用。

b、填入应用的参数，其中的镜像选择只有adm64架构的镜像，副本数量设置为10。

c、查看应用的详情，等待一段时间，查看应用是否为running状态，如果不是排查问题，如果为running，查看副本在集群中的分布情况。

d、可以看到所有的副本基本均匀的分布在amd64架构的机器上，并且全部正常运行。

e、再启动一个应用，把请求的资源调大，让一些副本的资源请求满足集群中剩余的amd64架构的资源部分不能满足要求。

f、查看新应用的副本运行情况，一些副本成功启动，一些副本因为资源不满足未启动，但是未启动的副本也未调度到arm64结构的机器上。

实施例4

本实施例中，调度具有arm64和amd64架构的镜像应用，其调度过程具体如下：

(1)创建一个有3台amd64和3台arm64机器的集群，打开容器调度引擎的web界面，选择创建应用。

(2)填入应用的参数，镜像选择为具有amd64和arm64两种架构的镜像，并且副本数为10。

(3)等待一段时间，查看应用的详情，可以看到在集群中的机器都运行这这个镜像，但是amd64节点上的副本数多于arm6节点上的副本数，这是因为arm64计算力较低，集群调度时剩余的资源评分较低，所以分配的副本数量也较少。