A Kubernetes resource scheduling method, device, equipment and medium

CN116932128BActive Publication Date: 2026-10-30SAIC MOTOR
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202210360698.2
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2022-04-07
Publication Date
2026-10-30
Estimated Expiration
2042-04-07

AI Technical Summary

Technical Problem

[0003]当Flink基于Yarn部署时,Flink只能基于预先为每个任务所分配的资源运行对应任务,无法对应调整,影响任务运行和资源占用

Benefits of technology

[0047]本申请实施例提供了一种Kubernetes的资源调度方法,该方法通过Kubernetes获取可用节点,根据每个可用节点上资源调度单元POD的类型的数量,以及每个可用节点上的空间与资源负载,确定目标节点,如此,可以在接收应用创建请求后,根据应用创建请求,在目标节点上运行POD。因此,在Kubernetes的资源调度过程中,考虑可用节点上POD的类型的数量,和空间与资源负载,从而确定目标节点,从而充分利用资源,提高任务运行性能。

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN116932128B_ABST
    Figure CN116932128B_ABST
Patent Text Reader

Abstract

The application provides a Kubernetes resource scheduling method. The method acquires available nodes through Kubernetes, determines a target node according to the number of types of resource scheduling units PODs on each available node and the space and resource load on each available node, and thus can run the POD on the target node according to an application creation request after receiving the application creation request. Therefore, in the Kubernetes resource scheduling process, the number of types of PODs on the available node and the space and resource load are considered to determine the target node, so that the resources are fully utilized and the task running performance is improved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of computer technology, and more particularly to a Kubernetes resource scheduling method, apparatus, device, and computer-readable storage medium. Background Technology

[0002] Apache Flink is a framework and distributed processing engine for stateful computation on unbounded and bounded streams of data. As a distributed processing system, Apache Flink requires computational resources to execute applications.

[0003] When Flink is deployed based on Yarn, it can only run tasks based on the resources pre-allocated for each task, and cannot adjust these resources accordingly, affecting task execution and resource consumption. While Flink deployed on Kubernetes allows for dynamic resource adjustment, node scheduling issues still exist, impacting task execution performance.

[0004] Therefore, the industry urgently needs a resource scheduling method for Kubernetes. Summary of the Invention

[0005] This application provides a resource scheduling method for Kubernetes. This application also provides apparatus, devices, computer-readable storage media, and computer program products corresponding to the above method.

[0006] Firstly, this application provides a resource scheduling method for Kubernetes, the method comprising:

[0007] Get available nodes;

[0008] The target node is determined from the available nodes based on the number of resource scheduling units (PODs) of each available node and the space and resource load on each available node.

[0009] Receive an application creation request, and run a POD on the target node according to the application creation request.

[0010] In some possible implementations, the space and resource load on each of the available nodes includes: the CPU on each of the available nodes, the memory on each of the available nodes, the disk throughput on each of the available nodes, and the network load on each of the available nodes.

[0011] In some possible implementations, determining the target node from the available nodes based on the number of resource scheduling units (PODs) of different types on each available node, and the space and resource load on each available node, includes:

[0012] A first score for each available node is determined based on the number of resource scheduling unit (POD) types on each available node;

[0013] A second score for each available node is determined based on the first score of each available node and the space and resource load on each available node;

[0014] The target node is determined from the available nodes based on the second score of each available node.

[0015] In some possible implementations, obtaining available nodes includes:

[0016] Listen to the application programming interface (API) and obtain candidate nodes;

[0017] The candidate nodes are filtered using the first rule to obtain the filtered usable nodes.

[0018] In some possible implementations, determining the first score of each available node based on the number of resource scheduling unit (POD) types on each available node includes:

[0019] A first score for each available node is determined based on the ratio of the number of resource scheduling unit (POD) types on each available node to the total number of POD types.

[0020] In some possible implementations, the number of types of resource scheduling units (PODs) on each of the available nodes is inversely proportional to the first score of each available node.

[0021] In some possible implementations, receiving the application creation request and, based on the application creation request, running the resource scheduling unit (POD) on the target node includes:

[0022] Receive an application creation request, and match the target node with the POD according to the application creation request;

[0023] Run POD on the target node.

[0024] Secondly, this application provides a resource scheduling device for Kubernetes, the device comprising:

[0025] The communication module is used to obtain available nodes;

[0026] The determination module is used to determine the target node from the available nodes based on the number of resource scheduling units (PODs) of each available node and the space and resource load on each available node;

[0027] The runtime module is used to receive an application creation request and run the POD on the target node according to the application creation request.

[0028] In some possible implementations, the space and resource load on each of the available nodes includes: the CPU on each of the available nodes, the memory on each of the available nodes, the disk throughput on each of the available nodes, and the network load on each of the available nodes.

[0029] In some possible implementations, the determining module is specifically used for:

[0030] A first score for each available node is determined based on the number of resource scheduling unit (POD) types on each available node;

[0031] A second score for each available node is determined based on the first score of each available node and the space and resource load on each available node;

[0032] The target node is determined from the available nodes based on the second score of each available node.

[0033] In some possible implementations, the communication module is specifically used for:

[0034] Listen to the application programming interface (API) and obtain candidate nodes;

[0035] The candidate nodes are filtered using the first rule to obtain the filtered usable nodes.

[0036] In some possible implementations, the module is specifically used for:

[0037] A first score for each available node is determined based on the ratio of the number of resource scheduling unit (POD) types on each available node to the total number of POD types.

[0038] In some possible implementations, the number of types of resource scheduling units (PODs) on each of the available nodes is inversely proportional to the first score of each available node.

[0039] In some possible implementations, the running module is specifically used for:

[0040] Receive an application creation request, and match the target node with the POD according to the application creation request;

[0041] Run POD on the target node.

[0042] Thirdly, this application provides an apparatus comprising a processor and a memory. The processor and the memory communicate with each other. The processor is configured to execute instructions stored in the memory to cause the apparatus to perform a Kubernetes resource scheduling method as described in the first aspect or any implementation thereof.

[0043] Fourthly, this application provides a computer-readable storage medium storing instructions that instruct a device to execute the Kubernetes resource scheduling method described in the first aspect or any implementation thereof.

[0044] Fifthly, this application provides a computer program product containing instructions that, when run on a device, causes the device to execute the Kubernetes resource scheduling method described in the first aspect or any implementation thereof.

[0045] Based on the implementation methods provided in the above aspects, this application can be further combined to provide more implementation methods.

[0046] As can be seen from the above technical solutions, the embodiments of this application have the following advantages:

[0047] This application provides a Kubernetes resource scheduling method. This method obtains available nodes through Kubernetes, determines target nodes based on the number of different types of Resource Scheduling Units (PODs) on each available node, and the space and resource load on each available node. Thus, after receiving an application creation request, the method can run PODs on the target node according to the application creation request. Therefore, in the Kubernetes resource scheduling process, considering the number of different types of PODs on available nodes, as well as the space and resource load, helps determine the target node, thereby fully utilizing resources and improving task performance.

[0048] Other features and advantages of this application will be described in detail in the following detailed description section. Attached Figure Description

[0049] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0050] Figure 1 A flowchart illustrating a Kubernetes resource scheduling method provided in this application embodiment;

[0051] Figure 2 A schematic diagram illustrating a process for determining a target node from available nodes, provided as an embodiment of this application;

[0052] Figure 3 A schematic diagram of a process for determining the first score of each available node, provided for an embodiment of this application;

[0053] Figure 4 A flowchart illustrating a method for determining a second score for each available node, provided as an embodiment of this application;

[0054] Figure 5 A schematic diagram of a process for determining a target node is provided for an embodiment of this application;

[0055] Figure 6 This is a schematic diagram of the architecture of a Kubernetes resource scheduling device provided in an embodiment of this application. Detailed Implementation

[0056] The solutions in the embodiments provided in this application will now be described with reference to the accompanying drawings.

[0057] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms can be used interchangeably where appropriate; this is merely a way of distinguishing objects with the same attributes in the embodiments of this application.

[0058] To facilitate understanding of the technical solution of this application, some technical terms involved in this application will be introduced below.

[0059] Apache Flink is a framework and distributed processing engine for stateful computation on unbounded and bounded streams of data. As a distributed processing system, Apache Flink requires computational resources to execute applications.

[0060] When Flink is deployed based on Yarn, resources such as CPU and memory need to be pre-allocated for the task before running real-time tasks. During task execution, the pre-allocated resources are fixed. Specifically, each task's resources are exclusive; as long as the task continues, the allocated resources cannot be released. Furthermore, if the task requires additional resources during execution, resources cannot be added accordingly, and idle resources cannot be released.

[0061] To address this issue, Flink can be deployed on Kubernetes, enabling dynamic resource adjustment through interaction with Kubernetes. Kubernetes (also known as k8s) can monitor system resource usage and automatically increase and decrease resources, thus achieving dynamic resource adjustment.

[0062] Specifically, Kubernetes can dynamically allocate and cancel TaskManagers based on the resources required by tasks running on Flink, thus dynamically adjusting task resources. This process typically uses Kubernetes' default scheduling algorithm, but node scheduling issues still exist, impacting task execution performance.

[0063] The applicant discovered that when Kubernetes nodes are overloaded or experience excessive network traffic, node resource utilization may decrease, reducing task performance. Furthermore, having too many types of Resource Scheduling Units (PODs) on a node can also degrade task performance, making it difficult to meet actual technical requirements.

[0064] In Kubernetes, the resource scheduling unit is the smallest unit that can be created and deployed. A Pod contains one or more containers, as well as shared resources such as storage and networking. Pods support various container environments, such as Docker.

[0065] In view of this, this application provides a Kubernetes resource scheduling method that can be executed by Kubernetes. Specifically, Kubernetes obtains available nodes, determines target nodes based on the number of different types of Resource Scheduling Units (PODs) on each available node, and the space and resource load on each available node. Thus, upon receiving an application creation request, the method can run PODs on the target node according to the application creation request. Therefore, in the Kubernetes resource scheduling process, the number of different types of PODs on available nodes, as well as the space and resource load, are considered to determine the target node, thereby fully utilizing resources and improving task performance.

[0066] To make the technical solutions of this disclosure clearer and easier to understand, a Kubernetes resource scheduling method provided by the embodiments of this disclosure will be described below. Figure 1 This is a flowchart illustrating a Kubernetes resource scheduling method provided in this application.

[0067] S102: Obtain available nodes.

[0068] In this context, available nodes refer to nodes that can be scheduled. For example, a custom Kubernetes scheduler can listen to the server's application programming interface (API) to obtain unscheduled PODs and all unscheduled nodes (candidate nodes). Candidate nodes can be directly used as available nodes.

[0069] In some possible implementations, candidate nodes can be filtered, and the filtered candidate nodes can be determined as available nodes. Specifically, Kubernetes can filter candidate nodes using a first rule, which can be a user-defined rule or a rule from Kubernetes' default pre-selection scheduling algorithm.

[0070] S104: Determine the target node based on the number of resource scheduling units (PODs) of each available node and the space and resource load on each available node.

[0071] The space and resource load on each available node includes the central processing unit (CPU) on each available node, the memory on each available node, the disk throughput on each available node, and the network load on each available node.

[0072] The applicant discovered that the more types of PODs on an available node, the lower the task's performance. Furthermore, high space and resource loads also reduce task performance. Therefore, the target node can be determined based on the number of resource scheduling unit POD types on each available node, as well as the space and resource load on each available node.

[0073] Specifically, the steps in S104 can be as follows: Figure 2 As shown:

[0074] S1042: Determine the first score for each available node based on the number of POD types on each available node.

[0075] Kubernetes can prioritize nodes by assigning them scores. The first score is determined by the ratio of the number of POD types to the total number of POD types. The number of POD types on each available node is inversely proportional to its first score. For example... Figure 3 As shown.

[0076] Kubernetes calculates a first score for each node based on the number of POD types present on each node. This process can be implemented using the following code:

[0077]

[0078]

[0079] S1044: Determine the second score of each available node based on the first score of each available node and the space and resource load on each available node.

[0080] The space and resource load on available nodes includes the central processing unit (CPU) on each available node, the memory on each available node, the disk throughput on each available node, and the network load on each available node. For example... Figure 4 As shown.

[0081] This step can be achieved using the following code:

[0082]

[0083]

[0084] S1046: Determine the target node from the available nodes based on the second score of each available node.

[0085] After obtaining the second score of the available nodes, the available nodes can be prioritized based on their second scores to determine the target node. The target node can be the node with the highest second score among the available nodes.

[0086] like Figure 5 As shown, available nodes (node1, node2, node3, and node4) are selected from multiple nodes (node1, node2, and node4) using a default pre-selection scheduling algorithm. Then, based on the number of resource scheduling units (PODs) of different types on each available node, and the space and resource load on each available node, a score is assigned to each node (node1: 7 points; node2: 10 points; node4: 8 points). Node2 can then be selected as the target node.

[0087] S106: Receives an application creation request and runs the POD on the target node according to the application creation request.

[0088] Kubernetes receives an application creation request, matches the target node with the POD based on the application creation request, and runs the POD on the target node.

[0089] Specifically, when a task needs to be created on Flink, i.e. after Kubernetes receives the application's creation request, it writes the target node and corresponding data into the POD. After the API Server receives the request, it stores the relevant data in a distributed key-value store system (e.g., the Etcd database for storing Kubernetes data). On the kubelet corresponding to the target node, the Pod creation operations are executed.

[0090] Based on the above description, this application provides a resource scheduling method for Kubernetes. Kubernetes obtains available nodes and determines target nodes based on the number of different types of Resource Scheduling Units (PODs) on each available node, as well as the space and resource load on each available node. Thus, after receiving an application creation request, PODs can be run on the target node according to the application creation request. Therefore, in the Kubernetes resource scheduling process, considering the number of different types of PODs on available nodes, and the space and resource load, the target node is determined, thereby making full use of resources and improving task performance.

[0091] The above combination Figure 1 The resource scheduling method for Kubernetes provided in the embodiments of this application has been described in detail. Next, the resource scheduling device for Kubernetes provided in the embodiments of this application will be described in conjunction with the accompanying drawings.

[0092] See Figure 6 The diagram shows the structure of a Kubernetes resource scheduling device 600, which includes a communication module 602, a determination module 604, and a running module 606.

[0093] The communication module is used to obtain available nodes;

[0094] The determination module is used to determine the target node from the available nodes based on the number of resource scheduling units (PODs) of each available node and the space and resource load on each available node;

[0095] The runtime module is used to receive an application creation request and run the POD on the target node according to the application creation request.

[0096] In some possible implementations, the space and resource load on each of the available nodes includes: the CPU on each of the available nodes, the memory on each of the available nodes, the disk throughput on each of the available nodes, and the network load on each of the available nodes.

[0097] In some possible implementations, the determining module is specifically used for:

[0098] A first score for each available node is determined based on the number of resource scheduling unit (POD) types on each available node;

[0099] A second score for each available node is determined based on the first score of each available node and the space and resource load on each available node;

[0100] The target node is determined from the available nodes based on the second score of each available node.

[0101] In some possible implementations, the communication module is specifically used for:

[0102] Listen to the application programming interface (API) and obtain candidate nodes;

[0103] The candidate nodes are filtered using the first rule to obtain the filtered usable nodes.

[0104] In some possible implementations, the module is specifically used for:

[0105] A first score for each available node is determined based on the ratio of the number of resource scheduling unit (POD) types on each available node to the total number of POD types.

[0106] In some possible implementations, the number of types of resource scheduling units (PODs) on each of the available nodes is inversely proportional to the first score of each available node.

[0107] In some possible implementations, the running module is specifically used for:

[0108] Receive an application creation request, and match the target node with the POD according to the application creation request;

[0109] Run POD on the target node.

[0110] The Kubernetes resource scheduling device 600 according to the embodiments of this application can correspondingly execute the methods described in the embodiments of this application, and the above and other operations and / or functions of each module of the Kubernetes resource scheduling device 600 are respectively for implementing Figure 1 For the sake of brevity, the corresponding processes of each method in the code will not be elaborated here.

[0111] This application provides an apparatus for implementing a Kubernetes resource scheduling method. The apparatus includes a processor and a memory. The processor and the memory communicate with each other. The processor executes instructions stored in the memory to cause the apparatus to perform the Kubernetes resource scheduling method.

[0112] This application provides a computer-readable storage medium storing instructions that, when run on a device, cause the device to execute the aforementioned Kubernetes resource scheduling method.

[0113] This application provides a computer program product containing instructions that, when run on a device, cause the device to execute the resource scheduling method of Kubernetes described above.

[0114] It should also be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. In addition, in the device embodiment drawings provided in this application, the connection relationship between modules indicates that they have a communication connection, which can be implemented as one or more communication buses or signal lines.

[0115] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware, or it can be implemented by special-purpose hardware including application-specific integrated circuits, special-purpose CPUs, special-purpose memory, special-purpose components, etc. Generally, any function performed by a computer program can be easily implemented by corresponding hardware, and the specific hardware structure used to implement the same function can also be diverse, such as analog circuits, digital circuits, or special-purpose circuits. However, for this application, software program implementation is more often the preferred implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a readable storage medium, such as a computer floppy disk, USB flash drive, mobile hard disk, ROM, RAM, magnetic disk, or optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, training equipment, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0116] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product.

[0117] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, training device, or data center to another website, computer, training device, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a training device or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state drives (SSDs)).

Claims

1. A resource scheduling method for Kubernetes, characterized in that, The method includes: Listen to the application programming interface (API) to obtain the current PODs and candidate nodes that have not been scheduled; The candidate nodes are filtered using the first rule to obtain the filtered usable nodes; For each available node, obtain all POD objects on the available node, iterate through all POD objects, determine whether the iterated POD objects are of the same type as the current POD object, and if the types are the same, accumulate the number of POD objects of the same type as the current POD object; Based on the number of POD objects of the same type as the current POD object and the total number of POD objects on the available node, the first score of the available node is determined according to the formula: first score = (1 - number of POD objects of the same type as the current POD object / total number of POD objects on the available node) × 10. A second score for each available node is determined based on the first score of each available node and the space and resource load on each available node, wherein the space and resource load on each available node includes the CPU of each available node, the memory of each available node, the disk throughput of each available node, and the network load of each available node; Based on the second score of each available node, the available nodes are prioritized and sorted, and the available node with the highest second score is determined as the target node; Receive an application creation request, and run a POD on the target node according to the application creation request.

2. The method according to claim 1, characterized in that, The process of receiving an application creation request and, based on the application creation request, running a resource scheduling unit (POD) on the target node includes: Receive an application creation request, and match the target node with the POD according to the application creation request; Run POD on the target node.

3. A resource scheduling device for Kubernetes, characterized in that, The device includes: The communication module is used to listen to the application programming interface (API) and obtain the current PODs and candidate nodes that have not been scheduled. The candidate nodes are filtered using the first rule to obtain the filtered usable nodes; The determination module is used to obtain all POD objects on each available node, iterate through all POD objects, determine whether the traversed POD objects are of the same type as the current POD object, and, if the types are the same, accumulate the number of POD objects of the same type as the current POD object. Based on the number of POD objects of the same type as the current POD object and the total number of POD objects on the available node, the first score of the available node is determined according to the formula: first score = (1 - number of POD objects of the same type as the current POD object / total number of POD objects on the available node) × 10. A second score for each available node is determined based on the first score of each available node and the space and resource load on each available node, wherein the space and resource load on each available node includes the CPU of each available node, the memory of each available node, the disk throughput of each available node, and the network load of each available node; Based on the second score of each available node, the available nodes are prioritized and sorted, and the available node with the highest second score is determined as the target node; The runtime module is used to receive an application creation request and run the POD on the target node according to the application creation request.

4. A device, characterized in that, The device includes a processor and a memory; The processor is configured to execute instructions stored in the memory to cause the device to perform the method as described in any one of claims 1 to 2.

5. A computer-readable storage medium, characterized in that, Includes instructions that instruct the device to perform the method as described in any one of claims 1 to 2.

Citation Information

Patent Citations

  • Container scheduling method and device, container scheduler and readable storage medium

    CN111045821A

  • Resource allocation method and device, computer equipment and storage medium

    CN113110938A