Computing cluster resource scheduling method and device, server and storage medium

Abstract

The invention discloses a computing cluster resource scheduling method and device, a server and a computer readable storage medium. According to the method, the expected resource utilization rate is calculated based on the resource request and the total amount of occupied resources, the strong reserved water level is taken as the boundary to screen and preselect the passing nodes, the strong reserved water level ensures that the cluster always keeps the resource capacity capable of accepting the large-specification container group, the problem of large-specification container group scheduling failure caused by resource fragmentation in the prior art is solved, and the resource utilization rate is improved. The response capability of the cluster to future resource demands is ensured; then, further combining the relative relationship between the expected resource utilization rate and the weak reserved water level, selecting a node with low expected resource utilization rate and high occupied resource total amount from the pre-selected passing nodes as a target node, so that the resource utilization concentration ratio is improved by utilizing the characteristic of high occupied resource total amount to reduce fragments; and excessive concentration of the resources is avoided under the condition that the expected resource utilization rate is low, and dynamic balance of the resources in container group deployment is guaranteed.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computers, in particular to a computing cluster resource scheduling method and device, a server and a computer readable storage medium. BACKGROUND

[0002] In a computing cluster, resource scheduling ensures that computing tasks (such as container groups (pods) in Kubernetes) run on appropriate nodes by managing hardware resources such as CPU, memory, disk, and network IO, which is a key link for efficient operation of distributed systems.

[0003] In the Kubernetes environment, there are two commonly used resource scheduling strategies. One is the Least Requested Priority strategy, which tends to schedule pods to nodes with the least allocated resources to achieve cluster load balancing. The other is the Most Requested Priority or Requested To Capacity Ratio strategy, which tends to schedule pods to nodes with the most allocated resources to improve resource utilization concentration, making it easier to schedule large-scale pods or shut down idle nodes to save costs during business off-peak periods.

[0004] However, these two strategies have obvious drawbacks. The Least Requested Priority strategy can lead to resource fragmentation, and when large-scale pods request scheduling, it may fail due to the lack of a single node that meets the demand, limiting the adaptability of the cluster to mixed load scenarios. The Most Requested Priority or Requested To Capacity Ratio strategy, while reducing fragmentation, can lead to excessive resource concentration, with high-load nodes having a large impact on the scope of failure, leading to a decrease in business availability, resource waste, and node-level resource contention, affecting pod performance.

[0005] Therefore, how to dynamically balance resource distribution and avoid fragmentation while reserving space for large-scale applications during resource scheduling is a problem that needs to be solved by those skilled in the art. SUMMARY

[0006] In view of the above-mentioned defects or deficiencies in the prior art, it is desirable to provide a computing cluster resource scheduling method, device, server and computer readable storage medium that can dynamically balance resource distribution and avoid fragmentation while reserving space for large-scale applications during resource scheduling.

[0007] In a first aspect, the embodiments of the present application provide a computing cluster resource scheduling method, comprising:

[0008] determine a container group to be scheduled and a candidate node, and obtain a resource request of the container group, a total amount of occupied resources on the candidate node, and a strong reservation water level and a weak reservation water level;

[0009] calculate an expected resource usage rate after the container group is scheduled to the candidate node according to the resource request and the total amount of occupied resources;

[0010] if the expected resource usage rate does not exceed the strong reservation water level, the candidate node is taken as a pre-selected passing node;

[0011] determine a node with a low expected resource usage rate and a high total amount of occupied resources from the pre-selected passing nodes as a target node according to a relative relationship between the expected resource usage rate and the weak reservation water level;

[0012] schedule the container group to the target node.

[0013] In an embodiment, determining a node with a low expected resource usage rate and a high total amount of occupied resources from the pre-selected passing nodes as a target node according to a relative relationship between the expected resource usage rate and the weak reservation water level comprises:

[0014] determining whether there is a node with an expected resource usage rate not exceeding the weak reservation water level in the pre-selected passing nodes;

[0015] if there is a node with an expected resource usage rate not exceeding the weak reservation water level in the pre-selected passing nodes, the node with an expected resource usage rate not exceeding the weak reservation water level is taken as a preferred node;

[0016] selecting a node with a high total amount of occupied resources from the preferred nodes as the target node.

[0017] In an embodiment, selecting a node with a high total amount of occupied resources from the preferred nodes as the target node comprises:

[0018] calculating a score of each of the preferred nodes according to an occupied resource rate by using a resource bin packing strategy, wherein the occupied resource rate is a proportion of the total amount of occupied resources to a total resource capacity;

[0019] taking a node with an expected resource usage rate exceeding the weak reservation water level as a non-preferred node, and calculating a score of each of the non-preferred nodes by using a basic scoring strategy, wherein a highest score in the basic scoring strategy is lower than a lowest score in the resource bin packing strategy;

[0020] selecting a node with a highest score as the target node.

[0021] In an embodiment, the computer cluster resource scheduling method further comprises:

[0022] If there is no node in the pre-selected passing node in which the expected resource usage rate does not exceed the weak reservation level, a node in which the occupied resource rate is highest is selected from the pre-selected passing node as the target node.

[0023] In an embodiment, after the container group is scheduled to the target node, the method further comprises:

[0024] The total amount of occupied resources of the target node is updated in real time.

[0025] In an embodiment, obtaining the resource request of the container group, the total amount of occupied resources on the candidate node, and the strong reservation level and the weak reservation level comprises:

[0026] Reading the label or annotation configuration of the candidate node, it is judged whether there is a configured strong reservation level and weak reservation level;

[0027] If not, the default strong reservation level and the default weak reservation level are extracted as the strong reservation level and the weak reservation level of the candidate node.

[0028] In an embodiment, before the determination of the container group to be scheduled and the candidate node, the method further comprises:

[0029] The strong reservation level and the weak reservation level corresponding to various resources are independently configured for the nodes and / or node groups in the computing cluster; wherein the resources include at least one of CPU, memory, disk, and network IO.

[0030] In a second aspect, the embodiments of the present application provide a computing cluster resource scheduling device, comprising:

[0031] The extraction module is configured to determine the container group to be scheduled and the candidate node, and obtain the resource request of the container group, the total amount of occupied resources on the candidate node, and the strong reservation level and the weak reservation level;

[0032] The pre-selection module is configured to calculate the expected resource usage rate after the container group is scheduled to the candidate node according to the resource request and the total amount of occupied resources; if the expected resource usage rate does not exceed the strong reservation level, the candidate node is taken as a pre-selected passing node.

[0033] The preferred module is configured to determine a node in which the expected resource usage rate is low and the total amount of occupied resources is high as a target node from the pre-selected passing node according to the relative relationship between the expected resource usage rate and the weak reservation level.

[0034] A scheduling module is configured to schedule the container group to the target node.

[0035] In a third aspect, an embodiment of the present application provides a server, comprising a memory, a processor, and a computer program stored in the memory and capable of running on the processor, and when the processor executes the program, the steps of the computing cluster resource scheduling method are implemented.

[0036] In a fourth aspect, an embodiment of the present application provides a computer readable storage medium, which stores a computer program, and the program is characterized in that when the program is executed by a processor, the steps of the computing cluster resource scheduling method are implemented.

[0037] The computing cluster resource scheduling method provided by the present application calculates the expected resource utilization based on the resource request and the total amount of occupied resources, quantifies the resource usage state after the container group is scheduled, and screens the pre-selected passing nodes with the strong reservation water level as the boundary, so that the strong reservation water level ensures that the cluster always has a resource capacity capable of accommodating large-specification container groups, solves the problem of large-specification container group scheduling failure caused by resource fragmentation in the prior art, guarantees the response capability of the cluster to future resource demand, and improves the stability of the cluster.

[0038] Additional aspects and advantages of the application will be made apparent by the following description of non-limiting embodiments thereof, given as a reference. BRIEF DESCRIPTION OF DRAWINGS

[0039] Other features, objects and advantages of the application will become apparent from the detailed description of non-limiting embodiments thereof, which is made with reference to the attached drawings:

[0040] Figure 1 A flowchart of a computing cluster resource scheduling method provided by an embodiment of the present application is shown;

[0041] Figure 2 A node resource partitioning diagram provided by an embodiment of the present application is shown;

[0042] Figure 3 An exemplary structural block diagram of a computing cluster resource scheduling device provided by an embodiment of the present application is shown;

[0043] Figure 4A structural schematic diagram of a computer system of a server suitable for implementing the embodiments of the present application is shown. DETAILED DESCRIPTION

[0044] The present application will be further described below in conjunction with the drawings and embodiments. It should be understood that the specific embodiments described herein are merely intended for the purpose of interpretation of the related application and are not limiting of the application. In addition, it should be noted that only parts related to the application are shown in the drawings for the purpose of description.

[0045] It should be noted that the embodiments and features in the embodiments in the present application can be combined with each other without conflict. The present application will be described in detail below with reference to the drawings and in conjunction with the embodiments. Although the embodiments of the present application provide the method operation instruction steps as shown in the embodiments or the drawings, more or fewer operation instruction steps can be included in the method based on conventional or non-creative labor. The execution order of the steps is not limited to the execution order provided by the embodiments of the present application in the steps that do not have logical necessary causality. The method can be executed in sequence or in parallel when the method is executed in actual processing or by the device, as shown in the embodiments or the drawings.

[0046] Embodiment One

[0047] The present embodiment proposes a computing cluster resource scheduling method. It should be noted that in the current cloud computing environment, Kubernetes (K8S) is a standard for container orchestration and resource scheduling, and its core scheduling component kube-scheduler is responsible for selecting a suitable host for a newly created Pod in the cluster worker node, and its resource scheduling process is divided into two stages of preselection and optimization. The core of the present method is to extend the scheduling logic of the Kubernetes native scheduler (kube-scheduler), and to integrate it into the scheduling framework of kube-scheduler by implementing a custom scheduler plugin (Scheduler Plugin). The custom scheduler plugin introduces two core concepts of strong reservation water level and weak reservation water level, and integrates them into the preselection and optimization stages of the scheduler.

[0048] Reference is made to Figure 1 , Figure 1 A flowchart of the computing cluster resource scheduling method provided by the present embodiment is shown. As Figure 1 shown, the method comprises:

[0049] S101, determining a container group to be scheduled and a candidate node, and obtaining the resource request of the container group, the total amount of occupied resources on the candidate node, and the strong reservation water level and the weak reservation water level;

[0050] First, identify the computing task carrier that needs resource allocation, i.e., the container group, such as a Pod in Kubernetes. Then, select nodes with resource allocation capabilities from the computing cluster, i.e., candidate nodes. Candidate nodes must meet the basic operating conditions of the cluster, such as being in normal operation and not marked as unschedulable, and are potential targets for container group deployment.

[0051] Collect all resource requests (requirements) required for the container group to run, including but not limited to specific requests for CPU, memory, disk, network I / O, such as a CPU request of 2 cores or a memory request of 4GB. Resource requests are the core basis for determining whether a node can support the container group.

[0052] The total amount of various resources currently occupied by all running container groups for each candidate node is calculated. For example, if a node has been allocated 8 CPU cores and 16GB of memory, this data is mainly used to calculate the expected resource usage after scheduling by combining the resource requests of container groups.

[0053] Extract the dual resource limit values ​​for each candidate node for various resource configurations, such as... Figure 2 The diagram shows a node resource partitioning scheme, which partitions node resources (such as CPU, MEM, DISK, disk I / O, network I / O) using strong and weak reservation levels.

[0054] Among them, the strong reservation level is a hard upper limit for the use of node resources, which is used to ensure that the reserved part of the node's resources are not over-occupied. For example, the strong reservation level can be configured to 85% of the node's total capacity.

[0055] The weak reserve level is a flexible warning line for node resource use, used to divide the comfort zone and warning zone of resource use and guide differentiated scoring strategies. For example, the weak reserve level can be configured as 70% of the total node capacity.

[0056] Resources above the strong reserve level are non-allocatable resources, also known as reserved resources. The core purpose of these resources is to address potential future resource demands, prevent excessively high node resource allocation rates, and thus avoid the problem of large-scale container groups being unable to be scheduled due to insufficient resources on a single node.

[0057] Resources below the weak reserve water level are considered high-priority allocable resources. During the node selection process, resources are preferentially allocated within this range.

[0058] Resources between the strong and weak reserved water levels are considered low-priority allocable resources. Low-priority allocable resources will only be enabled and used for allocation when the high-priority allocable resources of all nodes in the cluster are insufficient to meet the resource requirements of the container group.

[0059] This step, by identifying scheduling targets, screening potential nodes, and collecting resource demand and node status data, constructs a basic information pool for scheduling decisions. This provides necessary data support for subsequent calculations of expected resource utilization, execution of pre-selection filtering, and optimization, and is a key prerequisite for achieving dynamic balance in resource distribution while taking into account both resource concentration and reserved space.

[0060] It should be noted that the specific candidate selection rules for candidate nodes are not limited in this embodiment. You can refer to the operation rules of the native Kubernetes scheduler. For example, you can select nodes that are running and have resource allocation capabilities from the computing cluster as candidate nodes. This will not be elaborated here.

[0061] S102. Based on the resource requests and the total amount of resources already occupied, calculate the expected resource utilization rate after scheduling the container group to the candidate node;

[0062] After identifying the scheduling targets, candidate nodes, and related resource data, the expected resource utilization rate after the container group is scheduled to the candidate node is predicted through quantitative calculation. This transforms the abstract requirements of resource scheduling into quantifiable values, providing a precise basis for the implementation of the dual-level mechanism.

[0063] It should be noted that the specific calculation algorithm for the expected resource utilization rate is not limited in this embodiment. For example, the total amount of resources occupied by the candidate node can be added to the resource request amount of the container group to obtain the expected total resource usage of the node after scheduling this container group; then the expected total resource usage is compared with the total resource capacity of the node to obtain the expected resource utilization rate (i.e., expected total resource usage ÷ total resource capacity of the node × 100%). Specifically, if a node has a total CPU capacity of 10 cores, currently 6 cores are occupied, and the container group to be scheduled requests 2 cores, then the expected total CPU usage is 8 cores, and the expected CPU utilization rate is 80%. This embodiment only uses the above calculation method as an example. Other calculation algorithms (such as first calculating the current occupied resource rate of the candidate node, then calculating the proportion of the container group resource request amount to the total resource capacity of the node, and adding the two to obtain the expected resource utilization rate) can refer to the description in this embodiment, and will not be elaborated here.

[0064] S103. If the expected resource utilization rate does not exceed the strong reserved water level, the candidate node will be selected as the pre-selected node.

[0065] The standard is based on the comparison between the expected resource utilization rate and the strong reservation water level. The strong reservation water level is a hard upper limit for node resource utilization, such as 85% CPU utilization and 90% memory utilization. The expected resource utilization rate of each type of resource (CPU, memory, etc.) is checked one by one to see if it exceeds the corresponding strong reservation water level. If the expected utilization rate of all resources does not exceed the strong reservation water level, it means that after scheduling this container group, the node can still reserve unallocated resources above the strong reservation water level (i.e., reserved resources), meeting the requirement of reserving space for large-scale container groups. Therefore, it is judged as a pre-selected node and can enter the subsequent selection stage. If the expected utilization rate of any resource exceeds the strong reservation water level, the node is excluded in the pre-selection stage because it may lead to over-allocation of resources and inability to guarantee reserved space, and will not participate in subsequent scheduling.

[0066] This rigid screening enforces a red line for resource usage for each node, preventing nodes from being continuously allocated resources until they are exhausted. This reserves a deterministic resource pool for future large-scale container groups and prevents performance risks or failures caused by excessive resource concentration from expanding their impact. It is a fundamental aspect of ensuring the cluster resource reservation mechanism.

[0067] S104. Based on the relative relationship between the expected resource utilization rate and the weak reserved water level, determine the nodes with low expected resource utilization rate and high total occupied resources from the pre-selected nodes and use them as target nodes.

[0068] For nodes that have passed the preliminary selection, the comparison between expected resource utilization and weak reserved water level is used as the core judgment criterion. Within the range of nodes that have passed the preliminary selection, nodes that meet the two conditions of "low expected resource utilization and high total occupied resources" are selected and determined as target nodes. Among them, expected resource utilization refers to the expected proportion of resources used after the container group is scheduled to the node, and total occupied resources refers to the total resources currently occupied by all existing container groups on the node. The selection process is based solely on the numerical characteristics of these two indicators.

[0069] Among them, the weak reservation level is a flexible warning line for node resource usage, such as CPU utilization of 70% and memory utilization of 75%. It is used to divide the node resources into high-priority allocable zone (below the weak reservation level) and low-priority allocable zone (between the weak reservation level and the strong reservation level).

[0070] This step combines the relative relationship between expected resource utilization and weak reserved water level to select nodes with low expected resource utilization and high total occupied resources from the pre-selected nodes as target nodes. It leverages the high total occupied resources to increase resource utilization concentration and reduce fragmentation, while avoiding excessive resource concentration by using the condition of low expected resource utilization. It achieves precise node selection by balancing the two and adapts to the scheduling requirements under dual resource reserved water level.

[0071] S105. Schedule the container group to the target node.

[0072] After selecting nodes that meet the strong reserved water level requirements through the pre-selection phase, and determining target nodes with low expected resource utilization and high total occupied resources through the optimization phase based on the relative relationship of weak reserved water levels, the deployment operation of allocating the container group to the target node is executed. The container group will acquire the necessary resources on the target node and start running, which is the final manifestation of the resource scheduling decision.

[0073] It should be noted that the specific implementation method for scheduling container groups to target nodes is not limited in this embodiment. The implementation method of related technologies can be referred to, and this embodiment does not limit it.

[0074] It should be noted that after scheduling the container group to the target node, to ensure the accuracy of resource data, the total amount of occupied resources of the target node can be updated synchronously. This reflects the resource usage status after joining the newly scheduled container group, ensuring that the node resource status is up-to-date when scheduling other container groups. This provides a reliable data foundation for accurately calculating the expected resource utilization rate and determining whether the node meets the strong / weak reservation level requirements. Of course, the above settings can be omitted, and this embodiment does not limit this.

[0075] Based on the above introduction, the computing cluster resource scheduling method provided in this embodiment calculates the expected resource utilization rate based on resource requests and the total amount of occupied resources, quantifies the resource usage status after container group scheduling, and filters pre-selected nodes with a strong reservation level as the boundary. The strong reservation level ensures that the cluster always has the resource capacity to accommodate large-scale container groups, solving the problem of large-scale container group scheduling failure due to resource fragmentation in the prior art, ensuring the cluster's ability to cope with future resource demands, and improving cluster stability. Then, by combining the relative relationship between the expected resource utilization rate and the weak reservation level, nodes with low expected resource utilization rate and high total amount of occupied resources are selected from the pre-selected nodes as target nodes. This not only utilizes the characteristic of high total amount of occupied resources to improve resource utilization concentration to reduce fragmentation, but also avoids excessive resource concentration by using the condition of low expected resource utilization rate, thus achieving a balanced resource distribution. Finally, the container group is scheduled to the target node, completing the closed loop of resource allocation and ensuring the normal deployment and operation of the container group.

[0076] Example 2:

[0077] To ensure efficient node filling in conventional container groups to reduce fragmentation, while reserving space for large-scale container groups, this embodiment provides a specific implementation step for the optimization process of pre-selected nodes. The aim is to divide the node resource usage range by a weak reservation level and prioritize centralized resource scheduling within the resource comfort zone (not exceeding the weak reservation level).

[0078] Specifically, step S104, based on the relative relationship between the expected resource utilization rate and the weak reserved water level, determines the nodes with low expected resource utilization rates and high total occupied resources from the pre-selected nodes as target nodes. This process can be performed according to the following steps:

[0079] Step S41: Determine whether there are any nodes among the pre-selected nodes whose expected resource utilization rate does not exceed the weak reserved water level;

[0080] For all pre-selected nodes (i.e. nodes whose expected resource utilization rate does not exceed the strong reserve water level), check the relationship between their expected resource utilization rate and the corresponding weak reserve water level one by one, and determine whether there are any nodes among these nodes whose expected resource utilization rate is below the weak reserve water level.

[0081] The core of this judgment is to screen out nodes located in the high-priority allocable resource zone (below the weak reserved water level), providing a basis for subsequently prioritizing the selection of nodes in this zone using the resource bin packaging strategy, and ensuring that resource scheduling prioritizes the use of high-priority allocable resources.

[0082] Step S42: If there are nodes among the pre-selected nodes whose expected resource utilization rate does not exceed the weak reserve water level, then the nodes whose expected resource utilization rate does not exceed the weak reserve water level shall be selected as preferred nodes.

[0083] After determining the pre-selected nodes (i.e. nodes whose expected resource utilization rate does not exceed the strong reserve level), if there are nodes among them whose expected resource utilization rate does not exceed the weak reserve level, these nodes will be separately designated as preferred nodes.

[0084] If none of the pre-selected nodes have a expected resource utilization rate below the weak reservation level, all pre-selected nodes will exceed their weak reservation level after scheduling this Pod. This embodiment does not limit the handling method in this case. To control the management cost caused by resource dispersion and ensure scheduling continuity, the node with the highest resource utilization rate among the pre-selected nodes can be selected as the target node. For example, if the expected resource utilization rates of all pre-selected nodes have entered the warning zone, but one pre-selected node has an expected resource utilization rate of 71% and another has an expected resource utilization rate of 75%, the 75% node can still be selected, continuing the Bin Packing principle to ensure that the scheduling process does not fail because all nodes are in a warning state. Of course, other processing methods can also be configured, such as randomly selecting a pre-selected node as the target node, or selecting based on other node attributes (such as node hardware performance, network conditions, etc.). Specific configurations can be made according to the needs of the actual application scenario, and will not be elaborated further here.

[0085] Step S43: Select the node with the highest total occupied resources from the preferred nodes as the target node.

[0086] Based on the identified preferred nodes, the node with the highest total resource usage is selected from these nodes and designated as the target node for the container group to be scheduled.

[0087] By prioritizing nodes with high total resource usage, resource centralization is promoted to fill some nodes as quickly as possible, naturally freeing up complete resource space for other nodes. This avoids resource fragmentation and reserves available nodes for subsequent large-scale container groups.

[0088] This embodiment does not limit the specific screening rules in step S43. To deepen understanding, this embodiment further proposes an implementation method that determines the scheduling priority of nodes based on their scores and ultimately selects the optimal node. The specific steps are as follows:

[0089] Step S431: Using the resource bin packing strategy, calculate the score of each preferred node based on the occupied resource rate;

[0090] For candidate nodes designated as preferred nodes, a resource bin packaging strategy is used to calculate their scores. The core criterion for calculation is the occupied resource rate, which is the proportion of the total resources occupied by the node to the total resource capacity. Under this strategy, the higher the occupied resource rate of a node, the higher its score. This quantifies the scheduling logic of prioritizing nodes with high occupied resource amounts, promoting the centralized allocation of resources within the high-priority allocable zone, which aligns with the design logic of using resource bin packaging scoring below the weak reservation level.

[0091] Step S432: Nodes whose expected resource utilization exceeds the weak reserve water level are designated as non-preferred nodes, and the score of each non-preferred node is calculated using the basic scoring strategy.

[0092] For nodes whose expected resource utilization exceeds the weak reservation level, they are designated as non-preferred nodes, and their scores are calculated using a basic scoring strategy. These nodes are given a very low base score, or only 0 or 1 points within a standardized scoring range (e.g., 0-10). The highest score under the basic scoring strategy is lower than the lowest score under the resource bin packing strategy (used for evaluating preferred nodes). This design ensures that the scores of non-preferred nodes are always lower than those of preferred nodes. Therefore, during scheduling, non-preferred nodes are only considered when there are no suitable preferred nodes, conforming to the resource allocation logic that resources above the weak reservation level are considered low-priority and are only used when high-priority resources are insufficient.

[0093] Step S433: Select the node with the highest score as the target node.

[0094] The above scoring strategy employs a resource binning strategy for preferred nodes and a basic scoring strategy for non-preferred nodes, selecting the highest-scoring node as the target node. This achieves differentiated and prioritized resource scheduling, promoting resource concentration within high-priority allocable resource areas to reduce fragmentation, while the scoring mechanism inhibits overuse of low-priority allocable resource areas. Furthermore, the unified scoring standard ensures the objectivity and rationality of target node selection, effectively balancing resource concentration and reservation requirements, and improving scheduling adaptability and success rate. It should be noted that the configuration of other scoring strategies can be referred to the description in this embodiment, and will not be repeated here.

[0095] The target node screening method provided in this embodiment clearly distinguishes between high-priority allocable resource zones (not exceeding the weak water level) and low-priority allocable resource zones (exceeding the weak water level but not exceeding the strong water level) by determining whether a node exceeds the weak reserved water level. This makes the scheduling logic more targeted, only selecting nodes that do not exceed the weak reserved water level as preferred nodes, ensuring that the resource comfort zone is used first and avoiding premature occupation of the warning zone resources. At the same time, among the preferred nodes, nodes with a high total amount of occupied resources are selected, and resource utilization concentration is improved through centralized deployment, reducing fragmentation and balancing resource efficiency and reserved space guarantee.

[0096] Example 3:

[0097] To improve the flexibility of configuring strong and weak reserved water levels, while ensuring the consistency of scheduling logic regardless of whether nodes are configured individually.

[0098] The process of obtaining the strong and weak reserved water levels of candidate nodes in step S101 can be performed according to the following steps:

[0099] Step S11: Read the label or annotation configuration of the candidate node and determine whether there is a configured strong reserved water level or a weak reserved water level;

[0100] For each candidate node, check whether the node has individually set parameters for strong and weak reserved water levels by reading the configuration information in its label or annotation.

[0101] Resource reservation levels can be configured via node tags or annotations, offering high flexibility.

[0102] For example, the following annotation can be defined on a Node object:

[0103] scheduler.invention.com / cpu-strong-reservation-percent:"85"

[0104] scheduler.invention.com / cpu-weak-reservation-percent:"70"

[0105] scheduler.invention.com / mem-strong-reservation-percent:"90"

[0106] scheduler.invention.com / mem-weak-reservation-percent:"75"

[0107] If there are configured strong and weak reserved water levels, then the configured strong and weak reserved water levels can be directly used as the reserved water levels and weak reserved water levels of the candidate nodes.

[0108] Step S12: If it does not exist, extract the default strong reserved water level and the default weak reserved water level as the strong reserved water level and weak reserved water level of the candidate node.

[0109] When the inspection finds that a candidate node does not have a separate strong reserved water level and a weak reserved water level configured, the preset default strong reserved water level and default weak reserved water level are extracted from the system and used as the strong reserved water level and weak reserved water level of the node.

[0110] This step ensures that each candidate node has a clear resource reservation level parameter, providing necessary data support for subsequent scheduling decisions based on strong and weak reservation levels, and ensuring the smooth progress of the scheduling process.

[0111] The method for obtaining strong and weak reserved water levels provided in this embodiment allows for the individual configuration of strong and weak reserved water levels through nodes, node group tags, or annotations. This meets the personalized resource management needs of different nodes, while the default value setting ensures scheduling compatibility for nodes without individual configuration. Regardless of whether a node has individual configuration, the strong and weak reserved water levels can be clearly obtained, avoiding scheduling process interruptions due to missing parameters. This ensures the consistent application of the dual resource reservation mechanism across all cluster nodes and provides a reliable basis for judgment in the pre-selection and optimization stages.

[0112] Example 4:

[0113] This embodiment proposes a configuration step for strong and weak reserved water levels. Before determining the container group and candidate nodes to be scheduled in step S101, the strong and weak reserved water levels of different resources in the nodes and / or node groups in the cluster can be pre-configured and independently configured.

[0114] Specifically, for a single node or node group within the computing cluster, or both nodes and node groups are configured simultaneously, corresponding strong and weak reservation levels are independently configured for at least one of the following resources: CPU, memory, disk, and network I / O. That is, different nodes or node groups can set different strong and weak reservation level values ​​for different types of resources according to actual needs, and these configurations are independent of each other and do not affect each other.

[0115] Personalized configuration allows for clear reservation standards for each resource on different nodes or node groups, providing a basis for resource allocation and node selection based on strong and weak reservation levels during subsequent scheduling. It allows for independent configuration of reservation levels for different resources for individual nodes or node groups, and personalized parameters can be set according to differences in node hardware characteristics and the types of services carried, meeting diverse resource management needs. At the same time, reservation levels can be configured separately for various resources such as CPU and memory, enabling differentiated management based on the characteristics of different resources and business needs, thus improving adaptability to mixed resource load scenarios.

[0116] Example 5:

[0117] Further reference Figure 3 The diagram illustrates an exemplary structural block diagram of a computing cluster resource scheduling device according to an embodiment of the present application, which mainly includes an extraction module, a pre-selection module, an optimization module, and a scheduling module. The computing cluster resource scheduling device adopts a modular design and achieves dynamic balance of resource distribution through four core units.

[0118] The extraction module is used to determine the container group to be scheduled and the candidate nodes, and to obtain the resource requests of the container group, the total amount of resources occupied on the candidate nodes, and the strong and weak reserved water levels.

[0119] The pre-selection module is used to calculate the expected resource utilization rate after scheduling the container group to the candidate node based on the resource request and the total amount of occupied resources; if the expected resource utilization rate does not exceed the strong reservation water level, the candidate node is selected as the pre-selected node;

[0120] The optimization module is used to determine the target nodes from the pre-selected nodes based on the relative relationship between the expected resource utilization rate and the weak reserved water level.

[0121] The scheduling module is used to schedule container groups to target nodes.

[0122] It should be noted that the specific workflow of each module in the computing cluster resource scheduling device provided in this embodiment can be referred to the explanation of the above embodiment. The overlapping parts will not be repeated here, and the two parts can be referred to each other.

[0123] The computing cluster resource scheduling device provided in this embodiment has an extraction module that uniformly acquires the core data required for scheduling, providing an accurate basis for subsequent steps; a pre-selection module that uses a strong reservation level as a hard constraint to ensure that resources are reserved for large-scale container groups, avoiding over-allocation of resources; an optimization module that combines a weak reservation level to dynamically screen nodes, balancing resource concentration and fragmentation, and improving the adaptability of mixed loads; and a scheduling module that ensures the implementation of decisions, realizing a closed loop from data acquisition to resource allocation. Overall, this device improves cluster stability, resource utilization, and scheduling success rate.

[0124] Example 6:

[0125] The following is for reference. Figure 4 , Figure 4 A schematic diagram of the structure of a computer system suitable for implementing the server of the present application is shown.

[0126] like Figure 4 As shown, the computer system includes a central processing unit (CPU) 401, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 402 or programs loaded from storage section 408 into random access memory (RAM) 403. RAM 403 also stores various programs and data required for the system's operating instructions. CPU 401, ROM 402, and RAM 403 are interconnected via bus 404. Input / output (I / O) interface 405 is also connected to bus 404.

[0127] The following components are connected to I / O interface 405: an input section 406 including a keyboard, mouse, etc.; an output section 407 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 408 including a hard disk, etc.; and a communication section 409 including a network interface card such as a LAN card, modem, etc. The communication section 409 performs communication processing via a network such as the Internet. Drive 410 is also connected to I / O interface 405 as needed. Removable media 411, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 410 as needed so that computer programs read from them can be installed into storage section 408 as needed.

[0128] Specifically, according to embodiments of this application, the flowchart above refers to... Figure 1The described process can be implemented as a computer software program. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowchart. In such an embodiment, the computer program contains program code for performing the methods shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via communication section 409, and / or installed from removable medium 411. When the computer program is executed by central processing unit (CPU) 401, it performs the functions defined in the system of this application.

[0129] It should be noted that the computer-readable medium shown in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0130] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operational instructions of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two connected blocks may actually be executed substantially in parallel, or they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified functions or operational instructions, or using a combination of dedicated hardware and computer instructions.

[0131] The units or modules described in the embodiments of this application can be implemented in software or hardware. The described units or modules can also be located in a processor. The names of these units or modules do not, in certain circumstances, constitute a limitation on the unit or module itself.

[0132] In another aspect, this application also provides a computer-readable storage medium, which may be included in the server described in the above embodiments, or may exist independently and not assembled into the server. The aforementioned computer-readable storage medium stores one or more programs that, when used by one or more processors, execute the data balancing method described in this application.

[0133] The above description is merely a preferred embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this application is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the foregoing disclosed concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this application.

Claims

1. A method for scheduling computing cluster resources, characterized in that, include: Identify the container groups to be scheduled and candidate nodes, and obtain the resource requests of the container groups, the total amount of resources already occupied on the candidate nodes, and the strong and weak reserved water levels; Based on the resource request and the total amount of resources already occupied, calculate the expected resource utilization rate after scheduling the container group to the candidate node; If the expected resource utilization rate does not exceed the strong reserved water level, the candidate node will be selected as the pre-selected node. Based on the relative relationship between the expected resource utilization rate and the weak reserved water level, nodes with low expected resource utilization rate and high total occupied resources are determined from the pre-selected nodes and selected as target nodes. Schedule the container group to the target node.

2. The method as described in claim 1, characterized in that, Based on the relative relationship between the expected resource utilization rate and the weak reserved water level, nodes with low expected resource utilization rates and high total occupied resources are identified from the pre-selected nodes as target nodes, including: Determine whether there are any nodes among the pre-selected nodes whose expected resource utilization rate does not exceed the weak reserved water level; If there is a node among the pre-selected nodes whose expected resource utilization rate does not exceed the weak reserve level, the node whose expected resource utilization rate does not exceed the weak reserve level shall be selected as the preferred node. The node with the highest total occupied resources is selected from the preferred nodes and designated as the target node.

3. The method as described in claim 2, characterized in that, Selecting the node with the highest total occupied resources from the preferred nodes as the target node includes: A resource bin packaging strategy is adopted to calculate the score of each preferred node based on the occupied resource rate; wherein, the occupied resource rate is the ratio of the total occupied resources to the total resource capacity; Nodes whose expected resource utilization exceeds the weak reserved water level are designated as non-preferred nodes, and a basic scoring strategy is used to calculate the score of each non-preferred node; wherein, the highest score in the basic scoring strategy is lower than the lowest score in the resource bin packaging strategy. The node with the highest score is selected as the target node.

4. The method as described in claim 2, characterized in that, Also includes: If there is no node among the pre-selected nodes whose expected resource utilization rate does not exceed the weak reserved water level, the node with the highest occupied resource rate is selected from the pre-selected nodes as the target node.

5. The method as described in claim 1, characterized in that, After scheduling the container group to the target node, the process further includes: The total amount of resources occupied by the target node is updated in real time.

6. The method as described in claim 1, characterized in that, Obtaining the resource requests of the container group, the total amount of resources already occupied on the candidate nodes, and the strong and weak reserved water levels, including: Read the label or annotation configuration of the candidate node to determine whether there is a strong reserved water level or a weak reserved water level configured. If not, extract the default strong reserved water level and the default weak reserved water level, and use them as the strong reserved water level and weak reserved water level of the candidate node.

7. The method according to any one of claims 1 to 6, characterized in that, Before determining the container group to be scheduled and the candidate nodes, the following steps are also included: The nodes and / or groups of nodes in the computing cluster are independently configured with strong and weak reservation levels for various resources; wherein the resources include at least one of CPU, memory, disk and network I / O.

8. A computing cluster resource scheduling device, characterized in that, include: The extraction module is used to determine the container group to be scheduled and the candidate node, and to obtain the resource request of the container group, the total amount of resources occupied on the candidate node, and the strong reservation water level and weak reservation water level. The pre-selection module is used to calculate the expected resource utilization rate after scheduling the container group to the candidate node based on the resource request and the total amount of occupied resources; if the expected resource utilization rate does not exceed the strong reservation level, the candidate node is selected as the pre-selected node. The optimization module is used to determine, from the pre-selected nodes, nodes with low expected resource utilization and high total occupied resources as target nodes based on the relative relationship between the expected resource utilization rate and the weak reserved water level. The scheduling module is used to schedule the container group to the target node.

9. A server, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the steps of the method as described in any one of claims 1 to 7.

Images