基于yarn和kubernetes的容器化双层调度方法及系统
技术领域：
：1.本公开涉及应用调度处理
技术领域：
：，尤其涉及一种基于yarn和kubernetes的容器化双层调度方法及系统。
背景技术：
：：2.边缘计算为电网的数据处理及区域自治提供了重要技术手段，随着电力通信业务多样性的增强以及便携式终端的普及，存在海量的异构数据(如语音、视频、图像等数据)接入边缘网络，而有限的边缘网络资源与海量异构数据的实时高效处理需求之间的矛盾日益突出。轻量级容器作为一种新型虚拟化技术，具有启动速度快、接近物理主机性能、资源利用率高等特性。由于容器通过与宿主机共享操作系统内核的方式实现了进程级别的虚拟化，在运行不同的应用程序的调度指令时只需要启动多个进程隔离的容器即可。3.现有技术中使用容器编排引擎对容器进行调度处理，应用最广泛的是kubernetes，kubernetes使用两阶段算法选取最大评分节点来实现容器资源调度。4.但是，kubernetes默认的调度机制只能完成节点级别的调度，并不能完成任务级别的调度，这很难适应海量异构数据调度的业务场景。技术实现要素：5.有鉴于此，本公开的目的在于提出一种能够解决或者部分解决上述问题的基于yarn和kubernetes的容器化双层调度方法及系统。6.基于上述目的，本公开的第一方面提出了一种基于yarn和kubernetes的容器化双层调度方法，包括：7.接收调度指令，对调度指令进行类别确定；8.确定所述调度指令为应用程序的调度指令，且所述应用程序的调度指令没有对应匹配的休眠容器，则利用yarn调度器为所述应用程序的调度指令分配对应的目标容器，利用所述目标容器执行所述应用程序的调度指令；9.确定所述调度指令为容器集群pod的调度指令，且所述容器集群pod此前未被调度过，则利用kubernetes调度器为所述容器集群pod的调度指令分配对应的目标节点node，利用所述目标节点node执行所述容器集群pod的调度指令。10.基于上述目的，本公开的第二方面提出了一种基于yarn和kubernetes的容器化双层调度系统，包括：调度模块和功能模块；11.所述调度模块包括：12.yarn调度器，用于确定接收到的调度指令为应用程序的调度指令，且所述应用程序的调度指令没有对应匹配的休眠容器，则为所述应用程序的调度指令分配对应的目标容器，利用所述目标容器执行所述应用程序的调度指令；13.kubernetes调度器，用于确定接收到的调度指令为容器集群pod的调度指令，且所述容器集群pod此前未被调度过，则为所述容器集群pod的调度指令分配对应的目标节点node，利用所述目标节点node执行所述容器集群pod的调度指令。14.从上面所述可以看出，本公开提供的基于yarn和kubernetes的容器化双层调度方法及系统，能够同时利用yarn和kubernetes的优势，实现任务级别的应用程序的调度指令和节点级别的容器集群pod的调度指令，进行并行统一调度，这样能够降低部署成本，提高容器资源利用率，使得容器资源利用更加合理，同时还能提高调度效率。附图说明15.为了更清楚地说明本公开或相关技术中的技术方案，下面将对实施例或相关技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本公开的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。16.图1为本公开实施例的基于yarn和kubernetes的容器化双层调度方法的流程图；17.图2为本公开实施例的基于yarn和kubernetes的容器化双层调度方法中步骤100的展开流程图；18.图3为本公开实施例的基于yarn和kubernetes的容器化双层调度方法中步骤200的展开流程图；19.图4为本公开实施例的基于yarn和kubernetes的容器化双层调度方法中步骤210的展开流程图；20.图5为本公开实施例的基于yarn和kubernetes的容器化双层调度方法中步骤220的展开流程图；21.图6为本公开实施例的基于yarn和kubernetes的容器化双层调度方法中步骤300的展开流程图；22.图7为本公开实施例的基于yarn和kubernetes的容器化双层调度系统的结构框图；23.图8为本公开实施例的基于yarn和kubernetes的容器化双层调度系统的组成架构图；24.图9为本公开实施例的yarn调度器和kubernetes调度器对应调度的架构图；25.图10为本公开实施例的电子设备的硬件结构示意图。具体实施方式26.为使本公开的目的、技术方案和优点更加清楚明白，以下结合具体实施例，并参照附图，对本公开进一步详细说明。27.需要说明的是，除非另外定义，本公开实施例使用的技术术语或者科学术语应当为本公开所属领域内具有一般技能的人士所理解的通常意义。本公开实施例中“包括”或者“包含”等类似的词语意指出现该词前面的元件或者物件涵盖出现在该词后面列举的元件或者物件及其等同，而不排除其他元件或者物件。28.在边缘环境中需要利用一种轻量型的高效数据处理和资源调度机制来保证海量异构数据调度业务的实时性。轻量级容器作为一种新型虚拟化技术，具有启动速度快、接近物理主机性能、资源利用率高等特性。由于容器通过与宿主机共享操作系统内核的方式实现了进程级别的虚拟化，在运行不同的应用程序的调度指令时只需要启动多个进程隔离的容器即可。而无需像虚拟机那样为每个应用程序的调度指令重新加载一个从操作系统并为其分配单独的cpu、内存、磁盘等。29.因此对于海量异构数据处理场景而言，容器相比于虚拟机在启动时间、资源利用率、资源消耗情况、系统性能等方面具有显著的优势。将容器应用于资源调度时，其核心思想是通过合适的调度策略将封装大数据处理应用的容器均分到物理服务器上，从而优化吞吐率，提高存储与处理效率。30.目前有三大主流的容器编排引擎：dockerswarm、apachemesos以及googlekubernetes，其中应用最广泛的是kubernetes。kubernetes使用两阶段算法选取最大评分节点来实现容器资源调度，然而kubernetes默认的调度机制只能完成节点级别的调度，并不能完成任务级别的调度，这很难适应海量异构数据调度的业务场景。此外还有很多学者利用启发式算法将资源调度问题建模为多目标优化问题来求解，然而，其中有些方案并没有利用到容器本身的轻量高效特性。31.相关技术中，利用延迟因子与动态权重的多资源指标node匹配，可以实现针对不同类型资源的云计算任务的高效资源调度，从而保证了云计算任务及时响应并实现了各资源之间负载均衡。但是，这种方式并未考虑容器本身的轻量高效、资源可重复利用等特性，在部署成本、调度等待时延、资源利用率方面存在一定的缺陷。32.相关技术中，利用kubernetes资源调度时，部署集群环境，将多节点评定为高、中、低等级；当资源充足时，将新pod调度到高等级节点资源上运行；当高等级节点资源不足时，将新pod依据节点等级由高到低的顺序把资源调度到中等级节点运行；当遍历所有节点均产生资源不足的情况时，判断高等级节点上已运行的原有pod，并对原有pod进行等级分级评定，动态删减低等级原有pod已分配的资源，释放部分资源；然后高等级节点回收释放的资源，并整合节点上剩余的资源，再次判断资源是否满足新pod运行，若充足则调度到该节点，若仍不足以调度新pod，当可运行到中、低等级的节点，则将原有pod从高等级节点调度到中、低等级节点上，同时释放高等级节点的资源；待高等级节点释放资源后再次遍历节点资源，判断是否达到新pod运行的资源条件，若满足则调度到此时的高等节点上，若不满足则继续动态删减节点来释放资源，直到节点有足够资源运行。该方法最主要解决了面临资源不足时，在不清除pod的前提下，合理进行资源调度的问题。但该这种方案的适用场景较为有限，例如面向大数据实时性处理场景下，这种方案较为复杂的动态删减整合资源的方式可能无法满足许多数据业务要求的低时延、高效率指标。33.相关技术中，基于分布式部署的任务调度过程中，协调主机作为分布式架构的协调器，负责监控调度主机和执行主机的健康状态，并完成高可用调度主机的选举；调度主机作为分布式架构的主节点，负责接收数据处理作业并对执行节点进行任务调度；执行主机作为分布式架构的从节点，负责接收调度主机派发的任务并执行，在执行完毕后向调度主机反馈执行结果；调度主机至少建立2个，其中一个作为实际运行并提供任务调度的主用实例，另一个或多个作为备用实例；协调主机能够根据调度主机的健康状态选择高可用的备用实例切换为主用实例；调度主机能够将上一次派发失败或执行失败的任务重新进行任务调度。这种实现方案，虽然利用分布式集群环境和主备机制能够防止单点故障并提高作业执行效率，但是，在面临海量异构数据的处理任务时可能达不到低时延需求。34.本公开设计了一种基于yarn和kubernetes的容器化双层调度方法和系统，能够同时利用yarn和kubernetes的优势，实现任务级别的应用程序的调度指令和节点级别的容器集群pod的调度指令的统一调度，此外还利用了容器本身的轻量高效特性，考虑了容器的调度记忆功能以及容器资源的重复利用概率，降低了部署成本，提高了中断响应的速率，从而使整合后的调度架构的资源利用更合理、更高效。35.如图1所示，本实施例提出的基于yarn和kubernetes的容器化双层调度方法，包括：36.步骤100，接收调度指令，对调度指令进行类别确定。37.步骤200，确定调度指令为应用程序的调度指令，且应用程序的调度指令没有对应匹配的休眠容器，则利用yarn调度器为应用程序的调度指令分配对应的目标容器，利用目标容器执行应用程序的调度指令。38.步骤300，确定调度指令为容器集群pod的调度指令，且容器集群pod此前未被调度过，则利用kubernetes调度器为容器集群pod的调度指令分配对应的目标节点node，利用目标节点node执行容器集群pod的调度指令。39.在上述步骤中，接收到调度指令的请求之后，首先确定该调度指令是属于应用程序的调度指令，还是属于容器集群pod的调度指令。针对应用程序的调度指令，一个或多个容器就可以执行，利用yarn调度器进行调度。针对容器集群pod的调度指令可能需要一个或多个目标节点node来执行，这里利用kubernetes调度器进行调度。其中，pod指对应的容器集群。40.进而分别利用yarn调度器或kubernetes调度器进行对应的任务分配，完成对应的调度指令。其中，yarn调度器和kubernetes调度器能够进行并行处理，二者并不互相影响。41.通过上述方案，能够同时利用yarn和kubernetes的优势，实现任务级别的应用程序的调度指令和节点级别的容器集群pod的调度指令，进行并行统一调度，这样能够降低部署成本，提高容器资源利用率，使得容器资源利用更加合理，同时还能提高调度效率。42.在具体实施例中，如图2所示，步骤100具体包括：43.步骤110，接收调度指令。44.步骤120，判断调度指令是否为初始调度，是则进入步骤130，否则进入步骤140。45.步骤130，为至少一个容器进行任务初始化配置，以及为至少一个容器集群pod进行节点初始化配置后，进入步骤140。46.步骤140，对调度指令进行类别确定。47.通过上述方案，如果调度指令是初始调度，则需要将容器初始化分配给不同的任务，并将pod初始化分配到各节点上，再对调度指令的类别进行确定。这样能够保证后续调度过程的顺利进行。48.在具体实施例中，yarn调度器包括：应用管理器am、资源管理器rm和节点管理器nm。49.则步骤200中的利用yarn调度器为应用程序的调度指令分配对应的目标容器，利用目标容器执行应用程序的调度指令，如图3所示，具体包括：50.步骤210，利用am根据接收到的应用程序的调度指令生成对应的至少一个资源请求，并将至少一个资源请求发送给rm。51.步骤220，利用rm接收nm发送的nm心跳信息后，根据nm心跳信息为至少一个资源请求确定对应的至少一个目标容器，利用至少一个目标容器执行至少一个资源请求，其中，资源请求与目标容器一一对应。52.在上述方案中，一个调度指令可能需要一个或多个目标容器来完成调用过程，通过am、rm和nm的配合能够确定出完成该调度指令的各个目标容器，进而利用各个目标容器来完成调度的过程。在yarn调度机制中，资源分配过程是异步的，也就是说，当资源管理器(rm)接收到来自应用管理器(am)的资源请求时，并不会立即对该资源请求进行分配，而是等到rm收到来自节点管理器(nm)发送的心跳信息时，通过判断是否有资源请求能够被调度到该心跳节点的方式来实现资源调度。53.在具体实施例中，如图4所示，步骤210具体包括：54.步骤211，接收到客户端提交给rm的应用程序的调度指令。55.步骤212，根据客户端提交给rm的应用程序的调度指令，匹配启动am的启动容器，并利用启动容器启动am。56.步骤213，利用am将应用程序的调度指令划分为至少一个任务，为每个任务生成对应的资源请求，并将至少一个资源请求发送至rm。57.在上述方案中，具体启动am的启动容器是am和rm进行协商后获取的。该启动容器为第一个容器。然后am启动之后利用am将应用程序的调度指令进行任务划分，对应生成相应的资源请求。58.在具体实施例中，如图5所示，步骤220具体包括：59.步骤221，利用nm定期向rm发送nm心跳信息。其中，nm心跳信息中包含：容器资源节点的可用资源，以及可用容器资源节点的对应容器信息。60.步骤222，利用rm接收到容器资源节点的心跳信息时，会向对应的调度程序发送一个更新节点属性事件(即，node_update事件)。61.步骤223，rm中的调度程序接收到更新节点属性事件后，调取nm心跳信息中的容器资源节点的可用资源。62.步骤224，确定至少一个资源请求中存在目标资源请求与容器资源节点的可用资源相匹配，获取nm心跳信息中的匹配容器信息，将目标资源请求、容器资源节点的可用资源以及匹配容器信息进行关联形成关联信息并存储，其中，每个资源请求对应生成一个关联信息。63.步骤225，利用am定期向rm发送am心跳信息，从rm中获取至少一个关联信息。64.步骤226，利用am从接收到的至少一个关联信息中提取对应的至少一个匹配容器信息，并根据至少一个匹配容器信息确定对应的至少一个目标容器，为至少一个目标容器分别匹配对应的资源请求，生成执行通知发送给nm。65.步骤227，nm接收到执行通知后，启动对应的至少一个目标容器，执行对应匹配的资源请求。66.在上述方案中，yarn采用的是基于pull模型的调度模型，由节点心跳触发调度，进行主动拉取调度的过程。进而确定出对应目标容器后，主动将目标容器进行拉取，利用目标容器执行对应的资源请求。通过上述方案，能够将一个调度指令划分成多个资源请求，并为各个资源请求确定对应的目标容器进行执行，这样能够有效提高调取执行的过程。67.在具体实施例中，如图6所示，步骤300具体包括：68.步骤310，将所有节点node放入待调度节点node队列中。69.步骤320，利用predicates算法对多个待调度节点进行筛选，得到至少一个候选节点。70.在该步骤中，predicates算法为谓词函数，具体使用为：输入一个对象(例如各个待调度节点)，返回true或false，可以将现在处于空闲状态，没有进行调用的一些待调度节点筛选出来，进而得到一个或者多个候选节点。避免出现，调取正在执行的节点，这样可能会出现调度失败的情况。71.步骤330，利用priorities算法对各个候选节点进行评分。72.priorities算法为优先级算法，在进行评分过程中，可以预先在priorities算法中将对应的评分项以及各个评分项对应的权重值，在priorities算法中设置好，如cpu和内存资源的平衡性的权重为1，节点上是否存在pod所需镜像的权重为2。然后根据priorities算法中预先设置的内容，对各个候选节点进行评分。评分越高对应的调取过程的执行效力越强。73.步骤340，确定调度指令为容器集群pod的调度指令，且容器集群pod此前未被调度过或者容器集群pod此前被调度的节点不在至少一个候选节点中，则利用kubernetes调度器将评分最高的候选节点作为目标节点node。74.步骤350，将目标节点node与容器集群pod的调度指令进行关联，利用目标节点node执行容器集群pod的调度指令。75.在上述方案中，将kubernetes的调度流程分为预选和优选两阶段，在预选阶段过滤掉不满足要求的节点，优选阶段对剩余节点评分，最后选择评分最高的节点作为调度目标。这样，能够保证得到的目标节点node对容器集群pod的调度指令的执行效力。76.在具体实施例中，方法还包括：77.对调度指令的执行过程进行监控，若执行过程中发生异常，生成报警信息进行报警提示。78.在利用yarn调度器和/或kubernetes调度器进行调度执行过程中，需要进行不断的监控，如果执行过程发生异常则进行报警，另外还可以按照上述过程重新确定对应的目标容器或者目标节点node，利用重新确定的目标容器或者目标节点node进行继续执行，这样在进行报警提示的同时，还能保证调度过程的顺利进行。79.需要说明的是，本公开实施例的方法可以由单个设备执行，例如一台计算机或服务器等。本实施例的方法也可以应用于分布式场景下，由多台设备相互配合来完成。在这种分布式场景的情况下，这多台设备中的一台设备可以只执行本公开实施例的方法中的某一个或多个步骤，这多台设备相互之间会进行交互以完成所述的方法。80.需要说明的是，上述对本公开的一些实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于上述实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。81.基于同一发明构思，与上述任意实施例方法相对应，本公开提出了一种基于yarn和kubernetes的容器化双层调度系统，用以执行上述实施例中描述的基于yarn和kubernetes的容器化双层调度方法。方法和系统两部分是相辅相成的，两部分的内容和对应的实现效果均可互相参考。82.如图7所示，系统包括：调度模块和功能模块；83.调度模块包括：84.yarn调度器，用于确定接收到的调度指令为应用程序的调度指令，且应用程序的调度指令没有对应匹配的休眠容器，则为应用程序的调度指令分配对应的目标容器，利用目标容器与功能模块进行配合执行应用程序的调度指令；85.kubernetes调度器，用于确定接收到的调度指令为容器集群pod的调度指令，且容器集群pod此前未被调度过，则为容器集群pod的调度指令分配对应的目标节点node，利用目标节点node与功能模块进行配合执行容器集群pod的调度指令。86.如图8所示，功能模块包括用于提供镜像存储功能的dockerregistry(镜像存储模块)、用于提供数据可视化功能的zeppelin(数据可视化模块)、用于提供集群监控功能的cadvisor(集群监控模块)和用于支持容器调度记忆功能的hashtable(哈希表)。关于它们各自的功能阐述具体如下：87.(1)dockerregistry88.docker的镜像仓库主要分为共有镜像仓库和私有镜像仓库两种，而使用私有仓库在节省网络带宽以及提高镜像下载速度方面更具优势。因此将常用的docker镜像直接存储在dockerregistry中，当需要创建新的pod副本时，replicationcontroller可以直接从构建的私有dockerregistry中进行快速拉取镜像。89.(2)zeppelin90.面临海量异构数据的处理，由于很难在短时间内反馈数据变化的规律及处理结果，而利用数据可视化工具可以辅助进行该处理过程。目前的大数据引擎如spark、hadoop等均无法提供数据可视化功能，而zeppelin作为一个基于网页的数据可视化开源框架，能够提供数据分析、数据可视化等功能。通过构建一个zeppelin镜像，并在kubernetes中运行该镜像并生成一个zeppelinclient，然后用户将应用程序通过zeppelinclient提交到zeppelinserver中，然后再通过多种interpreter将上层提交的应用程序翻译为归属于不用引擎的任务在集群中运行，并将结果反馈到webui上进行可视化呈现。91.(3)cadvisor92.利用容器来实现海量异构数据环境下的资源调度时，相比于虚拟机，容器的最大优势在于其足够轻量化。通过大量轻量级的容器协同作业，可以完成一系列数据存储、任务分配、资源调度等功能，而为了保证这些过程有条不紊地进行，需要对容器集群进行监控。docker虽然自带了容器监控功能，可以监控相关的性能和指标，如主机cpu、内存、本地镜像、容器运行等情况，但docker自带的监控功能只能对单个主机进行监控，而要扩展到整个集群的监控，还需要额外使用其它监控工具，如开源软件cadvisor。cadvisor记录每个容器的资源使用情况和性能指标信息，并以直方图的形式呈现在webui上供用户查看。93.(4)hashtable94.通过哈希表的辅助支持，可以避免重复的pod被调度到不同的节点，进而避免容器镜像被重复下载，从而可以节约磁盘空间和网络资源，并缩短一定的调度时间，使集群中各节点资源利用更加均衡，换言之，哈希表的作用赋予了容器集群一定的调度记忆功能。具体而言，通过查找哈希表中某个pod在以前是否被创建和调度过，若该pod之前被调度过且以前调度的节点同时也在预选阶段的剩余节点中，则直接将新pod绑定到该节点；若该pod是一个新建的pod，则通过节点评分后进行调度。95.在具体实施例中，yarn调度器包括：96.应用管理器am，用于根据接收到的应用程序的调度指令生成对应的至少一个资源请求，并将至少一个资源请求发送给资源管理器rm；97.节点管理器nm，用于生成对应的nm心跳信息发送给资源管理器rm；98.资源管理器rm，用于接收到nm发送的nm心跳信息后，根据nm心跳信息为至少一个资源请求确定对应的至少一个目标容器，利用至少一个目标容器执行至少一个资源请求。99.在具体实施例中，kubernetes调度器包括：100.kubernetes控制模块(即，图8中kubernetesmaster)，用于对kubernetes节点模块中各个容器集群pod进行运行控制；101.kubernetes节点模块(即，图8中kubernetesnode)，包括：kubelet组件、proxy组件和各个容器集群pod，kubelet组件和proxy组件分别与对应的容器集群pod进行关联，利用kubelet组件和proxy组件管理对应的容器集群pod的生命周期。102.如图8所示的调度模块中的kubernetesmaster和kubernetesnode共同构成了kubernetes的总体框架(主从分布式框架)。其中pod是kubernetes的最基本操作单元，其本质上是若干个相关的、紧耦合的docker容器封装而成的容器集群，pod的生命周期由replicationcontroller管理。103.在kubernetesmaster上运行了replicationcontroller(复制控制器)、scheduler(kubernetes的调度程序)、apiserver(服务器接口)、etcd(存储系统)、webui(网络图形用户界面)和kubectl六个组件。104.replicationcontroller负责控制pod的副本数目与设定数目始终一致。105.scheduler指kubernetes自带的调度器，具体kubernete进行调度的过程详见上述实施例中步骤310‑步骤350的描述。106.apiserver是kubernetes系统的入口，通过将核心对象的增删改查操作以接口方式提供给外部客户和内部组件调用，并将维护的对象信息持久化到etcd中。107.etcd是一个高可用的键值对存储系统。108.webui是一个基于web的kubernetes图形化用户界面。109.kubectl是kubernetes的命令行工具，通过一些语法命令可以对集群中的资源对象进行管理操作。110.在kubernetesnode上运行了kubelet和proxy两个组件，负责管理各自节点上pod的生命周期。其中kubelet负责监控容器运行状态并定期向apiserver汇报节点上pod运行状态；proxy提供服务代理功能，负责为pod创建代理服务，通过从apiserver获取所有server信息并据此创建代理服务，来实现server到pod的请求路由和转发。111.hadoop(分布式系统)和spark(计算引擎)是大数据并行计算系统，均采用主从式结构，即，图8和图9中的hadoopmaster为分布式主容器，hadoopslave为分布式从属容器，sparkmaster为计算引擎主容器，sparkslave为计算引擎从属容器。112.flannel是一种网络通信解决方案，其通过创建一个覆盖网络，可以协助kubernetes为每个容器分配不同的、互不冲突的ip地址，从而实现容器之间的跨主机通信。113.yarn中的scheduler指yarn的调度程序。具体调度过程如步骤211‑步骤213和步骤221‑步骤227对应的yarn调度过程。114.采取yarn和kubernetes结合的双层调度架构如图9所示。通过kubernetes和yarn双层调度框架，让kubernetes进行节点级别的资源调度，yarn来负责任务级别的资源调度，能够同时利用kubernetes与yarn的优势，使整个架构的资源调度更加合理高效。图9中yarn中的scheduler为yarn的调度程序，kubernetes中的scheduler为kubernetes的调度程序。115.为了描述的方便，描述以上装置时以功能分为各种模块分别描述。当然，在实施本公开时可以把各模块的功能在同一个或多个软件和/或硬件中实现。116.上述实施例的装置用于实现前述任一实施例中相应的基于yarn和kubernetes的容器化双层调度方法，并且具有相应的方法实施例的有益效果，在此不再赘述。117.基于同一发明构思，与上述任意实施例方法相对应的，本公开还提供了一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上任意一实施例所述的基于yarn和kubernetes的容器化双层调度方法。118.图10示出了本实施例所提供的一种更为具体的电子设备硬件结构示意图，该设备可以包括：处理器1010、存储器1020、输入/输出接口1030、通信接口1040和总线1050。其中处理器1010、存储器1020、输入/输出接口1030和通信接口1040通过总线1050实现彼此之间在设备内部的通信连接。119.处理器1010可以采用通用的cpu(centralprocessingunit，中央处理器)、微处理器、应用专用集成电路(applicationspecificintegratedcircuit，asic)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本说明书实施例所提供的技术方案。120.存储器1020可以采用rom(readonlymemory，只读存储器)、ram(randomaccessmemory，随机存取存储器)、静态存储设备，动态存储设备等形式实现。存储器1020可以存储操作系统和其他应用程序的调度指令，在通过软件或者固件来实现本说明书实施例所提供的技术方案时，相关的程序代码保存在存储器1020中，并由处理器1010来调用执行。121.输入/输出接口1030用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。122.通信接口1040用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如usb、网线等)实现通信，也可以通过无线方式(例如移动网络、wifi、蓝牙等)实现通信。123.总线1050包括一通路，在设备的各个组件(例如处理器1010、存储器1020、输入/输出接口1030和通信接口1040)之间传输信息。124.需要说明的是，尽管上述设备仅示出了处理器1010、存储器1020、输入/输出接口1030、通信接口1040以及总线1050，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本说明书实施例方案所必需的组件，而不必包含图中所示的全部组件。125.上述实施例的电子设备用于实现前述任一实施例中相应的基于yarn和kubernetes的容器化双层调度方法，并且具有相应的方法实施例的有益效果，在此不再赘述。126.基于同一发明构思，与上述任意实施例方法相对应的，本公开还提供了一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储计算机指令，所述计算机指令用于使所述计算机执行如上任一实施例所述的基于yarn和kubernetes的容器化双层调度方法。127.本实施例的计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd‑rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。128.上述实施例的存储介质存储的计算机指令用于使所述计算机执行如上任一实施例所述的基于yarn和kubernetes的容器化双层调度方法，并且具有相应的方法实施例的有益效果，在此不再赘述。129.所属领域的普通技术人员应当理解：以上任何实施例的讨论仅为示例性的，并非旨在暗示本公开的范围(包括权利要求)被限于这些例子；在本公开的思路下，以上实施例或者不同实施例中的技术特征之间也可以进行组合，步骤可以以任意顺序实现，并存在如上所述的本公开实施例的不同方面的许多其它变化，为了简明它们没有在细节中提供。130.另外，为简化说明和讨论，并且为了不会使本公开实施例难以理解，在所提供的附图中可以示出或可以不示出与集成电路(ic)芯片和其它部件的公知的电源/接地连接。此外，可以以框图的形式示出装置，以便避免使本公开实施例难以理解，并且这也考虑了以下事实，即关于这些框图装置的实施方式的细节是高度取决于将要实施本公开实施例的平台的(即，这些细节应当完全处于本领域技术人员的理解范围内)。在阐述了具体细节(例如，电路)以描述本公开的示例性实施例的情况下，对本领域技术人员来说显而易见的是，可以在没有这些具体细节的情况下或者这些具体细节有变化的情况下实施本公开实施例。因此，这些描述应被认为是说明性的而不是限制性的。131.尽管已经结合了本公开的具体实施例对本公开进行了描述，但是根据前面的描述，这些实施例的很多替换、修改和变型对本领域普通技术人员来说将是显而易见的。例如，其它存储器架构(例如，动态ram(dram))可以使用所讨论的实施例。132.本公开实施例旨在涵盖落入所附权利要求的宽泛范围之内的所有这样的替换、修改和变型。因此，凡在本公开实施例的精神和原则之内，所做的任何省略、修改、等同替换、改进等，均应包含在本公开的保护范围之内。当前第1页12当前第1页12
技术领域：
：1.本公开涉及应用调度处理
技术领域：
：，尤其涉及一种基于yarn和kubernetes的容器化双层调度方法及系统。
背景技术：
：：2.边缘计算为电网的数据处理及区域自治提供了重要技术手段，随着电力通信业务多样性的增强以及便携式终端的普及，存在海量的异构数据(如语音、视频、图像等数据)接入边缘网络，而有限的边缘网络资源与海量异构数据的实时高效处理需求之间的矛盾日益突出。轻量级容器作为一种新型虚拟化技术，具有启动速度快、接近物理主机性能、资源利用率高等特性。由于容器通过与宿主机共享操作系统内核的方式实现了进程级别的虚拟化，在运行不同的应用程序的调度指令时只需要启动多个进程隔离的容器即可。3.现有技术中使用容器编排引擎对容器进行调度处理，应用最广泛的是kubernetes，kubernetes使用两阶段算法选取最大评分节点来实现容器资源调度。4.但是，kubernetes默认的调度机制只能完成节点级别的调度，并不能完成任务级别的调度，这很难适应海量异构数据调度的业务场景。技术实现要素：5.有鉴于此，本公开的目的在于提出一种能够解决或者部分解决上述问题的基于yarn和kubernetes的容器化双层调度方法及系统。6.基于上述目的，本公开的第一方面提出了一种基于yarn和kubernetes的容器化双层调度方法，包括：7.接收调度指令，对调度指令进行类别确定；8.确定所述调度指令为应用程序的调度指令，且所述应用程序的调度指令没有对应匹配的休眠容器，则利用yarn调度器为所述应用程序的调度指令分配对应的目标容器，利用所述目标容器执行所述应用程序的调度指令；9.确定所述调度指令为容器集群pod的调度指令，且所述容器集群pod此前未被调度过，则利用kubernetes调度器为所述容器集群pod的调度指令分配对应的目标节点node，利用所述目标节点node执行所述容器集群pod的调度指令。10.基于上述目的，本公开的第二方面提出了一种基于yarn和kubernetes的容器化双层调度系统，包括：调度模块和功能模块；11.所述调度模块包括：12.yarn调度器，用于确定接收到的调度指令为应用程序的调度指令，且所述应用程序的调度指令没有对应匹配的休眠容器，则为所述应用程序的调度指令分配对应的目标容器，利用所述目标容器执行所述应用程序的调度指令；13.kubernetes调度器，用于确定接收到的调度指令为容器集群pod的调度指令，且所述容器集群pod此前未被调度过，则为所述容器集群pod的调度指令分配对应的目标节点node，利用所述目标节点node执行所述容器集群pod的调度指令。14.从上面所述可以看出，本公开提供的基于yarn和kubernetes的容器化双层调度方法及系统，能够同时利用yarn和kubernetes的优势，实现任务级别的应用程序的调度指令和节点级别的容器集群pod的调度指令，进行并行统一调度，这样能够降低部署成本，提高容器资源利用率，使得容器资源利用更加合理，同时还能提高调度效率。附图说明15.为了更清楚地说明本公开或相关技术中的技术方案，下面将对实施例或相关技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本公开的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。16.图1为本公开实施例的基于yarn和kubernetes的容器化双层调度方法的流程图；17.图2为本公开实施例的基于yarn和kubernetes的容器化双层调度方法中步骤100的展开流程图；18.图3为本公开实施例的基于yarn和kubernetes的容器化双层调度方法中步骤200的展开流程图；19.图4为本公开实施例的基于yarn和kubernetes的容器化双层调度方法中步骤210的展开流程图；20.图5为本公开实施例的基于yarn和kubernetes的容器化双层调度方法中步骤220的展开流程图；21.图6为本公开实施例的基于yarn和kubernetes的容器化双层调度方法中步骤300的展开流程图；22.图7为本公开实施例的基于yarn和kubernetes的容器化双层调度系统的结构框图；23.图8为本公开实施例的基于yarn和kubernetes的容器化双层调度系统的组成架构图；24.图9为本公开实施例的yarn调度器和kubernetes调度器对应调度的架构图；25.图10为本公开实施例的电子设备的硬件结构示意图。具体实施方式26.为使本公开的目的、技术方案和优点更加清楚明白，以下结合具体实施例，并参照附图，对本公开进一步详细说明。27.需要说明的是，除非另外定义，本公开实施例使用的技术术语或者科学术语应当为本公开所属领域内具有一般技能的人士所理解的通常意义。本公开实施例中“包括”或者“包含”等类似的词语意指出现该词前面的元件或者物件涵盖出现在该词后面列举的元件或者物件及其等同，而不排除其他元件或者物件。28.在边缘环境中需要利用一种轻量型的高效数据处理和资源调度机制来保证海量异构数据调度业务的实时性。轻量级容器作为一种新型虚拟化技术，具有启动速度快、接近物理主机性能、资源利用率高等特性。由于容器通过与宿主机共享操作系统内核的方式实现了进程级别的虚拟化，在运行不同的应用程序的调度指令时只需要启动多个进程隔离的容器即可。而无需像虚拟机那样为每个应用程序的调度指令重新加载一个从操作系统并为其分配单独的cpu、内存、磁盘等。29.因此对于海量异构数据处理场景而言，容器相比于虚拟机在启动时间、资源利用率、资源消耗情况、系统性能等方面具有显著的优势。将容器应用于资源调度时，其核心思想是通过合适的调度策略将封装大数据处理应用的容器均分到物理服务器上，从而优化吞吐率，提高存储与处理效率。30.目前有三大主流的容器编排引擎：dockerswarm、apachemesos以及googlekubernetes，其中应用最广泛的是kubernetes。kubernetes使用两阶段算法选取最大评分节点来实现容器资源调度，然而kubernetes默认的调度机制只能完成节点级别的调度，并不能完成任务级别的调度，这很难适应海量异构数据调度的业务场景。此外还有很多学者利用启发式算法将资源调度问题建模为多目标优化问题来求解，然而，其中有些方案并没有利用到容器本身的轻量高效特性。31.相关技术中，利用延迟因子与动态权重的多资源指标node匹配，可以实现针对不同类型资源的云计算任务的高效资源调度，从而保证了云计算任务及时响应并实现了各资源之间负载均衡。但是，这种方式并未考虑容器本身的轻量高效、资源可重复利用等特性，在部署成本、调度等待时延、资源利用率方面存在一定的缺陷。32.相关技术中，利用kubernetes资源调度时，部署集群环境，将多节点评定为高、中、低等级；当资源充足时，将新pod调度到高等级节点资源上运行；当高等级节点资源不足时，将新pod依据节点等级由高到低的顺序把资源调度到中等级节点运行；当遍历所有节点均产生资源不足的情况时，判断高等级节点上已运行的原有pod，并对原有pod进行等级分级评定，动态删减低等级原有pod已分配的资源，释放部分资源；然后高等级节点回收释放的资源，并整合节点上剩余的资源，再次判断资源是否满足新pod运行，若充足则调度到该节点，若仍不足以调度新pod，当可运行到中、低等级的节点，则将原有pod从高等级节点调度到中、低等级节点上，同时释放高等级节点的资源；待高等级节点释放资源后再次遍历节点资源，判断是否达到新pod运行的资源条件，若满足则调度到此时的高等节点上，若不满足则继续动态删减节点来释放资源，直到节点有足够资源运行。该方法最主要解决了面临资源不足时，在不清除pod的前提下，合理进行资源调度的问题。但该这种方案的适用场景较为有限，例如面向大数据实时性处理场景下，这种方案较为复杂的动态删减整合资源的方式可能无法满足许多数据业务要求的低时延、高效率指标。33.相关技术中，基于分布式部署的任务调度过程中，协调主机作为分布式架构的协调器，负责监控调度主机和执行主机的健康状态，并完成高可用调度主机的选举；调度主机作为分布式架构的主节点，负责接收数据处理作业并对执行节点进行任务调度；执行主机作为分布式架构的从节点，负责接收调度主机派发的任务并执行，在执行完毕后向调度主机反馈执行结果；调度主机至少建立2个，其中一个作为实际运行并提供任务调度的主用实例，另一个或多个作为备用实例；协调主机能够根据调度主机的健康状态选择高可用的备用实例切换为主用实例；调度主机能够将上一次派发失败或执行失败的任务重新进行任务调度。这种实现方案，虽然利用分布式集群环境和主备机制能够防止单点故障并提高作业执行效率，但是，在面临海量异构数据的处理任务时可能达不到低时延需求。34.本公开设计了一种基于yarn和kubernetes的容器化双层调度方法和系统，能够同时利用yarn和kubernetes的优势，实现任务级别的应用程序的调度指令和节点级别的容器集群pod的调度指令的统一调度，此外还利用了容器本身的轻量高效特性，考虑了容器的调度记忆功能以及容器资源的重复利用概率，降低了部署成本，提高了中断响应的速率，从而使整合后的调度架构的资源利用更合理、更高效。35.如图1所示，本实施例提出的基于yarn和kubernetes的容器化双层调度方法，包括：36.步骤100，接收调度指令，对调度指令进行类别确定。37.步骤200，确定调度指令为应用程序的调度指令，且应用程序的调度指令没有对应匹配的休眠容器，则利用yarn调度器为应用程序的调度指令分配对应的目标容器，利用目标容器执行应用程序的调度指令。38.步骤300，确定调度指令为容器集群pod的调度指令，且容器集群pod此前未被调度过，则利用kubernetes调度器为容器集群pod的调度指令分配对应的目标节点node，利用目标节点node执行容器集群pod的调度指令。39.在上述步骤中，接收到调度指令的请求之后，首先确定该调度指令是属于应用程序的调度指令，还是属于容器集群pod的调度指令。针对应用程序的调度指令，一个或多个容器就可以执行，利用yarn调度器进行调度。针对容器集群pod的调度指令可能需要一个或多个目标节点node来执行，这里利用kubernetes调度器进行调度。其中，pod指对应的容器集群。40.进而分别利用yarn调度器或kubernetes调度器进行对应的任务分配，完成对应的调度指令。其中，yarn调度器和kubernetes调度器能够进行并行处理，二者并不互相影响。41.通过上述方案，能够同时利用yarn和kubernetes的优势，实现任务级别的应用程序的调度指令和节点级别的容器集群pod的调度指令，进行并行统一调度，这样能够降低部署成本，提高容器资源利用率，使得容器资源利用更加合理，同时还能提高调度效率。42.在具体实施例中，如图2所示，步骤100具体包括：43.步骤110，接收调度指令。44.步骤120，判断调度指令是否为初始调度，是则进入步骤130，否则进入步骤140。45.步骤130，为至少一个容器进行任务初始化配置，以及为至少一个容器集群pod进行节点初始化配置后，进入步骤140。46.步骤140，对调度指令进行类别确定。47.通过上述方案，如果调度指令是初始调度，则需要将容器初始化分配给不同的任务，并将pod初始化分配到各节点上，再对调度指令的类别进行确定。这样能够保证后续调度过程的顺利进行。48.在具体实施例中，yarn调度器包括：应用管理器am、资源管理器rm和节点管理器nm。49.则步骤200中的利用yarn调度器为应用程序的调度指令分配对应的目标容器，利用目标容器执行应用程序的调度指令，如图3所示，具体包括：50.步骤210，利用am根据接收到的应用程序的调度指令生成对应的至少一个资源请求，并将至少一个资源请求发送给rm。51.步骤220，利用rm接收nm发送的nm心跳信息后，根据nm心跳信息为至少一个资源请求确定对应的至少一个目标容器，利用至少一个目标容器执行至少一个资源请求，其中，资源请求与目标容器一一对应。52.在上述方案中，一个调度指令可能需要一个或多个目标容器来完成调用过程，通过am、rm和nm的配合能够确定出完成该调度指令的各个目标容器，进而利用各个目标容器来完成调度的过程。在yarn调度机制中，资源分配过程是异步的，也就是说，当资源管理器(rm)接收到来自应用管理器(am)的资源请求时，并不会立即对该资源请求进行分配，而是等到rm收到来自节点管理器(nm)发送的心跳信息时，通过判断是否有资源请求能够被调度到该心跳节点的方式来实现资源调度。53.在具体实施例中，如图4所示，步骤210具体包括：54.步骤211，接收到客户端提交给rm的应用程序的调度指令。55.步骤212，根据客户端提交给rm的应用程序的调度指令，匹配启动am的启动容器，并利用启动容器启动am。56.步骤213，利用am将应用程序的调度指令划分为至少一个任务，为每个任务生成对应的资源请求，并将至少一个资源请求发送至rm。57.在上述方案中，具体启动am的启动容器是am和rm进行协商后获取的。该启动容器为第一个容器。然后am启动之后利用am将应用程序的调度指令进行任务划分，对应生成相应的资源请求。58.在具体实施例中，如图5所示，步骤220具体包括：59.步骤221，利用nm定期向rm发送nm心跳信息。其中，nm心跳信息中包含：容器资源节点的可用资源，以及可用容器资源节点的对应容器信息。60.步骤222，利用rm接收到容器资源节点的心跳信息时，会向对应的调度程序发送一个更新节点属性事件(即，node_update事件)。61.步骤223，rm中的调度程序接收到更新节点属性事件后，调取nm心跳信息中的容器资源节点的可用资源。62.步骤224，确定至少一个资源请求中存在目标资源请求与容器资源节点的可用资源相匹配，获取nm心跳信息中的匹配容器信息，将目标资源请求、容器资源节点的可用资源以及匹配容器信息进行关联形成关联信息并存储，其中，每个资源请求对应生成一个关联信息。63.步骤225，利用am定期向rm发送am心跳信息，从rm中获取至少一个关联信息。64.步骤226，利用am从接收到的至少一个关联信息中提取对应的至少一个匹配容器信息，并根据至少一个匹配容器信息确定对应的至少一个目标容器，为至少一个目标容器分别匹配对应的资源请求，生成执行通知发送给nm。65.步骤227，nm接收到执行通知后，启动对应的至少一个目标容器，执行对应匹配的资源请求。66.在上述方案中，yarn采用的是基于pull模型的调度模型，由节点心跳触发调度，进行主动拉取调度的过程。进而确定出对应目标容器后，主动将目标容器进行拉取，利用目标容器执行对应的资源请求。通过上述方案，能够将一个调度指令划分成多个资源请求，并为各个资源请求确定对应的目标容器进行执行，这样能够有效提高调取执行的过程。67.在具体实施例中，如图6所示，步骤300具体包括：68.步骤310，将所有节点node放入待调度节点node队列中。69.步骤320，利用predicates算法对多个待调度节点进行筛选，得到至少一个候选节点。70.在该步骤中，predicates算法为谓词函数，具体使用为：输入一个对象(例如各个待调度节点)，返回true或false，可以将现在处于空闲状态，没有进行调用的一些待调度节点筛选出来，进而得到一个或者多个候选节点。避免出现，调取正在执行的节点，这样可能会出现调度失败的情况。71.步骤330，利用priorities算法对各个候选节点进行评分。72.priorities算法为优先级算法，在进行评分过程中，可以预先在priorities算法中将对应的评分项以及各个评分项对应的权重值，在priorities算法中设置好，如cpu和内存资源的平衡性的权重为1，节点上是否存在pod所需镜像的权重为2。然后根据priorities算法中预先设置的内容，对各个候选节点进行评分。评分越高对应的调取过程的执行效力越强。73.步骤340，确定调度指令为容器集群pod的调度指令，且容器集群pod此前未被调度过或者容器集群pod此前被调度的节点不在至少一个候选节点中，则利用kubernetes调度器将评分最高的候选节点作为目标节点node。74.步骤350，将目标节点node与容器集群pod的调度指令进行关联，利用目标节点node执行容器集群pod的调度指令。75.在上述方案中，将kubernetes的调度流程分为预选和优选两阶段，在预选阶段过滤掉不满足要求的节点，优选阶段对剩余节点评分，最后选择评分最高的节点作为调度目标。这样，能够保证得到的目标节点node对容器集群pod的调度指令的执行效力。76.在具体实施例中，方法还包括：77.对调度指令的执行过程进行监控，若执行过程中发生异常，生成报警信息进行报警提示。78.在利用yarn调度器和/或kubernetes调度器进行调度执行过程中，需要进行不断的监控，如果执行过程发生异常则进行报警，另外还可以按照上述过程重新确定对应的目标容器或者目标节点node，利用重新确定的目标容器或者目标节点node进行继续执行，这样在进行报警提示的同时，还能保证调度过程的顺利进行。79.需要说明的是，本公开实施例的方法可以由单个设备执行，例如一台计算机或服务器等。本实施例的方法也可以应用于分布式场景下，由多台设备相互配合来完成。在这种分布式场景的情况下，这多台设备中的一台设备可以只执行本公开实施例的方法中的某一个或多个步骤，这多台设备相互之间会进行交互以完成所述的方法。80.需要说明的是，上述对本公开的一些实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于上述实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。81.基于同一发明构思，与上述任意实施例方法相对应，本公开提出了一种基于yarn和kubernetes的容器化双层调度系统，用以执行上述实施例中描述的基于yarn和kubernetes的容器化双层调度方法。方法和系统两部分是相辅相成的，两部分的内容和对应的实现效果均可互相参考。82.如图7所示，系统包括：调度模块和功能模块；83.调度模块包括：84.yarn调度器，用于确定接收到的调度指令为应用程序的调度指令，且应用程序的调度指令没有对应匹配的休眠容器，则为应用程序的调度指令分配对应的目标容器，利用目标容器与功能模块进行配合执行应用程序的调度指令；85.kubernetes调度器，用于确定接收到的调度指令为容器集群pod的调度指令，且容器集群pod此前未被调度过，则为容器集群pod的调度指令分配对应的目标节点node，利用目标节点node与功能模块进行配合执行容器集群pod的调度指令。86.如图8所示，功能模块包括用于提供镜像存储功能的dockerregistry(镜像存储模块)、用于提供数据可视化功能的zeppelin(数据可视化模块)、用于提供集群监控功能的cadvisor(集群监控模块)和用于支持容器调度记忆功能的hashtable(哈希表)。关于它们各自的功能阐述具体如下：87.(1)dockerregistry88.docker的镜像仓库主要分为共有镜像仓库和私有镜像仓库两种，而使用私有仓库在节省网络带宽以及提高镜像下载速度方面更具优势。因此将常用的docker镜像直接存储在dockerregistry中，当需要创建新的pod副本时，replicationcontroller可以直接从构建的私有dockerregistry中进行快速拉取镜像。89.(2)zeppelin90.面临海量异构数据的处理，由于很难在短时间内反馈数据变化的规律及处理结果，而利用数据可视化工具可以辅助进行该处理过程。目前的大数据引擎如spark、hadoop等均无法提供数据可视化功能，而zeppelin作为一个基于网页的数据可视化开源框架，能够提供数据分析、数据可视化等功能。通过构建一个zeppelin镜像，并在kubernetes中运行该镜像并生成一个zeppelinclient，然后用户将应用程序通过zeppelinclient提交到zeppelinserver中，然后再通过多种interpreter将上层提交的应用程序翻译为归属于不用引擎的任务在集群中运行，并将结果反馈到webui上进行可视化呈现。91.(3)cadvisor92.利用容器来实现海量异构数据环境下的资源调度时，相比于虚拟机，容器的最大优势在于其足够轻量化。通过大量轻量级的容器协同作业，可以完成一系列数据存储、任务分配、资源调度等功能，而为了保证这些过程有条不紊地进行，需要对容器集群进行监控。docker虽然自带了容器监控功能，可以监控相关的性能和指标，如主机cpu、内存、本地镜像、容器运行等情况，但docker自带的监控功能只能对单个主机进行监控，而要扩展到整个集群的监控，还需要额外使用其它监控工具，如开源软件cadvisor。cadvisor记录每个容器的资源使用情况和性能指标信息，并以直方图的形式呈现在webui上供用户查看。93.(4)hashtable94.通过哈希表的辅助支持，可以避免重复的pod被调度到不同的节点，进而避免容器镜像被重复下载，从而可以节约磁盘空间和网络资源，并缩短一定的调度时间，使集群中各节点资源利用更加均衡，换言之，哈希表的作用赋予了容器集群一定的调度记忆功能。具体而言，通过查找哈希表中某个pod在以前是否被创建和调度过，若该pod之前被调度过且以前调度的节点同时也在预选阶段的剩余节点中，则直接将新pod绑定到该节点；若该pod是一个新建的pod，则通过节点评分后进行调度。95.在具体实施例中，yarn调度器包括：96.应用管理器am，用于根据接收到的应用程序的调度指令生成对应的至少一个资源请求，并将至少一个资源请求发送给资源管理器rm；97.节点管理器nm，用于生成对应的nm心跳信息发送给资源管理器rm；98.资源管理器rm，用于接收到nm发送的nm心跳信息后，根据nm心跳信息为至少一个资源请求确定对应的至少一个目标容器，利用至少一个目标容器执行至少一个资源请求。99.在具体实施例中，kubernetes调度器包括：100.kubernetes控制模块(即，图8中kubernetesmaster)，用于对kubernetes节点模块中各个容器集群pod进行运行控制；101.kubernetes节点模块(即，图8中kubernetesnode)，包括：kubelet组件、proxy组件和各个容器集群pod，kubelet组件和proxy组件分别与对应的容器集群pod进行关联，利用kubelet组件和proxy组件管理对应的容器集群pod的生命周期。102.如图8所示的调度模块中的kubernetesmaster和kubernetesnode共同构成了kubernetes的总体框架(主从分布式框架)。其中pod是kubernetes的最基本操作单元，其本质上是若干个相关的、紧耦合的docker容器封装而成的容器集群，pod的生命周期由replicationcontroller管理。103.在kubernetesmaster上运行了replicationcontroller(复制控制器)、scheduler(kubernetes的调度程序)、apiserver(服务器接口)、etcd(存储系统)、webui(网络图形用户界面)和kubectl六个组件。104.replicationcontroller负责控制pod的副本数目与设定数目始终一致。105.scheduler指kubernetes自带的调度器，具体kubernete进行调度的过程详见上述实施例中步骤310‑步骤350的描述。106.apiserver是kubernetes系统的入口，通过将核心对象的增删改查操作以接口方式提供给外部客户和内部组件调用，并将维护的对象信息持久化到etcd中。107.etcd是一个高可用的键值对存储系统。108.webui是一个基于web的kubernetes图形化用户界面。109.kubectl是kubernetes的命令行工具，通过一些语法命令可以对集群中的资源对象进行管理操作。110.在kubernetesnode上运行了kubelet和proxy两个组件，负责管理各自节点上pod的生命周期。其中kubelet负责监控容器运行状态并定期向apiserver汇报节点上pod运行状态；proxy提供服务代理功能，负责为pod创建代理服务，通过从apiserver获取所有server信息并据此创建代理服务，来实现server到pod的请求路由和转发。111.hadoop(分布式系统)和spark(计算引擎)是大数据并行计算系统，均采用主从式结构，即，图8和图9中的hadoopmaster为分布式主容器，hadoopslave为分布式从属容器，sparkmaster为计算引擎主容器，sparkslave为计算引擎从属容器。112.flannel是一种网络通信解决方案，其通过创建一个覆盖网络，可以协助kubernetes为每个容器分配不同的、互不冲突的ip地址，从而实现容器之间的跨主机通信。113.yarn中的scheduler指yarn的调度程序。具体调度过程如步骤211‑步骤213和步骤221‑步骤227对应的yarn调度过程。114.采取yarn和kubernetes结合的双层调度架构如图9所示。通过kubernetes和yarn双层调度框架，让kubernetes进行节点级别的资源调度，yarn来负责任务级别的资源调度，能够同时利用kubernetes与yarn的优势，使整个架构的资源调度更加合理高效。图9中yarn中的scheduler为yarn的调度程序，kubernetes中的scheduler为kubernetes的调度程序。115.为了描述的方便，描述以上装置时以功能分为各种模块分别描述。当然，在实施本公开时可以把各模块的功能在同一个或多个软件和/或硬件中实现。116.上述实施例的装置用于实现前述任一实施例中相应的基于yarn和kubernetes的容器化双层调度方法，并且具有相应的方法实施例的有益效果，在此不再赘述。117.基于同一发明构思，与上述任意实施例方法相对应的，本公开还提供了一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上任意一实施例所述的基于yarn和kubernetes的容器化双层调度方法。118.图10示出了本实施例所提供的一种更为具体的电子设备硬件结构示意图，该设备可以包括：处理器1010、存储器1020、输入/输出接口1030、通信接口1040和总线1050。其中处理器1010、存储器1020、输入/输出接口1030和通信接口1040通过总线1050实现彼此之间在设备内部的通信连接。119.处理器1010可以采用通用的cpu(centralprocessingunit，中央处理器)、微处理器、应用专用集成电路(applicationspecificintegratedcircuit，asic)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本说明书实施例所提供的技术方案。120.存储器1020可以采用rom(readonlymemory，只读存储器)、ram(randomaccessmemory，随机存取存储器)、静态存储设备，动态存储设备等形式实现。存储器1020可以存储操作系统和其他应用程序的调度指令，在通过软件或者固件来实现本说明书实施例所提供的技术方案时，相关的程序代码保存在存储器1020中，并由处理器1010来调用执行。121.输入/输出接口1030用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。122.通信接口1040用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如usb、网线等)实现通信，也可以通过无线方式(例如移动网络、wifi、蓝牙等)实现通信。123.总线1050包括一通路，在设备的各个组件(例如处理器1010、存储器1020、输入/输出接口1030和通信接口1040)之间传输信息。124.需要说明的是，尽管上述设备仅示出了处理器1010、存储器1020、输入/输出接口1030、通信接口1040以及总线1050，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本说明书实施例方案所必需的组件，而不必包含图中所示的全部组件。125.上述实施例的电子设备用于实现前述任一实施例中相应的基于yarn和kubernetes的容器化双层调度方法，并且具有相应的方法实施例的有益效果，在此不再赘述。126.基于同一发明构思，与上述任意实施例方法相对应的，本公开还提供了一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储计算机指令，所述计算机指令用于使所述计算机执行如上任一实施例所述的基于yarn和kubernetes的容器化双层调度方法。127.本实施例的计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd‑rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。128.上述实施例的存储介质存储的计算机指令用于使所述计算机执行如上任一实施例所述的基于yarn和kubernetes的容器化双层调度方法，并且具有相应的方法实施例的有益效果，在此不再赘述。129.所属领域的普通技术人员应当理解：以上任何实施例的讨论仅为示例性的，并非旨在暗示本公开的范围(包括权利要求)被限于这些例子；在本公开的思路下，以上实施例或者不同实施例中的技术特征之间也可以进行组合，步骤可以以任意顺序实现，并存在如上所述的本公开实施例的不同方面的许多其它变化，为了简明它们没有在细节中提供。130.另外，为简化说明和讨论，并且为了不会使本公开实施例难以理解，在所提供的附图中可以示出或可以不示出与集成电路(ic)芯片和其它部件的公知的电源/接地连接。此外，可以以框图的形式示出装置，以便避免使本公开实施例难以理解，并且这也考虑了以下事实，即关于这些框图装置的实施方式的细节是高度取决于将要实施本公开实施例的平台的(即，这些细节应当完全处于本领域技术人员的理解范围内)。在阐述了具体细节(例如，电路)以描述本公开的示例性实施例的情况下，对本领域技术人员来说显而易见的是，可以在没有这些具体细节的情况下或者这些具体细节有变化的情况下实施本公开实施例。因此，这些描述应被认为是说明性的而不是限制性的。131.尽管已经结合了本公开的具体实施例对本公开进行了描述，但是根据前面的描述，这些实施例的很多替换、修改和变型对本领域普通技术人员来说将是显而易见的。例如，其它存储器架构(例如，动态ram(dram))可以使用所讨论的实施例。132.本公开实施例旨在涵盖落入所附权利要求的宽泛范围之内的所有这样的替换、修改和变型。因此，凡在本公开实施例的精神和原则之内，所做的任何省略、修改、等同替换、改进等，均应包含在本公开的保护范围之内。当前第1页12当前第1页12
再多了解一些
本文用于企业家、创业者技术爱好者查询，结果仅供参考。
