一种资源调度方法、装置、设备及介质与流程

1.本发明涉及资源调度技术领域，尤其涉及一种资源调度方法、装置、设备及介质。


背景技术：

2.kubernetes系统是google开源的一款容器编排工具，用于管理云平台中多个主机上的容器化应用。其提供了对硬件资源，如cpu、内存和gpu的池化能力，提供了面向应用的容器编排、部署。目前，kubernetes已经成为了容器云平台的事实标准。hadoop系统是一个由apache基金会开源的分布式系统基础架构，其实现了一个分布式文件系统，其中hdfs提供了海量数据的存储能力，mapreduce/yarn提供了海量数据的计算能力，在设计之初hadoop部署在物理机上，对物理机上的资源进行统一调度。目前，hadoop是业界各公司大数据业务的必备基础设施，为个性化推荐、搜索推荐、数据分析等业务提供支持。
3.由于业务特性的不同，kubernetes和hadoop两者的运行压力是错峰的，比如在凌晨kubernetes系统处于空闲时，hadoop则需要对前一日的数据进行分析、汇聚，生成各业务系统所需的基础数据。这样hadoop系统运行压力很大，但是kubernetes系统并未充分利用。hadoop系统运行压力小时，也会出现hadoop系统资源利用率低的问题。因此，现有技术存在hadoop系统资源闲时浪费，忙时不足的问题。


技术实现要素：

4.本发明实施例提供了一种资源调度方法、装置、设备及介质，用以解决现有技术存在hadoop系统资源闲时浪费，忙时不足的问题。
5.本发明实施例提供了一种 资源调度方法，所述方法包括：在kubernetes系统中部署hadoop系统的各个应用，获取所述各个应用的资源占用率数据；当根据所述各个应用的资源占用率数据确定满足触发资源调度条件，且当前不处于预设的冷却期内时，根据预先设定的资源调度策略进行资源调度，并重新进入冷却期。
6.进一步地，所述在kubernetes系统中部署hadoop系统的各个应用包括：获取所述hadoop系统的各个应用的部署配置文件，根据所述各个应用的部署配置文件确定所述各个应用的镜像文件版本信息和副本数；根据所述各个应用的镜像文件版本信息从镜像仓库获取对应的镜像文件，根据所述各个应用的副本数和镜像文件，在所述kubernetes系统中部署所述各个应用。
7.进一步地，所述获取所述各个应用的资源占用率数据；根据所述各个应用的资源占用率数据确定满足触发资源调度条件包括：获取所述各个应用的存储资源占用率数据，根据所述各个应用的存储资源占用率数据确定平均存储资源占用率数据，当所述平均存储资源占用率数据大于预设的第一占用率阈值，或所述平均存储资源占用率数据小于预设的第二占用率阈值，确定触发资源调度条件。
8.进一步地，所述获取所述各个应用的资源占用率数据；根据所述各个应用的资源占用率数据确定满足触发资源调度条件包括：获取所述各个应用的计算资源占用率数据，根据所述各个应用的计算资源占用率数据确定平均计算资源占用率数据，当所述平均计算资源占用率数据大于预设的第三占用率阈值，或所述平均计算资源占用率数据小于预设的第四占用率阈值，确定触发资源调度条件。
9.进一步地，所述根据预先设定的资源调度策略进行资源调度包括：当所述平均存储资源占用率数据大于预设的第一占用率阈值，增加所述hadoop系统资源的副本实例；当所述平均存储资源占用率数据小于预设的第二占用率阈值，减少所述hadoop系统资源的副本实例。
10.进一步地，所述当所述平均存储资源占用率数据小于预设的第二占用率阈值，减少所述hadoop系统资源的副本实例包括：当所述平均存储资源占用率数据小于预设的第二占用率阈值，确定当前hdfs中不存在副本数不足的文件时，删除副本id最大的datanode副本实例。
11.进一步地，所述根据预先设定的资源调度策略进行资源调度包括：当所述平均计算资源占用率数据大于预设的第三占用率阈值，增加所述hadoop系统资源的副本实例；当所述平均计算资源占用率数据小于预设的第四占用率阈值，减少所述hadoop系统资源的副本实例。
12.进一步地，所述当所述平均计算资源占用率数据小于预设的第四占用率阈值，减少所述hadoop系统资源的副本实例包括：当所述平均计算资源占用率数据小于预设的第四占用率阈值，确定副本id最大的nodemanager没有执行任务时，删除副本id最大的nodemanager副本实例，如果所述副本id最大的nodemanager正在执行任务，等到所述副本id最大的nodemanager执行任务完成，删除所述副本id最大的nodemanager副本实例。
13.另一方面，本发明实施例提供了一种资源调度装置，所述装置包括：部署模块，用于在kubernetes系统中部署hadoop系统的各个应用，获取所述各个应用的资源占用率数据；调度模块，用于当根据所述各个应用的资源占用率数据确定满足触发资源调度条件，且当前不处于预设的冷却期内时，根据预先设定的资源调度策略进行资源调度，并重新进入冷却期。
14.进一步地，所述部署模块，具体用于获取所述hadoop系统的各个应用的部署配置文件，根据所述各个应用的部署配置文件确定所述各个应用的镜像文件版本信息和副本数；根据所述各个应用的镜像文件版本信息从镜像仓库获取对应的镜像文件，根据所述各个应用的副本数和镜像文件，在所述kubernetes系统中部署所述各个应用。
15.进一步地，所述部署模块，具体用于获取所述各个应用的存储资源占用率数据，根据所述各个应用的存储资源占用率数据确定平均存储资源占用率数据；所述调度模块，具体用于当所述平均存储资源占用率数据大于预设的第一占用率阈值，或所述平均存储资源占用率数据小于预设的第二占用率阈值，确定触发资源调度条件。
16.进一步地，所述部署模块，具体用于获取所述各个应用的计算资源占用率数据，根据所述各个应用的计算资源占用率数据确定平均计算资源占用率数据；所述调度模块，具体用于当所述平均计算资源占用率数据大于预设的第三占用率阈值，或所述平均计算资源占用率数据小于预设的第四占用率阈值，确定触发资源调度条件。
17.进一步地，所述调度模块，具体用于当所述平均存储资源占用率数据大于预设的第一占用率阈值，增加所述hadoop系统资源的副本实例；当所述平均存储资源占用率数据小于预设的第二占用率阈值，减少所述hadoop系统资源的副本实例。
18.进一步地，所述调度模块，具体用于当所述平均存储资源占用率数据小于预设的第二占用率阈值，确定当前hdfs中不存在副本数不足的文件时，删除副本id最大的datanode副本实例。
19.进一步地，所述调度模块，具体用于当所述平均计算资源占用率数据大于预设的第三占用率阈值，增加所述hadoop系统资源的副本实例；当所述平均计算资源占用率数据小于预设的第四占用率阈值，减少所述hadoop系统资源的副本实例。
20.进一步地，所述调度模块，具体用于当所述平均计算资源占用率数据小于预设的第四占用率阈值，确定副本id最大的nodemanager没有执行任务时，删除副本id最大的nodemanager副本实例，如果所述副本id最大的nodemanager正在执行任务，等到所述副本id最大的nodemanager执行任务完成，删除所述副本id最大的nodemanager副本实例。
21.再一方面，本发明实施例提供了一种电子设备，包括处理器、通信接口、存储器和通信总线，其中，处理器，通信接口，存储器通过通信总线完成相互间的通信；存储器，用于存放计算机程序；处理器，用于执行存储器上所存放的程序时，实现上述任一项所述的方法步骤。
22.再一方面，本发明实施例提供了一种计算机可读存储介质，所述计算机可读存储介质内存储有计算机程序，所述计算机程序被处理器执行时实现上述任一项所述的方法步骤。
23.本发明实施例提供了一种资源调度方法、装置、设备及介质，所述方法包括：在kubernetes系统中部署hadoop系统的各个应用，获取所述各个应用的资源占用率数据；当根据所述各个应用的资源占用率数据确定满足触发资源调度条件，且当前不处于预设的冷却期内时，根据预先设定的资源调度策略进行资源调度，并重新进入冷却期。
24.上述的技术方案具有如下优点或有益效果：本发明实施例中，预先设定触发资源调度条件以及资源调度策略。首先将hadoop系统的各个应用部署在kubernetes系统中，然后获取hadoop系统的各个应用的资源占用率数据之后，根据各个应用的资源占用率数据判断是否满足触发资源调度条件，如果满足，并且判断当前不处于预设的冷却期内，则根据预先设定的资源调度策略进行资源调度。本发明实施例提供的方案实现了hadoop系统资源的按需分配，解决了现有技术中hadoop系统资源闲时浪费，忙时不足的问题，并且通过设置冷却期，避免了资源调度后，又满足触发资源调度触发条件反复进行资源调度的问题。
附图说明
25.为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简要介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
26.图1为本发明实施例1提供的hadoop系统资源扩容和缩容过程示意图；图2为发明实施例2提供的在kubernetes系统中部署所述hadoop系统的服务的流程图；图3为本发明实施例3提供的hadoop存储资源自动扩容、缩容流程图；图4为本发明实施例4提供的hadoop计算资源自动扩容、缩容流程图；图5为本发明实施例5提供的hadoop系统扩容和缩容装置结构示意图；图6为本发明实施例6提供的电子设备结构示意图。
具体实施方式
27.下面将结合附图对本发明作进一步地详细描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。
28.本发明实施例中涉及的英文名次解释如下：kubernetes：是用于自动部署、扩展和管理容器化应用程序的开源老系统。它将组成应用程序的容器组合成逻辑单元，以便于管理和服务发现。kubernetes源自google 15年生产环境的运维经验，同时凝聚了社区的最佳创意和实践。
29.hadoop：起源于apache nutch项目，始于2002年，是apache lucene的子项目之一。2006年独立成为一套完整的软件，并被命名为hadoop。
30.hdfs：hadoop distributed file system，hadoop项目的核心子项目，是分布式计算中数据存储管理的基础。由namenode和datanode组成，其中namenode依赖journalnode和zookeeper。
31.journalnode：hadoop中的一个独立服务，作用是存放editlog（对hdfs进行的各种操作日志）。
32.namenode：hadoop中的一个独立服务，负责管理hdfs中文件系统的名字空间以及客户端的访问。
33.datanode：hadoop中的一个独立服务，提供真实文件数据的存储服务。
34.yarn：yet another resource negotiator，是hadoop分布式处理框架中的资源管理和作业调度技术实现。由于resourcemanager、jobhistoryserver和nodemanager组成，其中resourcemanager依赖zookeeper。
35.resourcemanager：hadoop中的一个独立服务，负责全局的资源管理和任务调度，把整个集群当成计算资源池。
36.jobhistoryserver：hadoop中的一个独立服务，负责记录历史分布式任务的日志。
37.nodemanager：hadoop中的一个独立服务，yarn中单节点的代理，管理hadoop集群中单个计算节点。
38.zookeeper：apache软件基金会的一个项目，它为大型分布式计算提供开源的分布式配置服务、同步服务和命名注册。
39.apache：是专门为运作开源软件项目的团体提供支持的非盈利组织。
40.cloudera：一家商业公司，基础开源的hadoop版本，提供修订、完善等配套和实施服务。
41.hortonworks：一家商业公司，类似于cloudera，与2018年与cloudear合并。
42.镜像：包含应用程序以及其相关依赖的一个基础文件系统。用镜像可以快速、批量创建应用程序的运行环境。
43.实施例1：图1为本发明实施例提供的资源调度过程示意图，该过程包括以下步骤：s101：在kubernetes系统中部署hadoop系统的各个应用，获取所述各个应用的资源占用率数据。
44.s102：当根据所述各个应用的资源占用率数据确定满足触发资源调度条件，且当前不处于预设的冷却期内时，根据预先设定的资源调度策略进行资源调度，并重新进入冷却期。
45.本发明实施例提供的资源调度方法应用于电子设备，该电子设备可以是pc、平板电脑、服务器等设备。本发明实施例中的资源调度包括对hadoop系统资源的调度。具体的是对hadoop系统资源扩容或缩容。
46.为了实现hadoop系统资源调度，首先需要在kubernetes系统中部署所述hadoop系统的各个应用。在本发明实施例中，制作hadoop系统的各个应用的镜像文件；将各个应用的镜像文件加载到kubernetes系统中；在kubernetes系统中运行镜像文件，以在kubernetes系统中部署hadoop系统的各个应用。
47.在kubernetes系统中部署hadoop系统的各个应用之后，电子设备获取各个应用的资源占用率数据，根据hadoop系统各个应用的资源占用率数据判断是否需要进行资源调度，即根据hadoop系统各个应用的资源占用率数据判断是否需要进行资源扩容或缩容。电子设备中预先设定触发资源调度条件和资源调度策略，若hadoop系统各个应用的资源占用率数据满足触发资源调度条件，则根据预先设定的资源调度策略进行资源调度。具体的，电子设备分别设定资源扩容条件和资源扩容策略，资源缩容条件和资源缩容策略。若hadoop系统各个应用的资源占用率数据满足触发资源扩容条件，则采用资源扩容策略进行资源调度。若各个应用的资源占用率数据满足触发资源缩容条件，则采用资源缩容策略进行资源调度。
48.其中，资源调度条件可以根据资源占用率阈值进行设定，资源调度策略包括增加系统资源的副本实例或减少系统资源的副本实例。
49.另外，本发明实施例中，扩容或缩容后，整体占用资源的平均值会下降。如果扩缩容阈值设置不合理，则可能导致扩容完又触发缩容，缩容完又触发扩容。因此，需要设置冷却期。避免由于资源占用波动，导致的扩容和缩容。
50.当根据hadoop系统各个应用的资源占用率数据确定满足触发资源调度条件之后，判断当前是否处于预设的冷却期内，如果否，根据预先设定的资源调度策略进行资源调度。当然，如果当前处于预设的冷却期内，则不进行资源调度。
51.本发明实施例中，预先设定触发资源调度条件以及资源调度策略。首先将hadoop系统的各个应用部署在kubernetes系统中，然后获取hadoop系统的各个应用的资源占用率数据之后，根据各个应用的资源占用率数据判断是否满足触发资源调度条件，如果满足，并且判断当前不处于预设的冷却期内，则根据预先设定的资源调度策略进行资源调度。本发明实施例提供的方案实现了hadoop系统资源的按需分配，解决了现有技术中hadoop系统资源闲时浪费，忙时不足的问题，并且通过设置冷却期，避免了资源调度后，又满足触发资源调度触发条件反复进行资源调度的问题。
52.实施例2：在上述实施例的基础上，在本发明实施例中，所述在kubernetes系统中部署hadoop系统的各个应用包括：获取所述hadoop系统的各个应用的部署配置文件，根据所述各个应用的部署配置文件确定所述各个应用的镜像文件版本信息和副本数；根据所述各个应用的镜像文件版本信息从镜像仓库获取对应的镜像文件，根据所述各个应用的副本数和镜像文件，在所述kubernetes系统中部署所述各个应用。
53.其中， hadoop系统的各个应用的镜像文件包括hadoop系统的journalnode、namenode、resourcemanager、jobhistoryserver、datanode、nodemanager、zookeeper应用的镜像文件。将制作完成的镜像文件推送至镜像仓库，编写zookeeper和hadoop的部署配置文件，从镜像仓库中获取镜像文件，根据zookeeper和hadoop的部署配置文件，在kubernetes系统中部署zookeeper、hadoop系统的journalnode、namenode、resourcemanager、jobhistoryserver、datanode、nodemanager的应用。
54.本发明实施例的目标之一是解决kubernetes集群和hadoop集群分开部署，导致硬件资源无法共享的问题。为了解决这一问题，最简单且直观的办法就是在kubernetes集群上部署hadoop集群。由于hadoop在设计之初就没有考虑过部署在kubernetes上，所以本方面实施例的一部分就是如何在kubernetes集群上部署hadoop集群。
55.本发明实施例的另一个目标是如何利用kubernetes对应用的自动弹性伸缩的能力，对hadoop的存储和计算资源进行扩容和缩容。这部分主要涉及容器扩缩容度量指标（如计算资源cpu占用率、存储资源占用率）的采集。扩容或缩容后，整体占用资源的平均值会下降。如果扩缩容阈值设置不合理，则可能导致扩容完又触发缩容，缩容完又触发扩容。因此，需要设置冷却期。避免由于资源占用波动，导致的扩容和缩容。
56.图2为本发明实施例提供的在kubernetes系统中部署所述hadoop系统的应用的流程图。
57.此处省略前置依赖部署kubernetes集群流程，假定已经存在一套kubernetes集群。
58.原生的hadoop，不论是apache官方提供的版本，还是cloudera、hortonworks提供的发行版本，均是设计部署在物理机上的。在本发明实施例中，为了统一物理机资源管理，需要将hadoop的各个应用部署在kubernetes集群上。因此第一步需要制作hadoop各应用的镜像。
59.hadoop集群由多个应用组成，其中包括journalnode、namenode、resourcemanager、jobhistoryserver、datanode、nodemanager。另外，hadoop集群还依赖
zookeeper集群，因此还需要制作zookeeper应用的镜像。制作的镜像需要包含适当的配置文件和支持自动启动对应的应用并组建集群。
60.将制作完成的镜像推送至镜像仓库，后续在kubernetes上部署hadoop集群，会从镜像仓库中拉取应用对应版本的镜像。镜像拉取至本地后，除非后续hadoop升级引起镜像版本变动，否则会利用缓存在本地的镜像，不用重复拉取。
61.制作并推送镜像完成后，需要编写zookeeper集群和hadoop集群的部署配置文件。该部署配置文件中包含了各应用的镜像版本、cpu和内存分配情况、副本个数（datanode和nodemanager包含最小和最大个数）、持久化磁盘信息，以及扩容、缩容策略。由于实际部署环境的差异，该部署配置文件也存在着各种差异，比如cpu和内存分配不同，副本个数不同，持久化磁盘信息不同等等。该部署配置文件由实施人员在现场部署时进行调整，此处不再详细举例。
62.使用对应的zookeeper部署配置文件，在kubernetes集群上部署zookeeper集群，这里假定现场部署的是3副本的zookeeper集群。kubernetes集群会尝试在本地查找是否存在指定的zookeeper镜像，如果不存在则会自动从镜像仓库拉取（下载）镜像。kubernetes集群确保本地存在指定版本的zookeeper镜像后，会根据部署配置文件创建3副本的zookeeper容器。每个zookeeper容器启动后，会先从环境变量中读取副本数（该副本数由kubernetes根据部署配置文件中配置信息生成并注入容器），然后启动脚本根据副本数和服务域名前缀信息，将副本实例的域名信息填入配置文件，并启动zookeeper应用。稍后，zookeeper各容器会根据配置信息组建集群。至此，zookeeper集群已经在kubernetes上部署并组建成功。
63.使用hadoop部署配置文件，在kubernetes集群上部署hadoop的journalnode、namenode、jobhistoryserver、resourcemanager等应用，这里假定现场部署的是3副本的journalnode、2副本的namenode、1副本的jobhistoryserver、2副本的resourcemanager。kubernetes集群会尝试在本地查找是否存在指定的服务镜像，如果不存在则会自动从镜像仓库拉取（下载）镜像。
64.kubernetes集群确保本地存在指定版本的journalnode镜像后，会根据部署配置文件创建3副本的journalnode容器。每个journalnode容器启动后，会先从环境变量中读取副本数（该副本数由kubernetes根据部署配置文件中配置信息生成并注入容器），然后启动脚本根据副本数和服务域名前缀信息，将副本实例的域名信息填入配置文件，并启动journalnode应用。稍后，journalnode各容器会根据配置信息组建集群。
65.kubernetes集群确保本地存在指定版本的namenode镜像后，会根据部署配置文件创建2副本的namenode容器。每个namenode 容器启动后，会先从环境变量中读取namenode副本数、journalnode的服务域名前缀及副本数、zookeeper的服务域名前缀及副本数（这些信息由kubernetes根据部署配置文件中配置信息生成并注入容器。由于namenode应用依赖journalnode和zookeeper，所以需要这部分信息），然后启动脚本根据journalnode和zookeeper的服务域名前缀和副本数，将journalnode和zookeeper的副本实例的域名信息填入配置文件，并启动namenode应用和zkfc应用（namenode和zkfc必须部署在一个容器内，zkfc属于namenode的辅助进程）。然后，副本id为0的namenode负责初始化集群，其中包括格式化zookeeper、格式化journalnode、生成集群id等步骤。待初始化后步骤完成后，副本id
为1的namenode将从副本id为0的namenode中同步集群信息。稍后，namenode的2个容器就会组建成主备关系。
66.kubernetes集群确保本地存在指定版本的jobhistoryserver镜像后，会根据部署配置文件创建1个jobhistoryserver容器。jobhistoryserver容器启动后，会从环境变量中读取namenode的服务域名前缀及副本数（这些信息由kubernetes根据部署配置文件中的配置信息生成并注入容器），然后启动脚本根据namenode的服务域名前缀和副本数，将namenode的副本实例的域名信息填入配置文件，并启动jobhistoryserver应用。
67.kubernetes集群确保本地存在指定版本的resourcemanager镜像后，会根据部署配置文件创建2副本的resourcemanager容器。resourcemanager容器启动后，会从环境变量中读取 resourcemanager副本数、namenode的服务域名前缀及副本数、zookeeper的服务域名前缀及副本数、jobhistoryserver的服务域名前缀及副本数（这些信息由kubernetes根据部署配置文件中配置信息生成并注入容器。由于resourcemanager应用依赖namenode、jobhistoryserver和zookeeper，所以需要这部分信息），然后启动脚本根据namenode的服务域名前缀和副本数、zookeeper的服务域名前缀和副本数、jobhistoryserver的服务域名前缀和副本数，将namenode、jobhistoryserver、zookeeper的副本实例域名信息填入配置文件，并启动resourcemanager应用。稍后，resourcemanager的2个容器就会组建成主备关系。
68.使用hadoop部署配置文件，在kubernetes集群上部署hadoop的datanode应用，datanode应用主要负责hadoop
‑
hdfs中的分布式数据存储部分。datanode应用需要配置最小副本数和最大副本数，以及扩容和缩容规则。当kubernetes检测到datanode各个副本容器的资源占用情况符合扩容或缩容标准，且实际副本个数在最小副本数和最大副本数之间，则会触发扩容或缩容操作。kubernetes集群确保本地存在指定版本的datanode镜像后，会根据部署配置文件创建最小副本数的datanode容器。datanode容器启动后，会从环境变量中读取namenode的服务域名前缀及副本数（这些信息由kubernetes根据部署配置文件中的配置信息生成并注入容器。由于datanode服务依赖namenode，所以需要这部分信息），然后启动脚本根据namenode的服务域名前缀和副本数，将namenode的副本实例域名信息填入配置文件，并启动datanode应用。稍后，datanode应用会根据配置的namenode的信息，注册至namenode。至此，hadoop中的hdfs部分已经部署完成。
69.使用hadoop部署配置文件，在kubernetes集群上部署hadoop的nodemanager应用，noademanager应用主要负责hadoop
‑
yarn中的分布式任务执行部分。nodemanager应用需要配置最小副本数和最大副本数，以及扩容和缩容规则（当kubernetes检测到nodemanager各个容器的资源占用情况符合扩容或缩容标准，且实际副本个数在最小副本数和最大副本数之间，则会触发扩容或缩容操作。kubernetes集群确保本地存在指定版本的nodemanager镜像后，会根据部署配置文件创建最小副本数的nodemanager容器。nodemanager容器启动后，会从环境变量中读取resourcemanager的服务域名前缀及副本数（这些信息由kubernetes根据部署配置文件中的配置信息生成并注入容器。由于nodemanager应用依赖resourcemanager，所以需要这部分信息），然后启动脚本根据resoucemanager的服务域名前缀和副本数，将resourcemanager的副本实例域名信息填入配置文件，并启动nodemanager应用。稍后，nodemanager应用会根据配置的resoucemanager的信息，注册至
resoucemanager。至此，hadoop中的yarn部分已经部署完成。
70.至此，一个最小资源的hadoop集群在kubernetes集群上已经部署完成，后续在使用过程中，会根据资源占用率kubernetes会自动的对hadoop集群进行扩容和缩容。
71.实施例3：在上述实施例的基础上，在本发明实施例中，所述获取所述各个应用的资源占用率数据；根据所述各个应用的资源占用率数据确定满足触发资源调度条件包括：获取所述各个应用的存储资源占用率数据，根据所述各个应用的存储资源占用率数据确定平均存储资源占用率数据，当所述平均存储资源占用率数据大于预设的第一占用率阈值，或所述平均存储资源占用率数据小于预设的第二占用率阈值，确定触发资源调度条件。
72.本发明实施例提供的资源调度方案涉及系统存储资源的调度。存储资源调度时，需要获取hadoop系统中各个应用的存储资源占用率数据，根据各个应用的存储资源占用率数据判断是否满足触发资源调度条件。
73.具体的，获取各个应用的存储资源占用率数据，根据各个应用的存储资源占用率数据确定平均存储资源占用率数据，当平均存储资源占用率数据大于预设的第一占用率阈值，或平均存储资源占用率数据小于预设的第二占用率阈值，确定触发资源调度条件。
74.其中，预设的第一占用率阈值大于预设的第二占用率阈值。
75.所述根据预先设定的资源调度策略进行资源调度包括：当所述平均存储资源占用率数据大于预设的第一占用率阈值，增加所述hadoop系统资源的副本实例；当所述平均存储资源占用率数据小于预设的第二占用率阈值，减少所述hadoop系统资源的副本实例。
76.所述当所述平均存储资源占用率数据小于预设的第二占用率阈值，减少所述hadoop系统资源的副本实例包括：当所述平均存储资源占用率数据小于预设的第二占用率阈值，确定当前hdfs中不存在副本数不足的文件时，删除副本id最大的datanode副本实例。
77.图3为本发明实施例提供的hadoop存储资源自动扩容、缩容流程图。
78.hadoop
‑
hdfs
‑
adapater会定时采集hdfs的存储空间占用空间，及采集各个应用的存储资源占用率数据，并将数据同步给kubernetes集群的metrics server。若所述hadoop系统中hdfs存储资源占用率大于预设的第一占用率阈值，确定满足所述扩容条件；增加所述hadoop系统资源的datanode副本实例；若所述hadoop系统中hdfs存储资源占用率小于预设的第二占用率阈值，确定满足所述缩容条件；减少所述hadoop系统资源的datanode副本实例；其中，所述预设的第二占用率阈值小于所述预设的第一占用率阈值。
79.具体的，kubernetes集群中的hpa控制器（horizontal pod autoscaler）会从metrics server上获取这些数据，用于对扩容、缩容规则进行计算，得到对应datanode应用的副本数量。比如，当前datanode应用副本数为4，每个副本的存储空间为1tb，实际使用存储空间分别为：550gb、500gb、600gb、550gb，则平均空间占用率为55%。如果在hpa规则中配置的缩容条件为空间占用率为60%，扩容条件为空间占用率为90%。hpa控制器通过计算后，得出合理的副本数应该为3，则会触发缩容，删除多余datanode服务副本，将datanode服务副本数调整为3。需要说明的是：删除datanode服务副本时，该副本上的数据会在其他
datanode服务副本上进行恢复，所以实际使用存储总空间是不变的。期望副本数是根据存储总空间跟实际使用空间计算出来的，其计算公式可以简单的理解为：60%（缩容阈值）<实际使用存储空间/(副本存储空间*副本数)<90%（扩容阈值）当hpa控制器计算出来的datanode服务的期望副本数量，与当前实际的副本数量不同时，hpa控制器就会向datanode服务的副本控制器发起scale操作，调整datanode的副本数量，完成扩容、缩容操作。
80.增加所述hadoop系统资源的副本实例，或者减少所述hadoop系统资源的副本实例之后，重新进入冷却期。
81.当hpa控制器计算出来的datanode服务的期望副本数量，与当前实际的副本数量不同时，且目前不处于前一次扩容、缩容后的冷却期。hpa控制器就会向datanode服务的副本控制器发起scale操作，调整datanode的副本数量，完成扩容、缩容操作。
82.根据hpa控制器计算和后续判断逻辑，可以分为以下几种情况：达到扩容条件，且不处于冷却期。hpa控制器会向datanode应用的副本控制器发起增加副本的操作，kubernetes集群会自动创建新的datanode副本，并注入依赖的环境变量。datanode的启动脚本会从环境变量中获取依赖的namenode信息，并将信息填入配置文件，并启动datanode应用。后续，datanode应用将自动注册到namenode应用上，至此，hdfs的存储空间自动扩容就完成了。新的datanode将承担起部分分布式数据的写入任务。在实际生产环境中，每次扩容的数量可以为3的倍数，避免扩容后数据不均衡。
83.达到扩容条件，但处于冷却期。由于当前处于冷却期，hpa控制器不会执行扩容操作。
84.达到缩容条件，且不处于冷却期。hpa控制器会向datanode应用的副本控制器发起减少副本的操作，kubernetes集群会自动删除副本id最大的datanode副本。在datanode副本被删除之前，datanode需要从namenode上删除自己，避免namenode认为datanode是离线，而不是删除。至此，hdfs的存储空间自动缩容就完成了。剩下的datanode将承担起全部分布式数据的写入任务，并且在剩余的datanode上恢复被删除的datanode上的数据。datanode上的数据，本身会在多个datanode上存储多份，所以就算删除一个datanode服务副本，数据也是可以在其他datanode上进行恢复的。在实际生产环境中，缩容意味着触发非常耗时数据恢复，占用集群的带宽，因此缩容会非常的谨慎，即便空间剩余很大，一般不会触发缩容操作。
85.达到缩容条件，但处于冷却期。由于当前处于冷却期，hpa控制器不会执行缩容操作。
86.未达到任何扩容、缩容条件。等待下一轮检查。
87.需要说明的是，kubernetes中，副本名称的后缀就是副本id，从1开始递增，扩容时，新创建的副本的副本id最大。当缩容时，从副本id最大的开始删除。datanode应用有一个描述信息，用于规定所需的cpu、内存、存储空间，当kubernetes用同样的描述信息，创建出一个个的datanode服务实例，这些服务实例被称为datanode服务副本（因为是从同一份描述信息创建出来的）。容器指的是kubernetes创建出来的实例，这些实例可能是同一个服务的副本，也可能是不同服务。副本一般是特指某一组容器中的一个，容器就是指某一个容器。
88.在扩容和缩容操作完成后，kubernetes会对datanode应用设置冷却期，为了避免
扩容、缩容度量指标波动带来的频繁扩容和缩容操作，尤其是缩容操作。因为缩容操作意味着分布式存储上的数据副本数减少，会进一步触发文件恢复流程。在文件恢复流程完成之前，如果再次触发缩容操作，可能会引起数据丢弃。因此缩容的触发条件会设置的比较苛刻，冷却时间会设置的比较长，以确保缩容对服务影响的平滑。同时，hadoop集群中的datanode可能处于离线状态，这种情况下hdfs的数据副本数不足，同样会进入等待，直至离线的datanode恢复正常才会触发缩容流程。
89.实施例4：在上述实施例的基础上，在本发明实施例中，所述获取所述各个应用的资源占用率数据；根据所述各个应用的资源占用率数据确定满足触发资源调度条件包括：获取所述各个应用的计算资源占用率数据，根据所述各个应用的计算资源占用率数据确定平均计算资源占用率数据，当所述平均计算资源占用率数据大于预设的第三占用率阈值，或所述平均计算资源占用率数据小于预设的第四占用率阈值，确定触发资源调度条件。
90.本发明实施例提供的资源调度方案涉及系统计算资源的调度。计算资源调度时，需要获取hadoop系统中各个应用的计算资源占用率数据，根据各个应用的计算资源占用率数据判断是否满足触发资源调度条件。
91.具体的，获取各个应用的计算资源占用率数据，根据各个应用的计算资源占用率数据确定平均计算资源占用率数据，当平均计算资源占用率数据大于预设的第三占用率阈值，或平均接收资源占用率数据小于预设的第四占用率阈值，确定触发资源调度条件。
92.其中，预设的第三占用率阈值大于预设的第四占用率阈值。对预设的第一占用率阈值和预设的第三占用率阈值的大小关系不进行限定，对预设的第二占用率阈值和预设的第四占用率阈值的大小关系不进行限定。
93.所述根据预先设定的资源调度策略进行资源调度包括：当所述平均计算资源占用率数据大于预设的第三占用率阈值，增加所述hadoop系统资源的副本实例；当所述平均计算资源占用率数据小于预设的第四占用率阈值，减少所述hadoop系统资源的副本实例。
94.所述当所述平均计算资源占用率数据小于预设的第四占用率阈值，减少所述hadoop系统资源的副本实例包括：当所述平均计算资源占用率数据小于预设的第四占用率阈值，确定副本id最大的nodemanager没有执行任务时，删除副本id最大的nodemanager副本实例，如果所述副本id最大的nodemanager正在执行任务，等到所述副本id最大的nodemanager执行任务完成，删除所述副本id最大的nodemanager副本实例。
95.图4为本发明实施例提供的hadoop计算资源自动扩容、缩容流程图。
96.若所述hadoop系统中各个nodemanager副本中的平均cpu占用率大于预设的第三占用率阈值，确定满足所述扩容条件；增加所述hadoop系统资源的nodemanager副本实例；若所述hadoop系统中各个nodemanager副本中的平均cpu占用率小于预设的第四占用率阈值，确定满足所述缩容条件；减少所述hadoop系统资源的nodemanager副本实例。
97.具体的，hadoop
‑
yarn
‑
adapater会定时采集nodemanager各个副本中的cpu占用率数据，并将数据同步给kubernetes集群的metrics server。kubernetes集群中的hpa控制器
（horizontalpodautoscaler）会从metricsserver上获取这些数据，用于对扩容、缩容规则进行计算，得到对应nodemanager服务的副本数量。比如，当前nodemanager服务副本数为4，实际使用cpu占用率分别为：60%、65%、60%、45%，则平均cpu占用率为57.5%。如果在hpa规则中配置的缩容条件为cpu占用率为60%，扩容条件为cpu占用率为80%。hpa控制器通过计算后，得出合理的副本数应该为3，则会触发缩容，删除多余nodemanager服务副本，将nodemanager服务副本数调整为3。需要说明的是：删除nodemanager服务副本并不是立即执行的，还需要判断该nodemanager副本实例上是否有尚未结束的任务，具体下面有描述。期望副本数是根据平均cpu占用率计算出来的，其计算公式可以简单的理解为：60%（缩容阈值）<平均cpu占用率<90%（扩容阈值）。注意，nodemanager缩容，是等待任务结束后才进行缩容，所以只需要考虑剩余的nodemanager副本的平均cpu占用率即可。
98.当hpa控制器计算出来的nodemanager服务的副本数量，与当前实际的副本数量不同时，且目前不处于前一次扩容、缩容后的冷却期。hpa控制器就会向nodemanager由于的副本控制器发起scale操作，调整nodemanager的副本数量，完成扩容、缩容操作。根据hpa控制器计算和后续判断逻辑，可以分为以下几种情况：达到扩容条件，且不处于冷却期。hpa控制器会向nodemanager由于的副本控制器发起增加副本的操作，kubernetes集群会自动创建新的nodemanager副本，并注入依赖的环境变量。nodemanager的启动脚本会从环境变量中获取依赖的resoucemanager信息，并将信息填入配置文件，并启动nodemanager由于。后续，nodemanager由于将自动注册到resoucemanager由于上，至此，yarn的计算资源自动扩容就完成了。新的nodemanager将承担起部分分布式计算任务的执行。在实际生产环境中，每次扩容只扩容一个副本，避免资源占用过多，导致利用率不足。
99.达到扩容条件，但处于冷却期。由于当前处于冷却期，hpa控制器不会执行扩容操作。
100.达到缩容条件，且不处于冷却期。hpa控制器会向nodemanager由于的副本控制器发起减少副本的操作，kubernetes集群会自动删除副本id最大的nodemanager副本。在nodemanager副本被删除之前，nodemanager需要从resoucemanager上删除自己，避免resoucemanager认为nodemanager是离线，而不是删除。至此，yarn的计算资源自动缩容就完成了。剩下的nodemanager将承担起全部分布式计算任务的执行。在实际生产环境中，任务的执行时间和周期不一致，以及调度策略，副本id最大的nodemanager在整个集群空闲的情况下，并不一定是空闲的，可能存在遗留任务正在执行的情况，这时需要将这台nodemanager标记为unhealthy，标记为unhealthy的nodemanager不会再被调度执行新的任务。待所有任务执行完成后，才会触发缩容操作。
101.达到缩容条件，但处于冷却期。由于当前处于冷却期，hpa控制器不会执行缩容操作。
102.未达到任何扩容、缩容条件。等待下一轮检查。
103.在扩容和缩容操作完成后，kubernetes会对nodemanager服务设置冷却期，为了避免扩容、缩容度量指标波动带来的频繁扩容和缩容操作，尤其是缩容操作。因为缩容操作必须要等待删除的nodemanager副本上的任务执行完毕，在任务执行完毕之前，这个nodemanager副本会被标记为unhealthy。因此，nodemanager的实际缩容可能会一次性删除
多个nodemanager副本（某些长时间任务执行完毕后，占用资源同时释放）。
104.实施例5：图5为本发明实施例提供的资源调度装置结构示意图，该装置包括：部署模块51，用于在kubernetes系统中部署hadoop系统的各个应用，获取所述各个应用的资源占用率数据；调度模块52，用于当根据所述各个应用的资源占用率数据确定满足触发资源调度条件，且当前不处于预设的冷却期内时，根据预先设定的资源调度策略进行资源调度，并重新进入冷却期。
105.所述部署模块51，具体用于获取所述hadoop系统的各个应用的部署配置文件，根据所述各个应用的部署配置文件确定所述各个应用的镜像文件版本信息和副本数；根据所述各个应用的镜像文件版本信息从镜像仓库获取对应的镜像文件，根据所述各个应用的副本数和镜像文件，在所述kubernetes系统中部署所述各个应用。
106.所述部署模块51，具体用于获取所述各个应用的存储资源占用率数据，根据所述各个应用的存储资源占用率数据确定平均存储资源占用率数据；所述调度模块52，具体用于当所述平均存储资源占用率数据大于预设的第一占用率阈值，或所述平均存储资源占用率数据小于预设的第二占用率阈值，确定触发资源调度条件。
107.所述部署模块51，具体用于获取所述各个应用的计算资源占用率数据，根据所述各个应用的计算资源占用率数据确定平均计算资源占用率数据；所述调度模块52，具体用于当所述平均计算资源占用率数据大于预设的第三占用率阈值，或所述平均计算资源占用率数据小于预设的第四占用率阈值，确定触发资源调度条件。
108.所述调度模块52，具体用于当所述平均存储资源占用率数据大于预设的第一占用率阈值，增加所述hadoop系统资源的副本实例；当所述平均存储资源占用率数据小于预设的第二占用率阈值，减少所述hadoop系统资源的副本实例。
109.所述调度模块52，具体用于当所述平均存储资源占用率数据小于预设的第二占用率阈值，确定当前hdfs中不存在副本数不足的文件时，删除副本id最大的datanode副本实例。
110.所述调度模块52，具体用于当所述平均计算资源占用率数据大于预设的第三占用率阈值，增加所述hadoop系统资源的副本实例；当所述平均计算资源占用率数据小于预设的第四占用率阈值，减少所述hadoop系统资源的副本实例。
111.所述调度模块52，具体用于当所述平均计算资源占用率数据小于预设的第四占用率阈值，确定副本id最大的nodemanager没有执行任务时，删除副本id最大的nodemanager副本实例，如果所述副本id最大的nodemanager正在执行任务，等到所述副本id最大的nodemanager执行任务完成，删除所述副本id最大的nodemanager副本实例。
112.实施例6：在上述各实施例的基础上，本发明实施例中还提供了一种电子设备，如图6所示，包括：处理器301、通信接口302、存储器303和通信总线304，其中，处理器301，通信接口302，存储器303通过通信总线304完成相互间的通信；
所述存储器303中存储有计算机程序，当所述程序被所述处理器301执行时，使得所述处理器301执行如下步骤：在kubernetes系统中部署hadoop系统的各个应用，获取所述各个应用的资源占用率数据；当根据所述各个应用的资源占用率数据确定满足触发资源调度条件，且当前不处于预设的冷却期内时，根据预先设定的资源调度策略进行资源调度，并重新进入冷却期。
113.基于同一发明构思，本发明实施例中还提供了一种电子设备，由于上述电子设备解决问题的原理与资源调度方法相似，因此上述电子设备的实施可以参见方法的实施，重复之处不再赘述。
114.本发明实施例提供的电子设备具体可以为桌面计算机、便携式计算机、智能手机、平板电脑、个人数字助理（personal digital assistant，pda）、网络侧设备等。
115.上述电子设备提到的通信总线可以是外设部件互连标准（peripheral component interconnect，pci）总线或扩展工业标准结构（extended industry standard architecture，eisa）总线等。该通信总线可以分为地址总线、数据总线、控制总线等。为便于表示，图中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
116.通信接口302用于上述电子设备与其他设备之间的通信。
117.存储器可以包括随机存取存储器（random access memory，ram），也可以包括非易失性存储器（non
‑
volatile memory，nvm），例如至少一个磁盘存储器。可选地，存储器还可以是至少一个位于远离前述处理器的存储装置。
118.上述处理器可以是通用处理器，包括中央处理器、网络处理器（network processor，np）等；还可以是数字信号处理器（digital signal processing，dsp）、专用集成电路、现场可编程门陈列或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。
119.在本发明实施例中处理器执行存储器上所存放的程序时，实现在kubernetes系统中部署hadoop系统的各个应用，获取所述各个应用的资源占用率数据；当根据所述各个应用的资源占用率数据确定满足触发资源调度条件，且当前不处于预设的冷却期内时，根据预先设定的资源调度策略进行资源调度，并重新进入冷却期。
120.本发明实施例中，预先设定触发资源调度条件以及资源调度策略。首先将hadoop系统的各个应用部署在kubernetes系统中，然后获取hadoop系统的各个应用的资源占用率数据之后，根据各个应用的资源占用率数据判断是否满足触发资源调度条件，如果满足，并且判断当前不处于预设的冷却期内，则根据预先设定的资源调度策略进行资源调度。本发明实施例提供的方案实现了hadoop系统资源的按需分配，解决了现有技术中hadoop系统资源闲时浪费，忙时不足的问题，并且通过设置冷却期，避免了资源调度后，又满足触发资源调度触发条件反复进行资源调度的问题。
121.实施例7：在上述各实施例的基础上，本发明实施例还提供了一种计算机存储可读存储介质，所述计算机可读存储介质内存储有可由电子设备执行的计算机程序，当所述程序在所述电子设备上运行时，使得所述电子设备执行时实现如下步骤：在kubernetes系统中部署hadoop系统的各个应用，获取所述各个应用的资源占用
率数据；当根据所述各个应用的资源占用率数据确定满足触发资源调度条件，且当前不处于预设的冷却期内时，根据预先设定的资源调度策略进行资源调度，并重新进入冷却期。
122.基于同一发明构思，本发明实施例中还提供了一种计算机可读存储介质，由于处理器在执行上述计算机可读存储介质上存储的计算机程序时解决问题的原理与资源调度方法相似，因此处理器在执行上述计算机可读存储介质存储的计算机程序的实施可以参见方法的实施，重复之处不再赘述。
123.上述计算机可读存储介质可以是电子设备中的处理器能够存取的任何可用介质或数据存储设备，包括但不限于磁性存储器如软盘、硬盘、磁带、磁光盘（mo）等、光学存储器如cd、dvd、bd、hvd等、以及半导体存储器如rom、eprom、eeprom、非易失性存储器（nand flash）、固态硬盘（ssd）等。
124.本发明是参照根据本发明实施例的方法、设备（系统）、和计算机程序产品的流程图和／或方框图来描述的。应理解可由计算机程序指令实现流程图和／或方框图中的每一流程和／或方框、以及流程图和／或方框图中的流程和／或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的装置。
125.这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能。
126.这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的步骤。
127.尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。
128.显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。