Container migration control method, system, and electronic device

Abstract

The application provides a container migration control method and system and electronic equipment, and relates to the field of container scheduling control. The method can simulate the container migration problem as an optimization problem. Specifically, the placement and migration of the container are simulated as specific attack and defense processes. Through iterative optimization, the minimum server load standard deviation is taken as the target, and finally the optimal strategy for container migration is found. Thus, the local optimal problem that may occur in the traditional container migration process is avoided, and the comprehensive improvement of resource utilization, load balancing and service quality is realized.

Description

Technical Field

[0001] This invention relates to the field of container scheduling and control, and in particular to a container migration control method, system, and electronic device. Background Technology

[0002] With the rapid development of cloud computing, edge computing, and computing power scheduling platforms, container technology, with its advantages of lightweight, portability, and elastic scalability, has become the core carrier for deploying and running various applications. Container migration, as a key technology for achieving dynamic resource scheduling, load balancing, and fault recovery, directly determines the overall performance and resource utilization of the computing power platform. However, current mainstream container migration methods still face many significant challenges. These problems become increasingly prominent in scenarios involving large-scale clusters, high dynamic loads, and multi-resource collaborative scheduling, severely restricting the effectiveness of computing power scheduling platforms.

[0003] For example, traditional threshold-based migration strategies typically rely on preset fixed resource utilization thresholds (e.g., 80% CPU utilization, 75% memory utilization). When node resource usage reaches these thresholds, container migration is triggered. The biggest drawback of this strategy is the mismatch between the rigidity of the threshold setting and the dynamic nature of load changes. In real-world scenarios, application loads often exhibit sudden and periodic fluctuations. Fixed thresholds cannot adapt to the load characteristics of different applications, potentially triggering unnecessary migrations during brief load peaks or missing the optimal migration opportunity when the load is continuously rising but hasn't reached the threshold. Frequent container migrations not only increase system overhead, including CPU computation, network bandwidth consumption, and container start / stop latency during the migration process, but can also cause temporary application service interruptions, impacting user experience and service availability. This impact is particularly pronounced for latency-sensitive applications (such as real-time data processing and online transactions).

[0004] Furthermore, most current simple load balancing methods often focus only on balancing the utilization of a single resource (such as CPU or memory), failing to fully consider the comprehensive utilization of various heterogeneous resources in the computing platform (such as GPUs, video memory, network bandwidth, and storage I / O), leading to a one-sided approach to resource scheduling. In actual deployments, the resource requirements of various applications are diverse: for example, deep learning tasks heavily rely on GPU computing power and video memory, big data processing tasks have high requirements for network bandwidth and storage I / O, while ordinary web applications focus more on CPU and memory resources. If only the balanced allocation of a single resource is pursued, resource fragmentation problems are very likely to occur. Some nodes may have idle CPU and memory, but their GPU video memory may be exhausted; some nodes may have sufficient network bandwidth, but have storage I / O bottlenecks, making it impossible to efficiently utilize the overall resources of the cluster. At the same time, the shortage of critical resources may also create performance bottlenecks, causing application lag, decreased task execution efficiency, or even task failure.

[0005] Existing technologies employ optimization algorithms such as container scheduling and migration algorithms based on genetic algorithms, particle swarm optimization, and reinforcement learning, attempting to improve migration efficiency and resource utilization through intelligent decision-making. However, these algorithms still have significant limitations in practical applications: some algorithms have slow convergence speeds, requiring a significant amount of time to calculate the optimal migration path in large-scale clusters (such as those containing thousands of nodes and tens of thousands of containers), making them unable to adapt to dynamic environments with rapidly changing loads; some algorithms are prone to getting trapped in local optima, only optimizing resource allocation for a single node or local area, ignoring the global resource balance of the cluster, and still experiencing resource overload or waste after long-term operation; and some algorithms have poor adaptability to dynamic environments, failing to quickly adjust migration strategies when faced with node failures, new node additions, or sudden increases or decreases in application load, leading to decision failures and making it difficult to meet the actual needs of large-scale, highly dynamic computing power scheduling platforms. Summary of the Invention

[0006] In view of this, the purpose of the present invention is to provide a container migration control method, system and electronic device. The method can simulate the container migration problem as an optimization problem, specifically simulating the placement and migration of containers as specific attack and defense processes. Through iterative optimization, with the goal of minimizing the standard deviation of server load, the optimal strategy for container migration is finally found, thereby avoiding the local optimum problem that may occur in the traditional container migration process and achieving a comprehensive improvement in resource utilization, load balancing and service quality.

[0007] In a first aspect, embodiments of the present invention provide a container migration control method, the method comprising: Based on the resource parameters of the server cluster and the requirement parameters of the container, determine the corresponding resource parameters, execution identifier and total number of iterations between the container and the server cluster, and use the resource parameters, execution identifier and total number of iterations to determine the initial running parameters of the container; The allocation strategy between containers and server clusters is determined using the initial running parameters. After constructing the container array corresponding to the container based on the allocation strategy, the solution array set corresponding to the container array is determined using the population size parameter corresponding to the container in the server cluster. Iterate through the target containers and target servers corresponding to the container array in the solution array set, control the migration of target containers to target servers based on the allocation strategy, calculate the fitness of the target container when it is allocated to the target server using the resource occupancy of the target server, and determine the remaining number of iterations between the container and the server cluster using the number of traversals and the total number of iterations. The migration update strategy corresponding to the target container is determined based on the execution identifier. The migration strategy corresponding to the target container for the remaining iterations is determined based on the migration update strategy. The container array and execution identifier are then updated using the migration strategy. The fitness and remaining iterations are updated by updating the container array; when the execution flag and remaining iterations meet the preset threshold conditions, the migration between the current container array and its corresponding fitness control container and the corresponding container in the server cluster is completed.

[0008] Optionally, the steps of determining the corresponding resource parameters, execution identifier, and total number of iterations between the container and the server cluster based on the resource parameters of the server cluster and the requirement parameters of the container, and determining the initial running parameters corresponding to the container using the resource parameters, execution identifier, and total number of iterations, include: Obtain the servers contained in the server cluster, and determine the resource parameters corresponding to the server cluster using the GPU resource parameters, video memory resource parameters, and bandwidth resource parameters of the server. Obtain the container corresponding to the server, and determine the required parameters of the container using the GPU requirement parameters, video memory requirement parameters, and bandwidth requirement parameters of the container. The GPU resource weight, video memory resource weight, and bandwidth resource weight of the server in the server cluster are determined by resource parameters and demand parameters, and the corresponding resource parameters between the container and the server cluster are determined by GPU resource weight, video memory resource weight, and bandwidth resource weight. Based on resource parameters, obtain the execution time parameters corresponding to the container and the population size parameters corresponding to the container in the server. Use the time parameters and population size parameters to determine the total number of iterations between the container and the server cluster. The execution identifier between the container and the server cluster is determined based on resource parameters, and the initial running parameters of the container are determined by resource parameters, execution identifier and total number of iterations.

[0009] Optionally, the steps of determining the allocation strategy between containers and server clusters using initial running parameters, constructing container arrays corresponding to containers using the allocation strategy, and determining the solution array set corresponding to the container arrays using the population size parameters corresponding to containers in the server cluster include: The number of containers corresponding to the containers and the number of servers in the server cluster are determined by the initial running parameters. The container number and the server number corresponding to each server in the server cluster are then determined by the number of containers and the number of servers. The allocation strategy between containers and server clusters is determined based on the random allocation instruction between container number and server number; Iterate through all containers by container number, randomly assign servers to containers according to the allocation strategy, and then construct the container array corresponding to the container using the container number and server number that have been allocated. The number of iterations for each container is determined based on the population size parameter of the container in the server cluster. After iterating through all containers using the number of iterations, the solution array set corresponding to the container array is obtained.

[0010] Optionally, the steps of traversing the target containers and target servers corresponding to the container arrays in the solution array set, controlling the migration of target containers to target servers based on the allocation strategy, calculating the fitness of the target containers when allocated to the target servers using the resource occupancy of the target servers, and determining the remaining number of iterations between the containers and the server cluster using the number of traversals and the total number of iterations include: The target container is determined based on the container number corresponding to the container array, and the target server corresponding to the target container under the allocation strategy is obtained. Traverse the target containers in the container array according to the container number, control the migration of the target containers to the target server through the allocation strategy, determine the resource utilization of the target server through the GPU utilization, video memory utilization and bandwidth utilization of the target server, and obtain the traversal number of the target container in real time. Calculate the load value corresponding to the target server based on the resource occupancy rate, and use the load value to determine the fitness function corresponding to the target container when it is allocated to the target server. The fitness function is used to calculate the fitness of the target container when it is assigned to the target server, and the difference between the total number of iterations and the number of traversals is used to determine the remaining number of iterations between the container and the server cluster.

[0011] Optionally, the step of calculating the load value corresponding to the target server based on the resource occupancy rate, and using the load value to determine the fitness function corresponding to the target container when it is allocated to the target server, includes: The GPU resource weight, video memory resource weight, and bandwidth resource weight corresponding to the server are obtained through resource parameters. Based on the GPU utilization, video memory utilization, and bandwidth utilization corresponding to the resource utilization, the load value corresponding to the target server is calculated using the GPU resource weight, video memory resource weight, and bandwidth resource weight. The average load value of the servers in the server cluster is calculated using the load value, and the fitness function corresponding to the target container when it is allocated to the target server is determined by the average load value, the load value, and the number of servers in the server cluster.

[0012] Optionally, the steps of determining the migration update strategy corresponding to the target container based on the execution identifier, determining the migration strategy corresponding to the target container for the remaining iterations based on the migration update strategy, and updating the container array and execution identifier using the migration strategy include: If the execution flag is equal to the preset first flag, then the attack strength value corresponding to the target container is calculated using the remaining number of iterations and the total number of iterations, and the target container array corresponding to the minimum fitness in the solution array set is obtained; The first migration update strategy for the target container in the container array is determined by using the attack intensity value and the number of containers corresponding to the container; The first migration strategy for the target container is determined by the first migration update strategy for the remaining number of iterations. Based on the first migration strategy, the allocation value corresponding to the target container in the container array is updated to the target allocation value corresponding to the target container array, and the execution flag is updated by increasing the preset step size.

[0013] Optionally, the steps of determining the migration update strategy corresponding to the target container based on the execution identifier, determining the migration strategy corresponding to the target container for the remaining iterations based on the migration update strategy, and updating the container array and execution identifier using the migration strategy include: If the execution flag is equal to the preset second flag, then the defense strength value corresponding to the target container is calculated using the random value of the preset interval, the remaining number of iterations, and the total number of iterations; Randomly obtain the first target container and the second target container contained in the target container array. Determine the second migration update strategy corresponding to the first target container and the second target container in the container array based on the first allocation value corresponding to the first target container, the second allocation value corresponding to the second target container, the defense strength value, and the number of containers corresponding to the container. The second migration strategy is determined by the second migration update strategy for the first target container and the second target container in the remaining number of iterations. After updating the allocation value of the first target container to the second allocation value using the second migration strategy, and then updating the allocation value of the second target container to the first allocation value, the execution flag is updated using a preset step size.

[0014] Optionally, the steps of determining the migration update strategy corresponding to the target container based on the execution identifier, determining the migration strategy corresponding to the target container for the remaining iterations based on the migration update strategy, and updating the container array and execution identifier using the migration strategy include: If the execution flag is equal to the preset third flag, the third migration update strategy corresponding to the target container is determined by using the preset reduction step size and the remaining number of iterations, and the target container array corresponding to the minimum fitness in the solution array set is obtained. The third migration strategy for the target container is determined by the third migration update strategy for the remaining number of iterations. The third migration strategy updates the allocation value corresponding to the target container in the container array to the target allocation value corresponding to the target container array, and updates the execution flag to the initial value.

[0015] In a second aspect, the present invention provides a container migration control system, the system comprising: The initialization module is used to determine the corresponding resource parameters, execution identifier, and total number of iterations between the container and the server cluster based on the resource parameters of the server cluster and the requirement parameters of the container, and to determine the initial running parameters of the container using the resource parameters, execution identifier, and total number of iterations. The array allocation module is used to determine the allocation strategy between containers and server clusters using initial running parameters. After constructing the container array corresponding to the container using the allocation strategy, the solution array set corresponding to the container array is determined using the population size parameter corresponding to the container in the server cluster. The traversal execution module is used to traverse the target containers and target servers corresponding to the container array in the solution array set, control the migration of target containers to target servers based on the allocation strategy, calculate the fitness of the target containers when they are allocated to the target servers using the resource occupancy of the target servers, and determine the remaining number of iterations between the containers and the server cluster using the number of traversals and the total number of iterations. The strategy update module is used to determine the migration update strategy corresponding to the target container based on the execution identifier, determine the migration strategy corresponding to the target container for the remaining iterations based on the migration update strategy, and update the container array and execution identifier using the migration strategy. The migration control module is used to update the fitness and remaining iterations through the updated container array; when the execution flag and remaining iterations meet the preset threshold conditions, it uses the current container array and its corresponding fitness to control the migration of the container to the corresponding container in the server cluster.

[0016] Thirdly, embodiments of the present invention also provide an electronic device, which includes a processor and a memory, the memory storing computer-executable instructions that can be executed by the processor, the processor executing the computer-executable instructions to implement the steps of the container migration control method provided in the first aspect.

[0017] This invention provides a container migration control method, system, and electronic device. During the migration of containers within a server cluster, the method first determines the corresponding resource parameters, execution identifier, and total number of iterations between the container and the server cluster based on the resource parameters of the server cluster and the requirement parameters of the container. It then uses these parameters to determine the initial operating parameters for the container. Next, it uses the initial operating parameters to determine the allocation strategy between the container and the server cluster. After constructing a container array corresponding to the container using the allocation strategy, it uses the population size parameters of the containers in the server cluster to determine the solution array set corresponding to the container array. Finally, it iterates through the solution array set to find the target containers and target servers corresponding to the container arrays. This method controls the migration of target containers to target servers based on allocation strategies. It calculates the fitness of the target container when allocated to the target server using the server's resource occupancy, and determines the remaining iterations between the container and the server cluster using the traversal count and total iteration count. Then, it determines the migration update strategy for the target container based on the execution identifier, and based on this strategy, determines the migration strategy for the target container with the remaining iterations. The container array and execution identifier are then updated using the migration strategy. Finally, the fitness and remaining iterations are updated using the updated container array. When the execution identifier and remaining iterations meet preset threshold conditions, the migration between the container and the server cluster is completed using the current container array and its corresponding fitness. This method simulates the container migration problem as an optimization problem, specifically simulating container placement and migration as a specific attack and defense process. Through iterative optimization, aiming to minimize the server load standard deviation, it ultimately finds the optimal container migration strategy, thus avoiding the local optima problem that may occur in traditional container migration processes and achieving a comprehensive improvement in resource utilization, load balancing, and service quality.

[0018] Other features and advantages of the invention will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention are realized and obtained through the structures particularly pointed out in the description and the drawings.

[0019] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0020] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0021] Figure 1 A flowchart of a container migration control method provided in an embodiment of the present invention; Figure 2 This is a flowchart of step S101 in a container migration control method provided in an embodiment of the present invention; Figure 3 This is a flowchart of step S102 in a container migration control method provided in an embodiment of the present invention; Figure 4 This is a flowchart of step S103 in a container migration control method provided in an embodiment of the present invention; Figure 5 This is a flowchart of step S403 in a container migration control method provided in an embodiment of the present invention; Figure 6 This is a flowchart of step S104 in the first container migration control method provided in an embodiment of the present invention; Figure 7 This is a flowchart of step S104 in the second container migration control method provided in this embodiment of the invention; Figure 8 A flowchart of step S104 in the third container migration control method provided in this embodiment of the invention; Figure 9 A flowchart of another container migration control method provided in an embodiment of the present invention; Figure 10 This is a schematic diagram of the structure of a container migration control system provided in an embodiment of the present invention; Figure 11 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention.

[0022] icon: 100 - Initialization module; 200 - Array allocation module; 300 - Traversal execution module; 400 - Strategy update module; 500 - Migration control module; 101 - Processor; 102 - Memory; 103 - Bus; 104 - Communication interface. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below in conjunction with the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0024] To facilitate understanding of this embodiment, a container migration control method disclosed in this embodiment of the invention will first be introduced, such as... Figure 1 As shown, the method includes: Step S101: Based on the resource parameters of the server cluster and the requirement parameters of the container, determine the corresponding resource parameters, execution identifier and total number of iterations between the container and the server cluster, and use the resource parameters, execution identifier and total number of iterations to determine the initial running parameters corresponding to the container.

[0025] First, a comprehensive collection of various resource parameters from the server cluster (including but not limited to CPU utilization, GPU computing power, video memory capacity, network bandwidth, and storage I / O for each server) and resource requirements for each container (such as CPU percentage, memory size, and GPU resource quota required for container operation) is established. Based on this fundamental data, the resource matching parameters between the container and the server cluster, process execution identifiers (used to mark the execution status of the migration iteration process and distinguish the operational logic of different iteration stages), and the preset total number of iterations (reasonably set according to the cluster size, number of containers, and optimization accuracy requirements) are determined. Subsequently, using these parameters as input, the initial operating parameters for each container are calculated and determined according to the preset parameter initialization rules, laying the foundation for subsequent allocation strategy construction and iterative optimization.

[0026] Step S102: Determine the allocation strategy between the container and the server cluster using the initial running parameters. After constructing the container array corresponding to the container using the allocation strategy, determine the solution array set corresponding to the container array using the population size parameter corresponding to the container in the server cluster.

[0027] Based on the initial running parameters of the containers obtained in step S101, and combined with the resource matching relationship between containers and servers, the initial allocation strategy between containers and server clusters is determined (i.e., the running server corresponding to each container in the initial state). According to this allocation strategy, a container array is constructed to record container allocation information (each element in the array corresponds to a container and its initially allocated server node). Then, combined with the population size parameter corresponding to the containers in the server cluster (used to control the number of candidate solutions during iterative optimization), a solution array set corresponding to the container array is constructed through random generation or rule generation. Each solution array corresponds to a possible container-server allocation scheme, forming a candidate solution space for iterative optimization.

[0028] Step S103: Traverse the target containers and target servers corresponding to the container array in the solution array set, control the migration of target containers to target servers based on the allocation strategy, calculate the fitness of the target containers when they are allocated to the target servers using the resource occupancy of the target servers, and determine the remaining number of iterations between the containers and the server cluster using the number of traversals and the total number of iterations.

[0029] Each solution array in the solution array set is traversed one by one, identifying the target container (the container to be migrated or adjusted) and the target server (the server node to which the container is to be allocated) for each solution array. Based on the allocation strategy determined in step S102, the target container is migrated to the corresponding target server. After migration, the resource occupancy rate of the target server is collected in real time. Combined with a preset fitness function (the core objective is to minimize the standard deviation of server load), the fitness value corresponding to the target container when allocated to the target server is calculated (a higher fitness value indicates a better load balancing effect and higher resource utilization of the allocation scheme). Simultaneously, the current traversal count (i.e., the number of iterations completed) is recorded. By subtracting the current traversal count from the total number of iterations, the remaining number of iterations between the container and the server cluster is determined, providing a basis for subsequent iteration updates.

[0030] Step S104: Determine the migration update strategy corresponding to the target container based on the execution identifier, determine the migration strategy corresponding to the target container in the remaining iterations based on the migration update strategy, and update the container array and execution identifier using the migration strategy.

[0031] Based on the execution identifier determined in step S101, the target container migration and update strategy corresponding to the current iteration stage is determined (different execution identifiers correspond to different update logics; for example, the focus is on expanding the optimization range in the early stage of the iteration, and on local optimization in the later stage). Based on this migration and update strategy, combined with the fitness value obtained in step S103 and the remaining number of iterations, the optimal migration strategy for the target container within the remaining number of iterations is analyzed and determined (including whether to continue migration, which server to migrate to, the migration priority, etc.). Subsequently, according to this migration strategy, the container array is updated (synchronously recording the latest allocation status of the containers) and the execution identifier (marking the completion status of the current iteration stage, providing a basis for selecting the update strategy for the next iteration).

[0032] Step S105: Update the fitness and remaining iterations using the updated container array; when the execution flag and remaining iterations meet the preset threshold conditions, use the current container array and its corresponding fitness to control the migration between the container and the corresponding container in the server cluster.

[0033] Based on the container array updated in step S104, the fitness value corresponding to each container allocation scheme is recalculated, and the remaining iteration count is updated (subtracting the currently completed iteration round). Then, it is determined whether the execution flag and the remaining iteration count meet a preset threshold condition (the preset threshold condition can be set as: the execution flag indicates iteration optimization is complete, the remaining iteration count is 0, or the current fitness value reaches a preset optimal threshold). If this condition is met, the iterative optimization process is stopped, and based on the allocation scheme corresponding to the current container array (i.e., the optimal allocation scheme) and its corresponding fitness value, all containers are controlled to complete the final migration operation between the server cluster, achieving the goal of load balancing and efficient resource utilization. If the condition is not met, the process returns to step S103 and continues with the next iteration.

[0034] Step S101, as the initial parameter configuration step of the container migration control method, focuses on completing the basic resource data collection and initial parameter determination to support subsequent iterative optimization. Optionally, step S101 involves determining the corresponding resource parameters, execution identifier, and total number of iterations between the container and the server cluster based on the resource parameters of the server cluster and the container's requirement parameters, and then using the resource parameters, execution identifier, and total number of iterations to determine the initial running parameters corresponding to the container. Figure 2 As shown, it includes: Step S201: Obtain the servers contained in the server cluster, and determine the resource parameters corresponding to the server cluster using the GPU resource parameters, video memory resource parameters and bandwidth resource parameters corresponding to the servers.

[0035] First, using the server list Obtain a comprehensive list of all available server nodes in the server cluster (excluding faulty, offline, and maintenance nodes), and analyze each server... Accurately collect parameters related to its core heterogeneous resources, with a focus on GPU resource parameters. (e.g., GPU model, computing power, number of available cores), video memory resource parameters (Such as total video memory capacity, occupied capacity, and available capacity) and bandwidth resource parameters (Such as peak network bandwidth, real-time available bandwidth, and data transmission latency). By summarizing, organizing, and standardizing these parameters, cluster resource parameters that comprehensively reflect the overall resource supply capacity of the server cluster are ultimately formed, providing basic data support for subsequent resource matching and weight calculation.

[0036] Step S202: Obtain the container corresponding to the server, and determine the required parameters of the container using the GPU requirement parameters, video memory requirement parameters and bandwidth requirement parameters corresponding to the container.

[0037] By container list Synchronously retrieve all containers currently deployed on each node of the server cluster, and combine each container Based on the operational characteristics and task requirements, we collect the corresponding resource requirement parameters, focusing particularly on the GPU requirement parameters corresponding to the server cluster resource parameters. (Such as GPU computing power quota and core usage required for container operation), and video memory requirements. (Such as the required video memory capacity and peak usage for container operation) and bandwidth requirements. (Such as the minimum and peak bandwidth required for container data transmission). These requirements are categorized, statistically analyzed, and verified to ensure their accuracy and completeness. Ultimately, the independent resource requirements for each container are determined, clarifying the specific resource consumption needs of each container on the cluster.

[0038] Step S203: Determine the GPU resource weight, video memory resource weight, and bandwidth resource weight of the server in the server cluster through resource parameters and demand parameters, and use the GPU resource weight, video memory resource weight, and bandwidth resource weight to determine the corresponding resource parameters between the container and the server cluster.

[0039] Based on the server cluster resource parameters obtained in step S201 and the container requirement parameters determined in step S202, a preset weight allocation algorithm is used to calculate the GPU resource weight corresponding to each server in the server cluster. Memory resource weight and bandwidth resource weight The weighting allocation needs to be dynamically adjusted based on the scarcity of resources and the urgency of containers' needs for various resources (for example, the weight of GPUs can be appropriately increased when GPU resources are scarce, and the weight of GPU memory should be increased when containers have high demands for video memory). Subsequently, the weights of the above three types of resources are integrated, and corresponding resource parameters that reflect the resource matching degree between containers and server clusters are obtained through weighted calculation, thus clarifying the resource adaptation relationship between the two.

[0040] Step S204: Based on the resource parameters, obtain the execution time parameters corresponding to the container and the population size parameters corresponding to the container in the server, and use the time parameters and population size parameters to determine the total number of iterations between the container and the server cluster.

[0041] Based on the resource parameters corresponding to the containers and server clusters obtained in step S203, and combined with the operating characteristics of the containers, the execution time parameter (estimated execution time) for each container to complete a single task is obtained. Simultaneously, the population size parameter P corresponding to the currently running containers in the server is collected (used to control the number of candidate solutions in subsequent iterative optimization processes, affecting optimization accuracy and efficiency). Based on the execution time parameter (to avoid excessive iteration time affecting container operation) and the population size parameter (to balance the optimization range and computational overhead), quantitative analysis is performed using a preset calculation formula to finally determine the total number of iterations T between the containers and the server cluster, ensuring that the iterative optimization process achieves optimal results without excessively consuming system resources.

[0042] Step S205: Determine the corresponding execution identifier between the container and the server cluster based on the resource parameters, and determine the initial running parameters of the container through the resource parameters, execution identifier and total number of iterations.

[0043] Based on the resource parameters corresponding to the container and server cluster obtained in step S203, and combined with the initial process requirements of iterative optimization, the execution identifier Z corresponding to the container and server cluster is determined. This identifier is used to mark the execution status of subsequent iteration processes (such as initial startup status, iterative optimization status, and iterative termination status), providing a basis for the selection of subsequent migration and update strategies. Subsequently, using the resource parameters determined in step S203, the execution identifier determined in this step, and the total number of iterations obtained in step S204 as inputs, and through preset initial parameter configuration rules, the initial running parameters corresponding to each container (including the initially allocated server nodes, running priority, initial resource allocation quota, etc.) are calculated and determined, making full preparations for the allocation strategy construction in step S102.

[0044] Step S102's core function is to complete the container allocation strategy construction, container array creation, and solution array set generation, providing a candidate solution space for subsequent iterative optimization. Optionally, step S102 involves determining the allocation strategy between containers and the server cluster using initial running parameters, constructing the container array corresponding to each container based on the allocation strategy, and then determining the solution array set corresponding to the container array using the population size parameters corresponding to the containers in the server cluster. Figure 3 As shown, including; Step S301: Determine the number of containers corresponding to the container and the number of servers in the server cluster using the initial running parameters. Then, identify the container number corresponding to the container and the server number corresponding to each server in the server cluster based on the number of containers and the number of servers.

[0045] First, extract the initial operating parameters of the containers determined in step S101, and parse out the total number of containers to be allocated and the total number of available servers in the server cluster (excluding faulty, offline nodes and nodes with insufficient resources to support containers). To facilitate accurate container and server location and efficient allocation operations, assign a unique container number to each container based on the total number of containers (e.g., sequentially numbered 1, 2, 3...N, where N is the total number of containers); simultaneously, assign a unique server number to each available server in the server cluster based on the total number of servers (e.g., sequentially numbered 1, 2, 3...M, where M is the total number of servers). These numbers serve as the core identifiers for subsequent allocation and migration operations, ensuring that each container and server can be uniquely distinguished.

[0046] Step S302: Determine the allocation strategy between the container and the server cluster based on the random allocation instruction between the container number and the server number.

[0047] Based on the container and server numbers allocated in step S301, a random allocation instruction issued by the system is received. Combined with the resource adaptation criteria included in the initial container running parameters (to avoid allocating containers with resource requirements far exceeding server capacity to corresponding servers), the initial allocation strategy between containers and the server cluster is determined. The core of this allocation strategy is to clarify the random correspondence rules between container and server numbers. That is, through the random allocation instruction, a preliminary random matching of containers and servers is achieved, while avoiding obviously unreasonable allocations (such as allocating containers requiring high GPU computing power to servers without GPUs), providing a core basis for subsequent container array construction.

[0048] Step S303: Traverse all containers by container number, randomly assign servers to containers according to the allocation strategy, and construct the container array corresponding to the container using the allocated container number and server number.

[0049] Following the order of container numbers, all containers to be allocated are traversed one by one. Based on the random allocation strategy determined in step S302, a server that meets the resource adaptation requirements is randomly assigned to each traversed container. After each container's server allocation is completed, the container number and the server number of its assigned server are immediately recorded, and these two sets of numbers are stored as a set of associated data in an array. After all containers have completed server allocation, all associated data are integrated to construct a uniquely corresponding container array X. i =[y1,y2,...,y N The container array clearly records the initial allocation state of all containers. Each array element corresponds to a container and its allocation server, providing basic data for the subsequent generation of the solution array set.

[0050] Step S304: Determine the number of traversal loops for each container based on the population size parameter corresponding to the container in the server cluster, and obtain the solution array set corresponding to the container array by traversing all containers using the number of traversal loops.

[0051] First, extract the population size parameter corresponding to the containers in the server cluster (this parameter controls the number of candidate solutions during iterative optimization, directly affecting optimization accuracy and system computational overhead; the population size needs to be reasonably set based on the number of containers and server scale). Based on this population size parameter, determine the number of traversal iterations P corresponding to each container (i.e., the number of candidate solutions to be generated; the number of traversal iterations should be consistent with the population size parameter). Then, according to the determined number of traversal iterations, traverse all containers one by one. Each traversal is based on the initial allocation state of the containers (container array), and a new container allocation scheme (i.e., a solution array) is generated by randomly adjusting the correspondence between containers and servers. After all traversal iterations are completed, integrate all generated solution arrays to form the solution array set SX={X1,X2, ...,X...} corresponding to the container array. P Each solution array in this set corresponds to a feasible container-server allocation scheme, forming a candidate solution space for subsequent iterative optimization.

[0052] Step S103 is crucial for completing the target container migration, resource occupancy collection, fitness calculation, and remaining iteration count update. It is a core evaluation and advancement step in the iterative optimization process. Optionally, step S103 involves traversing the target containers and target servers corresponding to the container arrays in the solution array set, controlling the migration of target containers to target servers based on allocation strategies, calculating the fitness of the target containers when allocated to the target servers using the resource occupancy of the target servers, and determining the remaining iteration count between the containers and the server cluster using the traversal count and the total number of iterations. Figure 4 As shown, it includes: Step S401: Determine the target container based on the container number corresponding to the container array, and obtain the target server corresponding to the target container under the allocation strategy.

[0053] First, the container array constructed in step S303 is retrieved. Based on the unique container number recorded in the container array, the target container to be processed (i.e., the container that needs to undergo migration evaluation) is accurately located. Simultaneously, combining the allocation strategy determined in step S302 (and the specific allocation scheme corresponding to the solution array in step S102), the target server corresponding to the target container under the current allocation strategy is queried. This target server must meet the resource requirement parameters of the container and correspond one-to-one with the server number recorded in the container array, ensuring that the matching relationship between the target container and the target server conforms to the candidate solution scheme of the current iteration.

[0054] Step S402: Traverse the target containers in the container array according to the container number. After the target containers are migrated to the target server by the allocation strategy, determine the resource occupancy of the target server by the GPU occupancy, video memory occupancy and bandwidth occupancy of the target server, and obtain the traversal number of the target containers in real time.

[0055] Following the order of container numbers, all target containers in the container array are traversed one by one. Based on a predetermined allocation strategy, container migration instructions are triggered to smoothly migrate the target containers to their corresponding target servers (ensuring uninterrupted core container processes and minimizing service latency during migration). After migration, various resource usage data of the target servers are collected in real time, with a focus on GPU utilization. (GPU computing power used / total GPU computing power), VRAM usage rate (Used video memory / total video memory) and bandwidth utilization (Used bandwidth / Total bandwidth) By comprehensively quantifying these three core indicators, the overall resource utilization of the target server is determined, which intuitively reflects the load status of the target server; at the same time, the number of target containers that have been traversed is recorded in real time, and the current traversal number (i.e. the number of iteration evaluation rounds that have been completed) corresponding to the target container is determined.

[0056] Step S403: Calculate the load value corresponding to the target server based on the resource occupancy rate, and use the load value to determine the fitness function corresponding to the target container when it is allocated to the target server.

[0057] Using the target server resource occupancy rate collected in step S402 as the core input, and combining it with the GPU, video memory, and bandwidth resource weights determined in step S203, the comprehensive load value corresponding to the target server is calculated by weighted summation through a preset load calculation model. Load value The higher the load value, the more strained the target server's current resource usage, and the less reasonable the container allocation scheme. Subsequently, based on this load value, the fitness function corresponding to the allocation of the target container to this target server is determined. The core design goal of this function is to minimize the standard deviation of server cluster load by quantitatively evaluating the rationality of container allocation schemes, thereby providing a standardized calculation basis for subsequent fitness calculations.

[0058] Step S404: Calculate the fitness of the target container when it is assigned to the target server using the fitness function, and determine the remaining number of iterations between the container and the server cluster using the difference between the total number of iterations and the number of traversals.

[0059] Substitute the target server's overall load value obtained in step S403 into the fitness function. It accurately calculates the fitness value of the target container when it is allocated to the corresponding target server. The fitness value is negatively correlated with the load value. The higher the fitness value, the better the container allocation scheme is, and the better it can achieve cluster load balancing and efficient resource utilization.

[0060] Simultaneously, the total number of iterations determined in step S204 is retrieved, and the current traversal count obtained in step S402 is subtracted from the total number of iterations to calculate the difference. This difference represents the remaining number of iterations between the container and the server cluster, clarifying the subsequent iteration evaluation rounds that need to be executed, and providing a key judgment basis for the migration strategy update in step S104. If the remaining number of iterations t=T, the fitness function value f(X) in SX is recorded. i The smallest allocation relation array is taken as the optimal allocation relation array X. best Preserve its fitness f(X) best ).

[0061] Step S403 is crucial for calculating the target server load and determining the fitness function. It's a key step connecting resource occupancy and fitness calculation, providing a core basis for subsequent fitness quantification. Optionally, step S403, which calculates the target server load based on resource occupancy and then uses that load to determine the fitness function for assigning the target container to the target server, is as follows: Figure 5 As shown, it includes: Step S501: Obtain the GPU resource weight, video memory resource weight, and bandwidth resource weight corresponding to the server through resource parameters.

[0062] First, retrieve the resource parameters determined in the preceding steps (i.e., the associated resource parameters calculated in step S203 based on server cluster resource parameters and container requirement parameters), and accurately extract the three types of core resource weights corresponding to the current target server from these resource parameters, namely, GPU resource weights. Memory resource weight and bandwidth resource weight These three resource weights have been dynamically allocated based on resource scarcity and the urgency of container demand, reflecting the impact of different resources on server load and laying the foundation for accurate calculation of subsequent load values.

[0063] Step S502: Based on the GPU occupancy, video memory occupancy, and bandwidth occupancy corresponding to the resource occupancy, calculate the load value corresponding to the target server using the GPU resource weight, video memory resource weight, and bandwidth resource weight.

[0064] Retrieve the target server resource occupancy rate collected in step S402, and extract three core occupancy rate indicators corresponding to the resource weights, namely GPU occupancy rate. Video memory usage and bandwidth utilization (The occupancy rates for each category are the ratios of currently used resources to the total server resources, directly reflecting the occupancy and stress levels of a single type of resource.)

[0065] Specifically, GPU utilization Video memory usage and bandwidth utilization The result is obtained through the following formula: ; ; ; in, The target server is then used. A weighted summation method is then employed, multiplying the occupancy rate of each resource type by its corresponding resource weight, and summing the three products to obtain the final overall load value for the target server. This load value can comprehensively and quantitatively reflect the current overall resource utilization status of the target server.

[0066] Step S503: Calculate the average load value of the servers in the server cluster using the load value, and determine the fitness function corresponding to the target container when it is allocated to the target server using the average load value, the load value and the number of servers in the server cluster.

[0067] First, based on the target server load value calculated in step S502, the current load values ​​of all available servers in the server cluster are collected (each server is calculated using the same weighted summation method). After summing the load values ​​of all servers, the average load value of the server cluster is obtained by dividing by the total number of servers in the server cluster. This value reflects the overall load balancing level of the cluster.

[0068] Subsequently, by combining the three core parameters—the average load value, the current load value of the target server, and the total number of servers in the server cluster—a fitness function is constructed and determined for assigning the target container to the target server. The core design logic of this function is consistent with that described above. It focuses on minimizing the standard deviation of the server cluster load by quantifying the deviation between the target server load value and the average load value of the cluster, thus providing a standardized and quantifiable calculation template for the subsequent accurate calculation of fitness.

[0069] Step S104's core is determining the migration update strategy based on the execution identifier, thereby clarifying the migration strategy of the target container and updating the container array and execution identifier, thus promoting the orderly progress of the iterative optimization process. Optionally, step S104 involves determining the migration update strategy corresponding to the target container based on the execution identifier, determining the migration strategy corresponding to the target container for the remaining iterations based on the migration update strategy, and updating the container array and execution identifier using the migration strategy, as follows: Figure 6 As shown, it includes: Step S601: If the execution flag is equal to the preset first flag, then use the remaining number of iterations and the total number of iterations to calculate the attack strength value corresponding to the target container, and obtain the target container array corresponding to the minimum fitness in the solution array set.

[0070] First, the established execution identifier and preset identifier system are retrieved to determine whether the current execution identifier is equal to the preset first identifier (e.g., Z=0, preset first identifier 0 corresponds to the initial stage of iterative optimization, the core objective of which is to expand the optimization range and quickly explore better allocation schemes, i.e., the offensive optimization stage). If the determination result is yes, then the remaining number of iterations and the total number of iterations are used as input, and... Calculate the attack strength value corresponding to the target container. This value quantifies the magnitude of container migration adjustments in the early stages of iteration. The more remaining iterations and the higher the percentage of total iterations, the greater the attack intensity and the wider the range of migration adjustments. Simultaneously, iterate through the previously constructed solution array set and select the target container array (minimum fitness X) corresponding to the minimum fitness. best The corresponding optimal container allocation scheme is represented by the container array, which is the optimal candidate allocation scheme for the current iteration stage.

[0071] Step S602: Determine the first migration update strategy for the target container in the container array using the attack strength value and the number of containers corresponding to the container.

[0072] Retrieve the attack strength value calculated in step S601 Simultaneously, the total number of containers N, determined earlier (used to control the scale of migration adjustments and avoid a surge in system overhead due to adjusting too many containers at once), is extracted. Combined with the quantified relationship A*N between the two, the first migration update strategy corresponding to the target container in the container array is determined. This strategy is an offensive update strategy in the early stages of iteration. Its core logic is based on the attack intensity value, clarifying the migration adjustment range, priority, and adjustment rules of the target container, ensuring that migration updates can quickly explore better solutions without affecting system stability due to excessive adjustments.

[0073] Step S603: Determine the first migration strategy corresponding to the target container for the remaining number of iterations through the first migration update strategy.

[0074] Based on the first migration update strategy determined in step S602, and combined with the remaining iteration count obtained in step S404 (which clarifies the subsequent executable iteration rounds), the current allocation status, resource adaptation of the target container, and the allocation scheme of the optimal candidate container array are comprehensively analyzed to determine the first migration strategy corresponding to the target container within the remaining iteration count. This first migration strategy specifically clarifies: whether the target container needs to continue migrating, the target server corresponding to the optimal candidate container array, the migration order, and resource allocation adaptation requirements, ensuring that the migration strategy matches the remaining iteration count and efficiently advancing the optimization process.

[0075] Step S604: Based on the first migration strategy, update the allocation value corresponding to the target container in the container array to the target allocation value corresponding to the target container array, and update the execution flag by increasing the preset step size.

[0076] Based on the first migration strategy determined in step S603, the current container array is updated. Specifically, SX is traversed, and A*N containers in the current allocation array are randomly selected and assigned values ​​x. j Adjust to X best The corresponding value x j_best At the same time, the execution flag is updated by increasing the step size according to the preset (such as incrementing the value of the execution flag Z by 1), marking the completion of the current offensive optimization phase. This provides an accurate basis for judging the execution flag and selecting the migration update strategy in the next iteration, and promotes the iterative optimization to gradually enter the subsequent phases.

[0077] Step S104 includes multi-branch migration and update logic. This part is the processing flow when the execution flag equals the preset second flag. The core is to optimize container allocation through a defensive fine-tuning strategy to avoid losing the optimal solution while advancing the iteration process. Optionally, step S104 involves determining the migration and update strategy corresponding to the target container based on the execution flag, determining the migration strategy corresponding to the target container for the remaining iterations based on the migration and update strategy, and updating the container array and execution flag using the migration strategy. Figure 7 As shown, it includes: Step S701: If the execution identifier is equal to the preset second identifier, then calculate the defense strength value corresponding to the target container using the random value of the preset interval, the remaining number of iterations and the total number of iterations.

[0078] First, retrieve the execution identifier and preset identifier system determined earlier, and determine whether the current execution identifier is equal to the preset second identifier (e.g., Z=1; the preset second identifier 1 usually corresponds to the mid-to-late stage of iterative optimization, the core goal of which is to consolidate the current optimal solution, fine-tune the optimization scheme, and avoid excessive migration leading to the loss of the optimal solution, i.e., the defensive optimization stage). If the determination result is yes, then start the calculation of the defense strength value: select a random value within a preset interval (to increase the diversity of fine-tuning and avoid getting trapped in local optima), combine it with the remaining number of iterations and the total number of iterations obtained earlier, and calculate the defense strength value corresponding to the target container using a preset calculation formula. This value is used to quantify the magnitude of container migration adjustments in the later stages of the iteration. Unlike the attack strength value, the defense strength value is generally smaller, focusing on fine-tuning rather than large-scale adjustments to ensure stable system load.

[0079] Step S702: Randomly obtain the first target container and the second target container contained in the target container array, and determine the second migration update strategy corresponding to the first target container and the second target container in the container array based on the first allocation value corresponding to the first target container, the second allocation value corresponding to the second target container, the defense strength value, and the number of containers corresponding to the containers.

[0080] First, from the current target container array X i In the candidate allocation schemes (i.e., the current iteration phase), two different containers are randomly selected, denoted as the first target container C. j Second target container C k Subsequently, the first allocation value y corresponding to the first target container is extracted. j (i.e., its currently assigned server number), the second allocation value y corresponding to the second target container. k (i.e., its currently assigned server number), combined with the defense strength value calculated in step S701, and the total number of containers determined earlier (used to control the scale of fine-tuning and avoid affecting system stability by adjusting too many containers at once), a second migration update strategy corresponding to the first and second target containers in the container array is determined through comprehensive quantitative analysis. This strategy is a defensive update strategy in the later stages of iteration. The core logic is to optimize the load distribution and consolidate the current optimal solution through local fine-tuning (such as swapping container allocation relationships), rather than adjusting container allocation on a large scale.

[0081] Step S703: Determine the second migration strategy corresponding to the first target container and the second target container for the remaining number of iterations through the second migration update strategy.

[0082] Based on the second migration and update strategy determined in step S702, and combined with the remaining iteration count obtained in the previous steps (to clarify the subsequent executable iteration rounds, with fewer remaining iteration counts in the mid-to-late stages, focusing on local optimization), the current resource adaptation status of the first target container and the second target container, as well as the target server load status, are comprehensively analyzed to determine the second migration strategy corresponding to the two target containers within the remaining iteration count.

[0083] The second migration strategy specifically clarifies the migration method (usually an exchange of allocation relationships) between the first target container and the second target container, the migration timing, and resource adaptation requirements. This ensures that the fine-tuning operation can optimize load balancing while avoiding disrupting the existing optimal allocation pattern and adapting to the optimization needs in the later stages of the iteration.

[0084] Step S704: After updating the allocation value of the first target container to the second allocation value using the second migration strategy and updating the allocation value of the second target container to the first allocation value, update the execution flag by increasing the preset step size.

[0085] Based on the second migration strategy determined in step S703, a local update is performed on the current container array: specifically, traversing SX, for each allocation array X i Randomly select two containers C j and C k Swap their assigned values ​​y j and y k The process involves performing B*N random selections and swaps to fine-tune the allocation relationship between the two target containers, ensuring that the container array is synchronized with the latest allocation status in real time.

[0086] After fine-tuning is completed, the step size is increased according to the same preset as before, and the current execution flag is updated (for example, the value of execution flag Z is incremented by 1). This marks the completion of the current defensive fine-tuning phase, providing an accurate basis for judging the execution flag and selecting the migration update strategy in the next iteration, and promoting iterative optimization to gradually approach the optimal solution.

[0087] The core of this branch of step S104 is that when the execution identifier is the preset third identifier, the optimal solution is solidified through convergence adjustment, and the execution identifier is reset to ensure the closed loop of the iteration process. Optionally, step S104 involves determining the migration update strategy corresponding to the target container based on the execution identifier, determining the migration strategy corresponding to the target container for the remaining iterations based on the migration update strategy, and updating the container array and execution identifier using the migration strategy. Figure 8 As shown, it includes: Step S801: If the execution identifier is equal to the preset third identifier, then the third migration update strategy corresponding to the target container is determined by using the preset reduction step size and the remaining number of iterations, and the target container array corresponding to the minimum fitness in the solution array set is obtained.

[0088] First, the previously determined execution identifier and preset identifier system are retrieved to determine whether the current execution identifier is equal to the preset third identifier (whether Z equals 2). If the result is yes, the process of determining the third migration update strategy is initiated: combining the preset reduction step size and the acquired remaining iteration count, the third migration update strategy corresponding to the target container is determined through quantitative analysis. At the same time, the solution array set constructed earlier is traversed again to select the target container array corresponding to the minimum fitness; this container array is the optimal container allocation scheme in the entire process of the current iteration and is the core reference standard for subsequent container allocation updates.

[0089] Step S802: Determine the third migration strategy corresponding to the target container for the remaining number of iterations through the third migration update strategy.

[0090] Based on the third migration update strategy determined in step S801, and considering the remaining iterations (the remaining iterations are limited at the end, and the strategy focuses on precise alignment rather than exploring new solutions), a comprehensive analysis is conducted to determine the third migration strategy for the target container within the remaining iterations, comparing the current allocation state of the target container with the allocation difference of the optimal target container array. The core logic of this third migration strategy is precise convergence and optimal consolidation. It specifically clarifies how the target container needs to adjust its allocation state to fully align with the allocation scheme in the optimal target container array, while also considering the stability of the system load, ensuring efficient consolidation of the optimal solution within the remaining iterations and avoiding unnecessary migration overhead.

[0091] Step S803: Update the allocation value corresponding to the target container in the container array to the target allocation value corresponding to the target container array through the third migration strategy, and update the execution flag to the initial value.

[0092] Based on the third migration strategy determined in step S802, the current container array is finally updated. Specifically, the original allocation values ​​(i.e., the current server numbers) corresponding to all target containers in the container array are updated one by one to the target allocation values ​​(optimal server numbers) corresponding to the optimal target container array selected in step S801. This ensures that the container array is completely synchronized with the optimal allocation scheme, solidifying the results of this iteration. After the container array is updated, the current execution identifier is updated to the initial value according to preset rules. The core purpose of this operation is to reset the iteration state, prepare for the next complete container migration iteration optimization cycle (starting from the initial parameter configuration), ensure that the entire container migration control process can form a closed loop, and can be repeatedly executed and continuously optimized according to actual needs.

[0093] The aforementioned container migration control method can be implemented based on the SBOA (Secretary Bird Optimization Algorithm). By introducing the SBOA algorithm, the placement and migration of containers are globally optimized to achieve a comprehensive improvement in resource utilization, load balancing, and service quality. The SBOA algorithm can simulate the search and battle process, finding the optimal container migration strategy through iterative optimization, thereby avoiding the local optima problem that may occur in traditional methods and improving adaptability in dynamic environments.

[0094] The container migration control method at this time is as follows: Figure 9 As shown, it includes: Step S901: Obtain basic parameters: container list N, each container C j Resource requirements R j and execution time T j Server list M, each server S k With resource capacity Q k .

[0095] Specifically, the list of containers Each container Execution time and GPU requirements Video memory requirements and bandwidth requirements Server list Each of the servers It has resources, and its capacity Q k Including GPU resources Video memory resources and bandwidth resources .

[0096] Step S902: Set initial running parameters: population size P; total number of iterations T, remaining number of iterations t; GPU resource weight u. g Memory resource weight u d Bandwidth resource weight u b ;Execute flag Z=0.

[0097] Step S903: Execute the traversal P times in a loop, randomly assign servers, and form a two-dimensional solution array set; each solution array X i =[y1,y2,...y N ], where y j ∈{1,2,…,M} represents container C j Assigned to server S yj .

[0098] Iterate through all containers and randomly assign a server number y to each container in turn. j ,y j ∈{1,2,...,M}, each iteration of the loop generates an array X. i =[y1,y2,...,y N After iterating P times, the resulting P arrays are merged to form a set of assignment relation arrays SX={X1,X2, ...,X...} P}

[0099] Step S904: Traverse all solutions and migrate containers to designated servers in sequence according to the solution array; if there is a server capacity overflow constraint limit, then reassign random servers to the current container until the resource requirements are met.

[0100] Iterate through SX, and for each allocation relation array traversed, proceed according to the current allocation relation array X. i Containers are migrated to the server sequentially, and the GPU utilization of the server is calculated for each container migrated to the specified server: Graphics card usage: Bandwidth utilization: .

[0101] If the current container is located on server S k WG k >1 or WD k >1 or WB k >1, randomly assign a server number to the current container, and calculate the WG of the server where the current container resides. k WD k WB k Until WG k ≤1 and WD k ≤1 and WB k If the value is less than or equal to 1, then update the current allocation relationship array according to the server assigned to the container.

[0102] After each allocation relationship array migration is completed, the three resource occupancy rates of each server are calculated sequentially using weighted averages to obtain the server load. Then calculate the average load of all servers. Subsequently, the standard deviation of server load is calculated as the fitness function for the current allocation relationship. .

[0103] Step S905: Calculate the server load standard deviation for each assignment relation array as the fitness function f(X). i If t=T, then select the smallest solution as the optimal solution and record it.

[0104] If the remaining iterations t=T, record the fitness function value f(X) in SX. i The smallest allocation relation array is taken as the optimal allocation relation array X. best Preserve its fitness f(X) best ).

[0105] Step S906: Calculate the fitness f(X) of the new solution. i If f(X) i ) <f(X best If X is updated, then the optimal solution X is updated. best =X i .

[0106] If f(X) i ) <f(X best Update the optimal solution X. best =X i and update f(X) best )=f(X i ) Step S907: Determine the value of the execution flag Z.

[0107] Determine if the value of execution flag Z is 0, 1 or 2; if execution flag Z is 0, proceed to step S908; if execution flag Z is 1, proceed to step S910; if execution flag Z is 2, proceed to step S912.

[0108] Step S908: If Z=0, calculate the control parameter A for the attack phase; as the number of iterations t changes, A moves closer to 0 when t is small, and moves closer to 1 when t is large, thus gradually enhancing the global search.

[0109] Calculate the attack intensity using the following formula. .

[0110] Step S909: Traverse all solutions, randomly select A*N containers from the current solution array, and allocate and adjust them to X. best The corresponding value; after the traversal is completed, the execution flag Z is incremented by 1.

[0111] Iterate through SX, randomly select a container in the current allocation array, and assign it the value x. j Adjust to X best The corresponding value x j_best After the traversal ends, the execution flag Z is incremented by 1, and finally the process returns to step S904.

[0112] Step S910: If Z=1, then calculate the control parameter B for the defensive phase.

[0113] The defensive strength for controlling the number of exchanges is calculated using the following formula. .

[0114] Step S911: Perform B random swaps: Traverse all solutions, randomly select two containers j1 and j2, and swap their server-assigned values; after the traversal ends, increment the flag Z by 1.

[0115] Iterate through SX, for each allocation array X i Randomly select two containers C j and C k Swap their assigned values ​​y j and y k Perform B*N random selections and swaps. After the traversal ends, increment the execution flag Z by 1, and finally return to step S904.

[0116] Step S912: If Z=2, then decrease the remaining number of iterations by 1 and set Z=0; check if the remaining number of iterations t is 0.

[0117] The remaining iteration count t is subtracted by 1, and the execution flag Z is updated to 0. Then, it is checked whether the remaining iteration count t is 0. If not, step S908 is executed; if so, step S913 is executed, and the optimal solution vector X is returned. best and its fitness f(X) best Returns the optimal allocation array X. best X provides relevant computing power scheduling platforms best This represents the final mapping scheme from each container to the server, returning the load standard deviation f(X). best This indicates the optimized server load balancing.

[0118] As can be seen from the container migration control method mentioned in the above embodiments, this method can simulate the container migration problem as an optimization problem. Specifically, the placement and migration of containers are simulated as specific attack and defense processes. Through iterative optimization, with the goal of minimizing the standard deviation of server load, the optimal strategy for container migration is finally found. This avoids the local optimum problem that may occur in the traditional container migration process and achieves a comprehensive improvement in resource utilization, load balancing and service quality.

[0119] Corresponding to the above embodiments of the container migration control method, this embodiment of the invention also provides a container migration control system, such as... Figure 10 As shown, the system includes: The initialization module 100 is used to determine the corresponding resource parameters, execution identifier, and total number of iterations between the container and the server cluster based on the resource parameters of the server cluster and the requirement parameters of the container, and to determine the initial running parameters corresponding to the container using the resource parameters, execution identifier, and total number of iterations. The array allocation module 200 is used to determine the allocation strategy between the container and the server cluster using the initial running parameters. After constructing the container array corresponding to the container through the allocation strategy, the solution array set corresponding to the container array is determined by using the population size parameter corresponding to the container in the server cluster. The traversal execution module 300 is used to traverse the target containers and target servers corresponding to the container array in the solution array set, control the migration of target containers to target servers based on the allocation strategy, calculate the fitness of the target containers when they are allocated to the target servers using the resource occupancy of the target servers, and determine the remaining number of iterations between the containers and the server cluster using the number of traversals and the total number of iterations. The strategy update module 400 is used to determine the migration update strategy corresponding to the target container based on the execution identifier, determine the migration strategy corresponding to the target container in the remaining iterations based on the migration update strategy, and update the container array and execution identifier using the migration strategy. The migration control module 500 is used to update the fitness and remaining iterations through the updated container array; when the execution flag and remaining iterations meet the preset threshold conditions, the migration between the container and the corresponding container in the server cluster is completed using the current container array and its corresponding fitness.

[0120] As can be seen from the above container migration control system, the system can simulate the container migration problem as an optimization problem. Specifically, the placement and migration of containers are simulated as specific attack and defense processes. Through iterative optimization, with the goal of minimizing the standard deviation of server load, the system finally finds the best strategy for container migration, thereby avoiding the local optimum problem that may occur in the traditional container migration process and achieving a comprehensive improvement in resource utilization, load balancing and service quality.

[0121] The container migration control system provided in this embodiment of the invention has the same implementation principle and technical effects as the aforementioned container migration control method embodiment. For the sake of brevity, any parts not mentioned in the system embodiment can be referred to the corresponding content in the aforementioned container migration control method embodiment.

[0122] This embodiment also provides an electronic device, the structural schematic diagram of which is shown below. Figure 11 As shown, the device includes a processor 101 and a memory 102; wherein the memory 102 is used to store one or more computer instructions, which are executed by the processor to implement the steps of the container migration control method described above.

[0123] Figure 11 The electronic device shown also includes a bus 103 and a communication interface 104, with the processor 101, communication interface 104 and memory 102 connected via the bus 103.

[0124] The memory 102 may include high-speed random access memory (RAM) and may also include non-volatile memory, such as at least one disk storage device. The bus 103 may be an ISA bus, PCI bus, or EISA bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 11 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0125] The communication interface 104 is used to connect to at least one user terminal and other network units through a network interface, and to send encapsulated IPv4 packets or IPv4 packets to the user terminal through the network interface.

[0126] Processor 101 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of processor 101 or by instructions in software form. The processor 101 may be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it may also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this disclosure. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this disclosure can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software module can reside in a mature storage medium in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory 102. The processor 101 reads the information in memory 102 and, in conjunction with its hardware, completes the steps of the method described in the foregoing embodiments.

[0127] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, devices, and methods can be implemented in other ways. The system embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the coupling or direct coupling or communication connection shown or discussed may be through some communication interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0128] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0129] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0130] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0131] Finally, it should be noted that the above-described embodiments are merely specific implementations of the present invention, used to illustrate the technical solutions of the present invention, and not to limit it. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the technical scope disclosed in the present invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of protection of the claims.

Claims

1. A container migration control method, characterized in that, The method includes: Based on the resource parameters of the server cluster and the requirement parameters of the container, the resource parameters, execution identifier, and total number of iterations corresponding to the container and the server cluster are determined, and the initial running parameters corresponding to the container are determined using the resource parameters, the execution identifier, and the total number of iterations. The initial running parameters are used to determine the allocation strategy between the container and the server cluster. After constructing the container array corresponding to the container through the allocation strategy, the solution array set corresponding to the container array is determined by using the population size parameter corresponding to the container in the server cluster. Traverse the target containers and target servers corresponding to the container array in the solution array set, control the migration of the target containers to the target servers based on the allocation strategy, calculate the fitness of the target containers when they are allocated to the target servers using the resource occupancy of the target servers, and determine the remaining number of iterations between the container and the server cluster using the number of traversals and the total number of iterations. The migration update strategy corresponding to the target container is determined based on the execution identifier, the migration strategy corresponding to the target container under the remaining iterations is determined based on the migration update strategy, and the container array and the execution identifier are updated using the migration strategy; The fitness and the remaining number of iterations are updated by updating the container array; when the execution identifier and the remaining number of iterations meet the preset threshold conditions, the migration between the container and the corresponding container in the server cluster is controlled by the current container array and its corresponding fitness.

2. The container migration control method according to claim 1, characterized in that, The steps of determining the resource parameters, execution identifier, and total number of iterations corresponding to the container and the server cluster based on the resource parameters of the server cluster and the requirement parameters of the container, and determining the initial running parameters corresponding to the container using the resource parameters, the execution identifier, and the total number of iterations, include: Obtain the servers included in the server cluster, and determine the resource parameters corresponding to the server cluster using the GPU resource parameters, video memory resource parameters, and bandwidth resource parameters corresponding to the servers; Obtain the container corresponding to the server, and determine the requirement parameters corresponding to the container using the GPU requirement parameters, video memory requirement parameters, and bandwidth requirement parameters corresponding to the container. The GPU resource weight, video memory resource weight, and bandwidth resource weight corresponding to the server in the server cluster are determined by the resource parameters and the demand parameters, and the resource parameters corresponding to the container and the server cluster are determined by the GPU resource weight, the video memory resource weight, and the bandwidth resource weight. Based on the resource parameters, obtain the execution time parameters corresponding to the container and the population size parameters corresponding to the container in the server, and use the time parameters and population size parameters to determine the total number of iterations between the container and the server cluster; The execution identifier corresponding to the container and the server cluster is determined based on the resource parameters, and the initial running parameters corresponding to the container are determined by the resource parameters, the execution identifier and the total number of iterations.

3. The container migration control method according to claim 1, characterized in that, The steps of determining the allocation strategy between the container and the server cluster using the initial running parameters, constructing the container array corresponding to the container using the allocation strategy, and determining the solution array set corresponding to the container array using the population size parameter corresponding to the container in the server cluster include: The number of containers corresponding to the container and the number of servers in the server cluster are determined using the initial running parameters. The container number and the number of servers are used to determine the container number corresponding to the container and the server number corresponding to each server in the server cluster. The allocation strategy between the container and the server cluster is determined based on the random allocation instruction between the container number and the server number; After traversing all the containers by the container number and randomly assigning the server to the container by the allocation strategy, a container array corresponding to the container is constructed using the container number and the server number that have been allocated. Based on the population size parameter corresponding to the container in the server cluster, the number of traversal loops corresponding to the container is determined, and the solution array set corresponding to the container array is obtained by traversing all the containers using the number of traversal loops.

4. The container migration control method according to claim 3, characterized in that, The steps of traversing the target containers and target servers corresponding to the container array in the solution array set, controlling the migration of the target containers to the target servers based on the allocation strategy, calculating the fitness of the target containers when allocated to the target servers using the resource occupancy of the target servers, and determining the remaining number of iterations between the containers and the server cluster using the number of traversals and the total number of iterations include: The target container is determined based on the container number corresponding to the container array, and the target server corresponding to the target container under the allocation strategy is obtained; According to the container number, the target container in the container array is traversed. After the target container is migrated to the target server by the allocation strategy, the resource occupancy of the target server is determined by the GPU occupancy, video memory occupancy and bandwidth occupancy of the target server, and the traversal number corresponding to the target container is obtained in real time. Calculate the load value corresponding to the target server based on the resource occupancy rate, and use the load value to determine the fitness function corresponding to the target container when it is allocated to the target server; The fitness function is used to calculate the fitness of the target container when it is assigned to the target server, and the difference between the total number of iterations and the number of traversals is used to determine the remaining number of iterations between the container and the server cluster.

5. The container migration control method according to claim 4, characterized in that, The steps of calculating the load value corresponding to the target server based on the resource occupancy rate, and determining the fitness function corresponding to the target container when it is allocated to the target server using the load value, include: The GPU resource weight, video memory resource weight, and bandwidth resource weight corresponding to the server are obtained through the resource parameters. Based on the GPU occupancy, video memory occupancy, and bandwidth occupancy corresponding to the resource occupancy, the load value corresponding to the target server is calculated using the GPU resource weight, video memory resource weight, and bandwidth resource weight; The average load value of the server in the server cluster is calculated using the load value, and the fitness function corresponding to the target container when it is allocated to the target server is determined by the average load value, the load value and the number of servers in the server cluster.

6. The container migration control method according to claim 1, characterized in that, The steps of determining the migration update strategy corresponding to the target container based on the execution identifier, determining the migration strategy corresponding to the target container for the remaining iterations based on the migration update strategy, and updating the container array and the execution identifier using the migration strategy include: If the execution identifier is equal to the preset first identifier, then the attack strength value corresponding to the target container is calculated using the remaining iteration count and the total iteration count, and the target container array corresponding to the minimum fitness in the solution array set is obtained; The first migration update strategy corresponding to the target container in the container array is determined by using the attack intensity value and the number of containers corresponding to the container; The first migration strategy corresponding to the target container under the remaining number of iterations is determined by the first migration update strategy; Based on the first migration strategy, the allocation value corresponding to the target container in the container array is updated to the target allocation value corresponding to the target container array, and the execution identifier is updated using a preset step size.

7. The container migration control method according to claim 6, characterized in that, The steps of determining the migration update strategy corresponding to the target container based on the execution identifier, determining the migration strategy corresponding to the target container for the remaining iterations based on the migration update strategy, and updating the container array and the execution identifier using the migration strategy include: If the execution identifier is equal to the preset second identifier, then the defense strength value corresponding to the target container is calculated using the random value of the preset interval, the remaining number of iterations, and the total number of iterations; Randomly obtain a first target container and a second target container contained in the target container array, and determine a second migration update strategy corresponding to the first target container and the second target container in the container array based on the first allocation value corresponding to the first target container, the second allocation value corresponding to the second target container, the defense strength value, and the number of containers corresponding to the container; The second migration update strategy is used to determine the second migration strategy corresponding to the first target container and the second target container under the remaining number of iterations; After updating the allocation value of the first target container to the second allocation value using the second migration strategy, and then updating the allocation value of the second target container to the first allocation value, the execution identifier is updated using a preset increment step.

8. The container migration control method according to claim 6, characterized in that, The steps of determining the migration update strategy corresponding to the target container based on the execution identifier, determining the migration strategy corresponding to the target container for the remaining iterations based on the migration update strategy, and updating the container array and the execution identifier using the migration strategy include: If the execution identifier is equal to the preset third identifier, then the third migration update strategy corresponding to the target container is determined by using the preset reduction step size and the remaining number of iterations, and the target container array corresponding to the minimum fitness in the solution array set is obtained; The third migration strategy corresponding to the target container under the remaining iterations is determined by the third migration update strategy. The third migration strategy updates the allocation value corresponding to the target container in the container array to the target allocation value corresponding to the target container array, and updates the execution identifier to the initial value.

9. A container migration control system, characterized in that, The system includes: An initialization module is used to determine the resource parameters, execution identifier, and total number of iterations between the container and the server cluster based on the resource parameters of the server cluster and the requirement parameters of the container, and to determine the initial running parameters corresponding to the container using the resource parameters, the execution identifier, and the total number of iterations. An array allocation module is used to determine the allocation strategy between the container and the server cluster using the initial running parameters, construct a container array corresponding to the container using the allocation strategy, and then determine the solution array set corresponding to the container array using the population size parameter corresponding to the container in the server cluster. The traversal execution module is used to traverse the target containers and target servers corresponding to the container array in the solution array set, control the migration of the target containers to the target servers based on the allocation strategy, calculate the fitness of the target containers when they are allocated to the target servers using the resource occupancy of the target servers, and determine the remaining number of iterations between the container and the server cluster using the number of traversals and the total number of iterations. The strategy update module is used to determine the migration update strategy corresponding to the target container based on the execution identifier, determine the migration strategy corresponding to the target container under the remaining iteration number based on the migration update strategy, and update the container array and the execution identifier using the migration strategy; The migration control module is used to update the fitness and the remaining iteration count through the updated container array; when the execution identifier and the remaining iteration count meet the preset threshold conditions, the module uses the current container array and its corresponding fitness to control the migration of the container to the corresponding container in the server cluster.

10. An electronic device, characterized in that, The server includes a processor and a memory, the memory storing computer-executable instructions that can be executed by the processor, the processor executing the computer-executable instructions to implement the steps of the container migration control method according to any one of claims 1 to 8.

Images