Real-time migration method and system for containerized application

Abstract

The invention provides a real-time migration method and system for containerized applications. Under the condition that the source container in the source host runs continuously, copying memory data and file system data of the source container into the target host so as to perform pre-migration; in the pre-migration process, dirty pages in the source host are tracked; the dirty pages are changed memory pages; synchronizing dirty page data generated by the source container in the pre-migration process to a target host through at least one round of iteration process in an incremental synchronization mode so as to realize incremental synchronization; judging whether the incremental synchronization process is finished or not, and if yes, executing network switching; when network switching is executed, capturing a network connection state at a kernel network layer of the source host, synchronizing the network connection state to the target host, and redirecting network traffic to the target host; and activating the target container on the target host, and releasing resources of the source container on the source host. According to the invention, the service interruption time in the containerized application migration process can be reduced.

Description

Technical Field

[0001] One or more embodiments of the present invention relate to network communication technology, and more particularly to a method and system for real-time migration of containerized applications. Background Technology

[0002] With the widespread adoption of cloud computing and microservice architectures, containerization technologies (such as Docker and Podman) have become central to application deployment and management. In large data centers and distributed systems, it is often necessary to migrate a running container from one physical host (source host) to another physical host (target host) in order to achieve load balancing, hardware maintenance, or fault recovery.

[0003] Existing container migration technologies, such as those utilizing the CRIU (Checkpoint / Restore In Userspace) project, typically employ a "stop-and-copy" model. This model first requires pausing the container's operation, taking a snapshot (checkpoint) of its memory, process state, and file system changes, then transferring the snapshot data to the target host, and finally restoring the container's operation on the target host using the snapshot.

[0004] However, the drawbacks of this approach are obvious. There is a service interruption window between when a container is paused and when it resumes operation. For memory-intensive, I / O-intensive applications, this interruption can last for several seconds or even longer, which is unacceptable for online services requiring high availability, such as e-commerce, financial transactions, or real-time communication systems.

[0005] Therefore, how to reduce or even eliminate service interruption time during container migration and achieve real-time migration that is transparent to users is a technical challenge that urgently needs to be solved in this field. Summary of the Invention

[0006] One or more embodiments of the present invention describe a real-time migration method and system for containerized applications, which can reduce service interruption time during the migration process of containerized applications.

[0007] According to the first aspect, a method for real-time migration of containerized applications is provided, including:

[0008] While the source container continues to run on the source host, the memory data and file system data of the source container are copied to the target host, thereby achieving pre-migration;

[0009] During the pre-migration process, dirty pages in the source host are tracked; wherein, dirty pages are memory pages that have changed.

[0010] Through at least one round of iteration and in an incremental synchronization manner, the dirty page data generated by the source container during the pre-migration process is synchronized to the target host to achieve incremental synchronization;

[0011] Determine whether the incremental synchronization process has ended. If it has, perform a network switch; otherwise, continue with the next iteration of the process.

[0012] When performing a network switch, the network connection state is captured at the kernel network layer of the source host, the network connection state is synchronized to the target host, and network traffic is redirected to the target host;

[0013] Activate the target container on the target host and release the resources of the source container on the source host.

[0014] The determination of whether the incremental synchronization process has ended includes:

[0015] After each iteration, the number of dirty pages in the source host that have not yet been synchronized and the current transmission rate are obtained. It is then determined whether the dirty page generation rate in the N consecutive iterations is lower than the transmission rate and whether the amount of data in the remaining unsynchronized dirty pages is lower than a preset threshold. If both are true, the incremental synchronization process ends.

[0016] The process of copying the source container's memory data and file system data to the target host while the source container continues to run on the source host includes:

[0017] While the source container is running continuously on the source host, the enhanced CRIU tool or the kernel interface is invoked to quickly scan all memory pages of the source container and copy the current memory state to obtain memory image data. The obtained memory image data is then transmitted to the target host over the network.

[0018] The process of tracking dirty pages in the source host during the pre-migration includes:

[0019] Write protection is set for the memory pages of the source container in the kernel of the source host through a kernel module;

[0020] A page fault is triggered when any process within the source container attempts to write to any of the first memory pages.

[0021] The interrupt is captured by the kernel, and write protection is disabled.

[0022] The original data of the first memory page is copied to a new location for the process to write, and the address of the first memory page is recorded in a pre-set dirty page log, thereby realizing the tracking of dirty pages in the source host.

[0023] The containerized application is a containerized application based on the Linux kernel;

[0024] The process of capturing network connection status at the kernel network layer of the source host, synchronizing the network connection status to the target host, and redirecting network traffic to the target host includes:

[0025] Load the pre-compiled eBPF program into the flow control entry point of the network interface used by the source container;

[0026] The eBPF program parses each data packet flowing through the flow control entry point, extracts the connection state information of the data packet, and synchronizes the extracted connection state information to the target host in real time; the eBPF program does not drop or block data packets.

[0027] While synchronizing the connection state, the eBPF program temporarily places newly arriving inbound packets into a buffer located in kernel space.

[0028] Once the target host confirms that it has received all connection state information and the target container is ready, it updates the routing table of the upstream network device so that all traffic originally directed to the source host's IP address is redirected to the target host's IP address.

[0029] The containerized application is a containerized application based on the Linux kernel;

[0030] Activating the target container on the target host includes:

[0031] Pause the source container for a preset time;

[0032] The source host generates a final state data packet and sends it to the target host; the final state data packet includes: dirty page data generated during the last iteration, CPU register status, and process tree information;

[0033] After the target host receives the final state data packet, a recovery operation is performed on the target container, and a corresponding eBPF program is injected into the network interface of the target host. The eBPF program retrieves data packets from the buffer and injects the retrieved data packets into the process of the recovered target container according to the synchronized connection state, so that the connection is not interrupted.

[0034] According to the second aspect, a real-time migration system for containerized applications is provided, comprising: a migration controller, a source migration agent, a target migration agent, and a kernel-level enhancement module; wherein,

[0035] The migration controller is configured to, upon detecting a migration trigger condition, instruct the source migration agent to perform migration processing, and determine whether the incremental synchronization process has ended. If so, it triggers the kernel layer enhancement module to perform network switching; otherwise, it triggers the source migration agent to continue executing the next round of the iteration process. During network switching, it redirects network traffic to the target host.

[0036] The source migration agent is configured to, upon receiving an instruction to perform migration processing, copy the memory data and file system data of the source container to the target host while the source container in the source host continues to run, thereby achieving pre-migration; and, through at least one round of iterative process and in an incremental synchronization manner, synchronize the dirty page data generated by the source container during the pre-migration process to the target host, thereby achieving incremental synchronization; and, release the resources of the source container on the source host.

[0037] The kernel layer enhancement module is configured to track dirty pages in the source host during the pre-migration process; wherein, the dirty page is a memory page that has changed; and when performing network switching, to capture the network connection status in the kernel network layer of the source host and synchronize the network connection status to the target host.

[0038] The target migration agent is configured to activate the target container on the target host.

[0039] The migration controller is configured to provide an API interface, receive migration instructions, maintain the migration state machine, and communicate with the source migration agent and the target migration agent.

[0040] And / or,

[0041] Each of the source migration agent and the target migration agent is configured to perform at least one of the following:

[0042] Use the CRIU tool to perform memory snapshots and restores;

[0043] Interact with the kernel-level enhancement module to manage copy-on-write tracking of dirty pages;

[0044] Perform file system synchronization;

[0045] Loading and unloading eBPF applications;

[0046] Establish a data transmission channel between hosts.

[0047] According to a third aspect, a computing device is provided, including a memory and a processor, wherein the memory stores executable code, and the processor executes the executable code to implement the method described in any embodiment of the present invention.

[0048] As can be seen, by synchronizing most of the data in advance and incrementally without stopping the container, and by realizing the synchronization of connection status and seamless traffic redirection at the network layer, the embodiments of the present invention greatly reduce service interruption time, and the notification can be shortened to the millisecond level, ensuring business continuity, realizing real-time migration that is almost transparent to users, and significantly improving service availability and continuity. Attached Figure Description

[0049] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the 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 based on these drawings without creative effort.

[0050] Figure 1 This is a flowchart of a real-time migration method for containerized applications in one embodiment of the present invention.

[0051] Figure 2 This is a schematic diagram of a system architecture applied in one embodiment of the present invention.

[0052] Figure 3 This is a schematic diagram of a system architecture applied in another embodiment of the present invention. Detailed Implementation

[0053] The solution provided by the present invention will now be described with reference to the accompanying drawings.

[0054] First, it should be noted that the terminology used in the embodiments of this invention is for the purpose of describing specific embodiments only and is not intended to limit the invention. The singular forms “a,” “the,” and “the” used in the embodiments of this invention and the appended claims are also intended to include the plural forms, unless the context clearly indicates otherwise.

[0055] It should be understood that the term "and / or" used in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0056] Figure 1 This is a flowchart of a real-time migration method for containerized applications according to one embodiment of the present invention. See also... Figure 1 The method includes:

[0057] Step 101: While the source container continues to run on the source host, copy the memory data and file system data of the source container to the target host to achieve pre-migration.

[0058] Step 103: During the pre-migration process, track dirty pages in the source host; wherein, the dirty page is a memory page that has changed.

[0059] Step 105: Through at least one round of iteration and in an incremental synchronization manner, the dirty page data generated by the source container during the pre-migration process is synchronized to the target host to achieve incremental synchronization.

[0060] Step 107: Determine whether the incremental synchronization process has ended. If yes, proceed to step 109; otherwise, return to step 105 to continue the next iteration process.

[0061] Step 109: When performing a network switch, capture the network connection state at the kernel network layer of the source host, synchronize the network connection state to the target host, and redirect network traffic to the target host;

[0062] Step 111: Activate the target container on the target host and release the resources of the source container on the source host.

[0063] according to Figure 1 As can be seen from the flowchart, the method of this embodiment of the invention can actually include four stages: pre-migration (steps 101 to 103), incremental synchronization (steps 105 to 107), network state synchronization and switching (step 109), and final activation (step 111).

[0064] In this embodiment of the invention, by synchronizing most of the data in advance and incrementally without stopping the container, and by realizing the synchronization of connection status and seamless redirection of traffic at the network layer, this embodiment of the invention greatly reduces service interruption time, and the notification can be shortened to the millisecond level, realizing real-time migration that is almost transparent to users, and significantly improving the availability and continuity of services.

[0065] It should be noted that, in various embodiments of the present invention, the migration of containerized applications based on the Linux kernel can be performed in real time.

[0066] See Figure 2 One embodiment of the present invention proposes a real-time migration system for containerized applications, the system comprising: a migration controller, a source migration proxy, a target migration proxy, and a kernel-level enhancement module; wherein,

[0067] The migration controller is configured to, upon detecting a migration trigger condition, have the instruction source migration agent perform migration processing, and determine whether the incremental synchronization process has ended. If so, it triggers the kernel layer enhancement module to perform network switching; otherwise, it continues to execute the next round of the iteration process. During network switching, it redirects network traffic to the target host.

[0068] The source migration agent is configured to, upon receiving an instruction to perform migration processing, copy the memory data and file system data of the source container to the target host through the target migration agent while the source container in the source host continues to run, thereby achieving pre-migration; and, through at least one round of iterative process and in an incremental synchronization manner, synchronize the dirty page data generated by the source container during the pre-migration process to the target host, thereby achieving incremental synchronization; and, release the resources of the source container on the source host.

[0069] The kernel layer enhancement module is configured to track dirty pages in the source host during the pre-migration process; wherein, the dirty page is a memory page that has changed; and when performing network switching, to capture the network connection status in the kernel network layer of the source host and synchronize the network connection status to the target host.

[0070] The target migration agent is configured to activate the target container on the target host.

[0071] In one embodiment of the system of the present invention, the migration controller is configured to provide an API interface, receive migration instructions, maintain a migration state machine, and communicate with the source migration agent and the target migration agent.

[0072] In one embodiment of the system of the present invention, each of the source migration agent and the target migration agent is configured to perform at least one of the following:

[0073] Use the CRIU tool to perform memory snapshots and restores;

[0074] Interact with the kernel-level enhancement module to manage copy-on-write tracking of dirty pages;

[0075] Perform file system synchronization;

[0076] Loading and unloading eBPF applications;

[0077] Establish a data transmission channel between hosts.

[0078] In one embodiment of the system of the present invention, the containerized application is a containerized application based on the Linux kernel.

[0079] As mentioned above, the embodiments of the present invention may actually include four stages: pre-migration, incremental synchronization, network state synchronization and switching, and final activation. The following will combine... Figure 1 Each step shown and Figure 2 and Figure 3 The system architecture shown illustrates the processing of these four stages.

[0080] First, prior to the pre-migration, i.e. before step 101, one embodiment of the present invention may further include an Initiate Migration phase, such as the processing of step 100 below.

[0081] Step 100: During the migration initiation process, this is triggered by an external command or cluster management system (such as Kubernetes) by calling the migration controller's API. For example, an administrator executes the command `migrate_container` on source host A.<container_id><target_host_b> Once the migration controller receives the instruction, it begins coordinating the entire migration process.

[0082] Next, perform step 101: While the source container continues to run on the source host, copy the memory data and file system data of the source container to the target host to achieve pre-migration.

[0083] Step 101 is part of the pre-migration phase. The goal of this phase is to complete the initial synchronization of most of the data without affecting the normal operation of the source container.

[0084] In one embodiment of the present invention, step 101, which involves copying the memory data and file system data of the source container to the target host while the source container continues to run on the source host, includes:

[0085] While the source container is running continuously on the source host, the enhanced CRIU tool or the kernel interface is invoked to quickly scan all memory pages of the source container and copy the current memory state to obtain memory image data. The obtained memory image data is then transmitted to the target host over the network.

[0086] Next, step 103 is performed: during the pre-migration process, dirty pages in the source host are tracked; wherein, dirty pages are memory pages that have changed.

[0087] In one embodiment of the present invention, step 103, which involves tracking dirty pages in the source host during the pre-migration process, includes:

[0088] Write protection is set for the memory pages of the source container in the kernel of the source host through a kernel module;

[0089] A page fault is triggered when any process within the source container attempts to write to any of the first memory pages.

[0090] The interrupt is captured by the kernel, and write protection is disabled.

[0091] The original data of the first memory page is copied to a new location for the process to write, and the address of the first memory page is recorded in a pre-set dirty page log, thereby realizing the tracking of dirty pages in the source host.

[0092] See Figure 3 The pre-migration phases of steps 101 to 103 will be described in detail below.

[0093] (1) Initial memory snapshot and transfer:

[0094] Migration Agent A (see Figure 3 2a) Invoke an enhanced CRIU tool or directly utilize the kernel interface to perform a "dirty snapshot" of all memory pages of the source container (located on source host A). This process does not freeze the container's operation but quickly scans and copies the current memory state. This complete memory image is then transferred over the network to target host B.

[0095] (2) Enable Copy-on-Write (COW) tracing:

[0096] Simultaneously with the initial memory snapshot, migration agent A uses a kernel module to set write protection for the container's memory pages within the source host A's kernel. When any process within the container attempts to write to a memory page, a page fault is triggered. The kernel catches this fault, removes the write protection, copies the original data of the page to a new location for the process to write to, and simultaneously records the address of the memory page in a "dirty page log." This efficiently tracks all memory pages modified after the initial synchronization.

[0097] (3) File system synchronization:

[0098] Meanwhile, the system uses tools such as rsync to synchronize the file system data mounted by the source container (such as the read / write layer of overlayfs) to the target host B.

[0099] Next, step 105 is executed: through at least one round of iteration and in an incremental synchronization manner, the dirty page data generated by the source container during the pre-migration process is synchronized to the target host to achieve incremental synchronization.

[0100] Step 107: Determine whether the incremental synchronization process has ended. If yes, proceed to step 109; otherwise, return to step 105 to continue the next iteration process.

[0101] Steps 105 and 107 constitute the incremental synchronization phase. This phase iterates multiple times, continuously synchronizing the changed data generated after the previous phase, until the data states of the source and target hosts become consistent.

[0102] In one embodiment of the present invention, step 107, determining whether the incremental synchronization process has ended, includes:

[0103] After each iteration, the number of dirty pages in the source host that have not yet been synchronized and the current transmission rate are obtained. It is then determined whether the dirty page generation rate in the N consecutive iterations is lower than the transmission rate and whether the amount of data in the remaining unsynchronized dirty pages is lower than a preset threshold. If both are true, the incremental synchronization process ends.

[0104] See Figure 3 The incremental synchronization phases from steps 105 to 107 will be explained in detail below.

[0105] (1) Iterative synchronization of dirty pages:

[0106] The migration controller is configured to run a loop. In each loop, migration agent A ( Figure 3 2a) Read the "dirty page log" and send all the dirty page data recorded therein to the migration agent B of the target host B. Figure 3 ,2b).

[0107] (2) Convergence judgment:

[0108] After each round of synchronization, the migration controller assesses the number of remaining dirty pages and the transfer rate. When the rate of dirty page generation is lower than the transfer rate for several consecutive rounds, and the amount of remaining unsynchronized data is below a preset threshold (e.g., less than 1% of total memory), the incremental synchronization phase ends, preparing for the final switchover phase. This process typically involves 3 to 5 iterations.

[0109] Next, proceed to step 109: When performing a network switch, capture the network connection state at the kernel network layer of the source host, synchronize the network connection state to the target host, and redirect network traffic to the target host.

[0110] Step 109 is the processing of the Network State Synchronization and Switch-over Phase.

[0111] In one embodiment of the present invention, the containerized application is: a containerized application based on the Linux kernel;

[0112] Therefore, in step 109, the network connection state is captured at the kernel network layer of the source host, synchronized to the target host, and network traffic is redirected to the target host, including:

[0113] Load the pre-compiled eBPF program into the flow control entry point of the network interface used by the source container;

[0114] The eBPF program parses each data packet flowing through the flow control entry point, extracts the connection state information of the data packet, and synchronizes the extracted connection state information to the target host in real time; the eBPF program does not drop or block data packets.

[0115] While synchronizing the connection state, the eBPF program temporarily places newly arriving inbound packets into a buffer located in kernel space.

[0116] Once the target host confirms that it has received all connection state information and the target container is ready, it updates the routing table of the upstream network device so that all traffic originally directed to the source host's IP address is redirected to the target host's IP address.

[0117] See Figure 3 The following section provides a detailed explanation of the network status synchronization and switching phase in step 109.

[0118] (1) Injecting eBPF program:

[0119] Migration agent A on migration controller source host A will send a pre-compiled eBPF program A (see Migration Agent A) to the source host A. Figure 3 ,3a) Loaded onto the flow control ingress (TC Ingress) of the network interface (such as the veth device) used by the source container.

[0120] (2) Capture and synchronize connection status:

[0121] eBPF program A begins operation. Instead of dropping or blocking packets, it parses every packet flowing through the interface, especially TCP packets. It extracts critical connection state information (such as source / destination IP and port, TCP sequence number, window size, etc.) and synchronizes this state information to the target host B in real time.

[0122] (3) Buffering new inbound traffic:

[0123] While synchronizing the connection state, eBPF program A temporarily places newly arriving inbound packets into a kernel-space buffer. This is done to prevent packets from being sent to the source container that is about to be destroyed at the moment of final switchover.

[0124] (4) Traffic redirection:

[0125] Once the target host B confirms that it has received all connection statuses and that the container replicas are ready, the migration controller will immediately update the routing table of the upstream network device (such as a load balancer or router) to redirect all traffic that was originally directed to the IP address of the source host A to the IP address of the target host B.

[0126] Next, perform step 111: Activate the target container on the target host and release the resources of the source container on the source host.

[0127] Step 111 is the Final Consistency and Activation Phase.

[0128] In one embodiment of the present invention, the containerized application is: a containerized application based on the Linux kernel;

[0129] Therefore, step 111, activating the target container on the target host, includes:

[0130] Pause the source container for a preset time;

[0131] The source host generates a final state data packet and sends it to the target host; the final state data packet includes: dirty page data generated during the last iteration, CPU register status, and process tree information;

[0132] After the target host receives the final state data packet, a recovery operation is performed on the target container, and a corresponding eBPF program is injected into the network interface of the target host. The eBPF program retrieves data packets from the buffer and injects the retrieved data packets into the process of the recovered target container according to the synchronized connection state, so that the connection is not interrupted.

[0133] See Figure 3 The final consistency and activation phase of step 111 will be explained in detail below.

[0134] (1) Final synchronization:

[0135] At this moment, the source container is briefly paused (usually only for a few milliseconds). Migration agent A packages the final state data, including the very few dirty pages generated in the last round, CPU register states, and precise process tree information, and sends it to the target host B.

[0136] (2) Restore and activate on the target host:

[0137] After receiving the final state data packet, the migration agent B of the target host B immediately performs a restore operation on the container replica that has been basically synchronized. At the same time, it injects a corresponding eBPF program (4) on the network interface of the target host. This program will retrieve data packets from the buffer and smoothly inject them into the restored container process according to the synchronized connection state, ensuring that the TCP connection is not interrupted.

[0138] (3) Clean up resources:

[0139] Once the migration controller confirms that the container on target host B has successfully taken over all traffic and is functioning normally, it instructs the migration agent on source host A to thoroughly clean up and destroy the source container and all its associated resources. The migration process is now complete.

[0140] In one embodiment of the present invention, Figure 2 , Figure 3 The functions of each component shown include:

[0141] (1) Migration Controller (Migration Controller, 1):

[0142] As a centralized service, it typically runs on the cluster's management node. It provides an API interface, receives migration instructions, and acts as the "commander" to coordinate the entire process. It maintains the migration state machine and communicates with migration agents on each host.

[0143] (2) Migration Agent (2a, 2b):

[0144] It runs as a daemon process on each compute node (source and target hosts). It is responsible for performing specific operations, such as:

[0145] Use tools such as CRIU to perform memory snapshots and restores;

[0146] Interact with kernel modules to manage copy-on-write (COW) tracing;

[0147] Perform file system synchronization;

[0148] Loading and unloading eBPF applications;

[0149] Establish a data transmission channel between hosts.

[0150] (3) Kernel-level Enhancements:

[0151] COW (Combine Written) dirty page tracking module: efficiently records memory changes.

[0152] eBPF programs (3a, 3b): Deployed on the network data path, they are key to achieving seamless network handover. They run directly in the kernel and offer extremely high performance.

[0153] The following is a detailed explanation using a specific example: migrating a Redis container that is currently processing requests.

[0154] See Figure 3 Suppose we have a running Redis caching service container on host A handling a large number of read and write requests. Now, because host A needs hardware maintenance, we need to migrate this Redis container to host B in real time.

[0155] (1) Start the migration:

[0156] The administrator executes the command `migrate_container redis-server-1host-b`. The migration controller (1) receives the command.

[0157] (2) Pre-migration:

[0158] On host A, the migration agent (2a) begins taking an initial snapshot of, for example, 2GB of memory used by the Redis container, and sends it to host B over a 10Gbps network. The Redis service remains completely unaffected during this process and continues to process requests.

[0159] At the same time, the kernel begins tracking all memory pages modified by Redis. For example, when a SET command modifies a key-value pair, the corresponding memory page is marked as a "dirty page".

[0160] (3) Incremental synchronization:

[0161] Round 1: After 500 milliseconds, approximately 100MB of dirty pages were generated. Migration agent A sent this 100MB of data to host B.

[0162] Round Two: Another 200 milliseconds passed, and 20MB of dirty pages were generated. Migration agent A resent this 20MB of data.

[0163] Third round: After another 100 milliseconds, only 5MB of dirty pages were generated. The controller determined that the convergence condition had been met.

[0164] (4) Network switching:

[0165] Migration agent A loads the eBPF program on the network interface of host A (3a).

[0166] At this point, a client sends a GET key request. This request packet arrives at host A, the eBPF program captures its TCP connection information (sequence number, etc.), synchronizes the state with host B, and then puts the packet into the kernel buffer.

[0167] The migration controller immediately updates the load balancer, resolving the Redis service's IP address from host A's IP to host B's IP. All subsequent new client requests will then be sent directly to host B.

[0168] (5) Final activation:

[0169] The Redis container is paused on host A (approximately 5 milliseconds). The last few KB of dirty pages and CPU register status are sent to host B.

[0170] The migration agent (2b) on host B completes container recovery. It loads the corresponding eBPF program, retrieves the previously buffered GET key request packet from the buffer, and injects it into the newly activated Redis process.

[0171] The Redis process processes this request and returns the result as if it had never been moved. For the client, there's only a slight increase in network latency; the connection is never broken.

[0172] After the migration controller confirms that the Redis service on host B is working properly, it destroys the old container on host A.

[0173] Through the above technical solutions and embodiments, the present invention successfully reduced the service interruption of seconds in traditional migration to milliseconds, achieving real-time migration with minimal impact on business.

[0174] Compared with the prior art, the beneficial effects of the various embodiments of the present invention include at least the following:

[0175] 1. Extremely low service interruption time: Through pre-synchronization and incremental synchronization, the vast majority of data is migrated while container A is still running. The final switchover phase takes only milliseconds, which is almost imperceptible to end users, achieving near-zero downtime migration.

[0176] 2. High efficiency and low overhead: By utilizing the Linux kernel's native copy-on-write and eBPF mechanisms, a large amount of data comparison and state tracking in user space is avoided, reducing the impact of the migration process on system performance.

[0177] 3. Smooth transition of network connections: By using eBPF to redirect traffic at the kernel network stack level, it ensures that long-lived TCP connections will not be broken during the migration process, avoiding the need for client reconnection and improving user experience.

[0178] 4. High versatility: This method does not depend on a specific container runtime (such as Docker or containerd) and works directly on Cgroups and Namespaces at the Linux kernel level, thus having better versatility and compatibility.

[0179] One embodiment of the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method in any of the embodiments of the specification.

[0180] One embodiment of the present invention provides a computing device, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, it implements the method of any embodiment in the specification.

[0181] It is understood that the structures illustrated in the embodiments of the present invention do not constitute a specific limitation on the apparatus of the embodiments of the present invention. In other embodiments of the specification, the above-described apparatus may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0182] The various embodiments in this invention are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the device embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0183] Those skilled in the art will recognize that, in one or more of the examples above, the functions described in this invention can be implemented using hardware, software, widgets, or any combination thereof. When implemented in software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium.

[0184] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above description is only a specific embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made on the basis of the technical solution of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for containerized application live migration, the method comprising: The application comprises the following steps: In the case that the source container in the source host keeps running, the memory data and file system data of the source container are copied to the target host, so as to realize pre-migration; In the process of pre-migration, the dirty pages in the source host are tracked; wherein the dirty pages are the memory pages that have changed; Through at least one iteration process and in an incremental synchronization manner, the dirty page data generated by the source container in the process of pre-migration is synchronized to the target host, so as to realize incremental synchronization; It is judged whether the incremental synchronization process is ended, if yes, network switching is executed, otherwise the next iteration process is continuously executed; In the execution of network switching, the network connection state is captured in the kernel network layer of the source host, the network connection state is synchronized to the target host, and the network traffic is redirected to the target host; The target container is activated on the target host, and the resource of the source container on the source host is released.

2. The method of claim 1, wherein, The judgment whether the incremental synchronization process is ended comprises the following steps: After each iteration process is ended, the number of dirty pages in the source host that have not been synchronized and the current transmission rate are obtained, it is judged whether the dirty page generation rate in the last N iteration processes is lower than the transmission rate and whether the data amount of the remaining dirty pages that have not been synchronized is lower than a preset threshold value, if both are yes, the incremental synchronization process is ended.

3. The method of claim 1, wherein, The copying of the memory data and file system data of the source container to the target host in the case that the source container in the source host keeps running comprises the following steps: In the case that the source container in the source host keeps running, an enhanced CRIU tool is called or a kernel interface is directly used to quickly scan and copy the current memory state of all memory pages of the source container, so as to obtain memory image data, and the obtained memory image data is transmitted to the target host through a network.

4. The method of claim 1, wherein, The tracking of the dirty pages in the source host in the process of pre-migration comprises the following steps: A kernel module is used to set write protection for the memory pages of the source container in the kernel of the source host; When any process in the source container attempts to write to any first memory page, a page fault interrupt is triggered; The interrupt is captured by the kernel, and the write protection is cancelled; The original data of the first memory page is copied to a new location for process writing, and the address of the first memory page is recorded in a pre-set dirty page log, so that the tracking of the dirty pages in the source host is realized.

5. The method of claim 1, wherein, The containerized application is a Linux kernel-based containerized application. The capturing of the network connection state in the kernel network layer of the source host, the synchronization of the network connection state to the target host, and the redirection of the network traffic to the target host comprise the following steps: A pre-compiled eBPF program is loaded to the traffic control entrance of the network interface used by the source container; The eBPF program parses each data packet flowing through the traffic control entrance, extracts the connection state information of the data packet, and synchronizes the extracted connection state information to the target host in real time; wherein the eBPF program does not discard or block the data packet; At the same time of synchronizing the connection state, the eBPF program temporarily puts the newly arrived inbound data packet into a buffer in the kernel space. When the target host confirms that it has received all the connection state information, and the target container is ready, the routing table of the upstream network device is updated so that all traffic originally directed to the IP address of the source host is directed to the IP address of the target host.

6. The method of claim 1, wherein, The containerized application is a Linux kernel-based containerized application. The activating the target container on the target host comprises: suspending the source container for a preset time; generating a final state packet by the source host, and sending the final state packet to the target host; wherein the final state packet comprises dirty page data generated in the last iteration process, CPU register state, and process tree information; after the target host receives the final state packet, performing a recovery operation on the target container, and injecting a corresponding eBPF program on the network interface of the target host, the eBPF program taking data packets from a buffer and injecting the taken data packets into the process of the recovered target container according to the synchronized connection state, so that the connection is not interrupted.

7. A system for live migration of containerized applications, characterized in that, The system comprises a migration controller, a source migration agent, a target migration agent, and a kernel layer enhancement module; wherein, the migration controller is configured to instruct the source migration agent to perform migration processing after detecting a migration trigger condition, and to determine whether the incremental synchronization process is complete, if yes, trigger the kernel layer enhancement module to perform network switching, otherwise trigger the source migration agent to continue to perform the next iteration process; and redirect network traffic to the target host during network switching; the source migration agent is configured to, after receiving the instruction to perform migration processing, copy memory data and file system data of the source container to the target host through the target migration agent while the source container in the source host continues to run, thereby realizing pre-migration, and synchronize dirty page data generated by the source container in the pre-migration process to the target host through at least one iteration process and in an incremental synchronization manner, thereby realizing incremental synchronization; and release the resources of the source container on the source host; the kernel layer enhancement module is configured to track dirty pages in the source host during the pre-migration process; wherein the dirty pages are memory pages that have changed; and capture network connection states at the kernel network layer of the source host during network switching, and synchronize the network connection states to the target host; the target migration agent is configured to activate the target container on the target host.

8. The system of claim 7, wherein the migration controller is configured to provide an API interface, receive a migration instruction, maintain a state machine of migration, and communicate with the source migration agent and the target migration agent; and / or each of the source migration agent and the target migration agent is configured to perform at least one of the following: invoke a CRIU tool for memory snapshot and recovery; interact with the kernel layer enhancement module to manage copy-on-write tracking of the dirty pages; perform file system synchronization; load and unload eBPF programs; establish a data transmission channel between the hosts.

9. The system according to claim 7 or 8, characterized in that, The containerized application is a Linux kernel-based containerized application.

10. A computing device comprising a memory having executable code stored therein and a processor that, when executing the executable code, implements the method of any one of claims 1-6.

Images