Flexible capacity expansion and contraction scheduling method based on mixed scaling under multi-resource constraint

Abstract

The invention belongs to the technical field of cloud computing container platforms, and particularly relates to an elastic capacity expansion and contraction scheduling method based on mixed scaling under multi-resource constraint. Comprising the following steps: monitoring index information of a k8s cluster based on a Kubernetes container management platform; the method comprises the following steps: constructing a vertical-horizontal collaborative elastic expansion framework, aiming at the problems of low utilization rate of horizontal expansion and contraction resources and upper limit of vertical expansion and contraction Pod resources in a single scaling mode, carrying out resource state division of multi-level thresholds based on hybrid control vertical elastic expansion and contraction scheduling according to a cost-benefit-based energy efficiency model under multi-resource constraint, and carrying out resource state division on the multi-level thresholds based on the hybrid control vertical elastic expansion and contraction scheduling; enabling the system to switch strategies in different pressure scenes; by dynamically balancing single instance resource allocation and the number of cluster instances, the resource cost is minimized on the premise of guaranteeing the service quality. According to the method, resource utilization can be optimized to the maximum extent, cost waste is reduced, and the efficiency and reliability of the whole system are improved.

Description

Technical Field

[0001] The present invention belongs to the technical field of cloud computing container platforms, and particularly relates to an elastic scaling scheduling method based on hybrid scaling under multi-resource constraints. Background Art

[0002] Cloud business models have attracted many enterprises due to their flexible resource usage methods, and the main advantage is that users only need to pay for the actually used resources. However, compared with traditional methods, cloud computing is not always a more economical choice. This largely depends on the user's ability to manage, track, and adjust their infrastructure. Insufficient resource allocation can save costs to a certain extent, but at the expense of service quality; while over-allocation of resources will lead to waste of funds and computing resources. For services with large load fluctuations and high peaks, these problems are particularly prominent. Therefore, automatic scaling systems play a crucial role because they can allocate the least amount of resources while ensuring service quality. With these systems, over-allocation of resources and additional financial costs can be effectively avoided.

[0003] In the field of information technology, resource allocation and management have always been difficult problems plaguing many company departments. Excessive resource allocation not only wastes resources but also causes unreasonable capital expenditure; while insufficient resource allocation will significantly reduce the service quality for users and seriously affect the user experience. To solve this problem, the concept of elastic scaling scheduling is proposed. In Kubernetes, container elastic scaling scheduling is divided into two scheduling methods. The first is horizontal elastic scaling, which is a strategy to adapt to load changes by increasing or decreasing the number of application instances. In Kubernetes, this strategy is usually implemented through the Horizontal Pod Autoscaler (HPA). HPA automatically adjusts the replica number of resources such as Deployment, ReplicaSet, or StatefulSet according to preset metrics (such as CPU usage, memory usage, or other custom metrics), thereby achieving the automatic expansion and contraction of applications. The advantage of horizontal scaling is that it can quickly respond to traffic peaks by increasing the number of instances to share the load, thus improving the availability and stability of the system. However, horizontal scaling may also lead to over-allocation of resources. Especially during traffic troughs, redundant instances will occupy unnecessary resources. The second is vertical elastic scaling, which is a strategy to adapt to load changes by adjusting the resource allocation (such as CPU and memory) of a single application instance. In Kubernetes, this strategy is usually implemented through the Vertical Pod Autoscaler (VPA). VPA automatically adjusts the resource allocation of Pods according to the resource requirements of the application, thereby ensuring that each instance has sufficient resources to handle its load. The advantage of vertical scaling is that it can manage resources more finely and avoid waste of resources. However, vertical scaling may also lead to over-allocation of resources for a single instance, thus affecting the overall efficiency of the system.

[0004] For horizontal elastic scaling, it sometimes cannot guarantee high resource utilization; for vertical elastic scaling, there is a performance limit for microservice instances, and it will not increase without limit as the resource supply increases. Therefore, this chapter proposes a combined scaling method of MR-CEHA (Multi-Resource Cost-Effective Hybrid Autoscaling). By integrating the cost-benefit model under multi-resource constraints in the previous text, and simultaneously using vertical elastic scaling and horizontal elastic scaling based on feedback control, it reduces both the SLA violation rate and the cost of the Kubernetes cluster. Summary of the Invention

[0005] Aiming at the deficiencies of the existing technology, the present invention proposes an elastic scaling scheduling method based on hybrid scaling under multi-resource constraints. The method includes:

[0006] Build a cost-benefit-based scheduling model under multi-resource constraints. According to the characteristics of vertical and horizontal elastic scaling, construct a cluster elasticity score, dynamic scaling threshold function, and HPA replica number decision formula to adapt to the hybrid of horizontal and vertical scaling.

[0007] Build a feedback control vertical elastic scaling framework. For the reconstruction problem that vertical elastic scaling in the default scaling mode cannot react to excessive resource supply in a timely manner, based on the cost-benefit-based energy efficiency model under multi-resource constraints, reconstruct the vertical elastic scaling framework based on a hybrid strategy of feedforward control and feedback control. Predict the load resource value based on feedforward control in a smooth load scenario, and react to the load resource value based on feedback control in a load mutation scenario.

[0008] Build a vertical-horizontal collaborative elastic scaling framework. For the problems of low resource utilization rate in horizontal scaling and upper limit of Pod resources in vertical scaling under a single scaling mode, based on the cost-benefit-based energy efficiency model under multi-resource constraints, divide the resource status of multi-level thresholds based on the hybrid control vertical elastic scaling scheduling, so that the system can switch strategies under different pressure scenarios.

[0009] Minimize the resource cost while ensuring the quality of service by dynamically balancing the resource allocation of a single instance and the number of cluster instances.

[0010] The beneficial effects of the present invention are as follows: Introduce a real-time response engine into the VPA vertical scaling mechanism. By collecting the time-series data stream of resources such as CPU / memory / IO at high frequency, combine the sliding window algorithm to predict the trend of real-time load. Compared with the traditional VPA mode that relies on periodic historical data analysis, R-VPA adopts a dual-threshold dynamic adjustment mechanism: when the resource utilization rate breaks through the instantaneous warning threshold, immediately trigger the elastic expansion of the Pod resource request; when it is detected that the resource utilization rate continues to be lower than the recovery threshold, start the progressive resource contraction process. This reactive-based strategy can adjust the resource allocation more flexibly when the load mutates, ensure meeting the SLA requirements, and avoid over-allocation of resources. Build a cascading decision-making mechanism of "vertical first - horizontal backup": when the load fluctuates, first implement vertical resource adjustment through R-VPA. If the vertical expansion reaches the preset safety boundary, automatically switch to the HPA horizontal expansion mode. Introduce a cost-benefit evaluation model in the decision-making process. By quantitatively calculating the SLA guarantee cost per unit resource, dynamically select the scaling path with the lowest comprehensive cost. Generally speaking, by introducing a reactive-based scaling strategy, VPA can more effectively cope with the challenges brought by load mutations. Through the hybrid scaling strategy, use the R-VPA and HPA hybrid scaling two-dimensional scaling algorithm to cope with different granularity resource scheduling. Make the present invention more flexible to adjust resource requests according to the real-time load situation, so as to optimize resource utilization to the greatest extent, reduce cost waste, and improve the efficiency and reliability of the overall system without violating the SLA. Brief Description of the Drawings

[0011] Figure 1 It is a flow chart of the elastic scaling scheduling method based on hybrid scaling under multi-resource constraints in the present invention;

[0012] Figure 2 It is a schematic structural diagram of the elastic scaling scheduling method based on hybrid scaling under multi-resource constraints in the present invention. Detailed Embodiments

[0013] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0014] The present invention proposes an elastic scaling scheduling method based on hybrid scaling under multi-resource constraints, as Figure 1 , Figure 2 shown, the method includes:

[0015] S1: Based on the Kubernetes container management platform, monitor the metric information of the k8s cluster.

[0016] In the Kubernetes container management platform, monitoring tools such as Cadvisor and Prometheus are used to monitor the information of the k8s cluster, such as CPU utilization, memory utilization, network IO metrics, and external resources (network latency, throughput), etc.; and monitor other resources except the default resources, including custom application-level metrics, such as response time and number of requests.

[0017] S2: Submit a YAML task, and initialize the resource allocation amount of the Pod according to the configuration information of the YAML file; use the allocated resource amount for service invocation.

[0018] Submit a YAML task. The configuration information of the YAML file contains the Pod resource allocation information. Initialize the resource allocation amount of the Pod according to the configuration information of the YAML file, create a Pod, and perform service invocation according to the allocated resource amount.

[0019] S3: Calculate the scaling threshold Score according to the current resource usage status of the Pod. And select to execute predictive feedforward control or reactive feedback control based on the Score value.

[0020] The formula for calculating the scaling threshold Score is:

[0021]

[0022] Among them, N Pod Indicates the number of Pods, N V U represents the number of SLA violations, and α represents the weight coefficient. r (Pod i ,t j ) represents the amount of resources required by the i-th Pod in the case of SLA breach, U0(Pod i ,t j ) represents the actual amount of resources allocated to the i-th Pod in the case of the j-th SLA breach.

[0023] S4: After VPA capacity expansion and contraction scheduling, HPA is used to perform horizontal capacity expansion and contraction scheduling based on the current pressure value.

[0024] Horizontal scaling: If system load remains high after the VPA completes resource expansion, the HPA increases the number of replicas (currentReplicas ← currentReplicas + 1) to further expand processing capacity. Horizontal scaling: The HPA prioritizes reducing the number of replicas to free up resources (currentReplicas ← currentReplicas - 1). VPA scaling is only executed when horizontal scaling is impossible (minReplicas has been reached). This horizontal-first, vertical-later scaling sequence maximizes resource redundancy within a single instance.

[0025] Step 1: Make scaling decisions based on the Score value. If 0.8 <Score≤2.0或-2.0≤Score<0.2,执行前馈控制缩放资源分配方案,前馈控制缩放资源分配方案包括:将Pod分配资源量填充到直方图中,计算直方图中每个桶的初始大小。具体的:

[0026] Assume that the consumption of each resource (such as CPU and memory) is an independent random variable, whose distribution is equal to the distribution of the variable observed over the past N time units (for example, if the unit is days, calculate the container resource distribution on the eighth day to capture the weekly business container peak). The Recommender component obtains real-time resource consumption data and stores it in the corresponding resource object CheckPoint. The CheckPoint CRD resource is essentially a histogram.

[0027] The size of each bucket in the histogram increases exponentially. Assume that the size of the first bucket is B. first (the maximum range that a bucket can cover), the initial size of the nth bucket is calculated as follows:

[0028]

[0029] Among them, Sn represents the initial size of the nth bucket, B first represents the size of the first bucket, and r represents the balance parameter; r is the size ratio of each bucket relative to the previous bucket (the size of the bucket grows exponentially), and r is a number greater than 1. Usually, a reasonable value is selected to balance the number of buckets and the growth rate of the bucket size. For example, if the value of r is 1.1, the accuracy is high and it is suitable for the case where the data distribution is relatively concentrated. If the value of r is 2.0, the number of buckets is small and the calculation and memory overhead are small.

[0030] The more the number of buckets, the larger the size of the nth bucket. The actual number of buckets B n is:

[0031]

[0032] where V max is the maximum value of the available resources, that is, the maximum value of the resources defined in the YAML file configuration information.

[0033] Calculate the weight index and update the size of each bucket according to the weight index. The weight index:

[0034]

[0035] where ζ represents the weight index, τ represents the current time, τ0 represents the reference time; λ represents the decay parameter, which determines the decay rate. Therefore, the closer the data point is to the current time τ, the higher the weight; the farther away from the current time, the lower the weight.

[0036] Recommender obtains the weighted sample data from the Metrics server or Prometheus, such as the CPU and Memory resource usage in the container dimension, etc. Multiply the weight of each sample data by the exponent ζ to ensure that the newer samples are given higher weights, and the weights of the older samples gradually decay over time. That is, the size of each bucket should be the information of each resource, that is, each k8s cluster information multiplied by ζ; therefore, the formula for updating the size of each bucket is:

[0037] S′ n = ζ × S n

[0038] where S′ n represents the size of the updated nth bucket.

[0039] Calculate the resource recommendation value, upper limit value, and lower limit value according to the size of the buckets in the histogram:

[0040]

[0041] Among them, T represents the resource recommendation value to ensure that the Pod has sufficient resources; L represents the resource lower limit value to ensure that the resource requests of the Pod will not be lower than a certain safety lower limit; U represents the resource upper limit value to prevent the Pod from requesting too many resources and causing resource waste; b 90 represents the current 90th percentile resource usage, that is, the resource usage of the Pod is lower than this value within 90% of the time, b 90 =

[0042] 90% × S' n . σ represents the safety margin ratio, b 90 ·(1 + σ) represents the predicted value based on historical data and adds the error standard deviation, providing a conservative estimate. p represents the minimum CPU usage of the Pod, and N represents the number of samples within the prediction window, which represents the number of resource usage data points collected during this period, that is, the current number of Pods; b 50 represents the current 50th percentile resource usage; δ is the prediction error adjustment coefficient used to adjust the range of the prediction error; b 95 represents the current 95th percentile resource usage.

[0043] Adjust the resource allocation amount of the Pod according to the resource recommendation value, upper limit value, and lower limit value and perform service calls. According to the resource recommendation value, upper limit value, and lower limit value, VPA further processes by specifying a ContainerResourcePolicy for each container to prevent the recommendation value from being too large or too small and perform service calls. The ContainerResourcePolicy defined by VPA for each container is used to control the vertical scaling mode of the container, the maximum and minimum ranges allowed for the resource recommendation value, the adjustable resources, etc.

[0044] Step 2: If Score > 2.0 or Score < -2.0, then execute the feedback control resource allocation scheme, and the feedback control resource allocation scheme includes:

[0045] Obtain the target reference and determine the target namespace, and list the Pods in the target namespace that match the target reference label. Specifically:

[0046] First, obtain the target reference targetRef, which is usually a Deployment or StatefulSet; second, determine the target namespace (namespace) and list the Pods in the target namespace that match the target reference label.

[0047] Calculate the resource lower limit value, unrestricted target value, and upper limit value of the Pod.

[0048] This formula for calculating the unrestricted target value is:

[0049]

[0050] Among them, T fc represents the unrestricted target value, V represents the current resource supply value, that is, the actual supply value of the current CPU or memory or other external resources; NU cur represents the current resource utilization rate of the Pod; NI tar represents the target resource utilization rate of the Pod. Here, NU tar is generally defaulted to 80%.

[0051] For example, when the CPU request value of the current Pod is 200m (millicores), the current CPU utilization rate is 210%, and the target CPU utilization rate is 80%. Then, the calculation of the unrestricted target value is as follows:

[0052]

[0053] The newly recommended resource value is restricted between the minimum and maximum values:

[0054] T' fc = max(min(T fc , V max ), V min )

[0055] Similarly, the lower limit value:

[0056] L fc = T fc × (1 - Δ)

[0057] The lower limit value is restricted between the minimum and maximum values:

[0058] L ′ fc = max(min(L fc , V max ), V min )

[0059] Similarly, the upper limit value:

[0060] U fc = T fc × (1 + Δ)

[0061] The upper limit value is restricted between the minimum and maximum values:

[0062] U' fc = max(min(U fc , V max ), V min )

[0063] Among them, Δ is a constant used to determine the offsets of the lower limit value and the upper limit value. For example, in the present invention, Δ = 0.2. V max is the maximum available resource of the Pod defined in YAML, V min is the minimum available resource of the Pod defined in YAML.

[0064] Adjust the resource allocation of the Pod according to the lower limit value of the resource, the unrestricted target value, and the upper limit value, and perform service calls.

[0065] According to the unrestricted target value, a resource recommendation value can be obtained. According to the new resource recommendation value, the upper limit value of the resource, and the lower limit value of the resource, VPA further processes and specifies a ContainerResourcePolicy for each container to prevent the recommendation value from being too large or too small, and perform service calls. The ContainerResourcePolicy defined by VPA for each container is used to control the vertical scaling mode of the container, the maximum and minimum ranges allowed for the resource recommendation value, the adjustable resources, etc.

[0066] Through the above formula, the target value and its upper and lower limit values can be calculated based on the optimal request of VPA and the node resource utilization rate of the system, which can improve the performance of the system under different workloads. Adjust the resource requirements of the Pod according to the resource recommendations provided by VPA and the actual running status of the node. When the load of the working node is very high, such as when the node load Score value exceeds 200% (i.e., Score > 2.0 or Score < -2.0), a higher target resource value is calculated so that the Pod can obtain more resources to handle the increased load. Conversely, when the node load Score value is low, indicating a light load, the Pod can reduce resource usage to save costs. In particular, when 0.2 ≤ Score ≤ 0.8, the current recommended value is maintained.

[0067] Step 3: Through a combination of horizontal and vertical scaling, realize the linkage of the number of replicas and resource evaluation, and define the single-Pod resource pressure index as the core indicator of HPA:

[0068]

[0069] In the formula, α r represents the resource type weight, represents the actual resource usage, represents the requested resource amount. For horizontal elastic scaling, the cluster elasticity score is expressed as:

[0070]

[0071] In the formula, β represents the SLO violation coefficient, and SLOv(t) represents the number of SLO violations within the time window. The dynamic scaling threshold function is expressed as:

[0072]

[0073] where γ represents the base threshold, and Cost dynamic (t) represents the real-time energy consumption cost, and Cost baseline represents the baseline operation and maintenance cost. The decision formula for the number of HPA replicas is expressed as:

[0074]

[0075] Based on the original energy consumption cost calculation, by introducing a dynamic scoring mechanism and cost constraint conditions, this formula can achieve the dual-objective optimization of resource utilization and service quality and elastic decision-making sensitive to energy consumption cost, serving as an improved formula for the HPA scaling threshold.

[0076] According to the above formula, when HPA performs scaling, it is divided into:

[0077] Horizontal scaling out: If there is still pressure on the system load after VPA completes resource improvement, HPA increases the number of replicas (currentReplicas←currentReplicas + 1) to further expand the processing capacity.

[0078] Horizontal scaling in: First, call horizontal scaling of HPA to reduce the number of replicas and release resources (currentReplicas←currentReplicas - 1). Only when horizontal scaling in is not possible (already reached minReplicas) will VPA perform scaling in. This scaling in order of first horizontal and then vertical maximally maintains the resource redundancy of a single instance.

[0079] S5: After an interval of one unit of time, return to step S3 until the service call task ends.

[0080] Perform scaling according to the selected scaling algorithm. To prevent oscillation effects caused by frequent scaling under excessive load changes, the parameter --vertical-pod-autoscaler-downscale-stabilization is introduced. The default value of this parameter is 1 unit of time, that is, 1 unit of time after the end of the last scaling in execution, scaling in can be performed again and the scaled result is allocated to the Pod. Return to S3 to continue iteration until the task ends.

[0081] The algorithm for hybrid scaling scheduling based on multi-resource constraints proposed by the present invention breaks through the limitations of a single scaling dimension through the sequential cooperation of VPA and HPA. It can not only quickly respond to sudden loads but also avoid the resource fragmentation problem caused by pure horizontal scaling. By using multi-level thresholds to divide the resource state, the system can switch and adjust strategies under different pressure scenarios, taking into account both response speed and stability. By dynamically balancing the resource allocation of a single instance and the number of cluster instances, the resource cost is minimized on the premise of ensuring the quality of service (QoS). This hybrid strategy is particularly suitable for scenarios with volatile loads without obvious rules, can effectively cope with sudden traffic shocks, and avoid long-term resource idleness. Its core idea reflects the system design concept of ensuring performance through vertical scaling, ensuring availability through horizontal scaling, preventing risks through vertical downscaling, and improving efficiency through horizontal downscaling.

[0082] The above-mentioned embodiments have further detailed the purpose, technical solution, and advantages of the present invention. It should be understood that the above-mentioned embodiments are only the preferred embodiments of the present invention and are not intended to limit the present invention. Any modifications, equivalent replacements, improvements, etc. made to the present invention within the spirit and principle of the present invention shall be included in the protection scope of the present invention.

Claims

1. A flexible scaling scheduling method based on hybrid scaling under multi-resource constraints, characterized in that, Including: S1: Based on the Kubernetes container management platform, monitor the metric information of the k8s cluster; S2: Submit a YAML task and initialize the resource allocation amount of the Pod according to the configuration information of the YAML file; Use the allocated resource amount for service calls; S3: Calculate the scaling threshold Score according to the resource usage status of the current Pod; S4: At the current time step, if 0.8 < Score ≤ 2.0 or -2.0 ≤ Score < 0.2, execute the predictive scaling resource allocation scheme; if Score > 2.0 or Score < -2.0, then execute the reactive scaling resource allocation scheme; S5: At the current time step, calculate and selectively execute horizontal elastic scaling according to the resource pressure value. S6: Return to step S3 after an interval of one unit time until the service call task ends.

2. The elastic scaling scheduling method based on hybrid scaling under multi-resource constraints according to claim 1, wherein The formula for calculating the scaling threshold Score is: Where N P)d represents the number of Pods, N V represents the number of SLA violations, α represents the weight coefficient, U r (Pod i , t j ) represents the amount of resources required for the i-th Pod in the j-th SLA violation scenario, U0(Pod i , t j ) represents the amount of resources actually allocated to the i-th Pod in the j-th SLA violation scenario.

3. A method for elastic scaling scheduling based on hybrid scaling under multi-resource constraints according to claim 1, characterized in that The process of executing the vertical elastic scaling scheduling scheme includes: Based on the given task set \(M = \{M_1, M_2, \ldots, M\}\), each task \(M\) is associated with the current resource request value \(R\). Set the global resource quota upper limit \(R\) as a hard boundary condition for resource adjustment to ensure that the adjustment process complies with node capacity or namespace quota limits. Integrate the Resource Monitor component (Metrics Server and Prometheus monitor) to obtain the instantaneous resource usage \(U(t)\) of each task \(M\) in real time and synchronously record the historical data sequence \(H=\{U(t - \Delta t), U(t - 2\Delta t), \ldots\}\). Calculate the vertical elastic scheduling of scaling up or down by selecting feedback control or feedforward control according to the threshold Score. Calculate the expected resource request \(R\in R\) of the feedback control. This model is based on moving window mean filtering and trend prediction: n} i is associated with the current resource request value \(R\). i Set the global resource quota upper limit \(R\) max as a hard boundary condition for resource adjustment to ensure that the adjustment process complies with node capacity or namespace quota limits. Integrate the Resource Monitor component (Metrics Server and Prometheus monitor) to obtain the instantaneous resource usage \(U(t)\) of each task \(M\) in real time and synchronously record the historical data sequence \(H=\{U(t - \Delta t), U(t - 2\Delta t), \ldots\}\). Calculate the vertical elastic scheduling of scaling up or down by selecting feedback control or feedforward control according to the threshold Score. Calculate the expected resource request \(R\in R\) of the feedback control. This model is based on moving window mean filtering and trend prediction: i instantaneous resource usage \(U\) i (t) of each task \(M\), and synchronously record the historical data sequence \(H\) i =\{U i (t - \Delta t), U i (t - 2\Delta t), \ldots\}\). i expected resource request \(R\) + of the feedback control. This model is based on moving window mean filtering and trend prediction: In the formula, β is the inertia coefficient, and EMA(·) represents the exponential moving average operator, which calculates the container elastic scaling scheduling based on the hybrid of feedback control and feedforward control.

4. A method for elastic scaling scheduling based on hybrid scaling under multi-resource constraints according to claim 3, characterized in that, To prevent prediction failures caused by underestimating sudden loads, a real-time coverage strategy is introduced: U i (t) ← max(U i (t), U min ) When the current usage U i (t) < U min is detected, the resource value is immediately updated to the lowest resource value. This mechanism ensures that the resource prediction is always not lower than the minimum requirement, avoiding the risk of resource shortage caused by model lag. By calculating the target resource request value R i , to prevent over-allocation of resources and system overload, the following verification logic is executed: directional filtering, triggering expansion only when to avoid meaningless scaling down; overload capacity limit, if force setting to ensure that the adjusted request does not exceed the global resource boundary. Submit the resource update request through the Kubernetes control plane, trigger the coordination process of the Deployment / StatefulSet controller in the old version cluster, and achieve configuration update through Pod reconstruction. Record the resource adjustment event in the audit log and push it to the monitoring system to form a feedback loop.

5. A method for elastic scaling scheduling based on hybrid scaling under multi-resource constraints according to claim 3, characterized in that Calculate M according to the Score value i Resource adaptation score, according to the score S i The threshold interval it falls into triggers a differential resource prediction model: Progressive adjustment area: (highThreshold < S i ≤ PositiveThreshold || NegativeThreshold ≤ S i < lowThreshold), Aggressive adjustment area: (S i > PositiveThreshold || S i < NegativeThreshold), Introduce a burst load detection mechanism and a non - linear correction term to quickly respond to extreme scenarios: where, R i represents the unrestricted target value, U i represents the current resource supply value, and γ is the sensitivity coefficient, which triggers a large adjustment when the resource utilization rate significantly deviates from the requested value. If the predicted value is greater than the current requested value R i , it indicates that the current resource allocation can no longer meet the expected demand, and a resource expansion operation is required.

6. A method for elastic scaling scheduling based on hybrid scaling under multi-resource constraints according to claim 1, characterized in that Through the combination of horizontal and vertical scaling, realize the linkage of replica number and resource evaluation, and define the single-Pod resource pressure index as the core index of HPA: Where α r represents the resource type weight, represents the actual resource usage, represents the requested resource amount.

7. A method for elastic scaling scheduling based on hybrid scaling under multi-resource constraints according to claim 1, characterized in that, For horizontal elastic scaling, the cluster elasticity score is expressed as: In the formula, β represents the SLO violation coefficient, and SLOv(t) represents the number of SLO violations within the time window.

8. A method for elastic scaling scheduling based on hybrid scaling under multi-resource constraints according to claim 7, characterized in that The dynamic scaling threshold function is expressed as: where γ represents the base threshold, Cost dynamic (t) represents the real-time energy consumption cost, Cost baseline represents the baseline operation and maintenance cost.

9. A method for elastic scaling scheduling based on hybrid scaling under multi-resource constraints according to claim 7, characterized in that The HPA replica number decision formula is expressed as: Based on the original energy consumption cost calculation, by introducing a dynamic scoring mechanism and cost constraint conditions, this formula can achieve the dual-objective optimization of resource utilization and service quality and the energy consumption cost-sensitive elastic decision-making, as an improved HPA scaling scheduling threshold formula.

Images