Cloud computing resource elastic scaling method and system based on Kubernetes cluster

Abstract

The invention 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 a time sequence, and performing normalization processing; s30, establishing a load prediction model based on historical load data, and predicting a future load by using a frequency domain feature extraction and time-frequency fusion technology; s40, inputting the prediction model according to the real-time load data, and triggering a capacity expansion and contraction operation in combination with a set capacity expansion and contraction threshold value; s50, calling the Kubernetes AP I to execute the capacity expansion or capacity shrinkage operation of the Pod according to the predicted load and the capacity expansion and shrinkage decision; the method has the beneficial effects that the resource management can be optimized, the cost can be reduced, the cloud service can be ensured to keep stable and efficient operation in a complex and changeable business scene, and the service quality and competitiveness of an enterprise are improved.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence technology, and more specifically, to a method and system for elastic scaling of cloud computing resources based on Kubernetes clusters. Background Technology

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

[0003] Traditional cloud resource allocation strategies typically employ static configuration, reserving resources based on the maximum possible load. While this approach can meet peak demand, it leads to resource idleness and waste during periods of low load, increasing operational costs. Conversely, insufficient cloud resource allocation degrades service performance, resulting in increased response latency and request failure rates, severely impacting user experience. In a highly competitive market, performance issues can lead to customer churn and damage to a company's reputation. Existing elastic scaling strategies often rely on simple real-time metrics for adjustments, but these methods are often lagging and fail to promptly detect rapid load changes, resulting in slow scaling decisions. This lag can cause service instability in high-dynamic-load scenarios.

[0004] To achieve efficient resource utilization and ensure service quality in cloud computing environments, more effective elastic scaling strategies are urgently needed. Load forecasting-based elastic scaling methods predict future load changes, enabling proactive adjustments to resource configuration. This ensures resource allocation closely matches actual demand, reducing resource waste and preventing performance degradation due to resource shortages. Accurate load forecasting and timely scaling up and down significantly optimize resource utilization and reduce operating costs, especially for large-scale services requiring long-term operation (such as e-commerce platforms and cloud storage services). This strategy also ensures rapid response to user requests during peak load periods, preventing service interruptions or delays due to resource shortages, and automatically scaling down to release excess resources during off-peak periods, guaranteeing both performance stability and cost savings.

[0005] Currently, load forecasting methods primarily rely on linear or Transformer models. However, these methods have limitations in capturing long-range dependencies, handling noise, and adapting to different workload patterns. Linear models such as DLinear and RLinear, due to their weak inductive bias, often struggle to capture complex patterns and are prone to underfitting. While Transformer-based models (such as autoencoders and FEDformers) have demonstrated strong capabilities in time series forecasting, their self-attention mechanisms are typically permutation-invariant, easily leading to the loss of sequence information. The high computational cost of Transformer models also limits their application in long-term load forecasting. Furthermore, most existing models over-rely on temporal features and fail to effectively integrate frequency domain features, limiting their ability to capture the inherent complex patterns in cloud workloads. In recent years, methods such as PatchTST, which divide time series data into blocks, have become the mainstream technique for long-term load time series forecasting. This method retains some temporal features by adding positional encoding to each block, but its block-based nature makes the model biased towards local pattern learning, resulting in insufficient utilization of global information. Meanwhile, frequency augmentation methods have attracted widespread attention in long-term load time series forecasting due to their effectiveness in capturing global trends and periodic patterns. However, existing frequency augmentation 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 of the Invention

[0006] To overcome the shortcomings of existing technologies, a method and system for elastic scaling of cloud computing resources based on Kubernetes clusters is proposed. This method 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. This ensures efficient utilization and timely adjustment of resources. The system automatically performs scaling operations through the Kubernetes API, reducing human intervention and improving service stability and responsiveness.

[0007] The technical solution adopted by the invention to solve its technical problem is: a method for elastic scaling of cloud computing resources based on Kubernetes clusters, the improvement of which includes:

[0008] 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.

[0009] S20: Divide the collected data into training and test sets 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

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

[0055] The following will clearly and completely describe the concept, specific structure and technical effects of the present invention in combination with the embodiments and drawings, so as to fully understand the purpose, characteristics and effects of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of them. Based on the embodiments of the present invention, other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present invention. In addition, all the connection / connection relationships involved in the patent do not refer to the direct connection of components, but refer to the fact that a better connection structure can be formed by adding or reducing connection accessories according to the specific implementation situation. The various technical features in the invention can be combined interactively without conflicting with each other.

[0056] 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.

[0057] 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.

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

[0059] 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.

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

[0061] 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;

[0062] 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.

[0063] 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.

[0064] 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 scaling-down operations. 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.

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

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

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

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

[0069] 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.

[0070] 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.

[0071] 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.

[0072] 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.

[0073] The specific steps of step S20 include:

[0074] 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;

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

[0076] 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}:

[0077]

[0078] 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.

[0079] 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.

[0080] 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.

[0081] 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.

[0082] 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.

[0083] 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.

[0084] 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.

[0085] 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.

[0086] 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

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

[0088]

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

[0090]

[0091] 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.

[0092] 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′.

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

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

[0095] F = Linear(F′);

[0096] Where F∈ MxL .

[0097] 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.

[0098] 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.

[0099] 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) :

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

[0101] 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 ;

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

[0103] 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:

[0104]

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

[0106] 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 layer consists of a multi-head attention layer, a normalization layer, and a feedforward neural network layer.

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

[0108]

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

[0110]

[0111] 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:

[0112]

[0113] 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) :

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

[0115] The load prediction module is shown in Figure 7. It 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 the load information for future times.

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

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

[0118] 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:

[0119]

[0120] 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.

[0121] 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:

[0122]

[0123] 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.

[0124] 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).

[0125]

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

[0127] 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.

[0128] The specific steps of step S40 include:

[0129] 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;

[0130] 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.

[0131] 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.

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

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

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

[0135] 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.

[0136] 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.

[0137] 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.

[0138] 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:

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

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

[0141] 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;

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

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

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

[0145] 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.

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

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

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

[0149] The load prediction module includes:

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

[0151] 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.

[0152] 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.

[0153] 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; 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 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.

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 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.

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 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.

5. 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.

6. The method for elastic scaling of cloud computing resources based on a Kubernetes cluster according to claim 5, characterized in that, The specific steps of step S50 include: S501: Based on scaling decisions, increase or decrease the number of Pods in the Dep loyment 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.

7. A cloud computing resource elastic scaling system based on a Kubernetes cluster, 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.

8. The system according to claim 7, 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.

9. The system according to claim 7, 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.

10. The system according to claim 7, 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