A multi-tenant resource entropy-based cluster dynamic resource overselling method

Abstract

The application belongs to the technical field of container orchestration, and discloses a cluster dynamic resource overselling method based on multi-tenant resource entropy, which comprises the following steps: obtaining historical resource data, preprocessing the historical resource data, predicting the cluster resource utilization rate by using a time series analysis model, and calculating the resource entropy; calculating the workload stability degree by using the pre-obtained tenant utilization rate data, combining the preset rule and the resource entropy to calculate the overselling proportion of the tenant, calculating the schedulable resource amount, and performing resource scheduling; obtaining the performance index of the container group in real time during scheduling, calculating the default score of the tenant service level agreement, and iteratively adjusting the overselling proportion according to the default score to calculate the final schedulable resource amount, and performing resource scheduling by using the final schedulable resource amount. The overselling proportion of the tenant is calculated, and the virtual resource exceeding the total amount of physical resources is reasonably allocated, so that the resource utilization efficiency is significantly improved.

Description

Technical Field

[0001] This invention relates to the field of container orchestration technology, and in particular to a method for dynamic resource overselling in a cluster based on multi-tenant resource entropy. Background Technology

[0002] With the rapid development of cloud computing, Kubernetes has become a leading platform in container orchestration, widely used for managing distributed applications. Its scheduler (Kube-Scheduler) schedules Pods (container groups) based on the allocatable resources of nodes. However, traditional scheduling mechanisms require that a Pod's resource requests cannot exceed the node's allocatable resources. This limitation often leads to insufficient resource utilization in low-load scenarios, especially in multi-tenant environments where resource idleness is more pronounced. To improve resource utilization, resource overcommitment, by allocating virtual resources exceeding the total physical resources, has become an effective strategy. However, static overcommitment strategies are difficult to adapt to dynamic load changes, potentially leading to resource contention, performance degradation, or even abnormal Pod exits. Therefore, a dynamic and scalable overcommitment method is urgently needed, capable of precisely adjusting the overcommitment ratio based on the resource distribution characteristics and service quality requirements of multi-tenants, thereby improving resource utilization while ensuring the stability and service quality of critical tasks.

[0003] Existing technologies (such as the patent application document with application number CN202210332539.1) calculate the oversold coefficient using historical resource utilization and a simple exponential smoothing algorithm to determine the amount of resources that can be scheduled for a node. However, this method has a relatively simple algorithm, lacks multi-tenancy support and real-time feedback, and is difficult to adapt to dynamic load changes in complex multi-tenant environments.

[0004] Furthermore, some solutions statically increase allocable resources by adjusting Kubelet parameters (such as `--system-reserved`), but cannot dynamically adjust the oversubscription ratio based on real-time load. Hardware-supported technologies (such as Intel RDT) optimize resources through memory bandwidth or cache allocation, but they rely on specific hardware, are complex to configure, and are not widely integrated into the Kubernetes ecosystem. Existing dynamic scheduling strategies mostly focus on Pod priority optimization and lack oversubscription control mechanisms for overall cluster resource utilization, thus limiting resource efficiency and stability.

[0005] Therefore, how to provide a method for dynamic resource overselling in a cluster based on multi-tenant resource entropy is an urgent problem to be solved. Summary of the Invention

[0006] This invention provides a method for dynamic resource overselling in a cluster based on multi-tenant resource entropy, in order to solve the above-mentioned technical problems in the prior art.

[0007] To provide a basic understanding of some aspects of the disclosed embodiments, a brief summary is given below. This summary is not intended as a general commentary, nor is it intended to identify key / important components or to describe the scope of protection of these embodiments. Its sole purpose is to present some concepts in a simple form as a prelude to the detailed description that follows.

[0008] According to a first aspect of the present invention, a method for dynamic resource overselling in a cluster based on multi-tenant resource entropy is provided.

[0009] In one embodiment, a cluster dynamic resource overselling method based on multi-tenant resource entropy includes:

[0010] Acquire historical resource data and preprocess it. Based on the preprocessed historical resource data, use a time series analysis model to predict the cluster resource utilization rate and calculate the resource entropy based on the predicted cluster resource utilization rate.

[0011] The workload stability is calculated by pre-acquired tenant utilization data, and the oversold ratio of tenants is calculated by combining the workload stability with preset rules and resource entropy. The amount of schedulable resources is calculated based on the oversold ratio, and resource scheduling is performed based on the amount of schedulable resources.

[0012] The system acquires real-time performance metrics of container groups during scheduling, calculates the default score of tenant service level agreements based on these metrics, iteratively adjusts the oversold ratio based on the default score, calculates the final schedulable resource quantity based on the adjusted oversold ratio, and then schedules resources using the final schedulable resource quantity.

[0013] In one embodiment, historical resource data is acquired and preprocessed. Based on the preprocessed historical resource data, a time series analysis model is used to predict cluster resource utilization. Resource entropy is calculated based on the predicted cluster resource utilization, including:

[0014] Historical resource data is acquired, and outlier and missing values ​​are processed using linear interpolation to obtain cleaned historical resource data. The cleaned historical resource data is then standardized to obtain preprocessed historical resource data.

[0015] The autoregressive integral moving average model was pre-trained using pre-processed historical resource data to obtain a cluster resource utilization prediction model.

[0016] Based on the real-time acquired resource data, the cluster resource utilization rate is predicted using a cluster resource utilization rate prediction model. The predicted cluster resource utilization rate is then used to calculate the resource entropy.

[0017] In one embodiment, the autoregressive integral moving average model is pre-trained using preprocessed historical resource data to obtain a cluster resource utilization prediction model, including:

[0018] Based on the characteristics of the preprocessed historical resource data, the initial parameters of the autoregressive integral moving average model are determined.

[0019] The initial parameters are optimized using the parameter optimization method to obtain an optimized autoregressive integral moving average model.

[0020] The preprocessed historical resource data is divided into training and validation sets. An optimized autoregressive integral moving average model is trained using the training set to obtain a cluster resource utilization prediction model. The prediction performance of the cluster resource utilization prediction model is evaluated using an error function.

[0021] In one embodiment, the parameter optimization method includes: grid search, Akaike information criterion, or Bayesian information criterion; the error function includes: mean square error or mean absolute error.

[0022] In one embodiment, cluster resource utilization is predicted using a cluster resource utilization prediction model based on real-time acquired resource data, resulting in a cluster resource utilization prediction result. The resource entropy is then calculated using this prediction result, including:

[0023] Based on real-time acquired resource data and a preset prediction window, the cluster resource utilization rate is predicted using a cluster resource utilization prediction model, and a prediction confidence interval is generated.

[0024] The resource utilization ratio is calculated based on the cluster resource utilization prediction results. The predicted resource entropy is then calculated using the resource utilization ratio. The predicted resource entropy is then normalized to obtain the normalized predicted resource entropy.

[0025] Based on the preset resource type weights, the overall predicted resource entropy of the cluster is calculated using a weighted average method combined with the normalized predicted resource entropy.

[0026] In one embodiment, workload stability is calculated using pre-acquired tenant utilization data, and the tenant oversubscription ratio is calculated using the workload stability in combination with preset rules and resource entropy. The amount of schedulable resources is then calculated based on the oversubscription ratio, and resource scheduling based on the schedulable resources includes:

[0027] The workload stability is calculated using pre-acquired tenant utilization data, and overselling adjustment parameters are determined.

[0028] The overselling ratio of tenants is calculated based on workload stability and overselling adjustment parameters, combined with preset tenant service level agreement weights, preset container group priorities, and resource entropy.

[0029] The schedulable resource quantity for each node, each type of resource, and each tenant is calculated based on the oversold ratio, and resource scheduling is performed based on the schedulable resource quantity.

[0030] In one embodiment, the formula for calculating the tenant's overbooking ratio is:

[0031]

[0032] In the formula, OversellRatio t Indicates the oversold ratio; α represents the oversold adjustment factor; H cluster ω represents the overall predicted resource entropy of the cluster; t Indicates the tenant service level agreement weight; π t Indicates container group priority; λ represents workload stability factor; S t This indicates the stability of the workload; γ represents the maximum overselling ratio limit.

[0033] In one embodiment, the performance metrics of the container group are acquired in real time during scheduling. The performance metrics are used to calculate the default score of the tenant's service level agreement (SLA). The oversubscription ratio is iteratively adjusted based on the default score. The final schedulable resource quantity is calculated based on the adjusted oversubscription ratio. Resource scheduling is then performed using the final schedulable resource quantity.

[0034] Real-time acquisition of container group performance metrics during scheduling, and calculation of tenant service level agreement breach scores using performance metrics;

[0035] Default is determined by combining the default score with a preset threshold, and the overselling ratio is iteratively adjusted or the container group is rescheduled based on the default determination result.

[0036] The final schedulable resource quantity is calculated based on the adjusted oversold ratio, and resource scheduling is performed based on the final schedulable resource quantity.

[0037] In one embodiment, the formula for calculating the default score is:

[0038]

[0039] In the formula, SLAViolationScore t This represents the tenant's service level agreement (SLA) breach score; M represents the total number of performance metrics; m represents the m-th performance metric; Metric m,t SLAThreshold represents the actual value of the m-th performance metric for tenant t. m,t ω represents the tenant service level agreement threshold for the m-th performance metric of tenant t; m This represents the weight of the m-th performance metric.

[0040] In one embodiment, iterative adjustment of the overselling ratio or rescheduling of container groups based on the default judgment result includes: if the default score in the default judgment result exceeds a preset threshold, then the overselling ratio is reduced by a preset ratio; if the number of defaults in the default judgment result exceeds a preset number, then the relevant container group is marked as eviction, and the container group is rescheduled according to the marked container group.

[0041] According to a third aspect of the present invention, a computer device is provided.

[0042] In some embodiments, the computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the steps of the above-described cluster dynamic resource overselling method based on multi-tenant resource entropy.

[0043] According to a fourth aspect of the present invention, a computer-readable storage medium is provided.

[0044] In one embodiment, a computer program is stored on a computer-readable storage medium, and when the computer program is executed by a processor, it implements the steps of the above-described cluster dynamic resource overselling method based on multi-tenant resource entropy.

[0045] The technical solutions provided by the embodiments of the present invention may include the following beneficial effects:

[0046] 1. This invention predicts resource utilization using the ARIMA (Autoregressive Integral Moving Average) model, combined with predicted resource entropy quantification and dynamic overselling ratio calculation, significantly improving the resource utilization of multi-tenant Kubernetes clusters while ensuring the service quality of high-priority tenants. Furthermore, it requires no specific hardware, is highly versatile, adapts to dynamic load changes, and effectively reduces resource waste. The real-time SLA (Service Level Agreement) feedback mechanism dynamically adjusts the overselling ratio by monitoring performance indicators to prevent SLA breaches, ensuring the stability of critical tasks. It is suitable for large-scale container cluster management, improving resource efficiency and operational convenience.

[0047] 2. By calculating the oversold ratio of tenants, this invention can predict the dynamic changes in future resource utilization based on historical resource data and reasonably allocate virtual resources that exceed the total physical resources, thereby significantly improving resource utilization efficiency. In multi-tenant scenarios, high-priority tenants' Pods receive a more conservative oversold ratio to ensure the stability of critical business operations, while low-priority tenants improve resource utilization through a higher oversold ratio.

[0048] 3. This invention dynamically optimizes resource overselling strategies by monitoring resource utilization and tenant workload characteristics, ensuring that resource allocation matches actual needs. In addition, by utilizing the native scheduling mechanism of Kubernetes, combined with entropy calculation and tenant characteristic analysis, it requires no specific hardware support and has strong versatility and scalability. It can improve cluster resource utilization while ensuring service quality in a multi-tenant environment, and is suitable for large-scale, dynamically loaded container cluster management.

[0049] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit the invention. Attached Figure Description

[0050] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0051] Figure 1 This is a flowchart illustrating a cluster dynamic resource overselling method based on multi-tenant resource entropy, according to an exemplary embodiment.

[0052] Figure 2 This is a schematic diagram illustrating the execution steps of a cluster dynamic resource overselling method based on multi-tenant resource entropy, according to an exemplary embodiment.

[0053] Figure 3 This is a schematic diagram of the structure of a computer device according to an exemplary embodiment. Detailed Implementation

[0054] The following description and accompanying drawings fully illustrate specific embodiments described herein to enable those skilled in the art to practice them. Some embodiments may include or substitute parts and features of other embodiments. The scope of the embodiments herein encompasses the entire scope of the claims and all available equivalents thereof. Throughout this document, the terms “first,” “second,” etc., are used only to distinguish one element from another without requiring or implying any actual relationship or order between the elements. Indeed, a first element can also be referred to as a second element, and vice versa. Furthermore, the terms “comprising,” “including,” or any other variations thereof are intended to cover non-exclusive inclusion, such that a structure, apparatus, or device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a structure, apparatus, or device. Without further limitation, an element defined by the phrase “comprising one…” does not exclude the presence of other identical elements in the structure, apparatus, or device that includes said element. The various embodiments described herein are presented in a progressive manner, with each embodiment focusing on its differences from other embodiments; similar or identical parts between embodiments can be referred to interchangeably.

[0055] The terms "longitudinal," "lateral," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer" used in this document to indicate orientations or positional relationships are based on the orientations or positional relationships shown in the accompanying drawings. They are used solely for the convenience of describing the document and for simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on the invention. In the description herein, unless otherwise specified and limited, the terms "installed," "connected," and "linked" should be interpreted broadly. For example, they can refer to mechanical or electrical connections, or internal connections between two elements; they can be direct connections or indirect connections through an intermediate medium. Those skilled in the art can understand the specific meaning of the above terms according to the specific circumstances.

[0056] In this document, unless otherwise stated, the term "multiple" means two or more.

[0057] In this article, the character " / " indicates that the objects before and after it are in an "or" relationship. For example, A / B means: A or B.

[0058] In this article, the term "and / or" describes an association between objects, indicating that three relationships can exist. For example, A and / or B means: A or B, or A and B.

[0059] It should be understood that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order constraint on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the diagram may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0060] The modules in the apparatus or system of this application can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0061] Where there is no conflict, the embodiments and features in the embodiments of the present invention can be combined with each other.

[0062] Figures 1-2 An embodiment of a cluster dynamic resource overselling method based on multi-tenant resource entropy according to the present invention is shown.

[0063] In this optional embodiment, the cluster dynamic resource overselling method based on multi-tenant resource entropy includes:

[0064] Step S101: Obtain historical resource data and preprocess the historical resource data. Based on the preprocessed historical resource data, use a time series analysis model to predict the cluster resource utilization rate and calculate the resource entropy based on the predicted cluster resource utilization rate.

[0065] Step S102: Calculate the workload stability using the pre-acquired tenant utilization data, and calculate the tenant oversubscription ratio using the workload stability combined with preset rules and resource entropy. Calculate the schedulable resource quantity based on the oversubscription ratio, and perform resource scheduling based on the schedulable resource quantity.

[0066] Step S103: Obtain the performance metrics of the container group in real time during scheduling, calculate the default score of the tenant's service level agreement using the performance metrics, iteratively adjust the oversold ratio based on the default score, calculate the final schedulable resource quantity based on the adjusted oversold ratio, and perform resource scheduling based on the final schedulable resource quantity.

[0067] In this optional embodiment, historical resource data is acquired and preprocessed. Based on the preprocessed historical resource data, a time series analysis model is used to predict the cluster resource utilization rate. The resource entropy is calculated based on the predicted cluster resource utilization rate, including:

[0068] Historical resource data is acquired, and outlier and missing values ​​are processed using linear interpolation to obtain cleaned historical resource data. The cleaned historical resource data is then standardized to obtain preprocessed historical resource data.

[0069] The autoregressive integral moving average model was pre-trained using pre-processed historical resource data to obtain a cluster resource utilization prediction model.

[0070] Based on the real-time acquired resource data, the cluster resource utilization rate is predicted using a cluster resource utilization rate prediction model. The predicted cluster resource utilization rate is then used to calculate the resource entropy.

[0071] In this optional embodiment, the autoregressive integral moving average model is pre-trained using preprocessed historical resource data to obtain a cluster resource utilization prediction model, including:

[0072] Based on the characteristics of the preprocessed historical resource data, the initial parameters of the autoregressive integral moving average model are determined.

[0073] The initial parameters are optimized using the parameter optimization method to obtain an optimized autoregressive integral moving average model.

[0074] The preprocessed historical resource data is divided into training and validation sets. An optimized autoregressive integral moving average model is trained using the training set to obtain a cluster resource utilization prediction model. The prediction performance of the cluster resource utilization prediction model is evaluated using an error function.

[0075] In this optional embodiment, the parameter optimization method includes: grid search, Akaike information criterion, or Bayesian information criterion; the error function includes: mean square error or mean absolute error.

[0076] In this optional embodiment, cluster resource utilization is predicted using a cluster resource utilization prediction model based on real-time acquired resource data, and the predicted cluster resource utilization result is obtained. The calculation of resource entropy based on the predicted cluster resource utilization result includes:

[0077] Based on real-time acquired resource data and a preset prediction window, the cluster resource utilization rate is predicted using a cluster resource utilization prediction model, and a prediction confidence interval is generated.

[0078] The resource utilization ratio is calculated based on the cluster resource utilization prediction results. The predicted resource entropy is then calculated using the resource utilization ratio. The predicted resource entropy is then normalized to obtain the normalized predicted resource entropy.

[0079] Based on the preset resource type weights, the overall predicted resource entropy of the cluster is calculated using a weighted average method combined with the normalized predicted resource entropy.

[0080] In this optional embodiment, the workload stability is calculated using pre-acquired tenant utilization data, and the tenant's oversubscription ratio is calculated using the workload stability in combination with preset rules and resource entropy. The schedulable resource quantity is then calculated based on the oversubscription ratio, and resource scheduling based on the schedulable resource quantity includes:

[0081] The workload stability is calculated using pre-acquired tenant utilization data, and overselling adjustment parameters are determined.

[0082] The overselling ratio of tenants is calculated based on workload stability and overselling adjustment parameters, combined with preset tenant service level agreement weights, preset container group priorities, and resource entropy.

[0083] The schedulable resource quantity for each node, each type of resource, and each tenant is calculated based on the oversold ratio, and resource scheduling is performed based on the schedulable resource quantity.

[0084] In this optional embodiment, the formula for calculating the tenant's overbooking ratio is:

[0085]

[0086] In the formula, OversellRatio t Indicates the oversold ratio; α represents the oversold adjustment factor; H cluster ω represents the overall predicted resource entropy of the cluster; t Indicates the tenant service level agreement weight; π t Indicates container group priority; λ represents workload stability factor; S t This indicates the stability of the workload; γ represents the maximum overselling ratio limit.

[0087] In this optional embodiment, the performance metrics of the container group are acquired in real time during scheduling. The performance metrics are used to calculate the default score of the tenant's service level agreement (SLA). The oversubscription ratio is iteratively adjusted based on the default score. The final schedulable resource quantity is calculated based on the adjusted oversubscription ratio. Resource scheduling is then performed using the final schedulable resource quantity.

[0088] Real-time acquisition of container group performance metrics during scheduling, and calculation of tenant service level agreement breach scores using performance metrics;

[0089] Default is determined by combining the default score with a preset threshold, and the overselling ratio is iteratively adjusted or the container group is rescheduled based on the default determination result.

[0090] The final schedulable resource quantity is calculated based on the adjusted oversold ratio, and resource scheduling is performed based on the final schedulable resource quantity.

[0091] In this optional embodiment, the formula for calculating the default score is:

[0092]

[0093] In the formula, SLAViolationScore t This represents the tenant's service level agreement (SLA) breach score; M represents the total number of performance metrics; m represents the m-th performance metric; Metric m,t SLAThreshold represents the actual value of the m-th performance metric for tenant t. m,t ω represents the tenant service level agreement threshold for the m-th performance metric of tenant t; m This represents the weight of the m-th performance metric.

[0094] In this optional embodiment, iterative adjustment of the overselling ratio or rescheduling of container groups based on the default judgment result includes: if the default score in the default judgment result exceeds a preset threshold, the overselling ratio is reduced by a preset ratio; if the number of defaults in the default judgment result exceeds a preset number, the relevant container groups are marked as evictions, and container groups are rescheduled according to the marked container groups.

[0095] It should be noted that the goal of resource utilization prediction based on the ARIMA (Autoregressive Integral Moving Average) model is to use the ARIMA model to predict the resource utilization (CPU, memory, storage, network I / O, GPU) of each node in the Kubernetes cluster, and to calculate the predicted resource entropy based on the predicted values.

[0096] ARIMA is a classic time series analysis model suitable for capturing trends, seasonality, and randomness in resource utilization. It models using three components: autoregression (AR), differencing (I), and moving average (MA), enabling it to predict future resource utilization and provide confidence intervals to assess the uncertainty of the forecast.

[0097] The collection of historical resource utilization data (i.e., historical resource data) includes collecting the historical utilization u of each resource r∈{CPU, memory, storage, network I / O, GPU} on each node i in the cluster through Prometheus (a monitoring tool in the Kubernetes ecosystem). r,iThe collected data is stored in a time-series format. (The utilization rate is the data collected by Prometheus monitoring; for example, if the CPU utilization rate on node 1 is 80%, then u...) cpu,1 =0.8).

[0098] Data preprocessing includes cleaning and standardizing the collected data. Outlier data is replaced using linear interpolation, and missing data is filled in to ensure the input quality of the ARIMA model.

[0099] ARIMA model training includes model selection, parameter optimization, model training, and model saving. Model selection involves determining the (p, d, q) parameters of the ARIMA model based on the characteristics of resource utilization data (whether there is a trend or seasonality). Parameter optimization involves using grid search to traverse possible combinations of model parameters or using AIC (Akaike Information Criterion) / BIC (Bayesian Information Criterion) to evaluate model goodness and select the optimal parameters. Model training involves dividing historical data into a training set (80%) and a validation set (20%), training the ARIMA model, and evaluating its predictive performance using mean squared error (MSE) or mean absolute error (MAE). Model saving involves serializing the trained model into a file for subsequent predictions.

[0100] Resource utilization forecasting includes forecasting window, forecast execution, and result storage. The forecasting window is selected based on business needs, such as (1 hour = 60 data points, or 1 day = 1440 data points). Forecast execution involves using a trained ARIMA model to predict the resource utilization of each node within the future time window. It generates prediction confidence intervals (e.g., 95% confidence level); result storage includes storing the prediction results in a time series format, including nodes, resource types, predicted values, and confidence intervals.

[0101] It should be further explained that resource entropy calculation, which is based on the predicted resource utilization rate, calculates the predicted resource entropy to provide a basis for the overselling strategy. First, for each resource type r∈{CPU, memory, storage, network I / O, GPU}, the resource utilization ratio is calculated based on the predicted utilization rate on each node:

[0102]

[0103] In the formula, P r,i Indicates the resource utilization ratio; i represents the i-th node; r represents the r-th resource; j represents the j-th node; N represents the total number of nodes in the cluster; u r,i Represents the predicted resource utilization rate of resource r on node i; u r,j This represents the predicted resource utilization rate of resource r on node j.

[0104] The formula for calculating predicted resource entropy based on resource utilization ratio is as follows:

[0105]

[0106] In the formula, H r This indicates the predicted resource entropy.

[0107] To facilitate comparison of entropy values ​​for different resource types and cluster sizes, the one-dimensional entropy value is normalized to the [0,1] interval:

[0108]

[0109] In the formula, H represents the normalized predicted resource entropy; r The maximum value is log2N (when resources are evenly distributed), so divide by log2N to normalize the entropy value to [0,1]. 0 indicates that resources are completely concentrated on one node, while 1 indicates that resources are evenly distributed across all nodes. Normalized values ​​facilitate comparisons across resource types and are suitable for clusters of different sizes.

[0110] Define resource type weight ω r , representing the weight of resource type r, is used to reflect the relative contribution of different resource types (CPU, memory, storage, network I / O, GPU) to the overall predicted resource entropy. The sum of the weights of each resource type is 1, i.e., ∑ω r =1, for example: ω cpu =0.3; ω mem =0.2; ω disk =0.2; ω network =0.2; ω gpu =0.1.

[0111] Finally, by combining the entropy values ​​of various resources, the formula for calculating the overall predicted resource entropy (weighted average) of the cluster is as follows:

[0112]

[0113] In the formula, H cluster This represents the overall predicted resource entropy of the cluster. The overall predicted resource entropy quantifies the uneven distribution of resources; a higher entropy value indicates a greater potential for overselling in the future.

[0114] It should be further explained that the tenant-specific dynamic oversold ratio target is calculated dynamically for each tenant based on predicted resource entropy, tenant SLA weight, Pod priority, and workload stability; whereby an SLA weight ω is set for tenant t. t ω tThe preferred range is [0,1], with higher priority tenants having higher weights, such as critical business tenants ω. t =0.8; Set the priority factor π for tenant t. t , π t The preferred range is [0,1]. Based on the Kubernetes PriorityClass mechanism, the π of high-priority Pods... t Approaching 1, for example, the critical business tenant π t =0.9.

[0115] The formula for calculating workload stability (i.e., workload stability) based on the reciprocal of the standard deviation of CPU utilization for tenant t is as follows:

[0116]

[0117] In the formula, σ cpu,t σ represents the standard deviation of CPU utilization for tenant t. cpu,t This reflects the volatility of the tenant's workload; the smaller the standard deviation (the lower the volatility), the better. t S represents the stability of the workload. t A higher value indicates a more stable workload, suitable for a higher oversold ratio, as its resource requirements are more predictable.

[0118] The overselling adjustment parameters are defined as follows: α, λ, and γ. α is the overselling adjustment factor, which controls the influence of predicted resource entropy on the overselling ratio. The more uniform the resource distribution, the higher the allowed overselling ratio. The preferred range is [4.0, 6.0], and this value can be adjusted according to actual business needs. λ is the workload stability factor, which adjusts the overselling ratio according to workload stability. Stable loads allow for higher overselling, with a preferred range of [0.1, 0.2]. This value can be adjusted according to actual business needs. γ is the maximum overselling ratio limit, which avoids excessive overselling leading to resource competition. The preferred range is [1.0, 3.0]. This value can be adjusted according to actual business needs.

[0119] Calculating the overselling ratio involves comprehensively considering the overall predicted resource entropy of the cluster (H). cluster Tenant SLA weight (ω) t ), priority (π) t ) and workload stability (S t This ensures that high-priority, stable-load tenants receive a lower oversold ratio, and Pods receive more computing resources to ensure business stability; low-priority, unstable-load tenants receive a higher oversold ratio, and Pods receive fewer computing resources to improve cluster resource utilization.

[0120] It should be noted that the schedulable resource calculation is based on the oversubscription ratio, calculating the schedulable resource quantity for each node, each resource type, and each tenant; the formula for calculating the schedulable resource quantity for node i, resource r, and tenant t is as follows:

[0121] SchedulableResource r,i,t =InitialResource r,i OversellRatio t ;

[0122] In the formula, ScheduledResource r,i,t InitialResource represents the amount of schedulable resources that tenant t has for resource r on node i. r,i OversellRatio represents the amount of physical resources r on node i. t This represents the overselling ratio of tenant t.

[0123] For example, if node i has 16 physical CPU cores, the oversell ratio of tenant t is... t If the value is 1.5, then the schedulable CPU quantity is 16 * 1.5 = 24. This means that tenant t can request a maximum of 24 CPU cores on node i, instead of the actual 16 cores. The requested resource quantity exceeds the physical resource, which can increase resource utilization, but the risk needs to be controlled through the feedback mechanism in subsequent steps.

[0124] It should be added that real-time SLA feedback and adjustment involves dynamically adjusting the oversubscription ratio or rescheduling Pods by monitoring Pod performance metrics (such as latency and error rate) in real time, in order to protect the tenant's quality of service (SLA) and avoid resource contention or performance degradation caused by excessive oversubscription.

[0125] First, the formula for calculating the SLA default score is:

[0126]

[0127] In the formula, SLAViolationScore t This represents the tenant's service level agreement (SLA) breach score; M represents the total number of performance metrics; m represents the m-th performance metric; Metric m,t This represents the actual value of the m-th performance metric for tenant t (collected via Prometheus, e.g., latency of 100ms and error rate of 2%); SLAThreshold m,tω represents the tenant service level agreement threshold for the m-th performance metric of tenant t (defined by the tenant SLA, e.g., maximum allowed latency of 80ms and maximum error rate of 1%); m This represents the weight of the m-th performance metric, reflecting its importance (e.g., latency has a weight of 0.6, and error rate has a weight of 0.4).

[0128] Secondly, if SLAViolationScore t >θ, then:

[0129] OversellRatio t1 ←OversellRatio t ·(1-η·SLAViolationScore t );

[0130] Where θ represents the threshold for the default score, which triggers an adjustment when it is exceeded. The preferred range is [0.05, 0.2], and this value can be adjusted according to actual business conditions. η represents the adjustment factor, which controls the reduction of the oversell ratio by the default score. The preferred range is [0.2, 0.5], and this value can be adjusted according to actual business conditions. OversellRatio t1 This represents the oversold ratio after tenant t's adjustment.

[0131] If the default score exceeds the threshold, it indicates that the Pod performance has significantly deviated from the SLA, and the overselling ratio needs to be reduced to decrease resource contention. The adjustment formula is 1 - η·SLAViolationScore. t The oversell ratio is reduced proportionally; the higher the default score, the greater the reduction. For example, if η is 0.3, the current OversellRatio... t =1.5, Slavolation Score t =0.2, then OversellRatio t1 ←1.5·(1-0.3·0.2)=1.41; that is, the overselling ratio is reduced from 1.5 to 1.41, reducing the aggressiveness of resource allocation.

[0132] Pod rescheduling is triggered via kube-scheduler's EvictAPI; if the SLA default score exceeds the threshold (SLAViolationScore)... t >θ) indicates that overselling has led to resource contention, causing Pod performance to deviate significantly from the SLA. In this case, these Pods are marked for eviction via kube-scheduler's EvictAPI, and kube-scheduler will reallocate the Pods to nodes with more resources.

[0133] Example:

[0134] The scenario describes an enterprise running a Kubernetes cluster with three nodes (Node1, Node2, and Node3) to host multi-tenant web applications and batch processing tasks. Peak CPU and memory utilization is observed daily between 10:00-12:00 and 14:00-16:00, due to concentrated web application traffic and batch processing task execution. To optimize resource utilization and avoid SLA defaults, it is necessary to predict peak resource utilization, calculate predicted resource entropy, and dynamically adjust the oversubscription ratio.

[0135] The cluster configuration consists of three nodes: Node1 with a 16-core CPU and 32GB of memory; Node2 with an 8-core CPU and 16GB of memory; and Node3 with an 8-core CPU and 16GB of memory. The resource types are CPU and memory. The time granularity is minute-level (collected once per minute). The prediction window is for the next hour (60 data points). The data source is the Prometheus monitoring system. The tenants are tenant A (high priority, SLA requires latency <100ms) and tenant B (low priority, batch processing task).

[0136] The implementation steps include data collection and preprocessing, ARIMA model training, resource utilization prediction, predicted resource entropy calculation, tenant-specific dynamic overselling ratio, schedulable resource calculation, real-time SLA feedback and adjustment, recalculation of schedulable resources and Pod rescheduling.

[0137] Data collection and preprocessing involves using Prometheus to collect CPU and memory utilization data from the past 7 days (10080 data points). The query statement is as follows:

[0138] rate(node_cpu_seconds_total{mode="user"}[5m])#CPU utilization

[0139] (node_memory_MemTotal_bytes-node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes#Memory usage.

[0140] The data is then stored in CSV format, with each column representing a node and resource type. The data is then preprocessed, with outliers replaced by linear interpolation results, and missing data filled in.

[0141] Assume the processed data are as shown in Tables 1.1 and 1.2.

[0142] Table 1.1 Data after assumed processing

[0143] time <![CDATA[Node1 cpu ]]> <![CDATA[Node2 cpu ]]> <![CDATA[Node3 cpu ]]> 09:00:00 0.60 0.40 0.30 09:01:00 0.62 0.42 0.32

[0144] Table 1.2 Data after assumed processing

[0145] time <![CDATA[Node1 memory ]]> <![CDATA[Node2 memory ]]> <![CDATA[Node3 memory ]]> 09:00:00 0.70 0.50 0.45 09:01:00 0.72 0.52 0.47

[0146] ARIMA model training includes stability testing, parameter estimation, parameter optimization, model training, and performance evaluation. Stability testing involves performing an ADF test on the CPU utilization data of Node1, with a p-value of 0.08 > 0.05, requiring first-order differencing (d = 1). Parameter estimation is based on the ACF plot showing lag 2 significance (p = 2) and the PACF plot showing lag 1 significance (q = 1), with initial parameters of (p = 2, d = 1, q = 1). Parameter optimization involves a grid search of p, q ∈ [0, 3], d ∈ [0, 2], using AIC as the standard to determine the optimal parameters as (2, 1, 1). Model training uses the first 80% of the data (8064 data points) for training and the validation set uses the last 20% (2016 data points). Performance evaluation shows a validation set MSE of 0.015 and MAE of 0.10, indicating high prediction accuracy.

[0147] Resource utilization prediction includes the prediction window, prediction execution, and prediction results. The prediction window is for predicting the next hour (09:00-10:00, 60 data points) from 09:00. Prediction execution involves loading the ARIMA model to predict the CPU and memory utilization of each node and generating 95% confidence intervals. An example of the prediction results, normalized values: Node1. CPU The CPU usage is 0.65 ± 0.05, meaning the CPU usage for node 1 is 0.65 ± 0.05; for node 2... CPU The CPU usage is 0.45 ± 0.04, meaning the CPU usage of node 2 is 0.45 ± 0.04; Node 3 CPU The CPU usage is 0.35 ± 0.04, meaning the CPU usage of node 3 is 0.35 ± 0.04; Node 1 Memory The memory size is 0.75 ± 0.06, meaning the memory size of node 1 is 0.75 ± 0.06; Node 2... Memory The value is 0.55 ± 0.05, meaning the memory of node 2 is 0.55 ± 0.05; Node 3 Memory The value is 0.50 ± 0.05, meaning the memory of node 3 is 0.50 ± 0.05.

[0148] The calculation of predicted resource entropy includes the calculation of predicted resource utilization ratio, predicted resource entropy, normalized entropy value, and overall predicted resource entropy of the cluster. The formula for calculating the predicted resource utilization ratio is as follows:

[0149]

[0150] Substitute the resource utilization rate forecast results into the above formula:

[0151]

[0152] The specific formula for calculating the predicted resource entropy is as follows:

[0153]

[0154] The specific formula for the normalized entropy value is:

[0155]

[0156] The specific formula for predicting the overall resource entropy of the cluster is as follows: assuming resource weight ω cpu =0.6, ω memory Substitute 0.4 into the formula below:

[0157]

[0158] Substituting the data, we get: H cluster =0.6×0.955+0.4×0.982=0.9658.

[0159] Calculating the tenant-specific dynamic oversold ratio involves assuming known parameters and calculating the oversold ratio; among which, the following known parameters are assumed: Tenant A (high priority), i.e., SLA weight ω. t =0.8, priority factor π t =0.9, workload stability σ cpu,t =0.1, S t =10; Tenant B (low priority), i.e., SLA weight ω t =0.2, priority factor π t =0.1, workload stability σ cpu,t =0.5, S t =2; Overselling adjustment parameters α=5, λ=0.1, γ=2.0.

[0160] The oversold ratio calculation includes the oversold ratio of tenant A and the oversold ratio of tenant B.

[0161] Tenant A:

[0162] OversellRatio A =min(5×0.9658(1 / (1+0.8+0.9+0.1×10)),2.0)≈min(1.305,2.0)=1.305.

[0163] Tenant B:

[0164] OversellRatio B =min(5×0.9658(1 / (1+0.2+0.1+0.1×2)),2.0)≈min(3.129,2.0)=2.0.

[0165] The schedulable resource calculation involves calculating the schedulable resource amount for each tenant on each node based on the oversold ratio.

[0166] Tenant A in Node1: CPU 16×1.305=20.88 cores, memory 32×1.305=41.76GB; Tenant B: CPU 16×2=32 cores, memory 32×2=64GB.

[0167] Tenant A in Node2: CPU has 8 × 1.305 = 10.44 cores, memory has 16 × 1.305 = 20.88 GB; Tenant B: CPU has 8 × 2 = 16 cores, memory has 16 × 2 = 32 GB.

[0168] Tenant A in Node3: CPU has 8 × 1.305 = 10.44 cores, and memory has 16 × 1.305 = 20.88 GB; Tenant B: CPU has 8 × 2 = 16 cores, and memory has 16 × 2 = 32 GB.

[0169] When scheduling tenant Pods, the scheduler prioritizes allocating Pods to higher-priority tenants based on the amount of schedulable resources and tenant priority, and allocates the remaining resources proportionally to lower-priority tenants. For example, if a Pod of tenant A requests 2 CPU cores, the scheduler checks whether the remaining schedulable CPU cores of tenant A on Node1 are ≥2.

[0170] Real-time SLA feedback and adjustment: First, Prometheus is used to monitor the latency of tenant A's web application in real time. Assuming that at 10:00 AM, tenant A's latency rises to 120ms (SLA threshold < 100ms), an SLA breach score is calculated. The input data is as follows:

[0171]

[0172] Assuming weight ω latency =1 (considering only delays), then tenant A's SLA default score is:

[0173] SLAViolationScore A =1×max(0,0.2)=0.2.

[0174] Adjusting the oversold ratio, assuming a threshold θ = 0.05 and an adjustment factor η = 0.3, then:

[0175] SLAViolationScoreA =0.2>0.05, adjust OversellRatio A ←1.305×(1-0.3×0.2)≈1.227.

[0176] Therefore, Tenant A's oversold ratio was adjusted from 1.305 to 1.227, reducing the aggressiveness of resource allocation to ensure service quality.

[0177] Recalculate the schedulable resources (taking Node1 as an example): CPU is 16 × 1.227 = 19.632 cores, and memory is 32 × 1.227 = 39.264 GB.

[0178] If the default continues, the kube-scheduler's EvictAPI will be triggered to mark some Pods as evictions and reschedule them to nodes with more resources.

[0179] In summary, this invention significantly improves the resource utilization of multi-tenant Kubernetes clusters by predicting resource utilization using an ARIMA model based on historical resource data, combined with predicted resource entropy quantification and dynamic overselling ratio calculation, while ensuring the service quality of high-priority tenants.

[0180] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 3 As shown, the computer device includes a processor, memory, and a network interface connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database stores static and dynamic information data. The network interface communicates with external terminals via a network connection. When the computer program is executed by the processor, it implements the steps in the above-described embodiment of the cluster dynamic resource overselling method based on multi-tenant resource entropy.

[0181] Those skilled in the art will understand that Figure 3 The structure shown is merely a block diagram of a portion of the structure related to the present invention and does not constitute a limitation on the computer device to which the present invention is applied. A specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0182] In addition, the present invention also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described embodiment of the cluster dynamic resource overselling method based on multi-tenant resource entropy.

[0183] In addition, the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps in the above-described embodiment of the cluster dynamic resource overselling method based on multi-tenant resource entropy.

[0184] Those skilled in the art will understand that implementing all or part of the processes in the above embodiments of the cluster dynamic resource overselling method based on multi-tenant resource entropy can be accomplished by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above-described cluster dynamic resource overselling method based on multi-tenant resource entropy. Any references to memory, storage, databases, or other media used in the embodiments provided by this invention can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, or optical storage, etc. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), etc.

[0185] This invention is not limited to the structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this invention is limited only by the appended claims.

Claims

1. A method for dynamic resource overselling in a cluster based on multi-tenant resource entropy, characterized in that, include: Acquire historical resource data and preprocess it. Based on the preprocessed historical resource data, use a time series analysis model to predict the cluster resource utilization rate and calculate the resource entropy based on the predicted cluster resource utilization rate. The workload stability is calculated by pre-acquired tenant utilization data, and the oversold ratio of tenants is calculated by combining the workload stability with preset rules and resource entropy. The amount of schedulable resources is calculated based on the oversold ratio, and resource scheduling is performed based on the amount of schedulable resources. The formula for calculating the overbooking ratio of the tenant is as follows: ; In the formula, OversellRatio t Indicates the overselling ratio; α Indicates the oversold adjustment factor; H cluster This represents the overall predicted resource entropy of the cluster. ω t Indicates the tenant's service level agreement weight; π t Indicates container group priority; λ represents workload stability factor; S t Indicates the stability of the workload; γ represents the maximum overselling ratio limit; Real-time acquisition of container group performance metrics during scheduling; calculation of tenant service level agreement (SLP) breach scores using performance metrics; iterative adjustment of oversold ratio based on breach scores; calculation of final schedulable resource quantity based on adjusted oversold ratio; and resource scheduling based on final schedulable resource quantity. The formula for calculating the default score is as follows: ; In the formula, SLAViolationScore t This indicates the tenant's service level agreement breach score; M Indicates the total number of performance indicators; m Indicates the first m One performance indicator; Metric m,t Indicates tenant t The m The actual values ​​of each performance indicator; SLAThreshold m,t Indicates tenant t The m Tenant service level agreement thresholds for each performance metric; ω m Indicates the first m The weights of each performance metric.

2. The cluster dynamic resource overselling method based on multi-tenant resource entropy according to claim 1, characterized in that, The process of acquiring historical resource data, preprocessing the historical resource data, predicting cluster resource utilization using a time series analysis model based on the preprocessed historical resource data, and calculating resource entropy based on the predicted cluster resource utilization includes: Historical resource data is acquired, and outlier and missing values ​​are processed using linear interpolation to obtain cleaned historical resource data. The cleaned historical resource data is then standardized to obtain preprocessed historical resource data. The autoregressive integral moving average model was pre-trained using pre-processed historical resource data to obtain a cluster resource utilization prediction model. Based on the real-time acquired resource data, the cluster resource utilization rate is predicted using a cluster resource utilization rate prediction model. The predicted cluster resource utilization rate is then used to calculate the resource entropy.

3. The cluster dynamic resource overselling method based on multi-tenant resource entropy according to claim 2, characterized in that, The process of pre-training the autoregressive integral moving average model using preprocessed historical resource data to obtain a cluster resource utilization prediction model includes: Based on the characteristics of the preprocessed historical resource data, the initial parameters of the autoregressive integral moving average model are determined. The initial parameters are optimized using the parameter optimization method to obtain an optimized autoregressive integral moving average model. The preprocessed historical resource data is divided into training and validation sets. An optimized autoregressive integral moving average model is trained using the training set to obtain a cluster resource utilization prediction model. The prediction performance of the cluster resource utilization prediction model is evaluated using an error function.

4. The cluster dynamic resource overselling method based on multi-tenant resource entropy according to claim 3, characterized in that, The parameter optimization method includes: grid search, Akaike information criterion, or Bayesian information criterion; the error function includes: mean square error or mean absolute error.

5. The cluster dynamic resource overselling method based on multi-tenant resource entropy according to claim 2, characterized in that, The step of predicting cluster resource utilization using a cluster resource utilization prediction model based on real-time acquired resource data, obtaining cluster resource utilization prediction results, and calculating resource entropy based on the cluster resource utilization prediction results includes: Based on real-time acquired resource data and a preset prediction window, the cluster resource utilization rate is predicted using a cluster resource utilization prediction model, and a prediction confidence interval is generated. The resource utilization ratio is calculated based on the cluster resource utilization prediction results. The predicted resource entropy is then calculated using the resource utilization ratio. The predicted resource entropy is then normalized to obtain the normalized predicted resource entropy. Based on the preset resource type weights, the overall predicted resource entropy of the cluster is calculated using a weighted average method combined with the normalized predicted resource entropy.

6. The cluster dynamic resource overselling method based on multi-tenant resource entropy according to claim 1, characterized in that, The process of calculating workload stability using pre-acquired tenant utilization data, calculating tenant oversubscription ratios using workload stability combined with preset rules and resource entropy, calculating schedulable resource quantity based on oversubscription ratios, and performing resource scheduling based on schedulable resource quantity includes: The workload stability is calculated using pre-acquired tenant utilization data, and overselling adjustment parameters are determined. The overselling ratio of tenants is calculated based on workload stability and overselling adjustment parameters, combined with preset tenant service level agreement weights, preset container group priorities, and resource entropy. The schedulable resource quantity for each node, each type of resource, and each tenant is calculated based on the oversold ratio, and resource scheduling is performed based on the schedulable resource quantity.

7. The cluster dynamic resource overselling method based on multi-tenant resource entropy according to claim 1, characterized in that, The process of acquiring container group performance metrics in real time, calculating tenant service level agreement (SLP) breach scores using these metrics, iteratively adjusting the oversubscription ratio based on the breach scores, calculating the final schedulable resource quantity based on the adjusted oversubscription ratio, and performing resource scheduling using the final schedulable resource quantity includes: Real-time acquisition of container group performance metrics during scheduling, and calculation of tenant service level agreement breach scores using performance metrics; Default is determined by combining the default score with a preset threshold, and the overselling ratio is iteratively adjusted or the container group is rescheduled based on the default determination result. The final schedulable resource quantity is calculated based on the adjusted oversold ratio, and resource scheduling is performed based on the final schedulable resource quantity.

8. The cluster dynamic resource overselling method based on multi-tenant resource entropy according to claim 7, characterized in that, The iterative adjustment of the overselling ratio or rescheduling of container groups based on the default judgment result includes: if the default score in the default judgment result exceeds a preset threshold, the overselling ratio is reduced by a preset ratio; if the number of defaults in the default judgment result exceeds a preset number, the relevant container groups are marked as evictions, and the container groups are rescheduled according to the marked container groups.

Images