A method and system for scheduling a cluster

Abstract

The application provides a cluster scheduling method and system, and relates to the technical field of cloud computing. The cluster scheduling method comprises the following steps: collecting resource usage data of each node and a Pod, wherein the node runs the Pod, and the resource usage data is used to represent the usage of memory and CPU; in response to a Pod scheduling request, determining the resource estimated usage of a to-be-scheduled Pod, the resource usage of each node, and the total amount of node allocatable resources according to the resource usage data, and screening a first set of nodes with a resource usage rate lower than a first usage rate threshold according to the three factors, and screening a second set of nodes in the first set, wherein the newly-built offline Pod data of the nodes in the second set does not exceed an allowed newly-built offline Pod quantity threshold. The application can improve the utilization rate of the cluster and ensure the stability of scheduling.

Description

Technical Field

[0001] This invention relates to the field of cloud computing technology, and more specifically, to a cluster scheduling method and system. Background Technology

[0002] A cluster is a collection of physical or virtual computers (nodes) that provide basic computing resources. Kubernetes is an open-source container orchestration platform that runs on top of clusters and is used to automate the deployment, scaling, and management of containerized applications on multiple hosts in a cloud platform.

[0003] In related technologies, the native scheduler (kube-scheduler) adopts a static resource quota scheduling mechanism, which relies on static resource quota requests as the scheduling basis. Pod is the smallest scheduling unit in Kubernetes. When scheduling Pod, the static resource quota request remains unchanged, resulting in low resource utilization. Moreover, offline tasks often exhibit "sudden high load and long idle periods". However, the native scheduler still needs to schedule according to the static resource quota, which means that the idle resources of the node cannot be reused, and new Pods cannot be scheduled. New Pods are easily scheduled to high-load nodes, causing new Pods to be evicted or nodes to become overloaded. Summary of the Invention

[0004] The problem that this invention aims to solve is that the native scheduler has low resource utilization and stability issues during scheduling.

[0005] To address the aforementioned problems, in a first aspect, the present invention provides a cluster scheduling method, comprising:

[0006] Collect resource usage data for each node and Pod, wherein Pods are running on the nodes, and the resource usage data is used to characterize memory and CPU usage;

[0007] In response to a Pod scheduling request, the estimated resource usage of the Pod to be scheduled, the resource usage of each node, and the total amount of resources that can be allocated to the node are determined based on the resource usage data. Then, a first set of nodes whose resource usage rate is lower than a first usage rate threshold is selected based on the three factors. A second set of nodes in the first set whose newly created offline Pod data does not exceed the threshold for the number of newly created offline Pods is selected.

[0008] Based on the resource usage and total allocatable resources of each node in the second set, and the estimated resource usage of the Pod to be scheduled, the estimated resource utilization rate after the Pod to be scheduled is scheduled to each node in the second set is determined. Based on the estimated resource utilization rate and the maximum expected utilization rate, the first score of each node in the second set is determined. Based on the newly created offline Pod data of each node in the second set, the second score of each node in the second set is determined.

[0009] By combining the first score and the second score, candidate nodes are determined in the second set, and the Pod to be scheduled is scheduled to the candidate node.

[0010] The cluster scheduling method provided by this invention collects resource usage data of each node and Pod to provide a basis for constructing a global resource view. In response to a Pod scheduling request, it determines the estimated resource usage of the Pod to be scheduled, the resource usage of each node, and the total allocatable resources of each node based on the resource usage data. It then filters a first set of nodes whose resource utilization is below a first utilization threshold, and a second set of nodes in the first set whose newly created offline Pod data does not exceed the allowed threshold for the number of newly created offline Pods, ensuring that candidate nodes simultaneously meet resource availability and business compatibility requirements. Finally, based on the resource usage of each node in the second set, the estimated resource usage of the Pod to be scheduled, and the total allocatable resources of each node, it determines the estimated resource utilization of the Pod after it is scheduled to each node in the second set, and then... The estimated resource utilization and maximum expected utilization are used to determine the first score of each node in the second set. Based on the newly created offline Pod data of each node in the second set, the second score of each node in the second set is determined. The Pods to be scheduled can be simulated and scheduled to each node in the second set. At the same time, considering the accurate resource utilization and the potential impact of offline load, a dynamic resource view is constructed to accurately quantify the risk of over-utilization and provide an accurate measurement basis for the adaptability of the Pods to be scheduled to each node in the second set. Finally, the first score and the second score can be combined to select the optimal node and schedule the Pods to be scheduled to the selected node. This ensures resource utilization efficiency while maintaining overall stability. That is, through a data-driven fine-grained scheduling strategy, the existing task requirements and the task characteristics of the Pods to be scheduled are effectively balanced, and the optimal configuration of cluster resources is achieved.

[0011] Secondly, the present invention also provides a cluster scheduling system, which applies the cluster scheduling method described in any of the preceding claims, comprising:

[0012] The metrics collection module is used to collect resource usage data for each node and Pod, wherein the nodes include Pods, and the resource usage data is used to characterize memory and CPU usage.

[0013] The filtering module is used to respond to a Pod scheduling request, determine the estimated resource usage of the Pod to be scheduled, the resource usage of each node, and the total amount of resources that can be allocated to the node based on the resource usage data, and filter the first set of nodes whose resource usage rate is lower than a first usage rate threshold based on the three factors, and filter the second set of nodes in the first set whose newly created offline Pod data does not exceed the threshold for the number of newly created offline Pods.

[0014] The estimation and determination module is used to determine the estimated resource utilization rate of the Pod to be scheduled after it is scheduled to each of the nodes in the second set, based on the resource usage of each node in the second set and the total amount of resources that the node can allocate, as well as the estimated resource usage of the Pod to be scheduled. Based on the estimated resource utilization rate and the maximum expected utilization rate, the module determines the first score of each node in the second set. Based on the newly created offline Pod data of each node in the second set, the module determines the second score of each node in the second set.

[0015] The scheduling module is used to combine the first score and the second score to determine the candidate nodes in the second set, and schedule the Pod to be scheduled to the candidate nodes.

[0016] Thirdly, the present invention provides an electronic device, including a memory and a processor;

[0017] The memory is used to store computer programs;

[0018] The processor is configured to implement the cluster scheduling method as described in the first aspect when executing the computer program.

[0019] Fourthly, the present invention provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the cluster scheduling method as described in the first aspect.

[0020] The cluster scheduling system, electronic device, and computer-readable storage medium provided by this invention have the same beneficial effects as the cluster scheduling method compared to the prior art, and will not be repeated here. Attached Figure Description

[0021] Figure 1 A flowchart illustrating a cluster scheduling method according to an embodiment of the present invention is shown;

[0022] Figure 2 This invention illustrates the overall architecture diagram of scheduling based on a Kubernetes cluster in an embodiment of the present invention;

[0023] Figure 3 This diagram illustrates the changes in CPU-aware scheduling scores in an embodiment of the present invention.

[0024] Figure 4 A schematic diagram of the cluster scheduling system in an embodiment of the present invention is shown;

[0025] Figure 5 A schematic diagram of the structure of an electronic device according to an embodiment of the present invention is shown. Detailed Implementation

[0026] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0027] It should be noted that relational terms such as "first" and "second" in this invention are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0028] In the description of this specification, references to terms such as "embodiment," "one embodiment," and "one implementation" indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or implementation is included in at least one embodiment or illustrative implementation of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or implementation. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or implementations.

[0029] Reference Figure 1 and Figure 2 As shown in the figure, an embodiment of the present invention proposes a cluster scheduling method;

[0030] The cluster scheduling method includes:

[0031] S100: Collect resource usage data for each node and Pod, wherein Pods are running on the nodes, and the resource usage data is used to characterize memory and CPU usage.

[0032] Specifically, in Kubernetes, a Node is a worker node (physical machine or virtual machine) in the cluster, responsible for running Pods. Each Node provides computing resources (CPU and memory, etc.), and a Pod is the smallest scheduling unit in Kubernetes, containing one or more containers (such as Docker containers) and sharing network and storage resources. Monitoring tools such as cAdvisor can be used to collect CPU and memory usage information of the Node itself, as well as CPU and memory usage information of the Pods on each node. Resource usage data includes this information.

[0033] S200: In response to a Pod scheduling request, determine the estimated resource usage of the Pod to be scheduled, the resource usage of each node, and the total amount of resources that can be allocated to the node based on the resource usage data. Then, based on the three factors, filter a first set of nodes whose resource usage rate is lower than a first usage rate threshold, and filter a second set of nodes in the first set whose newly created offline Pod data does not exceed the threshold for the number of newly created offline Pods.

[0034] Specifically, when a Pod scheduling request is detected, the system responds to the Pod scheduling request. The Pod to be scheduled is generally an offline Pod. Offline Pods are used to provide short-cycle or timed computing tasks. Resource usage data can be used to parse the resource usage of each node and the total amount of resources that can be allocated to the node. For the estimated resource usage of the Pod to be scheduled, the resource usage of the Pod to be scheduled can be determined comprehensively based on the resource requirements and limits of the Pod to be scheduled. The first set is filtered by the three factors and the first utilization rate threshold. The second set is further determined by combining the data of newly created offline Pods in the nodes in the first set. This can further reflect the changes in offline Pods on the nodes. The first set and the second set obtained by combining the two filtering conditions, that is, firstly, a preliminary filtering is performed based on the current resource utilization rate, and then a secondary filtering is performed based on the distribution of offline tasks, to ensure that the candidate nodes simultaneously meet the requirements of resource availability and business compatibility, which facilitates the global decision-making of subsequent scheduling.

[0035] S300: Based on the resource usage and total allocatable resources of each node in the second set, and the estimated resource usage of the Pod to be scheduled, determine the estimated resource utilization rate after the Pod to be scheduled is scheduled to each node in the second set. Based on the estimated resource utilization rate and the maximum expected utilization rate, determine the first score of each node in the second set. Based on the newly created offline Pod data of each node in the second set, determine the second score of each node in the second set.

[0036] Specifically, by simulating scheduling the Pods to be scheduled across each node in the second set, the perceived scheduling status of memory and CPU can be determined based on resource usage, the estimated resource usage of the Pods to be scheduled, and the total allocable resources of the nodes. This allows for accurate quantification of resource utilization. Combining the estimated resource utilization with the maximum expected utilization, a first score for each node can be calculated using a quantitative scoring model (such as linear interpolation or piecewise functions). This score directly reflects the node's suitability in terms of resources; the higher the estimated resource utilization, the lower the score, reflecting a balance between resource utilization efficiency and stability. Simultaneously, a second score is calculated by independently analyzing the offline Pod distribution characteristics of each node (e.g., the number of offline tasks). This score measures the potential impact of scheduling decisions on existing offline loads. Combining these two methods provides an accurate measure of the suitability of the Pods to be scheduled across each node in the second set, based on the accurate resource usage and the potential impact on offline loads after simulating scheduling the Pods to be scheduled across each node in the second set.

[0037] S400: Combining the first score and the second score, determine the candidate nodes in the second set, and schedule the Pod to be scheduled to the candidate nodes.

[0038] Specifically, by combining the first and second scores, the two scores can be integrated through a weighted synthesis or hierarchical screening strategy to determine the optimal matching node for the Pod to be scheduled, thereby achieving scheduling.

[0039] While ensuring the quality of online services, the system maximizes the utilization of cluster resources and maintains the long-term operational stability of offline tasks, thereby achieving intelligent scheduling optimization in mixed workload scenarios.

[0040] In practical application, this embodiment collects resource usage data from each node and Pod to provide a basis for building a global resource view. In response to Pod scheduling requests, it determines the estimated resource usage of the Pod to be scheduled, the resource usage of each node, and the total allocatable resources of each node based on the resource usage data. Then, it filters a first set of nodes whose resource utilization is below a first utilization threshold. A second set of nodes in the first set whose newly created offline Pod data does not exceed the allowed threshold for the number of newly created offline Pods is then filtered, ensuring that candidate nodes simultaneously meet resource availability and business compatibility requirements. Finally, based on the resource usage of each node in the second set, the estimated resource usage of the Pod to be scheduled, and the total allocatable resources of each node, it determines the estimated resource utilization of the Pod after it is scheduled to each node in the second set. By estimating the utilization rate and the maximum expected utilization rate, the first score of each node in the second set is determined. Based on the newly created offline Pod data of each node in the second set, the second score of each node in the second set is determined. By simulating the scheduling of Pods to be scheduled to each node in the second set, and considering the accurate utilization of resources and the potential impact of offline load, a dynamic resource view is constructed to accurately quantify the risk of over-utilization and provide an accurate measure of the compatibility between the Pods to be scheduled and each node in the second set. Finally, the first and second scores are combined to select the optimal node and schedule the Pods to be scheduled to the selected node. This ensures resource utilization efficiency while maintaining overall stability. In other words, through a data-driven fine-grained scheduling strategy, the existing task requirements and the task characteristics of the Pods to be scheduled are effectively balanced, and the optimal configuration of cluster resources is achieved.

[0041] The following section details the process of collecting node data through a node agent.

[0042] It should be noted that the English terms involved in the embodiments of the present invention can be explained by referring to their corresponding steps or by their direct explanation, and will not be explained further thereafter.

[0043] The agent is deployed on each node of the Kubernetes cluster as a DaemonSet. It collects CPU and memory metrics of the node and the Pods on the node, and reports the collected data. At the same time, it prevents the node from failing due to excessive resource usage by evicting Pods that meet the criteria and tainting the node. The agent consists of three components: MetricsProvider, Reporter, and Resmanager.

[0044] (1) Indicator acquisition module: The indicator acquisition module directly collects the CPU and memory indicators of the node, and executes once every 5 seconds by default.

[0045] The metrics collection module obtains Pod information directly from the Node using kubeletClient, instead of querying the cluster's control plane component apiserver, which reduces the load on the cluster control plane. The metric collection module calls cadvisorManager, taking the obtained Pod information from the Node as input, and can periodically collect CPU and memory metrics for each Pod on the Node. The collection interval (default setting is 3 seconds) must be greater than or equal to the cadvisorManager's collection interval (default 1 second), otherwise the collected Pod CPU usage will be inaccurate and periodically show as 0.

[0046] The calculation of CPU usage is essentially the increase in CPU time per unit of time.

[0047] Sampling point record: time point : Read the value of cpuacct.usage (nanosecond); time point : Read the value of cpuacct.usage (nanosecond).

[0048] CPU time increment: Δa = (exist CPU time consumed internally.

[0049] Time window length: Δt= ;

[0050] CPU usage = Δa / Δt.

[0051] If the data collection interval needs to be less than the refresh interval of cadvisorManager, it will cause time points to be affected. Collected The value is still This results in Δa being 0, meaning CPU usage is 0.

[0052] (2) Indicator Reporter: Periodically calculates the resource information collected by the indicator collection module and injects it into the annotation of the node. The annotation information is then reported to the apiserver, the control plane component of the Kubernetes cluster.

[0053] The reporting annotations include:

[0054] CPU usage per node (CpuUsage);

[0055] CPU usage of all offline Pods on each node (offlineCpuUsage);

[0056] The CPU limit for all offline Pods on each node: offlineCpuLimit;

[0057] Memory usage per node (memUsage);

[0058] The memory usage of all offline Pods on each node (offlineMemUsage);

[0059] The memory usage of all stable offline Pods on each node is stableOfflineMemUsed;

[0060] The memory limit for all unstable offline Pods on each node: UnstableOfflineMemLimit.

[0061] The offline Pod is identified as either stable or unstable based on the runtime threshold DurationForStableMinutes (default 5 minutes). If the runtime reaches 5 minutes, the offline Pod is considered stable; otherwise, it is considered unstable.

[0062] (3) Node Manager: Consists of CPU / memory evicter and taint machine.

[0063] 1. Create a queue with a default length of 12. Each time the CPU and memory usage of the node is obtained from the metrics collection module, it is enqueued (if the queue is full, the oldest element is removed first). Store the data for the past minute. Based on the average value of the queue data / node capacity, smoothly reflect the current node's CPU usage, memory usage, CPU load and other metrics.

[0064] 2. Obtain all Pod resource metrics on the current node from the metric collection module;

[0065] 3. Filtering phase: Filter Pods under the namespaces included in NamespacesRejectEviction, filter Pods whose business priority is higher than the eviction priority threshold (EVICT_PRIORITY_THRESHOLD), and filter Pods that belong to DaemonSet or CriticalPod.

[0066] 4. Adjust the termination timeout based on the Pod's priority type:

[0067] Online Pods: Retain the default terminationGracePeriodSeconds (usually 30 seconds) to ensure a smooth business exit;

[0068] Offline Pod: Forced to shorten to 5 seconds to accelerate resource release.

[0069] For details regarding expulsion and smearing, please refer to the following examples.

[0070] As an optional embodiment of the present invention, the step of responding to the Pod scheduling request further includes:

[0071] Based on the resource usage data of each node and the total allocable resources of the node, the nodes whose ratio exceeds the maximum eviction threshold are identified. The Pods of the identified nodes are filtered according to the set eviction exclusion conditions. The Pods of the identified nodes are scored and sorted according to the priority correspondence and the resource usage. Based on the sorting results, the Pods of the identified nodes are evicted one by one until the ratio of the remaining resource usage data of the identified nodes to the total allocable resources of the nodes is less than the maximum eviction threshold, thus obtaining the evicted nodes.

[0072] Specifically, the following explanation uses CPUEvictor to illustrate the eviction process when the resource is CPU (when the resource is memory, it is MemEvictor memory pressure eviction tool, and the eviction strategies of the two are similar).

[0073] 1. Based on the obtained Node_CPU_Usage and Node_CPU_Capacity (resource usage data and total amount of resources that can be allocated to a node), determine whether the ratio of the two exceeds the maximum eviction threshold. If it does, these nodes need to be evicted.

[0074] 2. Based on the filtered nodes, filter out Pods belonging to specific namespaces (fields), those with a priority threshold, or those belonging to DaemonSets or CriticalPods. Specifically, exclude all Pods under a specified namespace, such as filtering out Pods in system namespaces like kube-system; filter Pods with a priority threshold, excluding Pods whose priority exceeds the set value, as high-priority Pods are generally more important and should not be evicted; filter Pods belonging to DaemonSets (used for log collection, monitoring data acquisition, network plugins, and storage daemons), excluding Pods created by the DaemonSet controller, as these Pods typically run on each node and provide critical services; filter Pods marked as CriticalPods, excluding those marked as critical Pods (core system components), as these Pods are essential for the normal operation of the cluster.

[0075] 3. Scoring: Pods with lower priority receive lower scores. If priorities are the same, Pods with higher CPU Usage receive lower scores. The formula for calculating the CPU eviction score is as follows:

[0076] Score1 = (Value corresponding to the Pod's service priority) * MaxCpuCores + (MaxCpuCores - Pod's CPU usage);

[0077] Formula for calculating memory eviction score:

[0078] Score2 = (the value corresponding to the Pod's business priority) * MaxMemSpace + (MaxMemSpace - Pod's memory usage).

[0079] Among them, MaxCpuCores and MaxMemSpace are both very large constants (100*1000=100000, 300*1024), and the priority (its value is greater than 1) is used as the main factor for scoring, while CPU / memory usage is used as a secondary factor.

[0080] 4. Sorting: Sort the filtered and scored Pods in ascending order of their scores. Then, evict Pods in order of their scores from lowest to highest, prioritizing Pods with lower priority and higher Pod_CPU_Usage. Continue evictting Pods in the sorted list until the ratio of the remaining resource usage data (i.e., the difference between Node_CPU_Usage and the Pod_CPU_Usage of the evicted Pod) to the total allocatable resources of the node (node.Allocatable.CPU) is lower than cpuEvictArgs_maxUtilization (the maximum eviction threshold).

[0081] When the resource is memory, the memory eviction service performs eviction operations until the node's memory capacity minus (the sum of the node's memory usage and the memory usage of the evicted Pods) is greater than EvictArgs_LeftMemSpace (the remaining memory usage of the evicted Pods).

[0082] And / or, compare the resource utilization rate and remaining resource usage of the node with the target eviction threshold corresponding to the over-limit judgment criteria, and perform a staining operation on the node that meets the over-limit judgment criteria.

[0083] Specifically, in order to avoid excessive pressure on nodes and hinder subsequent scheduling, it is necessary to limit the scheduling of nodes. For example, if the resource utilization of a certain node is still too high, then the node should be excluded from subsequent scheduling, which means performing a taint operation on the node.

[0084] It should be noted that real-time eviction and tainting isolation of nodes can be parallel operations. Considering that the evictioned node may reuse the evictioned Pod, the tainted isolation node can also be the node obtained after real-time eviction.

[0085] In practical applications, this embodiment ensures stability by real-time eviction of Pods on nodes and / or tainting and isolating nodes, thus resolving the contradiction between resource utilization and stability. Furthermore, the obtained nodes serve as the basis for subsequent scheduling, thereby improving the smoothness of Pod operation after offline scheduling and reducing the computational load of the scheduling process.

[0086] As an optional embodiment of the present invention, comparing the resource utilization rate and remaining resource usage of the node with the target eviction threshold corresponding to the over-limit judgment criteria, and performing a tainting operation on the node that meets the over-limit judgment criteria based on the comparison result includes:

[0087] If the resource utilization rate of a node exceeds the taint usage threshold, a taint operation is performed on the corresponding node.

[0088] Specifically, if the CPU utilization of a node is greater than taintArgs_usageThreshold, a taintification operation is performed on the corresponding node.

[0089] Alternatively, if the node load rate of the node is greater than the taint load threshold, a taint removal operation is performed on the corresponding node.

[0090] Specifically, if the node load rate of the node is greater than TaintArgs_LoadThreshold, for example, 300%, then tainting is performed.

[0091] Alternatively, if the remaining resource usage of a node is less than the remaining taint threshold, a taint removal operation is performed on the corresponding node.

[0092] Specifically, for memory, the condition for tainting is that the remaining memory space is less than TaintArgs_LeftMemSpace.

[0093] The specific English explanation can be found in the steps above, and will not be explained further here.

[0094] For each node, if any of the above conditions are met, the taint machine will taint the current node, preventing it from participating in scheduling, until none of the above conditions are met, at which point the taint will be removed.

[0095] In practical applications, the taint machine performs a taint operation every 5 seconds by default. When the taint machine taints the current node, the node is excluded from scheduling. This continues until the above conditions are no longer met, at which point the node's taint certification is canceled. This improves the smoothness of Pod operation after offline scheduling and reduces the computational load of the scheduling process. It should be noted that if the evictioned Pod is an online Pod and does not belong to a controller, then the eviction of the Pod is canceled. If the evictioned Pod is an online Pod and belongs to a controller, a distributed lock is added to the controller belonging to the online Pod by connecting to a Redis instance deployed for this offline scheduler. This ensures that only one Pod under the same controller is evicted at the same time, avoiding the impact on the availability of online services due to eviction.

[0096] It should be noted that when there are Pods to be scheduled to a node, the existing scheduling schemes in related technologies are difficult to complete the scheduling, or the use of resources is limited after scheduling. Therefore, this invention proposes a scheduling scheme using an offline scheduler.

[0097] Using the scheduler-framework's plugin architecture, new plugins can be added to the existing scheduling process of the Kubernetes cluster. The scheduling framework defines several extension points, and after the scheduler plugin is registered, it is invoked at one or more extension points. The offline scheduler allows custom CPU-aware scheduling plugins, memory-aware scheduling plugins, and offline-aware scheduling plugins to be invoked in stages such as Filter and Score.

[0098] The following describes the priority and parameter configuration of the Pod to be scheduled during the actual execution process.

[0099] Core business Pod: prod-svalue: 2000;

[0100] Online (business) Pod:

[0101] prod-p1value: 1900;

[0102] prod-p2value: 1800;

[0103] prod-p3value: 1700;

[0104] prod-p4value: 1600 (default priority is prod-p4);

[0105] P1-p4 represent priorities, respectively.

[0106] Online services need to define priorities; if not defined, the default priority is prod-p4. For offline service Pods, priorities must be defined.

[0107] Offline (business) Pod:

[0108] offline-p1value: 1500;

[0109] offline-p2value: 1400;

[0110] Online Pods are used to provide continuously running services that need to respond quickly to user requests (such as web services and API services). They have the following characteristics: low latency requirements, high availability and real-time response must be guaranteed; resource volatility, traffic has periodic peaks (such as high load during the day and low load at night); stability is the priority, service interruption will lead to business losses (such as user access failure), typical examples are Deployment and StatefulSet (stateful services such as databases).

[0111] Offline Pods are used to provide short-cycle or scheduled computing tasks that automatically exit upon completion (such as data processing or backup). They have the following characteristics: latency tolerance, tasks can be queued for execution, and can be restarted if they fail; resource intensive, requiring a large amount of CPU / memory but not real-time response (such as log analysis or model training); and temporary, releasing resources upon completion of the task.

[0112] The variable admission controller is deployed to the Kubernetes cluster as a deployment, receives user requests to create and schedule Pods, responds to them, modifies the Pod configuration, and then returns the changes to the cluster control plane apiserver.

[0113] Prerequisite: Limits (OfflineCpulimit, OfflineMemlimit) must be set when creating an offline Pod;

[0114] Environment variables include OfflineMaxCpulimit;

[0115] 1. If the Pod's service priority is offline, modify the Pod's scheduler field to the local offline scheduler;

[0116] 2. If the Pod's service priority is offline, setting the resource request value of all containers in the Pod to 0 can avoid occupying the node's schedulable resource quota in the default Kubernetes scheduler.

[0117] 3. If the Pod's service priority is offline and the Pod's CPU limit exceeds the preset maximum threshold OfflineMaxCpulimit, then it will be forcibly reduced to that threshold. The reason is to prevent offline Pods from excessively consuming resources, which could lead to delays in online services.

[0118] It should be noted that there is generally no need to set a maximum limit on memory. Due to the irreversibility of OOM (memory overrun directly kills the container, while CPU overrun only temporarily limits the flow), if a task suddenly exceeds the memory limit, frequent OOM will cause the task to crash, requiring repeated restarts, wasting scheduling resources and increasing latency.

[0119] 4. After making the modifications, send the Pod configuration to the apiserver.

[0120] The following examples detail scheduling schemes based on CPU-aware scheduling plugins, memory-aware scheduling plugins, and offline-aware scheduling plugins.

[0121] As an optional embodiment of the present invention, determining the estimated resource usage of the Pod to be scheduled based on the resource usage data in response to the Pod scheduling request includes:

[0122] Based on the resource usage data, obtain all containers of the Pod to be scheduled and the predicted amplification ratio of resource usage, wherein the Pod includes containers.

[0123] Specifically, as mentioned earlier, the agent's Reporter will report the resource usage of its node to the NodeAnnoatation. This allows the scheduler to obtain the resource usage of all nodes in the cluster and retrieve parameters, including overusePercent (the predicted amplification ratio of resource usage), from the scheduler's corresponding configMap.

[0124] Specifically, when the resource is CPU or memory, the calculation strategy for the estimated resource usage of the Pod to be scheduled is the same. The following describes the CPU usage of the Pod to be scheduled (offline) using CPU as the resource.

[0125] Iterate through each container to obtain the resource requirements of each container, and sum the resource requirements of each container to obtain the estimated resource usage of the Pod to be scheduled.

[0126] Specifically, by traversing each container, the resource requirement of each container, i.e., CpuLimit, can be obtained. The sum of the CpuLimits of each main container is the estimated amount of the currently scheduled Pod.

[0127] Estimate the memory usage of currently scheduled offline Pods, using the same logic as the CPU-aware scheduling plugin.

[0128] In practical applications, this embodiment starts with the container's CpuLimit and determines the estimated resource usage of the Pod to be scheduled based on the extreme cases of each (main) container. This is used for node screening before subsequent global scheduling decisions.

[0129] As an optional embodiment of the present invention, the estimated resource utilization rate of the node is the ratio of the sum of the resource usage, the offline resource usage under normal stable conditions, and the estimated resource usage to the total amount of resources that the node can allocate.

[0130] Specifically, when the resources are CPU and memory, their estimated resource utilization rates differ, but in general, they should both follow the ratio of estimated resource utilization to the sum of resource usage, offline resource usage under normal stable conditions, and estimated resource usage, to the total amount of resources that can be allocated to the node.

[0131] When the resource is CPU, the estimated resource utilization rate = {CPU usage + (CPU limit of offline Pods - CPU usage of offline Pods) * (1 - reusable ratio of reserved resources for offline tasks) + estimated CPU usage of Pods to be scheduled} / total number of CPUs that can be allocated to the node.

[0132] When the resource is memory, the estimated resource utilization rate = (memory usage - memory usage of offline Pods + memory usage of stable offline Pods + memory limit of unstable offline Pods + estimated memory usage of Pods to be scheduled) / total allocatable memory of the node.

[0133] In practical applications, this embodiment can accurately calculate the estimated resource usage based on the different actual characteristics of the resource composition (CPU and memory) of the node and the offline Pod to be scheduled. This calculation will be illustrated in detail in the next embodiment.

[0134] As an optional embodiment of the present invention, in response to a Pod scheduling request, determining the estimated resource usage of the Pod to be scheduled, the resource usage of each node, and the total allocatable resources of the node based on the resource usage data, and filtering a first set of nodes whose resource utilization rate is lower than a first utilization rate threshold based on the three factors, and filtering a second set of nodes in the first set whose newly created offline Pod data does not exceed the threshold for the number of newly created offline Pods, includes:

[0135] Based on the resource usage data, a first set of nodes that simultaneously meet the first condition and the second condition is selected. The first condition includes: the ratio of the resource usage of the node to the total allocatable resources of the node is less than the first utilization rate threshold. The second condition includes: the estimated resource utilization rate of the node is less than the first utilization rate threshold.

[0136] Specifically, resources include memory and CPU. Therefore, this step involves selecting CPU-aware scheduling plugins and memory-aware scheduling plugins, which will be explained below.

[0137] For CPU-aware scheduling plugins, the selection is based on a combination of the first and second criteria;

[0138] CPULoadAwareSchedulingArgs.MaxUtilization (maximum allowed utilization) is represented by A1;

[0139] First condition: CpuUsage / node.Allocatable.CPU < A1;

[0140] Second condition:

[0141] predictedNodeUtilizAtion1=

[0142] {CpuUsage+(offlineCpuLimit-offlineCpuUsage)*(1-OfflineLeftReusePercent)+predictedPodUsedCpu} / node.Allocatable.CPU<A1;

[0143] Among them, the scheduled offline Pod resource elasticity increment represents the portion excluding CpuUsage and predictedPodUsedCpu; CpuUsage represents the CPU usage (of a node), and the total allocatable resources of a node include node.Allocatable.CPU; offlineCpuUsage represents the CPU usage of an offline Pod; offlineCpuLimit represents the CPU limit of an offline Pod; OfflineLeftReusePercent represents the reusable proportion of reserved resources for offline tasks; and the estimated resource usage of a Pod to be scheduled includes predictedPodUsedCpu.

[0144] The following example illustrates this.

[0145] Assuming the current node usage is 16c = 12c of online usage + 4c of offline usage, and the total limit of the 4c ​​offline pods is 8c, in an offline business scenario, this means that these 4c offline pods have not yet reached their normal load state. In the future, these offline pods may increase from 4c to 8c. At the same time, in order to further improve resource utilization, we want to reserve 20% (OfflineLeftReusePercent) of the portion from 4c to 8c for scheduling.

[0146] On the surface, the total is 16c, and then it will be 16 + (8-4)*(1-20%) = 19.2c;

[0147] Now another offline pod has arrived (the limit is 9c, so predictedPodCpuUsage is 9c).

[0148] Then the result should be 16 + (8-4) * (1-20%) + 9 compared with the threshold.

[0149] For memory-aware scheduling plugins, the selection is based on a combination of the first and second conditions.

[0150] The first condition is the same as the CPU-aware scheduling plugin.

[0151] The maximum allowed utilization rate (MEMLoadAwareSchedulingArgs.MaxUtilization) is represented by A2.

[0152] Estimate the memory usage of currently scheduled offline Pods, using the same logic as the CPU-aware scheduling plugin.

[0153] Second condition:

[0154] predictedNodeUtilization2=

[0155] (memUsage-offlineMemUsage+UnstableOfflineMemLimit+stableOfflineMemUsed+predictedPodUsedMEm) / node.Allocatable.Mem<A2 node.

[0156] Among them, the scheduled offline Pod resource elastic increment represents the portion excluding memUsage and predictedPodUsedMEm; memUsage represents the memory usage of each node, and the total allocatable resources of a node include node.Allocatable.Mem, offlineMemUsage represents the memory usage (of all offline Pods on each node); stableOfflineMemUsed represents the memory usage of all stable offline Pods on each node.

[0157] UnstableOfflineMemLimit represents the memory limit for all unstable offline Pods on each node (identified by the runtime threshold DurationForStableMinutes). Specifically, memory usage is relatively stable compared to CPU usage. As mentioned earlier, the runtime threshold DurationForStableMinutes (default 5 minutes) is used to distinguish between stable and unstable offline Pods. If a Pod has been running stably for DurationForStableMinutes, it means that the memory usage of that offline Pod is relatively stable and will not increase significantly. For unstable offline Pods, Limit is still used as the resource estimate.

[0158] The estimated resource usage of the Pods to be scheduled includes predictedPodUsedMem.

[0159] It's important to note that memory usage is relatively stable compared to CPU usage. To further improve utilization, we use the runtime threshold DurationForStableMinutes (default 5 minutes) to identify stable offline Pods. If a Pod has been running stably for DurationForStableMinutes, its memory usage is relatively stable and unlikely to increase significantly. For unstable offline Pods, Limit is still used as the resource estimate.

[0160] The above method allows the Pods to be scheduled to run on each node, and combines the enhancement status of the offline Pods already scheduled on the node, resource usage, and the ratio of estimated resource usage to the total available resources on the node for comprehensive filtering. This results in a first set of nodes filtered based on CPU and memory, fully taking into account the dynamic growth of node resources, thereby accurately simulating the enhancement status of the Pods to be scheduled on the nodes.

[0161] Based on the resource usage data, a second set of nodes in the first set that simultaneously meet the third and fourth conditions is selected. The third condition includes: the number of newly created offline Pods of the nodes in the first set does not exceed the maximum allowed number of offline Pods. The fourth condition includes: the total number of newly created offline Pods of the nodes in the first set within a set historical time period does not exceed the maximum allowed number of offline Pods.

[0162] Specifically, this step involves node filtering for the offline sensing scheduling plugin, with the window size defaulting to 30 seconds.

[0163] OfflineMaxCount: Represents the maximum number of new offline Pods allowed on a node within the current window period, with a default value of 7.

[0164] OfflineCountLimit: Indicates the maximum number of offline Pods allowed on a node, with a default value of 50.

[0165] Scheduling is based on the number of newly created offline Pods on a node. There are two variables: count and total. The total can be calculated as: total is the number of newly created offline Pods on the current Node, while count represents the total number of newly created offline Pods on the Node within a window period (WindowSize).

[0166] Filtering: Based on each node in the first set, filter out nodes whose count is greater than OfflineMaxCount; filter out nodes whose total is greater than OfflineCountLimit, and obtain the second set of nodes.

[0167] In practical applications, this embodiment uses CPU-aware scheduling plugins, memory-aware scheduling plugins, and offline-aware scheduling plugins for scheduling to achieve predictive loading of categorized resources. This can accurately quantify over-usage risks and prevent offline Pods from being loaded after the node.

[0168] like Figure 3As shown, in an optional embodiment of the present invention, the first score includes a CPU-aware scheduling score and a memory-aware scheduling score. The step of determining the estimated resource utilization rate of the Pod to be scheduled after it is scheduled to each node in the second set, based on the resource usage of each node in the second set, the total allocatable resources of the node, and the estimated resource usage of the Pod to be scheduled, and then determining the first score of each node in the second set based on the estimated resource utilization rate and the maximum expected utilization rate, and determining the second score of each node in the second set based on the newly created offline Pod data of each node in the second set, includes:

[0169] Based on the estimated CPU utilization, maximum CPU utilization, and expected CPU utilization of each node in the second set, the CPU-aware scheduling score of each node in the first set is linearly determined, wherein the maximum CPU utilization corresponds to the highest score, and the higher the estimated CPU utilization, the lower the CPU-aware scheduling score.

[0170] The estimated resource utilization includes the estimated CPU utilization.

[0171] Specifically, the following describes the linear deterministic process, where u% represents the predicted node utilization after the current Pod is scheduled to the node.

[0172] CPU expected utilization includes target, which represents the expected utilization of the node (targetUtilization%).

[0173] max_threshold% represents the maximum utilization rate of a node (MaxUtilization%); max represents the maximum score (a fixed value of 100).

[0174] If u ≤ target;

[0175] score=(max-target)*(target-u) / target+target;

[0176] If target < u ≤ max_threshold;

[0177] score=target*(max_threshold-u) / (max-target);

[0178] If u > max_threshold;

[0179] score=0;

[0180] The image of the CPU-aware scheduling score score in the first score is a piecewise linear function. For details, please refer to Figure 3 As can be seen from the figure, when the predicted CPU utilization rate exceeds the expected utilization rate, its score drops precipitously.

[0181] The second score is determined according to the total number of newly created offline Pods of each node in the second set. Among them, the larger the total number of newly created offline Pods, the lower the second score.

[0182] Specifically, the second score is the offline-aware scheduling score. The total number of newly created offline Pods count is directly assigned to the second score, that is, score = count. The NormalizeScore normalization algorithm is used to map the score to the range of 0-100. The larger the total number of newly created offline Pods, the lower the second score.

[0183] When this embodiment is actually applied, through the calculation of the first score based on the second set and the piecewise linear scoring mechanism, nodes with lower resource utilization are preferentially selected to avoid excessive node load; the calculation of the second score, by counting the number of newly created offline Pods (count) on the node, dynamically suppresses the excessive accumulation of offline tasks and avoids their preemption of resources (such as CPU and memory) of online services, ensuring the stability of high-priority services.

[0184] As an optional embodiment of the present invention, the determining the first score of each node in the first set according to the predicted resource utilization rate and the maximum expected utilization rate further includes:

[0185] According to the second highest score and the predicted memory utilization rate of each node in the first set, the memory-aware scheduling score of each node in the first set is determined, where the maximum memory utilization rate corresponds to the second highest score, and the predicted resource utilization rate further includes the predicted memory utilization rate.

[0186] Specifically, if predictedNodeUtilization < maxUtilization, that is, when the predicted memory utilization rate is less than the maximum memory utilization rate, the difference between the second highest score and the predicted memory utilization rate is used as the memory-aware scheduling score, that is, score = 100 - predictedUtilization, which is the difference between the second highest score and the predicted memory utilization rate. Otherwise, the score is 0.

[0187] When this embodiment is actually applied, the memory-aware scheduling score can be determined based on the relationship between the predicted memory utilization rate and the maximum memory utilization rate, thereby achieving accurate quantification of the predicted memory utilization rate.

[0188] As an optional embodiment of the present invention, determining candidate nodes in the second set by combining the first score and the second score, and scheduling the Pod to be scheduled to the candidate node includes:

[0189] Based on the first score, the second score, and their respective weight percentages, the total score of each node in the second set is determined, and the nodes are sorted according to their total scores to determine the candidate nodes.

[0190] Specifically, according to the foregoing embodiments, the first score includes a CPU-aware scheduling score and a memory-aware scheduling score, and the second score includes an offline-aware scheduling score, with weights of a, b, and c, respectively; then, for each node in the second set, the total score is expressed as follows:

[0191] The total score is calculated as follows: CPU-aware scheduling score * a + Memory-aware scheduling score * b + Offline-aware scheduling score * c. Generally, Pods to be scheduled are arranged in descending order of their total scores. For example, a, b, and c are all set to 1.

[0192] In practical applications, this embodiment can evaluate the nodes to be scheduled based on multiple aspects, thereby improving the overall utilization of the cluster based on the awareness of the node's resources, without affecting the operation of the existing Pods on the node.

[0193] like Figure 4 As shown, the present invention also provides a cluster scheduling system 200, which applies the cluster scheduling method described in the above embodiments, including:

[0194] The metric acquisition module 210 is used to collect resource usage data of each node and Pod, wherein the node includes Pod, and the resource usage data is used to characterize the usage of memory and CPU.

[0195] The filtering module 220 is used to respond to a Pod scheduling request, determine the estimated resource usage of the Pod to be scheduled, the resource usage of each node, and the total amount of resources that can be allocated to the node based on the resource usage data, and filter a first set of nodes whose resource usage rate is lower than a first usage rate threshold based on the three factors, and filter a second set of nodes in the first set whose newly created offline Pod data does not exceed the threshold for the number of newly created offline Pods.

[0196] The estimation and determination module 230 is used to determine the estimated resource utilization rate of the Pod to be scheduled after it is scheduled to each of the nodes in the second set, based on the resource usage of each node in the second set and the total amount of resources that the node can allocate, as well as the estimated resource usage of the Pod to be scheduled; and to determine the first score of each node in the second set based on the estimated resource utilization rate and the maximum expected utilization rate; and to determine the second score of each node in the second set based on the newly created offline Pod data of each node in the second set.

[0197] The scheduling module 240 is used to combine the first score and the second score to determine the candidate nodes in the second set, and schedule the Pod to be scheduled to the candidate nodes.

[0198] The specific implementation methods can be referred to the corresponding implementation methods described above, and will not be described again here.

[0199] like Figure 5 As shown, an electronic device 300 provided in this embodiment of the invention includes a memory 310 and a processor 320; the memory 310 is used to store a computer program; the processor 320 is used to implement the cluster scheduling method described above when the computer program is executed.

[0200] Alternatively, an electronic device 300 includes a memory 310 and a processor 320 coupled to the memory 310; the memory 310 is configured to store a computer program; and the processor 320 is configured to perform the following operations when the computer program is executed:

[0201] Collect resource usage data for each node and Pod, wherein Pods are running on the nodes, and the resource usage data is used to characterize memory and CPU usage;

[0202] In response to a Pod scheduling request, the estimated resource usage of the Pod to be scheduled, the resource usage of each node, and the total amount of resources that can be allocated to the node are determined based on the resource usage data. Then, a first set of nodes whose resource usage rate is lower than a first usage rate threshold is selected based on the three factors. A second set of nodes in the first set whose newly created offline Pod data does not exceed the threshold for the number of newly created offline Pods is selected.

[0203] Based on the resource usage and total allocatable resources of each node in the second set, and the estimated resource usage of the Pod to be scheduled, the estimated resource utilization rate after the Pod to be scheduled is scheduled to each node in the second set is determined. Based on the estimated resource utilization rate and the maximum expected utilization rate, the first score of each node in the second set is determined. Based on the newly created offline Pod data of each node in the second set, the second score of each node in the second set is determined.

[0204] By combining the first score and the second score, candidate nodes are determined in the second set, and the Pod to be scheduled is scheduled to the candidate node.

[0205] This invention provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the cluster scheduling method described above.

[0206] Alternatively, a non-volatile computer-readable storage medium storing a computer program that, when executed by a processor, causes the processor to perform the following operations:

[0207] Collect resource usage data for each node and Pod, wherein Pods are running on the nodes, and the resource usage data is used to characterize memory and CPU usage;

[0208] In response to a Pod scheduling request, the estimated resource usage of the Pod to be scheduled, the resource usage of each node, and the total amount of resources that can be allocated to the node are determined based on the resource usage data. Then, a first set of nodes whose resource usage rate is lower than a first usage rate threshold is selected based on the three factors. A second set of nodes in the first set whose newly created offline Pod data does not exceed the threshold for the number of newly created offline Pods is selected.

[0209] Based on the resource usage and total allocatable resources of each node in the second set, and the estimated resource usage of the Pod to be scheduled, the estimated resource utilization rate after the Pod to be scheduled is scheduled to each node in the second set is determined. Based on the estimated resource utilization rate and the maximum expected utilization rate, the first score of each node in the second set is determined. Based on the newly created offline Pod data of each node in the second set, the second score of each node in the second set is determined.

[0210] By combining the first score and the second score, candidate nodes are determined in the second set, and the Pod to be scheduled is scheduled to the candidate node.

[0211] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided by this invention can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0212] The above description is merely a specific embodiment of the present invention, enabling those skilled in the art to understand or implement the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the present invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features of the invention herein.

[0213] While the present invention has been disclosed above, its scope of protection is not limited thereto. Those skilled in the art can make various changes and modifications without departing from the spirit and scope of the present invention, and all such changes and modifications will fall within the scope of protection of the present invention.

Claims

1. A cluster scheduling method, characterized in that, include: Collect resource usage data for each node and Pod, wherein Pods are running on the nodes, and the resource usage data is used to characterize memory and CPU usage; In response to a Pod scheduling request, the estimated resource usage of the Pod to be scheduled, the resource usage of each node, and the total amount of resources that can be allocated to the node are determined based on the resource usage data. Then, a first set of nodes whose resource usage rate is lower than a first usage rate threshold is selected based on the three factors. A second set of nodes in the first set whose newly created offline Pod data does not exceed the threshold for the number of newly created offline Pods is selected. Based on the resource usage and total allocatable resources of each node in the second set, and the estimated resource usage of the Pod to be scheduled, the estimated resource utilization rate after the Pod to be scheduled is scheduled to each node in the second set is determined. Based on the estimated resource utilization rate and the maximum expected utilization rate, the first score of each node in the second set is determined. Based on the newly created offline Pod data of each node in the second set, the second score of each node in the second set is determined. By combining the first score and the second score, candidate nodes are determined in the second set, and the Pod to be scheduled is scheduled to the candidate node; The response prior to the Pod scheduling request also includes: Based on the resource usage data of each node and the total allocable resources of the node, the nodes whose ratio exceeds the maximum eviction threshold are identified. The Pods of the identified nodes are filtered according to the set eviction exclusion conditions. The Pods of the identified nodes are scored and sorted according to the priority correspondence and the resource usage. Based on the sorting results, the Pods of the identified nodes are evicted one by one until the ratio of the remaining resource usage data of the identified nodes to the total allocable resources of the nodes is less than the maximum eviction threshold, thus obtaining the evicted nodes. And / or, compare the resource utilization rate and remaining resource usage of the node with the target eviction threshold corresponding to the over-limit judgment criteria, and perform a staining operation on the node that meets the over-limit judgment criteria.

2. The cluster scheduling method according to claim 1, characterized in that, The step of comparing the resource utilization rate and remaining resource usage of the node with the target eviction threshold corresponding to the over-limit judgment criteria, and performing a tainting operation on the node that meets the over-limit judgment criteria based on the comparison results, includes: If the resource utilization rate of the node is greater than the taint usage threshold, a taint operation is performed on the corresponding node. Alternatively, if the node load rate of the node is greater than the taint load threshold, a taint removal operation is performed on the corresponding node. Alternatively, if the remaining resource usage of a node is less than the remaining taint threshold, a taint removal operation is performed on the corresponding node.

3. The cluster scheduling method according to claim 1, characterized in that, In response to a Pod scheduling request, determining the estimated resource usage of the Pod to be scheduled based on the resource usage data includes: Based on the resource usage data, obtain all containers of the Pod to be scheduled, wherein the Pod includes containers; Iterate through each container to obtain the resource requirements of each container, and sum the resource requirements of each container to obtain the estimated resource usage of the Pod to be scheduled.

4. The cluster scheduling method according to claim 3, characterized in that, The estimated resource utilization rate of the node is the ratio of the total resource usage, the offline resource usage under normal and stable conditions, and the sum of the estimated resource usage to the total amount of resources that the node can allocate.

5. The cluster scheduling method according to any one of claims 1-4, characterized in that, In response to a Pod scheduling request, the process involves determining, based on the resource usage data, the estimated resource usage of the Pod to be scheduled, the resource usage of each node, and the total allocatable resources of each node. Then, based on these three factors, a first set of nodes with resource utilization rates below a first utilization threshold is selected. A second set of nodes in the first set whose newly created offline Pod data does not exceed a threshold for the number of newly created offline Pods is selected. Based on the resource usage data, a first set of nodes that simultaneously meet the first condition and the second condition is selected. The first condition includes: the ratio of the resource usage of the node to the total allocatable resources of the node is less than the first utilization rate threshold. The second condition includes: the estimated resource utilization rate of the node is less than the first utilization rate threshold. Based on the resource usage data, a second set of nodes in the first set that simultaneously meet the third and fourth conditions is selected. The third condition includes: the number of newly created offline Pods of the nodes in the first set does not exceed the maximum allowed number of offline Pods. The fourth condition includes: the total number of newly created offline Pods of the nodes in the first set within a set historical time period does not exceed the maximum allowed number of offline Pods.

6. The cluster scheduling method according to claim 1 or 2, characterized in that, The first score includes a CPU-aware scheduling score and a memory-aware scheduling score. The estimated resource utilization rate of the Pod to be scheduled after being scheduled to each node in the second set is determined based on the resource usage and total allocable resources of each node in the second set, and the estimated resource usage of the Pod to be scheduled. The first score of each node in the second set is determined based on the estimated resource utilization rate and the maximum expected utilization rate. The second score of each node in the second set is determined based on the newly created offline Pod data of each node in the second set, including: Based on the estimated CPU utilization, maximum CPU utilization, and expected CPU utilization of each node in the second set, the CPU-aware scheduling score of each node in the first set is linearly determined, wherein the maximum CPU utilization corresponds to the highest score, the higher the estimated CPU utilization, the lower the CPU-aware scheduling score, and the estimated resource utilization includes the estimated CPU utilization. The second score is determined based on the total number of newly created offline Pods for each node in the second set, wherein the larger the total number of newly created offline Pods, the lower the second score.

7. The cluster scheduling method according to claim 6, characterized in that, The step of determining the first score of each node in the first set based on the estimated resource utilization rate and the maximum expected utilization rate further includes: The memory-aware scheduling score of each node in the first set is determined based on the second highest score and the estimated memory utilization rate of each node in the first set, wherein the maximum memory utilization rate corresponds to the second highest score, and the estimated resource utilization rate also includes the estimated memory utilization rate.

8. The cluster scheduling method according to claim 1 or 2, characterized in that, The process of combining the first score and the second score to determine candidate nodes in the second set, and scheduling the Pod to be scheduled to the candidate nodes, includes: Based on the first score, the second score, and their respective weight percentages, the total score of each node in the second set is determined, and the nodes are sorted according to their total scores to determine the candidate nodes.

9. A cluster scheduling system, characterized in that, The cluster scheduling method described in any one of claims 1-8 includes: The metrics collection module is used to collect resource usage data for each node and Pod, wherein the nodes include Pods, and the resource usage data is used to characterize memory and CPU usage. The filtering module is used to respond to a Pod scheduling request, determine the estimated resource usage of the Pod to be scheduled, the resource usage of each node, and the total amount of resources that can be allocated to the node based on the resource usage data, and filter the first set of nodes whose resource usage rate is lower than a first usage rate threshold based on the three factors, and filter the second set of nodes in the first set whose newly created offline Pod data does not exceed the threshold for the number of newly created offline Pods. The estimation and determination module is used to determine the estimated resource utilization rate of the Pod to be scheduled after it is scheduled to each of the nodes in the second set, based on the resource usage of each node in the second set and the total amount of resources that the node can allocate, as well as the estimated resource usage of the Pod to be scheduled. Based on the estimated resource utilization rate and the maximum expected utilization rate, the module determines the first score of each node in the second set. Based on the newly created offline Pod data of each node in the second set, the module determines the second score of each node in the second set. The scheduling module is used to combine the first score and the second score to determine the candidate nodes in the second set, and schedule the Pod to be scheduled to the candidate nodes.

Images