Container group migration method and device, electronic equipment and storage medium

Abstract

This invention provides a container group migration method, apparatus, electronic device, and storage medium. The method includes: determining the node to be migrated to obtain a first node; determining at least one original container group on the first node to be migrated to a second node; creating a target container group corresponding to the original container group on the second node and adding the target container group to a domain name load balancer providing external services; removing the original container group on the first node from the domain name load balancer and deleting the original container group on the first node. This invention enables lossless migration of application traffic, reducing request failure rate and timeout risk.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a container group migration method, apparatus, electronic device and storage medium. Background Technology

[0002] In a containerized deployment environment, when a node in the cluster fails, it is typically necessary to migrate the container pods running on that node to other healthy nodes to ensure continuous service availability. Currently, the main methods for migrating container groups when cluster nodes fail include the following two categories: First, automatic fault recovery. When a node fails, the cluster controller automatically triggers the container group rebuild process, scheduling the new container group to other healthy nodes in the cluster. Second, manual fault migration. This involves operations personnel executing a node eviction command to forcibly delete all container groups on the failed node, which are then recreated by the scheduler on other nodes.

[0003] In developing this invention, the inventors discovered that existing solutions, whether for automatic recovery or manual eviction, directly delete the container group on the original node and rely on the controller to rebuild it remotely. Due to the lack of a safe traffic transition mechanism, during the window period after the original container group is deleted and before the new container group is ready, service requests will encounter connection rejection or timeout, resulting in application traffic loss. Summary of the Invention

[0004] This invention provides a container group migration method, apparatus, electronic device, and storage medium that can achieve lossless migration of application traffic and reduce request failure rate and timeout risk.

[0005] The container group migration method provided in this embodiment of the invention includes: Identify the nodes that need to be migrated from the container group to obtain the first node; Determine at least one original container group on the first node to which it needs to be migrated, and obtain the second node; Create a target container group corresponding to the original container group on the second node, and add the target container group to the domain name load balancer that provides services to the outside world; Remove the original container group on the first node from the domain name load balancer and delete the original container group on the first node.

[0006] The container migration apparatus provided in this embodiment of the invention includes: The first determination module is used to determine the nodes that need to be migrated from the container group, and obtain the first node; The second determining module is used to determine at least one original container group on the first node that needs to be migrated to, thereby obtaining the second node; A creation module is used to create a target container group corresponding to the original container group on the second node, and add the target container group to the domain name load balancer that provides services to the outside world; The deletion module is used to remove the original container group on the first node from the domain name load balancer and delete the original container group on the first node.

[0007] The electronic device provided in the embodiments of the present invention includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements the container group migration method as described in any embodiment of the present invention.

[0008] The computer-readable storage medium provided in the embodiments of the present invention stores a computer program thereon, which, when executed by a processor, implements the container group migration method as described in any embodiment of the present invention.

[0009] In this embodiment of the invention, a "build first, then remove" strategy is adopted. A target container group corresponding to the original container group is pre-created on the second node and added to the domain name load balancer providing external services. After the target container group successfully handles the traffic, the original container group is removed from the load balancer. Therefore, the domain name load balancer always has available container groups to carry business traffic, eliminating the traffic interruption window caused by container group reconstruction delays, solving the problem of partial application traffic damage in existing technologies, and achieving lossless migration of application traffic. By using the "add to load balancer first, then remove the original container group" operation sequence, it is ensured that at any time during traffic switching, there are always container groups in a service state behind the domain name load balancer. Therefore, business requests can always be received and processed by normal container groups, improving the integrity and reliability of request processing during migration and reducing request failure rate and timeout risk. Attached Figure Description

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

[0011] Figure 1 This is a schematic flowchart of a container group migration method provided in an embodiment of the present invention; Figure 2 This is a flowchart example of a container group migration method provided in an embodiment of the present invention; Figure 3 This is a flowchart illustrating a node fault monitoring process provided in an embodiment of the present invention. Figure 4This is a schematic diagram of a container group migration device provided in an embodiment of the present invention; Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0012] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0013] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0014] Figure 1 This is a flowchart illustrating a container group migration method provided in an embodiment of the present invention. The container group migration method provided in this embodiment is applicable to scenarios where node failures in a cluster necessitate container group migration. This container group migration method can be executed by a container group migration device provided in this embodiment, which can be implemented in software and / or hardware. In a specific embodiment, the device can be integrated into an electronic device, such as a computer or server. The following embodiment illustrates the integration of the container group migration device into an electronic device. See also... Figure 1 The container group migration method in this embodiment may include the following steps: Step 101: Determine the node that needs to be migrated from the container group to obtain the first node.

[0015] A container group, often called a Pod, is the smallest deployable computing unit in a container orchestration platform. A container group can contain one or more tightly coupled containers that share network, storage, and runtime environments, serving as the actual instance hosting the business application. A node is a physical machine or virtual machine in a cluster used to run the container group. Nodes provide compute, storage, and network resources and are the infrastructure unit for the entire containerized application deployment. The first node identifies the source node determined to "require container group migration." The use of "first" here is merely to distinguish it from the subsequent "second node" (i.e., the migration target node) and does not indicate priority or importance; it is simply the logical name of the node.

[0016] That is, from all nodes in the cluster, based on predefined conditions, such as a node being manually marked as faulty, the automatic failover switch being turned on and the node's health status being abnormal, or a node connection timeout, the nodes on which the container groups need to be migrated to other nodes are identified.

[0017] Step 102: Determine at least one original container group on the first node to which it needs to be migrated, and obtain the second node.

[0018] The original container group refers to the containerized application instances (i.e., Pods) running on the first node that need to be migrated. The second node identifies the target node to which the container group needs to be migrated. The term "second" is used to establish a correspondence with the "first node" (source node) and does not indicate any difference in order or importance; it is merely a logical name for the target node.

[0019] After identifying the source node (i.e., the first node) that needs to be migrated, the next step is to determine which target node each of the at least one original container group on that source node should be migrated to. Once this target node is determined, it is named the second node.

[0020] Step 103: Create a target container group on the second node that corresponds to the original container group, and add the target container group to the domain name load balancer that provides services to the outside world.

[0021] The target container group refers to a newly created containerized application instance on the second node, used to replace the original container group. The target container group needs to maintain consistency with the original container group in terms of resource specifications, configuration, and application version to ensure that service capabilities are not degraded after migration. A domain load balancer refers to a load balancing device or component located at the service frontend, providing external access via domain names. The load balancer maintains a list of backend instance addresses, such as the IP addresses of the container group, and distributes external requests to the instances in the list based on domain names or path rules. Adding a container group to a load balancer means registering the container group's network address with the load balancer's backend list, enabling it to receive and process business requests destined for that domain name.

[0022] After identifying the second node, a target container group corresponding to the original container group is created on that node. This target container group is a copy or equivalent replacement of the original container group in terms of configuration and functionality. Subsequently, this target container group is registered in the list of backend instances of the domain load balancer providing external services, enabling it to begin receiving traffic from clients. Through this step, the newly created target container group is included in the load balancer's traffic distribution scope before it officially becomes available to the public, paving the way for the safe removal of the original container group later.

[0023] Step 104: Remove the original container group on the first node from the domain name load balancer and delete the original container group on the first node.

[0024] Removal refers to removing the original container group from the list of backend instances of the domain load balancer. This is a logical operation; after execution, the load balancer will no longer distribute new requests to the original container group, but the processes and data of the original container group itself usually still exist. The purpose of removal is to cut off the incoming traffic and prevent connection failures caused by requests still being sent when the original container group is deleted. Deletion refers to completely destroying the original container group and its occupied resources, such as storage volumes and network interfaces, from the first node. This is a physical operation; after execution, the processes of the original container group are terminated, and related resources are released. The deletion operation is performed after the removal operation is successful to ensure no traffic loss.

[0025] After creating the target container group and successfully adding it to the domain load balancer, the original container group is exited and cleaned up. First, the original container group on the first node is removed from the domain load balancer's backend list, preventing it from receiving new business requests. At this point, although the original container group is still running, no new traffic is coming in; it can only handle some existing connections. After the removal operation is complete, the original container group on the first node is deleted, releasing the system resources it occupied. This "remove first, delete later" order ensures that there is always an available instance (target container group) providing services throughout the migration process, thus avoiding request failures or connection timeouts caused by the sudden deletion of the original container group.

[0026] In this embodiment, a "build first, then remove" strategy is adopted. A target container group corresponding to the original container group is pre-created on the second node and added to the domain name load balancer providing external services. After the target container group successfully handles the traffic, the original container group is removed from the load balancer. Therefore, the domain name load balancer always has available container groups to carry business traffic, eliminating the traffic interruption window caused by container group reconstruction delays, solving the problem of partial application traffic damage in existing technologies, and achieving lossless migration of application traffic. By using the "add to load balancer first, then remove the original container group" operation sequence, it is ensured that at any time during traffic switching, there are always container groups in a service state behind the domain name load balancer. Therefore, business requests can always be received and processed by normal container groups, improving the integrity and reliability of request processing during migration and reducing request failure rate and timeout risk.

[0027] In one embodiment, the status of nodes in the cluster can be monitored; if a node is detected to be manually marked as a faulty node, the node that has been manually marked as a faulty node is determined as the first node.

[0028] Furthermore, for nodes that have not been manually marked as faulty nodes, the status of the automatic failover switch can be checked; if the automatic failover switch is in the on state, the node monitoring information is combined to determine whether the node that has not been manually marked as faulty node meets the automatic failover conditions; among which, the automatic failover conditions include abnormal node health and / or node connection timeout exceeding a preset duration; the node that meets the automatic failover conditions is determined as the first node.

[0029] Manually marking a node as faulty refers to operations and maintenance personnel adding a specific tag or marker to a node using command-line tools or an interface to declare that the node is in a faulty state or that the containers on it need to be removed. This is common in planned maintenance, such as node upgrades and hardware replacements.

[0030] The automatic failover switch is a configuration switch used to control whether the system is allowed to automatically detect node failures and trigger container group migration. Turning the switch on enables automatic failover, while turning it off disables automatic migration. This switch can prevent unnecessary migration during brief node downtime (such as a restart).

[0031] Node monitoring information refers to node operational status data collected by the monitoring system, such as node heartbeat responses, network latency, and resource pressure. This information is used to determine whether a node has actually failed. Automatic failover conditions refer to a set of predefined rules used by the system to trigger automatic migration. When a node meets these conditions, the system automatically identifies it as a node requiring migration. Abnormal node health is one type of automatic failover condition, specifically including a node state becoming unready, the node becoming unresponsive, or a serious error occurring in the node's operating system or kernel. Node connection timeout is another type of automatic failover condition, referring to a network-level connection timeout when accessing the node from the control plane, and the timeout duration exceeding a certain threshold. Preset duration refers to a time threshold set for node connection timeouts (e.g., 30 seconds, 1 minute). Automatic failover conditions are only considered met when the connection timeout duration exceeds this preset duration, to avoid falsely triggering migration due to momentary network jitter.

[0032] In practical applications, a two-tiered mechanism of "manual priority, automatic supplementation" can be adopted when determining the first node (i.e., the source node that needs to be migrated from the container group). First, the status of all nodes in the cluster is continuously monitored. If a node is manually marked as a faulty node by operations personnel, it is directly designated as the first node without any automatic detection. This approach is suitable for scenarios involving planned maintenance or manual judgment that nodes need to be removed, ensuring the priority of manual intervention. Second, for nodes not manually marked, the automatic failover switch is checked. If the switch is not turned on, no automatic migration will occur, avoiding unexpected migration during brief node failures or planned restarts. If the switch is turned on, node monitoring information is further combined to determine whether the node meets predefined automatic failover conditions. Automatic failover conditions include two categories: first, the node's health becomes abnormal (e.g., the node becomes unavailable); second, the node experiences a connection timeout, and the timeout duration exceeds a preset threshold. If either of these conditions is met, the system designates the node as the first node.

[0033] The method described above for determining the first node can flexibly handle different failure scenarios: for planned maintenance, migration is proactively triggered by manual marking; for sudden node failures, the system automatically detects and triggers migration, provided the automatic switch is enabled. Simultaneously, the automatic switch provides maintenance personnel with overall control, allowing them to disable the automatic migration function during brief node downtime or normal upgrades, preventing global migration due to temporary failures. This design balances flexibility, security, and automation.

[0034] In one embodiment, after obtaining the first node, the method further includes: Collect container group information on the first node; Based on the container group information, query the corresponding application information to group the original container groups according to the application dimension and generate corresponding container group migration tasks; The container group migration task is executed step by step, creating a target container group corresponding to the original container group on the second node.

[0035] Container group information refers to the metadata of each container group collected from the first node, such as the container group's name, namespace, tags, controller, resource requests, and limits. This information can be used to identify which application the container group belongs to. Application information refers to the business application-level information corresponding to the container group, obtained by querying the container group information, such as the application name, application version, and service it belongs to. An application is typically supported by multiple container group replicas.

[0036] Application-level migration refers to treating all container groups belonging to the same application as a single entity, using the application as the granularity for classification. During migration, the number of replicas and lossless traffic must be considered uniformly. Grouping refers to categorizing the multiple container groups collected from the first node according to their respective applications; container groups belonging to the same application are grouped together. A container group migration task is a migration task unit generated for each application group. This task includes information such as the list of container groups to be migrated (original container groups), the target number of replicas, and the corresponding application configuration. One container group migration task corresponds to the migration requirements of one application.

[0037] In other words, after identifying the first node (i.e., the source node to be migrated), detailed information about all running container groups on the first node can be collected, including their identifiers, tags, and associated controllers. Then, based on the collected container group information, the application information corresponding to each container group is obtained through querying, such as which application the container group belongs to and what configurations that application has. Based on this information, all original container groups on the first node are grouped according to the application dimension: container groups belonging to the same application are grouped together, and a corresponding container group migration task is generated for each application group. Each task specifies how many container groups on the first node for that application need to be migrated. Finally, according to these container group migration tasks, the steps to create the target container group on the second node are executed application by application. That is, the migration operation is performed sequentially with the application as the smallest unit, and the migration task for each application is completed independently, ensuring that the migration processes of different applications do not interfere with each other, and also facilitating the adoption of different migration strategies or priorities for different applications.

[0038] By grouping by application dimension, generating tasks, and migrating application by application, multiple applications that may be mixed on a single node can be handled in an orderly manner, avoiding the disorderly migration of all container groups and improving the controllability and maintainability of the migration.

[0039] In one embodiment, after adding the target container group to the domain name load balancer, the method further includes: Check whether the target container group has been successfully added to the domain load balancer; If the target container group is successfully added to the domain load balancer, trigger the execution to remove the original container group on the first node from the domain load balancer; If the target container group fails to join the domain load balancer, check if the detection time exceeds the preset timeout. If the detection time does not exceed the preset timeout, continue to wait and check again after the wait ends to see if the target container group has successfully joined the domain load balancer. If the detection time exceeds the preset timeout, delete the target container group created on the second node and recreate the corresponding target container group on other healthy nodes.

[0040] Successful joining means that the target container group's network address has been confirmed and registered by the load balancer, and the container group can receive traffic normally (e.g., health checks have passed). Only when successful joining is achieved is the new instance considered ready. Detection duration refers to the length of time elapsed from the start of detection to the current moment. Typically, the timer can start from the first detection after the target container group is added to the load balancer, or from the creation of the target container group. The preset timeout is a pre-configured time threshold (e.g., 30 seconds, 1 minute) used to limit the maximum tolerable time of the detection process. If the detection duration exceeds this threshold and still fails, it is considered a timeout failure.

[0041] In other words, this embodiment actively detects whether the target container group has been successfully added to the domain name load balancer. The detection result is divided into two cases: Scenario 1: Successful Joining. At this point, it's confirmed that the new container group is ready and capable of handling traffic, triggering the next step: removing the original container group on the first node from the domain load balancer. This follows the lossless migration principle of "first confirming the new container group is available, then removing the old one."

[0042] Scenario 2: Unsuccessful Joining. In this case, it will further determine whether the elapsed time since the start of the detection has exceeded the preset timeout. If it has not yet timed out, it will not immediately give up, but will enter a waiting state. After the waiting period, it will initiate the detection again, forming a "detection-failure-wait-redetection" loop, giving the load balancer or target container group a certain buffer time to complete the registration or health check. If the preset timeout has exceeded, the creation and joining operation is considered to have failed. To avoid indefinite waiting, the target container group that failed to join, created on the second node, will be actively deleted to release resources, and another healthy node will be selected to re-execute the entire process of creating the target container group and joining the load balancer.

[0043] By employing a dual safeguard mechanism of waiting for retries and re-establishing nodes after timeouts, issues such as load balancer registration delays, network fluctuations, and abnormal node resources are effectively addressed, improving the robustness of migration. Simultaneously, the design of removing the original container group only upon successful completion ensures lossless traffic: the old instance is only removed after confirming that the new instance is capable of receiving requests, thus eliminating the risk of service interruption due to the new instance not being ready.

[0044] In one embodiment, determining at least one original container group on the first node to which it needs to be migrated to obtain the second node includes: The second node is determined according to the first preset strategy; The first preset strategy includes scheduling the target container group to a healthy node that is in the same data center, cluster, and availability zone as the first node, in order to maintain the current application resource deployment topology.

[0045] The first preset strategy is a pre-configured migration target node selection rule used to specify how to select the second node when a container group needs to be migrated. This strategy emphasizes "maintaining the status quo," that is, avoiding changes to the geographical and logical distribution of the current application deployment as much as possible.

[0046] "Same data center" means the second node and the first node are located within the same physical data center. Data center is a locational concept at the infrastructure level; communication latency is low within the same data center. "Same cluster" means the second node and the first node belong to the same containerized application cluster. A cluster is the management boundary for container orchestration; nodes within the same cluster share the control plane and network policies. "Same availability zone" means the second node and the first node are located in the same cloud availability zone. An availability zone is an independent fault domain provided by a cloud service provider; nodes within the same availability zone have low network latency and sufficient bandwidth.

[0047] A healthy node is a node that is in a normal state and can schedule and run container groups normally. A healthy node typically meets conditions such as being in a "ready" state, having sufficient resources, and having no fault markers. Topology refers to the distribution of container group instances across different nodes, data centers, clusters, and availability zones. Maintaining the topology means that the distribution of container groups relative to these location dimensions remains consistent before and after migration.

[0048] Specifically, when it is necessary to determine a target node (second node) for the original container group on the first node, scheduling can be performed according to the first preset strategy. This strategy requires that the newly created target container group be scheduled to a healthy node that meets the following conditions: it is located in the same data center, the same cluster, and the same availability zone as the first node.

[0049] This constraint ensures that the migrated container group continues to operate within the same geographical location and logical management domain as before, thus maintaining the following effects: no significant increase in network latency, avoidance of cross-availability zone traffic costs, compliance with the low latency or data locality requirements of certain applications, and no disruption to the original disaster recovery and deployment design. This strategy is suitable for scenarios involving "simple failures that do not allow disruption to the current application resource deployment topology." For example, if a node's hardware fails but other nodes in the same data center remain healthy and available, operations personnel may want to migrate workloads to a backup node in the same environment rather than across zones.

[0050] In one embodiment, determining at least one original container group on the first node to which it needs to be migrated to obtain the second node includes: The second node is determined according to the second preset strategy; The second preset strategy includes: when a specified data center, specified cluster, and / or specified availability zone is configured, the target container group is scheduled to a node in the specified data center, specified cluster, and / or specified availability zone; when a specified data center, specified cluster, and / or specified availability zone is not configured, the target container group is automatically migrated to a node in a different data center, different cluster, and / or different availability zone from the first node, so as to achieve topology adjustment.

[0051] The second preset strategy is another pre-configured migration target node selection rule. In contrast to the first preset strategy's "maintain topology", this strategy focuses on "adjusting topology", that is, changing the geographical or logical distribution of application deployment according to needs.

[0052] Configuration refers to the parameters or rules set by operations and maintenance personnel before migration, such as scheduling constraints specified through configuration files, API requests, or management interfaces. Configuration content may include the data center, cluster, and / or availability zone where the target node is located. Topology adjustment refers to proactively changing the distribution structure of application instances across nodes, data centers, clusters, availability zones, etc., through migration to achieve purposes such as load balancing, disaster recovery optimization, cost reduction, or addressing resource exhaustion.

[0053] This section presents an alternative target node selection strategy alongside the first preset strategy: the second preset strategy. The core idea of ​​this strategy is to proactively adjust the application deployment topology by utilizing node failure migration opportunities. Specifically, it includes two scenarios: The first scenario: The data center, cluster, and / or availability zone are specified through configuration.

[0054] At this point, the target container group will be scheduled to a healthy node that matches the configuration, strictly following the configuration requirements. For example, operations personnel can specify "migrate to data center B", "migrate to availability zone Z2", or "migrate to cluster 2". This capability makes fault migration a planned resource rescheduling method, suitable for scenarios where business needs cross-regional disaster recovery or resource integration.

[0055] The second scenario: The specified data center, cluster, and / or availability zone were not configured.

[0056] At this point, the target container group will be automatically migrated to a node located in a different data center, different cluster, and / or different availability zone than the first node. Here, "and / or" means that there can be differences in one or more dimensions; for example, only the data center may be changed, or both the cluster and availability zone may be changed simultaneously, determined by the automatic scheduling algorithm. For instance, the node with the lowest current load may be selected, but at least one location attribute must be different. The purpose of this automatic migration is to achieve topology adjustments, such as moving instances out of fault domains, distributing load, or avoiding too many instances within the same availability zone.

[0057] The second preset strategy not only solves the instance migration problem when a node fails, but also provides a flexible topology adjustment mechanism, allowing operations and maintenance personnel to change the application deployment distribution as needed, or automatically achieve fault domain isolation when not explicitly specified, thereby improving the robustness of the cluster and resource utilization.

[0058] In one embodiment, creating a target container group corresponding to the original container group on the second node includes: Get a memory snapshot of the original container group; The container process state is restored on the second node based on a memory snapshot to generate the target container group.

[0059] A memory snapshot is a file that captures and persistently stores the complete process memory data of a running container group (formerly the container group) at a specific point in time. This snapshot typically includes information such as the application's heap memory data, loaded class metadata, thread states, and just-in-time (JIT) compiled code cache. Memory snapshots can be created after the application has finished starting and warming up for traffic, thus preserving a process image in a "ready" state.

[0060] Restoring the container process state refers to directly reconstructing the process running state of the original container group on the target node using a pre-saved memory snapshot file, without having to re-execute the standard startup process (such as loading classes, initialization, and establishing connection pools). The restored process can directly continue execution from the instruction positions recorded in the snapshot, quickly reaching a state where it can provide services.

[0061] Specifically, when creating a target container group, instead of the traditional "fresh start" approach, a memory snapshot of the original container group (or a pre-prepared baseline container group) can be obtained first. This memory snapshot is typically created after the application has finished starting, preheating the cache, and reaching its optimal service state, and has been uploaded to shared storage in advance. Then, on the second node, the container process state is directly restored based on this memory snapshot to generate the target container group. The restoration process essentially loads the memory data from the snapshot into the memory of the new node and restores the process's execution context to the state at the time of the snapshot. This allows the newly created container group to skip the lengthy startup and preheating phases and quickly reach a traffic-receiving ready state.

[0062] The above-mentioned "snapshot creation-snapshot restoration" mechanism shortens the startup time of new instances during fault migration and speeds up the "attachment" process, thereby further reducing the risk of potential traffic loss during migration.

[0063] In one embodiment, creating a target container group corresponding to the original container group on the second node includes: If a low-power container group exists that corresponds to the original container group, the resource specifications of the low-power container group are restored to the first resource specifications to serve as the target container group. The low-power container group is pre-formed in the following way: If the business load is detected to be higher than the preset load threshold, a container group with the first resource specification is created and added to the domain name load balancer. If the business load is detected to be lower than the preset load threshold, the resource specification of the container group with the first resource specification is reduced to the second resource specification, and the container group with the reduced resource specification is removed from the domain name load balancer to form a low-power container group; during the resource specification reduction process, the memory data is saved to the disk, and the released CPU resources and memory resources are included in the low-power resource pool. Resource specification recovery includes: recovering memory data from the disk, and reclaiming CPU and memory resources from the low-power resource pool.

[0064] Low-power container groups refer to a special state of container group formed by degrading the resources of normally running container groups when the business load is low. It remains running but consumes very little CPU and memory resources and has been removed from the load balancer, no longer receiving business traffic. A low-power container group is equivalent to a semi-dormant hot standby instance, which can be quickly restored to normal specifications.

[0065] Resource specifications refer to the amount of hardware resources allocated to a container group, primarily including the number of CPU cores and memory size. Resource specifications determine the container group's computing power and the amount of data it can process. The first resource specification refers to the full resource specifications a container group should have during normal operation, such as a 4-core CPU and 16GB of memory. The first resource specification is sufficient to support peak traffic. The second resource specification refers to the extremely low resource specifications that a container group is reduced to when entering a low-power state, such as 0.1 CPU cores and 1GB of memory. The second resource specification may only maintain the container group's survival (such as preserving the basic process framework) without supporting actual business processing.

[0066] A preset load threshold is a pre-defined critical value for business traffic or resource utilization. When the actual load exceeds this threshold, it is determined that container groups need to be maintained or created at normal specifications; when the load falls below this threshold, it is determined that some container groups can be degraded to a low-power state to conserve resources. A low-power resource pool is a logical resource container used to aggregate CPU and memory resources released during container group degradation. These resources can be allocated to run offline jobs (such as non-critical data analysis tasks) and reclaimed when a rapid recovery of low-power container groups is needed.

[0067] Saving memory data to disk refers to proactively writing valid data (such as cache, session state, etc.) in memory to persistent storage on disk when downgrading a container group from the first resource specification to the second resource specification, in order to prevent process crashes due to a significant reduction in memory, so that it can be recovered later. Restoring memory data from disk refers to reloading memory data from previously saved disk files when restoring a low-power container group to the first resource specification, restoring it to the memory state before the downgrade, allowing processes to continue running seamlessly. Reclaiming CPU and memory resources refers to reclaiming previously released CPU and memory resources from the low-power resource pool and reallocating them to the restored low-power container group.

[0068] In this embodiment, a batch of container groups can be pre-created and put into hibernation during off-peak periods. When a node fails and a new container group needs to be quickly activated, these hibernating instances are directly woken up and restored to their full specifications, thus saving the time required for creation, startup, and traffic warm-up. The specific process of forming low-power container groups is as follows: Continuously monitor the business load. When the business load is detected to be higher than the preset load threshold, it indicates that sufficient processing capacity is needed. At this time, a batch of container groups with the first resource specification (full specification) will be created and added to the domain name load balancer normally to receive business traffic.

[0069] When the monitored business load falls below a preset load threshold, it indicates resource redundancy, which can save costs. At this point, container groups with the highest resource specifications can be downgraded: they are removed from the domain load balancer, preventing them from receiving traffic; then their resource specifications are reduced to the second highest. When reducing memory specifications, due to the significant reduction in available memory, data in memory can be proactively saved to disk to prevent processes from crashing due to insufficient memory. Simultaneously, the freed-up CPU and memory resources are allocated to a low-power resource pool, which can be used for offline, less critical but resource-intensive jobs, thereby improving the overall resource utilization of the cluster.

[0070] When a node fails and a target container group needs to be quickly created to replace the original container group, if a low-power container group corresponding to the original container group exists (e.g., belonging to the same application or from the same batch of downgraded instances), a completely new container group will not be created in the conventional way. Instead, the resource specifications of these low-power container groups will be restored to the first resource specification. The restoration operation includes: reclaiming previously released CPU and memory resources from the low-power resource pool, restoring previously saved memory data from disk, and returning the process state of the container group to its pre-downgrade state, so that it can directly carry traffic without restarting the process. After restoration, the container group can be used as the target container group to perform subsequent operations such as adding it to the domain name load balancer.

[0071] This approach achieves extremely fast fault migration speed (no process restart required, only specification and memory data are restored), while leveraging a low-power resource pool to enable resource reuse (resources released during degradation are used for offline jobs), thus improving the overall resource utilization of the cluster while ensuring rapid fault recovery.

[0072] The container group migration method provided by the embodiments of the present invention is further described below. For example... Figure 2 As shown, Figure 2 This is a flowchart illustrating a container group migration method provided in an embodiment of the present invention. (See attached diagram.) Figure 2 When node failover is required, the fault node controller first monitors the status of nodes in the cluster to determine the first node (i.e., the fault node) that needs to be migrated for container groups. After determining the first node, the system collects information on all original container groups (Pods) on the fault node and reports the collected container group information for subsequent application identification.

[0073] Subsequently, based on the reported container group information, the application information corresponding to each container group is queried to group the original container groups according to the application dimension and generate corresponding container group migration tasks. For each migration task, the following migration process is executed: On the healthy node (i.e., the second node), create target container groups with the same number as the original container groups that need to be migrated. After creation, perform a load balancing operation on these target container groups, that is, add them to the domain name load balancer that provides external services, so that it can start receiving application traffic.

[0074] The system checks whether the target container group has been successfully added to the domain load balancer, i.e., whether it can receive traffic normally. If the check is successful, the system proceeds to the traffic grabbing step; if the check fails, it further checks whether the detection time since the addition operation has exceeded the preset timeout. If the timeout has not exceeded, the system continues to wait and performs the check again after the wait ends; if the timeout has exceeded, the target container group created on the second node is deleted, and the target container group is recreated on another healthy node, repeating the above traffic grabbing and detection process.

[0075] After confirming that the target container group has been successfully added to the domain load balancer, a traffic stripping operation is performed on the original container group on the first node. This involves removing the original container group from the domain load balancer so that it no longer receives new application traffic. After the traffic stripping operation is completed, the system determines whether the stripping was successful. If successful, the original container group on the first node is deleted, releasing the resources it occupies. At this point, the migration task for this application dimension is complete.

[0076] If the volume picking operation fails (e.g., network jitter causes the volume picking command to not take effect), the system can retry or record the exception according to the configuration, which will not be elaborated in this embodiment.

[0077] By following the process of "creating a new instance first, attaching traffic successfully, and then removing the old instance", this embodiment ensures that there is always at least one healthy container group in the backend list of the domain load balancer processing requests throughout the entire migration process, thereby achieving lossless migration of application traffic.

[0078] Figure 3 This is a flowchart illustrating a node fault monitoring method provided in an embodiment of the present invention, as shown below. Figure 3 As shown, the status of each node in the cluster can be continuously monitored. When a node is manually marked as a faulty node, it is directly designated as the first faulty node, and the subsequent faulty node container group collection and migration process begins. Manual marking is typically used in planned maintenance scenarios (such as node upgrades or hardware replacements), where operations personnel actively trigger the migration, without relying on automatic detection.

[0079] If a node has not been manually marked as a faulty node, the status of the automatic failover switch is further checked. If the automatic failover switch is not activated, the node will not be automatically migrated, and the process will end or continue monitoring other nodes.

[0080] If the automatic failover switch is on, the system uses node monitoring information (such as node health status and whether the node connection timeout exceeds a preset duration) to determine whether the node meets the automatic failover conditions. For example, if the node status changes to "not ready," or a critical component on the node becomes unresponsive, or the node connection timeout exceeds a preset duration, then the automatic failover conditions are considered met. If met, the node is designated as the first node; otherwise, the system continues monitoring other nodes.

[0081] Through the multi-level judgment mechanism of "manual marking priority, automatic switch control, and monitoring condition verification" mentioned above, this embodiment can flexibly adapt to different fault scenarios: for planned maintenance, manual marking is used to actively trigger migration; for sudden node failures, migration is automatically detected and triggered under the premise that the automatic switch is turned on; at the same time, the automatic switch provides maintenance personnel with overall control capabilities to avoid unexpected automatic migration during node brief disconnection or normal upgrades.

[0082] Figure 4 This is a schematic diagram of a container migration device provided in an embodiment of the present invention, as shown below. Figure 4 As shown, the device includes: The first determining module 401 is used to determine the node that needs to be migrated from the container group, and obtain the first node; The second determining module 402 is used to determine at least one original container group on the first node that needs to be migrated to the node, thereby obtaining the second node; The creation module 403 is used to create a target container group corresponding to the original container group on the second node, and add the target container group to the domain name load balancer that provides services to the outside world. The deletion module 404 is used to remove the original container group on the first node from the domain name load balancer and delete the original container group on the first node.

[0083] In one embodiment, the first determining module 401 determines the node that needs to be migrated from the container group, obtaining the first node, including: Monitor the status of nodes in the cluster; If a node is detected to have been manually marked as a faulty node, the node that has been manually marked as a faulty node will be identified as the first node.

[0084] In one embodiment, the first determining module 401 determines the node that needs to be migrated from the container group, thus obtaining the first node, and further includes: For nodes that have not been manually marked as faulty, check the status of the automatic failover switch; When the automatic failover switch is in the on state, the system combines node monitoring information to determine whether nodes that have not been manually marked as faulty nodes meet the automatic failover conditions; wherein, the automatic failover conditions include abnormal node health and / or node connection timeout exceeding a preset duration. The node that meets the automatic failover conditions is identified as the first node.

[0085] In one embodiment, the creation module 403 is specifically used for: Collect container group information on the first node; Based on the container group information, query the corresponding application information to group the original container groups according to the application dimension and generate corresponding container group migration tasks; According to the container group transfer task, each application executes the step of creating a target container group corresponding to the original container group on the second node.

[0086] In one embodiment, after adding the target container group to the domain name load balancer, the creation module 403 is further configured to: Detect whether the target container group has been successfully added to the domain name load balancer; If the target container group is successfully added to the domain name load balancer, the deletion module 404 is triggered to remove the original container group on the first node from the domain name load balancer. If the target container group fails to join the domain name load balancer, determine whether the detection time exceeds the preset timeout. If the detection time does not exceed the preset timeout, continue to wait and check again whether the target container group has successfully joined the domain name load balancer after the wait ends. If the detection time exceeds the preset timeout, delete the target container group created on the second node and recreate the corresponding target container group on other healthy nodes.

[0087] In one embodiment, the second determining module 402 determines at least one node to which the original container group on the first node needs to be migrated, thereby obtaining the second node, including: The second node is determined according to the first preset strategy; The first preset strategy includes scheduling the target container group to a healthy node that is in the same data center, cluster, and availability zone as the first node, in order to maintain the current application resource deployment topology.

[0088] In one embodiment, the second determining module 402 determines at least one node to which the original container group on the first node needs to be migrated, thereby obtaining the second node, including: The second node is determined according to the second preset strategy; The second preset strategy includes: scheduling the target container group to a node in a specified data center, specified cluster, and / or specified availability zone when a specified data center, specified cluster, and / or specified availability zone is configured; and automatically migrating the target container group to a node in a different data center, different cluster, and / or different availability zone than the first node when a specified data center, specified cluster, and / or specified availability zone is not configured, so as to achieve topology adjustment.

[0089] In one embodiment, the creation module 403 creates a target container group corresponding to the original container group on the second node, including: Obtain a memory snapshot of the original container group; Based on the memory snapshot, the container process state is restored on the second node to generate the target container group.

[0090] In one embodiment, the creation module 403 creates a target container group corresponding to the original container group on the second node, including: If a low-power container group exists that corresponds to the original container group, the resource specifications of the low-power container group are restored to the first resource specifications to serve as the target container group. The low-power container group is pre-formed in the following manner: If the business load is detected to be higher than the preset load threshold, a container group with the first resource specification is created and the container group with the first resource specification is added to the domain name load balancer. If the business load is detected to be lower than the preset load threshold, the resource specification of the container group with the first resource specification is reduced to the second resource specification, and the container group with the reduced resource specification is removed from the domain name load balancer to form the low-power container group; during the resource specification reduction process, the memory data is saved to the disk, and the released CPU resources and memory resources are included in the low-power resource pool. The resource specification recovery includes: recovering memory data from the disk, and reclaiming the CPU resources and memory resources from the low-power resource pool.

[0091] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional modules is merely an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. The specific working process of the functional modules described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0092] The apparatus of this invention employs a "build first, then remove" strategy. On the second node, a target container group corresponding to the original container group is pre-created and added to the domain name load balancer providing external services. After the target container group successfully handles the traffic, the original container group is removed from the load balancer. This ensures that the domain name load balancer always has available container groups to carry business traffic, eliminating the traffic interruption window caused by container group reconstruction delays, solving the problem of partial application traffic damage in existing technologies, and achieving lossless application traffic migration. By using the "add to load balancer first, then remove the original container group" operation sequence, it ensures that at any time during traffic switching, there are always container groups in a service state behind the domain name load balancer. Therefore, business requests can always be received and processed by normal container groups, improving the integrity and reliability of request processing during migration and reducing request failure rate and timeout risk.

[0093] The following is for reference. Figure 5 It shows a schematic diagram of the structure of a computer system 500 suitable for implementing an electronic device according to embodiments of the present invention. Figure 5 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments of the present invention.

[0094] like Figure 5As shown, the computer system 500 includes a central processing unit (CPU) 501, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 502 or programs loaded from storage section 508 into random access memory (RAM) 503. The RAM 503 also stores various programs and data required for the operation of the computer system 500. The CPU 501, ROM 502, and RAM 503 are interconnected via a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.

[0095] The following components are connected to I / O interface 505: input section 506 including keyboard, mouse, etc.; output section 507 including cathode ray tube, liquid crystal display, etc., and speakers, etc.; storage section 508 including hard disk, etc.; and communication section 509 including network interface card, such as modem, etc. Communication section 509 performs communication processing via a network such as the Internet. Drive 510 is also connected to I / O interface 505 as needed. Removable media 511, such as disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 510 as needed so that computer programs read from them can be installed into storage section 508 as needed.

[0096] In particular, according to the embodiments disclosed in this invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 509, and / or installed from removable medium 511. When the computer program is executed by central processing unit (CPU) 501, it performs the functions defined above in the system of this invention.

[0097] It should be noted that the computer-readable medium shown in this invention can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, a random access memory, a read-only memory, an erasable programmable read-only memory, an optical fiber, a portable compact disk read-only memory, an optical storage device, a magnetic storage device, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this invention, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, etc., or any suitable combination thereof.

[0098] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0099] The modules and / or units described in the embodiments of the present invention can be implemented in software or hardware. The described modules and / or units can also be housed in a processor; for example, a processor can be described as including a first determining module, a second determining module, a creating module, and a deleting module. The names of these modules do not necessarily limit the functionality of the module itself.

[0100] In another aspect, the present invention also provides a computer-readable medium, which may be included in the device described in the above embodiments; or it may exist independently and not assembled into the device. The computer-readable medium carries one or more programs, which, when executed by the device, cause the device to include: The nodes that need to be migrated for container groups are identified as the first nodes; at least one original container group on the first node is identified as the node to which it needs to be migrated to, resulting in the second nodes; a target container group corresponding to the original container group is created on the second node, and the target container group is added to the domain name load balancer that provides services to the outside world; the original container group on the first node is removed from the domain name load balancer, and the original container group on the first node is deleted.

[0101] The technical solution of this invention employs a "build first, then remove" strategy. A target container group corresponding to the original container group is pre-created on the second node and added to the domain name load balancer providing external services. After the target container group successfully handles the traffic, the original container group is removed from the load balancer. This ensures that there are always available container groups in the domain name load balancer to carry business traffic, eliminating the traffic interruption window caused by container group reconstruction delays, solving the problem of partial application traffic damage in existing technologies, and achieving lossless migration of application traffic. By using the "add to load balancer first, then remove the original container group" operation sequence, it ensures that at any time during traffic switching, there are always container groups in a service state behind the domain name load balancer. Therefore, business requests can always be received and processed by normal container groups, improving the integrity and reliability of request processing during migration and reducing request failure rate and timeout risk.

[0102] This invention also provides a computer program product, including a computer program that, when executed by a processor, implements the container group migration method provided in any embodiment of this invention.

[0103] In the implementation of a computer program product, computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof. Programming languages ​​include object-oriented programming languages ​​as well as conventional procedural programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including local area networks (LANs) or wide area networks (WANs), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0104] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0105] It should be noted that the collection, use, storage, sharing, and transfer of user personal information involved in the technical solution of this invention all comply with the provisions of relevant laws and regulations, and require notification to the user and obtaining the user's consent or authorization. Where applicable, user personal information has undergone de-identification and / or anonymization and / or encryption technical processing. In addition, a corresponding operation entry is provided for the user to choose to agree to or reject the automated decision result; if the user chooses to reject, the process proceeds to the expert decision-making process.

[0106] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and objectives can occur depending on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method of container group migration, the method comprising: The method includes: Identify the nodes that need to be migrated from the container group to obtain the first node; Determine at least one original container group on the first node to which it needs to be migrated, and obtain the second node; Create a target container group corresponding to the original container group on the second node, and add the target container group to the domain name load balancer that provides services to the outside world; Remove the original container group on the first node from the domain name load balancer and delete the original container group on the first node.

2. The method of claim 1, wherein, The nodes that need to be migrated from the container group are identified, resulting in the first node, which includes: Monitor the status of nodes in the cluster; If a node is detected to have been manually marked as a faulty node, the node that has been manually marked as a faulty node will be identified as the first node.

3. The method of claim 2, wherein, The nodes that need to be migrated for the container group are identified, resulting in the first node, which also includes: For nodes that have not been manually marked as faulty, check the status of the automatic failover switch; When the automatic failover switch is in the on state, the system determines whether nodes that have not been manually marked as faulty nodes meet the automatic failover conditions based on node monitoring information; wherein, the automatic failover conditions include abnormal node health and / or node connection timeout exceeding a preset duration. The node that meets the automatic failover conditions is identified as the first node.

4. The method of claim 1, wherein, After obtaining the first node, the method further includes: Collect container group information on the first node; Based on the container group information, query the corresponding application information to group the original container groups according to the application dimension and generate corresponding container group migration tasks; According to the container group transfer task, each application executes the step of creating a target container group corresponding to the original container group on the second node.

5. The method of claim 1, wherein, After adding the target container group to the domain name load balancer, the method further includes: Detect whether the target container group has been successfully added to the domain name load balancer; If the target container group is successfully added to the domain name load balancer, the original container group on the first node is removed from the domain name load balancer. If the target container group fails to join the domain name load balancer, determine whether the detection time exceeds the preset timeout. If the detection time does not exceed the preset timeout, continue to wait and check again whether the target container group has successfully joined the domain name load balancer after the wait ends. If the detection time exceeds the preset timeout, delete the target container group created on the second node and recreate the corresponding target container group on other healthy nodes.

6. The method of claim 1, wherein, To determine the node to which at least one original container group on the first node needs to be migrated, a second node is obtained, including: The second node is determined according to the first preset strategy; The first preset strategy includes scheduling the target container group to a healthy node that is in the same data center, cluster, and availability zone as the first node, in order to maintain the current application resource deployment topology.

7. The method according to claim 1, characterized in that, To determine the node to which at least one original container group on the first node needs to be migrated, a second node is obtained, including: The second node is determined according to the second preset strategy; The second preset strategy includes: scheduling the target container group to a node in a specified data center, specified cluster, and / or specified availability zone when a specified data center, specified cluster, and / or specified availability zone is configured; and automatically migrating the target container group to a node in a different data center, different cluster, and / or different availability zone than the first node when a specified data center, specified cluster, and / or specified availability zone is not configured, so as to achieve topology adjustment.

8. The method according to any one of claims 1 to 7, characterized in that, Creating a target container group corresponding to the original container group on the second node includes: Obtain a memory snapshot of the original container group; Based on the memory snapshot, the container process state is restored on the second node to generate the target container group.

9. The method according to any one of claims 1 to 7, characterized in that, Creating a target container group corresponding to the original container group on the second node includes: If a low-power container group exists that corresponds to the original container group, the resource specifications of the low-power container group are restored to the first resource specifications to serve as the target container group. The low-power container group is pre-formed in the following manner: If the business load is detected to be higher than the preset load threshold, a container group with the first resource specification is created and the container group with the first resource specification is added to the domain name load balancer. If the business load is detected to be lower than the preset load threshold, the resource specification of the container group with the first resource specification is reduced to the second resource specification, and the container group with the reduced resource specification is removed from the domain name load balancer to form the low-power container group; during the resource specification reduction process, the memory data is saved to the disk, and the released CPU resources and memory resources are included in the low-power resource pool. The resource specification recovery includes: recovering memory data from the disk, and reclaiming the CPU resources and memory resources from the low-power resource pool.

10. A container group migration apparatus characterized by comprising: The device includes: The first determination module is used to determine the nodes that need to be migrated from the container group, and obtain the first node; The second determining module is used to determine at least one original container group on the first node that needs to be migrated to, thereby obtaining the second node; A creation module is used to create a target container group corresponding to the original container group on the second node, and add the target container group to the domain name load balancer that provides services to the outside world; The deletion module is used to remove the original container group on the first node from the domain name load balancer and delete the original container group on the first node.

11. An electronic device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, The processor executes the container group migration method as described in any one of claims 1 to 9.

12. A computer readable storage medium having stored thereon a computer program, characterized in that, When the program is executed by the processor, it implements the container group migration method as described in any one of claims 1 to 9.

Images