A Dynamic Composite Resource Scheduling Method, Electronic Device and Storage Medium Based on Kubernetes

Abstract

A dynamic combined resource scheduling method, electronic device and storage medium based on Kubernetes belong to the field of cloud computing technology. To solve the problem that the existing scheduling strategies in Kubernetes consider few resource types and do not consider the pod resource types and the relationships between pods. In the present invention, the master node receives the resource list of the pod to be scheduled; identifies the main resources of the pod to be scheduled and the scale of the pod to be scheduled; the worker node reports the worker node information to the master node; the master node analyzes the worker node information and fills the information into the node information table after analysis, and the node information table includes an RP table, an image table and a QoS table; the master node generates a dynamic combined status bit; sorts the dynamic combined status bits, and schedules the pod to be scheduled to the worker node with the highest priority of the dynamic combined status bit; determines whether the pod to be scheduled is scheduled completely. The present invention can reduce the time cost and the computing cost and ensure the service quality.

Description

Technical Field

[0001] The present invention belongs to the technical field of cloud computing, and particularly relates to a dynamic combined resource scheduling method, an electronic device, and a storage medium based on Kubernetes. Background Art

[0002] Containers are the products of the rapid development of cloud computing. With the maturity of the cloud computing industry, the number of enterprises using cloud computing has increased significantly. To give full play to the advantages of cloud computing and make full use of the resources in the cloud, enterprises have higher requirements for the scheduling accuracy of cloud computing resources. Containers divide various computing resources in the cloud and use them as the basic scheduling units, solving problems such as low resource utilization and chaotic service discovery in cloud computing. Kubernetes is currently the most mainstream open-source container orchestration tool, providing elastic scaling, storage orchestration, and load balancing for containers. It speeds up the efficiency of applications going to the cloud and meets the needs of enterprise agile development and cost savings.

[0003] In the default scheduling policy of Kubernetes, the container group pod is used as the basic scheduling unit and is centrally scheduled according to the rules set by the scheduler in the master node (Master). First, some nodes are filtered out according to the scheduling task requirements, and then the remaining nodes are traversed multiple times and scored according to various algorithms in the scheduler. The algorithms in the scheduler take effect on all pods to be scheduled.

[0004] In the scheduling policy of Kubernetes, the resource preferences of pods of different application types are not considered. Pods of different application types have different resource requirements, and the default policy cannot perform scheduling optimization according to the pod resource preferences. Moreover, the metrics for measuring resources are not comprehensive. The default scheduling policy only focuses on CPU and memory and lacks attention to storage and container image resources. In addition, the quality of service (QoS) of nodes is not considered. In enterprise application deployment, to cope with disaster recovery, the method of deploying multiple pod replicas and dispersing them to different nodes for backup is often adopted, but the dispersion of the same pod is not considered during scheduling. Summary of the Invention

[0005] In view of the problems in the existing scheduling policy in Kubernetes, such as considering fewer resource types and not considering the pod resource types and the relationships between pods, the present invention proposes a dynamic combined resource scheduling method, an electronic device, and a storage medium based on Kubernetes.

[0006] To achieve the above object, the present invention is realized through the following technical solutions:

[0007] A dynamic combined resource scheduling method based on Kubernetes includes the following steps:

[0008] S1. The master node receives the resource list of the pod to be scheduled;

[0009] S2. The master node identifies the main resources and scale of the pod to be scheduled according to the resource list of the pod to be scheduled obtained in step S1;

[0010] The specific implementation method of step S2 includes the following steps:

[0011] S2.1. Standardize each resource metric of the pod to be scheduled according to the cost. The expression is:

[0012] P j = X j * U j

[0013] Where U j is the selling price of the jth resource type in cloud computing, X j is the demand of the jth resource type of the pod to be scheduled, and P j is the cost of the jth resource type;

[0014] S2.2. Normalize the demand of each resource of the pod to be scheduled to obtain the normalized demand S j of the jth resource type. The calculation formula is:

[0015]

[0016] Where i is the resource type and n is the total number of resource types;

[0017] S2.3. Calculate the information entropy of the resource type using the normalized demand of the resource type obtained in step S2.3. The expression is:

[0018]

[0019] Where e j is the information entropy of the jth resource type;

[0020] S2.4. Calculate the weight coefficient according to the information entropy of the resource type obtained in step S2.3. The expression is:

[0021]

[0022] Where ω j is the weight coefficient of the jth resource type; the resource type with the largest obtained weight coefficient corresponds to the main resource;

[0023] S2.5. Determine the scale of the pod according to the demand cost P of the main resource obtained in step S2.4;

[0024] S3. The worker node reports the worker node information to the master node. The node information includes remaining resources, the deployed pod set, and existing images.

[0025] S4. The master node analyzes the worker node information obtained in step S3 and fills the analyzed worker node information into the node information table. The node information table includes an RP table, an image table, and a QoS table.

[0026] S5. The master node generates a dynamic combination status bit according to the worker node information table obtained in step S4.

[0027] S6. Sort the dynamic combination status bits obtained in step S5, and schedule the pod to be scheduled to the worker node with the highest priority of the dynamic combination status bit.

[0028] S7. Determine whether the pod to be scheduled has been scheduled. If the determination result is no, update the node information table in the master node, and then repeat steps S1 - S6. If the determination result is yes, complete the dynamic combination resource scheduling based on kubernetes.

[0029] Further, in step S1, the APIserver on the master node collects the resource list of the pod to be scheduled, including the resource application amount and container image of the pod to be scheduled. The resource types of the pod to be scheduled include CPU, memory, storage, and image.

[0030] Further, in step S2.5, the determination of the pod scale is based on the main resource. Calculate the ratio r of the quota of this resource of the computing node to the demand of this resource of the pod. The calculation formula is:

[0031]

[0032] where node is the node. If r is greater than 20, it is determined that the pod scale is small. If r is less than or equal to 20, it is determined that the pod scale is large.

[0033] Further, in step S4, the master node obtains the deployed pod set of the worker node and fills the QoS level of the current pod on the worker node into the QoS table.

[0034] Further, the data structure of the QoS table in step S4 is: the abscissa is the deployed pod, and the ordinate is the level of the pod, specifically the QoS level information of the worker node for this pod, which is divided into three levels: 3, 2, and 1. 3 means that the worker node has not deployed this type of pod, and the pod should be scheduled to this node first; 2 means that the worker node has deployed one such pod, and the pod can be considered for deployment to this node; 1 means that the worker node has deployed multiple such pods, and the pod should be avoided from being deployed to this worker node as much as possible.

[0035] The RP table structure is as follows: the vertical coordinate represents the level of the pod, and the horizontal coordinate represents the remaining deployable quantity of pods at different levels;

[0036] The mirror table structure is: the list of mirrors already existing on the worker nodes.

[0037] Further, the dynamic combination status bits generated in step S5 are specifically divided from high to low priority as: 311, 310, 301; 300; 211, 210, 201, 200; 111, 110, 101, 100;

[0038] Among them, the first bit is the QoS information of the node. In the first bit, 3 indicates that no pod replicas have been deployed, 2 indicates that one pod replica has been deployed, and 1 indicates that multiple pod replicas have been deployed;

[0039] The second bit is whether there is an image required by the pod. 0 indicates no, and 1 indicates yes;

[0040] The third bit is whether the current pod scale can be accommodated in the RP table. 1 indicates that it can be accommodated, and 0 indicates that it cannot be accommodated; the earlier the order, the more favorable the node is for the pod.

[0041] Further, the specific implementation method of step S6 includes the following steps:

[0042] S6.1: Set the current worker node status bit to the minimum status bit;

[0043] S6.2: Traverse the dynamic combination status bits of the worker nodes in sequence, and compare them with the minimum status bit set in step S6.1. If the dynamic combination status bit of the compared worker node is less than the minimum status bit, then replace the minimum status bit with the dynamic combination status bit of the compared worker node until all worker nodes are traversed, and output the minimum status bit;

[0044] S6.3: The minimum status bit output in step S6.2 is the worker node with the highest priority of the dynamic combination status bit. Schedule the pod to be scheduled to the worker node with the highest priority of the dynamic combination status bit.

[0045] An electronic device, including a memory and a processor, the memory stores a computer program, and when the processor executes the computer program, it implements the steps of the described dynamic combination resource scheduling method based on kubernetes.

[0046] A computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the described dynamic combination resource scheduling method based on kubernetes.

[0047] The beneficial effects of the present invention:

[0048] A dynamic combined resource scheduling method based on Kubernetes according to the present invention generates dynamic combination to achieve reasonable scheduling between pods and nodes, so as to save resource costs and ensure service quality and load balancing, and can improve the reliability and stability of Kubernetes scheduling.

[0049] A dynamic combined resource scheduling method based on Kubernetes according to the present invention takes into account the resource requirements and container images of pods affecting scheduling, considers the quantity and type of resource requirements, and at the same time considers the service quality and load balancing of nodes, analyzes the pod information and node key information affecting scheduling quality, analyzes pod information, establishes a node information table. When scheduling, it is not necessary to review the resources inside the node multiple times, only need to dynamically maintain the node information table located on the master node, reduce the reporting times of nodes to the master node, reduce time costs and computing costs, and at the same time consider the load balancing of pods on the cluster to ensure service quality. BRIEF DESCRIPTION OF THE DRAWINGS

[0050] Figure 1 is a flowchart of a dynamic combined resource scheduling method based on Kubernetes according to the present invention;

[0051] Figure 2 is an overall architecture diagram of a dynamic combined resource scheduling method based on Kubernetes according to the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0052] In order to make the objectives, technical solutions and advantages of the present invention clearer, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention, and are not used to limit the present invention, that is, the specific embodiments described are only a part of the embodiments of the present invention, rather than all of the specific embodiments. Usually, the components of the specific embodiments of the present invention described and shown in the accompanying drawings herein can be arranged and designed in various different configurations, and the present invention can also have other embodiments.

[0053] Therefore, the following detailed description of the specific embodiments of the present invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely represents the selected specific embodiments of the present invention. All other specific embodiments obtained by those skilled in the art based on the specific embodiments of the present invention without creative efforts fall within the scope of protection of the present invention.

[0054] In order to further understand the content, features and effects of the present invention, the following specific embodiments are exemplified and are described in detail in conjunction with the attached Figure 1 and the attached Figure 2 as follows: Specific implementation method 1:

[0056] A dynamic combined resource scheduling method based on kubernetes, comprising the following steps:

[0057] S1. The master node receives the resource list of the pod to be scheduled;

[0058] Further, in step S1, the API server on the master node collects the resource list of the pod to be scheduled, including the resource application amount and container image of the pod to be scheduled, and the resource types of the pod to be scheduled include CPU, memory, storage, and image;

[0059] S2. The master node identifies the main resources and scale of the pod to be scheduled according to the resource list of the pod to be scheduled obtained in step S1;

[0060] Further, the specific implementation method of step S2 includes the following steps:

[0061] S2.1. Standardize each resource metric of the pod to be scheduled according to the cost, and the expression is:

[0062] P j =X j *U j

[0063] Where U j is the selling price of the jth resource type in cloud computing, X j is the demand of the jth resource type of the pod to be scheduled, and P j is the cost of the jth resource type;

[0064] S2.2. Normalize the demand of each resource of the pod to be scheduled to obtain the normalized demand S of the jth resource type j The calculation formula is:

[0065]

[0066] Where i is the resource type and n is the total number of resource types;

[0067] S2.3. Calculate the information entropy of the resource type using the normalized demand of the resource type obtained in step S2.3, and the expression is:

[0068]

[0069] Where e j is the information entropy of the jth resource type;

[0070] S2.4. Calculate the weight coefficient according to the information entropy of the resource type obtained in step S2.3. The expression is as follows:

[0071]

[0072] where ω j is the weight coefficient of the j-th resource type; the resource type with the largest obtained weight coefficient corresponds to the main resource

[0073] S2.5. Determine the scale of the pod according to the demand cost P of the main resource obtained in step S2.4;

[0074] Furthermore, in step S2.5, the determination of the pod scale is based on the main resource. Calculate the ratio r of the quota of this resource of the computing node to the demand of the pod for this resource. The calculation formula is:

[0075]

[0076] where node is the node. If r is greater than 20, it is judged that the pod scale is small. If r is less than or equal to 20, it is judged that the pod scale is large;

[0077] S3. The working node reports the working node information to the master node. The node information includes the remaining resources, the deployed pod set, and the existing images;

[0078] S4. The master node analyzes the working node information obtained in step S3 and fills the analyzed working node information into the node information table. The node information table includes the RP table, the image table, and the QoS table;

[0079] Furthermore, in step S4, the master node obtains the deployed pod set of the working node and fills the judged QoS level of the current pod on the working node into the QoS table;

[0080] Furthermore, the data structure of the QoS table in step S4 is: the abscissa is the deployed pod, and the ordinate is the level of the pod. Specifically, it is the QoS level information of the working node for this pod, which is divided into three levels: 3, 2, and 1. 3 means that the working node has not deployed this type of pod, and the pod should be preferentially scheduled to this node; 2 means that the working node has deployed one such pod, and the pod can be considered for deployment to this node; 1 means that the working node has deployed multiple such pods, and the pod should be avoided as much as possible to be deployed to this working node;

[0081] The structure of the RP table is: the ordinate is the level of the pod, and the abscissa is the remaining deployable quantity of pods of different levels; the meaning is to fix a node to be able to deploy several large pods and several small pods. Deploying one pod on the node occupies one quota;

[0082] The mirror table structure is: the mirror list existing on the working node;

[0083] S5. The master node generates a dynamic combination status bit according to the working node information table obtained in step S4;

[0084] Further, the dynamic combination status bits generated in step S5 are specifically divided from high to low priority as: 311, 310, 301; 300; 211, 210, 201, 200; 111, 110, 101, 100;

[0085] Among them, the first bit is the QoS information of the node. In the first bit, 3 indicates that no pod replicas have been deployed, 2 indicates that one pod replica has been deployed, and 1 indicates that multiple pod replicas have been deployed;

[0086] The second bit is whether there is an image required by the pod. 0 indicates no, and 1 indicates yes;

[0087] The third bit is whether the current pod scale can be accommodated in the RP table. 1 indicates that it can be accommodated, and 0 indicates that it cannot be accommodated; the earlier the order, the more favorable the node is for the pod;

[0088] S6. Sort the dynamic combination status bits obtained in step S5, and schedule the pod to be scheduled to the working node with the highest priority of the dynamic combination status bit;

[0089] Further, the specific implementation method of step S6 includes the following steps:

[0090] S6.1. Set the current working node status bit as the minimum status bit;

[0091] S6.2. Traverse the dynamic combination status bits of the working nodes in turn, compare them with the minimum status bit set in step S6.1. If the dynamic combination status bit of the compared working node is less than the minimum status bit, replace the minimum status bit with the dynamic combination status bit of the compared working node until all working nodes are traversed, and output the minimum status bit;

[0092] S6.3. The minimum status bit output in step S6.2 is the working node with the highest priority of the dynamic combination status bit. Schedule the pod to be scheduled to the working node with the highest priority of the dynamic combination status bit;

[0093] S7. Judge whether the pod to be scheduled has been scheduled. If the judgment is no, update the node information table in the master node, and then repeat steps S1 - S6. If the judgment is yes, complete the dynamic combination resource scheduling based on kubernetes.

[0094] This embodiment takes into account the resource requirements of pods and container image resources that affect scheduling, while also considering the quality of service and load balancing of nodes. It analyzes the pod information and node key information that affect scheduling quality, establishes a pod information table and a node information table. During scheduling, it is not necessary to repeatedly review the resources inside the nodes. Instead, only the node information table located on the master node needs to be dynamically maintained, reducing the number of reports from nodes to the master node, and reducing time costs and computing resource costs. At the same time, it considers the load balancing of pods on the cluster to ensure the quality of service. This solves the problems of the single default scheduling policy in Kubernetes, high time complexity, and inability to dynamically adjust the application type. Specific Embodiment 2:

[0096] An electronic device includes a memory and a processor. The memory stores a computer program, and when the processor executes the computer program, the steps of the dynamic combined resource scheduling method based on Kubernetes are implemented.

[0097] The computer device of the present invention can be a device including a processor and a memory, such as a single-chip microcomputer including a central processing unit. Moreover, when the processor is used to execute the computer program stored in the memory, the steps of the dynamic combined resource scheduling method based on Kubernetes are implemented.

[0098] The so-called processor may be a central processing unit (CPU), or may also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc.

[0099] The memory may mainly include a program storage area and a data storage area. Among them, the program storage area may store an operating system, application programs required for at least one function (such as a sound playback function, an image playback function, etc.); the data storage area may store data created according to the use of the mobile phone (such as audio data, phone book, etc.). In addition, the memory may include high-speed random access memory and may also include non-volatile memory, such as a hard disk, memory, plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, at least one magnetic disk storage device, flash memory device, or other volatile solid-state storage devices. Specific Embodiment Three:

[0101] A computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the described dynamic combined resource scheduling method based on kubernetes is implemented.

[0102] The computer-readable storage medium of the present invention can be any form of storage medium readable by the processor of the computer device, including but not limited to non-volatile memory, volatile memory, ferroelectric memory, etc. A computer program is stored on the computer-readable storage medium. When the processor of the computer device reads and executes the computer program stored in the memory, the steps of the described dynamic combined resource scheduling method based on kubernetes can be implemented.

[0103] The computer program includes computer program code, and the computer program code can be in the form of source code, object code, executable file, or some intermediate form, etc. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording medium, USB flash drive, mobile hard disk, magnetic disk, optical disc, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signal, telecommunication signal, and software distribution medium, etc. It should be noted that the content included in the computer-readable medium can be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, the computer-readable medium does not include electrical carrier signals and telecommunication signals.

[0104] It should be noted that relational terms such as "first" and "second" are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprising", "including" or any other variant thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device comprising a series of elements not only includes those elements, but also includes other elements not expressly listed, or further includes elements inherent to such process, method, article or device. Without further limitation, an element defined by the statement "comprising an..." does not exclude the presence of additional identical elements in the process, method, article or device comprising the said element.

[0105] Although the present application has been described above with reference to specific embodiments, various improvements can be made thereto and components thereof can be replaced with equivalents without departing from the scope of the present application. In particular, as long as there is no structural conflict, the various features in the specific embodiments disclosed in the present application can be combined with each other in any way, and the exhaustive description of the situations of these combinations is not given in this specification only for the sake of saving space and resources. Therefore, the present application is not limited to the specific embodiments disclosed herein, but includes all technical solutions falling within the scope of the claims.

Claims

1. A dynamic combined resource scheduling method based on kubernetes, characterized in that, It includes the following steps: S1. The master node receives the resource list of the pod to be scheduled; S2. Based on the resource list of the pod to be scheduled obtained in step S1, the master node identifies the main resources of the pod to be scheduled and the scale of the pod to be scheduled; The specific implementation method of step S2 includes the following steps: S2.

1. Standardize each resource metric of the pod to be scheduled according to the cost. The expression is: P j = X j * U j Among them, U j is the selling price of the j-th resource type in cloud computing, X j is the demand for the j-th resource type of the pod to be scheduled, and P j is the cost of the j-th resource type; S2.

2. Normalize the demand for each resource of the pod to be scheduled to obtain the normalized demand S for the j-th resource type j The calculation formula is as follows: where i is the resource type and n is the total number of resource types; S2.

3. Calculate the information entropy of the resource type using the normalized demand of the resource type obtained in step S2.

3. The expression is: Among them, e j is the information entropy of the j-th resource type; S2.

4. Calculate the weight coefficient according to the information entropy of the resource type obtained in step S2.

3. The expression is: where ω j is the weight coefficient of the j-th resource type; the resource type with the largest obtained weight coefficient corresponds to the main resource; S2.

5. Determine the scale of the pod according to the demand cost P of the main resources obtained in step S2.4; S3. The worker node reports the worker node information to the master node. The node information includes the remaining resources, the set of deployed pods, and the existing images; S4. The master node analyzes the worker node information obtained in step S3 and fills the analyzed worker node information into the node information table. The node information table includes the RP table, the image table, and the QoS table; The data structure of the QoS table in step S4 is: the abscissa is the deployed pod, and the ordinate is the level of the pod. Specifically, it is the QoS level information of the worker node for this pod, which is divided into three levels: 3, 2, and 1. 3 means that the worker node has not deployed this pod, and the pod should be preferentially scheduled to this node; 2 means that the worker node has deployed one such pod, and the pod can be considered for deployment to this node; 1 means that the worker node has deployed multiple such pods, and the pod should be avoided from being deployed to this worker node as much as possible; The structure of the RP table is: the ordinate is the level of the pod, and the abscissa is the remaining deployable quantity of pods at different levels; The structure of the image table is: the list of existing images on the worker node; S5. The master node generates a dynamic combination status bit according to the worker node information table obtained in step S4; The dynamic combination status bits generated in step S5 are specifically divided from high to low priority as: 311, 310, 301; 300; 211, 210, 201, 200; 111, 110, 101, 100; Among them, the first bit is the QoS information of the node. In the first bit, 3 means that no pod replicas have been deployed, 2 means that one pod replica has been deployed, and 1 means that multiple pod replicas have been deployed; The second bit is whether there is an image required by the pod. 0 means no, and 1 means yes; The third bit is whether the current pod scale can be accommodated in the RP table. 1 means it can be accommodated, and 0 means it cannot be accommodated; the earlier the order, the more favorable the node is for the pod; S6. Sort the dynamic combination status bits obtained in step S5 and schedule the pod to be scheduled to the worker node with the highest priority of the dynamic combination status bit; S7. Determine whether the pod to be scheduled has been scheduled. If the judgment is no, update the node information table in the master node, and then repeat steps S1 - S6. If the judgment is yes, complete the dynamic combination resource scheduling based on kubernetes.

2. The dynamic combined resource scheduling method based on kubernetes according to claim 1, wherein In step S1, the API server on the master node collects the resource list of the pods to be scheduled, including the resource requests of the pods to be scheduled and the container images. The resource types of the pods to be scheduled include CPU, memory, storage, and images.

3. A dynamic combined resource scheduling method based on kubernetes according to claim 1, characterized in that In step S2.5, the determination of the pod scale is based on the primary resources. Calculate the ratio r of the quota of the computing node resources to the required resources of the pod. The calculation formula is: where node is the node. If r is greater than 20, it is determined that the pod scale is small. If r is less than or equal to 20, it is determined that the pod scale is large.

4. A dynamic composite resource scheduling method based on Kubernetes according to claim 3, characterized in that In step S4, the master node obtains the set of deployed pods on the worker nodes and fills the QoS level of the worker nodes under the current pod determined into the QoS table.

5. A dynamic combined resource scheduling method based on Kubernetes according to claim 4, characterized in that, The specific implementation method of step S6 includes the following steps: S6.

1. Set the current worker node status bit to the minimum status bit; S6.

2. Traverse the dynamic combination status bits of the worker nodes in turn and compare them with the minimum status bit set in step S6.

1. If the dynamic combination status bit of the compared worker node is less than the minimum status bit, replace the minimum status bit with the dynamic combination status bit of the compared worker node until all worker nodes are traversed, and output the minimum status bit; S6.

3. The minimum status bit output in step S6.2 is the worker node with the highest priority of the dynamic combination status bit. Schedule the pod to be scheduled to the worker node with the highest priority of the dynamic combination status bit.

6. An electronic device, characterized in that, It includes a memory and a processor. The memory stores a computer program. When the processor executes the computer program, it implements the steps of a dynamic combined resource scheduling method based on kubernetes according to any one of claims 1-5.

7. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements a dynamic combined resource scheduling method based on kubernetes according to any one of claims 1-5.

Images