Container automatic expansion and contraction method and system for heterogeneous computing power cluster

Abstract

The application belongs to the technical field of cloud computing and container orchestration, and discloses a container automatic expansion and contraction method and system for a heterogeneous computing power cluster. First, the running indexes of the containers in the heterogeneous computing power cluster are collected, the future load trend is predicted through an LSTM time sequence prediction model, and an expansion and contraction decision is generated according to the computing power density index and the load prediction curve. The computing power density index normalizes the actual computing power output values of different types of general-purpose processors and accelerator cards into standardized densities, thereby providing a unified evaluation basis for the expansion and contraction decision across heterogeneous nodes. When the predicted load exceeds the capacity threshold, expansion is triggered, and when the predicted load continuously falls below the threshold, contraction is triggered, so that the resource adjustment is accurately matched with the business demand. Finally, the hard isolation and elastic control of the container resources are realized through cgroups v2, a unified hierarchical structure is adopted to construct independent resource sub-trees for different priority applications, and the problem of extensive resource isolation is solved.

Description

Technical Field

[0001] This invention belongs to the field of cloud computing and container orchestration technology, specifically a method and system for automatic scaling of containers for heterogeneous computing power clusters. Background Technology

[0002] In current cloud-native container orchestration technologies, orchestration platforms such as Kubernetes are widely used for the automated deployment and management of containerized applications. Automatic scaling is one of the core functions for ensuring stable operation of business workloads. With the advancement of domestically produced computing infrastructure, heterogeneous computing clusters based on ARM architecture general-purpose processors and AI accelerator cards are gradually becoming the computing foundation for critical mission scenarios such as aerospace research, high-performance computing, and large-scale simulation, placing higher demands on the dynamic scheduling and fine-grained management of container resources.

[0003] Existing automatic scaling technologies primarily rely on a passive response strategy based on thresholds. This involves collecting CPU or memory utilization metrics of containers and triggering scaling up when the utilization exceeds a preset threshold and scaling down when it falls below. This mechanism suffers from three main drawbacks in domestically produced heterogeneous computing power clusters: First, scheduling lag. Adopting a reactive, "after-the-fact" response mode, by the time excessive load is detected and scaling up is triggered, the service has often already experienced response delays or performance fluctuations, failing to meet stringent requirements for real-time performance and stability. Second, inaccurate computing power assessment. In heterogeneous clusters composed of different models of domestically produced ARM processors, simple utilization metrics cannot accurately reflect actual computing power consumption. Differences in the microarchitecture of different cores lead to varying computing capabilities, and existing technologies lack awareness of the characteristics of heterogeneous hardware, potentially resulting in a "computing power mismatch" phenomenon where high-performance cores handle low-load tasks while low-performance cores are overloaded. Third, resource isolation is poor. Existing resource isolation mechanisms are mostly based on cgroups v1, which has limitations in terms of the accuracy of resource allocation and hard isolation capabilities. In complex scenarios with multiple tasks running in parallel, sudden high-load tasks will preempt shared resources, affecting the performance and stability of critical business containers.

[0004] Some existing technologies attempt to introduce simple time-series prediction algorithms to anticipate business traffic and trigger scaling operations in advance. Meanwhile, some solutions use cgroups v1 to limit container CPU and memory resources to achieve a certain degree of resource isolation. Furthermore, Kubernetes' native HPA component supports scaling decisions based on custom metrics, allowing users to extend the source of metrics and the decision-making logic.

[0005] Existing solutions incorporating time-series prediction have limited accuracy and fail to establish a closed-loop linkage with the underlying heterogeneous computing power scheduling strategy. The prediction results are merely used as scaling-up / scaling triggers and are not integrated with the actual computing power consumption assessment of heterogeneous hardware. Resource isolation mechanisms based on cgroups v1 are insufficient in terms of accuracy and hard isolation capabilities, failing to effectively suppress the interference of sudden tasks on critical services. Overall, existing technologies lack an intelligent scaling-up / scaling system that combines time-series traffic prediction, standardized heterogeneous computing power assessment, and fine-grained kernel-level resource management, making it difficult to achieve a complete closed loop from passive response to proactive prediction and from coarse isolation to fine-grained management on domestically produced heterogeneous computing power clusters. Summary of the Invention

[0006] This invention provides a method and system for automatic scaling of containers for heterogeneous computing power clusters, which solves the problems of lagging scheduling, lack of unified measurement of heterogeneous computing power, and rough resource isolation in existing passive response strategies.

[0007] To achieve the above objectives, the present invention provides the following technical solution: An automatic scaling method for containers designed for domestically produced heterogeneous computing power clusters includes the following steps: Collect operational metrics of containers in heterogeneous computing power clusters, including CPU utilization, memory utilization, I / O metrics, service QPS, response latency, and computing power density metrics of heterogeneous nodes. The collected historical operating indicators are input into the LSTM time series prediction model to predict the load change trend in future time periods and obtain the load prediction curve. Based on the computing power density index in the operational indicators and the load prediction curve, a scaling up / down decision is generated. Determine whether to trigger scaling up or down and determine the number of container replicas to be adjusted. Specifically: when the predicted load exceeds the first preset threshold of the current capacity within a preset future time, scaling up is triggered, and the number of scaling up is determined based on the difference between the predicted load and the current capacity. When the predicted load remains below the second preset threshold of the current capacity for a preset period of time, scaling down is triggered, and the number of scaling down is determined based on the business dependency graph and the resource idle rate. Perform scaling operations, create or destroy containers, and use cgroups v2 to manage container resources in a fine-grained manner.

[0008] Preferably, the computing power density index is obtained by: quantifying the computing power characteristics of the general-purpose processors and accelerator cards of each node in the heterogeneous computing power cluster, dividing the actual computing power output values ​​of the general-purpose processors and accelerator cards by their corresponding peak reference computing power, multiplying them by their corresponding weight coefficients, and summing them to obtain the standardized computing power density index.

[0009] Preferably, the calculation formula for the computing power density index is:

[0010] in, This represents the actual computing power output value of the general-purpose computing unit collected at the current moment. This represents the peak reference computing power of a general-purpose computing unit under standard benchmark tests. This represents the actual computing power output value of the accelerated computing unit collected at the current moment. To accelerate the peak reference computing power of the computing unit under standard AI benchmark tests, and These are the general computational weight coefficient and the AI ​​inference weight coefficient, respectively.

[0011] Preferably, the weighting coefficient is dynamically adjusted according to the task type: when the task is a data processing task, Set to high value Set to a low value; when the task is an AI inference task. Set to low value The weighting coefficient is set to a high value; it is also calculated in real time using task priority factors and power consumption constraints.

[0012] Preferably, in the LSTM time series prediction model, the input is a historical 24-hour traffic sequence, and the output is a load prediction curve for the next 15 minutes to 2 hours; the LSTM time series prediction model adopts a multi-layer LSTM network, introduces an attention mechanism and Dropout regularization, and adapts to new traffic patterns through an incremental learning mechanism.

[0013] Preferably, the training dataset of the LSTM time series prediction model is constructed by collecting historical traffic data from the platform for a period of time or longer. The historical traffic data includes daily load, task switching and peak scenarios, and the extracted features include timestamp, application type, QPS, response latency and resource consumption.

[0014] Preferably, the fine-grained management of container resources through cgroups v2 includes: constructing independent resource subtrees for applications of different priorities using a unified hierarchical structure of cgroups v2; enabling cgroups v2 thread mode for general-purpose processors to independently control the resources of multi-threaded tasks within the container; implementing container-level I / O bandwidth control through the io.max interface of cgroups v2; and dynamically mapping and generating the resource quota of cgroups v2 according to the computing power density index.

[0015] Preferably, during the scaling up and down operation, a rolling update strategy is adopted when scaling up, and the old container is destroyed after the new container is ready and the service access is completed; when scaling down, the task is migrated to other heterogeneous nodes first and then the container is destroyed.

[0016] Preferably, in the computing power density index, when the computing power density value is greater than the first overload threshold, it is determined to be computing power overload, and when the computing power density value is less than the first idle threshold, it is determined to be computing power idle, thereby triggering container replica adjustment or node migration.

[0017] An automatic container scaling system for domestically developed heterogeneous computing power clusters includes: The data acquisition module is used to collect the operating metrics of containers in the heterogeneous computing power cluster; The traffic prediction module is used to input the collected historical operating indicators into the LSTM time series prediction model to predict the load change trend in the future time period and obtain the load prediction curve. The decision generation module is used to generate scaling up / down decisions based on the load prediction curve and the computing power density index. The judgment and calculation module determines whether scaling up or down is triggered and determines the number of container replicas that need to be adjusted. The resource execution module is used to perform scaling operations, create or destroy containers, and perform fine-grained management of container resources through cgroups v2.

[0018] Compared with existing technologies, this invention has the following advantages: This invention provides an automatic scaling method for containers in heterogeneous computing power clusters. First, it collects the operating metrics of containers in the heterogeneous computing power cluster. Then, it predicts future load trends using an LSTM time-series prediction model. Based on the computing power density metric and the load prediction curve, it generates scaling decisions. The computing power density metric normalizes the actual computing power output values ​​of different general-purpose processors and accelerator cards into a standardized density, providing a unified evaluation basis for scaling decisions across heterogeneous nodes. Scaling is triggered when the predicted load exceeds a capacity threshold, and scaling is triggered when it remains below the threshold, ensuring precise matching of resource adjustments with business needs. Finally, it achieves hard isolation and elastic control of container resources through cgroups v2, using a unified hierarchical structure to build independent resource subtrees for applications of different priorities, thus solving the problem of coarse resource isolation. Attached Figure Description

[0019] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly described below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a flowchart of an automatic container scaling method for heterogeneous computing power clusters according to an embodiment of the present invention. Figure 2A hierarchical architecture topology diagram constructed for an embodiment of the present invention; Figure 3 This is a diagram showing the overall cluster deployment topology according to an embodiment of the present invention. Figure 4 This is a block diagram of an automatic container scaling system for heterogeneous computing power clusters according to an embodiment of the present invention. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0022] Therefore, the following detailed description of the embodiments of the invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the invention without inventive effort are within the scope of protection of the invention.

[0023] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0024] To enable those skilled in the art to better understand the technical solution of the present invention, the present invention will be further described in detail below with reference to the accompanying drawings.

[0025] See Figure 1 In one embodiment of the present invention, an automatic scaling method for containers for domestic heterogeneous computing power clusters is provided, which solves the technical problems of existing passive response strategies such as scheduling lag, lack of unified measurement of heterogeneous computing power, and extensive resource isolation.

[0026] Step S1: Collect operational metrics of containers in the heterogeneous computing power cluster Collect operational metrics of containers in heterogeneous computing power clusters, including CPU utilization, memory utilization, I / O metrics, service QPS, response latency, and computing power density metrics of heterogeneous nodes.

[0027] Specifically, by using Prometheus in conjunction with self-developed ARM64 / NPU hardware probes, it collects CPU utilization, memory utilization, I / O metrics, business QPS, response latency, link status of containers, as well as kernel-level metrics such as general processor core computing power density, Ascend NPU utilization, cache hit rate, and TLB miss rate of heterogeneous nodes, providing full-dimensional data support for upper-layer decision-making.

[0028] Explanatory: Comprehensive collection of operational metrics forms the data foundation for subsequent traffic prediction and computing power assessment. Traditional solutions only collect CPU and memory utilization, which cannot reflect the actual changing trends of business load and the true computing power consumption of heterogeneous nodes. By introducing business-level metrics such as business QPS and response latency, business load characteristics can be more accurately depicted; by introducing hardware-level metrics such as NPU utilization and cache hit rate, the computing power status of heterogeneous nodes can be perceived, providing data support for subsequent computing power density assessment.

[0029] Step S2: The LSTM time series forecasting model predicts the load change trend. The collected historical operating metrics are input into the LSTM time series prediction model to predict the load change trend in future time periods, resulting in a load prediction curve.

[0030] Specifically, an LSTM time-series prediction model is used. Taking the historical traffic sequence of the past 24 hours as input, it outputs load prediction curves for the next 15 minutes to 2 hours. The model employs a multi-layer LSTM network structure with hidden layer dimensions of 64 and 32. Dropout regularization is used to prevent overfitting, and an attention mechanism is introduced to enhance the capture of features related to periodic and sudden traffic events. An incremental learning mechanism is used to adapt to new traffic patterns. The training dataset is constructed by collecting more than three months of historical traffic data from the platform, including daily load, task switching, and peak scenarios, extracting features such as timestamps, application type, QPS, response latency, and resource consumption.

[0031] Explanation: Traditional threshold-based scaling up and down is a reactive, "after-the-fact" approach. By the time excessive load is detected and scaling up is triggered, performance degradation often has already occurred. Using LSTM models for long-term prediction of traffic time-series data allows for the early prediction of traffic peaks and troughs, transforming passive response into proactive prediction. Introducing an attention mechanism enhances the capture of periodic and sudden characteristics of traffic patterns, while incremental learning enables the model to quickly adapt to emerging traffic patterns, maintaining consistent prediction accuracy.

[0032] Step S3: Generate scaling decisions based on computing power density indicators and load prediction curves. Based on the computing density index in the operational metrics and the load prediction curve, a scaling decision is generated to determine whether to trigger scaling and to determine the number of container replicas that need to be adjusted.

[0033] Specifically, the computing power characteristics of the general-purpose processors and accelerator cards on each node in the heterogeneous computing power cluster are quantified. For ARM architecture general-purpose processors, their single-precision / double-precision peak computing power, memory access bandwidth, and multi-core collaborative efficiency are quantified through standard integer / floating-point arithmetic benchmark tests and typical business workloads. For AI accelerator cards, their TOPS computing power, memory bandwidth, inference latency, and heterogeneous collaborative overhead are quantified through standard deep learning model inference tests. The actual computing power output values ​​of the general-purpose processors and accelerator cards are divided by their corresponding peak reference computing power, multiplied by their respective weighting coefficients, and then summed to obtain the standardized computing power density index D. The calculation formula is as follows:

[0034] in, This represents the actual computing power output value of the general-purpose computing unit collected at the current moment. This represents the peak reference computing power of this model's general-purpose computing unit under standard benchmark testing. This represents the actual computing power output value of the accelerated computing unit collected at the current moment. This is the peak reference computing power of this model's accelerated computing unit under standard AI benchmark tests. and These are the general computational weight coefficient and the AI ​​inference weight coefficient, respectively. The weight coefficients are dynamically adjusted based on the task type; when the task is a data processing task... Set to high value Set to a low value; when the task is an AI inference task. Set to low value Set to a high value. The weighting coefficient is also calculated in real time using task priority factors and power consumption constraints. When the computing power density value is greater than 0.85, it is determined to be computing power overload; when the computing power density value is less than 0.2, it is determined to be computing power idle, thereby triggering container replica adjustment or node migration.

[0035] Based on computing power density indicators and load prediction curves, scaling up and down decisions are generated: when the predicted load exceeds the first preset threshold of the current capacity within a preset future time, scaling up is triggered, and the amount of scaling up is determined based on the difference between the predicted load and the current capacity; when the predicted load remains below the second preset threshold of the current capacity for a preset period of time, scaling down is triggered, and the amount of scaling down is determined based on the business dependency graph and resource idle rate.

[0036] Explanatory: The heterogeneous computing power density assessment model addresses the problem of inconsistent measurement of computing power across different architectures. Traditional CPU utilization metrics fail to reflect the computing power differences between different ARM processors and accelerator cards, potentially leading to a "computing power mismatch" where high-performance cores handle low-load tasks while low-performance cores are overloaded. By uniformly converting the actual computing power output values ​​of general-purpose processors and accelerator cards into standardized density metrics, fair and accurate scheduling across heterogeneous nodes is achieved. A dynamic weighting coefficient adjustment mechanism allows computing power assessment to adapt to task types, further improving accuracy. Combining computing power density metrics with traffic prediction curves for scaling decisions enables resource adjustments to both anticipate load change trends and perceive the true computing power status of heterogeneous nodes, avoiding decision-making biases caused by relying solely on predictions or current utilization rates.

[0037] Step S4: Perform expansion / shrinkage operations Perform scaling operations, create or destroy containers, and use cgroups v2 to manage container resources in a fine-grained manner.

[0038] Specifically, during expansion, a rolling update strategy is adopted. New containers are destroyed only after they are ready and have completed business integration, ensuring uninterrupted service. During scaling down, tasks are migrated to other heterogeneous nodes before destroying the containers to avoid service interruption. Fine-grained management of container resources is achieved through cgroups v2: a unified hierarchical structure is used to build independent resource subtrees for applications of different priorities; cgroups v2 thread mode is enabled for general-purpose processors to independently control the resources of multi-threaded tasks within containers; container-level I / O bandwidth control is implemented through the cgroups v2 io.max interface to prevent I / O-intensive applications from preempting critical business resources. cgroups v2 resource quotas (cpu.max, memory.max) are dynamically mapped based on computing density metrics. When the computing density value increases, the cpu.max limit of the container is automatically tightened to prevent overload from affecting neighbors; when the computing density value decreases, the memory.high limit is automatically relaxed to allow the use of idle memory.

[0039] Explanatory: cgroups v2's unified hierarchical structure replaces cgroups v1's multi-tree structure, building independent resource subtrees for applications with different priorities, avoiding resource contention between multiple applications. Rolling update strategies and task migration mechanisms ensure uninterrupted service during scaling up and down. Resource quotas are dynamically mapped based on computing power density, forming an evaluation-control closed loop, enabling resource management to be adjusted in real time according to load changes, unlike traditional static quota schemes.

[0040] Validity verification In one possible implementation, the technical effects and feasibility of the present invention are illustrated using a heterogeneous computing power cluster consisting of eight domestically produced server nodes as an example.

[0041] System architecture and testing scenarios See Figure 3 The hardware layer comprises four Kunpeng 920 ARM64 general-purpose servers (32 cores / 256GB memory) and four Kunpeng 920+Ascend 310 NPU heterogeneous servers (32 CPU cores + 8×Ascend 310 NPUs / 256GB memory). The operating system layer deploys the openEuler system, kernel version 5.10.0, enabling cgroups v2 features and the xSched heterogeneous fusion scheduling framework. The orchestration layer builds a Kubernetes cluster, using Docker as the container runtime, and integrates a custom heterogeneous scheduler and an extended HPA controller. The application layer deploys three typical service types: CPU-intensive data processing services, NPU-intensive image recognition services, and I / O+CPU hybrid API gateway services.

[0042] The control plane consists of 3 Kunpeng 920 nodes, deploying etcd, kube-apiserver, and kube-controller-manager components; the compute node pool includes 4 pure Kunpeng general-purpose compute nodes and 4 Kunpeng + Ascend heterogeneous compute nodes.

[0043] Technical feature implementation parameters The LSTM model takes a 24-hour historical traffic sequence as input and outputs a load prediction curve for the next 15 minutes to 2 hours. The scaling-up / scaling decision thresholds are set as follows: first preset threshold 80%, second preset threshold 30%, future preset time 10 minutes, and duration preset time 30 minutes. The computing power density overload threshold is 0.85, and the idle threshold is 0.2.

[0044] Algorithm Execution and Data Generation Process Data Acquisition: Real-time acquisition of operational metrics for API Gateway service (QPS 8000, response latency 150ms, CPU utilization 75%) and Image Recognition service (NPU utilization 60%) via Prometheus and self-developed ARM64 / NPU hardware probes.

[0045] Traffic prediction: The LSTM model takes historical traffic data from the past 24 hours as input and outputs prediction results for the next 30 minutes, showing that the API gateway QPS will rise to 12,000 and the NPU utilization of the image recognition service will rise to 85%.

[0046] Computing power assessment: Based on the heterogeneous computing power density model, the current computing power density of the API gateway service is 0.78 (predicted value 0.92), and the current computing power density of the image recognition service is 0.62 (predicted value 0.88), both of which are determined to be about to be overloaded.

[0047] Scheduling decision: The heterogeneous HPA controller triggers an expansion command, adding 4 Pods to the API Gateway service (preferred to be scheduled to Kunpeng nodes), and adding 2 Pods to the Image Recognition service (preferred to be scheduled to Ascend nodes).

[0048] Resource execution: A rolling update strategy is adopted to start new Pods. An independent resource subtree (CPU quota of 4 cores, memory of 8G, NPU quota of 2 cores) is allocated to the new Pod through openEuler cgroups v2. After the new Pod is ready, it gradually takes over the traffic, and the business latency is stabilized within 80ms.

[0049] Downsizing Scenario: During off-peak hours at night, the API gateway service QPS was 2000 (CPU utilization 20%), and the image recognition service NPU utilization was 15%. The LSTM model predicted that traffic would remain low for the next two hours, with computing power densities of 0.21 and 0.18 respectively, indicating idle resources. The heterogeneous HPA controller triggered downsizing, reducing the API gateway service from 12 Pods to 6 and the image recognition service from 6 to 3, prioritizing the destruction of lower-priority Pods. Before downsizing, the business traffic of the Pods to be destroyed was migrated using the Kubernetes scheduling mechanism, and the released CPU / NPU resources were allocated to offline data processing tasks.

[0050] Analysis of Implementation Results and Measured Indicators The test results are shown in Table 1, which compares the performance of the traditional threshold scaling scheme with that of the present invention.

[0051]

[0052] See Figure 2 The diagram illustrates the layered architecture topology of the method of this invention. The data acquisition layer collects operational metrics through Prometheus and ARM64 / NPU hardware probes; the AI ​​prediction layer outputs load prediction curves based on the LSTM model; the scheduling decision layer integrates the computing power density assessment model to generate scaling decisions; and the resource execution layer completes fine-grained management of container resources based on cgroups v2, forming a fully closed-loop intelligent scaling system of "traffic prediction - computing power assessment - scheduling decision - kernel management".

[0053] Verification results show that the heterogeneous computing power density model can accurately quantify the computing power output of Kunpeng CPU and Ascend NPU, solving the problem of resource mismatch in heterogeneous environments; fine-grained management based on openEuler cgroups v2 effectively suppresses resource contention among multiple applications and ensures the stability of core businesses; and deep integration with the Kubernetes orchestration layer enables automated scaling up and down of multiple applications throughout their entire lifecycle.

[0054] See Figure 4 In another embodiment of the present invention, an automatic container scaling system for domestically produced heterogeneous computing power clusters is provided, comprising: The data acquisition module is used to collect the operating metrics of containers in the heterogeneous computing power cluster; The traffic prediction module is used to input the collected historical operating indicators into the LSTM time series prediction model to predict the load change trend in the future time period and obtain the load prediction curve. The decision generation module is used to generate scaling up / down decisions based on the load prediction curve and the computing power density index. The judgment and calculation module is used to determine whether scaling up or down is triggered and to determine the number of container replicas that need to be adjusted. The resource execution module is used to perform scaling operations, create or destroy containers, and perform fine-grained management of container resources through cgroups v2.

[0055] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. It will be apparent to those skilled in the art that the invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other specific forms without departing from its spirit or essential characteristics. Therefore, the embodiments should be considered illustrative and non-limiting in all respects, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within the scope of the invention. No reference numerals in the claims should be construed as limiting the scope of the claims.

[0056] Furthermore, it should be understood that although this specification describes embodiments, not every embodiment contains only one independent technical solution. This narrative style is merely for clarity. Those skilled in the art should consider the specification as a whole, and the technical solutions in each embodiment can be appropriately combined to form other embodiments that can be understood by those skilled in the art. The above content is only for illustrating the technical concept of the present invention and should not be construed as limiting the scope of protection of the present invention. Any modifications made based on the technical concept proposed in this invention shall fall within the scope of protection of the claims of this invention.

Claims

1. A method for automatic scaling of containers for domestically produced heterogeneous computing power clusters, characterized in that, Includes the following steps: Collect operational metrics of containers in heterogeneous computing power clusters, including CPU utilization, memory utilization, I / O metrics, service QPS, response latency, and computing power density metrics of heterogeneous nodes. The collected historical operating indicators are input into the LSTM time series prediction model to predict the load change trend in future time periods and obtain the load prediction curve. Based on the computing power density index in the operational indicators and the load prediction curve, a scaling up / down decision is generated. Determine whether to trigger scaling up or down and determine the number of container replicas to be adjusted. Specifically: when the predicted load exceeds the first preset threshold of the current capacity within a preset future time, scaling up is triggered, and the number of scaling up is determined based on the difference between the predicted load and the current capacity. When the predicted load remains below the second preset threshold of the current capacity for a preset period of time, scaling down is triggered, and the number of scaling down is determined based on the business dependency graph and the resource idle rate. Perform scaling operations, create or destroy containers, and use cgroups v2 to manage container resources in a fine-grained manner.

2. The automatic scaling method for containers in domestically produced heterogeneous computing power clusters according to claim 1, characterized in that, The method for obtaining the computing power density index is as follows: the computing power characteristics of the general-purpose processors and accelerator cards of each node in the heterogeneous computing power cluster are quantified respectively. The actual computing power output values ​​of the general-purpose processors and accelerator cards are divided by their corresponding peak reference computing power, and then multiplied by their corresponding weight coefficients and summed to obtain the standardized computing power density index.

3. The automatic scaling method for containers in domestically produced heterogeneous computing power clusters according to claim 2, characterized in that, The calculation formula for the computing power density index is as follows: in, This represents the actual computing power output value of the general-purpose computing unit collected at the current moment. This represents the peak reference computing power of a general-purpose computing unit under standard benchmark tests. This represents the actual computing power output value of the accelerated computing unit collected at the current moment. To accelerate the peak reference computing power of the computing unit under standard AI benchmark tests, and These are the general computational weight coefficient and the AI ​​inference weight coefficient, respectively.

4. The automatic scaling method for containers in domestically produced heterogeneous computing power clusters according to claim 3, characterized in that, The weighting coefficients are dynamically adjusted according to the task type: when the task is a data processing task... Set to high value Set to a low value; when the task is an AI inference task. Set to low value The weighting coefficient is set to a high value; it is also calculated in real time using task priority factors and power consumption constraints.

5. The automatic scaling method for containers in domestically produced heterogeneous computing power clusters according to claim 1, characterized in that, The LSTM time series prediction model takes a historical 24-hour traffic sequence as input and outputs a load prediction curve for the next 15 minutes to 2 hours. The LSTM time series prediction model adopts a multi-layer LSTM network, introduces attention mechanism and Dropout regularization, and adapts to new traffic patterns through incremental learning mechanism.

6. The automatic scaling method for containers in domestically produced heterogeneous computing power clusters according to claim 5, characterized in that, The training dataset for the LSTM time-series prediction model is constructed by collecting historical traffic data from the platform for a period of time or longer. The historical traffic data includes daily load, task switching, and peak scenarios. The extracted features include timestamps, application types, QPS, response latency, and resource consumption.

7. The automatic scaling method for containers in domestically produced heterogeneous computing power clusters according to claim 1, characterized in that, The fine-grained management of container resources through cgroups v2 includes: using a unified hierarchical structure of cgroups v2 to build independent resource subtrees for applications of different priorities; enabling cgroups v2 thread mode for general-purpose processors to independently control the resources of multi-threaded tasks within the container; implementing container-level I / O bandwidth control through the io.max interface of cgroups v2; and dynamically mapping and generating cgroups v2 resource quotas based on computing power density indicators.

8. The automatic scaling method for containers in domestically produced heterogeneous computing power clusters according to claim 1, characterized in that, During the scaling up and down operations, a rolling update strategy is adopted when scaling up, and the old container is destroyed after the new container is ready and the service is connected; when scaling down, the task is migrated to other heterogeneous nodes first and then the container is destroyed.

9. The automatic scaling method for containers in domestically produced heterogeneous computing power clusters according to claim 1, characterized in that, In the computing power density index, when the computing power density value is greater than the first overload threshold, it is determined to be computing power overload; when the computing power density value is less than the first idle threshold, it is determined to be computing power idle, thereby triggering container replica adjustment or node migration.

10. An automatic container scaling system for domestically produced heterogeneous computing power clusters, characterized in that, A method for automatically scaling up and down containers for domestically produced heterogeneous computing power clusters, as described in any one of claims 1-9, includes: The data acquisition module is used to collect the operating metrics of containers in the heterogeneous computing power cluster; The traffic prediction module is used to input the collected historical operating indicators into the LSTM time series prediction model to predict the load change trend in the future time period and obtain the load prediction curve. The decision generation module is used to generate scaling up / down decisions based on the load prediction curve and the computing power density index. The judgment and calculation module determines whether scaling up or down is triggered and determines the number of container replicas that need to be adjusted. The resource execution module is used to perform scaling operations, create or destroy containers, and perform fine-grained management of container resources through cgroups v2.

Images