A Kubernetes cluster-based cloud computing resource elastic scaling method and system

Abstract

The application discloses a cloud computing resource elastic scaling method and system based on a Kubernetes cluster, and belongs to the technical field of artificial intelligence, S10: deploying multiple nodes and multiple Pods in the Kubernetes cluster for processing loads, and collecting load information of the cluster and the Pods in real time through a monitoring module; S20: dividing the collected load data into a training set and a test set according to time sequence, and performing normalization processing; S30: establishing a load prediction model based on historical load data, and predicting future loads by using frequency domain feature extraction and time-frequency fusion technology; S40: inputting real-time load data into the prediction model, and triggering expansion or contraction operation in combination with a set expansion or contraction threshold; S50: calling a Kubernetes API to perform expansion or contraction operation of the Pods according to the predicted load and the expansion or contraction decision; the application has the beneficial effects that not only can resource management be optimized and cost be reduced, but also cloud services can be ensured to remain stable and efficient in complex and changeable business scenarios, and the service quality and competitiveness of enterprises are improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of artificial intelligence, and more particularly, to a cloud computing resource elastic scaling method and system based on a Kubernetes cluster. BACKGROUND

[0002] With the rapid development of cloud computing technology, cloud services have become a core component of infrastructure in various industries. Cloud computing provides elastic and on-demand resource management capabilities, helping enterprises efficiently cope with changing business needs. However, as user needs become more diverse and complex, the management of cloud resources faces many challenges. Cloud service loads often exhibit dynamic changes, such as traffic peaks caused by e-commerce promotions or sudden user access growth on video platforms. These dynamic loads make it difficult to accurately predict resource needs, often leading to problems of too much or too little resources.

[0003] Traditional cloud resource allocation strategies usually use static configuration, reserving resources based on possible maximum loads. Although this approach can meet peak demand, it causes resource idling and waste during low loads, increasing operating costs. On the other hand, if cloud resources are insufficiently allocated, service performance will decline, such as increased response delays and rising request failure rates, which severely affects user experience. In a competitive market, performance problems can lead to user loss and damage to corporate reputation. Existing elastic scaling strategies usually rely on simple real-time indicators for adjustment, but these methods often lag behind, failing to timely perceive rapid changes in load, leading to slow response to scaling decisions. This lag can cause service instability in high-dynamic-load scenarios.

[0004] To achieve efficient resource utilization and ensure service quality in a cloud computing environment, more effective elastic scaling strategies are needed. Load prediction-based elastic scaling methods can predict future load changes, allowing for early adjustment of resource configurations, so that resource allocation closely matches actual demand, reducing resource waste and avoiding performance degradation due to insufficient resources. Accurate load prediction and timely scaling can significantly optimize resource utilization, reducing operating costs, especially in large-scale services that need to run for a long time (such as e-commerce platforms and cloud storage services), where such savings are particularly significant. At the same time, this strategy can ensure quick response to user requests during load peaks, avoiding service interruptions or delays due to insufficient resources, and releasing excess resources through automatic scaling during load valleys, ensuring performance stability and saving costs.

[0005] Currently, load prediction methods mainly rely on linear models or Transformer models. However, these methods have certain limitations in capturing long-range dependencies, handling noise, and adapting to different workload patterns. Linear models such as DLinear and RLinear often struggle to capture complex patterns due to weak inductive bias, leading to underfitting. Although Transformer-based models such as autoencoders and FEDformer have shown strong capabilities in time series prediction, their self-attention mechanism is usually permutation-invariant, which can lead to loss of sequence information. The high computational overhead of Transformer models also limits their application in long-term load prediction. In addition, most existing models rely excessively on time-domain features and fail to effectively integrate frequency-domain features, which limits their ability to capture inherent complex patterns in cloud workloads. In recent years, methods such as PatchTST that process time series in blocks have become mainstream techniques for long-term load time series prediction. This method preserves some temporal features by adding positional encoding to each block, but its block-based nature makes the model biased towards local pattern learning, leading to insufficient utilization of global information. At the same time, frequency enhancement methods have received widespread attention in long-term load time series prediction due to their effectiveness in capturing global trends and periodic patterns. However, existing frequency enhancement methods often fail to fully utilize the complementary advantages of time-domain and frequency-domain features, limiting their effectiveness in modeling complex sequence data. SUMMARY

[0006] To overcome the shortcomings of the prior art, a Kubernetes cluster-based cloud computing resource elasticity method and system can monitor and accurately predict cloud computing load in real time, automatically adjust resource scaling, and achieve accurate prediction of load fluctuations through load prediction models combined with frequency domain feature extraction and time-frequency fusion technology, ensuring efficient resource utilization and timely adjustment. The Kubernetes API automatically performs scaling operations, reducing human intervention and improving service stability and response capabilities.

[0007] The technical solution adopted by the invention to solve its technical problems is: a Kubernetes cluster-based cloud computing resource elasticity method, which is improved in that it includes:

[0008] S10: Deploy multiple nodes in the Kubernetes cluster, each node running multiple Pods for processing user requests or workloads, and use a monitoring module to collect performance indicators of Pods and nodes in real time;

[0009] S20: Divide the collected data into a training set and a test set in chronological order and perform normalization processing;

[0010] S30: Establish a load prediction model, train and fine-tune the model using the training set, and verify the effectiveness of the model using the test set;

[0011] S40: Collect real-time load data, input it into the load prediction model to predict future load, and trigger scaling up or down operations according to the set scaling up / down thresholds.

[0012] S50: Based on the predicted future load and scaling decisions, call the Kubernetes API to perform Pod scaling up or down operations to achieve elastic resource adjustment.

[0013] Furthermore, the load prediction model includes:

[0014] Frequency domain feature extraction module: The signal is decomposed into high-frequency details corresponding to short-term patterns and low-frequency components reflecting long-term trends through discrete wavelet transform multi-level decomposition technology. The obtained frequency domain components are spliced ​​together and the feature dimensions are transformed through a linear layer.

[0015] Time-frequency fusion module: After processing the original time-domain features into blocks, it forms joint features with the frequency-domain features. Wavelet time-frequency fusion features are obtained through a feedforward neural network layer. The wavelet time-frequency fusion features carrying cross-block trend information are used as query vectors, and the original time-domain block features are used as key vectors. Time-domain and frequency-domain information are fused through multiple frequency-enhanced attention layers, enabling the self-attention layer to utilize local patterns and global context simultaneously, breaking through the global information utilization bottleneck of PatchTST, and capturing complex patterns of load changes.

[0016] Load prediction module: By setting linear layer, ReLU activation layer and GELU activation layer to process time-frequency fusion output, it predicts load information for future time periods.

[0017] Furthermore, step S10 specifically includes the following steps:

[0018] S101: Use multiple nodes in a Kubernetes cluster, configure computing resources on each node, and deploy simulated service workloads in the cluster;

[0019] S102: Generate and control traffic patterns through load simulation tools, and design traffic peaks and troughs according to actual application scenarios;

[0020] S103: Use Kubernetes monitoring tools or other third-party monitoring tools to collect load data for clusters, nodes, and Pods.

[0021] Furthermore, step S20 specifically includes the following steps:

[0022] S201: Divide the collected load data into training set and test set in chronological order, with the data from earlier times used for training and the data from later times used for testing;

[0023] S202: Normalize the metrics in the training and test sets and scale them to the [0,1] interval.

[0024] Furthermore, step S40 specifically includes the following steps:

[0025] S401: Collect the latest load index data from the monitoring system every 1-2 minutes and convert it into a data format suitable for input into the prediction model;

[0026] S402: Pass the collected historical data to the trained load prediction model to generate load prediction values ​​for a future period of time. The load prediction values ​​include CPU utilization, memory utilization, and number of requests.

[0027] S403: Compare the load prediction value output by the model with the preset expansion and contraction thresholds, and make a judgment based on the comparison between the predicted load data and the preset expansion and contraction thresholds. When the load exceeds the set threshold, the expansion operation is triggered, and conversely, when the load is lower than the set contraction threshold, the contraction operation is triggered.

[0028] Furthermore, step S50 specifically includes the following steps:

[0029] S501: Based on scaling decisions, increase or decrease the number of Pods in a Deployment via the Kubernetes API;

[0030] S502: When scaling up, call the Kubernetes API to increase the number of Pods and allocate the new Pods to nodes with sufficient resources;

[0031] S503: When scaling down, reduce the number of Pods, prioritize removing Pods with lighter loads, and update the backend Pod list of the load balancer.

[0032] This invention also provides a cloud computing resource elastic scaling system based on a Kubernetes cluster, wherein the improvement is that the system includes:

[0033] Data acquisition module: Used to collect real-time load information from multiple nodes and Pods in a Kubernetes cluster;

[0034] Data preprocessing module: used to normalize and divide the collected load data to generate training and test sets;

[0035] Prediction module: Used to predict future load changes based on historical load data, including frequency domain feature extraction module, time-frequency fusion module and load prediction module;

[0036] The scaling control module is used to make scaling decisions on cloud service resources based on load forecast results and preset scaling thresholds.

[0037] API control module: Used to make scaling decisions, executing Pod scaling operations by calling Kubernetes API or related commands.

[0038] In the above structure, the frequency domain feature extraction module includes:

[0039] Linear layer: Used to map the input historical load data to a higher dimension for signal transformation;

[0040] Discrete wavelet transform layer: used to extract high-frequency and low-frequency components of the signal to facilitate the analysis of different characteristics of the load signal.

[0041] In the above structure, the time-frequency fusion module includes:

[0042] Feedforward neural network layer: used to transform input data into time-frequency fusion features;

[0043] Frequency-enhanced attention layer: Enhances the model's adaptability to complex temporal changes through attention mechanisms.

[0044] In the above structure, the load prediction module includes:

[0045] Linear layer and activation function layer: used to predict future load data based on the output of the time-frequency fusion module.

[0046] The beneficial effects of this invention are: it can monitor and accurately predict cloud computing load in real time, automatically adjust resource scaling, and achieve accurate prediction of load fluctuations by combining a load prediction model with frequency domain feature extraction and time-frequency fusion technology, thereby ensuring efficient utilization and timely adjustment of resources. It can also automatically perform scaling operations through the Kubernetes API, reducing human intervention and improving service stability and responsiveness. Attached Figure Description

[0047] Figure 1 This is a flowchart of a method for elastic scaling of cloud computing resources based on a Kubernetes cluster, according to the present invention.

[0048] Figure 2 This is a cluster architecture diagram of a cloud computing resource elastic scaling method based on a Kubernetes cluster according to the present invention.

[0049] Figure 3This is a schematic diagram of the overall structure of the load index prediction model of the industry instruction fine-tuning dataset automatic generation system of the present invention;

[0050] Figure 4 This is a schematic diagram of the frequency domain feature extraction module of a cloud computing resource elastic scaling method based on a Kubernetes cluster according to the present invention.

[0051] Figure 5 This is a schematic diagram of the frequency-enhanced attention layer structure of a cloud computing resource elastic scaling method based on a Kubernetes cluster according to the present invention.

[0052] Figure 6 This is a schematic diagram of the time-frequency fusion module of a cloud computing resource elastic scaling method based on a Kubernetes cluster according to the present invention. Detailed Implementation

[0053] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0054] The following will clearly and completely describe the concept, specific structure, and technical effects of the present invention in conjunction with embodiments and accompanying drawings, so as to fully understand the purpose, features, and effects of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, not all of them. Other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are all within the scope of protection of the present invention. Furthermore, all connections / linkages involved in the patent do not simply refer to direct contact between components, but rather to the ability to form a better connection structure by adding or reducing connecting accessories according to specific implementation conditions. The various technical features in this invention can be combined interactively without contradicting each other.

[0055] It should be noted that if the embodiments of the present invention involve directional indicators (such as up, down, left, right, front, back, etc.), the directional indicators are only used to explain the relative positional relationship and movement of the components in a certain specific posture (as shown in the figure). If the specific posture changes, the directional indicators will also change accordingly.

[0056] Furthermore, if the embodiments of this invention involve descriptions such as "first" or "second," these descriptions are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined with "first" or "second" may explicitly or implicitly include at least one of those features. Secondly, the technical solutions of the various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. When the combination of technical solutions is contradictory or impossible to implement, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed by this invention.

[0057] See Figures 1-2 As shown, this invention provides a method for elastic scaling of cloud computing resources based on a Kubernetes cluster, including:

[0058] S10: Deploy multiple nodes in a Kubernetes cluster, with each node running multiple Pods to handle user requests or workloads, and use the monitoring module to collect Pod and node performance metrics in real time.

[0059] S20: Divide the collected data into training and test sets in chronological order and perform normalization processing;

[0060] S30: Establish a load prediction model, train and fine-tune the model using the training set, and verify the effectiveness of the model using the test set;

[0061] S40: Collect real-time load data, input it into the load prediction model to predict future load, and trigger scaling up or down operations according to the set scaling up / down thresholds.

[0062] S50: Based on the predicted future load and scaling decisions, call the Kubernetes API to perform Pod scaling up or down operations to achieve elastic resource adjustment.

[0063] This invention combines historical load data with real-time load forecasting to accurately predict future load changes and dynamically adjust resource allocation within the Kubernetes cluster based on the forecast results. It then employs a load forecast-based scaling-up / scaling strategy, avoiding the waste of excessive resource reservations or idle resources that can result from traditional static resource configuration. When the load is low, scaling down automatically releases excess resources, significantly reducing the operating costs of the cloud computing platform. This invention uses frequency domain feature extraction and time-frequency fusion technology to capture changes in load signals from both time and frequency domain perspectives, enhancing the adaptability of the load forecasting model to complex load patterns. Through deep integration with the Kubernetes API, the system can respond to load changes in real time, enabling automatic scaling up and down. During scaling up, the system allocates new Pods to nodes with sufficient resources to ensure load balancing; during scaling down, the system prioritizes removing Pods with lighter loads to maintain service stability and optimize resource utilization efficiency.

[0064] Furthermore, step S10 specifically includes the following steps:

[0065] S101: Use multiple nodes in a Kubernetes cluster, configure computing resources on each node, and deploy simulated service workloads in the cluster;

[0066] S102: Generate and control traffic patterns through load simulation tools, and design traffic peaks and troughs according to actual application scenarios;

[0067] S103: Use Kubernetes monitoring tools or other third-party monitoring tools to collect load data for clusters, nodes, and Pods.

[0068] Deploying simulated service workloads in a Kubernetes cluster accurately reproduces the load patterns of a real-world production environment. This provides a testing environment that more closely resembles actual operation, simulating cluster performance under different traffic scenarios and offering more realistic data support for load prediction model training and scaling decisions. By generating and controlling traffic patterns through load simulation tools, traffic peaks and troughs can be set to test the cluster's responsiveness under different loads, ensuring that the system can handle high load pressure and low load idleness during actual use, thereby guaranteeing system stability and performance. Real-time load data for the cluster, nodes, and Pods can be collected using Kubernetes monitoring tools or other third-party monitoring tools. Monitoring tools provide multi-dimensional performance metrics (such as CPU utilization, memory utilization, network bandwidth, etc.), which help developers, operations personnel, or prediction models accurately understand the current system workload. Designing traffic peaks and troughs through simulation tools allows the system to prepare for extreme load scenarios in advance. For example, it's possible to simulate a surge in traffic during peak business periods or a sharp drop in traffic during off-peak periods, thereby testing the system's responsiveness under these extreme conditions.

[0069] In this embodiment, data collection is based on a dynamic load simulation scenario running on a Kubernetes cluster. The cluster consists of multiple nodes, each running multiple Pods to handle user requests or workloads. A 4-node Kubernetes cluster is used, with each node configured with 2 CPU cores, 4GB of memory, and 40GB of disk, providing a balanced and reliable computing resource foundation. A Flask application is deployed as the simulated service workload, with each Flask instance running in an independent Pod; the application simulates CPU-intensive tasks through cumulative computational operations, and the load intensity is controlled by the parameters of the user requests.

[0070] The Apache Benchmark (ab) tool is used to simulate request load. The `-n` parameter specifies the total number of requests, and the `-c` parameter specifies the number of concurrent requests, allowing users to control the overall intensity and concurrency of the simulated requests. The frequency and intensity of requests are designed based on real-world scenarios. The traffic pattern is derived from the Google 2011 dataset, simulating periodic changes in workload and sudden increases in traffic. For example, request traffic peaks during the morning (9:00-11:00) and evening (19:00-21:00) periods, gradually decreasing at other times. This design effectively simulates traffic fluctuations in real-world business scenarios.

[0071] This implementation leverages Kubernetes' built-in Metrics Server and Prometheus system monitoring tools to collect real-time performance metrics for Pods and nodes. This includes Pod-level data such as CPU utilization, memory utilization, and requests per Pod (QPS), as well as cluster-level data such as total CPU utilization, total memory utilization, and total requests, forming multivariate time-series data. Sampling is performed every minute to generate multivariate time-series data, continuously collecting workload data for 8 days to ensure data sufficiency and diversity. This implementation is not only suitable for Flask applications but can also be extended to other types of applications (such as Node.js, Java, etc.) to adapt to different workloads and business scenarios.

[0072] The specific steps of step S20 include:

[0073] S201: Divide the collected load data into training set and test set in chronological order, with the data collected in the first 7 days used for training and the data collected in the last day used for testing;

[0074] S202: Normalize the metrics in the training and test sets and scale them to the [0,1] interval.

[0075] Then, for each time step data x = {x1, x2, ..., x...} n Each feature x in} n After normalization using the following formula, we get x′={x′1,x′2,…,x′ n}:

[0076]

[0077] in, Let n be the minimum value of the nth indicator feature in the training set. This represents the maximum value of the nth indicator feature in the training set.

[0078] By partitioning the time-series data, the independence between the training and test sets is ensured, avoiding overfitting. The model learns from past historical load data to predict future load patterns, thereby enhancing its predictive ability. Within the load data, some metrics may have large numerical ranges, while others (such as CPU utilization and memory utilization) may have relatively small ranges. This difference can cause certain metrics to dominate during training, affecting model performance. Normalization scales all metric values ​​to a uniform [0,1] range, ensuring that each metric has roughly the same weight during model training, thus preventing any single metric from having an excessive impact on model training.

[0079] Using a sliding window method, each sample X in the training and test sets is split into model input load and load prediction target. The sliding window length is selected as L. all Data X with time step L before partitioning 1:L As the input history load of the model, the remaining L true =L all -L time step data As a model, it predicts the actual load.

[0080] A schematic diagram of the overall structure of the load index prediction model is shown below. Figure 3 As shown, the load index prediction model consists of a frequency domain feature extraction module, a time-frequency fusion module, and a load prediction module. The model input data is historical load data, and the output is predicted load data.

[0081] Frequency domain feature extraction module: The signal is decomposed into high-frequency details corresponding to short-term patterns and low-frequency components reflecting long-term trends through discrete wavelet transform multi-level decomposition technology. The obtained frequency domain components are spliced ​​together and the feature dimensions are transformed through a linear layer.

[0082] Time-frequency fusion module: After processing the original time-domain features into blocks, it forms joint features with the frequency-domain features. Wavelet time-frequency fusion features are obtained through a feedforward neural network layer. The wavelet time-frequency fusion features carrying cross-block trend information are used as query vectors, and the original time-domain block features are used as key vectors. Time-domain and frequency-domain information are fused through multiple frequency-enhanced attention layers, enabling the self-attention layer to utilize local patterns and global context simultaneously, breaking through the global information utilization bottleneck of PatchTST, and capturing complex patterns of load changes.

[0083] Load prediction module: By setting linear layer, ReLU activation layer and GELU activation layer to process time-frequency fusion output, it predicts load information for future time periods.

[0084] Discrete wavelet transform (DWT) can decompose input data into components of different frequencies, allowing the model to simultaneously capture short-term fluctuations (high frequencies) and long-term trends (low frequencies) in the data. This is particularly important for load data, as load changes typically contain both periodic patterns and sudden fluctuations. By separating these components, the model can more accurately predict future load conditions. Transforming the frequency domain features extracted by wavelet transform through a linear layer can compress or expand the information into a form suitable for subsequent model processing. This helps reduce redundant information in the feature space, improves the computational efficiency of the model, and enhances the separability of features. In this embodiment, the frequency domain feature extraction module consists of a linear layer and a discrete wavelet transform layer, as follows: Figure 4 As shown.

[0085] The linear layer responsible for receiving model input takes the original input time series X with a time step of L and the number of features M. 1:L ∈ MxL Mapping to a higher dimension X′ 1:L ∈ LxL Discrete wavelet transform is performed; the discrete wavelet transform layer uses the DB1 wavelet basis as the basis function, and a low-pass filter is used. High-pass filter

[0086] Use the following formula to extract the low-frequency components from the input information:

[0087]

[0088] Use the following formula to extract high-frequency components from the input information:

[0089]

[0090] Where K = 2, t represents the time step, and f low [k] and f high [k] represents the k-th weight of the low-pass filter and the high-pass filter, respectively.

[0091] The extracted low-frequency components contain global information about the time series, while the high-frequency components reveal key points of change within the time series. The extracted high-frequency components F... high and low-frequency component F low The concatenation is performed as the transformation result; the concatenated result is then used as the input to a linear layer to extract intermediate features F′.

[0092] F′=Linear(concat(F low ,F high ));

[0093] The linear layer responsible for outputting frequency features maps the intermediate feature representations back to the original feature dimensions:

[0094] F = Linear(F′);

[0095] Where F∈ MxL .

[0096] Further, a schematic diagram of the time-frequency fusion module structure is shown, as follows: Figure 6As shown, the time-frequency fusion module consists of a feedforward neural network layer, two linear embedding layers, several frequency-enhancing attention layers, a Flatten layer, and a linear output layer. Before receiving input data, the time-frequency fusion module needs to further divide the input samples into a series of patches, determining the number of patches N and their length A. Thus, the input samples are divided into n time series patches of length A. The time-frequency fusion module models each feature of the input time series separately, and all features share the network parameters in the same module. For ease of description, the method described below only operates on one feature; the operations on other features in the data are consistent with and independent of the feature operations described. The attention mechanism can dynamically adjust the weights according to the importance of different frequencies, making the model pay more attention to key frequency regions (such as load peaks during specific periods). This mechanism can automatically learn and extract frequency domain information that has an important impact on load changes, thereby improving prediction accuracy.

[0097] Feedforward Neural Networks (FFNNs) can nonlinearly combine information in the time and frequency domains, capturing complex relationships in data through a multilayer perceptron approach. Load data variations are often influenced by multiple factors, and FFNNs can handle these complex relationships, avoiding data patterns that simple linear models cannot capture.

[0098] After the above operations, the data containing the Mth feature of an input time series sample with M features and L length is decomposed into a series of Patch sequences P. (m) ∈ NxA The sequence F corresponding to the Mth frequency feature extracted by the feature extraction module. (m) ∈ 1xL After repeating N times, we obtain F' (m) ∈ NxL Concatenate it with the Patch sequence to obtain TF' (m) ∈ Nx(A+L) :

[0099] TF' (m) =concat(F′( m ),P (m) );

[0100] The feedforward neural network layer in the time-frequency fusion module is responsible for converting the concatenated information into time-frequency fusion features (TFs). (m) ∈ NxA ;

[0101] TF (m) =MLP(TF' (m) );

[0102] Two independent linear embedding layers are responsible for integrating the time-frequency fusion features TF. (m) Time-domain data P (m) Transformed into the input of the frequency-enhanced attention layer:

[0103]

[0104] in, These represent the parameters of the two linear embedding layers, respectively.

[0105] Several layers of frequency-enhanced attention layers are responsible for capturing complex patterns in the time series and improving adaptability to dynamic changes. The frequency-enhanced attention layers consist of multi-head attention layers, normalization layers, and feedforward neural network layers.

[0106] The first frequency-enhanced attention layer, corresponding to the portion of each attention head, yields the embedding features for single-head attention as follows:

[0107]

[0108] The single-head attention output is obtained by performing a softmax dot product operation on the embedded features.

[0109]

[0110] in D represents the feature dimension, and H represents the number of attention heads. The outputs of the attention heads are concatenated to obtain O. 1 , will O 1 After performing residual connections and inputting them into a normalization layer, the results are fed into a feedforward neural network (FFN) layer to obtain an intermediate representation. Finally, after another residual connection, the results are input into the last normalization layer to obtain the output h of the frequency-enhanced attention layer. 1 h 1 and This will be used as the input to the next frequency-enhanced attention layer, and so on; therefore, for the input of the Lth frequency-enhanced attention layer, we have:

[0111]

[0112] A schematic diagram of the frequency-enhanced attention layer structure is shown below. Figure 5 As shown. After several layers of frequency-enhanced attention layers, the output h is obtained. last ,h last The input to the Flatten layer is used as input, and finally the output z of the time-frequency fusion module is obtained through the linear layer. (m) :

[0113] z (m) =Linear(Flatten(h last ));

[0114] The load prediction module consists of a linear layer, a ReLU activation function layer, and a GELU activation function layer. It uses the output of the time-frequency fusion module as input to predict load information for future times.

[0115] The weights w for each time step in the output of the time-frequency fusion module are calculated using linear and ReLU layers. (m)

[0116] w (m) =Linear(ReLU(Linear(z) (m) )));

[0117] The m-th feature is obtained by element-wise multiplication, followed by the GELU activation function and the last linear layer, and then further processed in the future L... true Load forecast information for each time step:

[0118]

[0119] This load index prediction model effectively handles complex load data patterns by combining frequency domain feature extraction, time-frequency fusion, and a load prediction module. High- and low-frequency components are extracted using discrete wavelet transform, and the fusion of a feedforward neural network and a frequency-enhanced attention mechanism improves the model's ability to capture load fluctuations. Furthermore, the load prediction module utilizes a combination of various activation functions and linear layers to enable the model to predict future loads more accurately. Overall, the model maintains high computational efficiency and stability while improving prediction accuracy, making it suitable for various practical application scenarios.

[0120] The model is trained based on the error between the actual load data of the calculated samples and the predicted load output by the model. The parameters of different network structures in the model are adjusted to obtain a model that can accurately predict future long-term loads based on historical load data. The loss function for model training is defined by the following formula:

[0121]

[0122] Where Loss is the loss function used during training. Indicates a time step of L true The future load forecast target, Indicates a time step of L true The model outputs a predicted load.

[0123] The selected network model is validated using a test set to evaluate its generalization ability. The evaluation metrics are mean squared error (MSE) and mean absolute error (MAE).

[0124]

[0125] Among them, y i Represents the actual value. This represents the predicted value.

[0126] The trained and validated model is deployed to the prediction module of the Kubernetes cluster control node to achieve elastic scaling of real-time cloud service resources in the Kubernetes cluster.

[0127] The specific steps of step S40 include:

[0128] S401: Collect the latest load index data from the monitoring system every minute and convert it into a data format suitable for input into the prediction model;

[0129] S402: Pass the collected historical data to the trained load prediction model to generate load prediction values ​​within 4 minutes, including CPU utilization, memory utilization, and number of requests.

[0130] S403: Compare the load prediction value output by the model with the preset expansion and contraction thresholds, and make a judgment based on the comparison between the predicted load data and the preset expansion and contraction thresholds. When the load exceeds the set threshold, the expansion operation is triggered, and conversely, when the load is lower than the set contraction threshold, the contraction operation is triggered.

[0131] Furthermore, step S50 specifically includes the following steps:

[0132] S501: Based on scaling decisions, increase or decrease the number of Pods in a Deployment via the Kubernetes API;

[0133] S502: When scaling up, call the Kubernetes API to increase the number of Pods and allocate the new Pods to nodes with sufficient resources;

[0134] S503: When scaling down, reduce the number of Pods, prioritize removing Pods with lighter loads, and update the backend Pod list of the load balancer.

[0135] The Kubernetes API is the core of a Kubernetes cluster, providing users and systems with a way to interact with the cluster, manage, and control resources. The Kubernetes API acts as a communication bridge between the Kubernetes cluster's control plane and its various components, and is the primary way to interact with the Kubernetes cluster via command-line tools (such as kubectl) and other clients (such as Helm). The API Server is the entry point to the Kubernetes cluster; it's where all requests within the cluster (such as managing Pods, Deployments, Services, etc.) pass through. It processes user requests, forwarding them to the appropriate controller, resource manager, or persistent storage.

[0136] Automated scaling decisions via the Kubernetes API mean that resources can be automatically adjusted based on system load, business needs, or pre-defined strategies. This process avoids manual intervention and responds quickly to changes in system load. During scaling up, the number of Pods is automatically increased, ensuring that new Pods are allocated to nodes with sufficient resources. The system can automatically sense cluster status and dynamically schedule resources based on node availability (such as CPU and memory), avoiding excessive resource concentration and ensuring stable system operation. During scaling down, lighter-loaded Pods are automatically removed. By sensing load, the least-loaded Pods can be intelligently removed, maintaining application performance while freeing up unused resources and avoiding wasted computing resources. Automatic scaling up and down provides the system with good elasticity, allowing resources to be added or removed based on real-time load conditions. This elasticity ensures stable application operation regardless of traffic peaks or troughs. Scaling up and down via the Kubernetes API guarantees that the system dynamically adjusts according to actual needs, supporting high business scalability.

[0137] like Figure 2 As shown, the present invention also provides a cloud computing resource elastic scaling system based on a Kubernetes cluster, the system comprising:

[0138] Data acquisition module: Used to collect real-time load information from multiple nodes and Pods in a Kubernetes cluster;

[0139] Data preprocessing module: used to normalize and divide the collected load data to generate training and test sets;

[0140] Prediction module: Used to predict future load changes based on historical load data, including frequency domain feature extraction module, time-frequency fusion module and load prediction module;

[0141] The scaling control module is used to make scaling decisions on cloud service resources based on load forecast results and preset scaling thresholds.

[0142] API control module: Used to make scaling decisions, executing Pod scaling operations by calling Kubernetes API or related commands.

[0143] Furthermore, the linear layer is used to map the input historical load data to a higher dimension for signal transformation;

[0144] Discrete wavelet transform layer: used to extract high-frequency and low-frequency components of the signal to facilitate the analysis of different characteristics of the load signal.

[0145] Furthermore, the time-frequency fusion module includes:

[0146] Feedforward neural network layer: used to transform input data into time-frequency fusion features;

[0147] Frequency-enhanced attention layer: Enhances the model's adaptability to complex temporal changes through attention mechanisms.

[0148] The load prediction module includes:

[0149] Linear layer and activation function layer: used to predict future load data based on the output of the time-frequency fusion module.

[0150] This Kubernetes-based cloud computing resource elastic scaling system achieves automated and intelligent resource management through the collaborative work of multiple modules (such as data acquisition, preprocessing, load prediction, and scaling control). Utilizing technologies such as deep learning and time-frequency analysis, the system can accurately predict load changes and make reasonable scaling decisions based on the prediction results, thereby improving resource utilization efficiency and ensuring high application availability and system elastic scaling.

[0151] The embodiments described above are merely illustrative of several implementations of the present invention, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these modifications and improvements all fall within the scope of protection of the present invention. Therefore, the scope of protection of this patent should be determined by the appended claims.

[0152] Finally, it should be noted that the above is a detailed description of the preferred embodiments of the present invention, but the present invention is not limited to the embodiments described. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of the present invention, and these equivalent modifications or substitutions are all included within the scope defined by the claims of this application.

Claims

1. A method for elastic scaling of cloud computing resources based on a Kubernetes cluster, characterized in that, include: S10: Deploy multiple nodes in a Kubernetes cluster, with each node running multiple Pods to handle user requests or workloads, and use the monitoring module to collect Pod and node performance metrics in real time. S20: Divide the collected data into training and test sets in chronological order and perform normalization processing; S30: Establish a load prediction model, train and fine-tune the model using the training set, and verify the effectiveness of the model using the test set; The load prediction model includes: Frequency domain feature extraction module: The signal is decomposed into high-frequency details corresponding to short-term patterns and low-frequency components reflecting long-term trends through discrete wavelet transform multi-level decomposition technology. The obtained frequency domain components are spliced ​​together and the feature dimensions are transformed through a linear layer. Time-frequency fusion module: After processing the original time-domain features into blocks, it forms joint features with the frequency-domain features. Wavelet time-frequency fusion features are obtained through a feedforward neural network layer. The wavelet time-frequency fusion features carrying cross-block trend information are used as query vectors, and the original time-domain block features are used as key vectors. Time-domain and frequency-domain information are fused through multiple frequency-enhanced attention layers, enabling the self-attention layer to utilize local patterns and global context simultaneously, breaking through the global information utilization bottleneck of PatchTST, and capturing complex patterns of load changes. Load prediction module: By setting linear layer, ReLU activation layer and GELU activation layer to process time-frequency fusion output, it predicts load information for future time periods; S40: Collect real-time load data, input it into the load prediction model to predict future load, and trigger scaling up or down operations according to the set scaling up / down thresholds. S50: Based on the predicted future load and scaling decisions, call the Kubernetes API to perform Pod scaling up or down operations to achieve elastic resource adjustment.

2. The method for elastic scaling of cloud computing resources based on a Kubernetes cluster according to claim 1, characterized in that, The specific steps of step S10 include: S101: Use multiple nodes in a Kubernetes cluster, configure computing resources on each node, and deploy simulated service workloads in the cluster; S102: Generate and control traffic patterns through load simulation tools, and design traffic peaks and troughs according to actual application scenarios; S103: Use Kubernetes monitoring tools or other third-party monitoring tools to collect load data for clusters, nodes, and Pods.

3. The method for elastic scaling of cloud computing resources based on a Kubernetes cluster according to claim 1, characterized in that, The specific steps of step S20 include: S201: Divide the collected load data into training set and test set in chronological order, with the data from earlier times used for training and the data from later times used for testing; S202: Normalize the metrics in the training and test sets and scale them to the [0,1] interval.

4. The method for elastic scaling of cloud computing resources based on a Kubernetes cluster according to claim 1, characterized in that, The specific steps of step S40 include: S401: Collect the latest load index data from the monitoring system every 1-2 minutes and convert it into a data format suitable for input into the prediction model; S402: Pass the collected historical data to the trained load prediction model to generate load prediction values ​​for a future period of time. The load prediction values ​​include CPU utilization, memory utilization, and number of requests. S403: Compare the load prediction value output by the model with the preset expansion and contraction thresholds, and make a judgment based on the comparison between the predicted load data and the preset expansion and contraction thresholds. When the load exceeds the set threshold, the expansion operation is triggered, and conversely, when the load is lower than the set contraction threshold, the contraction operation is triggered.

5. The method for elastic scaling of cloud computing resources based on a Kubernetes cluster according to claim 4, characterized in that, The specific steps of step S50 include: S501: Based on scaling decisions, increase or decrease the number of Pods in a Deployment via the Kubernetes API; S502: When scaling up, call the Kubernetes API to increase the number of Pods and allocate the new Pods to nodes with sufficient resources; S503: When scaling down, reduce the number of Pods, prioritize removing Pods with lighter loads, and update the backend Pod list of the load balancer.

6. A cloud computing resource elastic scaling system based on a Kubernetes cluster, the system being used to execute the cloud computing resource elastic scaling method based on a Kubernetes cluster as described in any one of claims 1-5, characterized in that, The system includes: Data acquisition module: Used to collect real-time load information from multiple nodes and Pods in a Kubernetes cluster; Data preprocessing module: used to normalize and divide the collected load data to generate training and test sets; Prediction module: Used to predict future load changes based on historical load data, including frequency domain feature extraction module, time-frequency fusion module and load prediction module; The scaling control module is used to make scaling decisions on cloud service resources based on load forecast results and preset scaling thresholds. API control module: Used to make scaling decisions, executing Pod scaling operations by calling Kubernetes API or related commands.

7. The system according to claim 6, wherein, The frequency domain feature extraction module includes: Linear layer: Used to map the input historical load data to a higher dimension for signal transformation; Discrete wavelet transform layer: used to extract high-frequency and low-frequency components of the signal to facilitate the analysis of different characteristics of the load signal.

8. The system according to claim 6, wherein, The time-frequency fusion module includes: Feedforward neural network layer: used to transform input data into time-frequency fusion features; Frequency-enhanced attention layer: Enhances the model's adaptability to complex temporal changes through attention mechanisms.

9. The system according to claim 6, wherein, The load prediction module includes: Linear layer and activation function layer: used to predict future load data based on the output of the time-frequency fusion module.

Images