CN116860461B - K8s集群的资源调度方法、设备及存储介质 - Google Patents

Abstract

本发明涉及资源调度领域，公开了一种K8s集群的资源调度方法、设备及存储介质。该方法包括：接收资源请求；利用预置Rancher集群读取预置K8s集群中N个k8s节点对应的节点名称，其中，N为正整数；通过预置yaml配置文件和N个k8s节点对应的节点名称，对N个k8s节点均添加affinity标签的匹配规则，得到N个带标签K8s节点；利用Rancher集群监控N个带标签K8s节点对应的资源使用数据，从N个带标签K8s节点中筛选出affinity标签匹配的带标签K8s节点，得到M个匹配K8s节点，其中，M为不大于N的正整数；调用M个匹配K8s节点的资源执行资源请求。在本发明实施例中，解决了当前K8s集群的各个节点资源使用分布不均匀，导致各个节点的负载差别巨大。

Description

K8s集群的资源调度方法、设备及存储介质

技术领域

本发明涉及资源调度领域，尤其涉及一种K8S集群的资源调度方法、设备及存储介质。

背景技术

在使用Rancher集群部署在K8s集群上调度的容器时，Rancher集群的主机负载不均衡，有的主机只有十几个容器，有的主机有三十几个容器。容器部署采用默认主机调度规则，主机没有污点且容器有设置cpu和内存资源预留，但是容器调度不均衡，经常往资源占用高的主机部署。有的主机资源相对富余，但新容器却不往对主机部署，而对其他负载较大的主机进行部署。导致个别主机实际负载高、个别主机空闲的情况，这样会导致资源的严重浪费以及会导致业务容器OOM对业务造成影响。

因此，针对当前K8s集群的各个节点资源使用分布不均匀，导致各个节点的负载差别巨大的技术问题，需要一种新的技术来解决当前的问题。

发明内容

本发明的主要目的在于解决当前K8s集群的各个节点资源使用分布不均匀，导致各个节点的负载差别巨大的技术问题。

本发明第一方面提供了一种K8S集群的资源调度方法，所述K8S集群的资源调度方法包括：

接收资源请求；

利用预置Rancher集群读取预置K8s集群中N个k8s节点对应的节点名称，其中，N为正整数；

通过预置yaml配置文件和N个k8s节点对应的节点名称，对所述N个k8s节点均添加affinity标签的匹配规则，得到N个带标签K8s节点；

利用所述Rancher集群监控所述N个带标签K8s节点对应的资源使用数据，从所述N个带标签K8s节点中筛选出affinity标签匹配的带标签K8s节点，得到M个匹配K8s节点，其中，M为不大于N的正整数；

调用所述M个匹配K8s节点的资源执行所述资源请求。

可选的，在本发明第一方面的第一种实现方式中，所述调用所述M个匹配K8s节点的资源执行所述资源请求包括：

在所述M个匹配K8s节点选择一个节点确定为K8s执行节点；

通过所述K8s执行节点执行所述资源请求。

可选的，在本发明第一方面的第二种实现方式中，在所述通过所述K8s执行节点执行所述资源请求之后，还包括：

读取所述K8s执行节点的资源使用数据；

判断所述资源使用数据是否超过预置扩容阈值；

若超过预置扩容阈值，则对所述K8s执行节点进行pod容器扩容处理，得到扩容的K8s执行节点；

若未超过预置扩容阈值，则对所述K8s执行节点进行pod容器进行缩容处理，得到缩容的K8s执行节点。

可选的，在本发明第一方面的第三种实现方式中，所述读取所述K8s执行节点的资源使用数据包括：

利用metric-server组件，读取所述K8s执行节点的内存使用率和CPU使用率。

可选的，在本发明第一方面的第四种实现方式中，所述对所述K8s执行节点进行pod容器扩容处理，得到扩容的K8s执行节点包括：

读取预置扩容等待时长；

经过所述扩容等待时长，对所述K8s执行节点进行pod容器扩容处理，得到扩容的K8s执行节点。

可选的，在本发明第一方面的第五种实现方式中，所述对所述K8s执行节点进行pod容器进行缩容处理，得到缩容的K8s执行节点包括：

读取预置缩容等待时长；

经过所述缩容等待时长，对所述K8s执行节点进行pod容器缩容处理，得到缩容的K8s执行节点。

可选的，在本发明第一方面的第六种实现方式中，在所述利用预置Rancher集群读取预置K8s集群中N个k8s节点对应的节点名称之前，还包括：

基于预置K8s集群的Java服务端，对所述K8s集群中N个k8s节点添加节点名称标签。

可选的，在本发明第一方面的第七种实现方式中，所述通过预置yaml配置文件和N个k8s节点对应的节点名称，对所述N个k8s节点添加affinity标签的匹配规则包括：

基于预置Descheduler组件，查询出所述K8s集群中N个k8s节点对应节点名称的configmap.yam文件夹；

通过所述Rancher集群，基于预置yaml配置文件修改所有的configmap.yam文件夹，将affinity标签的匹配规则均添加至所述N个k8s节点中。

本发明第二方面提供了一种K8S集群的资源调度设备，包括：存储器和至少一个处理器，所述存储器中存储有指令，所述存储器和所述至少一个处理器通过线路互连；所述至少一个处理器调用所述存储器中的所述指令，以使得所述K8S集群的资源调度设备执行上述的K8S集群的资源调度方法。

本发明的第三方面提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述的K8S集群的资源调度方法。

在本发明实施例中，通过利用Rancher集群对K8S集群的每个节点注入affinity标签的匹配规则，匹配出资源占用不高的节点，将资源调用请求使用匹配的节点执行，通过容器和Pod的资源请求和限制设置合理，以避免资源浪费和资源争用问题，避免了资源瓶颈和满负荷运行的情况，解决了当前K8s集群的各个节点资源使用分布不均匀，导致各个节点的负载差别巨大的技术问题。

附图说明

图1为本发明实施例中K8s集群的资源调度方法的第一个实施例示意图；

图2为本发明实施例中K8s集群的资源调度方法的103步骤的一个实施例示意图；

图3为本发明实施例中K8s集群的资源调度方法的105步骤的一个实施例示意图；

图4为本发明实施例中K8s集群的资源调度方法的一个具体扩展实施例示意图；

图5为本发明实施例中K8s集群的资源调度设备的一个实施例示意图。

具体实施方式

本发明实施例提供了一种K8s集群的资源调度方法、设备及存储介质。

下面将参照附图更详细地描述本发明公开的实施例。虽然附图中显示了本发明公开的某些实施例，然而应当理解的是，本发明公开可以通过各种形式来实现，而且不应该被解释为限于这里阐述的实施例，相反提供这些实施例是为了更加透彻和完整地理解本公开。应当理解的是，本发明公开的附图及实施例仅用于示例性作用，并非用于限制本发明公开的保护范围。

在本发明公开的实施例的描述中，术语“包括”及其类似用语应当理解为开放性包含，即“包括但不限于”。术语“基于”应当理解为“至少部分地基于”。术语“一个实施例”或“该实施例”应当理解为“至少一个实施例”。术语“第一”、“第二”等等可以指代不同的或相同的对象。下文还可能包括其他明确的和隐含的定义。

为便于理解，下面对本发明实施例的具体流程进行描述，请参阅图1，本发明实施例中K8S集群的资源调度方法的一个实施例包括：

101、接收资源请求；

在本实施例中，接收到资源调度的请求的方式可以是远程互联网进行数据传输。

102、利用预置Rancher集群读取预置K8s集群中N个k8s节点对应的节点名称，其中，N为正整数；

在本实施例中，接收到资源请求后，直接触发Rancher集群读取K8s集群中N个k8s节点对应的节点名称。Rancher监控接口指标代码通过Prometheus采集各节点监控指标（CPU使用率、内存使用率等），将监控指标写入对应节点的Label，部署容器时通过节点亲和配置来对监控指标进行判断，以此来确保容器不会被调度到高负载的节点上。

工作场景是采用Rancher来管理k8s集群，Rancher已经集成了Prometheus，只需开启监控即可。如果直接使用k8s，需要安装好Prometheus并对集群各节点进行监控。

进一步的，在102步骤之前，可以执行以下步骤：

1021、基于预置K8s集群的Java服务端，对所述K8s集群中N个k8s节点添加节点名称标签。

在本实施例中，在Rancher平台上，由于Prometheus没有暴露出监控API端口，需要手动配置。首先进入System项目，在服务发现中为cattle-prometheus命名空间添加一条DNS记录，映射端口为8080，本地能够远程访问Prometheus API，需要配置一个负载均衡，通过域名访问，或者在上个步骤中将服务类型改成NodePort，然后通过主机IP+端口方式访问，例如：以http://prometheus.xxx.cn作为Prometheus API访问入口的

利用Kubernetes官方Java客户端client-java，为各节点添加Label，添加Label后可在Rancher后台看到各节点已加上了monitor-mem和monitor-ts的标签，或者可以通过kubectl查看节点label。monitor-mem代表内存使用率，monitor-ts代表监控指标的更新时间，每分钟会采集一次指标并更新Label。

103、通过预置yaml配置文件和N个k8s节点对应的节点名称，对所述N个k8s节点均添加affinity标签的匹配规则，得到N个带标签K8s节点；

在本实施例中，在yaml文件中添加affinity标签内容，如下示例：

spec:

replicas: 1

selector:

matchLabels:

app: test

template:

metadata:

labels:

app: test

spec:

affinity:

nodeAffinity:

preferredDuringSchedulingIgnoredDuringExecution:

- preference:

matchExpressions:

- key: monitor-mem

operator: Lt

values:

- "80"

weight: 100

以上代码解释如下：

spec：指定Deployment的规范。

replicas: 1：定义要创建的Pod副本数量为1。

selector：定义用于选择要管理的Pod的标签选择器。

matchLabels：通过匹配标签app: test来选择要管理的Pod。

template：定义创建Pod时使用的模板。

metadata.labels：为Pod定义标签app: test。

spec.affinity：定义Pod的亲和性。

nodeAffinity：指定节点的亲和性规则。

preferredDuringSchedulingIgnoredDuringExecution：定义在调度过程中优先选择满足条件的节点。

preference.matchExpressions：以表达式的方式定义条件。

key: monitor-mem：定义条件的键值，此处以"monitor-mem"为例。

operator: Lt：定义条件操作符，此处使用"小于"操作符（Less than）。

values: - "80"：定义条件的值，此处要求"monitor-mem"小于80。

weight: 100：定义条件的权重，此处设置为100。

通过上述配置，这个Deployment将会创建一个Pod副本，并选择所有标签为app:test的Pod进行管理。此外，Pod还具有亲和性规则，要求"monitor-mem"（假设是一个节点的内存监测指标）小于80，且具有更高的优先级（权重为100）。

可以使用kubectl命令将该Deployment资源对象部署到Kubernetes集群，Kubernetes会根据YAML文件中的定义创建一个Deployment，并在集群中自动管理Pod副本数量和调度规则。

matchExpressions标签内容为匹配规则，以上配置表示优先匹配monitor-mem<80的节点。

进一步的，请参阅图2，图2为本发明实施例中K8S集群的资源调度方法的103步骤的一个实施例，103步骤可以包含以下步骤：

1031、基于预置Descheduler组件，查询出所述K8s集群中N个k8s节点对应节点名称的configmap.yam文件夹；

1032、通过所述Rancher集群，基于预置yaml配置文件修改所有的configmap.yam文件夹，将affinity标签的匹配规则均添加至所述N个k8s节点中。

在1031-1032步骤中，部署Descheduler组件，在kubernetes目录下找到rbac.yaml、configmap.yaml和cronjob.yaml三个文件。然后基于预置yaml配置文件调整configmap.yaml配置根据容器数量来平衡调度，把cpu和memory参数去除，pods上限调27。当节点非系统pods数量超过27个时，会将多余的pods转移到其他节点，具体执行代码如下：

thresholds:

#"cpu" : 20

#"memory": 20

"pods": 20

targetThresholds:

#"cpu" : 50

#"memory": 50

"pods": 27

kubectl create -f kubernetes/rbac.yaml//通过Rancher将affinity标签的匹配规则均添加导入yaml进程部署

kubectl create -f kubernetes/configmap.yaml

kubectl create -f kubernetes/job.yaml

需要说明的，descheduler-cronjob定时任务每两分钟会执行一次调度。位于system项目-kube-system命名空间-descheduler-cronjob工作负载。

104、利用所述Rancher集群监控所述N个带标签K8s节点对应的资源使用数据，从所述N个带标签K8s节点中筛选出affinity标签匹配的带标签K8s节点，得到M个匹配K8s节点，其中，M为不大于N的正整数；

在本实施例中，利用Rancher集群监控所述N个带标签K8s节点对应的资源使用数据，访问监控接口后：

1、读取内存使用率

访问地址及参数 ：

http://prometheus.xxx.cn/api/v1/query?query=(1-sum(node_memory_MemAvailable_bytes{node="node1"})/sum(node_memory_MemTotal_bytes{node="node1"}))*100

//其中node1为节点名称

响应内容：

{"status":"success","data":{"resultType":"vector","result":[{"metric":{},"value":[1658904252.442,"58.612902871333915"]}]}}

//value中的58.612902871333915就是内存使用率

2、读取CPU使用率

访问地址及参数 ：

http://prometheus.xxx.cn/api/v1/query?query=100 - (avg by(instance)(irate(node_cpu_seconds_total{mode="idle",node="node1"}[5m])) * 100)

//其中node1为节点名称

//响应内容 ：

{"status":"success","data":{"resultType":"vector","result":[{"metric":{"instance":"192.168.0.71:9796"},"value":[1658904957.78,"9.450000000651926"]}]}}

//value中的9.450000000651926就是CPU使用率

以上为读取node1节点名称的资源使用数据的具体方式，将N个带标签K8s节点的内存使用率小于80的节点筛选出，得到M个匹配K8s节点。

105、调用所述M个匹配K8s节点的资源执行所述资源请求。

在本实施例中，将上述筛选的M个匹配K8s节点的一个或者多个作为执行主体执行资源请求。

进一步的，请参阅图3，图3为本发明实施例中K8S集群的资源调度方法的105步骤的一个实施例，105步骤可以包含以下步骤：

1051、在所述M个匹配K8s节点选择一个节点确定为K8s执行节点；

1052、通过所述K8s执行节点执行所述资源请求。

在1051-1052步骤中，只采用一个节点执行资源请求，从M个匹配K8s节点选择一个节点来执行资源请求。

进一步的，请参阅图4，图4为本发明实施例中K8S集群的资源调度方法的一个具体扩展实施例，在1052步骤之后，还可以执行以下步骤：

10521、读取所述K8s执行节点的资源使用数据；

10522、判断所述资源使用数据是否超过预置扩容阈值；

10523、若超过预置扩容阈值，则对所述K8s执行节点进行pod容器扩容处理，得到扩容的K8s执行节点；

10524、若未超过预置扩容阈值，则对所述K8s执行节点进行pod容器进行缩容处理，得到缩容的K8s执行节点。

在10521-10524步骤中，通过HPA（Horizontal Pod Autoscaler）来自动调整应用程序的Pod副本数量，以根据实时负载需求进行扩展或缩减。使用HPA时，Kubernetes会根据指定的度量标准，例如CPU利用率或内存利用率，来监测应用程序的负载情况。如果负载过高，HPA会自动增加Pod的副本数量以满足需求；如果负载较低，HPA会自动减少Pod的副本数量以节省资源。HPA的计算是基于两个核心概念：目标平均利用率和最小/最大副本数量。

目标平均利用率（target average utilization）：它表示应用程序的资源使用程度。例如，80%的CPU利用率或70%的内存利用率。

最小/最大副本数量（min/max replicas）：它们定义了Pod副本数量的范围，确保系统能够动态扩展和收缩。最小副本数量是应用程序运行所需的最低副本数量，而最大副本数量是应用程序所允许的最高副本数量。

HPA计算资源使用率的公式是：

currentUtilization = int32((metricsTotal * 100) / requestsTotal)

当使用率超过阈值时，HPA会增加Pod副本数量。而这里的Total意味着，HPA计算的是全部Pod的资源消耗。

具体的，10521步骤包含以下步骤：

105211、利用metric-server组件，读取所述K8s执行节点的内存使用率和CPU使用率。

在105211步骤中，Resource类型的指标依赖metric-server组件（目前仅支持cpu和memory），执行的代码可以如下：

- type: esource

resource:

#支持memory

name:memory

#Resource类型的target只支持Utilization和AverageValue类型的目标值

target:

#AverageValue类型的目标值(type:AverageValue, averageValue:具体值)

type: AverageValue

averageValue:1200Mi

以上代码可以读取不同节点node的资源消耗率。

具体的，10523步骤包含以下步骤：

105231、读取预置扩容等待时长；

105232、经过所述扩容等待时长，对所述K8s执行节点进行pod容器扩容处理，得到扩容的K8s执行节点。

在105231-105232步骤中，默认的扩容算法会在较短的时间内扩容，针对这种场景我们可以给扩容增加一个时间窗口以避免扩容带来的资源浪费，behavior 配置示例如下:

behavior:

scaleUp:

stabilizationWindowSeconds: 300# 扩容前等待 5 分钟的时间窗口

policies:

- type: pods

value: 20# 每次扩容新增 20 个 Pod

上面的示例表示扩容时，需要先等待5分钟的时间窗口，如果在这段时间内负载降下来了就不再扩容，如果负载持续超过扩容阀值才扩容，每次扩容新增20个Pod。

具体的，10524步骤包含以下步骤：

105241、读取预置缩容等待时长；

105242、经过所述缩容等待时长，对所述K8s执行节点进行pod容器缩容处理，得到缩容的K8s执行节点。

在105241-105242步骤中，缩容默认时间窗口是5min，如果我们需要延长时间窗口以避免一些流量造成的异常，可以指定下缩容的时间窗口，behavior配置示例如下:

behavior:

scaleDown:

stabilizationWindowSeconds: 600#等待10分钟之后再开始缩容

policies:

- type: pods

value: 5#每次只缩掉5个Pod

上面的示例表示当负载降下来时，会等待600s(10分钟)再缩容，每次只缩容5个Pod。如果应用非常关键，希望扩容后不自动缩容，需要人工干预来判断缩容条件，可以禁止自动缩容

在本发明实施例中，通过利用Rancher集群对K8S集群的每个节点注入affinity标签的匹配规则，匹配出资源占用不高的节点，将资源调用请求使用匹配的节点执行，通过容器和Pod的资源请求和限制设置合理，以避免资源浪费和资源争用问题，避免了资源瓶颈和满负荷运行的情况，解决了当前K8s集群的各个节点资源使用分布不均匀，导致各个节点的负载差别巨大的技术问题。

图5是本发明实施例提供的一种K8S集群的资源调度设备的结构示意图，该K8S集群的资源调度设备500可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上处理器（central processing units，CPU）510（例如，一个或一个以上处理器）和存储器520，一个或一个以上存储应用程序533或数据532的存储介质530（例如一个或一个以上海量存储设备）。其中，存储器520和存储介质530可以是短暂存储或持久存储。存储在存储介质530的程序可以包括一个或一个以上模块（图示没标出），每个模块可以包括对K8S集群的资源调度设备500中的一系列指令操作。更进一步地，处理器510可以设置为与存储介质530通信，在K8S集群的资源调度设备500上执行存储介质530中的一系列指令操作。

基于K8S集群的资源调度设备500还可以包括一个或一个以上电源540，一个或一个以上有线或无线网络接口550，一个或一个以上输入输出接口560，和/或，一个或一个以上操作系统531，例如Windows Serve，Mac OS X，Unix，Linux，Free BSD等等。本领域技术人员可以理解，图5示出的K8S集群的资源调度设备结构并不构成对基于K8S集群的资源调度设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

本发明还提供一种计算机可读存储介质，该计算机可读存储介质可以为非易失性计算机可读存储介质，该计算机可读存储介质也可以为易失性计算机可读存储介质，所述计算机可读存储介质中存储有指令，当所述指令在计算机上运行时，使得计算机执行所述K8S集群的资源调度方法的步骤。

在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。

此外，虽然采用特定次序描绘了各操作，但是这应当理解为要求这样操作以所示出的特定次序或以顺序次序执行，或者要求所有图示的操作应被执行以取得期望的结果。在一定环境下，多任务和并行处理可能是有利的。同样地，虽然在上面论述中包含了若干具体实现细节，但是这些不应当被解释为对本公开的范围的限制。在单独的实施例的上下文中描述的某些特征还可以组合地实现在单个实现中。相反地，在单个实现的上下文中描述的各种特征也可以单独地或以任何合适的子组合的方式实现在多个实现中。

尽管已经采用特定于结构特征和/或方法逻辑动作的语言描述了本主题，但是应当理解所附权利要求书中所限定的主题未必局限于上面描述的特定特征或动作。相反，上面所描述的特定特征和动作仅仅是实现权利要求书的示例形式。

Claims (5)

1.一种K8s集群的资源调度方法，其特征在于，包括步骤：

接收资源请求；

利用预置Rancher集群读取预置K8s集群中N个k8s节点对应的节点名称，其中，N为正整数；

通过预置yaml配置文件和N个k8s节点对应的节点名称，对所述N个k8s节点均添加affinity标签的匹配规则，得到N个带标签K8s节点；

利用所述Rancher集群监控所述N个带标签K8s节点对应的资源使用数据，从所述N个带标签K8s节点中筛选出affinity标签匹配的带标签K8s节点，得到M个匹配K8s节点，其中，M为不大于N的正整数；

调用所述M个匹配K8s节点的资源执行所述资源请求；

其中，所述调用所述M个匹配K8s节点的资源执行所述资源请求包括：

在所述M个匹配K8s节点选择一个节点确定为K8s执行节点；

通过所述K8s执行节点执行所述资源请求；

其中，在所述通过所述K8s执行节点执行所述资源请求之后，还包括：

读取所述K8s执行节点的资源使用数据；

判断所述资源使用数据是否超过预置扩容阈值；

若超过预置扩容阈值，则对所述K8s执行节点进行pod容器扩容处理，得到扩容的K8s执行节点；

若未超过预置扩容阈值，则对所述K8s执行节点进行pod容器进行缩容处理，得到缩容的K8s执行节点；

其中，所述读取所述K8s执行节点的资源使用数据包括：

利用metric-server组件，读取所述K8s执行节点的内存使用率和CPU使用率；

其中，所述对所述K8s执行节点进行pod容器扩容处理，得到扩容的K8s执行节点包括：

读取预置扩容等待时长；

经过所述扩容等待时长，对所述K8s执行节点进行pod容器扩容处理，得到扩容的K8s执行节点；

其中，所述对所述K8s执行节点进行pod容器进行缩容处理，得到缩容的K8s执行节点包括：

读取预置缩容等待时长；

经过所述缩容等待时长，对所述K8s执行节点进行pod容器缩容处理，得到缩容的K8s执行节点。

2.根据权利要求1所述的K8s集群的资源调度方法，其特征在于，在所述利用预置Rancher集群读取预置K8s集群中N个k8s节点对应的节点名称之前，还包括：

基于预置K8s集群的Java服务端，对所述K8s集群中N个k8s节点添加节点名称标签。

3.根据权利要求1所述的K8s集群的资源调度方法，其特征在于，所述通过预置yaml配置文件和N个k8s节点对应的节点名称，对所述N个k8s节点添加affinity标签的匹配规则包括：

基于预置Descheduler组件，查询出所述K8s集群中N个k8s节点对应节点名称的configmap.yam文件夹；

通过所述Rancher集群，基于预置yaml配置文件修改所有的configmap.yam文件夹，将affinity标签的匹配规则均添加至所述N个k8s节点中。

4.一种K8s集群的资源调度设备，其特征在于，所述K8s集群的资源调度设备包括：存储器和至少一个处理器，所述存储器中存储有指令，所述存储器和所述至少一个处理器通过线路互连；

所述至少一个处理器调用所述存储器中的所述指令，以使得所述K8s集群的资源调度设备执行如权利要求1-3中任一项所述的K8s集群的资源调度方法。

5.一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1-3中任一项所述的K8s集群的资源调度方法。