A cloud-native scheduling method and server system based on differentiated task portraits

Abstract

A cloud native scheduling method based on differentiated task profiling and a server system.The application belongs to the technical field of cloud computing, and particularly relates to a cloud native scheduling method based on Kubernetes task profiling and a server system, which comprises the following steps: S1, profiling construction of delay-sensitive tasks and non-delay-sensitive tasks; and S2, task scheduling according to quality of service information QoS indicators of the delay-sensitive tasks and the non-delay-sensitive tasks.The cloud native scheduling method based on Kubernetes task profiling can not only guarantee the stability of running tasks, but also improve the overall resource utilization and save resources.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of cloud computing, and in particular to a cloud native scheduling method based on differentiated task profiling and a server system. BACKGROUND

[0002] Cloud native is a new architecture paradigm for super large scale distributed applications, which has been favored by the industry and academia. The key technology of cloud native is virtualization technology. Through virtualization of various resources, cloud native service providers can conveniently customize and deliver various resources to users for use, while users no longer need to consider the underlying resources and environment configuration. Users can disassemble the original super large scale distributed application into numerous independent business modules through virtualization means such as container technology or virtual machine technology. These modules are fully decoupled, and a client-server mode is built between the modules to cooperatively process business. For these numerous and diverse business modules, there are many cloud native management systems such as Kubernetes and OpenStack, among which Kubernetes is the most mainstream. Kubernetes encapsulates containers as Pods, and deploys, maintains, and upgrades the Pods running thereon through simple commands, significantly reducing the difficulty of service providers and users in managing large-scale container clusters. Compared with traditional separate management of each machine, Kubernetes virtualizes numerous independent physical machine resources, improves overall resource utilization while ensuring business stability by properly scheduling and managing containers.

[0003] Currently, the scheduling strategy of Kubernetes is to first select available machines according to the affinity of the Pod and other specific requirements, and then select the machine with the largest idle resource from the available machines to schedule the Pod. After the Pod selects the machine for scheduling, the single-machine component Kubelet of Kubernetes will take over the startup and running management of the Pod. When the resource usage of the Pod exceeds its request, Kubelet will restart the Pod to ensure that it does not interfere with the normal operation of other Pods.

[0004] However, the current Kubernetes only provides a platform with strong compatibility, but there are still a series of problems in the scheduling of containers. For example, in order to ensure the stability of part of the business, the default scheduling scheme is too simple and conservative, which ultimately leads to the inability to improve the overall resource utilization of the cluster, and a large amount of resources are idle. SUMMARY

[0005] In view of this, the application provides a cloud-native scheduling method based on differentiated task profiling, which solves the problem of improving cluster resource utilization as much as possible while ensuring the normal execution of services with high stability requirements.

[0006] To solve the above technical problems, the application provides a cloud-native scheduling method based on Kubernetes task profiling, including the following steps:

[0007] S1, profiling construction of delay-sensitive tasks and non-delay-sensitive tasks,

[0008] S2, task scheduling according to the quality of service information QoS indicators of delay-sensitive tasks and non-delay-sensitive tasks.

[0009] Further, the step of profiling construction of delay-sensitive tasks and non-delay-sensitive tasks includes:

[0010] S11, collecting resource utilization information RU, physical machine resource utilization RU, hardware event information HE, and quality of service information QoS of delay-sensitive tasks, and constructing a random forest model RM of quality of service information QoS and resource utilization information RU, physical machine resource utilization RU, and hardware event information HE;

[0011] S12, collecting resource utilization information RU, hardware index information HE, and quality of service information QoS of non-delay-sensitive tasks, and constructing a linear model LM of quality of service information QoS and resource utilization information RU, and hardware index information HE.

[0012] Further, the step of profiling construction of delay-sensitive tasks and non-delay-sensitive tasks includes:

[0013] S13, distinguishing the quality of service information QoS of delay-sensitive tasks and non-delay-sensitive tasks, defining the quality of service information QoS of non-delay-sensitive tasks as completion time, and defining the quality of service information QoS of delay-sensitive tasks as pressure blocking information PSI.

[0014] Further, the step of task scheduling according to the quality of service information QoS indicators of delay-sensitive tasks and non-delay-sensitive tasks includes:

[0015] S21, predicting the average resource utilization required to meet different completion times using the linear model LM of non-delay-sensitive tasks;

[0016] S22: using the random forest model of delay-sensitive task to determine the range of quality of service information QoS index of delay-sensitive task under the condition of different resource utilization of non-delay-sensitive task, and giving the machine with the least impact on the quality of service information QoS index as the running machine of the task.

[0017] Further, the method further comprises:

[0018] The scheduler receives a new Pod request.

[0019] The scheduler determines whether the category of the Pod is a delay-sensitive task or a non-delay-sensitive task according to the resource request of the Pod, the name of the Pod, the application to which the Pod belongs and the label of the Pod.

[0020] Further, when the category of the Pod is a delay-sensitive task:

[0021] The node with the highest resource idle rate in the cluster is selected as the running node of the Pod,

[0022] The Pod is run, the running information of the Pod on the node is monitored in real time, and the running information is returned to step S1.

[0023] Further, when the category of the Pod is a non-delay-sensitive task:

[0024] The minimum resource utilization under the premise that the execution time of the non-delay-sensitive task does not exceed the longest execution time in the historical record of the same type of Pod is calculated, that is,

[0025] min(RU), s.t. LM(RU, HE)≤Max(ExecutionTime);

[0026] The quality of service information QoS of the delay-sensitive task LS application on each machine is calculated according to the random forest model RM,

[0027] QoS pred = RM(NLS-MRU+NRU, RU, HE),

[0028] Meanwhile, the QoS min = RM(RR+NRU, RU, HE) needs to be calculated, the current QoS is QoS now , the sum of the predicted value of the QoS on the same machine in the future period of time and the difference value of the current QoS value is calculated, that is, The machine with the minimum value is selected from the cluster as the running node of the Pod.

[0029] On the other hand, the application further provides a server system, which comprises: ​

[0030] processor, and

[0031] The memory communicatively connected to the processor, wherein,

[0032] The memory stores readable instructions, which, when executed by the processor, implement the scheduling method described above.

[0033] Compared to existing technologies, the advantages of this application are as follows:

[0034] This application addresses the shortcomings of existing technologies that rely solely on resource utilization information for scheduling decisions. These technologies struggle to guarantee QoS across different service types and fail to fully utilize cluster resources. The cloud-native scheduling solution based on differentiated task profiles categorizes running tasks into latency-sensitive and non-latency-sensitive types. Corresponding profiles are constructed for each type, and these profiles are then used to predict whether and approximately how QoS will be affected by different resource usage scenarios. Finally, the machine with the least QoS impact is selected as the task execution machine. This approach not only ensures task stability but also improves overall resource utilization and conserves resources. Attached Figure Description

[0035] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0036] Figure 1 A flowchart illustrating the implementation of a cloud-native scheduling method based on differentiated task profiles, provided in this application embodiment;

[0037] Figure 2 This is a flowchart illustrating the specific application implementation of a cloud-native scheduling method based on differentiated task profiles, as provided in this application embodiment. Detailed Implementation

[0038] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below with reference to specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them.

[0039] This invention provides a cloud-native scheduling method based on differentiated task profiles, including the following steps, please refer to [link / reference]. Figure 1 :

[0040] S1. Create profiles for latency-sensitive and non-latency-sensitive tasks.

[0041] S2, scheduling tasks according to quality of service information QoS indicators of delay-sensitive tasks and non-delay-sensitive tasks.

[0042] More specifically, please refer to Figure 2 :

[0043] First step:

[0044] 1) Collect resource usage information RU, physical machine resource usage RU, hardware event information HE, and quality of service information QoS of delay-sensitive tasks LS using collection tools Node exporter and cadvisor,

[0045] 2) Collect resource usage information RU, hardware indicator information HE, and quality of service information QoS of non-delay-sensitive tasks using collection tools Node exporter and cadvisor,

[0046] Second step:

[0047] 1) For delay-sensitive tasks LS, a random forest model RM is constructed using a random forest to describe the relationship between quality of service information QoS and resource usage information RU, physical machine resource usage RU, and hardware event information HE. The input of the model is NRU, RU, and HE, and the output is QoS. The model describes that under a certain NRU, RU, and HE, the range of Oos may be. Here, the QoS of the LS task is defined as the PSI (Pressure Stall Information) of the system. PSI can well reflect the degree of tension of the current resources, can significantly affect application-level indicators such as Throughput, ResponseTime, and is more stable than application-level indicators and is not easily affected by the structure of the application itself.

[0048] 2) For non-delay-sensitive tasks NLS, a linear model LM is constructed to describe the relationship between its QoS and resource usage RU and hardware event information HE. The input of the model is RU and HE, and the output is QoS. The model describes that under a certain RU and HE, the value of the QoS of the NLS task is returned. Since the QoS of NLS is usually its completion time, the model also indicates that with a certain RU and HE, the execution time estimate will be how much.

[0049] Third step:

[0050] When the first step and the second step are all executed, the scheduler receives a new Pod request.

[0051] Fourth step:

[0052] The scheduler determines whether a Pod belongs to a latency-sensitive task or a non-latency-sensitive task based on the Pod's resource request (RR), Pod name, application to which the Pod belongs, and Pod tag.

[0053] If the Pod belongs to a latency-sensitive task category, proceed to step 5; if the Pod belongs to a non-latency-sensitive task category, proceed to step 6.

[0054] Step 5:

[0055] Select the node with the highest resource idle rate in the cluster as the running node for the Pod, and proceed to step eight.

[0056] Step 6:

[0057] Calculate the minimum resource utilization rate while ensuring that the execution time of non-latency-sensitive pods does not exceed the longest execution time in the history of similar pods.

[0058] min(RU),stLM(RU,HE)≤Max(ExecutionTime);

[0059] The smallest RU is denoted as NLS-MRU.

[0060] Step 7:

[0061] Based on the Random Forest (RM) model, calculate the Quality of Service (QoS) information for latency-sensitive tasks on each machine. pred =RM(NLS-MRU+NRU,RU,HE), and to ensure that the QoS of LS applications is not affected in the future, it is also necessary to calculate the QoS. min =RM(RR+NRU,RU,HE), let the current QoS be QoS now Calculate the sum of the differences between the predicted QoS value and the current QoS value over a future period on the same machine, i.e. Select from cluster The smallest machine serves as the running node for a Pod.

[0062] Step 8:

[0063] Run the Pod, monitor the running information of the Pod on the node in real time, and return the running information to the first and second steps.

[0064] Example 2:

[0065] Embodiment 2 of the present invention provides a server system, the server system comprising:

[0066] processor, and

[0067] The memory communicatively connected to the processor, wherein,

[0068] The memory stores readable instructions, which, when executed by the processor, implement the scheduling method described above.

[0069] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A cloud-native scheduling method based on Kubernetes task profiling, characterized in that, Includes the following steps: S1. Construct profiles for both latency-sensitive and non-latency-sensitive tasks; S2. Perform task scheduling based on the Quality of Service (QoS) indicators of both delay-sensitive and non-delay-sensitive tasks. The method further includes: The scheduler receives new Pod requests; The scheduler determines whether a Pod belongs to a latency-sensitive task or a non-latency-sensitive task based on the Pod's resource request (RR), Pod name, application to which the Pod belongs, and Pod's tag. When the Pod belongs to the category of latency-sensitive tasks: Select the node with the highest resource idle rate in the cluster as the running node for the Pod. Run the Pod, monitor the running information of the Pod on the node in real time, and return the running information to step S1; When the Pod belongs to a non-latency-sensitive task type: Calculate the minimum resource utilization rate while ensuring that the execution time of non-latency-sensitive pods does not exceed the longest execution time in the history of similar pods. The smallest RU for a non-latency-sensitive Pod is denoted as NLS. MRU; QoS information for latency-sensitive tasks (LS) on each machine is calculated using the Random Forest (RM) model. ， Simultaneously, calculations are required. Let the current QoS be Calculate the predicted QoS value for a future period of time on the same machine. The sum of the differences from the current QoS value, i.e. Select from cluster The smallest machine serves as the running node for the Pod; The steps for profiling latency-sensitive and non-latency-sensitive tasks include: S11. Collect resource utilization information (RU), physical machine resource utilization (NRU), hardware event information (HE), and quality of service (QoS) for latency-sensitive tasks; construct a random forest model RM that integrates QoS with RU, NRU, and HE. S12. Collect resource utilization information RU, hardware event information HE, and quality of service information QoS for non-latency-sensitive tasks, and construct a linear model LM of QoS and resource utilization information RU and hardware event information HE.

2. The cloud-native scheduling method for Kubernetes task profiling according to claim 1, characterized in that, The steps for profiling latency-sensitive and non-latency-sensitive tasks also include: S13. Differentiate between Quality of Service (QoS) information for delay-sensitive tasks and non-delay-sensitive tasks. Define the QoS information for non-delay-sensitive tasks as completion time, and define the QoS information for delay-sensitive tasks as Pressure Congestion Information (PSI).

3. The cloud-native scheduling method for Kubernetes task profiling according to claim 1, characterized in that, The steps for scheduling tasks based on QoS indicators for both latency-sensitive and non-latency-sensitive tasks include: S21: Use the linear model LM for non-delay-sensitive tasks to predict the average resource utilization required to meet different completion times; S22: Using the Random Forest (RM) model for latency-sensitive tasks, determine the range of change of the Quality of Service (QoS) index for latency-sensitive tasks under different resource utilization conditions for non-latency-sensitive tasks, and assign the machine with the least impact on the QoS index as the running machine for the task.

4. A server system, characterized in that, The server system includes: processor, and The memory communicatively connected to the processor, wherein, The memory stores readable instructions, which are implemented when executed by the processor. The method as described in any one of claims 1-3.

Images