1.本公开涉及容器集群
技术领域：
：，尤其涉及一种资源调度方法、装置、电子设备和计算机可读存储介质。
背景技术：
：：2.kubernetes是一个全新的基于容器技术的分布式领先方案，简称：k8s。它是google开源的容器集群管理系统，它的设计灵感来自于google内部的一个叫作borg的容器管理系统，继承了google十余年的容器集群使用经验。kubernetes为容器化的应用提供了部署运行、资源调度、服务发现和动态伸缩等一些列完整的功能，极大地提高了大规模容器集群管理的便捷性。3.在集群管理方面，kubernetes将集群中的机器划分为一个master节点和一群工作节点node，每个node上可以有多个pod，pod表示一组一个或多个应用程序容器(如docker或rkt)，以及这些容器的一些共享资源。node能够汇总其上pod的各个容器的资源请求，并与master通信。在master则运行着集群管理相关的一组进程，这些进程实现了整个集群的资源管理、pod调度等管理能力，能够将cpu、内存等资源分配给各个容器，实现容器的运行。4.但kubernetes使用的是静态调度，静态调度是指根据容器请求的资源进行装箱调度。静态调度最大的优点就是调度简单高效、集群资源管理方便，但在实际环境中，业务在选择容器规格时带有一定的主观性和盲目性，为了保证业务稳定性，业务会申请远大于其实际资源使用量的资源，导致业务容器的资源利用率很低，这样的业务占比一大，就容易导致集群资源利用率低的情况。技术实现要素：5.本公开提供一种资源调度方法、装置、电子设备和计算机可读存储介质，以至少解决相关技术中的集群资源利用率低的问题，也可不解决任何上述问题。6.根据本公开的第一方面，提供了一种资源调度方法，所述资源调度方法包括：获取容器集群的目标节点的历史资源利用率和初始配置资源量；根据所述历史资源利用率，确定所述目标节点的资源超卖系数；其中，所述资源超卖系数是基于所述初始配置资源量进行超卖后的资源量的倍数，当所述历史资源利用率小于预设资源利用率时，所述资源超卖系数与所述历史资源利用率负相关；根据所述资源超卖系数和所述初始配置资源量，确定所述目标节点的可调度资源量。7.可选地，所述根据所述历史资源利用率，确定所述目标节点的资源超卖系数的步骤，包括：若所述历史资源利用率小于所述预设资源利用率，获取所述目标节点的超卖常数，并对所述历史资源利用率进行指数化处理，得到指数化值，将所述超卖常数与所述指数化值的差值作为所述资源超卖系数；其中，所述超卖常数是预定的资源超卖系数最大值与所述指数化值的最小值的和值；若所述历史资源利用率大于或等于所述预设资源利用率，确定所述资源超卖系数为1。8.可选地，所述对所述历史资源利用率进行指数化处理，得到指数化值的步骤，包括：确定所述历史资源利用率与第一参数的乘积；以第二参数为底数、以所述乘积为指数，确定所述指数化值；其中，所述第一参数为正值，且所述第二参数大于1，或所述第一参数为负值，且所述第二参数小于1。9.可选地，在所述根据所述资源超卖系数和所述初始配置资源量，确定所述目标节点的可调度资源量的步骤之后，所述资源调度方法还包括：获取所述目标节点对应的容器集合的已部署资源量；若确定所述已部署资源量大于或等于所述可调度资源量，根据所述已部署资源量和所述初始配置资源量，重新确定所述资源超卖系数，并返回所述根据所述资源超卖系数和所述初始配置资源量，确定所述目标节点的可调度资源量的步骤。10.可选地，所述根据所述已部署资源量和所述初始配置资源量，重新确定所述资源超卖系数的步骤，包括：确定所述已部署资源量和所述初始配置资源量的比值，作为更新的所述资源超卖系数。11.可选地，在所述获取容器集群的目标节点的历史资源利用率和初始配置资源量的步骤之前，所述资源调度方法还包括：响应于拦截到节点信息，将所述节点信息对应的节点确定为目标节点；在所述根据所述资源超卖系数和所述初始配置资源量，确定所述目标节点的可调度资源量的步骤之后，所述资源调度方法还包括：更新所述节点信息中的可调度资源量，并上报更新后的节点信息。12.根据本公开的第二方面，提供了一种资源调度装置，所述资源调度装置包括：获取单元，被配置为执行：获取容器集群的目标节点的历史资源利用率和初始配置资源量；系数确定单元，被配置为执行：根据所述历史资源利用率，确定所述目标节点的资源超卖系数；其中，所述资源超卖系数是基于所述初始配置资源量进行超卖后的资源量的倍数，当所述历史资源利用率小于预设资源利用率时，所述资源超卖系数与所述历史资源利用率负相关；调度确定单元，被配置为执行：根据所述资源超卖系数和所述初始配置资源量，确定所述目标节点的可调度资源量。13.可选地，所述系数确定单元还被配置为执行：若所述历史资源利用率小于所述预设资源利用率，获取所述目标节点的超卖常数，并对所述历史资源利用率进行指数化处理，得到指数化值，将所述超卖常数与所述指数化值的差值作为所述资源超卖系数；其中，所述超卖常数是预定的资源超卖系数最大值与所述指数化值的最小值的和值；若所述历史资源利用率大于或等于所述预设资源利用率，确定所述资源超卖系数为1。14.可选地，所述系数确定单元还被配置为执行：确定所述历史资源利用率与第一参数的乘积；以第二参数为底数、以所述乘积为指数，确定所述指数化值；其中，所述第一参数为正值，且所述第二参数大于1，或所述第一参数为负值，且所述第二参数小于1。15.可选地，所述获取单元还被配置为执行：获取所述目标节点对应的容器集合的已部署资源量；所述系数确定单元还被配置为执行：若确定所述已部署资源量大于或等于所述可调度资源量，根据所述已部署资源量和所述初始配置资源量，重新确定所述资源超卖系数，并运行所述调度确定单元。16.可选地，所述系数确定单元还被配置为执行：确定所述已部署资源量和所述初始配置资源量的比值，作为更新的所述资源超卖系数。17.可选地，所述资源调度装置还包括：拦截单元，被配置为执行：响应于拦截到节点信息，将所述节点信息对应的节点确定为目标节点；更新单元，被配置为执行：更新所述节点信息中的可调度资源量，并上报更新后的节点信息。18.根据本公开的第三方面，提供了一种电子设备，电子设备包括：至少一个处理器；至少一个存储计算机可执行指令的存储器，其中，计算机可执行指令在被至少一个处理器运行时，促使至少一个处理器执行根据本公开的资源调度方法。19.根据本公开的第四方面，提供了一种计算机可读存储介质，当计算机可读存储介质中的指令被电子设备的至少一个处理器运行时，促使电子设备执行根据本公开的资源调度方法。20.根据本公开的第五方面，提供了一种计算机程序产品，包括计算机指令，计算机指令被至少一个处理器执行时实现根据本公开的资源调度方法。21.本公开的实施例提供的技术方案至少带来以下有益效果：22.根据本公开的实施例的资源调度方法和资源调度装置，通过根据目标节点的历史资源利用率确定资源超卖系数和相应的可调度资源量，可考虑目标节点的实际负载，在历史资源利用率较低、目标节点此前的请求资源量虚高的情况下，适当为目标节点分配超过实际供应能力的资源量，使得目标节点能够为pod和容器提供更多的虚拟资源，有助于部署更多的pod和容器，从而提升目标节点的资源利用率，使得目标节点的资源尽可能被利用；在历史资源利用率较高、目标节点此前的请求资源量相对合理的情况下，适当减少资源超卖，防止资源超卖过度，有助于在超卖资源的同时保障集群服务的稳定性。23.应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。附图说明24.此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理，并不构成对本公开的不当限定。25.图1是示出相关技术中的资源请求量与实际资源使用量的关系图。26.图2是示出根据本公开的示例性实施例的资源调度方法的流程图。27.图3是示出根据本公开的示例性实施例的资源调度方法的数据流示意图。28.图4是示出根据本公开的示例性实施例的可调度资源量示意图。29.图5是示出根据本公开的示例性实施例的cpu超卖系数和内存超卖系数的变化趋势曲线。30.图6是示出根据本公开的示例性实施例的资源调度装置的框图。31.图7是示出根据本公开的示例性实施例的电子设备的框图。具体实施方式32.为了使本领域普通人员更好地理解本公开的技术方案，下面将结合附图，对本公开实施例中的技术方案进行清楚、完整地描述。33.需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本公开的实施例能够以除了在这里图示或描述的那些以外的顺序实施。以下实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。34.在此需要说明的是，在本公开中出现的“若干项之中的至少一项”均表示包含“该若干项中的任意一项”、“该若干项中的任意多项的组合”、“该若干项的全体”这三类并列的情况。例如“包括a和b之中的至少一个”即包括如下三种并列的情况：(1)包括a；(2)包括b；(3)包括a和b。又例如“执行步骤一和步骤二之中的至少一个”，即表示如下三种并列的情况：(1)执行步骤一；(2)执行步骤二；(3)执行步骤一和步骤二。35.容器化技术是指有效地将单个操作系统的资源划分到孤立的组中，以便更好地在孤立的组之间平衡有冲突的资源使用需求的技术。不同于把服务器、存储设备等网络资源整合成资源池后进行分割的虚拟化技术，在容器化技术中，被容器化的应用是直接运行在物理机之上的，因此能使得物理机充分发挥其性能，可提高硬件使用效率。同样得益于容器化技术，即使物理机宕机，也可以通过之前的备份进行还原，不至于产生难以挽回的后果。36.容器化是当今主流趋势，有足够多的开源工具供参考使用，kubernetes就是其中之一，kubernetes是一个基于容器技术的容器编排工具，他提供足够强大的功能方便我们进行开发运维并根据场景需要进行自行开发。从而减小了开发及运维难度，节约了运维成本。37.kubernetes将集群中的机器划分为一个master节点和一群工作节点node，每个node上可以有多个pod，pod表示一组一个或多个应用程序容器(如docker或rkt)，以及这些容器的一些共享资源。node能够汇总其上pod的各个容器的资源请求，并与master通信。在master则运行着集群管理相关的一组进程，这些进程实现了整个集群的资源管理、pod调度等管理能力，能够将cpu、内存等资源分配给各个容器，实现容器的运行。38.但kubernetes使用的是静态调度，静态调度是指根据容器请求的资源进行装箱调度，而不考虑node的实际负载。静态调度最大的优点就是调度简单高效、集群资源管理方便，最大的缺点也很明显，就是不管节点实际负载，极容易导致集群负载不高。而在实际环境中，业务在选择容器规格时带有一定的主观性和盲目性，如图1所示，为了保证业务稳定性，业务会申请远大于其实际资源使用量的资源(requests＞＞reality)，导致业务容器的资源利用率很低，这样的业务占比一大，就容易导致集群资源利用率低的情况。同时，如图1所示，业务申请的资源量过大，甚至接近可供调度的资源量上限(limits》requests)，又会导致集群按照kubernetes静态调度策略无法再容纳更多的业务容器，进一步制约了集群资源利用率。39.因此，本公开提供了一种资源调度方法、装置、电子设备和计算机可读存储介质，通过根据目标节点的历史资源利用率确定资源超卖系数和相应的可调度资源量，可考虑目标节点的实际负载，在历史资源利用率较低、目标节点此前的请求资源量虚高的情况下，适当为目标节点分配超过实际供应能力的资源量，使得目标节点能够为pod和容器提供更多的虚拟资源，有助于部署更多的pod和容器，从而提升目标节点的资源利用率，使得目标节点的资源尽可能被利用；在历史资源利用率较高、目标节点此前的请求资源量相对合理的情况下，适当减少资源超卖，防止资源超卖过度，有助于在超卖资源的同时保障集群服务的稳定性。40.下面，将参照图2至图7具体描述根据本公开的示例性实施例的资源调度方法和资源调度装置。41.图2是示出根据本公开的示例性实施例的资源调度方法的流程图。应理解，根据本公开的示例性实施例的资源调度方法可以在诸如智能手机、平板电脑、个人电脑(pc)的终端设备中实现，也可以在诸如服务器的设备中实现。42.参照图2，在步骤201，获取容器集群的目标节点的历史资源利用率和初始配置资源量。43.目标节点是当前需要调整其可调度资源量的node节点，可调度资源量是指可供pod调度的资源量。在相关技术的静态调度中，可调度资源量就是目标节点的初始配置资源量，也就是未进行资源超卖前的可调度资源量，由划分到目标节点的物理机的资源量决定。历史资源利用率反映了目标节点对应的各个pod(归根结底是各个容器)对所调度的资源量的利用率，可通过计算实际资源使用量与被调度的资源量的比值(参照图1，即为reality/requests)得到。需说明的是，为实现可调度资源量的动态调整，可以每隔设定时长就获取过去一段时间(即过去的设定时长对应的时段)的资源利用率的平均值，作为过去这段时间的历史资源利用率，即历史资源利用率是动态更新的，所以可以在后续步骤中持续更新可调度资源量。作为示例，可以每隔5分钟就获取过去5分钟内目标节点的资源利用率的最大值和最小值，并求取平均值，作为过去5分钟的历史资源利用率。44.可选地，对于目标节点，在步骤201之前，根据本公开的示例性实施例的资源调度方法还可包括：响应于拦截到节点信息，将节点信息对应的节点确定为目标节点。节点信息具体可以是反映节点的请求资源量的信息，准确地说，是节点对应的pod和容器的请求资源量，通过拦截节点上传的节点信息，能够在节点发出资源请求时及时拦截，从而有针对性地对相应节点进行资源超卖。相应地，在后续步骤按照资源超卖确定出可调度资源量后，根据本公开的示例性实施例的资源调度方法还可包括：更新节点信息中的可调度资源量，并上报更新后的节点信息。通过将更新后的节点信息进行上报，可保障数据流完整，同时，通过直接更新节点信息中的可调度资源量，也就是将可调度资源量从初始配置资源量更新为后续步骤确定出的可调度资源量，能够借助现有的节点信息完成动态化的资源调度，降低改进成本。应理解，还可在节点信息中单独保存初始配置资源量，以供持续更新可调度资源量使用。45.作为示例，在kubernetes中，master节点运行着集群管理相关的一组进程，其中包括了kube-apiserver、kube-controller-manager。前者可提供各类资源对象的增删改查，后者可实现集群状态的监控，根据本公开的示例性实施例的资源调度方法就可基于kube-controller-manager实现。此外，参照图3，node节点运行着kubelet，kubelet负责master节点和node节点间的通信，并可管理pod和容器，node节点的kubelet会向apiserver上报节点信息，根据本公开的示例性实施例即可对此节点信息进行拦截，并进行如下操作：将未超卖前该节点的可调度资源量(即初始配置资源量)写入该节点的annotation字段中，便于进行对照；此后每隔设定时长获取历史资源利用率，以执行后续步骤202，并将得到的资源超卖系数写入该节点的annotation字段；将获取的历史资源利用率写入该节点的annotation字段，便于进行观察以及配合调度。46.在步骤202，根据历史资源利用率，确定目标节点的资源超卖系数。其中，资源超卖系数是基于初始配置资源量进行超卖后的资源量的倍数，当历史资源利用率小于预设资源利用率时，资源超卖系数与历史资源利用率负相关。参照图3和图4，资源超卖系数为resourceoversellrate，则将初始配置资源量noderesource扩大相应倍数，作为可调度资源量noderesourceallocatable。历史资源利用率能够反映此前(例如前述的过去5分钟内)目标节点对资源的实际利用情况，通过在历史资源利用率小于预设资源利用率时，令资源超卖系数与历史资源利用率负相关，能够考虑目标节点的实际负载，在历史资源利用率较低、目标节点此前的请求资源量虚高的情况下，适当为目标节点分配超过实际供应能力的可调度资源量，使得目标节点能够为pod和容器提供更多的虚拟资源，有助于部署更多的pod和容器，从而提升目标节点的资源利用率，使得目标节点的资源尽可能被利用。在历史资源利用率较高、目标节点此前的请求资源量相对合理的情况下，适当减少资源超卖，即减少可调度资源量，能够实现合理的资源超卖，防止资源超卖过度，有助于在超卖资源的同时保障集群服务的稳定性。47.可选地，预设资源利用率小于1，而历史资源利用率在0到1之间变化，这表明资源超卖系数仅在历史资源利用率取值相对较小时，与历史资源利用率负相关。也就是说，在历史资源利用率尚低时，历史资源利用率越高，资源超卖系数越低。在历史资源利用率达到预设资源利用率后，考虑到目标节点的请求资源量已较为合理，可将资源超卖系数保持为1，不再进行资源超卖，以保障系统稳定性。需说明的是，预设资源利用率可以根据实际的运行情况确定，例如可为55％，本公开对此不作限制。48.具体地，对于历史资源利用率小于预设资源利用率的情况，步骤202可获取目标节点的超卖常数，并对历史资源利用率进行指数化处理，得到指数化值，将超卖常数与指数化值的差值作为资源超卖系数。换言之，资源超卖系数是超卖常数与指数化值的差值。其中，超卖常数是预定的资源超卖系数最大值与指数化值的最小值的和值，预定的资源超卖系数最大值则是对当前集群的资源利用情况进行分析后确定的，本公开对具体的分析方式不作限制。受限于前文限定的在历史资源利用率小于预设资源利用率时，资源超卖系数与历史资源利用率负相关，使得此处的指数化值与历史资源利用率正相关，也就是指数化值随着历史资源利用率的增大而逐渐增大，而指数化值本身具备增速逐渐加快的性能，使得资源超卖系数的取值在随着历史资源利用率的增大而逐渐减小时，其减小的速度逐渐加快，能够在资源利用率升高后迅速减少资源超卖系数，从而防止资源超卖过度，有助于保障集群服务的稳定性。49.可选地，对历史资源利用率进行指数化处理，得到指数化值的步骤可包括：确定历史资源利用率与第一参数的乘积；以第二参数为底数、以乘积为指数，确定指数化值。也就是满足y＝bax，z＝c-bax，其中x为历史资源利用率，y为指数化值，z为资源超卖系数，a为第一参数，b为第二参数，c为超卖常数。ba实质上构成指数化值的底数，相应地，x构成指数化值的指数。其中，第一参数a为正值，且第二参数b大于1(例如为自然常数e)，或第一参数a为负值，且第二参数b小于1(例如为自然常数e的倒数1/e)，可充分保障ba大于1，使得指数化值y随着历史资源利用率x的增大而增大。此外，将指数化值的底数拆分为第一参数和第二参数，可以通过为所有的资源调度场景选用统一的第二参数b，实现底数的统一，再通过确定适宜的第一参数a来为指数化值配置合理的、实质上的底数ba，一方面，相较于直接取值或使用科学计数法，ba的形式可以在第一参数a取小数点后同样多位数值的情况下保留更多的数值细节，有助于在保障计算精度的同时降低资源超卖系数计算公式的存储负担，另一方面，可减少不同的计算公式形式上的差异。具体到各个参数的确定，理论上来说，历史资源利用率x为0时，资源超卖系数z可以取到最大，当历史资源利用率x为0时，指数化值y稳定为1，可以将资源超卖系数的合理最大值增加1，作为超卖常数c，便于实现超卖常数c的确定。在确定超卖常数c后，如前所述，在历史资源利用率x达到预设资源利用率(例如55％)后，可将资源超卖系数z保持为1，基于此，可将超卖常数c、x＝预设资源利用率、z＝1带入公式z＝c-bax，从而确定实质上的底数ba的取值，该取值决定了指数化值的变化速度。基于确定的ba，就可以在选定第二参数b后，通过对ba求对数得到第一参数a。具体来说，在ba一定的情况下，第二参数b的取值越大，则第一参数a发生同样幅度的增减时，ba发生的增减幅度会越大，从而保留更多的数值细节，但b的取值过大也会导致a需要在小数点后取足够多位数值才能体现ba的变化，同样会增加存储负担，过犹不及。所以第二参数b的合理取值也有助于保留更多的数值细节。作为示例，第二参数b为自然常数e。50.具体地，待调度的资源可包括cpu和内存，相应地，可在步骤201获取目标节点的历史cpu利用率cpuutilization、初始配置的cpu资源量nodecpu、历史内存利用率memoryutilization、初始配置的内存资源量nodememory，并参照上述公式z＝c-bax，在步骤202根据历史cpu利用率cpuutilization确定cpu超卖系数cpuoversellrate，根据历史内存利用率memoryutilization确定内存超卖系数memoryoversellrate，例如采用如下公式：[0051][0052][0053]由上述公式绘制的cpu超卖系数和内存超卖系数的变化趋势曲线如图5所示。[0054]在步骤203，根据资源超卖系数和初始配置资源量，确定目标节点的可调度资源量。[0055]具体地，参照图3和图4以及前文论述，通过计算资源超卖系数和初始配置资源量的乘积，即可得到目标节点的可调度资源量。参照图5的示例，可采用如下公式计算可调度的cpu资源量nodecpuallocatable和可调度的内存资源量nodememoryallocatable∶[0056]nodecpuallocatable＝nodecpu×cpuoversellrate[0057]nodememoryallocatable＝nodememory×memoryoversellrate[0058]进一步地，在步骤203之后，根据本公开的示例性实施例的资源调度方法还包括：获取目标节点对应的容器集合的已部署资源量，若确定已部署资源量大于或等于可调度资源量，根据已部署资源量和初始配置资源量，重新确定资源超卖系数，并返回步骤203。在系统的资源利用率突然大幅增加时，步骤202确定的资源超卖系数会呈下降趋势，此时可能出现目标节点中已部署的容器集合的已部署资源量(统计的具体是已部署的pod的已部署资源量之和)大于或等于目标节点当前的可调度资源量的情况。此时，通过结合实际的已部署资源量和初始配置资源量重新确定资源超卖系数，能够令新确定的可调度资源量满足当前已部署的容器的运行，保障服务稳定性。[0059]具体地，根据已部署资源量和初始配置资源量，重新确定资源超卖系数的步骤包括：确定已部署资源量和初始配置资源量的比值，作为更新的资源超卖系数，可令由此相应更新的可调度资源量刚好等于已部署的容器集合的已部署资源量，也就没有多余的资源再分配给其他pod和容器，可不再部署新的pod和容器，能够保障已部署的pod和容器不被驱逐，从而可靠地保障了服务稳定性。仍以cpu和内存为例，则更新的cpu超卖系数和内存超卖系数为：[0060][0061][0062]其中，∑podcpurequest为已部署的各个pod的已部署cpu资源量之和，∑podmemoryrequest为已部署的各个pod的已部署内存资源量之和。[0063]图6是示出根据本公开的示例性实施例的资源调度装置的框图。应理解，根据本公开的示例性实施例的资源调度装置可以在诸如智能手机、平板电脑、个人电脑(pc)的终端设备中以软件、硬件或软件硬件结合的方式实现，也可以在诸如服务器的设备中实现。[0064]参照图6，资源调度装置600包括获取单元601、系数确定单元602、调度确定单元603。[0065]获取单元601获取容器集群的目标节点的历史资源利用率和初始配置资源量。[0066]目标节点是当前需要调整其可调度资源量的node节点，可调度资源量是指可供pod调度的资源量。在相关技术的静态调度中，可调度资源量就是目标节点的初始配置资源量，也就是未进行资源超卖前的可调度资源量，由划分到目标节点的物理机的资源量决定。历史资源利用率反映了目标节点对应的各个pod(归根结底是各个容器)对所调度的资源量的利用率，可通过计算实际资源使用量与被调度的资源量的比值(参照图1，即为reality/requests)得到。需说明的是，为实现可调度资源量的动态调整，可以每隔设定时长就获取过去一段时间(即过去的设定时长对应的时段)的资源利用率的平均值，作为过去这段时间的历史资源利用率，即历史资源利用率是动态更新的，所以可以在后续操作中持续更新可调度资源量。作为示例，可以每隔5分钟就获取过去5分钟内目标节点的资源利用率的最大值和最小值，并求取平均值，作为过去5分钟的历史资源利用率。[0067]可选地，根据本公开的示例性实施例的资源调度装置600还可包括拦截单元(图中未示出)，在获取单元601运行之前，拦截单元可响应于拦截到节点信息，将节点信息对应的节点确定为目标节点。节点信息具体可以是反映节点的请求资源量的信息，准确地说，是节点对应的pod和容器的请求资源量，通过拦截节点上传的节点信息，能够在节点发出资源请求时及时拦截，从而有针对性地对相应节点进行资源超卖。相应地，根据本公开的示例性实施例的资源调度装置600还可包括更新单元(图中未示出)，更新单元可在系数确定单元602和调度确定单元603确定出可调度资源量后，更新节点信息中的可调度资源量，并上报更新后的节点信息。通过将更新后的节点信息进行上报，可保障数据流完整，同时，通过直接更新节点信息中的可调度资源量，也就是将可调度资源量从初始配置资源量更新为后续步骤确定出的可调度资源量，能够借助现有的节点信息完成动态化的资源调度，降低改进成本。应理解，还可在节点信息中单独保存初始配置资源量，以供持续更新可调度资源量使用。[0068]作为示例，在kubernetes中，master节点运行着集群管理相关的一组进程，其中包括了kube-apiserver、kube-controller-manager。前者可提供各类资源对象的增删改查，后者可实现集群状态的监控，根据本公开的示例性实施例的资源调度装置600就可基于kube-controller-manager实现。此外，参照图3，node节点运行着kubelet，kubelet负责master节点和node节点间的通信，并可管理pod和容器，node节点的kubelet会向apiserver上报节点信息，根据本公开的示例性实施例即可对此节点信息进行拦截，并进行如下操作：将未超卖前该节点的可调度资源量(即初始配置资源量)写入该节点的annotation字段中，便于进行对照；此后每隔设定时长获取历史资源利用率，以运行系数确定单元602，并将得到的资源超卖系数写入该节点的annotation字段；将获取的历史资源利用率写入该节点的annotation字段，便于进行观察以及配合调度。[0069]系数确定单元602可根据历史资源利用率，确定目标节点的资源超卖系数。其中，资源超卖系数是基于初始配置资源量进行超卖后的资源量的倍数，当历史资源利用率小于预设资源利用率时，资源超卖系数与历史资源利用率负相关。参照图3和图4，资源超卖系数可为超额分配的资源量倍数resourceoversellrate，则将初始配置资源量noderesource扩大相应倍数，作为可调度资源量noderesourceallocatable。历史资源利用率能够反映此前(例如前述的过去5分钟内)目标节点对资源的实际利用情况，通过在历史资源利用率小于预设资源利用率时，令资源超卖系数与历史资源利用率负相关，能够考虑目标节点的实际负载，在历史资源利用率较低、目标节点此前的请求资源量虚高的情况下，适当为目标节点分配超过实际供应能力的可调度资源量，使得目标节点能够为pod和容器提供更多的虚拟资源，有助于部署更多的pod和容器，从而提升目标节点的资源利用率，使得目标节点的资源尽可能被利用。在历史资源利用率较高、目标节点此前的请求资源量相对合理的情况下，适当减少资源超卖，即减少可调度资源量，能够实现合理的资源超卖，防止资源超卖过度，有助于在超卖资源的同时保障集群服务的稳定性。[0070]可选地，预设资源利用率小于1，而历史资源利用率在0到1之间变化，这表明资源超卖系数仅在历史资源利用率取值相对较小时，与历史资源利用率负相关。也就是说，在历史资源利用率尚低时，历史资源利用率越高，资源超卖系数越低。在历史资源利用率达到预设资源利用率后，考虑到目标节点的请求资源量已较为合理，可将资源超卖系数保持为1，不再进行资源超卖，以保障系统稳定性。需说明的是，预设资源利用率可以根据实际的运行情况确定，例如可为55％，本公开对此不作限制。[0071]具体地，对于历史资源利用率小于预设资源利用率的情况，系数确定单元602可获取目标节点的超卖常数，并对历史资源利用率进行指数化处理，得到指数化值，将超卖常数与指数化值的差值作为资源超卖系数。换言之，资源超卖系数是超卖常数与指数化值的差值。其中，超卖常数是预定的资源超卖系数最大值与指数化值的最小值的和值，预定的资源超卖系数最大值则是对当前集群的资源利用情况进行分析后确定的，本公开对具体的分析方式不作限制。受限于前文限定的在历史资源利用率的设定区间内，资源超卖系数与历史资源利用率负相关，使得此处的指数化值与历史资源利用率正相关，也就是指数化值随着历史资源利用率的增大而逐渐增大，而指数化值本身具备增速逐渐加快的性能，使得资源超卖系数的取值在随着历史资源利用率的增大而逐渐减小时，其减小的速度逐渐加快，能够在资源利用率升高后迅速减少资源超卖系数，从而防止资源超卖过度，有助于保障集群服务的稳定性。[0072]可选地，系数确定单元602对历史资源利用率进行指数化处理，得到指数化值的操作可包括：确定历史资源利用率与第一参数的乘积；以第二参数为底数、以乘积为指数，确定指数化值。也就是满足y＝bax，z＝c-bax，其中x为历史资源利用率，y为指数化值，z为资源超卖系数，a为第一参数，b为第二参数，c为超卖常数。ba实质上构成指数化值的底数，相应地，x构成指数化值的指数。其中，第一参数a为正值，且第二参数b大于1(例如为自然常数e)，或第一参数a为负值，且第二参数b小于1(例如为自然常数e的倒数1/e)，可充分保障ba大于1，使得指数化值y随着历史资源利用率x的增大而增大。此外，将指数化值的底数拆分为第一参数和第二参数，可以通过为所有的资源调度场景选用统一的第二参数b，实现底数的统一，再通过确定适宜的第一参数a来为指数化值配置合理的、实质上的底数ba，一方面，相较于直接取值或使用科学计数法，ba的形式可以在第一参数a取小数点后同样多位数值的情况下保留更多的数值细节，有助于在保障计算精度的同时降低资源超卖系数计算公式的存储负担，另一方面，可减少不同的计算公式形式上的差异。具体到各个参数的确定，理论上来说，历史资源利用率x为0时，资源超卖系数z可以取到最大，当历史资源利用率x为0时，指数化值y稳定为1，可以将资源超卖系数的合理最大值增加1，作为超卖常数c，便于实现超卖常数c的确定。在确定超卖常数c后，如前所述，在历史资源利用率x达到预设资源利用率(例如55％)后，可将资源超卖系数z保持为1，基于此，可将超卖常数c、x＝预设资源利用率、z＝1带入公式z＝c-bax，从而确定实质上的底数ba的取值，该取值决定了指数化值的变化速度。基于确定的ba，就可以在选定第二参数b后，通过对ba求对数得到第一参数a。具体来说，在ba一定的情况下，第二参数b的取值越大，则第一参数a发生同样幅度的增减时，ba发生的增减幅度会越大，从而保留更多的数值细节，但b的取值过大也会导致a需要在小数点后取足够多位数值才能体现ba的变化，同样会增加存储负担，过犹不及。所以第二参数b的合理取值也有助于保留更多的数值细节。作为示例，第二参数b为自然常数e。[0073]调度确定单元603可根据资源超卖系数和初始配置资源量，确定目标节点的可调度资源量。具体地，参照图3和图4以及前文论述，通过计算资源超卖系数和初始配置资源量的乘积，即可得到目标节点的可调度资源量。[0074]进一步地，在调度确定单元603确定可调度资源量之后，获取单元601还可获取目标节点对应的容器集合的已部署资源量，系数确定单元602还可执行：若确定已部署资源量大于或等于可调度资源量，根据已部署资源量和初始配置资源量，重新确定资源超卖系数，并运行调度确定单元603。在系统的资源利用率突然大幅增加时，系数确定单元602确定的资源超卖系数会呈下降趋势，此时可能出现目标节点中已部署的容器集合的已部署资源量(统计的具体是已部署的pod的已部署资源量之和)大于或等于目标节点当前的可调度资源量的情况。此时，系数确定单元602通过结合实际的已部署资源量和初始配置资源量重新确定资源超卖系数，能够令调度确定单元603新确定的可调度资源量满足当前已部署的容器的运行，保障服务稳定性。[0075]具体地，系数确定单元602根据已部署资源量和初始配置资源量，重新确定资源超卖系数的操作包括：确定已部署资源量和初始配置资源量的比值，作为更新的资源超卖系数，可令由此相应更新的可调度资源量刚好等于已部署的容器集合的已部署资源量，也就没有多余的资源再分配给其他pod和容器，可不再部署新的pod和容器，能够保障已部署的pod和容器不被驱逐，从而可靠地保障了服务稳定性。[0076]图7是根据本公开的示例性实施例的电子设备的框图。[0077]参照图7，电子设备700包括至少一个存储器701和至少一个处理器702，至少一个存储器701中存储有计算机可执行指令集合，当计算机可执行指令集合被至少一个处理器702执行时，执行根据本公开的示例性实施例的资源调度方法。[0078]作为示例，电子设备700可以是pc计算机、平板装置、个人数字助理、智能手机、或其他能够执行上述指令集合的装置。这里，电子设备700并非必须是单个的电子设备，还可以是任何能够单独或联合执行上述指令(或指令集)的装置或电路的集合体。电子设备700还可以是集成控制系统或系统管理器的一部分，或者可被配置为与本地或远程(例如，经由无线传输)以接口互联的便携式电子设备。[0079]在电子设备700中，处理器702可包括中央处理器(cpu)、图形处理器(gpu)、可编程逻辑装置、专用处理器系统、微控制器或微处理器。作为示例而非限制，处理器还可包括模拟处理器、数字处理器、微处理器、多核处理器、处理器阵列、网络处理器等。[0080]处理器702可运行存储在存储器701中的指令或代码，其中，存储器701还可以存储数据。指令和数据还可经由网络接口装置而通过网络被发送和接收，其中，网络接口装置可采用任何已知的传输协议。[0081]存储器701可与处理器702集成为一体，例如，将ram或闪存布置在集成电路微处理器等之内。此外，存储器701可包括独立的装置，诸如，外部盘驱动、存储阵列或任何数据库系统可使用的其他存储装置。存储器701和处理器702可在操作上进行耦合，或者可例如通过i/o端口、网络连接等互相通信，使得处理器702能够读取存储在存储器中的文件。[0082]此外，电子设备700还可包括视频显示器(诸如，液晶显示器)和用户交互接口(诸如，键盘、鼠标、触摸输入装置等)。电子设备700的所有组件可经由总线和/或网络而彼此连接。[0083]根据本公开的示例性实施例，还可提供一种计算机可读存储介质，当计算机可读存储介质中的指令被电子设备的至少一个处理器运行时，促使电子设备执行根据本公开的示例性实施例的资源调度方法。这里的计算机可读存储介质的示例包括：只读存储器(rom)、随机存取可编程只读存储器(prom)、电可擦除可编程只读存储器(eeprom)、随机存取存储器(ram)、动态随机存取存储器(dram)、静态随机存取存储器(sram)、闪存、非易失性存储器、cd-rom、cd-r、cd+r、cd-rw、cd+rw、dvd-rom、dvd-r、dvd+r、dvd-rw、dvd+rw、dvd-ram、bd-rom、bd-r、bd-rlth、bd-re、蓝光或光盘存储器、硬盘驱动器(hdd)、固态硬盘(ssd)、卡式存储器(诸如，多媒体卡、安全数字(sd)卡或极速数字(xd)卡)、磁带、软盘、磁光数据存储装置、光学数据存储装置、硬盘、固态盘以及任何其他装置，任何其他装置被配置为以非暂时性方式存储计算机程序以及任何相关联的数据、数据文件和数据结构并将计算机程序以及任何相关联的数据、数据文件和数据结构提供给处理器或计算机使得处理器或计算机能执行计算机程序。上述计算机可读存储介质中的计算机程序可在诸如客户端、主机、代理装置、服务器等计算机设备中部署的环境中运行，此外，在一个示例中，计算机程序以及任何相关联的数据、数据文件和数据结构分布在联网的计算机系统上，使得计算机程序以及任何相关联的数据、数据文件和数据结构通过一个或多个处理器或计算机以分布式方式存储、访问和执行。[0084]根据本公开的示例性实施例，还可提供一种计算机程序产品，该计算机程序产品包括计算机指令，计算机指令被至少一个处理器运行时，促使至少一个处理器执行根据本公开的示例性实施例的资源调度方法。[0085]根据本公开的示例性实施例的资源调度方法、装置、电子设备和计算机可读存储介质，通过根据目标节点的历史资源利用率确定资源超卖系数和相应的可调度资源量，可考虑目标节点的实际负载，在历史资源利用率较低、目标节点此前的请求资源量虚高的情况下，适当为目标节点分配超过实际供应能力的资源量，使得目标节点能够为pod和容器提供更多的虚拟资源，有助于部署更多的pod和容器，从而提升目标节点的资源利用率，使得目标节点的资源尽可能被利用；在历史资源利用率较高、目标节点此前的请求资源量相对合理的情况下，适当减少资源超卖，防止资源超卖过度，有助于在超卖资源的同时保障集群服务的稳定性。[0086]本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本技术旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本
技术领域：
：中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。[0087]应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。当前第1页12当前第1页12