Container mounting method and device, equipment, storage medium and program product

Abstract

The invention provides a container mounting method and device, equipment, a storage medium and a program product, the method is applied to a cloud platform comprising at least one cloud server, the cloud server comprises a container, and the method comprises the following steps: in response to a trigger event, obtaining a performance evaluation parameter of the cloud server; performing performance evaluation on each cloud server according to the performance evaluation parameters to obtain an evaluation result; based on the evaluation result, gradient grouping is carried out on all cloud servers contained in the cloud platform, at least one cloud server group is obtained, and each cloud server group corresponds to one performance level; and carrying out the migration of the cloud application in at least one cloud server group by carrying out mounting release and / or remounting on the container. Therefore, through a cloud server gradient grouping and cloud application dynamic migration mechanism based on performance evaluation, intelligent scheduling and load balancing of cloud server resources are realized, so that the overall resource utilization efficiency and the stability of cloud application operation are improved.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, and in particular to a container mounting method, apparatus, device, storage medium, and program product. Background Technology

[0002] In the context of the rapid development of cloud computing and the surge in demand for high-performance computing, traditional single-server architectures can no longer meet the computing power requirements of large-scale deep learning models (such as Deepseek) and the Jiutian large model, which have capacities of 1.5B, 7B, 14B, 70B, and 671B. To address this challenge, the cloud computing industry has proposed strategies of multi-cloud collaboration and multi-container parallel processing, distributing task loads across multiple container instances.

[0003] However, existing container mounting methods have revealed significant shortcomings in practical applications. First, mounting strategies generally lack dynamism and predictability. Existing methods typically make one-time, relatively static mounting decisions when containers are created, failing to dynamically adjust based on the actual operational needs of cloud applications, the real-time status of container resources, and changes in the overall performance of the cloud server cluster. This model easily leads to an imbalance between resource supply and demand between containers and cloud servers, resulting in an "unsaturated" phenomenon where some containers are overloaded while others are idle, thereby reducing overall computing efficiency.

[0004] Secondly, there is a lack of effective cluster-level collaborative mounting mechanisms. When new cloud applications need to be mounted or the state of cluster resources changes, existing technologies often adopt local optimization or simple load balancing strategies, such as migrating applications on high-load containers to low-load containers. This approach easily leads to frequent mounting, unmounting, and remounting operations, which not only incurs additional performance overhead but may also cause application service interruptions, data transmission delays, and even trigger chain reactions, causing temporary lag or downtime of cloud servers, seriously affecting the stability and reliability of the system.

[0005] Therefore, existing technologies struggle to achieve efficient utilization of container resources and intelligent scheduling of cloud applications while ensuring system stability. Summary of the Invention

[0006] This application provides a container mounting method, apparatus, device, storage medium, and program product to solve the technical problem in the prior art of achieving efficient utilization of container resources and intelligent scheduling of cloud applications while ensuring system stability.

[0007] To solve the above-mentioned technical problems, this application is implemented as follows:

[0008] In a first aspect, embodiments of this application provide a container mounting method, the method being applied to a cloud platform containing at least one cloud server, the cloud server containing a container, the method comprising:

[0009] In response to the triggering event, obtain the performance evaluation parameters of the cloud server;

[0010] The performance of each cloud server is evaluated based on the aforementioned performance evaluation parameters to obtain the evaluation results.

[0011] Based on the evaluation results, all cloud servers included in the cloud platform are grouped in a gradient manner to obtain at least one cloud server group, and each cloud server group corresponds to a performance level.

[0012] Migrate cloud applications in at least one cloud server group by unmounting and / or remounting the container.

[0013] Optionally, the triggering event includes at least one of the following:

[0014] The system receives a packaging request from the terminal for a cloud application to be mounted to the container, the packaging request carrying runtime status parameters.

[0015] The performance indicators of the cloud server were monitored and found to have reached the preset performance indicator threshold.

[0016] Optionally, when the triggering event is receiving a packaging request from the terminal for a cloud application to be mounted to the container, the performance evaluation parameters include: the running status parameters and the status of the container.

[0017] Optionally, the performance of each cloud server is evaluated based on the aforementioned performance evaluation parameters to obtain evaluation results, including:

[0018] The unsaturated differential value corresponding to the container on the cloud server is determined based on the operating status parameters.

[0019] Based on the running status parameters and the status of the container on the cloud server, determine the possibility of seamless execution of the mounting and matching between the container and the cloud server;

[0020] The comprehensive score of each cloud server is determined based on the unsaturated differential value and the probability of seamless execution of the mount matching, and the comprehensive score is used as the evaluation result.

[0021] Optionally, the running status parameters include: the number of dependencies of the cloud application to be mounted, the configuration type value, the resource consumption of version rollback, the controllability of version rollback, and the ratio between the debug package and the official package.

[0022] Determining the unsaturated differential value corresponding to the container on the cloud server based on the operating status parameters includes:

[0023] The unsaturated differential speed value is determined based on the number of dependency relationships, the configuration type value, the resource consumption, and the controllability.

[0024] The step of determining the seamless execution probability of mounting and matching between the container and the cloud server based on the running status parameters and the status of the container on the cloud server includes:

[0025] The task status execution differential of the cloud server is determined based on the unsaturated differential value and the proportional relationship.

[0026] Based on the unsaturated differential value, the task status execution differential, and the status of the container on the cloud server, the possibility of seamless execution of the mounting match between the container and the cloud server is determined.

[0027] Optionally, based on the evaluation results, the cloud platform is subjected to gradient grouping of all cloud servers to obtain at least one cloud server group, including:

[0028] Based on the relationship between the comprehensive score and the preset energy efficiency threshold, all cloud servers included in the cloud platform are divided into an inefficient cloud server group and an efficient cloud server group.

[0029] Based on the overall score and the number of sub-shards contained in the container, a benchmark cloud server group is determined from the inefficient cloud server group and / or the efficient cloud server group.

[0030] Optionally, the migration of cloud applications in the at least one cloud server group by unmounting and / or remounting the container includes:

[0031] The cloud application in the inefficient cloud server group is unmounted from its currently mounted container and remounted to the target container in the efficient cloud server group; wherein the balanced load value of the target container is less than a preset load threshold.

[0032] Optionally, after migrating the cloud application in the at least one cloud server group, the method further includes:

[0033] Obtain the computing capacity, energy consumption data, and task crack data of the target container;

[0034] Based on the computing power capacity, the energy consumption data, the task crack data, and the resource consumption of the version rollback of the cloud application to be mounted in the running status parameters, the exclusivity between the target container and its cloud server is determined.

[0035] The corresponding energy-saving strategy is executed based on the exclusionary property.

[0036] Secondly, embodiments of this application provide a container mounting device, the device being applied to a cloud platform containing at least one cloud server, the cloud server containing a container, the device comprising:

[0037] The acquisition module is used to acquire the performance evaluation parameters of the cloud server in response to a triggering event;

[0038] The execution module is used to perform performance evaluation on each cloud server according to the performance evaluation parameters and obtain the evaluation results.

[0039] Based on the evaluation results, all cloud servers included in the cloud platform are grouped in a gradient manner to obtain at least one cloud server group, and each cloud server group corresponds to a performance level.

[0040] Migrate cloud applications in at least one cloud server group by unmounting and / or remounting the container.

[0041] Thirdly, embodiments of this application provide a network device, including: a processor, a memory, and a program stored in the memory and executable on the processor, wherein when the program is executed by the processor, it implements the steps of a container mounting method as described in the first aspect.

[0042] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of a container mounting method as described in the first aspect.

[0043] Fifthly, embodiments of this application provide a computer program product, including computer instructions, which, when executed by a processor, implement the steps of a container mounting method as described in the first aspect.

[0044] In this embodiment, by responding to a trigger event to obtain the performance evaluation parameters of the cloud server, the performance status of the cloud server can be dynamically perceived; then, the cloud server is evaluated based on the performance evaluation parameters and the evaluation results are obtained, thereby enabling quantitative measurement of the performance of each cloud server; based on the evaluation results, all cloud servers are divided into groups with different performance levels, and cloud applications are migrated between groups by unmounting and / or remounting containers, so that the load can be dynamically adjusted between different cloud server groups.

[0045] In summary, by using a performance-based cloud server gradient grouping and cloud application dynamic migration mechanism, intelligent scheduling and load balancing of cloud server resources are achieved, thereby improving overall resource utilization efficiency and the stability of cloud application operation. Attached Figure Description

[0046] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0047] Figure 1 A flowchart illustrating a container mounting method provided in this application embodiment;

[0048] Figure 2 A flowchart illustrating a container mounting method provided in this application embodiment;

[0049] Figure 3 A flowchart illustrating a container mounting method provided in this application embodiment;

[0050] Figure 4 A structural block diagram of a container mounting device provided in an embodiment of this application;

[0051] Figure 5 This is a structural block diagram of a network device provided in an embodiment of this application. Detailed Implementation

[0052] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0053] Figure 1 This application illustrates a container mounting method according to an embodiment of the present application, the method comprising:

[0054] Step S101: In response to the triggering event, obtain the performance evaluation parameters of the cloud server;

[0055] Step S102: Perform performance evaluation on each cloud server according to the performance evaluation parameters and obtain the evaluation results;

[0056] Step S103: Based on the evaluation results, perform gradient grouping on all cloud servers included in the cloud platform to obtain at least one cloud server group.

[0057] Each cloud server group corresponds to a performance level;

[0058] Step S104: Migrate cloud applications in at least one cloud server group by unmounting and / or remounting the containers.

[0059] It should be noted that this application provides a container mounting method. The method is applied to a cloud platform containing at least one cloud server. The cloud server contains containers, and cloud applications can be mounted on these containers. The method begins with a response to a triggering event. Once the event is triggered, the system automatically acquires performance evaluation parameters used to measure the operating status and capabilities of the cloud server. Subsequently, based on the acquired performance evaluation parameters, the system performs a unified performance evaluation on each cloud server within the platform and generates corresponding evaluation results. Based on these evaluation results, all cloud servers in the cloud platform are tiered and classified into different cloud server groups. Each cloud server group corresponds to a specific performance level (e.g., inefficient cloud server group, efficient cloud server group), thus intuitively distinguishing high-performance and low-performance resource groups within the server cluster. Finally, based on the above grouping results, by selectively unmounting and / or remounting containers, the migration and scheduling of cloud applications between different levels of cloud server groups can be achieved.

[0060] In summary, by using a performance-based cloud server gradient grouping and cloud application dynamic migration mechanism, intelligent scheduling and load balancing of cloud server resources are achieved, thereby improving overall resource utilization efficiency and the stability of cloud application operation.

[0061] In one possible implementation, the triggering event includes at least one of the following: receiving a packaging request from the terminal for a cloud application to be mounted to the container, the packaging request carrying runtime status parameters; or monitoring that the performance indicators of the cloud server have reached a preset performance indicator threshold.

[0062] It should be noted that the triggering event is a prerequisite for starting the entire container mounting method, and it includes at least one of the following two scenarios: The first scenario is that the system receives a package request from the terminal for a cloud application to be mounted to a cloud platform container, and this package request includes runtime status parameters describing the cloud application to be mounted; the second scenario is that the system, through continuous (real-time or time-segmented) monitoring mechanisms, discovers that the real-time performance indicators of one or more cloud servers have reached or exceeded pre-set performance indicator thresholds (such as approaching a preset full-load threshold). Both of these events indicate that the current cloud platform resource status or load demand has changed, requiring reassessment and rescheduling.

[0063] Furthermore, the cloud application to be mounted is not an isolated task. The runtime parameters carried in its packaging requirements specifically describe the application's key operational characteristics, such as its demand for computing, memory, storage, and network resources, performance sensitivity, and dependencies. These characteristics indicate that the cloud application needs to be matched and mounted with an existing container on the cloud platform that has sufficient resource reserves and a specific operating environment. To find the most suitable container and ensure that this mounting does not negatively impact the stability of the platform's existing load and overall resource utilization efficiency, the system can initiate a global resource review and evaluation process. By obtaining the performance evaluation parameters of the cloud servers, the system recalculates the status and capacity of all cloud servers and containers to optimize and adjust the existing load distribution from a globally optimal perspective and allocate suitable containers for the new application. Therefore, the new packaging requirements are a key signal driving the system to dynamically optimize and achieve continuous adaptive resource management.

[0064] When the system detects that a cloud server's performance metrics (such as memory usage or response latency) reach or exceed preset performance thresholds, it indicates that the server may be under high load, experiencing performance bottlenecks, or is about to become unstable. Therefore, the system needs to trigger a reassessment and resource allocation process to proactively eliminate performance bottlenecks and restore overall load balancing and stable operation of the cloud servers on the cloud platform.

[0065] Overall, this section clarifies the two specific conditions for the startup method. Its technical effect lies in defining a flexible and comprehensive process triggering mechanism, which enables the system to proactively adapt resources when new cloud applications need to be deployed, and to promptly start optimization when existing servers are overloaded or have abnormal performance. This ensures that resource scheduling can respond to dynamic changes and maintain the overall efficiency and stability of the cloud platform.

[0066] In one possible implementation, when the triggering event is receiving a packaging request from the terminal for a cloud application to be mounted to a container, the performance evaluation parameters include: runtime status parameters and the container's status. Based on these parameters, the performance of each cloud server is evaluated to obtain evaluation results, including: determining the unsaturated differential value corresponding to the container on the cloud server based on the runtime status parameters; determining the likelihood of seamless mounting and matching between the container and the cloud server based on the runtime status parameters and the container's status; and determining a comprehensive score for each cloud server based on the unsaturated differential value and the likelihood of seamless mounting and matching, using the comprehensive score as the evaluation result.

[0067] It should be noted that, in this application, when the triggering event is the receipt of a new cloud application packaging request to be mounted, the performance of each cloud server can be evaluated and the evaluation results obtained based on the acquired performance evaluation parameters (i.e., the container status and the runtime status parameters carried by the packaging request). Specifically, firstly, based on the characteristics of the cloud application described by the runtime status parameters, the unsaturated differential value corresponding to the container is calculated. This indicator measures the gap between the container's current resource supply capacity and the demand of the cloud application to be mounted. The system integrates the runtime status parameters and the container status on the cloud server to determine the possibility of seamless mounting and matching between the container and the cloud server. This indicator predicts the possibility of completing the container mounting operation on the cloud server without affecting the continuous and stable operation of existing tasks. Finally, the system uses the two key indicators, the unsaturated differential value and the possibility of seamless mounting and matching, to determine a single quantitative value representing the overall mounting suitability and performance level of each cloud server, namely a comprehensive score, and uses this comprehensive score as the performance evaluation result for the cloud server.

[0068] In summary, by introducing and applying indicators such as unsaturated differential speed value and the possibility of seamless execution of mount matching, the final evaluation result (comprehensive score) can comprehensively reflect the overall performance and matching degree of the cloud server when handling new mount requirements, thus providing an accurate and reliable foundation for subsequent cloud server gradient grouping.

[0069] In one possible implementation, the runtime status parameters include: the number of dependencies of the cloud applications to be mounted, the configuration type value, the resource consumption of version rollback, the controllability of version rollback, and the ratio between debug and production packages.

[0070] The unsaturated differential value for containers on the cloud server is determined based on the running status parameters, including: determining the unsaturated differential value based on the number of dependencies, configuration type value, resource consumption, and controllability.

[0071] Based on the running status parameters and the status of containers on the cloud server, determine the possibility of seamless execution of the mounting match between the container and the cloud server, including: determining the task status execution differential of the cloud server based on the unsaturated differential value and the proportional relationship; and determining the possibility of seamless execution of the mounting match between the container and the cloud server based on the unsaturated differential value, the task status execution differential, and the status of the container on the cloud server.

[0072] It should be noted that the runtime status parameters include five core attributes: the number of dependencies of the cloud application to be mounted, the configuration type value of the cloud application to be mounted, the resource consumption of the version rollback of the cloud application to be mounted, the controllability of the version rollback of the cloud application to be mounted, and the ratio of debug package to production package of the cloud application to be mounted.

[0073] The packaging requirements will now be explained in detail based on the runtime status parameters. First, when the terminal packages the cloud application onto the cloud container, it sends the packaging requirement of the cloud application to the cloud server where the cloud container is located.

[0074] The packaging requirements for cloud applications include: the number of dependencies of the application that needs to be mounted on the cloud server. Debug package and formal package proportional relationship between The configuration includes the PT type, ER version rollback cost, and ER-C rollback cost controllability. Each parameter is described in detail below:

[0075] Number of dependencies of applications that need to be mounted on the cloud server :

[0076] This relationship differs from typical dependencies. Here, the dependency relationship refers to the number of subordinate applications within a cloud application. The underlying layer of the cloud application corresponds to multiple pre-packaged open-source components, and some of these components have dependencies on each other; that is, component N1 depends on the capabilities of component N2. The number of dependencies represents the total number of dependencies between open-source components within this cloud application. .

[0077] Configuration type PT value:

[0078] This refers to whether platform or channel configuration is required in addition to the basic application configuration. Basic configuration involves filling in basic information such as the application name, version number, and icon. Subsequent configuration depends on the cloud application's preset distribution channels. This involves selecting the target platform (e.g., Android, iOS) and the corresponding packaging format (e.g., APK, IPA, or AAB), or channel configuration. If the application needs to be listed in different app stores, the corresponding channel configuration must be selected according to the store's requirements.

[0079] When the configuration type is platform configuration, the configuration type value = the capacity of the basic configuration information. When the configuration type is channel configuration, the configuration type value = basic configuration type * 1 / number of channels.

[0080] Version rollback cost ER:

[0081] ER=sign( ;

[0082] Where sign is the return function, i.e., returns... The value, The resource consumption for rolling back to the latest version within the execution duration t of the rollback. To account for the resource consumption required to roll back to the universal base version within the rollback execution duration t, Adjust parameters to suit the rollback difficulty for different versions. The initial rollback resource consumption for different versions.

[0083] Rollback cost controllability ER-C:

[0084] ER-C=(1- ) (1- ) (1- )

[0085] in, This represents the actual difficulty of a version rollback. Theoretically, the larger the rollback span, the higher the difficulty, with a maximum of 10. This value represents the maximum possible rollback difficulty. It is a preset value and indicates the rollback difficulty under the most scarce environmental resources.

[0086] It's important to note that the ER-C metric is calculated using three dimensions of rollback difficulty. Each dimension's rollback difficulty is normalized to a value between 0 and 1. Then, this normalized value is subtracted from 1, resulting in a score between 0 and 1, representing the ease of rollback for that dimension. Finally, these three scores are multiplied to obtain a comprehensive ER-C metric. A higher ER-C value indicates lower rollback difficulty and stronger environmental recovery or rollback capability. , , If all values ​​are 0, then ER-C will reach its maximum value of 1, indicating that rollback is very easy. If these values ​​are close to or equal to their maximum possible value, then ER-C will be close to 0, indicating that rollback is very difficult.

[0087] First, by comprehensively utilizing parameters that directly reflect the complexity and resource requirements of the cloud application to be mounted—such as the number of dependencies, configuration type values, resource consumption during version rollback, and the controllability of version rollback—the system calculates the first key indicator—the unsaturated differential speed value—using a specific formula. This value characterizes the potential gap between container resource supply and the expected demand of the cloud application. The system then combines this calculated unsaturated differential speed value with another key parameter: the ratio of debug to production packages of the cloud application to be mounted, to further derive the second key indicator: the task execution differential speed of the cloud server. This indicator reflects the efficiency differences and potential bottlenecks of the server when handling tasks in different states (development / debugging and production). Finally, the system integrates and analyzes the calculated unsaturated differential speed value, the task execution differential speed, and the real-time monitored container status on the cloud server to comprehensively determine the possibility of seamless execution between the container and the cloud server. This is a comprehensive predictive indicator that measures whether the mounting operation can be completed smoothly and efficiently without causing resource conflicts or performance fluctuations. In summary, after receiving a packaging request, the cloud server can combine the packaging request and the status of the containers on the cloud server to determine and calculate the unsaturated differential value (DSV) corresponding to the containers in the current task environment. Then, based on the unsaturated differential value (DSV), the uncertainty of the task package, and the current task status of the cloud server, the differential value (Gj) is executed to obtain the container adaptation and seamless mounting matching probability (Sprb) between servers in the current task environment.

[0088] The above process will now be explained in detail using formulas:

[0089] Determine the unsaturated differential speed (DSV):

[0090] The unsaturated differential value (DSV) of the container in the current task environment is calculated based on the rollback cost controllability (ER-C), version rollback cost (ER), configuration type (PT) value, and the number of dependencies of the application that needs to be mounted on the cloud server.

[0091] DSV=

[0092] Here, C represents the log value of a single rollback cost when the number of rollbacks exceeds N. This method obtains the unsaturated differential velocity (DSV) by dividing the resource consumption adjustment value in the numerator by the configuration adjustment factor in the denominator. The smaller this value, the higher the resource utilization efficiency of the container in the current task environment, meaning the resource utilization is closer to saturation. This method provides a quantitative indicator to evaluate the resource utilization efficiency of containers on cloud servers by comprehensively considering rollback cost, rollback controllability, number of dependencies, and configuration complexity.

[0093] Determine the likelihood of seamless execution of Sprb with mount matching:

[0094] Based on the unsaturated differential value DSV corresponding to the container in the current task environment and the debug package and formal package And Gj, to obtain the container adaptation of the server in the current task environment and the seamless execution probability of mount matching between servers: Sprb:

[0095] Sprb= ;

[0096] in, To and become Two mutually exclusive correction coefficients on the inverse function curve, task state execution difference Gj= / V )* , This represents the unsaturated differential speed value corresponding to the container in the current task environment.

[0097] Therefore, by comprehensively analyzing the cloud application tasks to be executed, the current running status of containers on the cloud server (including resource usage and performance metrics), the gap between the real-time resource usage of containers and their maximum capacity, and the execution efficiency of the server under the current task state, the seamless execution probability (Sprb) is finally calculated. This metric characterizes the likelihood that the server can seamlessly adapt to containers and execute tasks smoothly under the current task environment. The higher the Sprb value, the stronger the server's ability to efficiently handle new tasks or additional loads without interrupting existing tasks. The implementation of this step aims to help cloud service providers more accurately predict and evaluate the actual performance of servers when facing diverse task demands, thereby providing key decision-making basis for subsequent server tiered grouping.

[0098] In summary, the abstract characteristics of cloud applications and container states can be transformed into quantifiable evaluation metrics with clear physical meaning (unsaturated differential value, task execution differential, and the probability of seamless execution of mount matching), providing a solid and reliable data foundation for subsequent comprehensive scoring, gradient grouping, and intelligent mount decisions.

[0099] In one possible implementation, based on the evaluation results, all cloud servers included in the cloud platform are tiered and grouped to obtain at least one cloud server group, including: dividing all cloud servers included in the cloud platform into an inefficient cloud server group and an efficient cloud server group based on the relationship between the comprehensive score and the preset energy efficiency threshold; and determining a benchmark cloud server group from the inefficient cloud server group and / or the efficient cloud server group based on the comprehensive score and the number of sub-shards contained in the container.

[0100] Furthermore, by unmounting and / or remounting containers, cloud applications are migrated in at least one cloud server group, including: unmounting cloud applications in inefficient cloud server groups from their currently mounted containers and remounting them to target containers in efficient cloud server groups; wherein the balanced load value of the target container is less than a preset load threshold.

[0101] It's important to note that the process of gradiently grouping all cloud servers within the cloud platform based on the evaluation results to obtain at least one cloud server group involves two logical levels of operations. First, the system compares the overall score of each cloud server with a preset energy efficiency threshold (e.g., 60 points). Based on the relationship between the overall score and the energy efficiency threshold, all cloud servers are divided into two basic categories: inefficient cloud server group and high-efficiency cloud server group, thus achieving an initial classification of server cluster performance. Building on this, the grouping process deepens further. The system combines the overall score of each cloud server with the number of sub-shards contained in the containers on the cloud server to analyze and filter the already divided inefficient and high-efficiency cloud server groups, determining the group that serves as a stability benchmark, i.e., the baseline cloud server group.

[0102] Based on the grouping results, in the container mounting method, cloud applications located in low-scoring, inefficient cloud server groups can be unmounted from their current running containers, separating them from their original operating environment. These unmounted cloud applications are then remounted to target containers in high-scoring, efficient cloud server groups that meet the receiving conditions. Furthermore, the target containers are not arbitrarily selected; their load balancing value must be lower than a pre-set load threshold to ensure that they maintain stable and efficient operation after receiving new loads.

[0103] This section uses a specific application scenario as an example to explain how to perform tiered grouping of cloud servers and how to mount the grouped containers. The core of this approach lies in utilizing the evaluation capabilities of the Sprb and DSV metrics to identify inefficient and efficient cloud servers, and then migrating cloud applications to achieve rational resource allocation, avoid resource waste, and ensure that high-demand tasks (cloud applications) are scheduled to target containers with sufficient resources and high execution efficiency, thereby improving overall resource utilization.

[0104] The specific gradient grouping method is as follows: First, using the following formula:

[0105] The overall score is calculated as w1 × DSV + w2 × Sprb, where w1 and w2 are weighting coefficients, and w1 + w2 = 1.

[0106] It should also be noted that in practical applications, cloud servers can be divided into three groups based on the relationship between the comprehensive score and the preset energy efficiency threshold, combined with the preset ratio coefficient. For example, cloud servers with a comprehensive score greater than the preset energy efficiency threshold and ranked in the top 30% are divided into the high-efficiency cloud server group; cloud servers with a comprehensive score greater than the preset energy efficiency threshold and ranked in the top 30% to 70% are divided into the medium-efficiency cloud server group; and cloud servers with a comprehensive score less than the preset energy efficiency threshold and ranked in the bottom 30% are divided into the low-efficiency cloud server group.

[0107] After grouping, the load balancing value of containers within each cloud server group needs to be assessed to provide a basis for subsequent container mounting. The system first calculates the load value (FD) of a single container using the following formula:

[0108] FD = Old load × Attenuation factor + Current load × (1 − Attenuation factor).

[0109] Based on this, FD is containerized to obtain the balanced load value FD-c of the container. The calculation formula is: FD-c = FD / number of containers that meet the condition where the number of sub-shards is greater than the number of containers in the high group of the gradient group.

[0110] Furthermore, after grouping, a baseline cloud server group needs to be determined based on the comprehensive score and the number of sub-shards contained in the container. This involves determining the number of containers within a cloud server group that meet preset screening criteria: the number of sub-shards in the container is greater than the number of containers in the cloud server group with the highest comprehensive score. Within the cloud server groups that pass the screening, a baseline cloud server group is determined, specifically the cloud server group with the largest number of containers. All cloud applications already mounted in the baseline cloud server group are kept on-premises.

[0111] It should be noted that when constructing the differential mounting strategy, based on the number of containers (CG) in each group that meet the condition that "the number of sub-shards is greater than the number of containers in the higher-level group of the gradient group," the following differentiated operations are performed: The group with the most CGs enjoys a differential expansion coefficient, and cloud applications within this group do not need to be updated and mounted. Even if the container load is close to the limit, its mounting time can still be extended. Because such cloud applications are sensitive to stability, updating and mounting may cause a brief pause, which may lead to errors in the execution of batch applications. Therefore, maintaining their stable operation is the primary goal. In groups with fewer than the most CGs, lower-level applications need to update and mount to the same type of server in higher-level groups. If there are multiple target containers, the specific mounting target can be freely selected by the user for migration. This process aims to ensure the stability of the container itself, while ensuring the smooth execution of cloud applications through reasonable migration. Furthermore, the differential mounting strategy aims to improve container I / O (Input / Output) performance, reduce mounting latency, and enhance the balance and adaptability of mounting by optimizing mounting parameter configuration.

[0112] Therefore, the complex judgment of mounting suitability can be transformed into a single comparable score through objective weighted calculation, and gradient grouping can be carried out using preset ratios, thus providing a clear and operable classification basis for subsequent identification of benchmark cloud server groups and execution of differentiated mounting and migration strategies.

[0113] It should be noted that the core of the differential update mounting operation lies in differentiating the mounting status of cloud applications based on the container's load balancer value (FD-c) and group attributes to achieve the dual goals of load balancing and system stability. For example, after completing gradient grouping and load balancer value calculation, the specific steps of the differential update mounting operation are as follows:

[0114] Determine the baseline group and migration range:

[0115] First, the number of containers in each tier group (taking the high-efficiency, medium-efficiency, and low-efficiency groups as examples) that satisfy the condition "number of sub-shards > number of containers in the high-efficiency group" is counted and denoted as CG. The group with the largest number of CGs is determined as the baseline group. All cloud applications in this group maintain their current mounts and are not migrated to ensure the absolute stability of core services. For groups with a smaller number of CGs (i.e., the medium-efficiency and low-efficiency groups), the cloud applications mounted in them need to be migrated. The migration direction is usually from the low-efficiency group to the medium-efficiency group to avoid interfering with the high-efficiency group.

[0116] Secondly, select the target container: Within the target group (such as the medium-efficiency group), the system will filter out containers whose balanced load value (FD-c) is lower than the preset load threshold as candidate target containers. The final target container selection can be automatically specified by the system based on the principle of the lowest FD-c, or a list can be provided for users to freely select.

[0117] Finally, perform differential mounting: unmount the cloud application to be migrated from its original container (such as a container in the inefficient group) and remount it to the selected target container. New cloud applications can also be directly mounted to FD-c qualified target containers in the medium or high efficiency groups.

[0118] For example, a cloud platform runs multiple cloud applications, including an online payment application (App-P) with extremely high stability requirements, an enterprise internal management system (App-M), and a batch processing application (App-B) for testing and data analysis.

[0119] The gradient grouping results are as follows:

[0120] High-efficiency group: contains 10 containers, of which the number of sub-shards of the 8 containers in the high-efficiency group is greater than 10 (i.e. the number of containers in the high-efficiency group), so CG = 8.

[0121] Medium efficiency group: contains 14 containers, of which 5 containers have more than 10 sub-shards, so CG = 5.

[0122] Inefficient group: contains 10 containers, of which 2 containers have more than 10 sub-shards, so CG = 2.

[0123] The high-efficiency group can be designated as the benchmark group. However, it should be noted that in practical applications, the high-efficiency group is the group with the highest overall score, not necessarily the group with the most CG. The medium-efficiency group may also be the benchmark group.

[0124] Update mount operation process:

[0125] Since the high-efficiency group has the highest CG value (8), it is determined as the baseline group. Therefore, even if some containers in this group have high loads, the online payment application (App-P) mounted here will not be migrated, ensuring the continuity and stability of core financial business.

[0126] The system calculates the container load balance (FD-c) and finds that the batch application (App-B) in the inefficient group has a high FD-c, while two containers in the medium-efficient group have low FD-c and meet the mounting criteria. Therefore, the system automatically unmounts App-B from its original container in the inefficient group and remounts it to a target container with a low FD-c in the medium-efficient group.

[0127] This not only facilitates the transfer of computing load from underperforming server areas to overperforming server areas, but also ensures that each migration operation will not cause new overloads or performance degradation in the target container by setting a hard condition that "the balanced load value is less than the preset load threshold". This improves overall resource utilization while ensuring the stability and service quality of the system after migration.

[0128] In one possible implementation, such as Figure 2 As shown, after migrating cloud applications in at least one cloud server group, the method further includes:

[0129] Step S201: Obtain the computing power capacity, energy consumption data, and task crack data of the target container;

[0130] Step S202: Determine the exclusivity between the target container and its cloud server based on the computing power capacity, energy consumption data, task crack data, and the resource consumption of the version rollback of the cloud application to be mounted in the running status parameters.

[0131] Step S203: Execute the corresponding energy-saving strategy based on the exclusionary relationship.

[0132] It should be noted that existing technologies not only have the technical problems described in the background section, but also present technical issues in energy saving. Current energy-saving methods generally adopt a one-size-fits-all strategy, that is, immediately terminating the current container-cloud server mount chain when resources are idle. While this approach may seem to save resources in the short term, in practice it leads to temporary freezing and downtime of cloud servers and containers, affecting the stability and reliability of the system.

[0133] and Figure 2 The method shown can solve this technical problem. After completing the core mounting and scheduling operations—namely, maintaining the stable state of the baseline cloud server group and migrating cloud applications from the inefficient cloud server group to the target containers of the efficient cloud server group—it can be started. Figure 2 As shown, this is the monitoring and adjustment phase aimed at achieving long-term stability and energy efficiency optimization.

[0134] Specifically, after the cloud application completes remounting and runs for a first preset time period (e.g., 1 hour), the system proactively collects the target container's computing capacity, energy consumption data generated during actual operation, and task fragmentation data reflecting the integrity and reliability of task execution. Subsequently, the system comprehensively analyzes this real-time operational data along with the pre-known resource consumption of the cloud application's version rollback from the operational status parameters, and the target container's own computing capacity. Using a specific algorithm (detailed in the subsequent implementation), it determines the incompatibility between the target container and its host cloud server. Finally, based on this incompatibility, the system automatically triggers and executes corresponding differentiated energy-saving strategies.

[0135] In conclusion, Figure 2The method described describes an intelligent, data-driven post-optimization mechanism that overcomes the limitations of initial static mounting decisions. By monitoring the actual operating status and determining the exclusivity between the target container and its cloud server, it determines energy-saving strategies. This makes the execution of energy-saving strategies no longer blind but precise and adaptive. Thus, while attempting to reduce energy consumption, it maximizes the stability and reliability of the cloud application operating environment, achieving an effective balance between energy saving and performance maintenance.

[0136] In one possible implementation, a quantified comprehensive repulsion index can be determined based on the repulsion, and a corresponding energy-saving strategy can be executed based on the comprehensive repulsion index. Specifically, this includes: comparing the comprehensive repulsion index with a preset repulsion threshold; if the comprehensive repulsion index value is greater than the preset repulsion threshold, it is determined that the repulsion between the target container and the cloud server is strong; otherwise, it is determined that the repulsion between the target container and the cloud server is weak. If the repulsion is determined to be strong, a first energy-saving strategy is executed, which is to cancel the operation of the target container from an active state to a sleep state and keep the target container in an active state. If the repulsion is determined to be weak, a second energy-saving strategy is executed, which is to allow the target container to enter a shallow sleep state when the computing power load rate of the cloud server where the target container is located is less than a preset sleep load threshold, or when the computing power fluctuation of the cloud server where the target container is located is less than a preset sleep fluctuation threshold; and when it is detected that the computing power load rate of the cloud server where the target container is located reaches a preset wake-up load threshold, or when the computing power fluctuation of the cloud server where the target container is located is greater than a preset wake-up fluctuation threshold, a wake-up operation is performed on the target container.

[0137] It should be noted that the specific decision-making and execution process for implementing the corresponding energy-saving strategy based on the comprehensive rejection index is as follows: The system first compares the calculated comprehensive rejection index with a pre-set rejection threshold, and makes a clear judgment based on the comparison result: if the comprehensive rejection index value is greater than the preset rejection threshold, it is determined that there is a strong rejection between the target container and the cloud server it is located on; otherwise, it is determined that there is a weak rejection between the target container and the cloud server it is located on.

[0138] Based on this determination, the system will execute a completely different energy-saving strategy: if the rejection is strong, the first energy-saving strategy will be activated. The core of this strategy is to cancel the standard operation that the target container may automatically transition from an active state to a sleep state, and instead force the target container to remain in an active working state to avoid performance problems that may be caused by state switching in an unstable environment.

[0139] If the rejection is determined to be weak, a second energy-saving strategy is executed. This strategy is more refined and allows the target container to enter a low-power shallow sleep state when certain conditions are met. These conditions include the real-time computing load rate of the cloud server where the target container resides being lower than a preset sleep load threshold, or the computing power fluctuation amplitude being less than a preset sleep fluctuation threshold. At the same time, this strategy also specifies a wake-up mechanism. When the computing power load rate of the cloud server is detected to rise to a preset wake-up load threshold, or the computing power fluctuation increases beyond a preset wake-up fluctuation threshold, the system will immediately perform a wake-up operation on the target container in the shallow sleep state, restoring it to an active state to cope with the load.

[0140] In summary, by accurately determining the power status of containers based on objective indicators, refined and adaptive management is achieved, thereby effectively reducing energy consumption where possible and prioritizing business continuity when there are stability risks, thus achieving the best balance between energy efficiency and system reliability.

[0141] In one possible implementation, if the exclusion is determined to be weak, after executing the second energy-saving strategy, the method further includes: determining a second ratio between the computing load rate of the cloud server where the target container is located and the computing power fluctuation of the cloud server where the target container is located; comparing the second ratio with a preset stability threshold; when the second ratio is lower than the preset stability threshold, executing a third energy-saving strategy, wherein the third energy-saving strategy is: monitoring the number of dependencies of the cloud applications to be mounted in the key parameters; when the fluctuation of the number of dependencies of the cloud applications to be mounted within a second preset time period is greater than a preset architecture fluctuation threshold, waking up the target container.

[0142] It should be noted that after the system determines that the target container and the cloud server have a weak exclusion relationship and has implemented a second energy-saving strategy that allows it to enter a shallow sleep state under certain conditions, the method also includes a deeper monitoring and protection mechanism designed to prevent potential risks. Specifically, it first calculates another key operational metric of the cloud server hosting the target container: the second ratio between the cloud server's computing load rate and its computing power fluctuation. This second ratio is then compared to a preset stability threshold used to measure system operational stability. When the comparison reveals that this second ratio is lower than the preset stability threshold, it indicates that although the system load is not high, the relative fluctuation may be significant, placing it in a metastable state that requires special attention. At this point, the system will automatically activate and execute a third energy-saving strategy. The core of the third energy-saving strategy is to continuously monitor a specific indicator among the key parameters: the number of dependencies of the cloud applications to be mounted. Once it is detected that the number of dependencies of the cloud applications to be mounted changes by more than the preset architecture fluctuation threshold in the next second preset time period, it means that the internal architecture dependency of the cloud application may be undergoing significant changes, which may pose a potential risk of a sudden increase in performance demand. The system will then immediately and proactively wake up the target container that is in a shallow sleep state, so that it can be restored to an active state in advance to cope with the possible load.

[0143] In summary, energy-saving strategies can be upgraded from simply responding to the current load status to proactively responding to potential risks caused by changes in the application's internal architecture. This maximizes the extension of low-power sleep time while greatly enhancing the system's insight into hidden performance fluctuations and its ability to respond quickly. It effectively avoids response delays or service interruptions caused by sudden changes in application dependencies, further improving the system's robustness in the energy efficiency optimization process.

[0144] In specific application scenarios, after completing gradient grouping and update mounting operations, the system runs the cloud server stably for a period of time and collects energy consumption data E (energy consumption data E is the basic runtime state data, which can be collected in real time during operation) and task fragmentation data Q during this period. Based on these two types of data, an energy efficiency health score can be determined. Furthermore, the incompatibility relationship between containers and cloud applications can be further analyzed, thereby comprehensively considering these factors to determine a comprehensive incompatibility index, and then selecting an appropriate cooling strategy (i.e., energy-saving strategy). This step aims to reorganize the resources of the remounted containers, improving the utilization rate of the container's internal space by releasing fragmented space.

[0145] The selection logic for the cooling strategy is as follows: First, the energy efficiency health score is determined based on the energy consumption data E and the task crack data Q collected during the stable operation phase.

[0146] The task fragment data Q represents the amount of fragment space occupied by a cloud task during container operation, and is composed of task space fragment data Q1 and task equivalent fragment data Q2.

[0147] Mission Space Rift Data Q1: ;

[0148] in, These represent specific coefficients or performance parameters for cloud-based applications, which are related to the application's characteristics or configuration. ρ represents the ruggedness or complexity of the container space, while ρ represents density or resource utilization, which is related to the efficiency of resource allocation and use within the container. This is the sum of energy dissipation and workload. The ruggedness of the container space can be understood as the irregularity and complexity of the container's internal space.

[0149] By combining the performance parameters of cloud applications, the complexity of container space, resource utilization, and changes in energy dissipation, task space crack data (Q1) is calculated. This data can be used to evaluate the performance or stability of cloud applications running in a container environment, especially space cracks or resource allocation problems that may occur during mounting.

[0150] Equivalent Crack Data Q2: The equivalence of cloud-based tasks needs to be calculated. Equivalence refers to the equivalent value that cloud-based applications in the same group can generate when achieving the same running goal in a container. This value generally refers to the ratio between the task's consumption and output capabilities.

[0151] Q2=Q1-P*Rjc

[0152] Where P represents the equivalent value generated, and Rjc is the loss coefficient under the same objective. This formula is used to quantify the equivalence of cloud-based tasks in achieving the same objective, taking into account the task's consumption and output capabilities, and helping to optimize resource allocation and improve task efficiency.

[0153] And Q = Q1 + Q2

[0154] Additionally, the ratio of resource consumption during version rollback of the cloud application to be mounted to the basic computing power capacity can be calculated. This ratio is then weighted and summed with the energy efficiency health score to obtain a comprehensive rejection index. This comprehensive rejection index is compared to a preset rejection threshold. If the comprehensive rejection index value is greater than the preset rejection threshold, the rejection between the target container and its host cloud server is determined to be strong; otherwise, the rejection is determined to be weak.

[0155] If the rejection is determined to be strong, the first energy-saving strategy is selected, which directly cancels the operation of switching the container from an active state to a sleep state. If the rejection is determined to be weak, the second energy-saving strategy is adopted, with the following rules: when the computing power load rate of the server hosting the container is below 80% or the computing power fluctuation is less than 5%, the container is allowed to enter a shallow sleep; however, when the load rate rises to 40% or the computing power fluctuation exceeds 3.2%, it is immediately woken up.

[0156] If the second energy-saving strategy is selected, the system will further evaluate the ratio of server computing load rate to its fluctuation. If this ratio is lower than a certain set threshold, it indicates that the system is in an unstable state of low load but high fluctuation. The second energy-saving strategy may not be able to balance energy efficiency and stability, and in this case, a switch to the third energy-saving strategy is required. The third energy-saving strategy adds a floating monitoring mechanism to the second energy-saving strategy to continuously monitor the number of dependencies N_n of cloud applications. If the fluctuation of N_n exceeds 50% within a specific time period T, the system will wake up the containers in advance to cope with potential sudden changes in performance requirements.

[0157] In this embodiment, by responding to trigger events to obtain cloud server performance evaluation parameters, the performance status of the cloud servers can be dynamically perceived. Then, performance evaluation is performed on the cloud servers based on these parameters, and evaluation results are obtained, thereby enabling quantitative measurement of the performance of each cloud server. Based on the evaluation results, all cloud servers are divided into groups with different performance levels, and cloud applications are migrated between groups by unmounting and / or remounting containers, allowing the load to be dynamically adjusted between different cloud server groups. In summary, through a performance-based cloud server gradient grouping and dynamic cloud application migration mechanism, intelligent scheduling and load balancing of cloud server resources are achieved, thereby improving overall resource utilization efficiency and the stability of cloud application operation.

[0158] Furthermore, the container mounting method shown in the embodiments of this application (refer to...) Figure 3 It has the following technical effects:

[0159] The terminal sends a packaging request for the cloud application to be mounted to the cloud server. This request includes runtime status parameters such as the number of dependencies, configuration type PT value, version rollback cost ER, and rollback cost controllability ER-C. The cloud server can then accurately calculate the unsaturated differential value (DSV) for the container in the current task environment based on these parameters. This allows the cloud server to more precisely adapt to containers and improve resource utilization. Based on the unsaturated differential value (DSV), the container's state, and the cloud server's current task state, the execution differential value (Gj) is used to obtain the container adaptation and seamless mounting matching probability (Sprb) between servers in the current task environment. This helps ensure efficient task execution on the cloud server, reducing latency and interruptions. Based on the seamless mounting matching probability (Sprb) and the container's unsaturated differential value (DSV), the cloud servers are grouped in a gradient manner. This grouping method enables the system to manage cloud servers more intelligently. Based on the balanced load values ​​of different gradient groups, the system differentially selects target containers for mounted cloud applications and performs update mounting operations, thereby achieving dynamic resource allocation and optimization.

[0160] After the cloud application is remounted and runs for a first preset time period (e.g., 1 hour), the system actively collects the target container's computing capacity, energy consumption data generated during actual operation, and task fragment data reflecting the integrity and reliability of task execution. Combined with the resource consumption of the cloud application version rollback in the running status parameters, the system determines the incompatibility between the target container and its host cloud server, and then selects either a first or second energy-saving strategy. This effectively reduces server energy consumption and improves energy efficiency. If the second energy-saving strategy is selected, further evaluation of the ratio of computing load rate and fluctuation is needed to determine whether a transition between the second and third energy-saving strategies is required. This flexible strategy adjustment mechanism dynamically adjusts the energy-saving strategy based on the server's actual operating status, ensuring that energy consumption is minimized while guaranteeing normal task execution. By collecting runtime energy consumption data and task fragment data, the system can monitor the server's operating status in real time, promptly identify and address potential problems, and ensure stable server operation.

[0161] New evaluation metrics are proposed, including Version Rollback Cost (ER), Rollback Cost Controllability (ER-C), Matching Gapless Execution Probability (Sprb), and Unsaturated Differential Value (DSV). These metrics can quantitatively evaluate the operational status and performance of cloud applications on cloud servers, providing strong data support for system optimization and management. By detailing the generation process and specific meaning of these metrics, system administrators and developers can better understand the system's operation, thereby enabling targeted performance optimization and adjustments to improve the overall system performance and stability. These evaluation metrics provide a scientific basis for system decision-making; for example, in selecting energy-saving strategies, allocating resources, and scheduling tasks, more reasonable and effective decisions can be made based on these metrics.

[0162] A novel grouping method is proposed, based on which a self-developed differential update and mounting operation is performed. This grouping method enables more scientific classification and management of cloud servers, improving resource allocation efficiency and utilization. The concept of differential mounting makes cloud application update and mounting operations more flexible and efficient. Through differential mounting, the mounted containers can be dynamically adjusted according to the server's load and task requirements, achieving dynamic resource allocation and optimization, and improving system response speed and performance.

[0163] Figure 4 This application illustrates a container mounting device according to an embodiment of the present application. The device is applied to a cloud platform containing at least one cloud server, the cloud server containing containers, such as... Figure 4 As shown, the device includes:

[0164] Module 401 is used to obtain the performance evaluation parameters of the cloud server in response to the triggering event;

[0165] Execution module 402 is used to perform performance evaluation on each cloud server according to performance evaluation parameters and obtain evaluation results;

[0166] Based on the evaluation results, all cloud servers included in the cloud platform are grouped in a tiered manner to obtain at least one cloud server group, and each cloud server group corresponds to a performance level.

[0167] Migrate cloud applications in at least one cloud server group by unmounting and / or remounting containers.

[0168] In one possible implementation, the triggering event includes at least one of the following: receiving a packaging request from the terminal for a cloud application to be mounted to the container, the packaging request carrying runtime status parameters; or monitoring that the performance indicators of the cloud server have reached a preset performance indicator threshold.

[0169] In one possible implementation, when the triggering event is receiving a packaging request from the terminal for a cloud application to be mounted to the container, the performance evaluation parameters include: runtime status parameters and the container's status.

[0170] In one possible implementation, the execution module 402 is further configured to determine the unsaturated differential value corresponding to the container on the cloud server based on the running status parameters.

[0171] Based on the running status parameters and the status of the containers on the cloud server, determine the possibility of seamless execution of the mounting and matching between the containers and the cloud server.

[0172] The comprehensive score of each cloud server is determined based on the unsaturated differential value and the possibility of seamless execution of the mount matching, and the comprehensive score is used as the evaluation result.

[0173] In one possible implementation, the runtime status parameters include: the number of dependencies of the cloud applications to be mounted, the configuration type value, the resource consumption of version rollback, the controllability of version rollback, and the ratio between debug and production packages.

[0174] The execution module 402 is also used to determine the unsaturated differential speed value based on the number of dependency relationships, configuration type value, resource consumption and controllability;

[0175] The execution module 402 is also used to determine the task status execution differential of the cloud server based on the unsaturated differential value and the proportional relationship; and to determine the possibility of seamless execution of the mounting match between the container and the cloud server based on the unsaturated differential value, the task status execution differential, and the status of the container on the cloud server.

[0176] In one possible implementation, the execution module 402 is further configured to divide all cloud servers included in the cloud platform into an inefficient cloud server group and an efficient cloud server group based on the relationship between the comprehensive score and the preset energy efficiency threshold; and to determine a baseline cloud server group from the inefficient cloud server group and / or the efficient cloud server group based on the comprehensive score and the number of sub-shards contained in the container.

[0177] In one possible implementation, the execution module 402 is further configured to unmount the cloud application in the inefficient cloud server group from the currently mounted container and remount it to the target container in the efficient cloud server group; wherein the balanced load value of the target container is less than a preset load threshold.

[0178] In one possible implementation, the execution module 402 is further configured to, after migrating a cloud application in at least one cloud server group, obtain the computing power capacity, energy consumption data, and task rift data of the target container; determine the exclusivity between the target container and its cloud server based on the computing power capacity, energy consumption data, task rift data, and the resource consumption of the version rollback of the cloud application to be mounted in the running status parameters; and execute the corresponding energy-saving strategy based on the exclusivity.

[0179] In this embodiment, by responding to a trigger event to obtain the performance evaluation parameters of the cloud server, the performance status of the cloud server can be dynamically perceived; then, the cloud server is evaluated based on the performance evaluation parameters and the evaluation results are obtained, thereby enabling quantitative measurement of the performance of each cloud server; based on the evaluation results, all cloud servers are divided into groups with different performance levels, and cloud applications are migrated between groups by unmounting and / or remounting containers, so that the load can be dynamically adjusted between different cloud server groups.

[0180] In summary, by using a performance-based cloud server gradient grouping and cloud application dynamic migration mechanism, intelligent scheduling and load balancing of cloud server resources are achieved, thereby improving overall resource utilization efficiency and the stability of cloud application operation.

[0181] This application provides a network device 50, such as... Figure 5 As shown, the network device 50 includes a processor 501, a memory 502, and a program stored in the memory 502 and executable on the processor 501. When the program is executed by the processor 501, it implements the steps of a container mounting method as shown in the above embodiment.

[0182] This application also provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the steps of a container mounting method as shown in the above embodiments and achieves the same technical effect. To avoid repetition, it will not be described again here. The computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0183] This application also provides a computer program product, including computer instructions. When executed by a processor, the computer instructions implement the steps of the container mounting method shown in the above embodiments and achieve the same technical effect. To avoid repetition, they will not be described again here.

[0184] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0185] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0186] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A method for mounting a container, characterized in that, The method is applied to a cloud platform containing at least one cloud server, the cloud server containing containers, and the method includes: In response to the triggered event, obtain the performance evaluation parameters of the cloud server; The performance of each cloud server is evaluated based on the aforementioned performance evaluation parameters to obtain the evaluation results. Based on the evaluation results, all cloud servers included in the cloud platform are grouped in a gradient manner to obtain at least one cloud server group, and each cloud server group corresponds to a performance level. Migrate cloud applications in at least one cloud server group by unmounting and / or remounting the container.

2. The method according to claim 1, characterized in that, The triggering event includes at least one of the following: The system receives a packaging request from the terminal for a cloud application to be mounted to the container, the packaging request carrying runtime status parameters. The performance indicators of the cloud server were monitored and found to have reached the preset performance indicator threshold.

3. The method according to claim 2, characterized in that, When the triggering event is receiving a packaging request from the terminal for a cloud application to be mounted to the container, the performance evaluation parameters include: the running status parameters and the status of the container.

4. The method according to claim 3, characterized in that, The performance of each cloud server is evaluated based on the aforementioned performance evaluation parameters to obtain evaluation results, including: The unsaturated differential value corresponding to the container on the cloud server is determined based on the operating status parameters. Based on the running status parameters and the status of the container on the cloud server, determine the possibility of seamless execution of the mounting and matching between the container and the cloud server; The comprehensive score of each cloud server is determined based on the unsaturated differential value and the probability of seamless execution of the mount matching, and the comprehensive score is used as the evaluation result.

5. The method according to claim 4, characterized in that, The running status parameters include: the number of dependencies of the cloud application to be mounted, the configuration type value, the resource consumption of version rollback, the controllability of version rollback, and the ratio between debug and official packages. Determining the unsaturated differential value corresponding to the container on the cloud server based on the operating status parameters includes: The unsaturated differential speed value is determined based on the number of dependency relationships, the configuration type value, the resource consumption, and the controllability. The step of determining the seamless execution probability of mounting and matching between the container and the cloud server based on the running status parameters and the status of the container on the cloud server includes: The task status execution differential of the cloud server is determined based on the unsaturated differential value and the proportional relationship. Based on the unsaturated differential value, the task status execution differential, and the status of the container on the cloud server, the possibility of seamless execution of the mounting match between the container and the cloud server is determined.

6. The method according to claim 4, characterized in that, Based on the evaluation results, all cloud servers included in the cloud platform are tiered and grouped to obtain at least one cloud server group, including: Based on the relationship between the comprehensive score and the preset energy efficiency threshold, all cloud servers included in the cloud platform are divided into an inefficient cloud server group and an efficient cloud server group. Based on the overall score and the number of sub-shards contained in the container, a benchmark cloud server group is determined from the inefficient cloud server group and / or the efficient cloud server group.

7. The method according to claim 6, characterized in that, The migration of cloud applications in at least one cloud server group by unmounting and / or remounting the container includes: The cloud application in the inefficient cloud server group is unmounted from its currently mounted container and remounted to the target container in the efficient cloud server group; wherein the balanced load value of the target container is less than a preset load threshold.

8. The method according to claim 7, characterized in that, After migrating the cloud application in the at least one cloud server group, the method further includes: Obtain the computing capacity, energy consumption data, and task crack data of the target container; Based on the computing power capacity, the energy consumption data, the task crack data, and the resource consumption of the version rollback of the cloud application to be mounted in the running status parameters, the exclusivity between the target container and its cloud server is determined. The corresponding energy-saving strategy is executed based on the exclusionary property.

9. A container mounting device, characterized in that, The apparatus is applied to a cloud platform comprising at least one cloud server, the cloud server comprising a container, and the apparatus includes: The acquisition module is used to acquire the performance evaluation parameters of the cloud server in response to a triggering event; The execution module is used to perform performance evaluation on each cloud server according to the performance evaluation parameters and obtain the evaluation results. Based on the evaluation results, all cloud servers included in the cloud platform are grouped in a gradient manner to obtain at least one cloud server group, and each cloud server group corresponds to a performance level. Migrate cloud applications in at least one cloud server group by unmounting and / or remounting the container.

10. A network device, characterized in that, include: A processor, a memory, and a program stored in the memory and executable on the processor, wherein the program, when executed by the processor, implements the steps of a container mounting method as described in any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of a container mounting method as described in any one of claims 1 to 8.

12. A computer program product, characterized in that, It includes computer instructions that, when executed by a processor, implement the steps of a container mounting method as described in any one of claims 1 to 8.

Images