CN117608760A - 应用于Kubernetes的云上应用混合部署方法 - Google Patents

Abstract

本发明公开了一种应用于Kubernetes的云上应用混合部署方法，当接收到待处理应用的任务处理请求时，获取待处理应用的命名空间信息、用户信息和/或用户组信息、资源请求量以及调度参考信息；基于命名空间信息、用户信息和/或用户组信息以及预设编队规则，将待处理应用分配至预设在线应用消息队列、预设离线应用消息列队或预设spark应用消息队列中；对待处理应用，若至少一个预设任务群组存在空闲资源，基于待处理应用的资源请求量、调度参考信息以及待处理应用的队列调度策略，将待处理应用部署至目标任务群组中，以基于目标任务群组中的占位容器完成任务处理，提高了云上资源利用率，且侵入性低，部署简单、架构轻便。

Description

应用于Kubernetes的云上应用混合部署方法

技术领域

本发明涉及用户数据处理领域，尤其涉及一种应用于Kubernetes的云上应用混合部署方法。

背景技术

云计算技术不断发展，云平台已经成为越来越多企业的必然选择。随着云平台的规模越来越大，集群管理已经成为一项关键技术课题。对于集群管理来说，提高资源利用率是最重要的目标之一。随着集群规模的扩大和基础设施成本的上涨，资源利用率问题逐步突显，为降低成本，混合部署技术应运而生。混合部署技术是指云平台上的在线服务应用与离线任务部署在同一集群，共享资源、集约统筹，从而实现资源高效利用的目标。

目前，在Kubernetes的云平台中，为了实现混合部署，需要从云平台的任务调度和资源配置入手，Kubernetes默认提供了任务调度和资源配置的原生工具(Kubernetesdefault scheduler)，但原生工具的功能较为简单，不足以满足混合部署的资源利用率目标，依然存在资源利用率低的技术问题。

发明内容

本发明提供了一种应用于Kubernetes的云上应用混合部署方法，以提高云上资源利用率，且侵入性低，部署简单、架构轻便。

根据本发明的第一方面，提供了一种应用于Kubernetes的云上应用混合部署方法，应用于Kubernetes云集群中，所述方法包括：

当接收到待处理应用的任务处理请求时，获取所述待处理应用的命名空间信息、用户信息和/或用户组信息、资源请求量以及调度参考信息；其中，所述调度参考信息包括资源消耗量、资源请求时间、应用状态以及应用优先级别；

基于所述命名空间信息、用户信息和/或用户组信息以及预设编队规则，将所述待处理应用分配至预设在线应用消息队列、预设离线应用消息列队或预设spark应用消息队列中；其中，不同的消息队列对应不同的队列调度策略和不同的队列优先级别，所述调度策略与所述调度参考信息相对应；

对所述待处理应用，若至少一个预设任务群组存在空闲资源，基于所述待处理应用的资源请求量、所述调度参考信息以及待处理应用的队列调度策略，将所述待处理应用部署至目标任务群组中，以基于所述目标任务群组中的占位容器完成任务处理。

根据本发明的第二方面，提供了一种应用于Kubernetes的云上应用混合部署装置，应用于Kubernetes云集群中，该装置包括：

应用信息获取模块，用于当接收到待处理应用的任务处理请求时，获取所述待处理应用的命名空间信息、用户信息和/或用户组信息、资源请求量以及调度参考信息；其中，所述调度参考信息包括资源消耗量、资源请求时间、应用状态以及应用优先级别；

消息队列分配模块，用于基于所述命名空间信息、用户信息和/或用户组信息以及预设编队规则，将所述待处理应用分配至预设在线应用消息队列、预设离线应用消息列队或预设spark应用消息队列中；其中，不同的消息队列对应不同的队列调度策略和不同的队列优先级别，所述调度策略与所述调度参考信息相对应；

应用部署模块，用于对所述待处理应用，若至少一个预设任务群组存在空闲资源，基于所述待处理应用的资源请求量、所述调度参考信息以及待处理应用的队列调度策略，将所述待处理应用部署至目标任务群组中，以基于所述目标任务群组中的占位容器完成任务处理。

根据本发明的第三方面，提供了一种电子设备，电子设备包括：

至少一个处理器；以及与至少一个处理器通信连接的存储器；其中，存储器存储有可被至少一个处理器执行的计算机程序，计算机程序被至少一个处理器执行，以使至少一个处理器能够执行本发明任一实施例的应用于Kubernetes的云上应用混合部署方法。

根据本发明的第四方面，提供了一种计算机可读存储介质，计算机可读存储介质存储有计算机指令，计算机指令用于使处理器执行时实现本发明任一实施例的应用于Kubernetes的云上应用混合部署方法。

本发明实施例的技术方案，当接收到待处理应用的任务处理请求时，获取所述待处理应用的命名空间信息、用户信息和/或用户组信息、资源请求量以及调度参考信息；其中，所述调度参考信息包括资源消耗量、资源请求时间、应用状态以及应用优先级别；基于所述命名空间信息、用户信息和/或用户组信息以及预设编队规则，将所述待处理应用分配至预设在线应用消息队列、预设离线应用消息列队或预设spark应用消息队列中；其中，不同的消息队列对应不同的队列调度策略和不同的队列优先级别，所述调度策略与所述调度参考信息相对应；对所述待处理应用，若至少一个预设任务群组存在空闲资源，基于所述待处理应用的资源请求量、所述调度参考信息以及待处理应用的队列调度策略，将所述待处理应用部署至目标任务群组中，以基于所述目标任务群组中的占位容器完成任务处理。本实施例提供的技术方案，提高了云上资源利用率，且侵入性低，部署简单、架构轻便。

应当理解，本部分所描述的内容并非旨在标识本发明的实施例的关键或重要特征，也不用于限制本发明的范围。本发明的其它特征将通过以下的说明书而变得容易理解。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是根据本发明实施例一涉及的企业服务部署示意图；

图2是根据本发明实施例一提供的一种应用于Kubernetes的云上应用混合部署方法的流程图；

图3是根据本发明实施例一涉及的目标调度代理插件在Kubernetes云集群上的部署示意图；

图4是根据本发明实施例一涉及的应用状态的转移关系示意图；

图5是根据本发明实施例二提供的一种应用于Kubernetes的云上应用混合部署装置的结构示意图；

图6是实现本发明实施例的应用于Kubernetes的云上应用混合部署方法的电子设备的结构示意图。

具体实施方式

为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

在介绍本发明实施例提供的技术方案之前，可以先对本方案的具体应用场景进行示例性说明。

企业服务部署示意图参见图1，企业的IT环境通常运行两大类进程，一类是在线服务，一类是离线作业。在线服务的运行时间长，服务流量及资源利用率有潮汐特征，时延敏感，对服务水平和质量要求相对较高，如消息流Feed服务、电商交易服务等。离线作业的运行时间分区间，运行期间资源利用率较高，时延不敏感，容错率高，中断一般允许重运行，如Hadoop生态下的MapReduce、Spark作业。因为在线服务资源利用率有更明显的起伏特征，所以混部的主要场景是通过填充离线作业把在线服务各个时段的空闲资源利用起来，减少企业基础设施的成本开支。

为了更直观地了解混合部署的成本价值，接下来以一个具体的示例进行说明。以某一中小型企业基础设施为例，其云服务器集群包括4核8G的节点1000个，相当于计算资源4000核8000G。在一般的分离部署场景下，由于资源潮汐利用的不均衡，平均每台机器的资源使用率是10％，那么实际使用的计算资源是4000*10％＝400核，8000*10％＝800G。如果混合部署将资源利用率提升20％，那么只需要500台机器即可。假设CPU的平均价格是300元/核/年，内存的平均价格是180元/G/年，就可以节省2000*300+4000*180＝132万元/年，由此可见，成本节省可观。

在离线混部虽然有明显的成本价值，但目前落地到实际应用的还是一些头部互联网企业。究其原因，主要是在离线混部涉及多方面底层问题，缺乏较为轻便易用的、适用于小规模组织的解决方案。具体来说，这几方面关键的技术问题一是调度决策，调度问题是决定混部效果的核心，目前主要有几种决策方式，如整机分时复用，在固定的时间点(比如凌晨以后)跑离线作业，白天让出资源给在线服务。这种以时间维度切分的混部方式比较简单易理解，但整体资源利用率提升有限。还有资源部分共享：将单机的资源整体划分为在线资源、离线资源以及在离线共享资源，各资源之间隔离，提前划分预留。这种从单机资源维度切分的混部方式比分时复用相对更精细一些，但是需要资源规格较大的机器切分才有意义。另外还有资源完全共享的方式，通过及时准确的资源预测手段、快速响应资源变化的能力，以及一套可以在资源水位发生变化时的服务保障措施，更高效自动化地实现机器资源复用。二是资源隔离，容器的本质是一个受限制的进程，以Kubernetes为例，进程之间通过命名空间做隔离，通过cgroups限制资源。但这种方式不利于混合部署的资源共享，例如在CPU方面，为了保证在线服务稳定性，将在线服务绑定在某个逻辑核心上避免其他业务占用。混合部署的集群属于底层架构，需要对应用透明，因此混合部署须在保证资源隔离的前提下实现。三是冲突解决，在线服务和离线作业属于不同的工作类型，将这两种负载部署在同一个节点上，会出现资源干扰，当资源紧张或者流量突发的时候，在线服务在资源使用上会受到离线作业的干扰。在离线混部最重要的目标，就是在保障在线服务和离线作业的服务水平和质量的同时，最大限度提高单机资源利用率。针对在线服务，需要尽量保证其服务在流量高峰时期，混部前后的指标波动控制在5％之内；针对离线作业，不能因为优先级不如在线服务，就一直处于饥饿或者频繁驱逐状态，影响离线作业总的运行时间和服务水平和质量。要解决上面这些关键技术问题，需要在云原生底座上的平台级支持，但重构平台的技术要求很高，是一种昂贵的解决方案。为此，可以将注意力只集中在调度环节上，通过较为简便但健壮、通用的管理策略实现一种适配绝大多数在线、离线应用的混合部署方法。

实施例一

图2是本发明实施例一提供的一种应用于Kubernetes的云上应用混合部署方法的流程图，本实施例可适用于在Kubernetes集群中进行线上应用和线下应用混合部署的情形，该方法可以由应用于Kubernetes的云上应用混合部署装置来执行，该应用于Kubernetes的云上应用混合部署装置可以采用硬件和/或软件的形式实现，该应用于Kubernetes的云上应用混合部署装置可配置于终端和/或服务器中。

在本实施例中，应用于Kubernetes的云上应用混合部署方法是在Kubernetes集群上进行的，Kubernetes集群中可以包括至少一个在线应用和至少一个离线应用。所谓在线应用即为：与用户实时发生交互，一般在日间甚至全天候运行。在线应用运行时间长，服务流量及资源利用率有潮汐特征(如夜间访问量较低)，对时延敏感，对服务SLA要求高，常见的在线应用有消息流服务、电商交易服务、一般的网站服务等。所谓离线应用即为：以某一计算任务为目标，运行后生产具体的数据结果，运行完成后即释放资源。离线任务的运行时间一般分区间，运行期间资源利用率较高，时延不敏感，容错率高，中断一般允许重运行，如Hadoop生态下的MapReduce、Spark作业。所谓混合部署即为：由于在线应用与离线任务在资源需求、运行状态等方面上的先天区别，大部分企业一般会将在线机房和离线机房分别部署，这样不同集群间的在、离线应用没有统一调度，资源池也不互通共享。混合部署技术是专门针对这一情况所提出的统一调度、资源共享的方法，为大规模集群提升资源利用率、降低成本提供了一种最为有效的解决方案。

在本实施例中，本方案S110-S130的步骤可以通过目标调度代理插件实现，目标调度代理插件可以为Yunikorn轻量级通用资源调度器。Yunikorn是一种应用较为广泛、功能较为成熟的轻量级通用资源调度器，这种资源调度器适用于Kubernetes集群，提供了大规模多租户云环境中的多种任务调度与资源共享功能。其中，调度器负责监测集群中的容器，并将容器调度到合适的节点上运行。调度器会依据容器的资源需求和集群中的资源容量来做出调度选择，包括与具体运行时相关的任务调度和资源分配。

在执行本方案S110步骤之前，可以先将目标调度代理插件在Kubernetes云集群上进行通用性适配。具体实现方式可以包括如下步骤：

(1)获取用于实现云上应用混合部署的目标调度代理插件，在所述Kubernetes云集群上实现目标调度代理插件的通用性适配。

在本实施例中，目标调度代理插件为Yunikorn轻量级通用资源调度器，YuniKorn是专门用于Kubernetes的调度器插件，不会影响默认的Kubernetes调度功能，只需将要混合部署的应用挂载给Yunikorn调度器代理即可。具体的适配方法包括两个环节，一是在Kubernetes集群中部署Yunikorn的代理服务，二是将应用移交给该代理负责任务调度和资源管理。具体部署关系如下图所示，将Yunikorn服务作为一般节点部署在集群中，并配置集群的调度器组件，以使用Yunikorn来代理其具体功能，目标调度代理插件在Kubernetes云集群上的部署示意图如图3所示。

在Kubernetes集群中部署Yunikorn与部署一般应用并无区别，可以直接使用官方镜像手动部署，同时Yunikorn也提供自动化支持，可以通过Helm方式自动化部署。对于手动部署这种方式，由于不同的公有云平台都提供一键式的发布方式，本方法中不再赘述，以下仅对原生Kubernetes下的手动部署作介绍：使用镜像直接部署Yunikorn即通过yaml声明文件(其中包含了镜像地址、部署参数等用户要求)输入到Kubernetes集群实现。输入接口使用kubectl命令集中的apply即可，这是一种声明式的API调用方法，能将编写在一份yaml文件中的配置直接部署为实际pod，命令格式如下所示：[kubectl apply-fyunikorn.yaml]，需要特别说明的是，如果不指定命名空间，则默认部署在default命名空间下，这与后文提到的调度器指定代理有关，需要注意。

以上是以手动部署镜像作为通用性适配前提的具体方法，除此之外可以通过Helm方式自动化部署，为了实现调度器的通用性适配，具体方法是：直接使用Yunikorn官方提供的Helm Charts文件，自动化完成环境初始化、容器启动、服务创建等一系列操作。Helm作为一种开源的Kubernetes包管理器，能在联网环境下快速查找、下载和安装软件包。命令格式如下所示：[helm install yunikorn]，默认情况下，使用这种方式将在集群中安装Yunikorn的调度器、web服务器和准入控制器等多项关联组件。尤其是其中的控制器组件，它会直接将所有流量路由到Yunikorn负责调度，这也意味着资源调度已经委托给了Yunikorn。

为了实现调度器的通用性适配，除了按照上述方法安装调度器插件，还需要将Kubernetes集群中的应用移交给这一插件代理调度。一般情况下这不需要特殊配置，因为Yunikorn能够直接调度到同一命名空间下的其他应用，但是如果所在的云环境较为复杂，涉及多租户、多命名空间的场景，则需要在具体应用中为应用指明使用Yunikorn调度代理服务，并在权限列表中为对应命名空间添加例外。在Kubernetes的原生环境中，kube-scheduler是集群的默认调度器，但kube-scheduler在设计上也允许使用自定义的调度组件替换原有的kube-scheduler。无论使用哪一个调度器，它都会负责在集群中找到一个可调度节点，并提供一系列接口用于应用的运行控制。最终由调度器将调度决定通知给kube-apiserver组件，需要交互的信息包括资源请求、软硬件限制、亲和及反亲和要求、数据局部性、负载间干扰等。对于任一具体部署到Kubernetes集群中的应用来说，按照集群规范都必须提供一份部署声明文件，在这份规范接口文件中的容器模板部分有一项scheduler属性，需要将其键值由“default-scheduler”改为“yunikorn”，以此实现该应用的调度代理转移。

(2)在所述Kubernetes云集群的标签体系中为各个应用声明与所述目标调度代理插件相对应的用户和用户组信息，以获取待处理应用的用户信息和/或用户组信息。

用户和用户组信息是调度周期中的首要信息，它用于确定作业应该提交到哪个队列。Yunikorn调度器依赖Kubernetes的Shim组件获取用户信息。在Kubernetes原生环境中，没有定义用于标识实际用户的对象，而在Yunikorn中提供了处理用户或用户组的方式，即简便地使用标签(label或annotation)声明。如果Pod中设置了用户组信息的相关标签，那么该值将自动提取到Shim中，并供Yunikorn在调度时读取。在Kubernetes的标签体系中为应用声明了Yunikorn的用户或用户组信息之后，再通过表1所示的键值配置实现用户管理。

表1实现用户管理的键值对应关系表

键	值	含义
			bypassAuth	布尔值	是否允许任何用户创建Pod并申请资源
trustControllers	布尔值	是否允许第三方控制器调度资源
			systemUsers	字符串	系统用户列表，支持正则表达式
externalUsers	字符串	外部可信用户列表，支持正则表达式
			externalGroups	字符串	外部可信用户组列表，支持正则表达式

需要特别说明的是，上述配置位于Yunikorn的config文件中，前文已经提到Yunikorn本身就是普通的应用节点，因此可以直接通过Kubernetes的kubectl工具操作，具体命令为“kubectl edit cm”。

(3)在所述Kubernetes云集群的标签体系中为各个应用声明与所述目标调度代理插件相对应的应用信息，以获取待处理应用的命名空间信息和调度参考信息。

在本实施例中，被Yunikorn代理调度的应用程序，可以在其容器声明Yaml文件中添加应用注解，与用户信息注解相同，Yunikorn调度器依赖Kubernetes的Shim组件获取这部分信息。具体格式如下：

spec:

template:

metadata:

labels:

app:应用名(所有Kubernetes应用的必填信息)

applicationId:应用名(用于Yunikorn调度器的附加注解信息)

与用户管理类似，在Kubernetes的标签体系中为应用声明了Yunikorn的应用信息之后，再通过表2所示的键值配置实现应用管理。

表2实现应用管理的键值对应关系表

键	值	含义
			applicationId	字符串	应用名，用于Yunikorn调度器的附加注解信息
disableStateAware	布尔值	是否禁用StateAware调度策略，该调度策略详见后文。
			placeholder	布尔值	是否为该应用启用占位模式，占位模式详见后文。

需要特别说明的是，上述配置位于Yunikorn的config文件中，前文已经提到Yunikorn本身就是普通的应用节点，因此可以直接通过Kubernetes的kubectl工具操作，具体命令为“kubectledit cm”。

除此之外，还可以为任何按照上述方式管理的应用配置一个动态优先级值，这允许调度程序动态地根据优先级实施调度决策。在选择要调度的应用程序时，应用程序排序策略将(默认情况下)首先调度来自高优先级应用程序的请求。

(4)在所述Kubernetes云集群中配置与所述目标调度代理插件相对应的队列参数。

Yunikorn的队列是一种树状数据结构，这种数据结构可以在逻辑上更好地映射资源管理逻辑。队列为不同的租户提供了对资源的细粒度控制，Yunikorn的监控功能也主要围绕这一队列概念来监控集群资源的使用情况，所以它是整个调度系统的核心。队列作为最主要的资源弹性配置工具，包括一系列可以根据每个租户的资源消耗需求定义弹性的参数。应用在队列中登记资源并排队，再由调度策略决定哪个应用可以首先获得资源。

具体的，调度策略包括FIFO、Fair、StateAware和Priority四种。Yunikorn调度器可以根据这些策略为任务分配相应的资源，当队列达到最大容量时，作业或任务在资源队列中按照预定策略排队等待资源释放。实践证明，这些策略赋予了用户足够强大灵活的调度能力，并且简化了管理操作。这也是队列调度相比Kubernetes默认调度器的最大优势，默认调度器中资源仅仅由命名空间的配额限制，如果命名空间下没有足够的配额就不能创建pod，并且需要复杂的逻辑(例如按条件重试等)来处理这类场景。为了实现灵活的调度目标，每个队列都可以通过如下参数管理：

1.访问控制列表：声明哪些用户可以使用该队列

2.最大应用个数：该队列下的最大可运行应用数量

3.调度策略：即FIFO、Fair、StateAware和Priority四种之一

4.优先级开关：布尔值

5.优先级：整数值，最小为0。前面在应用层面中提到的优先级控制即通过该参数实现。

6.资源默认配额：该队列的默认配额，如CPU或内存等。

7.资源最大配额：该队列的最大配额，如CPU或内存等。

8.递归子队列：该队列的子队列，其参数仍为上述七项内容。

其中，FIFO、Fair、StateAware和Priority四种调度策略提供了适用于不同场景的管理方案。

FIFO策略基于应用的创建时间调度，在对应用程序进行调度之前，检查应用的资源请求是否可以被满足，满足资源需求的应用仅根据应用程序创建时间戳进行排序。

Fair策略基于应用的资源消耗调度，在对应用程序进行排序之前，检查应用的资源请求是否可以被满足，满足资源需求的应用将根据应用程序的使用情况进行排序。应用的资源消耗包括所有已确认和未确认的资源分配，计算所有这些资源的使用量，将可用的资源平均分配给所有请求资源的应用。

StateAware策略基于应用的状态调度，在对应用程序进行排序之前，检查应用的资源请求是否可以被满足。在这一策略下，将应用的状态分为new、accepted、starting、running、completed、expired、failing、failed、rejected，这些状态的转移关系如图4所示。基于上述应用状态实现精细调度。例如已经运行的应用(running)将首先获得资源，而新晋应用(new)则会先分配一个试用容器并监控状态，再根据其状态决定后续调度。这一功能为混合部署的调度管理提供了坚实的管理基础。

Priority策略是优先级调度策略，根据应用优先级选择下一个要占用处理器的应用。

如图2所示，该方法包括：

S110、当接收到待处理应用的任务处理请求时，获取所述待处理应用的命名空间信息、用户信息和/或用户组信息、资源请求量以及调度参考信息。

其中，调度参考信息包括资源消耗量、资源请求时间、应用状态以及应用优先级别。应用状态为new、accepted、starting、running、completed、expired、failing、failed、rejected中的一种。

其中，待处理应用为即将需要基于Kubernetes云资源完成任务处理的应用。

具体的，由于Kubernetes云集群中已经部署了Yunikorn调度器，已经预先在Kubernetes云集群的标签体系中为各个应用声明与Yunikorn调度器相对应的用户和用户组信息，因此，在此依据Shim组件获取用户信息和/或用户组信息。另外，待处理应用的命名空间信息是容易获取到的。任务处理请求中携带有资源请求量、资源消耗量、资源请求时间、应用状态。应用优先级别为预先定义好的设定量，可以直接获取得到。

S120、基于所述命名空间信息、用户信息和/或用户组信息以及预设编队规则，将所述待处理应用分配至预设在线应用消息队列、预设离线应用消息列队或预设spark应用消息队列中。

其中，不同的消息队列对应不同的队列调度策略和不同的队列优先级别，所述调度策略与所述调度参考信息相对应。

在本实施例中，预先配置混合部署队列，例如，混合部署队列可以包括预设在线应用消息队列、预设离线应用消息列队和预设spark应用消息队列。

具体的，为不同的应用预先准备不同的消息队列，各个消息队列还可以包括多个子消息队列，并为各个消息队列设置动态优先级。实际部署中队列优先级的具体数值取决于队列中优先级最高的未完成请求，调度器据此动态地调整调度决策的优先级。

需要特别说明的是，对于集群中不需要纳入混合部署的应用，也可以在队列中的叶子节点上设置“application.sort.priority”属性为禁用状态，此时对应的优先级将被忽略。其他需要混合部署的应用统一按照在线应用、离线应用的分类情况，设置对应队列的优先级。不同类型的队列优先级不同(一般在线应用优先级更高)，同一类型的队列内优先级相同。以此来保证不同类型的应用按照不同优先级调度，相同类型的应用按照既有的调度策略分配资源。

还有一种混合部署中的常见场景，仅在各自应用内部按照混合部署的方式管理，此时可以通过优先级偏移量的方式加以管理。当某一个应用既有在线服务又有离线任务时，将同一应用的所有部署编组到同一队列，而不是在集群层面按照在线、离线分队。由于队列的优先级是在其所包含的最高优先级应用之上附加偏移量计算获得的，因此当为该队列中的在线任务配置偏移量时，便可为应用内部的在线应用提高调度优先级。示例性的，如果一个偏移量为5的叶子队列(这个队列用于挂载在线应用)包含两个应用程序，一个优先级为10，另一个优先级为20，队列的优先级将计算为25，如果高优先级的应用程序不再有请求，队列的优先级将下降为15。这个偏移量为5的叶子队列用于容纳在线应用，在选择要调度的子队列时，队列排序策略将首先调度这一高优先级队列的请求。

默认情况下，优先级具有全局作用域，这意味着高优先级队列将先于低优先级队列得到服务。但是对于混合部署场景，经常需要将优先级限制在队列的一个子集内。为了达到这一目标，可将子集对应的队列“priority.policy”属性设置为“fence”，这样队列的优先级将被隔离，优先级仅在该队列(及其子队列)中计算，整个队列的优先级在外部来看仅为其偏移量属性，如果未指定偏移值则为0。在常见的混合部署场景下，不同模块、不同命名空间之间可以通过这种方式来实现隔离。

在上述示例性的基础上，预设编队规则包括：第一编队规则、第二编队规则以及第三编队规则；

其中，第一编队规则为：若所述待处理应用的用户组信息为在线用户组标识，则将所述待处理应用分配至所述预设在线应用消息队列中，并基于待处理应用的用户信息再次分配至对应的子消息队列中；

第二编队规则为：若所述待处理应用的用户信息为spark用户标识，则将所述待处理应用分配至所述预设spark应用消息队列中，并基于待处理应用的命名空间信息再次分配至对应的子消息队列中；

第三编队规则为：将不满足所述第一编队规则以及所述第二编队规则的待处理应用分配至所述预设离线应用消息列队中。

基于此，S120具体包括以下步骤：

(1)判断所述待处理应用的所述命名空间信息、用户信息和/或用户组信息是否满足第一编队规则。

在本实施例中，第一编队规则至第三编队规则按顺序校验，符合规则条件则产生对应队列名以供应用使用，如果当前规则不符合就继续向下校验，直到没有任何规则可供匹配，此时不提供任何队列，应用被拒绝调度。

具体的，首先根据待处理应用的所述命名空间信息、用户信息和/或用户组信息，判断待处理应用是否满足第一编队规则，如果是，则执行步骤(2)，如果不是，则执行步骤(3)。

(2)若是，则将所述待处理应用分配至所述预设在线应用消息队列，并基于待处理应用的用户信息再次分配至对应的子消息队列中。

示例性的，待处理应用来自在线应用命名空间onlineapp，用户信息为appA，用户组为在线用户组onlineApps。由于该待处理应用的用户组为onlineApps，第一编队规则的groups正则表达式，因此按照第一编队规则分配队列。按照规则1，将待处理应用分配至预设在线应用消息队列，队列的父节点按照tag方式取自命名空间onlineapp，子节点按照user方式取自用户，因此最终队列名为root.onlineapp.appA。

(3)若否，则基于所述第二编队规则和所述第三编队规则将所述待处理应用分配至对应的预设消息队列中。

具体的，判断所述待处理应用的所述命名空间信息、用户信息和/或用户组信息是否满足第二编队规则；若是，则将所述待处理应用分配至预设spark应用消息队列中，并基于待处理应用的命名空间信息再次分配至对应的子消息队列中；若否，则基于所述第三编队规则，将所述待处理应用添加至预设离线应用消息列队。

在此举两个具体的示例，以解释步骤(3)。

示例一：待处理应用来自离线应用命名空间anyApp，用户信息为spark，用户组未指定。由于该待处理应用的用户组未指定，不符合第一编队规则的groups正则表达式，符合第二编队规则的users属性，因此按照第二编队规则分配队列。将待处理应用分配至预设spark应用消息队列中，按照第二编队规则，队列的父节点按照fixed方式命名为“root.myspace”，子节点按照tag方式取自命名空间，因此最终队列名为root.myspace.anyApp。

示例二：待处理应用来自离线待处理应用命名空间hadoopApp，用户信息为hadoop，用户组信息为离线用户组offlineApps。由于该待处理应用的用户组为offlineApps，不符合第一编队规则的groups正则表达式，也不符合第二编队规则的users属性(不是spark)，因此按照第三编队规则分配队列，将待处理应用分配至预设离线应用消息列队中，按照第三编队规则，队列直接按照fixed方式命名为“root.default”。

S130、对所述待处理应用，若至少一个预设任务群组存在空闲资源，基于所述待处理应用的资源请求量、所述调度参考信息以及待处理应用的队列调度策略，将所述待处理应用部署至目标任务群组中，以基于所述目标任务群组中的占位容器完成任务处理。

在本实施例中，在具体应用之前，预先配置预设数量的预设任务群组；其中，所述每个预设任务群组包括至少一个占位容器。

具体的，为了管理混合部署的应用资源，可以用Yunikorn的群组为单位管理，同一任务群组(对应于Yunikorn的task-group)内的应用共用一部分预留空间。在任务群组的定义中声明了预留的资源空间，Yunikorn会在启动任务时创建用于占位的容器(Yunikorn的placeholder)，确保群组内的应用得到调度。对于启用群组调度的任务，满足最小资源请求时会得到yunikorn的调度，否则任务将在队列中等待。每个资源队列分配最大数量的容器并发运行，并保证可运行任务的最小资源。为了使任务被Yunikorn识别并调度，在YAML中添加注解的内容具体参见表3。

表3在YAML中添加注解的内容

需要特别说明的是，task-group即需要被统一调度的一组应用(gang of app)，同组应用使用相同的资源方案和调度策略。以Spark任务为例，可以分为driver任务组和executor任务组。task-group的定义(即“task-groups”注解)与实际Pod格式相同，用于Yunikorn提前准备占位容器。

在本实施例中，预先配置任务群组的应用调度机制为：

(1)创建对应数量的占位容器(Placeholders)。

示例性的，两个任务组(taskGroup)，每个任务组的最小成员数量(minMember)是3，则任务(job)提交时会创建最多6个占位容器。

(2)占位容器的定义(spec)以任务组(taskGroup)为准。

(3)占位容器不消耗资源，等待群组中的应用出现后再创建实际Pod。

在本实施例中，混合部署的应用按照队列方式调度，按照任务群组方式管理资源。下面给出一个用以模拟耗时的批量离线任务，在其annotation注解中声明任务组：

/>

上述配置中的关键参数是completions为4，parallelism为2，minMember为8，即总计需要完成4次任务(completions)，最大同时并行2个任务(parallelism)。在这一规定下，同一时刻最多有两个容器并发运行。由于配置了任务组task-group的成员数量是8(minMember)，所以启动任务后由Yunikorn实际创建了8个Pod，其中两个立即开始实际运行，其余为占位容器，等待需要时提供资源。

可以理解的是，相比没有任务组机制的Kubernetes原生应用，这种方式为混合部署的各个应用预留了资源，避免倾轧和挤占。同时这一机制提高了应用完成任务后切换资源的速度，省去了新建容器的开销，可以直接在预先创建的占位容器中运行。

可选的，队列调度策略包括基于资源消耗量的第一调度策略、基于资源请求时间的第二调度策略、基于应用状态的第三调度策略以及基于应用优先级别的第四调度策略。S130具体包括以下步骤：

(1)确定所述空闲资源满足所述待处理应用的资源请求量的目标任务群组。

在本实施例中，首先要判断是否有满足待处理应用的资源请求量的空闲资源，如果没有，待处理应用只能在消息队列中等待。如果有，才可以执行处理任务。基于此，如果其中一个预设任务群组的空闲资源满足待处理应用的资源请求量，则将此预设任务群组确定为目标任务群组。

(2)若所述待处理应用的队列调度策略为第一调度策略，则当所述待处理应用的资源消耗量满足第一条件时，将所述待处理应用部署至目标任务群组中。

在本实施例中，由于已经预先为待处理应用进入的消息队列设置了调度策略，因此，在此需要根据待处理应用所位于的消息队列的队列调度策略，进行调度。

具体的，第一调度策略是基于资源消耗量的调度策略，根据待处理应用的资源消耗量是否满足第一条件，确定是否将待处理应用部署至目标任务群组中进行处理。例如，第一条件可以是已经得到与资源消耗量相对应的分配资源。

(3)若所述待处理应用的队列调度策略为第二调度策略，则当所述待处理应用的资源请求时间满足第二条件时，将所述待处理应用部署至目标任务群组中。

具体的，第二调度策略是基于资源请求时间的调度策略，根据待处理应用的资源请求时间是否满足第二条件，确定是否将待处理应用部署至目标任务群组中进行处理。例如，第二条件可以是待处理应用的资源请求时间为所在消息队列中的时间最早。

(4)若所述待处理应用的队列调度策略为第三调度策略，则当所述待处理应用的应用状态满足第三条件时，将所述待处理应用部署至目标任务群组中。

具体的，第三调度策略是基于应用状态的调度策略，根据待处理应用的应用状态是否满足第三条件，确定是否将待处理应用部署至目标任务群组中进行处理。例如，第三条件可以是待处理应用的应用状态是待处理应用所在消息队列中的设定的最先获取资源的应用状态。

(5)若所述待处理应用的队列调度策略为第四调度策略，则当所述待处理应用的应用优先级别满足第四条件时，将所述待处理应用部署至目标任务群组中。

具体的，第四调度策略是基于优先级别的调度策略，根据待处理应用优先级别确是否满足第四条件，确定是否将待处理应用部署至目标任务群组中进行处理。例如，第四条件可以是待处理应用的应用优先级别为所在消息队列中的最高优先级别。

本发明实施例的技术方案，当接收到待处理应用的任务处理请求时，获取所述待处理应用的命名空间信息、用户信息和/或用户组信息、资源请求量以及调度参考信息；其中，所述调度参考信息包括资源消耗量、资源请求时间、应用状态以及应用优先级别；基于所述命名空间信息、用户信息和/或用户组信息以及预设编队规则，将所述待处理应用分配至预设在线应用消息队列、预设离线应用消息列队或预设spark应用消息队列中；其中，不同的消息队列对应不同的队列调度策略和不同的队列优先级别，所述调度策略与所述调度参考信息相对应；对所述待处理应用，若至少一个预设任务群组存在空闲资源，基于所述待处理应用的资源请求量、所述调度参考信息以及待处理应用的队列调度策略，将所述待处理应用部署至目标任务群组中，以基于所述目标任务群组中的占位容器完成任务处理。本实施例提供的技术方案，提高了云上资源利用率，且侵入性低，部署简单、架构轻便。

实施例二

图5是本发明实施例二提供的一种应用于Kubernetes的云上应用混合部署装置的结构示意图。如图5所示，该装置包括：交互图构建模块310、搜索内容获取模块320、第一活动确定模块330、第二活动确定模块340以及目标活动确定模块350。

其中，应用信息获取模块310，用于当接收到待处理应用的任务处理请求时，获取所述待处理应用的命名空间信息、用户信息和/或用户组信息、资源请求量以及调度参考信息；其中，所述调度参考信息包括资源消耗量、资源请求时间、应用状态以及应用优先级别；

消息队列分配模块320，用于基于所述命名空间信息、用户信息和/或用户组信息以及预设编队规则，将所述待处理应用分配至预设在线应用消息队列、预设离线应用消息列队或预设spark应用消息队列中；其中，不同的消息队列对应不同的队列调度策略和不同的队列优先级别，所述调度策略与所述调度参考信息相对应；

应用部署模块330，用于对所述待处理应用，若至少一个预设任务群组存在空闲资源，基于所述待处理应用的资源请求量、所述调度参考信息以及待处理应用的队列调度策略，将所述待处理应用部署至目标任务群组中，以基于所述目标任务群组中的占位容器完成任务处理。

本发明实施例的技术方案，当接收到待处理应用的任务处理请求时，获取所述待处理应用的命名空间信息、用户信息和/或用户组信息、资源请求量以及调度参考信息；其中，所述调度参考信息包括资源消耗量、资源请求时间、应用状态以及应用优先级别；基于所述命名空间信息、用户信息和/或用户组信息以及预设编队规则，将所述待处理应用分配至预设在线应用消息队列、预设离线应用消息列队或预设spark应用消息队列中；其中，不同的消息队列对应不同的队列调度策略和不同的队列优先级别，所述调度策略与所述调度参考信息相对应；对所述待处理应用，若至少一个预设任务群组存在空闲资源，基于所述待处理应用的资源请求量、所述调度参考信息以及待处理应用的队列调度策略，将所述待处理应用部署至目标任务群组中，以基于所述目标任务群组中的占位容器完成任务处理。本实施例提供的技术方案，提高了云上资源利用率，且侵入性低，部署简单、架构轻便。

可选的，应用于Kubernetes的云上应用混合部署装置，还包括调度代理插件适配模块，包括：

通用性适配单元，用于获取用于实现云上应用混合部署的目标调度代理插件，在所述Kubernetes云集群上实现目标调度代理插件的通用性适配；

用户信息声明单元，用于在所述Kubernetes云集群的标签体系中为各个应用声明与所述目标调度代理插件相对应的用户和用户组信息，以获取待处理应用的用户信息和/或用户组信息；

应用信息声明单元，用于在所述Kubernetes云集群的标签体系中为各个应用声明与所述目标调度代理插件相对应的应用信息，以获取待处理应用的命名空间信息和调度参考信息；

队列参数配置单元，用于在所述Kubernetes云集群中配置与所述目标调度代理插件相对应的队列参数。

其中，所述目标调度代理插件为Yunikorn轻量级通用资源调度器。

可选的，所述预设编队规则包括：第一编队规则、第二编队规则以及第三编队规则；

所述第一编队规则为若所述待处理应用的用户组信息为在线用户组标识，则将所述待处理应用分配至所述预设在线应用消息队列中，并基于待处理应用的用户信息再次分配至对应的子消息队列中；

所述第二编队规则为若所述待处理应用的用户信息为spark用户标识，则将所述待处理应用分配至所述预设spark应用消息队列中，并基于待处理应用的命名空间信息再次分配至对应的子消息队列中；

所述第三编队规则为将不满足所述第一编队规则以及所述第二编队规则的待处理应用分配至所述预设离线应用消息列队中。

可选的，消息队列分配模块320，包括：

应用信息判断子模块，用于判断所述待处理应用的所述命名空间信息、用户信息和/或用户组信息是否满足第一编队规则；

在线队列分配子模块，用于若是，则将所述待处理应用分配至所述预设在线应用消息队列，并基于待处理应用的用户信息再次分配至对应的子消息队列中；

待分配子模块，用于若否，则基于所述第二编队规则和所述第三编队规则将所述待处理应用分配至对应的预设消息队列中。

可选的，待分配子模块，包括：

应用信息判断单元，用于判断所述待处理应用的所述命名空间信息、用户信息和/或用户组信息是否满足第二编队规则；

spark队列分配子模块，用于若是，则将所述待处理应用分配至预设spark应用消息队列中，并基于待处理应用的命名空间信息再次分配至对应的子消息队列中；

离线队列分配子模块，用于若否，则基于所述第三编队规则，将所述待处理应用添加至预设离线应用消息列队。

可选的，应用于Kubernetes的云上应用混合部署装置，还包括任务群组配置模块，具体用于配置预设数量的预设任务群组；其中，所述每个预设任务群组包括至少一个占位容器。

可选的，所述队列调度策略包括基于资源消耗量的第一调度策略、基于资源请求时间的第二调度策略、基于应用状态的第三调度策略以及基于应用优先级别的第四调度策略，应用部署模块330，包括：

目标任务群组确定子模块，用于确定所述空闲资源满足所述待处理应用的资源请求量的目标任务群组；

第一调度子模块，用于若所述待处理应用的队列调度策略为第一调度策略，则当所述待处理应用的资源消耗量满足第一条件时，将所述待处理应用部署至目标任务群组中；

第二调度子模块，用于若所述待处理应用的队列调度策略为第二调度策略，则当所述待处理应用的资源请求时间满足第二条件时，将所述待处理应用部署至目标任务群组中；

第三调度子模块，用于若所述待处理应用的队列调度策略为第三调度策略，则当所述待处理应用的应用状态满足第三条件时，将所述待处理应用部署至目标任务群组中；

第四调度子模块，用于若所述待处理应用的队列调度策略为第四调度策略，则当所述待处理应用的应用优先级别满足第四条件时，将所述待处理应用部署至目标任务群组中。

本发明实施例所提供的应用于Kubernetes的云上应用混合部署装置可执行本发明任意实施例所提供的应用于Kubernetes的云上应用混合部署方法，具备执行方法相应的功能模块和有益效果。

实施例三

图6示出了可以用来实施本发明的实施例的电子设备10的结构示意图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备(如头盔、眼镜、手表等)和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本发明的实现。

如图6所示，电子设备10包括至少一个处理器11，以及与至少一个处理器11通信连接的存储器，如只读存储器(ROM)12、随机访问存储器(RAM)13等，其中，存储器存储有可被至少一个处理器执行的计算机程序，处理器11可以根据存储在只读存储器(ROM)12中的计算机程序或者从存储单元18加载到随机访问存储器(RAM)13中的计算机程序，来执行各种适当的动作和处理。在RAM 13中，还可存储电子设备10操作所需的各种程序和数据。处理器11、ROM 12以及RAM 13通过总线14彼此相连。输入/输出(I/O)接口15也连接至总线14。

电子设备10中的多个部件连接至I/O接口15，包括：输入单元16，例如键盘、鼠标等；输出单元17，例如各种类型的显示器、扬声器等；存储单元18，例如磁盘、光盘等；以及通信单元19，例如网卡、调制解调器、无线通信收发机等。通信单元19允许电子设备10通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。

处理器11可以是各种具有处理和计算能力的通用和/或专用处理组件。处理器11的一些示例包括但不限于中央处理单元(CPU)、图形处理单元(GPU)、各种专用的人工智能(AI)计算芯片、各种运行机器学习模型算法的处理器、数字信号处理器(DSP)、以及任何适当的处理器、控制器、微控制器等。处理器11执行上文所描述的各个方法和处理，例如应用于Kubernetes的云上应用混合部署方法。

在一些实施例中，应用于Kubernetes的云上应用混合部署方法可被实现为计算机程序，其被有形地包含于计算机可读存储介质，例如存储单元18。在一些实施例中，计算机程序的部分或者全部可以经由ROM 12和/或通信单元19而被载入和/或安装到电子设备10上。当计算机程序加载到RAM 13并由处理器11执行时，可以执行上文描述的应用于Kubernetes的云上应用混合部署方法的一个或多个步骤。备选地，在其他实施例中，处理器11可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行应用于Kubernetes的云上应用混合部署方法。

计算系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器，又称为云计算服务器或云主机，是云计算服务体系中的一项主机产品，以解决了传统物理主机与VPS服务中，存在的管理难度大，业务扩展性弱的缺陷。

应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本发明中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本发明的技术方案所期望的结果，本文在此不进行限制。

上述具体实施方式，并不构成对本发明保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本发明的精神和原则之内所作的修改、等同替换和改进等，均应包含在本发明保护范围之内。

Claims (10)

1.一种应用于Kubernetes的云上应用混合部署方法，其特征在于，应用于Kubernetes云集群中，所述方法包括：

当接收到待处理应用的任务处理请求时，获取所述待处理应用的命名空间信息、用户信息和/或用户组信息、资源请求量以及调度参考信息；其中，所述调度参考信息包括资源消耗量、资源请求时间、应用状态以及应用优先级别；

基于所述命名空间信息、用户信息和/或用户组信息以及预设编队规则，将所述待处理应用分配至预设在线应用消息队列、预设离线应用消息列队或预设spark应用消息队列中；其中，不同的消息队列对应不同的队列调度策略和不同的队列优先级别，所述调度策略与所述调度参考信息相对应；

对所述待处理应用，若至少一个预设任务群组存在空闲资源，基于所述待处理应用的资源请求量、所述调度参考信息以及待处理应用的队列调度策略，将所述待处理应用部署至目标任务群组中，以基于所述目标任务群组中的占位容器完成任务处理。

2.根据权利要求1所述的方法，其特征在于还包括：

获取用于实现云上应用混合部署的目标调度代理插件，在所述Kubernetes云集群上实现目标调度代理插件的通用性适配；

在所述Kubernetes云集群的标签体系中为各个应用声明与所述目标调度代理插件相对应的用户和用户组信息，以获取待处理应用的用户信息和/或用户组信息；

在所述Kubernetes云集群的标签体系中为各个应用声明与所述目标调度代理插件相对应的应用信息；

在所述Kubernetes云集群中配置与所述目标调度代理插件相对应的队列参数。

3.根据权利要求2所述的方法，其特征在于，所述目标调度代理插件为Yunikorn轻量级通用资源调度器。

4.根据权利要求1所述的方法，其特征在于，所述预设编队规则包括：第一编队规则、第二编队规则以及第三编队规则；

所述第一编队规则为若所述待处理应用的用户组信息为在线用户组标识，则将所述待处理应用分配至所述预设在线应用消息队列中，并基于待处理应用的用户信息再次分配至对应的子消息队列中；

所述第二编队规则为若所述待处理应用的用户信息为spark用户标识，则将所述待处理应用分配至所述预设spark应用消息队列中，并基于待处理应用的命名空间信息再次分配至对应的子消息队列中；

所述第三编队规则为将不满足所述第一编队规则以及所述第二编队规则的待处理应用分配至所述预设离线应用消息列队中。

5.根据权利要求4所述的方法，其特征在于，所述基于所述命名空间信息、用户信息和/或用户组信息以及预设编队规则，将所述待处理应用分配至预设在线应用消息队列、预设离线应用消息列队或预设spark应用消息队列中，包括：

判断所述待处理应用的所述命名空间信息、用户信息和/或用户组信息是否满足第一编队规则；

若是，则将所述待处理应用分配至所述预设在线应用消息队列，并基于待处理应用的用户信息再次分配至对应的子消息队列中；

若否，则基于所述第二编队规则和所述第三编队规则将所述待处理应用分配至对应的预设消息队列中。

6.根据权利要求5所述的方法，其特征在于，所述基于所述第二编队规则和所述第三编队规则将所述待处理应用分配至对应的预设消息队列中，包括：

判断所述待处理应用的所述命名空间信息、用户信息和/或用户组信息是否满足第二编队规则；

若是，则将所述待处理应用分配至预设spark应用消息队列中，并基于待处理应用的命名空间信息再次分配至对应的子消息队列中；

若否，则基于所述第三编队规则，将所述待处理应用添加至预设离线应用消息列队。

7.根据权利要求1所述的方法，其特征在于，还包括：

配置预设数量的预设任务群组；其中，每个所述预设任务群组包括至少一个占位容器。

8.根据权利要求1所述的方法，其特征在于，所述队列调度策略包括基于资源消耗量的第一调度策略、基于资源请求时间的第二调度策略、基于应用状态的第三调度策略以及基于应用优先级别的第四调度策略；

所述若至少一个预设任务群组存在空闲资源，基于所述待处理应用的资源请求量、所述调度参考信息以及待处理应用的队列调度策略，将所述待处理应用部署至目标任务群组中，包括：

确定所述空闲资源满足所述待处理应用的资源请求量的目标任务群组；

若所述待处理应用的队列调度策略为第一调度策略，则当所述待处理应用的资源消耗量满足第一条件时，将所述待处理应用部署至目标任务群组中；

若所述待处理应用的队列调度策略为第二调度策略，则当所述待处理应用的资源请求时间满足第二条件时，将所述待处理应用部署至目标任务群组中；

若所述待处理应用的队列调度策略为第三调度策略，则当所述待处理应用的应用状态满足第三条件时，将所述待处理应用部署至目标任务群组中；

若所述待处理应用的队列调度策略为第四调度策略，则当所述待处理应用的应用优先级别满足第四条件时，将所述待处理应用部署至目标任务群组中。

9.一种应用于Kubernetes的云上应用部署装置，其特征在于，应用于Kubernetes云集群中，该装置包括：

应用信息获取模块，用于当接收到待处理应用的任务处理请求时，获取所述待处理应用的命名空间信息、用户信息和/或用户组信息、资源请求量以及调度参考信息；其中，所述调度参考信息包括资源消耗量、资源请求时间、应用状态以及应用优先级别；

消息队列分配模块，用于基于所述命名空间信息、用户信息和/或用户组信息以及预设编队规则，将所述待处理应用分配至预设在线应用消息队列、预设离线应用消息列队或预设spark应用消息队列中；其中，不同的消息队列对应不同的队列调度策略和不同的队列优先级别，所述调度策略与所述调度参考信息相对应；

应用部署模块，用于对所述待处理应用，若至少一个预设任务群组存在空闲资源，基于所述待处理应用的资源请求量、所述调度参考信息以及待处理应用的队列调度策略，将所述待处理应用部署至目标任务群组中，以基于所述目标任务群组中的占位容器完成任务处理。

10.一种电子设备，其特征在于，所述电子设备包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的计算机程序，所述计算机程序被所述至少一个处理器执行，以使所述至少一个处理器能够执行权利要求1-8中任一项所述的应用于Kubernetes的云上应用混合部署方法。