CN117176818A - 云原生平台的业务执行方法、执行装置和电子设备 - Google Patents
云原生平台的业务执行方法、执行装置和电子设备 Download PDFInfo
- Publication number
- CN117176818A CN117176818A CN202311193782.0A CN202311193782A CN117176818A CN 117176818 A CN117176818 A CN 117176818A CN 202311193782 A CN202311193782 A CN 202311193782A CN 117176818 A CN117176818 A CN 117176818A
- Authority
- CN
- China
- Prior art keywords
- service
- resource pool
- memory
- resource
- service type
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 128
- 238000011176 pooling Methods 0.000 claims abstract description 49
- 238000002955 isolation Methods 0.000 claims description 141
- 238000004064 recycling Methods 0.000 claims description 30
- 238000003860 storage Methods 0.000 claims description 24
- 238000007726 management method Methods 0.000 description 41
- 230000008569 process Effects 0.000 description 29
- 230000007246 mechanism Effects 0.000 description 26
- 238000013468 resource allocation Methods 0.000 description 25
- 238000012545 processing Methods 0.000 description 21
- 238000010586 diagram Methods 0.000 description 16
- 230000006870 function Effects 0.000 description 14
- 238000005516 engineering process Methods 0.000 description 12
- 238000004590 computer program Methods 0.000 description 10
- 230000005540 biological transmission Effects 0.000 description 7
- 238000004364 calculation method Methods 0.000 description 6
- 230000008901 benefit Effects 0.000 description 5
- 230000008859 change Effects 0.000 description 4
- 230000006872 improvement Effects 0.000 description 4
- 238000012544 monitoring process Methods 0.000 description 4
- 238000011084 recovery Methods 0.000 description 4
- 238000011144 upstream manufacturing Methods 0.000 description 4
- 238000004422 calculation algorithm Methods 0.000 description 3
- 238000000275 quality assurance Methods 0.000 description 3
- 230000035945 sensitivity Effects 0.000 description 3
- 230000003068 static effect Effects 0.000 description 3
- 230000001960 triggered effect Effects 0.000 description 3
- 230000015556 catabolic process Effects 0.000 description 2
- 239000003795 chemical substances by application Substances 0.000 description 2
- 238000004891 communication Methods 0.000 description 2
- 230000006835 compression Effects 0.000 description 2
- 238000007906 compression Methods 0.000 description 2
- 238000006731 degradation reaction Methods 0.000 description 2
- 238000009826 distribution Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 230000001629 suppression Effects 0.000 description 2
- XLYOFNOQVPJJNP-UHFFFAOYSA-N water Substances O XLYOFNOQVPJJNP-UHFFFAOYSA-N 0.000 description 2
- 241000109539 Conchita Species 0.000 description 1
- 239000004606 Fillers/Extenders Substances 0.000 description 1
- 239000008186 active pharmaceutical agent Substances 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 238000005192 partition Methods 0.000 description 1
- 239000002699 waste material Substances 0.000 description 1
Classifications
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本申请提供了一种云原生平台的业务执行方法、执行装置和电子设备。该方法包括:获取多个当前业务的业务类型标签,将业务类型标签相同的一个或多个当前业务划分至同一个资源池,得到多个资源池,其中,业务类型标签为表征当前业务的类型的标签,且包括在线业务类型、离线业务类型和混合业务类型;建立分级池化模型,根据分级池化模型确定每个资源池的优先级,其中,分级池化模型为预先根据资源池的优先级建立的且用于划分资源池的优先级的模型;按照优先级由大到小的顺序执行每个资源池中的当前业务。通过本申请,解决了现有技术中云原生平台的资源利用率低的问题。
Description
技术领域
本申请涉及云计算领域,具体而言,涉及一种云原生平台的业务执行方法、执行装置、云原生平台、计算机可读存储介质和电子设备。
背景技术
云原生(Cloud Native)是一种计算架构模式,它利用云计算的弹性,使用云服务来构建和运行应用程序。云原生架构利用云计算的弹性,通过微服务、容器、API、事件驱动等手段构建和运行应用,实现可持续的快速迭代,这使得开发和运维的效率极大提高。云原生代表了软件开发模式的未来方向。Kubernetes(简称K8s)是云原生应用的编排平台。Kubernetes提供了开源的容器编排平台,可以动态管理云原生应用所使用的大量容器,实现应用的部署、扩展和管理。云原生生态系统中的众多开源技术也都围绕Kubernetes构建。可以说,Kubernetes是云原生应用实现的最大基石。
随着云计算时代的到来,规模化运营成为数据中心的必然选择。大规模数据中心是支撑企业级互联网应用和云计算系统的关键基础设施。为满足不断增长的计算需求,数据中心需要不断扩容,服务器总量呈现快速增长趋势。然而,随着数据中心的迅速扩张,资源利用率却一直相对较低。统计数据显示,全球数据中心的资源利用率仅为10%~20%。这样低的资源利用率意味着大量资源被浪费,导致数据中心的成本效率极低。
因此,如何在最小化服务影响的前提下提高服务器的资源利用率,从而降低服务器的采购成本,是需要解决的问题。
发明内容
本申请的主要目的在于提供一种云原生平台的业务执行方法、执行装置、云原生平台、计算机可读存储介质和电子设备,以至少解决现有技术中云原生平台的资源利用率低的问题。
为了实现上述目的,根据本申请的一个方面,提供了一种云原生平台的业务执行方法,包括:获取多个当前业务的业务类型标签,将所述业务类型标签相同的一个或多个所述当前业务划分至同一个资源池,得到多个资源池,其中,所述业务类型标签为表征所述当前业务的类型的标签,且包括在线业务类型、离线业务类型和混合业务类型;建立分级池化模型,根据所述分级池化模型确定每个所述资源池的优先级,其中,所述分级池化模型为预先根据所述资源池的优先级建立的且用于划分所述资源池的优先级的模型;按照所述优先级由大到小的顺序执行每个所述资源池中的所述当前业务。
可选地,所述方法还包括:通过第一CPU隔离策略确定所述当前业务使用的CPU内核,其中,所述第一CPU隔离策略用于对CPU进行粗粒度的隔离,所述粗粒度的隔离表示按照业务的类别划分;通过第二CPU隔离策略确定所述CPU内核的带宽,在所述CPU内核中以所述带宽执行所述当前业务,其中,所述第二CPU隔离策略用于对所述CPU进行细粒度的隔离,所述细粒度的隔离表示在所述类别划分的基础上进一步按照实例划分。
可选地,所述方法还包括:在所述当前业务类型为所述离线业务类型的情况下,计算所述云原生平台中多个节点的负载程度,其中,每个所述节点用于执行一个所述当前业务,所述负载程度表示每个所述当前业务所在的节点的负载大小;比较多个所述节点的负载程度的大小,在所述负载程度最小的所述节点上执行所述离线业务类型对应的所述当前业务。
可选地,所述方法还包括:在所述在线业务类型的所述当前业务的数量大于预设阈值的情况下,获取所述云原生平台中多个处于空闲状态的节点地址,得到空闲节点地址;将所述离线业务类型的所述当前业务发送至所述空闲节点地址对应的节点,在所述空闲节点地址对应的所述节点上执行所述离线业务类型对应的所述当前业务。
可选地,所述方法还包括:通过第一内存回收策略确定所述云原生平台中的内存参数,其中,所述第一内存回收策略用于确定所述云原生平台中使用的内存参数,所述内存参数至少包括内存限制参数;通过第二内存回收策略确定所述云原生平台的最大可用内存,其中,所述第二内存回收策略用于确定所述云原生平台的可用内存的最大值。
可选地,所述方法还包括:通过第一网络隔离策略获取所述云原生平台的流量参数,并根据所述流量参数计算所述云原生平台的网络流量,其中,所述第一网络隔离策略用于计算所述网络流量;通过第二网络隔离策略确定所述云原生平台的网络的队列规则,在所述队列规则下按照所述网络流量执行所述当前业务,其中,所述第二网络隔离策略用于按照所述队列规则对所述网络流量进行限制。
根据本申请的另一方面,提供了一种云原生平台的业务执行装置,包括:划分单元,用于获取多个当前业务的业务类型标签,将所述业务类型标签相同的一个或多个所述当前业务划分至同一个资源池,得到多个资源池,其中,所述业务类型标签为表征所述当前业务的类型的标签,且包括在线业务类型、离线业务类型和混合业务类型;第一确定单元,用于建立分级池化模型,根据所述分级池化模型确定每个所述资源池的优先级,其中,所述分级池化模型为预先根据所述资源池的优先级建立的且用于划分所述资源池的优先级的模型;第一执行单元,用于按照所述优先级由大到小的顺序执行每个所述资源池中的所述当前业务。
根据本申请的再一方面,提供了一种云原生平台,所述云原生平台包括基础组件层、资源调度层、调度器层、重调度器层和节点管控层,所述云原生平台用于执行任意一种所述的业务执行方法。
根据本申请的又一方面,提供了一种计算机可读存储介质,所述计算机可读存储介质包括存储的程序,其中,在所述程序运行时控制所述计算机可读存储介质所在设备执行任意一种所述的业务执行方法。
根据本申请的又一方面,提供了一种电子设备,其特征在于,包括:一个或多个处理器,存储器,以及一个或多个程序,其中,所述一个或多个程序被存储在所述存储器中,并且被配置为由所述一个或多个处理器执行,所述一个或多个程序包括用于执行任意一种所述的业务执行方法。
应用本申请的技术方案,获取多个当前业务的业务类型标签,将当前业务按照业务类型标签进行划分,得到多个资源池;并建立分级池化模型,根据所述分级池化模型确定每个所述资源池的优先级;最后按照优先级由大到小的顺序执行每个所述资源池中的所述当前业务。这样将当前业务按照业务类型进行划分,并按照优先级执行,最大化利用服务器的资源,与现有技术中,无法进行资源划分与优先级调度而造成资源利用率低的问题,本申请按照资源划分与优先级的调度执行业务,使平台服务器的资源被有效利用,因此,能够解决云原生平台的资源利用率低的问题,达到提高资源利用率的效果。
附图说明
构成本申请的一部分的说明书附图用来提供对本申请的进一步理解,本申请的示意性实施例及其说明用于解释本申请,并不构成对本申请的不当限定。在附图中:
图1示出了本申请的实施例提供的一种执行云原生平台的业务执行方法的移动终端的硬件结构框图;
图2示出了本申请的实施例提供的一种云原生平台的业务执行方法的流程示意图;
图3示出了本申请的实施例提供的一种具体的云原生平台的业务执行方法中业务场景划分示意图;
图4示出了本申请的实施例提供的一种云原生平台的结构示意图;
图5示出了本申请的实施例提供的一种具体的云原生平台的业务执行方法中节点划分示意图;
图6示出了本申请的实施例提供的一种具体的云原生平台的业务执行方法中分级池化资源模型示意图;
图7示出了本申请的实施例提供的一种具体的云原生平台的业务执行方法中扩展资源示意图;
图8示出了本申请的实施例提供的一种云原生平台的业务执行装置的结构框图。
其中,上述附图包括以下附图标记:
102、处理器;104、存储器;106、传输设备;108、输入输出设备。
具体实施方式
需要说明的是,在不冲突的情况下,本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。
为了使本技术领域的人员更好地理解本申请方案,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分的实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都应当属于本申请保护的范围。
需要说明的是,本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的本申请的实施例。此外,术语“包括”和“具有”以及他们的任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
为了便于描述,以下对本申请实施例涉及的部分名词或术语进行说明:
云原生:Cloud Native,是一种计算架构模式,它利用云计算的弹性,使用云服务来构建和运行应用程序。
Cgroup:控制组群,Control group,简称Cgroup,是Linux内核的一个功能,用来限制、控制与分离一个进程组的资源。
Kubernetes:简称K8s,是一个开源的,用于管理云平台中多个主机上的容器化的应用。
正如背景技术中所介绍的,由于多个作业竞争共享资源(如CPU、缓存、内存、内存带宽、网络带宽),导致作业间出现在离线混部作业调度问题、在离线作业的共享资源隔离问题、资源动态分配问题。这种在离线混部作业间的资源竞争及性能干扰使得混部集群作业调度与资源管理变得十分复杂。对于Kubernetes云平台来说,造成机器平均资源利用率低的原因可以概括为以下几点:业务申请的资源配额超过实际使用量,这就导致机器配额被占满,无法继续调度容器,而实际资源利用率却很低。服务的资源使用量存在波峰波谷,大部分服务的负载都会存在高低峰,当服务处于波谷的时候就会存在很大的资源浪费。传统的数据中心中将在/离线服务分开部署管理,会导致在线业务性能下降,并且这种下降是不可预测的,无法统一调度。因此,现有技术中云原生平台的资源利用率低,为解决云原生平台的资源利用率低的问题,本申请的实施例提供了一种云原生平台的业务执行方法、执行装置、云原生平台、计算机可读存储介质和电子设备。
下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述。
本申请实施例中所提供的方法实施例可以在移动终端、计算机终端或者类似的运算装置中执行。以运行在移动终端上为例,图1是本发明实施例的一种云原生平台的业务执行方法的移动终端的硬件结构框图。如图1所示,移动终端可以包括一个或多个(图1中仅示出一个)处理器102(处理器102可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置)和用于存储数据的存储器104,其中,上述移动终端还可以包括用于通信功能的传输设备106以及输入输出设备108。本领域普通技术人员可以理解,图1所示的结构仅为示意,其并不对上述移动终端的结构造成限定。例如,移动终端还可包括比图1中所示更多或者更少的组件,或者具有与图1所示不同的配置。
存储器104可用于存储计算机程序,例如,应用软件的软件程序以及模块,如本发明实施例中的云原生平台的业务执行方法对应的计算机程序,处理器102通过运行存储在存储器104内的计算机程序,从而执行各种功能应用以及数据处理,即实现上述的方法。存储器104可包括高速随机存储器,还可包括非易失性存储器,如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中,存储器104可进一步包括相对于处理器102远程设置的存储器,这些远程存储器可以通过网络连接至移动终端。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。传输设备106用于经由一个网络接收或者发送数据。上述的网络具体实例可包括移动终端的通信供应商提供的无线网络。在一个实例中,传输设备106包括一个网络适配器(Network InterfaceController,简称为NIC),其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中,传输设备106可以为射频(Radio Frequency,简称为RF)模块,其用于通过无线方式与互联网进行通讯。
在本实施例中提供了一种运行于移动终端、计算机终端或者类似的运算装置的云原生平台的业务执行方法,需要说明的是,在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行,并且,虽然在流程图中示出了逻辑顺序,但是在某些情况下,可以以不同于此处的顺序执行所示出或描述的步骤。
图2是根据本申请实施例的云原生平台的业务执行方法的流程图。如图2所示,该方法包括以下步骤:
步骤S201,获取多个当前业务的业务类型标签,将上述业务类型标签相同的一个或多个上述当前业务划分至同一个资源池,得到多个资源池,其中,上述业务类型标签为表征上述当前业务的类型的标签,且包括在线业务类型、离线业务类型和混合业务类型;
具体地,将平台中的节点(Node)划分为三种类型,并将它们放置在三个不同的资源池中。在线资源池存放在线业务类型的当前业务:该资源池包含具有label/service业务类型标签的节点,仅用于调度在线业务。这些节点专门为在线服务提供高可用性和低延迟的支持。离线资源池存放离线业务类型的当前业务:该资源池包含具有label/job业务类型标签的节点,仅用于调度离线业务。这些节点主要用于批处理作业和数据处理任务,其特点是对计算时间不敏感且对资源需求较高。混合资源池存放混合业务类型的在线业务:该资源池包含具有label/colocation业务类型标签的节点,可混合调度在线和离线业务。这些节点既能满足在线业务的低延迟需求,又能处理离线业务的高计算需求。混合资源池的引入允许用户逐步采用混合部署技术,将在线和离线业务逐渐整合在一起,以提高资源利用率和灵活性。混合部署并非一蹴而就,用户不需要立即将所有业务和服务器迁移到混合资源池。相反,用户可以根据需求逐步将一部分服务器迁移到混合资源池中,控制混合部署的进度和风险。随着混合部署技术的成熟和用户接受度的提高,我们计划逐渐缩小在线资源池和离线资源池的规模,扩大混合资源池的规模。然而,对于某些特殊情况下无法进行混合部署的在线业务,我们仍然支持将其部署在在线资源池中,而不需要强制要求所有业务都进行混合部署。这样的灵活性可以满足不同业务需求和风险偏好。
在将节点划分之前,首先把当前业务划分为在线业务类型和离线业务类型。在线业务一般是各类微服务,特点是延时敏感、有很高的可用性要求;离线业务一般是批处理任务,特点是延时不敏感、允许出错重跑。云原生混部属于计算密集型任务,具有运行时间短、允许失败重试的特点。在凌晨时段会触发大量的定时任务,刚好和在线任务形成错峰。可以通过在/离线混部技术将定时任务调度到在线集群,这样既提高了在线集群的资源使用率,又补充了定时任务高峰期时的算力缺口,极大地提升了服务器效率。离线间混部的离线集群整体CPU使用率较高,但部分时段也存在一定的资源闲置。由于都是离线任务,延时敏感性没有在线那么高,因此这类场景可以混部一些更庞大的大数据任务。实现大数据混部后,就可以做到各个离线业务互相出让资源,并解决了将Kubernetes(K8s)调度和Yarn调度(资源调度平台)进行协调的关键问题。
步骤S202,建立分级池化模型,根据上述分级池化模型确定每个上述资源池的优先级,其中,上述分级池化模型为预先根据上述资源池的优先级建立的且用于划分上述资源池的优先级的模型;
具体地,为了提高资源利用率和保障服务质量,采用分级池化模型,确定上述每个资源池的优先级。该模型包括资源分池动态管理和资源池优先级管理两个核心设计。资源分池动态管理是一种将节点资源划分为多个资源池并进行管理的方法。它通过实现资源池内部资源的高度共享,提高资源的复用率,并通过资源池之间的隔离来避免池间服务的干扰。资源池内的资源配置会根据服务负载的变化进行动态调整,以确保资源池的负载保持在相对稳定的范围内,从而保证服务的质量。这种方法能够灵活地管理和分配资源,提高资源利用率,并确保服务质量的同时实现资源的高效利用。资源池优先级管理机制是基于资源分池动态管理的基础上,通过设置不同优先级的资源池来确保业务的服务质量。在资源池优先级管理机制中,每个资源池具有不同的优先级,对应不同级别的服务质量保障。这种机制下,资源配置管理有以下三个区别:资源配置管理策略不同:不同优先级的资源池采用不同的资源配置管理策略。高优先级的资源池拥有充足的资源配置,负载维持在安全稳定的水平。通过资源池的资源隔离能力,高优先级资源池内部的服务资源使用被优先保障,从而提供更高的服务质量。资源隔离保障能力不同:高级别的资源池依托系统内核等提供的资源隔离能力,提供更高级别的资源池资源隔离级别。这意味着高优资源池可以享受更高级别的资源隔离,如独占CPU绑定、I/O隔离等,从而保障其内部服务不受池外服务的影响。优先级资源抢占机制:资源池的资源配置可以动态调整。当高优先级资源池配置资源不足或负载过高时,QoS(服务质量保障机制,Quality of Service,简称QoS)会根据资源池的优先级,允许高优资源池抢占低优资源池已配置的资源。这样可以牺牲低优资源池的服务质量水平,优先保障高级别资源池的资源供给,从而确保高优服务的服务质量。因此,在分级池化的资源模型中,节点空闲资源首先被分配给优先级最低的资源池。其余资源池的资源配置由服务的资源需求、资源池资源配置管理策略以及资源池的负载情况决定。通过动态调整资源池的资源配置和优先级资源的抢占机制,能够确保资源池内的负载稳定,并根据优先级保障不同级别的服务质量。
步骤S203,按照上述优先级由大到小的顺序执行每个上述资源池中的上述当前业务。
具体地,在确定每个资源池的优先级之后,按照优先级由大到小的顺序执行当前业务。
通过本实施例,获取多个当前业务的业务类型标签,将当前业务按照业务类型标签进行划分,得到多个资源池;并建立分级池化模型,根据上述分级池化模型确定每个上述资源池的优先级;最后按照优先级由大到小的顺序执行每个上述资源池中的上述当前业务。这样将当前业务按照业务类型进行划分,并按照优先级执行,最大化利用服务器的资源,与现有技术中,无法进行资源划分与优先级调度而造成资源利用率低的问题,本申请按照资源划分与优先级的调度执行业务,使平台服务器的资源被有效利用,因此,能够解决云原生平台的资源利用率低的问题,达到提高资源利用率的效果。
具体实现过程中,上述方法还包括以下步骤:通过第一CPU隔离策略确定上述当前业务使用的CPU内核,其中,上述第一CPU隔离策略用于对CPU进行粗粒度的隔离,上述粗粒度的隔离表示按照业务的类别划分;通过第二CPU隔离策略确定上述CPU内核的带宽,在上述CPU内核中以上述带宽执行上述当前业务,其中,上述第二CPU隔离策略用于对上述CPU进行细粒度的隔离,上述细粒度的隔离表示在上述类别划分的基础上进一步按照实例划分。该方法通过第一CPU隔离策略进行隔离,之后再通过第二COU隔离策略进行隔离,这样可以合理利用CPU资源。
具体地,首先采用第一CPU隔离策略进行粗粒度隔离,第一CPU隔离策略可以为“cpuset”,“cpuset”通过指定一组整数的核心数来限制进程可以使用的CPU资源。通过Cgroup(控制组群,Control Group,简称Cgroup)子系统中的“cpuset.cpus”接口,可以调整CPU列表。需要注意的是,子集的CPU列表不能超过父集的设定范围,否则设定将不会成功。使用cpuset时,进程将被限制在指定的CPU内核上运行,实现了粗粒度的CPU隔离。在进行了粗粒度隔离的基础上,再进行细粒度的隔离即通过第二隔离策略进一步进行隔离,可以为“cfsQuota”,“cfsQuota”是一种更精细的CPU隔离策略,利用Linux的CFS(完全公平调度器,Completely Fair Scheduler,简称CFS调度器)进行调度。它通过设置Cgroup中的“cpu.cfs_quota_us”和“cpu.cfs_period_us”两个接口,以微秒为单位,来限制进程的CPU带宽(即可以使用CPU的时间)。总结来说,“cpuset”提供了粗粒度的CPU隔离,通过指定一组整数的核心数来限制进程使用的CPU资源;而“cfsQuota”则更加精细,利用CFS调度器实现完全公平的CPU时间片分配和控制,可以根据进程优先级、权重或控制组进行CPU带宽的分配。
为了解决静态调度过程中负载过重以及资源闲置的问题,上述方法还包括以下步骤:在上述当前业务类型为上述离线业务类型的情况下,计算上述云原生平台中多个节点的负载程度,其中,每个上述节点用于执行一个上述当前业务,上述负载程度表示每个上述当前业务所在的节点的负载大小;比较多个上述节点的负载程度的大小,在上述负载程度最小的上述节点上执行上述离线业务类型对应的上述当前业务。该方法采用动态调度的方式,将离线业务置于负载程度小的节点上执行,这样可以提高资源利用率,确保节点负载的均衡分布。
具体实现过程中,上述动态调度机制通过扩展调度器,利用节点和业务的资源画像信息进行计算和选择。它采用基于时间滑动窗口的动态加权算法,来评估候选调度节点的优劣,选择负载程度较低的节点作为最优调度目标。这种选择考虑了当前和未来一段时间内节点负载的情况。通过将离线任务调度到负载程度较低的节点上,通过实时监控和动态调整,可以更好地利用节点资源,避免负载过重或资源闲置的情况,从而提高整个集群的性能和效率。还可以控制每个节点允许调度离线任务的时间段,比如:只允许在每天的凌晨0-6点混部、控制每个节点最多调度几个离线任务、动态自适应地调整每个节点上可以分配给离线任务的资源量、将离线任务优先调度到负载较低、空闲资源较多的节点上。如果该节点近期内发生过离线任务的驱逐,那么短时间内不允许再调度离线任务上来,避免网络颠簸。
在一些可选的实施方式中,上述方法还包括以下步骤:在上述在线业务类型的上述当前业务的数量大于预设阈值的情况下,获取上述云原生平台中多个处于空闲状态的节点地址,得到空闲节点地址;将上述离线业务类型的上述当前业务发送至上述空闲节点地址对应的节点,在上述空闲节点地址对应的上述节点上执行上述离线业务类型对应的上述当前业务。该方法将离线业务发送至空闲节点上运行,这样可以避免节点过载,提高离线任务的执行效率,并提高资源的利用率。
具体地,在某些情况下,开始时混部节点(包括在线业务类型的节点和离线业务类型的节点)上的在线业务较少或流量较小,可以分配更多资源给离线业务,调度更多离线任务。但随着时间推移,如果节点上的在线业务增多或流量激增,离线业务的资源会迅速减少,降低执行效率。为了避免这种情况,可以进行离线任务的重调度,将其调度到其他空闲节点上。重调度的优点包括均衡负载、避免节点过载、不影响在线业务性能和稳定性,以及提高离线任务执行效率。而重调度也有缺点。如果离线任务没有远程检查点机制,重调度可能会导致之前的计算工作被浪费,甚至导致任务计算失败。影响程度取决于任务处理时长,处理时间较短时影响微小,较长时影响较大。因此,是否使用重调度功能以及触发阈值等配置应根据具体业务场景进行灵活调整,以平衡离线任务执行效率和资源利用。也就是说,当云原生平台中某一节点上的在线业务激增,同时又存在处于空闲状态的节点,则获取空闲节点的地址,得到空闲节点地址,并将离线业务类型的上述当前业务发送至上述空闲节点地址对应的节点,在上述空闲节点地址对应的上述节点上执行上述离线业务类型对应的上述当前业务。
为了在多场景下合理分配和利用内存资源,以保障在线业务的服务质量,上述方法还包括以下步骤:通过第一内存回收策略确定上述云原生平台中的内存参数,其中,上述第一内存回收策略用于确定上述云原生平台中使用的内存参数,上述内存参数至少包括内存限制参数;通过第二内存回收策略确定上述云原生平台的最大可用内存,其中,上述第二内存回收策略用于确定上述云原生平台的可用内存的最大值。该方法通过内存回收策略来控制离线业务内存的使用,这样可以合理分配和利用内存资源。
具体实现过程中,第一内存回收策略可以为“dynlevel策略”,该策略是基于内核Cgroup的多级别控制,通过监测节点内存压力,动态调整离线业务的内存,以尽可能保障在线业务的服务质量。具体操作包括调整离线应用容器的内存限制参数,如“memory.soft_limit_in_bytes”、“memory.force_empty”、“memory.limit_in_bytes”、“/proc/sys/vm/drop_caches”等。第二内存回收策略可以为“fssr策略”,该策略是基于内核Cgroup的动态水位线控制。通过使用“memory.high”接口,动态调整离线应用的内存上限,以实现对离线业务的内存压制,从而保障在线业务的服务质量。具体操作包括根据内存压力情况,动态调整离线应用的“memory.high”值,以限制其内存使用。这两种策略都可以通过“/sys/fs/cgroup/memory”目录下容器的Cgroup中的相关接口进行配置和调整。“dynlevel策略”会根据节点的内存压力情况,依次调整离线应用容器的内存限制参数;而“fssr策略”则根据可用内存和预留内存的比例来调整离线应用的内存上限,以实现快速压制和慢速恢复的策略。因此,“dynlevel策略”通过动态调整内存限制参数来控制离线业务的内存使用,而“fssr策略”则通过动态调整内存上限来实现对离线业务的内存压制。这些策略的目标是在多场景下合理分配和利用内存资源,以保障在线业务的服务质量。
在一些可选的实施方式中,上述方法还包括以下步骤:通过第一网络隔离策略获取上述云原生平台的流量参数,并根据上述流量参数计算上述云原生平台的网络流量,其中,上述第一网络隔离策略用于计算上述网络流量;通过第二网络隔离策略确定上述云原生平台的网络的队列规则,在上述队列规则下按照上述网络流量执行上述当前业务,其中,上述第二网络隔离策略用于按照上述队列规则对上述网络流量进行限制。该方法通过网络隔离策略实现网络隔离,这样可以更好地控制和管理网络流量,以满足业务场景的需求,进一步提高资源的利用率。
具体地,在Kubernetes集群中,网络隔离技术的选择取决于网络插件和网络模型。有许多可行的方式,但在某些复杂的网络环境中,可能需要直接编写内核驱动程序以实现隔离功能。在这种情况下,使用“bpftrace”和“tc”来实现网络隔离。使用第一网络隔离策略“bpftrace”来收集流量参数,并进行网络流量的测算。“bpftrace”是一个强大的工具,可以通过动态追踪机制监控内核函数的执行过程,从而获取流量相关的信息。通过执行一系列命令,如“modprobe”、“ip link”和“tc qdisc”,我们建立虚拟网卡设备,并使用第二网络隔离策略“tc qdisc”(队列规则)来建立入口和出口规则,从而限制上行和下行流量的控制。通过这种方式,我们能够基于bpftrace和tc技术实现网络隔离,根据需求限制上行和下行流量,并将指定设备用于离线任务。这种自定义网络隔离机制允许我们更好地控制和管理集群中的网络流量,以满足特定业务场景的需求。
为了使得本领域技术人员能够更加清楚地了解本申请的技术方案,以下将结合具体的实施例对本申请的云原生平台的业务执行方法的实现过程进行详细说明。
本实施例涉及一种具体的云原生平台的业务执行方法,图3为一种业务场景划分示意图,包括在线任务、离线任务以及混合部署之后的在离线混部,在线任务执行中存放在线利用资源,离线任务中存放离线利用资源,在离线混部存放离线利用资源和在线利用资源,空白的为空闲资源;图4为云原生平台的结构示意图,包括基础组件、资源调度、节点管控、存储管理和系统隔离五部分,基础组件层:该层主要通过调用“ApiServer”与k8s资源进行交互,提供基础的组件支持。
资源调度层:该层负责资源的调度、同步和计算。其中的“Manager”组件用于同步节点的“let agent”配置,例如:BE内存和CPU分配比例,以及开启某项压制开关。另外,该层还负责对节点资源进行计算工作。“Scheuler”组件即调度器组件:该层负责在线和离线应用的调度。它扩展了负载均衡调度,包括CPU、内存和CPI(每条指令的平均时钟周期数)干扰的调度。此外,还包含重调度预调度和CationFit插件。重调度器层“Descheuler”组件:该层是重调度器,主要用于实时运行过程中的二次调度,即重新调度节点。它扩展了高级防护策略,按照节点、命名空间和工作负载进行保护。
节点管控层:该层包括节点级调度器“NodeManager”、“let”、“Online Pod”。其中,“NodeManager”是Yarn中单节点的代理,用于管理Hadoop集群中的单个计算节点,并与应用程序的ApplicationMaster和集群资源管理器RM进行交互。而“let”是节点级调度器,主要负责CPI和LC(Latency Critical)动态指标采集、OS QOS(服务质量,Quality of service,简称QOS)分级、资源隔离、过载保护、full-pcpus-only绑核等任务。
此外,还有存储管理层,该层采用存算分离的方式,使用RSS(UNIFFLE)读取shuffle数据,并进行存储管理。
而系统隔离层主要利用“openEuler”的Cgroup管理,包括CPU SET&CPU CFS&QQS层、L3 CACHE&MEM QQS层、IOPS&QQS层、NETWORK TC层和NUMA&GPU层。云原生平台还包括OSOn Centos层和Prometheus层,通过上述组件对CPU、内存、IO、网络、Numa、GPU和OS QOS进行管理。
一种具体的云原生平台的业务执行方法包括如下步骤:
步骤S1:如图5所示,Pod数据结构通过Kuber-scheduler(标准调度程序)以及Scheduler-extender(调度扩展程序)进行资源请求与真实使用。在实际应用过程中,将节点进行划分,并将它们放置在三个不同的资源池中:在线资源池:该资源池包含具有“label/service”业务类型标签的节点,仅用于调度在线业务。离线资源池:该资源池包含具有“label/job”业务类型标签的节点,仅用于调度离线业务。混合资源池:该资源池包含具有“label/colocation”业务类型标签的节点,可混合调度在线和离线业务;
步骤S2:采用分级池化模型,确定每个上述资源池的优先级,按照上述优先级由大到小的顺序执行每个上述资源池中的上述当前业务,分级池化资源模型如图6所示,单机可用资源划分为Pool0、Pool1、Pool2,开始时,Pool1执行任务1,到最后Pool0执行任务7和8,Pool1执行任务1、2、3、4、5、6,以及Pool2执行任务9,这样就将多个任务隔离开执行,提高资源的利用率;
步骤S3:CPU隔离:在业务执行过程中,通过第一CPU隔离策略“cpuset”确定上述当前业务使用的CPU内核;通过第二CPU隔离策略“cfsQuota”确定上述CPU内核的带宽,在上述CPU内核中以上述带宽执行上述当前业务;
步骤S4:动态调度离线任务:为了实现离线任务的动态调度,APIServer Webhook定义了两种扩展资源:colocation/cpu和colocation/memory,如图7所示,分别对应原生的CPU和内存资源。基于时间滑动窗口的动态加权算法计算上述云原生平台中多个节点的负载程度;比较多个上述节点的负载程度的大小,在上述负载程度最小的上述节点上执行上述离线业务类型对应的上述当前业务;
步骤S5:离线任务的重调度,在上述在线业务类型的上述当前业务的数量大于预设阈值的情况下,获取上述云原生平台中多个处于空闲状态的节点地址,得到空闲节点地址;将上述离线业务类型的上述当前业务发送至上述空闲节点地址对应的节点,在上述空闲节点地址对应的上述节点上执行上述离线业务类型对应的上述当前业务;
步骤S6:内存回收:通过第一内存回收策略确定上述云原生平台中的内存参数,其中,上述第一内存回收策略用于确定上述云原生平台中使用的内存参数,上述内存参数至少包括内存限制参数;通过第二内存回收策略确定上述云原生平台的最大可用内存,其中,上述第二内存回收策略用于确定上述云原生平台的可用内存的最大值;
步骤S7:网络隔离:通过第一网络隔离策略获取上述云原生平台的流量参数,并根据上述流量参数计算上述云原生平台的网络流量;通过第二网络隔离策略确定上述云原生平台的网络的队列规则,在上述队列规则下按照上述网络流量执行上述当前业务。
本申请实施例还提供了一种云原生平台的业务执行装置,需要说明的是,本申请实施例的云原生平台的业务执行装置可以用于执行本申请实施例所提供的用于云原生平台的业务执行方法。该装置用于实现上述实施例及优选实施方式,已经进行过说明的不再赘述。如以下所使用的,术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现,但是硬件,或者软件和硬件的组合的实现也是可能并被构想的。
以下对本申请实施例提供的云原生平台的业务执行装置进行介绍。
图8是根据本申请实施例的云原生平台的业务执行装置的示意图。如图8所示,该装置包括:
划分单元10,用于获取多个当前业务的业务类型标签,将上述业务类型标签相同的一个或多个上述当前业务划分至同一个资源池,得到多个资源池,其中,上述业务类型标签为表征上述当前业务的类型的标签,且包括在线业务类型、离线业务类型和混合业务类型;
具体地,将平台中的节点(Node)划分为三种类型,并将它们放置在三个不同的资源池中。在线资源池存放在线业务类型的当前业务:该资源池包含具有label/service业务类型标签的节点,仅用于调度在线业务。这些节点专门为在线服务提供高可用性和低延迟的支持。离线资源池存放离线业务类型的当前业务:该资源池包含具有label/job业务类型标签的节点,仅用于调度离线业务。这些节点主要用于批处理作业和数据处理任务,其特点是对计算时间不敏感且对资源需求较高。混合资源池存放混合业务类型的在线业务:该资源池包含具有label/colocation业务类型标签的节点,可混合调度在线和离线业务。这些节点既能满足在线业务的低延迟需求,又能处理离线业务的高计算需求。混合资源池的引入允许用户逐步采用混合部署技术,将在线和离线业务逐渐整合在一起,以提高资源利用率和灵活性。混合部署并非一蹴而就,用户不需要立即将所有业务和服务器迁移到混合资源池。相反,用户可以根据需求逐步将一部分服务器迁移到混合资源池中,控制混合部署的进度和风险。随着混合部署技术的成熟和用户接受度的提高,我们计划逐渐缩小在线资源池和离线资源池的规模,扩大混合资源池的规模。然而,对于某些特殊情况下无法进行混合部署的在线业务,我们仍然支持将其部署在在线资源池中,而不需要强制要求所有业务都进行混合部署。这样的灵活性可以满足不同业务需求和风险偏好。
在将节点划分之前,首先把当前业务划分为在线业务类型和离线业务类型。在线业务一般是各类微服务,特点是延时敏感、有很高的可用性要求;离线业务一般是批处理任务,特点是延时不敏感、允许出错重跑。云原生混部属于计算密集型任务,具有运行时间短、允许失败重试的特点。在凌晨时段会触发大量的定时任务,刚好和在线任务形成错峰。可以通过在/离线混部技术将定时任务调度到在线集群,这样既提高了在线集群的资源使用率,又补充了定时任务高峰期时的算力缺口,极大地提升了服务器效率。离线间混部的离线集群整体CPU使用率较高,但部分时段也存在一定的资源闲置。由于都是离线任务,延时敏感性没有在线那么高,因此这类场景可以混部一些更庞大的大数据任务。实现大数据混部后,就可以做到各个离线业务互相出让资源,并解决了将Kubernetes(K8s)调度和Yarn调度(资源调度平台)进行协调的关键问题。
第一确定单元20,用于建立分级池化模型,根据上述分级池化模型确定每个上述资源池的优先级,其中,上述分级池化模型为预先根据上述资源池的优先级建立的且用于划分上述资源池的优先级的模型;
具体地,为了提高资源利用率和保障服务质量,采用分级池化模型,确定上述每个资源池的优先级。该模型包括资源分池动态管理和资源池优先级管理两个核心设计。资源分池动态管理是一种将节点资源划分为多个资源池并进行管理的装置。它通过实现资源池内部资源的高度共享,提高资源的复用率,并通过资源池之间的隔离来避免池间服务的干扰。资源池内的资源配置会根据服务负载的变化进行动态调整,以确保资源池的负载保持在相对稳定的范围内,从而保证服务的质量。这种装置能够灵活地管理和分配资源,提高资源利用率,并确保服务质量的同时实现资源的高效利用。资源池优先级管理机制是基于资源分池动态管理的基础上,通过设置不同优先级的资源池来确保业务的服务质量。在资源池优先级管理机制中,每个资源池具有不同的优先级,对应不同级别的服务质量保障。这种机制下,资源配置管理有以下三个区别:资源配置管理策略不同:不同优先级的资源池采用不同的资源配置管理策略。高优先级的资源池拥有充足的资源配置,负载维持在安全稳定的水平。通过资源池的资源隔离能力,高优先级资源池内部的服务资源使用被优先保障,从而提供更高的服务质量。资源隔离保障能力不同:高级别的资源池依托系统内核等提供的资源隔离能力,提供更高级别的资源池资源隔离级别。这意味着高优资源池可以享受更高级别的资源隔离,如独占CPU绑定、I/O隔离等,从而保障其内部服务不受池外服务的影响。优先级资源抢占机制:资源池的资源配置可以动态调整。当高优先级资源池配置资源不足或负载过高时,QoS服务质量保障机制会根据资源池的优先级,允许高优资源池抢占低优资源池已配置的资源。这样可以牺牲低优资源池的服务质量水平,优先保障高级别资源池的资源供给,从而确保高优服务的服务质量。因此,在分级池化的资源模型中,节点空闲资源首先被分配给优先级最低的资源池。其余资源池的资源配置由服务的资源需求、资源池资源配置管理策略以及资源池的负载情况决定。通过动态调整资源池的资源配置和优先级资源的抢占机制,能够确保资源池内的负载稳定,并根据优先级保障不同级别的服务质量。
第一执行单元30,用于按照上述优先级由大到小的顺序执行每个上述资源池中的上述当前业务。
具体地,在确定每个资源池的优先级之后,按照优先级由大到小的顺序执行当前业务。
通过本实施例,获取多个当前业务的业务类型标签,将当前业务按照业务类型标签进行划分,得到多个资源池;并建立分级池化模型,根据上述分级池化模型确定每个上述资源池的优先级;最后按照优先级由大到小的顺序执行每个上述资源池中的上述当前业务。这样将当前业务按照业务类型进行划分,并按照优先级执行,最大化利用服务器的资源,与现有技术中,无法进行资源划分与优先级调度而造成资源利用率低的问题,本申请按照资源划分与优先级的调度执行业务,使平台服务器的资源被有效利用,因此,能够解决云原生平台的资源利用率低的问题,达到提高资源利用率的效果。
具体实现过程中,上述装置还包括第二确定单元和第二执行单元,其中,第二确定单元用于通过第一CPU隔离策略确定上述当前业务使用的CPU内核,其中,上述第一CPU隔离策略用于对CPU进行粗粒度的隔离,上述粗粒度的隔离表示按照业务的类别划分;第二执行单元用于通过第二CPU隔离策略确定上述CPU内核的带宽,在上述CPU内核中以上述带宽执行上述当前业务,其中,上述第二CPU隔离策略用于对上述CPU进行细粒度的隔离,上述细粒度的隔离表示在上述类别划分的基础上进一步按照实例划分。该装置通过第一CPU隔离策略进行隔离,之后再通过第二COU隔离策略进行隔离,这样可以合理利用CPU资源。
具体地,首先采用第一CPU隔离策略进行粗粒度隔离,第一CPU隔离策略可以为“cpuset”,“cpuset”通过指定一组整数的核心数来限制进程可以使用的CPU资源。通过Cgroup(控制组群,Control Group,简称Cgroup)子系统中的“cpuset.cpus”接口,可以调整CPU列表。需要注意的是,子集的CPU列表不能超过父集的设定范围,否则设定将不会成功。使用cpuset时,进程将被限制在指定的CPU内核上运行,实现了粗粒度的CPU隔离。在进行了粗粒度隔离的基础上,再进行细粒度的隔离即通过第二隔离策略进一步进行隔离,可以为“cfsQuota”,“cfsQuota”是一种更精细的CPU隔离策略,利用Linux的CFS(完全公平调度器,Completely Fair Scheduler,简称CFS调度器)进行调度。它通过设置Cgroup中的“cpu.cfs_quota_us”和“cpu.cfs_period_us”两个接口,以微秒为单位,来限制进程的CPU带宽(即可以使用CPU的时间)。总结来说,“cpuset”提供了粗粒度的CPU隔离,通过指定一组整数的核心数来限制进程使用的CPU资源;而“cfsQuota”则更加精细,利用CFS调度器实现完全公平的CPU时间片分配和控制,可以根据进程优先级、权重或控制组进行CPU带宽的分配。
为了解决静态调度过程中负载过重以及资源闲置的问题,上述装置还包括第一计算单元和第三执行单元,其中,第一计算单元用于在上述当前业务类型为上述离线业务类型的情况下,计算上述云原生平台中多个节点的负载程度,其中,每个上述节点用于执行一个上述当前业务,上述负载程度表示每个上述当前业务所在的节点的负载大小;第三执行单元用于比较多个上述节点的负载程度的大小,在上述负载程度最小的上述节点上执行上述离线业务类型对应的上述当前业务。该装置采用动态调度的方式,将离线业务置于负载程度小的节点上执行,这样可以提高资源利用率,确保节点负载的均衡分布。
具体实现过程中,上述动态调度机制通过扩展调度器,利用节点和业务的资源画像信息进行计算和选择。它采用基于时间滑动窗口的动态加权算法,来评估候选调度节点的优劣,选择负载程度较低的节点作为最优调度目标。这种选择考虑了当前和未来一段时间内节点负载的情况。通过将离线任务调度到负载程度较低的节点上,通过实时监控和动态调整,可以更好地利用节点资源,避免负载过重或资源闲置的情况,从而提高整个集群的性能和效率。还可以控制每个节点允许调度离线任务的时间段,比如:只允许在每天的凌晨0-6点混部、控制每个节点最多调度几个离线任务、动态自适应地调整每个节点上可以分配给离线任务的资源量、将离线任务优先调度到负载较低、空闲资源较多的节点上。如果该节点近期内发生过离线任务的驱逐,那么短时间内不允许再调度离线任务上来,避免网络颠簸。
在一些可选的实施方式中,上述装置还包括获取单元和第四执行单元,其中,获取单元在上述在线业务类型的上述当前业务的数量大于预设阈值的情况下,获取上述云原生平台中多个处于空闲状态的节点地址,得到空闲节点地址;第四执行单元用于将上述离线业务类型的上述当前业务发送至上述空闲节点地址对应的节点,在上述空闲节点地址对应的上述节点上执行上述离线业务类型对应的上述当前业务。该装置将离线业务发送至空闲节点上运行,这样可以避免节点过载,提高离线任务的执行效率,并提高资源的利用率。
具体地,在某些情况下,开始时混部节点(包括在线业务类型的节点和离线业务类型的节点)上的在线业务较少或流量较小,可以分配更多资源给离线业务,调度更多离线任务。但随着时间推移,如果节点上的在线业务增多或流量激增,离线业务的资源会迅速减少,降低执行效率。为了避免这种情况,可以进行离线任务的重调度,将其调度到其他空闲节点上。重调度的优点包括均衡负载、避免节点过载、不影响在线业务性能和稳定性,以及提高离线任务执行效率。而重调度也有缺点。如果离线任务没有远程检查点机制,重调度可能会导致之前的计算工作被浪费,甚至导致任务计算失败。影响程度取决于任务处理时长,处理时间较短时影响微小,较长时影响较大。因此,是否使用重调度功能以及触发阈值等配置应根据具体业务场景进行灵活调整,以平衡离线任务执行效率和资源利用。也就是说,当云原生平台中某一节点上的在线业务激增,同时又存在处于空闲状态的节点,则获取空闲节点的地址,得到空闲节点地址,并将离线业务类型的上述当前业务发送至上述空闲节点地址对应的节点,在上述空闲节点地址对应的上述节点上执行上述离线业务类型对应的上述当前业务。
为了在多场景下合理分配和利用内存资源,以保障在线业务的服务质量,上述装置还包括第三确定单元和第四确定单元,其中,通过第一内存回收策略确定上述云原生平台中的内存参数,其中,上述第一内存回收策略用于确定上述云原生平台中使用的内存参数,上述内存参数至少包括内存限制参数;通过第二内存回收策略确定上述云原生平台的最大可用内存,其中,上述第二内存回收策略用于确定上述云原生平台的可用内存的最大值。该装置通过内存回收策略来控制离线业务内存的使用,这样可以合理分配和利用内存资源。
具体实现过程中,第一内存回收策略可以为“dynlevel策略”,该策略是基于内核Cgroup的多级别控制,通过监测节点内存压力,动态调整离线业务的内存,以尽可能保障在线业务的服务质量。具体操作包括调整离线应用容器的内存限制参数,如“memory.soft_limit_in_bytes”、“memory.force_empty”、“memory.limit_in_bytes”、“/proc/sys/vm/drop_caches”等。第二内存回收策略可以为“fssr策略”,该策略是基于内核Cgroup的动态水位线控制。通过使用“memory.high”接口,动态调整离线应用的内存上限,以实现对离线业务的内存压制,从而保障在线业务的服务质量。具体操作包括根据内存压力情况,动态调整离线应用的“memory.high”值,以限制其内存使用。这两种策略都可以通过“/sys/fs/cgroup/memory”目录下容器的Cgroup中的相关接口进行配置和调整。“dynlevel策略”会根据节点的内存压力情况,依次调整离线应用容器的内存限制参数;而“fssr策略”则根据可用内存和预留内存的比例来调整离线应用的内存上限,以实现快速压制和慢速恢复的策略。因此,“dynlevel策略”通过动态调整内存限制参数来控制离线业务的内存使用,而“fssr策略”则通过动态调整内存上限来实现对离线业务的内存压制。这些策略的目标是在多场景下合理分配和利用内存资源,以保障在线业务的服务质量。
在一些可选的实施方式中,上述装置还包括第二计算单元和第五执行单元,其中,第二计算单元用于通过第一网络隔离策略获取上述云原生平台的流量参数,并根据上述流量参数计算上述云原生平台的网络流量,其中,上述第一网络隔离策略用于计算上述网络流量;第五执行单元用于通过第二网络隔离策略确定上述云原生平台的网络的队列规则,在上述队列规则下按照上述网络流量执行上述当前业务,其中,上述第二网络隔离策略用于按照上述队列规则对上述网络流量进行限制。该装置通过网络隔离策略实现网络隔离,这样可以更好地控制和管理网络流量,以满足业务场景的需求,进一步提高资源的利用率。
具体地,在Kubernetes集群中,网络隔离技术的选择取决于网络插件和网络模型。有许多可行的方式,但在某些复杂的网络环境中,可能需要直接编写内核驱动程序以实现隔离功能。在这种情况下,使用“bpftrace”和“tc”来实现网络隔离。使用第一网络隔离策略“bpftrace”来收集流量参数,并进行网络流量的测算。“bpftrace”是一个强大的工具,可以通过动态追踪机制监控内核函数的执行过程,从而获取流量相关的信息。通过执行一系列命令,如“modprobe”、“ip link”和“tc qdisc”,我们建立虚拟网卡设备,并使用第二网络隔离策略“tc qdisc”(队列规则)来建立入口和出口规则,从而限制上行和下行流量的控制。通过这种方式,我们能够基于bpftrace和tc技术实现网络隔离,根据需求限制上行和下行流量,并将指定设备用于离线任务。这种自定义网络隔离机制允许我们更好地控制和管理集群中的网络流量,以满足特定业务场景的需求。
上述云原生平台的业务执行装置包括处理器和存储器,上述划分单元、第一确定单元和第一执行单元等均作为程序单元存储在存储器中,由处理器执行存储在存储器中的上述程序单元来实现相应的功能。上述模块均位于同一处理器中;或者,上述各个模块以任意组合的形式分别位于不同的处理器中。
处理器中包含内核,由内核去存储器中调取相应的程序单元。内核可以设置一个或以上,通过调整内核参数来提高云原生平台的资源利用率。
存储器可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM),存储器包括至少一个存储芯片。
本发明实施例提供了一种计算机可读存储介质,上述计算机可读存储介质包括存储的程序,其中,在上述程序运行时控制上述计算机可读存储介质所在设备执行上述云原生平台的业务执行方法。
具体地,云原生平台的业务执行方法包括:
步骤S201,获取多个当前业务的业务类型标签,将上述业务类型标签相同的一个或多个上述当前业务划分至同一个资源池,得到多个资源池,其中,上述业务类型标签为表征上述当前业务的类型的标签,且包括在线业务类型、离线业务类型和混合业务类型;
具体地,将平台中的节点(Node)划分为三种类型,并将它们放置在三个不同的资源池中。在线资源池存放在线业务类型的当前业务:该资源池包含具有label/service业务类型标签的节点,仅用于调度在线业务。这些节点专门为在线服务提供高可用性和低延迟的支持。离线资源池存放离线业务类型的当前业务:该资源池包含具有label/job业务类型标签的节点,仅用于调度离线业务。这些节点主要用于批处理作业和数据处理任务,其特点是对计算时间不敏感且对资源需求较高。混合资源池存放混合业务类型的在线业务:该资源池包含具有label/colocation业务类型标签的节点,可混合调度在线和离线业务。这些节点既能满足在线业务的低延迟需求,又能处理离线业务的高计算需求。混合资源池的引入允许用户逐步采用混合部署技术,将在线和离线业务逐渐整合在一起,以提高资源利用率和灵活性。混合部署并非一蹴而就,用户不需要立即将所有业务和服务器迁移到混合资源池。相反,用户可以根据需求逐步将一部分服务器迁移到混合资源池中,控制混合部署的进度和风险。随着混合部署技术的成熟和用户接受度的提高,我们计划逐渐缩小在线资源池和离线资源池的规模,扩大混合资源池的规模。然而,对于某些特殊情况下无法进行混合部署的在线业务,我们仍然支持将其部署在在线资源池中,而不需要强制要求所有业务都进行混合部署。这样的灵活性可以满足不同业务需求和风险偏好。
在将节点划分之前,首先把当前业务划分为在线业务类型和离线业务类型。在线业务一般是各类微服务,特点是延时敏感、有很高的可用性要求;离线业务一般是批处理任务,特点是延时不敏感、允许出错重跑。云原生混部属于计算密集型任务,具有运行时间短、允许失败重试的特点。在凌晨时段会触发大量的定时任务,刚好和在线任务形成错峰。可以通过在/离线混部技术将定时任务调度到在线集群,这样既提高了在线集群的资源使用率,又补充了定时任务高峰期时的算力缺口,极大地提升了服务器效率。离线间混部的离线集群整体CPU使用率较高,但部分时段也存在一定的资源闲置。由于都是离线任务,延时敏感性没有在线那么高,因此这类场景可以混部一些更庞大的大数据任务。实现大数据混部后,就可以做到各个离线业务互相出让资源,并解决了将Kubernetes(K8s)调度和Yarn调度(资源调度平台)进行协调的关键问题。
步骤S202,建立分级池化模型,根据上述分级池化模型确定每个上述资源池的优先级,其中,上述分级池化模型为预先根据上述资源池的优先级建立的且用于划分上述资源池的优先级的模型;
具体地,为了提高资源利用率和保障服务质量,采用分级池化模型,确定上述每个资源池的优先级。该模型包括资源分池动态管理和资源池优先级管理两个核心设计。资源分池动态管理是一种将节点资源划分为多个资源池并进行管理的方法。它通过实现资源池内部资源的高度共享,提高资源的复用率,并通过资源池之间的隔离来避免池间服务的干扰。资源池内的资源配置会根据服务负载的变化进行动态调整,以确保资源池的负载保持在相对稳定的范围内,从而保证服务的质量。这种方法能够灵活地管理和分配资源,提高资源利用率,并确保服务质量的同时实现资源的高效利用。资源池优先级管理机制是基于资源分池动态管理的基础上,通过设置不同优先级的资源池来确保业务的服务质量。在资源池优先级管理机制中,每个资源池具有不同的优先级,对应不同级别的服务质量保障。这种机制下,资源配置管理有以下三个区别:资源配置管理策略不同:不同优先级的资源池采用不同的资源配置管理策略。高优先级的资源池拥有充足的资源配置,负载维持在安全稳定的水平。通过资源池的资源隔离能力,高优先级资源池内部的服务资源使用被优先保障,从而提供更高的服务质量。资源隔离保障能力不同:高级别的资源池依托系统内核等提供的资源隔离能力,提供更高级别的资源池资源隔离级别。这意味着高优资源池可以享受更高级别的资源隔离,如独占CPU绑定、I/O隔离等,从而保障其内部服务不受池外服务的影响。优先级资源抢占机制:资源池的资源配置可以动态调整。当高优先级资源池配置资源不足或负载过高时,QoS服务质量保障机制会根据资源池的优先级,允许高优资源池抢占低优资源池已配置的资源。这样可以牺牲低优资源池的服务质量水平,优先保障高级别资源池的资源供给,从而确保高优服务的服务质量。因此,在分级池化的资源模型中,节点空闲资源首先被分配给优先级最低的资源池。其余资源池的资源配置由服务的资源需求、资源池资源配置管理策略以及资源池的负载情况决定。通过动态调整资源池的资源配置和优先级资源的抢占机制,能够确保资源池内的负载稳定,并根据优先级保障不同级别的服务质量。
步骤S203,按照上述优先级由大到小的顺序执行每个上述资源池中的上述当前业务。
具体地,在确定每个资源池的优先级之后,按照优先级由大到小的顺序执行当前业务。
可选地,上述方法还包括:通过第一CPU隔离策略确定上述当前业务使用的CPU内核,其中,上述第一CPU隔离策略用于对CPU进行粗粒度的隔离,上述粗粒度的隔离表示按照业务的类别划分;通过第二CPU隔离策略确定上述CPU内核的带宽,在上述CPU内核中以上述带宽执行上述当前业务,其中,上述第二CPU隔离策略用于对上述CPU进行细粒度的隔离,上述细粒度的隔离表示在上述类别划分的基础上进一步按照实例划分。
可选地,上述方法还包括:在上述当前业务类型为上述离线业务类型的情况下,计算上述云原生平台中多个节点的负载程度,其中,每个上述节点用于执行一个上述当前业务,上述负载程度表示每个上述当前业务所在的节点的负载大小;比较多个上述节点的负载程度的大小,在上述负载程度最小的上述节点上执行上述离线业务类型对应的上述当前业务。
可选地,上述方法还包括:在上述在线业务类型的上述当前业务的数量大于预设阈值的情况下,获取上述云原生平台中多个处于空闲状态的节点地址,得到空闲节点地址;将上述离线业务类型的上述当前业务发送至上述空闲节点地址对应的节点,在上述空闲节点地址对应的上述节点上执行上述离线业务类型对应的上述当前业务。
可选地,上述方法还包括:通过第一内存回收策略确定上述云原生平台中的内存参数,其中,上述第一内存回收策略用于确定上述云原生平台中使用的内存参数,上述内存参数至少包括内存限制参数;通过第二内存回收策略确定上述云原生平台的最大可用内存,其中,上述第二内存回收策略用于确定上述云原生平台的可用内存的最大值。
可选地,上述方法还包括:通过第一网络隔离策略获取上述云原生平台的流量参数,并根据上述流量参数计算上述云原生平台的网络流量,其中,上述第一网络隔离策略用于计算上述网络流量;通过第二网络隔离策略确定上述云原生平台的网络的队列规则,在上述队列规则下按照上述网络流量执行上述当前业务,其中,上述第二网络隔离策略用于按照上述队列规则对上述网络流量进行限制。
本发明实施例提供了一种设备,设备包括处理器、存储器及存储在存储器上并可在处理器上运行的程序,处理器执行程序时实现至少以下步骤:
步骤S201,获取多个当前业务的业务类型标签,将上述业务类型标签相同的一个或多个上述当前业务划分至同一个资源池,得到多个资源池,其中,上述业务类型标签为表征上述当前业务的类型的标签,且包括在线业务类型、离线业务类型和混合业务类型;
步骤S202,建立分级池化模型,根据上述分级池化模型确定每个上述资源池的优先级,其中,上述分级池化模型为预先根据上述资源池的优先级建立的且用于划分上述资源池的优先级的模型;
步骤S203,按照上述优先级由大到小的顺序执行每个上述资源池中的上述当前业务。
本文中的设备可以是服务器、PC、PAD、手机等。
可选地,上述方法还包括:通过第一CPU隔离策略确定上述当前业务使用的CPU内核,其中,上述第一CPU隔离策略用于对CPU进行粗粒度的隔离,上述粗粒度的隔离表示按照业务的类别划分;通过第二CPU隔离策略确定上述CPU内核的带宽,在上述CPU内核中以上述带宽执行上述当前业务,其中,上述第二CPU隔离策略用于对上述CPU进行细粒度的隔离,上述细粒度的隔离表示在上述类别划分的基础上进一步按照实例划分。
可选地,上述方法还包括:在上述当前业务类型为上述离线业务类型的情况下,计算上述云原生平台中多个节点的负载程度,其中,每个上述节点用于执行一个上述当前业务,上述负载程度表示每个上述当前业务所在的节点的负载大小;比较多个上述节点的负载程度的大小,在上述负载程度最小的上述节点上执行上述离线业务类型对应的上述当前业务。
可选地,上述方法还包括:在上述在线业务类型的上述当前业务的数量大于预设阈值的情况下,获取上述云原生平台中多个处于空闲状态的节点地址,得到空闲节点地址;将上述离线业务类型的上述当前业务发送至上述空闲节点地址对应的节点,在上述空闲节点地址对应的上述节点上执行上述离线业务类型对应的上述当前业务。
可选地,上述方法还包括:通过第一内存回收策略确定上述云原生平台中的内存参数,其中,上述第一内存回收策略用于确定上述云原生平台中使用的内存参数,上述内存参数至少包括内存限制参数;通过第二内存回收策略确定上述云原生平台的最大可用内存,其中,上述第二内存回收策略用于确定上述云原生平台的可用内存的最大值。
可选地,上述方法还包括:通过第一网络隔离策略获取上述云原生平台的流量参数,并根据上述流量参数计算上述云原生平台的网络流量,其中,上述第一网络隔离策略用于计算上述网络流量;通过第二网络隔离策略确定上述云原生平台的网络的队列规则,在上述队列规则下按照上述网络流量执行上述当前业务,其中,上述第二网络隔离策略用于按照上述队列规则对上述网络流量进行限制。
本申请还提供了一种云原生平台,上述云原生平台包括基础组件层、资源调度层、调度器层、重调度器层和节点管控层,上述云原生平台用于执行上述云原生平台的业务执行方法,包括如下步骤:
步骤S201,获取多个当前业务的业务类型标签,将上述业务类型标签相同的一个或多个上述当前业务划分至同一个资源池,得到多个资源池,其中,上述业务类型标签为表征上述当前业务的类型的标签,且包括在线业务类型、离线业务类型和混合业务类型;
步骤S202,建立分级池化模型,根据上述分级池化模型确定每个上述资源池的优先级,其中,上述分级池化模型为预先根据上述资源池的优先级建立的且用于划分上述资源池的优先级的模型;
步骤S203,按照上述优先级由大到小的顺序执行每个上述资源池中的上述当前业务。
显然,本领域的技术人员应该明白,上述的本发明的各模块或各步骤可以用通用的计算装置来实现,它们可以集中在单个的计算装置上,或者分布在多个计算装置所组成的网络上,它们可以用计算装置可执行的程序代码来实现,从而,可以将它们存储在存储装置中由计算装置来执行,并且在某些情况下,可以以不同于此处的顺序执行所示出或描述的步骤,或者将它们分别制作成各个集成电路模块,或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样,本发明不限制于任何特定的硬件和软件结合。
本领域内的技术人员应明白,本申请的实施例可提供为方法、系统、或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在一个典型的配置中,计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
存储器可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。存储器是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括要素的过程、方法、商品或者设备中还存在另外的相同要素。
从以上的描述中,可以看出,本申请上述的实施例实现了如下技术效果:
1)、本申请的云原生平台的业务执行方法中,获取多个当前业务的业务类型标签,将当前业务按照业务类型标签进行划分,得到多个资源池;并建立分级池化模型,根据上述分级池化模型确定每个上述资源池的优先级;最后按照优先级由大到小的顺序执行每个上述资源池中的上述当前业务。这样将当前业务按照业务类型进行划分,并按照优先级执行,最大化利用服务器的资源,与现有技术中,无法进行资源划分与优先级调度而造成资源利用率低的问题,本申请按照资源划分与优先级的调度执行业务,使平台服务器的资源被有效利用,因此,能够解决云原生平台的资源利用率低的问题,达到提高资源利用率的效果。
2)、本申请的云原生平台的业务执行装置中,获取多个当前业务的业务类型标签,将当前业务按照业务类型标签进行划分,得到多个资源池;并建立分级池化模型,根据上述分级池化模型确定每个上述资源池的优先级;最后按照优先级由大到小的顺序执行每个上述资源池中的上述当前业务。这样将当前业务按照业务类型进行划分,并按照优先级执行,最大化利用服务器的资源,与现有技术中,无法进行资源划分与优先级调度而造成资源利用率低的问题,本申请按照资源划分与优先级的调度执行业务,使平台服务器的资源被有效利用,因此,能够解决云原生平台的资源利用率低的问题,达到提高资源利用率的效果。
以上所述仅为本申请的优选实施例而已,并不用于限制本申请,对于本领域的技术人员来说,本申请可以有各种更改和变化。凡在本申请的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本申请的保护范围之内。
Claims (10)
1.一种云原生平台的业务执行方法,其特征在于,包括:
获取多个当前业务的业务类型标签,将所述业务类型标签相同的一个或多个所述当前业务划分至同一个资源池,得到多个资源池,其中,所述业务类型标签为表征所述当前业务的类型的标签,且包括在线业务类型、离线业务类型和混合业务类型;
建立分级池化模型,根据所述分级池化模型确定每个所述资源池的优先级,其中,所述分级池化模型为预先根据所述资源池的优先级建立的且用于划分所述资源池的优先级的模型;
按照所述优先级由大到小的顺序执行每个所述资源池中的所述当前业务。
2.根据权利要求1所述的业务执行方法,其特征在于,所述方法还包括:
通过第一CPU隔离策略确定所述当前业务使用的CPU内核,其中,所述第一CPU隔离策略用于对CPU进行粗粒度的隔离,所述粗粒度的隔离表示按照业务的类别划分;
通过第二CPU隔离策略确定所述CPU内核的带宽,在所述CPU内核中以所述带宽执行所述当前业务,其中,所述第二CPU隔离策略用于对所述CPU进行细粒度的隔离,所述细粒度的隔离表示在所述类别划分的基础上进一步按照实例划分。
3.根据权利要求1所述的业务执行方法,其特征在于,所述方法还包括:
在所述当前业务类型为所述离线业务类型的情况下,计算所述云原生平台中多个节点的负载程度,其中,每个所述节点用于执行一个所述当前业务,所述负载程度表示每个所述当前业务所在的节点的负载大小;
比较多个所述节点的负载程度的大小,在所述负载程度最小的所述节点上执行所述离线业务类型对应的所述当前业务。
4.根据权利要求1所述的业务执行方法,其特征在于,所述方法还包括:
在所述在线业务类型的所述当前业务的数量大于预设阈值的情况下,获取所述云原生平台中多个处于空闲状态的节点地址,得到空闲节点地址;
将所述离线业务类型的所述当前业务发送至所述空闲节点地址对应的节点,在所述空闲节点地址对应的所述节点上执行所述离线业务类型对应的所述当前业务。
5.根据权利要求1所述的业务执行方法,其特征在于,所述方法还包括:
通过第一内存回收策略确定所述云原生平台中的内存参数,其中,所述第一内存回收策略用于确定所述云原生平台中使用的内存参数,所述内存参数至少包括内存限制参数;
通过第二内存回收策略确定所述云原生平台的最大可用内存,其中,所述第二内存回收策略用于确定所述云原生平台的可用内存的最大值。
6.根据权利要求1所述的业务执行方法,其特征在于,所述方法还包括:
通过第一网络隔离策略获取所述云原生平台的流量参数,并根据所述流量参数计算所述云原生平台的网络流量,其中,所述第一网络隔离策略用于计算所述网络流量;
通过第二网络隔离策略确定所述云原生平台的网络的队列规则,在所述队列规则下按照所述网络流量执行所述当前业务,其中,所述第二网络隔离策略用于按照所述队列规则对所述网络流量进行限制。
7.一种云原生平台的业务执行装置,其特征在于,包括:
划分单元,用于获取多个当前业务的业务类型标签,将所述业务类型标签相同的一个或多个所述当前业务划分至同一个资源池,得到多个资源池,其中,所述业务类型标签为表征所述当前业务的类型的标签,且包括在线业务类型、离线业务类型和混合业务类型;
第一确定单元,用于建立分级池化模型,根据所述分级池化模型确定每个所述资源池的优先级,其中,所述分级池化模型为预先根据所述资源池的优先级建立的且用于划分所述资源池的优先级的模型;
第一执行单元,用于按照所述优先级由大到小的顺序执行每个所述资源池中的所述当前业务。
8.一种云原生平台,其特征在于,所述云原生平台包括基础组件层、资源调度层、调度器层、重调度器层和节点管控层,所述云原生平台用于执行权利要求1至6中任意一项所述的业务执行方法。
9.一种计算机可读存储介质,其特征在于,所述计算机可读存储介质包括存储的程序,其中,在所述程序运行时控制所述计算机可读存储介质所在设备执行权利要求1至6中任意一项所述的业务执行方法。
10.一种电子设备,其特征在于,包括:一个或多个处理器,存储器,以及一个或多个程序,其中,所述一个或多个程序被存储在所述存储器中,并且被配置为由所述一个或多个处理器执行,所述一个或多个程序包括用于执行权利要求1至6中任意一项所述的业务执行方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202311193782.0A CN117176818A (zh) | 2023-09-14 | 2023-09-14 | 云原生平台的业务执行方法、执行装置和电子设备 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202311193782.0A CN117176818A (zh) | 2023-09-14 | 2023-09-14 | 云原生平台的业务执行方法、执行装置和电子设备 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN117176818A true CN117176818A (zh) | 2023-12-05 |
Family
ID=88929578
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202311193782.0A Pending CN117176818A (zh) | 2023-09-14 | 2023-09-14 | 云原生平台的业务执行方法、执行装置和电子设备 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN117176818A (zh) |
-
2023
- 2023-09-14 CN CN202311193782.0A patent/CN117176818A/zh active Pending
Similar Documents
Publication | Publication Date | Title |
---|---|---|
Pietri et al. | Mapping virtual machines onto physical machines in cloud computing: A survey | |
CN107003887B (zh) | Cpu超载设置和云计算工作负荷调度机构 | |
Javadi et al. | Scavenger: A black-box batch workload resource manager for improving utilization in cloud environments | |
US20230229495A1 (en) | Task scheduling method and apparatus | |
CN107222531B (zh) | 一种容器云资源调度方法 | |
WO2016078178A1 (zh) | 一种虚拟cpu调度方法 | |
CN109564528B (zh) | 分布式计算中计算资源分配的系统和方法 | |
Nithya et al. | SDCF: A software-defined cyber foraging framework for cloudlet environment | |
CN110221920B (zh) | 部署方法、装置、存储介质及系统 | |
US10630600B2 (en) | Adaptive network input-output control in virtual environments | |
WO2024120205A1 (zh) | 一种应用性能优化方法、装置、电子设备及存储介质 | |
CN110086726A (zh) | 一种自动切换Kubernetes主节点的方法 | |
WO2023174037A1 (zh) | 资源调度方法、装置、系统、设备、介质和程序产品 | |
Luo et al. | Erms: Efficient resource management for shared microservices with SLA guarantees | |
Xu et al. | Ibis: interposed big-data i/o scheduler | |
Nicodemus et al. | Managing vertical memory elasticity in containers | |
Wu et al. | ABP scheduler: Speeding up service spread in docker swarm | |
CN106775925B (zh) | 一种虚拟机cpu的限额处理方法和装置 | |
Klusáček et al. | Scheduling scientific workloads in private cloud: problems and approaches | |
CN117176818A (zh) | 云原生平台的业务执行方法、执行装置和电子设备 | |
CN115766582A (zh) | 流量控制方法、装置和系统、介质和计算机设备 | |
WO2022177455A1 (en) | Method and system for optimizing resource and traffic management of a computer execution environment in a vran | |
CN115774614A (zh) | 资源调控方法、终端及存储介质 | |
CN115878303A (zh) | 一种资源调度方法、装置及电子设备 | |
Monaco et al. | Extensions for shared resource orchestration in Kubernetes to support RT-cloud containers |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination |