Elastic capacity expansion and contraction method, device and equipment for container arrangement platform and storage medium

Abstract

The invention relates to the technical field of information processing, in particular to an elastic capacity expansion and contraction method, device and equipment for a container arrangement platform and a storage medium, and solves the problem of insufficient service perception of a traditional HPA by collecting resource indexes and service indexes of containers in real time and performing joint modeling on the service indexes and system indexes. The multi-index joint prediction model is used for predicting resource requirements in a certain time in the future, differentiated service priority weights are distributed for different service services, the number of Deployment copies is dynamically adjusted based on the resource requirements and the service priority weights, capacity expansion and shrinkage adjustment information is generated based on changes of the number of the Deployment copies, and the capacity expansion and shrinkage adjustment information is used for adjusting the capacity expansion and shrinkage of the different service services. According to the method, the response effect on burst flow is improved, the operation state of the capacity expansion and contraction adjustment information is monitored in real time, when the monitoring information is abnormal, the rollback strategy is executed, the abnormal feedback information is generated, response is rapid, and the capacity expansion and contraction requirement of the delay sensitive application container is met.

Description

Technical Field

[0001] The present invention relates to the field of information processing technology, and in particular to a method, apparatus, device, and storage medium for elastically scaling a container orchestration platform. Background Art

[0002] Currently, in cloud computing environments, Kubernetes (K8s) provides automated configuration, management, and orchestration of containers, along with automatic elastic scaling to address changing resource demands of business containers. K8s primarily implements elastic scaling through the HorizontalPodAutoscaler (HPA) and VerticalPodAutoscaler (VPA). HPA uses simple threshold policies to determine whether to scale capacity. This responsive approach results in significant delays in responding to changes in business container load and cannot meet the scaling requirements of latency-sensitive application containers. Existing HPA relies on single metrics like CPU and memory, making it unable to cope with sudden traffic bursts such as those associated with e-commerce promotions. It also fails to incorporate business metrics like request volume, response time, and order volume, leading to a disconnect between resource allocation and business needs. Rules based on historical averages or percentiles (such as scaling when CPU > 80%) are slow to respond and can easily trigger service outages. Summary of the Invention

[0003] In order to overcome the shortcomings of the existing technology, the purpose of the present invention is to provide a container orchestration platform elastic scaling method, device, equipment and storage medium that responds quickly and meets the scaling needs of delay-sensitive application containers, jointly models business indicators and system indicators, solves the problem of insufficient business perception of traditional HPA, and can configure weights according to business priorities and dynamically adjust the number of Deployment copies based on predicted resource requirements and weights, thereby improving the response effect to sudden traffic.

[0004] The first aspect of the present invention provides a method for elastic scaling of a container orchestration platform, comprising: real-time collection of resource indicators and business indicators of containers, pre-processing the resource indicators and business indicators to obtain multi-dimensional indicators; inputting the multi-dimensional indicators into a preset multi-indicator joint prediction model, and using the multi-indicator joint prediction model to predict resource requirements within a certain period of time in the future; assigning differentiated business priority weights to different business services, and dynamically adjusting the number of Deployment copies based on the resource requirements and the business priority weights; generating scaling adjustment information based on changes in the number of Deployment copies, monitoring the operating status of the scaling adjustment information in real time to obtain monitoring information; when the monitoring information is abnormal, executing a rollback strategy and generating abnormal feedback information, and optimizing the multi-indicator joint prediction model based on the feedback information.

[0005] Optionally, in a first implementation method of the first aspect of the present invention, the resource indicators and business indicators of the container are collected in real time, and the resource indicators and the business indicators are preprocessed to obtain multi-dimensional indicators, including: collecting the resource indicators of the container in real time through Prometheus, and the resource indicators include CPU utilization, memory usage and network bandwidth occupancy; collecting the business indicators of the container in real time through SkyWalking, and the business indicators include query rate per second, response time quantile and order volume; merging the resource indicators and the business indicators to obtain the original indicators; setting the window duration according to the business cycle characteristics, and performing sliding window normalization processing on the original indicators; using the DBSCAN density clustering algorithm to identify and eliminate outliers of the merged indicators to obtain multi-dimensional indicators.

[0006] Optionally, in a second implementation method of the first aspect of the present invention, the multi-dimensional indicators are input into a preset multi-indicator joint prediction model, and the multi-indicator joint prediction model is used to predict resource requirements within a certain period of time in the future, including: using the LSTM time series prediction layer and the Attention mechanism to fuse a multi-indicator joint prediction model; inputting the multi-dimensional indicators into the multi-indicator joint prediction model to extract time series features; calculating the dynamic weight relationship between the business indicators and the resource indicators in the multi-dimensional indicators through the multi-indicator joint prediction model; and outputting resource requirements within a certain period of time in the future based on the time series features and the dynamic weight relationship, wherein the resource requirements include the required number of CPU cores, memory size, and replica number baseline.

[0007] Optionally, in a third implementation of the first aspect of the present invention, differentiated business priority weights are assigned to different business services, and the number of Deployment replicas is dynamically adjusted based on the resource requirements and the business priority weights, including: defining business priority weights according to the SLA agreement, performing weighted calculation on the resource requirements based on the business priority weights to obtain weighted resource requirements; when the weighted resource requirements exceed the preset safety factor of the current replica carrying capacity, expansion is triggered, and a packing algorithm is used to allocate replicas during expansion; when multiple consecutive weighted resource requirements are lower than the preset demand threshold and there are no abnormal alarms, progressive scaling is triggered, and during scaling, replicas are gradually reduced from low to high priority.

[0008] Optionally, in a fourth implementation of the first aspect of the present invention, the scaling adjustment information is generated based on the change in the number of Deployment replicas, and the operating status of the scaling adjustment information is monitored in real time to obtain monitoring information, including: generating the scaling adjustment information based on the change in the number of Deployment replicas; monitoring the Pod startup success rate in the scaling adjustment information through Kube-state-metrics, and if the success rate is less than a preset success rate threshold within a certain period of time, it is marked as abnormal; detecting the resource allocation status of the new replica in the scaling adjustment information in real time through cAdvisor, and if the CPU utilization is less than the preset utilization threshold for a certain period of time and the query rate per second is zero, it is marked as abnormal; monitoring the marked information in real time to obtain monitoring information.

[0009] Optionally, in the fifth implementation method of the first aspect of the present invention, when the monitoring information is abnormal, the rollback strategy is executed and abnormal feedback information is generated, and the multi-indicator joint prediction model is optimized according to the feedback information, including: when the monitoring information is abnormal, it is automatically restored to the replica number configuration of the previous stable version, and abnormal feedback information is generated, the abnormal feedback information includes the abnormal type code, occurrence time, associated indicator snapshot and configuration comparison before and after rollback; an abnormal sample training data set is generated according to the abnormal feedback information; and the multi-indicator joint prediction model is optimized according to the abnormal sample training data set.

[0010] Optionally, in a sixth implementation manner of the first aspect of the present invention, when the monitoring information is abnormal, a rollback strategy is executed and abnormal feedback information is generated. After optimizing the multi-indicator joint prediction model according to the feedback information, it also includes: generating a scaling operation analysis report, the scaling operation analysis report including prediction accuracy, resource saving rate and abnormal event statistics; storing the scaling operation analysis report through the ELK architecture, and creating a report retrieval interface in the ELK architecture; regularly performing stress testing, and injecting simulated traffic to verify the robustness of the multi-indicator joint prediction model.

[0011] The second aspect of the present invention provides an elastic scaling device for a container orchestration platform, comprising: a collection and processing module for collecting resource indicators and business indicators of containers in real time, pre-processing the resource indicators and business indicators to obtain multi-dimensional indicators; an input prediction module for inputting the multi-dimensional indicators into a preset multi-indicator joint prediction model, and using the multi-indicator joint prediction model to predict resource requirements within a certain period of time in the future; an allocation and adjustment module for allocating differentiated business priority weights to different business services, and dynamically adjusting the number of Deployment copies based on the resource requirements and the business priority weights; a generation monitoring module for generating scaling adjustment information based on changes in the number of Deployment copies, and monitoring the operating status of the scaling adjustment information in real time to obtain monitoring information; a generation optimization module for executing a rollback strategy and generating abnormal feedback information when the monitoring information is abnormal, and optimizing the multi-indicator joint prediction model according to the feedback information.

[0012] Optionally, in a first implementation method of the second aspect of the present invention, the collection and processing module includes: a first collection unit, used to collect the resource indicators of the container in real time through Prometheus, and the resource indicators include CPU utilization, memory usage and network bandwidth occupancy; a second collection unit, used to collect the business indicators of the container in real time through SkyWalking, and the business indicators include query rate per second, response time quantile and order volume; a merging unit, used to merge the resource indicators and the business indicators to obtain the original indicators; a setting processing unit, used to set the window duration according to the business cycle characteristics, and perform sliding window normalization processing on the original indicators; an identification and elimination unit, used to use the DBSCAN density clustering algorithm to identify and eliminate outliers of the merged indicators to obtain multi-dimensional indicators.

[0013] Optionally, in a second implementation of the second aspect of the present invention, the input prediction module includes: a construction unit for constructing a multi-indicator joint prediction model by integrating the LSTM time series prediction layer and the Attention mechanism; an input extraction unit for inputting the multi-dimensional indicators into the multi-indicator joint prediction model to extract time series features; a calculation unit for calculating the dynamic weight relationship between the business indicators and the resource indicators in the multi-dimensional indicators through the multi-indicator joint prediction model; and an output unit for outputting resource requirements within a certain period of time in the future based on the time series features and the dynamic weight relationship, wherein the resource requirements include the required number of CPU cores, memory size, and replica number baseline.

[0014] Optionally, in a third implementation of the second aspect of the present invention, the allocation adjustment module includes: a definition calculation unit, used to define the business priority weight according to the SLA agreement, and perform weighted calculation on the resource demand based on the business priority weight to obtain a weighted resource demand; a first trigger unit, used to trigger capacity expansion when the weighted resource demand exceeds the preset safety factor of the current replica carrying capacity, and a packing algorithm is used to allocate replicas during capacity expansion; a second trigger unit, used to trigger progressive capacity reduction when multiple consecutive weighted resource demands are lower than a preset demand threshold and there is no abnormal alarm, and when reducing capacity, the replicas are gradually reduced from low to high according to priority.

[0015] Optionally, in a fourth implementation of the second aspect of the present invention, the generation monitoring module includes: a first generation unit, used to generate scaling adjustment information based on changes in the number of Deployment replicas; a monitoring marking unit, used to monitor the Pod startup success rate in the scaling adjustment information through Kube-state-metrics, if the success rate is less than a preset success rate threshold within a certain period of time, it is marked as abnormal; a detection marking unit, used to detect the resource allocation status of the new replica in the scaling adjustment information in real time through cAdvisor, if the CPU utilization is less than the preset utilization threshold for a certain period of time and the query rate per second is zero, it is marked as abnormal; a monitoring unit, used to monitor the marking information in real time to obtain monitoring information.

[0016] Optionally, in a fifth implementation of the second aspect of the present invention, the generation optimization module includes: a recovery generation unit, which is used to automatically restore to the replica number configuration of the previous stable version when the monitoring information is abnormal, and generate abnormal feedback information, wherein the abnormal feedback information includes the abnormal type code, occurrence time, associated indicator snapshot and configuration comparison before and after rollback; a second generation unit, which is used to generate an abnormal sample training data set based on the abnormal feedback information; and an optimization unit, which is used to optimize the multi-indicator joint prediction model based on the abnormal sample training data set.

[0017] Optionally, in the sixth implementation method of the second aspect of the present invention, it also includes: a generation module for generating a scaling operation analysis report, the scaling operation analysis report including prediction accuracy, resource saving rate and abnormal event statistics; a storage creation module for storing the scaling operation analysis report through the ELK architecture, and creating a report retrieval interface in the ELK architecture; an execution verification module for regularly performing stress testing and injecting simulated traffic to verify the robustness of the multi-indicator joint prediction model.

[0018] A third aspect of the present invention provides a container orchestration platform elastic scaling device, comprising: a memory and at least one processor, wherein the memory stores instructions; at least one processor calls the instructions in the memory to enable the container orchestration platform elastic scaling device to execute each step of any of the above-mentioned container orchestration platform elastic scaling methods.

[0019] A fourth aspect of the present invention provides a computer-readable storage medium having instructions stored thereon, which, when executed by a processor, implement the various steps of any of the above-mentioned methods for elastically scaling a container orchestration platform.

[0020] In the technical solution of the present invention, by collecting the resource indicators and business indicators of the container in real time, the business indicators and system indicators are jointly modeled to solve the problem of insufficient business perception of traditional HPA, the multi-dimensional indicators are input into a preset multi-indicator joint prediction model, and the multi-indicator joint prediction model is used to predict the resource demand in a certain period of time in the future, and differentiated business priority weights are assigned to different business services. The number of Deployment copies is dynamically adjusted based on the resource demand and the business priority weights, and scaling adjustment information is generated based on the change in the number of Deployment copies to improve the response effect to sudden traffic. The operating status of the scaling adjustment information is monitored in real time. When the monitoring information is abnormal, the rollback strategy is executed and abnormal feedback information is generated. The multi-indicator joint prediction model is optimized according to the feedback information, and the response is rapid to meet the scaling needs of delay-sensitive application containers. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 A first flow chart of the method for elastically scaling a container orchestration platform provided by an embodiment of the present invention;

[0022] Figure 2 A second flow chart of the method for elastically scaling a container orchestration platform provided in an embodiment of the present invention;

[0023] Figure 3 A third flow chart of the method for elastically scaling a container orchestration platform provided in an embodiment of the present invention;

[0024] Figure 4 A fourth flow chart of the method for elastically scaling a container orchestration platform provided in an embodiment of the present invention;

[0025] Figure 5 A schematic diagram of the structure of a container orchestration platform elastic expansion and contraction device provided by an embodiment of the present invention;

[0026] Figure 6Another structural diagram of the elastic expansion and contraction device for the container orchestration platform provided by an embodiment of the present invention;

[0027] Figure 7 This is a schematic diagram of the structure of the elastic scaling device for the container orchestration platform provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0028] The present invention provides a method, apparatus, device and storage medium for elastic scaling of a container orchestration platform, which responds quickly and meets the scaling requirements of delay-sensitive application containers. It jointly models business indicators and system indicators to solve the problem of insufficient business perception of traditional HPA. It can configure weights according to business priorities and dynamically adjust the number of Deployment copies based on predicted resource requirements and weights, thereby improving the response effect to sudden traffic.

[0029] The terms "first," "second," "third," "fourth," and the like (if any) in the description and claims of the present invention and in the accompanying drawings are used to distinguish similar objects and are not necessarily used to describe a particular order or precedence. It should be understood that the terms used in this manner are interchangeable where appropriate so that the embodiments described herein can be implemented in an order other than that illustrated or described herein. In addition, the terms "including" or "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units that are not explicitly listed or that are inherent to these processes, methods, products, or apparatus.

[0030] For ease of understanding, the specific process of the embodiment of the present invention is described below. Figure 1 An embodiment of a method for elastically scaling a container orchestration platform according to an embodiment of the present invention includes:

[0031] 101. Collect resource indicators and business indicators of containers in real time, pre-process the resource indicators and business indicators to obtain multi-dimensional indicators;

[0032] In this embodiment, the Prometheus monitoring system is integrated to capture container-level resource indicators such as CPU utilization, memory usage, network I / O in real time. At the same time, APM (application performance management) tools such as SkyWalking are integrated to collect indicators closely related to business logic in real time, such as business indicators such as QPS (query rate per second), response time, and order processing rate of specific services. The collected raw indicator data will be merged and aligned with the timestamp, and the sliding window size will be set based on the business periodicity (such as daily / weekly peaks and troughs), and standardized processing (such as Z-score standardization) will be performed. Finally, the DBSCAN density clustering algorithm is used to identify and remove outliers (such as instantaneous glitches) to form high-quality, multi-dimensional time series indicator data.

[0033] 102. Input the multi-dimensional indicators into the preset multi-indicator joint prediction model, and use the multi-indicator joint prediction model to predict resource demand within a certain period of time in the future;

[0034] In this embodiment, the multi-indicator joint prediction model adopts a deep learning architecture. The core is the LSTM (long short-term memory) network layer for capturing the long-term and short-term temporal dependencies of indicators, and integrating the Attention mechanism. The Attention mechanism can dynamically calculate the association weights between different indicators at different times, and identify the key feature points that have the greatest impact on resource demand prediction. The model input is the preprocessed multi-dimensional indicator historical sequence. The time series features are extracted through LSTM, and the Attention layer calculates the feature weights. Finally, the predicted resource demand value for a specified time window in the future (such as 5 minutes below) is output, including the required number of CPU cores, memory size, and estimated replica number baseline.

[0035] 103. Assign differentiated business priority weights to different business services, and dynamically adjust the number of Deployment replicas based on resource requirements and business priority weights;

[0036] In this embodiment, service priority weights are predefined based on a service level agreement (SLA). For example, a core payment service weight is 1.0, and a reporting service weight is 0.7. The predicted resource demand (e.g., the baseline number of required replicas) is multiplied by the corresponding service priority weight to obtain a weighted resource demand. When the weighted resource demand exceeds the current replica capacity multiplied by a preset safety factor (e.g., 120%), a capacity expansion operation is triggered. This capacity expansion utilizes a bin-packing algorithm similar to the Kubernetes scheduler to efficiently allocate new replicas to appropriate nodes while satisfying node resource constraints. When the weighted resource demand for multiple consecutive prediction cycles (e.g., three cycles) is below a preset demand threshold (e.g., 70% of the current replica capacity) and the system has no abnormal alarms, a progressive capacity reduction is triggered. The number of replicas is gradually reduced based on service priority, from low to high (e.g., reducing reporting service replicas first). The reduction ratio is limited each time (e.g., no more than 20% of the current number of replicas) to prevent excessive capacity reduction from impacting services.

[0037] 104. Generate scaling adjustment information based on the change in the number of Deployment replicas, monitor the operational status of the scaling adjustment information in real time, and obtain monitoring information.

[0038] In this embodiment, when it is decided to adjust the number of replicas (expand or shrink), an expansion or shrink adjustment instruction containing information such as the target number of replicas, the services involved, and the reason for the adjustment will be generated. The system monitors the startup status of the new Pod by integrating Kube-state-metrics. If the Pod startup success rate is lower than the preset threshold (such as 90%) within the specified time window (such as 2 minutes), the adjustment operation is marked as abnormal. At the same time, cAdvisor is used to monitor the resource allocation and actual load of the newly started Pod in real time. If the CPU utilization of the new Pod is lower than the extremely low threshold (such as 5%) for a period of time (such as 1 minute) and the QPS it processes is zero (indicating that there is no real traffic access), it is also marked as abnormal. The system continuously aggregates these marking information to form a real-time monitoring information flow.

[0039] 105. When the monitoring information is abnormal, the rollback strategy is executed and abnormal feedback information is generated. The multi-indicator joint prediction model is optimized based on the feedback information;

[0040] In this embodiment, once the monitoring information detects an anomaly (such as Pod startup failure or new replica no load), the system immediately and automatically executes the rollback strategy, rolling back the number of Deployment replicas to the configuration of the previous known stable version. At the same time, detailed exception feedback information is generated, including the exception type code, occurrence timestamp, associated real-time resource and business indicator snapshots, and configuration difference comparison before and after the rollback. These exception feedback information will be organized into structured exception samples and added to the model's training data set. Subsequently, these new samples containing failure scenarios are used to incrementally train or fine-tune the multi-indicator joint prediction model to optimize the model's prediction accuracy and robustness, especially its performance in boundary or abnormal situations.

[0041] In an embodiment of the present invention, by collecting the resource indicators and business indicators of the container in real time, the business indicators and system indicators are jointly modeled to solve the problem of insufficient business perception of traditional HPA, the multi-dimensional indicators are input into a preset multi-indicator joint prediction model, and the multi-indicator joint prediction model is used to predict the resource demand in a certain period of time in the future, and differentiated business priority weights are assigned to different business services. The number of Deployment copies is dynamically adjusted based on resource demand and business priority weights, and scaling adjustment information is generated based on changes in the number of Deployment copies to improve the response effect to sudden traffic. The operating status of the scaling adjustment information is monitored in real time. When the monitoring information is abnormal, the rollback strategy is executed and abnormal feedback information is generated. The multi-indicator joint prediction model is optimized according to the feedback information, and the response is rapid to meet the scaling needs of delay-sensitive application containers.

[0042] See also Figure 2 A second embodiment of the method for elastically scaling a container orchestration platform according to an embodiment of the present invention includes:

[0043] 201. Use Prometheus to collect container resource indicators in real time, including CPU utilization, memory usage, and network bandwidth usage;

[0044] In this embodiment, Prometheus is configured with a ServiceMonitor or PodMonitor for the target Kubernetes cluster, and captures the metrics exposed by cAdvisor of each container at a fixed collection interval (such as 15 seconds) to calculate the real-time CPU utilization, memory usage, and network receiving or sending bandwidth occupancy.

[0045] 202. SkyWalking is used to collect real-time business metrics of containers, including query rate per second, response time quantile, and order volume.

[0046] In this embodiment, SkyWalking's Agent or Service Mesh probe is deployed in the application container, intercepting and analyzing application traffic, and reporting business indicators such as the number of calls to a specific API interface (converted to QPS), response time distribution, and counts of key business events (such as "order created successfully") (converted to order volume) to SkyWalking OAPServer in real time.

[0047] 203. Combine the resource indicators and the business indicators to obtain the original indicators;

[0048] In this embodiment, a unified time series database or stream processing pipeline is established to associate and merge resource indicators from Prometheus and business indicators from SkyWalking based on precise timestamps and labels to form an original indicator dataset containing multi-dimensional labels.

[0049] 204. Set the window duration according to the business cycle characteristics and perform sliding window standardization on the original indicators;

[0050] In this embodiment, historical business load patterns (such as e-commerce daytime peaks and nighttime troughs) are analyzed to determine the sliding window size (such as 5 minutes). During stream processing, the original indicator values ​​within each window (such as CPU and QPS) are Z-score normalized to eliminate the impact of different indicator dimensions and baseline differences, making them more suitable for model input.

[0051] 205. Use the DBSCAN density clustering algorithm to identify and eliminate outliers in the combined indicators to obtain multi-dimensional indicators;

[0052] In this embodiment, the standardized multidimensional indicators are used as feature vectors, and the DBSCAN algorithm is applied. The appropriate neighborhood radius and minimum number of points are set, and the indicator vector of each time point is clustered and analyzed. Points that fall outside the neighborhood of any core object or in small clusters are identified as outliers (such as instantaneous traffic spikes and collection failures). These outliers are removed or replaced by interpolation of normal points before and after them. Finally, a cleaned multidimensional indicator time series reflecting the actual load trend is output.

[0053] 206. Utilize the LSTM time series prediction layer and the Attention mechanism to build a multi-indicator joint prediction model;

[0054] In this embodiment, the model architecture includes an input layer that receives a standardized multi-dimensional indicator sequence, a multi-layer stacked LSTM unit for learning the long-term and short-term dependency patterns of the historical sequence, an Attention layer that calculates the contribution weights of different time steps in the historical sequence to the current prediction moment, and pays special attention to the impact weights of sudden changes in business indicators (such as QPS surges) on resource indicators (such as CPU), and a fully connected layer that aggregates LSTM outputs and Attention weights to generate predicted values ​​for future resource requirements (number of CPU cores, memory size, and baseline number of replicas).

[0055] 207. Input multi-dimensional indicators into the multi-indicator joint prediction model to extract time series features;

[0056] In this embodiment, the preprocessed, chronologically arranged multi-dimensional indicator matrix is ​​input into the constructed model. The LSTM layer processes the input time step by time, and its hidden state captures the sequence feature information up to the time. These hidden state sequences are the key time series features extracted by the model.

[0057] 208. Calculate the dynamic weight relationship between business indicators and resource indicators in multi-dimensional indicators through a multi-indicator joint prediction model;

[0058] In this embodiment, the Attention mechanism acts on the hidden state sequence output by the LSTM. It calculates the correlation score between the hidden state at each historical moment and the context vector at the current prediction moment (usually through dot products or a small neural network), and then applies the Softmax function to convert these scores into weights. These weights intuitively reflect the dynamic importance or influence of different historical moments and the various indicators contained in the moment (especially business indicators such as high QPS moments) on the current predicted resource demand.

[0059] 209. Output resource requirements for a certain period of time in the future based on time series characteristics and dynamic weight relationships. Resource requirements include the required number of CPU cores, memory size, and the baseline number of replicas.

[0060] In this embodiment, the weights calculated by the Attention layer are weighted and summed with the corresponding LSTM hidden states to obtain a context vector containing key timing information and dynamic weights. This vector is input into the subsequent fully connected layer (regression layer). The fully connected layer outputs specific prediction values, including the predicted number of CPU core requirements (normalized and denormalized), the predicted memory requirement size, and the recommended baseline value of the number of replicas calculated based on the resource requirement prediction value and the single-copy resource specifications.

[0061] In the embodiment of the present invention, Prometheus and SkyWalking are used to achieve efficient collection and integration of resource and business indicators, combined with sliding window normalization to eliminate dimensional differences, and the DBSCAN algorithm is used to accurately eliminate outliers to form high-quality multi-dimensional indicators. An innovative multi-indicator joint prediction model that integrates LSTM time series prediction and Attention mechanism is constructed. The long-term and short-term time series dependency features of multi-dimensional indicators are effectively extracted through the LSTM layer, and the Attention mechanism is used to dynamically calculate the influence weight of each indicator at a historical moment (especially the sudden change of business indicators) on the current prediction. The weight relationship between business indicators (such as QPS) and resource indicators (such as CPU) is dynamically captured, and the future resource demand baseline (CPU, memory, number of replicas) is accurately output, laying the data and model foundation for intelligent scaling.

[0062] See also Figure 3 A third embodiment of the method for elastically scaling a container orchestration platform according to the present invention includes:

[0063] 301. Define business priority weights according to the SLA agreement, perform weighted calculation on resource requirements based on the business priority weights, and obtain weighted resource requirements;

[0064] In this embodiment, the business priority weight is pre-set for each microservice or deployment in the system configuration. For example, the weight of the core transaction service is 1.0, and the weight of the background analysis service is 0.6. For the resource requirements output by the prediction model, its weighted resource requirements are calculated.

[0065] 302. When the weighted resource demand exceeds the preset safety factor of the current replica carrying capacity, expansion is triggered, and the packing algorithm is used to allocate replicas during expansion;

[0066] In this embodiment, capacity expansion is triggered when the weighted resource demand exceeds the preset safety factor of the current replica carrying capacity. During capacity expansion, the system calculates the number of new replicas that need to be added, and then uses the packing algorithm to consider the remaining CPU, memory resources, and anti-affinity constraints of the cluster nodes to schedule each new replica to the most suitable node, maximize resource utilization and meet scheduling constraints.

[0067] 303. When multiple consecutive weighted resource demands are lower than the preset demand threshold and there are no abnormal alarms, progressive scaling is triggered. During scaling, replicas are gradually reduced from low to high priority.

[0068] In this embodiment, a demand threshold is set, and the system continuously checks the weighted resource demand of the most recent K prediction cycles (such as K = 3 cycles, each cycle is 5 minutes). If the weighted resource demand for K consecutive cycles is lower than the demand threshold, and the system monitoring (such as Pod status, node status) does not trigger any abnormal alarm during this period, then scaling down is triggered. The scaling down is not completed all at once, but adopts a progressive strategy. First, the service instance with the lowest business priority weight among the currently running services is identified, and then its number of replicas is proportionally reduced. After the reduction, it is observed for a period of time (such as 1-2 cycles). After confirming that the system is stable and there are no abnormalities, if the load is still low, services are selected from low to high priority for the next round of scaling down until the overall load approaches the target threshold.

[0069] 304. Generate scaling adjustment information based on the change in the number of Deployment replicas;

[0070] In this embodiment, when the system decides to perform an expansion or reduction operation, a structured expansion or reduction adjustment instruction object is generated, which includes the target Deployment name, Namespace, current number of replicas, target number of replicas, operation type, trigger reason, associated predicted load value, timestamp, operation ID, etc.

[0071] 305. Use Kube-state-metrics to monitor the Pod startup success rate in the scaling adjustment information. If the success rate is lower than the preset success rate threshold within a certain period of time, it is marked as abnormal.

[0072] In this embodiment, the system tracks the status of all new Pods triggered by scaling operations by monitoring the indicators exposed by Kube-state-metrics, sets a time window, and calculates the proportion of new Pods reaching the Ready state (success rate) within this window. If the success rate is lower than the preset threshold, the scaling operation is considered abnormal (such as insufficient resources, image pull failure, health check failure), and the operation is marked as abnormal, and the specific failed Pod information is recorded.

[0073] 306. Use cAdvisor to monitor the resource allocation status of the new replica in the scaling adjustment information in real time. If the CPU utilization is less than the preset utilization threshold and the query rate per second is zero for a certain period of time, it is marked as abnormal.

[0074] In this embodiment, for the new Pod started by the expansion operation, the system obtains its container-level resource usage indicators in real time through cAdvisor and sets an observation time window. If the new Pod continues to meet the average CPU utilization below an extremely low threshold within the observation time window, and the QPS it processes continues to be zero, it is determined that the new replica may not be correctly connected to the traffic (such as service discovery delay, load balancing configuration problem), or the application itself failed to start but did not exit, and this new Pod is marked as abnormal, and the expansion operation is marked as having some abnormalities.

[0075] 307. Monitor the marked information in real time to obtain monitoring information;

[0076] In this embodiment, the system establishes a real-time monitoring stream to continuously collect and aggregate abnormal marking information. This abnormal marking information includes operation ID, abnormality type (Pod startup failure or low utilization and zero traffic), occurrence time, involved Deployment or Pod, specific error indicator value, etc. This information is processed and associated in real time (associated with the original scaling adjustment information) to form a structured monitoring information stream for subsequent abnormality judgment and automatic rollback.

[0077] In an embodiment of the present invention, differentiated priority weights are configured for different business services based on the SLA agreement, and weighted calculation is performed on the predicted resource demand. When the weighted demand exceeds the safety factor of the current carrying capacity, a packing algorithm is used to trigger efficient capacity expansion. When the demand is continuously lower than the threshold and there is no alarm, gradual capacity reduction is implemented from low to high according to the business priority, thereby ensuring the stability of core services while achieving refined resource scheduling and effectively responding to traffic fluctuations.

[0078] See also Figure 4 The fourth embodiment of the method for elastically scaling a container orchestration platform according to the present invention includes:

[0079] 401. When the monitoring information is abnormal, the replica number configuration of the previous stable version is automatically restored and abnormal feedback information is generated. The abnormal feedback information includes the abnormal type code, occurrence time, related indicator snapshots, and configuration comparison before and after rollback;

[0080] In this embodiment, once the monitoring information flow detects that the scaling operation is marked as abnormal, the system immediately triggers the automatic rollback process and rolls back to the number of replicas configured before this operation. At the same time, a detailed exception feedback record is generated. The exception feedback record includes the exception type code, the exact timestamp of the exception, the real-time resource and business indicator snapshot associated with the exception when the exception occurred, the number of replicas before the rollback, the target number of replicas, the number of replicas after the rollback, and other configuration comparison information.

[0081] 402. Generate an abnormal sample training data set based on the abnormal feedback information;

[0082] In this embodiment, each abnormal feedback record generated is combined with the original input indicator sequence that triggered the scaling operation (i.e., the historical load data that caused the prediction model to make the prediction decision), and the monitoring data during the operation execution (such as Pod event logs), to form a structured abnormal sample. The abnormal sample includes input features (historical multi-dimensional indicators), model prediction output (predicted resource requirements or target number of replicas), actual execution results (abnormality type and details), and environmental context (such as cluster load, node status snapshot). All abnormal samples are added to a training data set specifically for model optimization.

[0083] 403. Optimize the multi-indicator joint prediction model based on the abnormal sample training data set;

[0084] In this embodiment, the multi-indicator joint prediction model is retrained or incrementally trained using a mixed data set containing normal samples and newly added abnormal samples periodically (such as daily or weekly) or after accumulating a sufficient number of new abnormal samples. The training process is intended to enable the model to learn patterns that lead to prediction errors or abnormal operations (such as specific load mutation patterns, resource contention scenarios), and adjust model parameters (LSTM weights, Attention weights, fully connected layer weights) to improve the model's prediction accuracy and robustness when facing similar scenarios in the future, and reduce abnormal scaling operations caused by inaccurate predictions.

[0085] 404. Generate a scaling operation analysis report, which includes prediction accuracy, resource saving rate, and abnormal event statistics;

[0086] In this embodiment, the system generates a scaling operation analysis report periodically (such as every hour or every day). The core indicators of the report include prediction accuracy, resource saving rate, number of successful scaling operations, number and type distribution of operations that trigger abnormal rollbacks, average scaling or scaling delay time, model version information, etc. The report provides a comprehensive view of system performance, resource efficiency and security.

[0087] 405. Use the ELK architecture to store scaling analysis reports and create a report retrieval interface in the ELK architecture.

[0088] In this embodiment, the generated scaling operation analysis report is indexed and stored in Elasticsearch, and Kibana is used to build a visual dashboard and report retrieval interface on the ELK architecture. Users can use this interface to flexibly query historical reports by time range, service name, operation type and other conditions, and view trend charts (such as accuracy change curves, resource savings bar charts), abnormal event lists and detailed report content.

[0089] 406. Perform stress tests regularly and inject simulated traffic to verify the robustness of the multi-indicator joint prediction model;

[0090] In this embodiment, in order to continuously verify and improve the performance of the system in extreme or emergency scenarios, stress testing is performed regularly (such as weekly or monthly) in a test environment or isolated production replica. Tools are used to inject simulated traffic into the target service and construct various load patterns (such as instantaneous peaks, slow climbs, and periodic pulses). During this process, the prediction accuracy of the multi-indicator joint prediction model for the simulated load, the timeliness of the response of the scaling strategy (especially the scaling speed and magnitude), and the overall stability of the system (whether unnecessary abnormal rollbacks are triggered) are monitored and evaluated. The test results are used to further calibrate the model parameters, adjust policy parameters such as safety factors or demand thresholds, and enhance the robustness of the model and system.

[0091] In an embodiment of the present invention, an automatic rollback mechanism is used to quickly restore abnormal operations to a stable state, and detailed feedback information including abnormality type, indicator snapshot, and configuration comparison is generated. Based on the feedback, an abnormal sample data set is constructed, and the multi-indicator joint prediction model is continuously optimized to improve its robustness in boundary scenarios. Analysis reports covering prediction accuracy and resource saving rate are regularly generated, and the ELK architecture is used to achieve visual retrieval. Combined with stress testing and simulated traffic injection, the robustness of the model and strategy is systematically verified to form a closed-loop optimization system.

[0092] The above describes the elastic expansion and contraction method of the container orchestration platform in the embodiment of the present invention. The following describes the elastic expansion and contraction device of the container orchestration platform in the embodiment of the present invention. Figure 5 In one embodiment of the present invention, an embodiment of a container orchestration platform elastic expansion and contraction device includes:

[0093] The collection and processing module 501 is used to collect resource indicators and business indicators of the container in real time, pre-process the resource indicators and business indicators, and obtain multi-dimensional indicators;

[0094] Input prediction module 502, used to input multi-dimensional indicators into a preset multi-indicator joint prediction model, and use the multi-indicator joint prediction model to predict resource demand within a certain period of time in the future;

[0095] Allocation adjustment module 503, used to assign differentiated business priority weights to different business services and dynamically adjust the number of Deployment replicas based on resource requirements and business priority weights;

[0096] Generate monitoring module 504, which is used to generate scaling adjustment information based on the change in the number of Deployment replicas, and monitor the operating status of the scaling adjustment information in real time to obtain monitoring information;

[0097] The generation optimization module 505 is used to execute the rollback strategy and generate abnormal feedback information when the monitoring information is abnormal, and optimize the multi-indicator joint prediction model according to the feedback information.

[0098] In this embodiment, by collecting the resource indicators and business indicators of the container in real time, the business indicators and system indicators are jointly modeled to solve the problem of insufficient business perception of traditional HPA, the multi-dimensional indicators are input into a preset multi-indicator joint prediction model, and the multi-indicator joint prediction model is used to predict the resource demand in a certain period of time in the future, and differentiated business priority weights are assigned to different business services. The number of Deployment copies is dynamically adjusted based on the resource demand and the business priority weights, and scaling adjustment information is generated based on the change in the number of Deployment copies to improve the response effect to sudden traffic. The operating status of the scaling adjustment information is monitored in real time. When the monitoring information is abnormal, the rollback strategy is executed and abnormal feedback information is generated. The multi-indicator joint prediction model is optimized according to the feedback information, and the response is rapid to meet the scaling needs of delay-sensitive application containers.

[0099] See also Figure 6 Another embodiment of the container orchestration platform elastic expansion and contraction device according to the embodiment of the present invention includes:

[0100] The collection and processing module 501 is used to collect resource indicators and business indicators of the container in real time, pre-process the resource indicators and business indicators, and obtain multi-dimensional indicators;

[0101] Input prediction module 502, used to input multi-dimensional indicators into a preset multi-indicator joint prediction model, and use the multi-indicator joint prediction model to predict resource demand within a certain period of time in the future;

[0102] Allocation adjustment module 503, used to assign differentiated business priority weights to different business services and dynamically adjust the number of Deployment replicas based on resource requirements and business priority weights;

[0103] Generate monitoring module 504, which is used to generate scaling adjustment information based on the change in the number of Deployment replicas, and monitor the operating status of the scaling adjustment information in real time to obtain monitoring information;

[0104] Generate an optimization module 505, which is used to execute a rollback strategy and generate abnormal feedback information when the monitoring information is abnormal, and optimize the multi-indicator joint prediction model according to the feedback information;

[0105] In this embodiment, the collection and processing module 501 includes: a first collection unit 5011, which is used to collect the resource indicators of the container in real time through Prometheus. The resource indicators include CPU utilization, memory usage and network bandwidth occupancy; a second collection unit 5012, which is used to collect the business indicators of the container in real time through SkyWalking. The business indicators include query rate per second, response time quantile and order volume; a merging unit 5013, which is used to merge the resource indicators and business indicators to obtain the original indicators; a setting processing unit 5014, which is used to set the window duration according to the business cycle characteristics and perform sliding window normalization processing on the original indicators; an identification and elimination unit 5015, which is used to use the DBSCAN density clustering algorithm to identify and eliminate outliers of the merged indicators to obtain multi-dimensional indicators.

[0106] In this embodiment, the input prediction module 502 includes: a construction unit 5021, which is used to use the LSTM time series prediction layer and the Attention mechanism to fuse to construct a multi-indicator joint prediction model; an input extraction unit 5022, which is used to input the multi-dimensional indicators into the multi-indicator joint prediction model to extract time series features; a calculation unit 5023, which is used to calculate the dynamic weight relationship between the business indicators and the resource indicators in the multi-dimensional indicators through the multi-indicator joint prediction model; an output unit 5024, which is used to output the resource requirements within a certain period of time in the future based on the time series features and the dynamic weight relationship. The resource requirements include the required number of CPU cores, memory size and replica number baseline.

[0107] In this embodiment, the allocation adjustment module 503 includes: a definition calculation unit 5031, which is used to define the business priority weight according to the SLA agreement, and perform weighted calculation on the resource demand based on the business priority weight to obtain the weighted resource demand; a first trigger unit 5032, which is used to trigger capacity expansion when the weighted resource demand exceeds the preset safety factor of the current replica carrying capacity, and a packing algorithm is used to allocate replicas during capacity expansion; a second trigger unit 5033, which is used to trigger progressive capacity reduction when multiple consecutive weighted resource demands are lower than the preset demand threshold and there is no abnormal alarm, and when reducing capacity, the replicas are gradually reduced from low to high priority.

[0108] In this embodiment, the generation monitoring module 504 includes: a first generation unit 5041, which is used to generate scaling adjustment information based on changes in the number of Deployment replicas; a monitoring marking unit 5042, which is used to monitor the Pod startup success rate in the scaling adjustment information through Kube-state-metrics. If the success rate is less than a preset success rate threshold within a certain period of time, it is marked as abnormal; a detection marking unit 5043, which is used to detect the resource allocation status of the new replica in the scaling adjustment information in real time through cAdvisor. If the CPU utilization is less than the preset utilization threshold for a certain period of time and the query rate per second is zero, it is marked as abnormal; a monitoring unit 5044, which is used to monitor the marking information in real time to obtain monitoring information.

[0109] In this embodiment, the generation optimization module 505 includes: a recovery generation unit 5051, which is used to automatically restore to the replica number configuration of the previous stable version when the monitoring information is abnormal, and generate abnormal feedback information, the abnormal feedback information including the abnormal type code, occurrence time, associated indicator snapshot and configuration comparison before and after rollback; a second generation unit 5052, which is used to generate an abnormal sample training data set based on the abnormal feedback information; an optimization unit 5053, which is used to optimize the multi-indicator joint prediction model based on the abnormal sample training data set.

[0110] In this embodiment, it also includes: a generation module 506 for generating a scaling operation analysis report, which includes prediction accuracy, resource saving rate and abnormal event statistics; a storage creation module 507 for storing the scaling operation analysis report through the ELK architecture and creating a report retrieval interface in the ELK architecture; an execution verification module 508 for regularly performing stress testing and injecting simulated traffic to verify the robustness of the multi-indicator joint prediction model.

[0111] above Figure 5 and Figure 6 The elastic scaling device for the container orchestration platform in the embodiment of the present invention is described in detail from the perspective of modular functional entities. The elastic scaling device for the container orchestration platform in the embodiment of the present invention is described in detail from the perspective of hardware processing.

[0112] Figure 7: This is a structural diagram of a container orchestration platform elastic scaling device provided in an embodiment of the present invention. The container orchestration platform elastic scaling device 600 may have relatively large differences due to different configurations or performance, and may include one or more processors (central processing units, CPU) 610 (for example, one or more processors) and memory 620, and one or more storage media 630 (for example, one or more mass storage devices) storing application programs 633 or data 632. Among them, the memory 620 and the storage medium 630 can be temporary storage or persistent storage. The program stored in the storage medium 630 may include one or more modules (not shown in the figure), each of which may include a series of instruction operations on the container orchestration platform elastic scaling device 600. Furthermore, the processor 610 can be configured to communicate with the storage medium 630 and execute a series of instruction operations in the storage medium 630 on the container orchestration platform elastic scaling device 600 to implement the steps of the container orchestration platform elastic scaling method provided in the above-mentioned method embodiments.

[0113] The container orchestration platform elastic expansion and contraction device 600 may also include one or more power supplies 640, one or more wired or wireless network interfaces 650, one or more input and output interfaces 660, and / or one or more operating systems 631, such as Windows Server, Mac OS X, Unix, Linux, FreeBSD, etc. It will be understood by those skilled in the art that Figure 7 The illustrated structure of the container orchestration platform elastic scaling device does not limit the elastic scaling device based on the container orchestration platform and may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently.

[0114] The present invention also provides a computer-readable storage medium, which may be a non-volatile computer-readable storage medium or a volatile computer-readable storage medium. The computer-readable storage medium stores instructions that, when executed on a computer, cause the computer to execute the steps of a method for elastically scaling a container orchestration platform.

[0115] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the above-described systems, devices, and units can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0116] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), magnetic disk or optical disk, etc., various media that can store program code.

[0117] Finally, it should be noted that the above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art will be able to modify the technical solutions described in the aforementioned embodiments or substitute equivalents for some of the technical features. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention shall be included within the scope of protection of the present invention.

Claims

1. A method for elastically scaling a container orchestration platform, characterized in that: include: Collect resource indicators and business indicators of the container in real time, pre-process the resource indicators and business indicators to obtain multi-dimensional indicators; Input the multi-dimensional indicators into a preset multi-indicator joint prediction model, and use the multi-indicator joint prediction model to predict resource demand within a certain period of time in the future; Assign differentiated business priority weights to different business services, and dynamically adjust the number of Deployment replicas based on the resource requirements and the business priority weights; Generate scaling adjustment information based on the change in the number of Deployment replicas, and monitor the operating status of the scaling adjustment information in real time to obtain monitoring information; When the monitoring information is abnormal, a rollback strategy is executed and abnormal feedback information is generated, and the multi-indicator joint prediction model is optimized according to the feedback information.

2. The method for elastically scaling a container orchestration platform according to claim 1, characterized in that: The real-time collection of resource indicators and business indicators of the container and pre-processing of the resource indicators and business indicators are performed to obtain multi-dimensional indicators, including: Prometheus collects container resource metrics in real time, including CPU utilization, memory usage, and network bandwidth usage. SkyWalking collects real-time container business metrics, including query rate per second, response time quantile, and order volume. Merging the resource indicator and the business indicator to obtain an original indicator; Setting the window duration according to the business cycle characteristics and performing sliding window normalization processing on the original indicators; The DBSCAN density clustering algorithm is used to identify and eliminate outliers of the combined index to obtain a multi-dimensional index.

3. The method for elastically scaling a container orchestration platform according to claim 1, characterized in that: Inputting the multi-dimensional indicators into a preset multi-indicator joint prediction model, and using the multi-indicator joint prediction model to predict resource demand within a certain period of time in the future, includes: Utilize the LSTM time series prediction layer and the Attention mechanism to build a multi-indicator joint prediction model; Inputting the multi-dimensional indicators into the multi-indicator joint prediction model to extract time series features; Calculating the dynamic weight relationship between the business indicator and the resource indicator in the multi-dimensional indicator through the multi-indicator joint prediction model; Output resource requirements within a certain period of time in the future based on the time series characteristics and the dynamic weight relationship, where the resource requirements include the required number of CPU cores, memory size, and a baseline number of replicas.

4. The method for elastically expanding and contracting a container orchestration platform according to claim 1, characterized in that: The step of allocating differentiated business priority weights to different business services and dynamically adjusting the number of Deployment replicas based on the resource requirements and the business priority weights includes: Defining service priority weights according to the SLA agreement, and performing weighted calculation on the resource requirements based on the service priority weights to obtain weighted resource requirements; When the weighted resource demand exceeds the preset safety factor of the current replica carrying capacity, expansion is triggered, and the replicas are allocated using the packing algorithm during expansion; When multiple consecutive weighted resource demands are lower than a preset demand threshold and there is no abnormal alarm, progressive scaling is triggered, and during scaling, replicas are gradually reduced from low to high priority.

5. The method for elastically expanding and contracting a container orchestration platform according to claim 1, characterized in that: Generating the scaling adjustment information based on the change in the number of Deployment replicas, and monitoring the operation status of the scaling adjustment information in real time to obtain monitoring information includes: Generate scaling adjustment information based on the change in the number of Deployment replicas; Use Kube-state-metrics to monitor the Pod startup success rate in the scaling adjustment information. If the success rate is lower than the preset success rate threshold within a certain period of time, it is marked as abnormal. cAdvisor is used to monitor the resource allocation status of the new replica in the scaling adjustment information in real time. If the CPU utilization is less than the preset utilization threshold and the query rate per second is zero for a certain period of time, it is marked as abnormal. The marking information is monitored in real time to obtain monitoring information.

6. The method for elastically scaling a container orchestration platform according to claim 1, characterized in that: When the monitoring information is abnormal, a rollback strategy is executed and abnormal feedback information is generated, and the multi-indicator joint prediction model is optimized according to the feedback information, including: When the monitoring information is abnormal, the replica number configuration of the previous stable version is automatically restored and abnormal feedback information is generated. The abnormal feedback information includes the abnormal type code, occurrence time, related indicator snapshots and configuration comparison before and after rollback; generating an abnormal sample training data set according to the abnormal feedback information; The multi-indicator joint prediction model is optimized according to the abnormal sample training data set.

7. The method for elastically expanding and contracting a container orchestration platform according to claim 1, characterized in that: When the monitoring information is abnormal, a rollback strategy is executed and abnormal feedback information is generated. After optimizing the multi-indicator joint prediction model according to the feedback information, the method further includes: Generate a scaling operation analysis report, the scaling operation analysis report including prediction accuracy, resource saving rate and abnormal event statistics; Storing the scaling operation analysis report through the ELK architecture and creating a report retrieval interface in the ELK architecture; Stress testing is performed regularly, and simulated traffic is injected to verify the robustness of the multi-indicator joint prediction model.

8. A container orchestration platform elastic expansion and contraction device, characterized in that: include: A collection and processing module is used to collect resource indicators and business indicators of the container in real time, pre-process the resource indicators and business indicators, and obtain multi-dimensional indicators; An input prediction module is used to input the multi-dimensional indicators into a preset multi-indicator joint prediction model, and use the multi-indicator joint prediction model to predict resource demand within a certain period of time in the future; An allocation adjustment module, configured to assign differentiated business priority weights to different business services and dynamically adjust the number of Deployment replicas based on the resource requirements and the business priority weights; Generate a monitoring module for generating scaling adjustment information based on the change in the number of Deployment replicas, and monitor the operating status of the scaling adjustment information in real time to obtain monitoring information; Generate an optimization module, which is used to execute a rollback strategy and generate abnormal feedback information when the monitoring information is abnormal, and optimize the multi-indicator joint prediction model according to the feedback information.

9. A container orchestration platform elastic expansion and contraction device, characterized in that: The container orchestration platform elastic expansion and contraction device includes: a memory and at least one processor, wherein the memory stores instructions; At least one of the processors calls the instructions in the memory to enable the container orchestration platform elastic scaling device to perform each step of the container orchestration platform elastic scaling method according to any one of claims 1 to 7.

10. A computer-readable storage medium having instructions stored thereon, characterized in that: When the instructions are executed by the processor, the steps of the method for elastically scaling a container orchestration platform as described in any one of claims 1 to 7 are implemented.

Images