A method, system, device and storage medium for kubernets container migration

Abstract

The application provides a kind of kubernets container migration method, system, equipment and storage medium, method includes: the migration of container image and file system, and apply system resources on target node to complete the creation of Pod;Memory data of Pod is migrated;The identification of Pod is restored, and key-value pair is set according to namespace, Pod name and IP address of Pod, and virtual IP table is generated according to the key-value pair;And target Pod is determined according to the name of Pod and the namespace where it is based on the virtual IP table, and the source end Pod is cleared according to the target Pod.The application takes namespace+Pod name as Key value, and the IP address of Pod as Value value, maintains a virtual IP table, and solves the problem of renaming in Kubernetes container migration.

Description

Technical Field

[0001] This invention relates to the field of cluster management, and more specifically, to a method, system, device, and storage medium for migrating Kubernetes containers. Background Technology

[0002] As the most widely used cluster management tool, Kubernetes has increasingly created a strong demand for online Pod migration within Kubernetes environments. In Kubernetes, the smallest management element is not a container, but a Pod; containers are organized and managed by Kubernetes as Pods. Therefore, implementing online container migration in Kubernetes is essentially implementing online Pod migration. Pod online migration differs from simple container migration. Container migration only requires migrating one container at a time, but in Kubernetes, a Pod may contain multiple running containers, so migrating a Pod requires migrating multiple containers simultaneously. Furthermore, each Pod in Kubernetes has its own unique identifier, while the migrated Pod should be identical to the source Pod during the migration process. Therefore, there is a contradiction between Pod uniqueness and migration. Resolving these contradictions is a crucial problem that must be addressed when implementing container migration in Kubernetes. Summary of the Invention

[0003] In view of this, the purpose of this invention is to provide a method, system, computer device, and computer-readable storage medium for Kubernetes container migration. This invention maintains a virtual IP table using namespaces and Pod names as keys and Pod IP addresses as values. During the service recovery phase of the migration, the virtual IP table is used to switch the flow of Pod requests, thereby resolving the contradiction between Kubernetes and migration, as well as cleaning up the source Pods.

[0004] To achieve the above objectives, one aspect of this invention provides a method for migrating Kubernetes containers, comprising the following steps: migrating the container image and file system, and requesting system resources on the target node to complete the creation of the Pod; migrating the memory data of the Pod; restoring the Pod's identifier, setting key-value pairs based on the namespace, Pod name, and Pod IP address, and generating a virtual IP table based on the key-value pairs; and determining the target Pod based on the virtual IP table according to the Pod name and the namespace it belongs to, and clearing the source Pod based on the target Pod.

[0005] In some implementations, setting key-value pairs based on namespace, Pod name, and Pod IP address includes: using the namespace and Pod name of the target node's Pod as the key value, using the IP address of the target node's Pod as the value value, and forming key-value pairs based on the key value and value value.

[0006] In some implementations, the identification of the restored Pod includes: downloading the last backup file from the OSS, synchronizing the memory state of the containers in the Pod, restoring the memory state of the corresponding container in the Pod according to the container's memory image file, and synchronizing the file content of the container's read / write layer.

[0007] In some implementations, determining the target Pod based on the virtual IP table according to the Pod's name and namespace, and clearing the source Pod based on the target Pod includes: finding all corresponding Pod entities stored in Etcd according to the Pod's name and namespace, and checking whether the IP addresses are consistent; in response to the IP addresses being consistent, deleting the corresponding Pod entity and clearing the virtual IP table; in response to deleting the corresponding Pod entity, deleting the source Pod during source Kubelet synchronization.

[0008] In another aspect of this invention, a system for migrating Kubernetes containers is provided, comprising: a creation module configured to migrate container images and file systems, and to request system resources on a target node to complete the creation of a Pod; a migration module configured to migrate the memory data of the Pod; an identification module configured to restore the Pod's identification, set key-value pairs based on a namespace, Pod name, and Pod IP address, and generate a virtual IP table based on the key-value pairs; and a recovery module configured to determine the target Pod based on the virtual IP table according to the Pod's name and namespace, and to clear the source Pod based on the target Pod.

[0009] In some implementations, the identification module is configured to: use the namespace and Pod name of the target node's Pod as the key value, use the IP address of the target node's Pod as the value value, and form a key-value pair based on the key value and the value value.

[0010] In some implementations, the identification module is configured to: download the last backup file from the OSS, synchronize the memory state of the container in the Pod, restore the memory state of the corresponding container in the Pod according to the container's memory image file, and synchronize the file content of the container's read / write layer.

[0011] In some implementations, the recovery module is configured to: locate all corresponding Pod entities stored in Etcd based on the Pod's name and namespace, and sequentially check whether the IP addresses are consistent; in response to the consistent IP addresses, delete the corresponding Pod entity and clean up the virtual IP table; in response to the deletion of the corresponding Pod entity, delete the source Pod during source-side Kubelet synchronization.

[0012] In another aspect of the present invention, a computer device is provided, comprising: at least one processor; and a memory storing computer instructions executable on the processor, the instructions, when executed by the processor, implementing the steps of the method described above.

[0013] In another aspect, the present invention provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method steps.

[0014] The present invention has the following beneficial technical effects: a virtual IP table is maintained using namespace and Pod name as key values ​​and Pod IP address as value value. During the service recovery phase of migration, the virtual IP table is used to switch the flow of Pod requests, thereby resolving the contradiction between Kubernetes and migration, as well as the cleanup of source Pods. Attached Figure Description

[0015] 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 only some embodiments of the present invention. For those skilled in the art, other embodiments can be obtained based on these drawings without creative effort.

[0016] Figure 1 A schematic diagram illustrating an embodiment of the Kubernetes container migration method provided by the present invention;

[0017] Figure 2 A schematic diagram illustrating conflict resolution using the virtual IP table provided by this invention;

[0018] Figure 3 A schematic diagram of an embodiment of the Kubernetes container migration system provided by the present invention;

[0019] Figure 4 A schematic diagram of the hardware structure of a computer device for migrating Kubernetes containers provided by the present invention;

[0020] Figure 5This is a schematic diagram of an embodiment of a computer storage medium for Kubernetes container migration provided by the present invention. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of the present invention clearer, the embodiments of the present invention will be further described in detail below with reference to specific examples and accompanying drawings.

[0022] It should be noted that all uses of "first" and "second" in the embodiments of the present invention are for the purpose of distinguishing two entities or parameters with the same name but different names. It is clear that "first" and "second" are only for the convenience of expression and should not be construed as limiting the embodiments of the present invention. Subsequent embodiments will not explain this in detail.

[0023] In a first aspect, an embodiment of a method for migrating Kubernetes containers is proposed. Figure 1 This diagram illustrates an embodiment of the Kubernetes container migration method provided by the present invention. Figure 1 As shown, the embodiments of the present invention include the following steps:

[0024] S1. Migrate the container image and file system, and request system resources on the target node to complete the creation of the Pod;

[0025] S2. Migrate the Pod's memory data;

[0026] S3. Restore the Pod's identifier, set key-value pairs based on the namespace, Pod name, and Pod IP address, and generate a virtual IP table based on the key-value pairs; and

[0027] S4. Based on the virtual IP table, determine the target Pod according to the Pod's name and namespace, and clear the source Pod according to the target Pod.

[0028] The Kubernetes system architecture mainly includes the following key components:

[0029] (1) Etcd: Stores the state of all resources in the entire cluster, such as Pods, PVs / PVCs, etc.

[0030] (2) Apiserver: Apiserver is the entry point for operating cluster resources. Accessing, modifying, and deleting cluster resources all require going through Apiserver.

[0031] (3) Controller manager: It is the control and management center of the entire cluster and is responsible for maintaining the status of the entire cluster;

[0032] (4) Scheduler: Implements the scheduling of cluster resources and schedules Pods in the cluster to different nodes according to different scheduling strategies;

[0033] (5) Kubelet: Kubelet runs on each node and is responsible for managing the lifecycle of Pods on the node as well as managing Volume and network;

[0034] (6) kube-proxy is responsible for providing service discovery and load balancing within the cluster for Services.

[0035] In a Kubernetes environment, container migration typically involves three phases: pre-migration, memory migration, and service recovery. The pre-migration phase involves migrating the container image and file system, requesting system resources on the target node, and creating the Pod. The memory migration phase involves migrating the Pod's memory data. The service recovery phase involves switching the Pod's service traffic, modifying the Pod, and cleaning up the migrated Pod. This invention primarily focuses on using a virtual IP table to switch Pod requests during the service recovery phase of the migration, resolving the conflict between Kubernetes and migration, and cleaning up the source Pod.

[0036] During the service recovery phase, Pods are pre-created based on their static configurations. However, many of these configurations are temporary, such as the Pod's UUID and IP address. This is because Kubernetes' uniqueness requirement for Pods prevents different Pods in the same namespace from having the same name, IP address, etc., as this would cause conflicts in system management. During recovery, the Pod's identifier needs to be restored. One direct method is to delete the Pod on the source node and then reset the new Pod identifier. This approach is simple and intuitive. However, it has several drawbacks. First, the destination Pod must wait for the source Pod to be deleted before it can reconnect to the service. If an error occurs during the deletion of the source Pod, and it cannot be deleted correctly, the destination Pod will remain suspended, and the service will be unavailable during this time, indirectly increasing service downtime. Second, if an error occurs while modifying the Pod identifier, meaning the recovery process fails, the Pod needs to be restored on the source node. However, since the source Pod has already been deleted, it needs to be recreated, increasing recovery costs. Therefore, deleting the Pod first and then modifying the Pod identifier is not a good choice.

[0037] Therefore, modifying the Pod identifier first and then performing source cleanup is a reasonable choice. Thus, Kubernetes must allow conflicts to exist before performing source cleanup. The reason Pod name conflicts are not allowed is that when Pods with the same name exist, the target Pod cannot be determined. Therefore, it's sufficient to explicitly tell the system the target Pod when a conflict occurs. Since Pod names and IP addresses are unique within a namespace, a virtual IP table is maintained using the namespace + Pod name as the key and the Pod's IP address as the value. When a conflict exists, the target Pod's IP address can be obtained based on the specified Pod name, thus locating the target Pod.

[0038] Figure 2 This is a schematic diagram illustrating the conflict resolution mechanism of the virtual IP table provided by the present invention, as shown below. Figure 2 As shown, during service recovery, a new record is inserted into the Virtual IP Table, using the target node's Pod namespace and Pod name as the key, and its IP address as the value. The Virtual IP Table identifies conflicting Pod requests, directing requests to the counter in the `default` namespace to the Pod with IP address 10.0.0.2 for processing. Ultimately, conflicting Pod requests are handled by the counter on the NodeB based on their IP addresses. The data in the Virtual IP Table is time-sensitive and does not need to be permanently stored. Once the Pod's identifier on the destination server is modified, the Pod's service is restored. At this point, a request to clean up the source Pod can be submitted to the kube-apiserver. After the kube-apiserver cleans up the source Pod's objects in Etcd, it can delete the corresponding data in the Virtual IP Table. The Pod deletion operation is then handled by subsequent Kubelets on the source node.

[0039] Restoring Pod services on the target node mainly involves restoring the Pod's identifier and cleaning up the source Pod. Restoring the Pod's identifier mainly includes the Pod's name and tag data, and setting up the Virtual IP Table. Cleaning up the source Pod involves initiating a request to clean up the source Pod, and the actual cleanup process is then handled by kube-apiserver. After cleanup is complete, the corresponding record in the Virtual IP Table is also deleted.

[0040] In some implementations, the identification of the restored Pod includes: downloading the last backup file from the OSS, synchronizing the memory state of the containers in the Pod, restoring the memory state of the corresponding container in the Pod according to the container's memory image file, and synchronizing the file content of the container's read / write layer.

[0041] Download the last backup file from OSS (Object Storage Service), synchronize the memory state of containers in the Pod, restore the memory state of the corresponding containers within the Pod based on the container's memory image file, and synchronize the file content of the container's read / write layer. If memory restoration fails in this step, the source Pod is restored, and the entire migration process fails. If memory state restoration is successful, the Pod's identifier needs to be modified. Kubernetes does not allow modification of Pod names, IPs, etc., but this is only a code-level issue; only minor modifications to the Kubelet are needed to connect the management layer, making it possible for Pods with the same name to exist. If the Pod's identifier is successfully modified, then the Virtual IP Table can be set up.

[0042] In some implementations, determining the target Pod based on the virtual IP table according to the Pod's name and namespace, and clearing the source Pod based on the target Pod includes: finding all corresponding Pod entities stored in Etcd according to the Pod's name and namespace, and checking whether the IP addresses are consistent; in response to the IP addresses being consistent, deleting the corresponding Pod entity and clearing the virtual IP table; in response to deleting the corresponding Pod entity, deleting the source Pod during source Kubelet synchronization.

[0043] Handling Pod name conflicts is implemented by the Kubelet running on the node initiating the request, which is then processed by the kube-apiserver. When processing a Pod request, the kube-apiserver also needs to check the Virtual IP Table to see if the specified Pod exists before accessing the Etcd to find the corresponding Pod object. If the Virtual IP Table is successfully set, the entire Pod service has restarted, and the service recovery phase is complete. At this point, a request can be sent to the kube-apiserver to remove the source Pod. Conversely, if any step in this process fails, it is considered a failure of the recovery process, requiring the source Pod to be restored, and the entire migration process fails.

[0044] After restoring the Pod service, the migration process can be considered complete. However, some cleanup work still needs to be performed. After the migration is complete, the Pods on the source node are no longer providing services and can be deleted. This cleanup is initiated by the kubelet on the target node and handled by the kube-apiserver. Cleaning up the source Pods mainly involves finding all corresponding Pod entities stored in Etcd based on the Pod's name and namespace, then checking if the IP addresses match. If they match, the corresponding entity is deleted and the Virtual IP Table is cleaned up. When the corresponding entity is deleted, the source kubelet will delete the source Pod during synchronization.

[0045] It should be noted that the steps in the various embodiments of the Kubernetes container migration method described above can be interchanged, substituted, added, or deleted. Therefore, these reasonable permutations and combinations of the Kubernetes container migration method should also fall within the protection scope of this invention, and the protection scope of this invention should not be limited to the embodiments.

[0046] Based on the above objectives, a second aspect of this invention provides a system for migrating Kubernetes containers. For example... Figure 3 As shown, system 200 includes the following modules: a creation module, configured to migrate container images and file systems, and request system resources on the target node to complete the creation of Pods; a migration module, configured to migrate the memory data of Pods; an identification module, configured to restore the identification of Pods, set key-value pairs according to namespace, Pod name and Pod IP address, and generate a virtual IP table according to the key-value pairs; and a recovery module, configured to determine the target Pod based on the virtual IP table according to the Pod name and the namespace it belongs to, and clear the source Pod according to the target Pod.

[0047] In some implementations, the identification module is configured to: use the namespace and Pod name of the target node's Pod as the key value, use the IP address of the target node's Pod as the value value, and form a key-value pair based on the key value and the value value.

[0048] In some implementations, the identification module is configured to: download the last backup file from the OSS, synchronize the memory state of the container in the Pod, restore the memory state of the corresponding container in the Pod according to the container's memory image file, and synchronize the file content of the container's read / write layer.

[0049] In some implementations, the recovery module is configured to: locate all corresponding Pod entities stored in Etcd based on the Pod's name and namespace, and sequentially check whether the IP addresses are consistent; in response to the consistent IP addresses, delete the corresponding Pod entity and clean up the virtual IP table; in response to the deletion of the corresponding Pod entity, delete the source Pod during source-side Kubelet synchronization.

[0050] Based on the above objectives, a third aspect of the present invention provides a computer device, comprising: at least one processor; and a memory storing computer instructions executable on the processor, the instructions being executed by the processor to perform the following steps: S1, migrating a container image and file system, and requesting system resources on a target node to complete the creation of a Pod; S2, migrating the memory data of the Pod; S3, restoring the Pod's identifier, setting key-value pairs based on the namespace, Pod name, and Pod IP address, and generating a virtual IP table based on the key-value pairs; and S4, determining a target Pod based on the virtual IP table according to the Pod's name and namespace, and clearing the source Pod based on the target Pod.

[0051] In some implementations, setting key-value pairs based on namespace, Pod name, and Pod IP address includes: using the namespace and Pod name of the target node's Pod as the key value, using the IP address of the target node's Pod as the value value, and forming key-value pairs based on the key value and value value.

[0052] In some implementations, the identification of the restored Pod includes: downloading the last backup file from the OSS, synchronizing the memory state of the containers in the Pod, restoring the memory state of the corresponding container in the Pod according to the container's memory image file, and synchronizing the file content of the container's read / write layer.

[0053] In some implementations, determining the target Pod based on the virtual IP table according to the Pod's name and namespace, and clearing the source Pod based on the target Pod includes: finding all corresponding Pod entities stored in Etcd according to the Pod's name and namespace, and checking whether the IP addresses are consistent; in response to the IP addresses being consistent, deleting the corresponding Pod entity and clearing the virtual IP table; in response to deleting the corresponding Pod entity, deleting the source Pod during source Kubelet synchronization.

[0054] like Figure 4 The diagram shown is a hardware structure schematic of an embodiment of the computer device for migrating Kubernetes containers provided by the present invention.

[0055] For example Figure 4 Taking the device shown as an example, the device includes a processor 301 and a memory 302.

[0056] Processor 301 and memory 302 can be connected via a bus or other means. Figure 4 Taking the example of a connection between China and Israel via a bus.

[0057] The memory 302, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules, such as the program instructions / modules corresponding to the Kubernetes container migration method in this embodiment. The processor 301 executes various server functions and data processing by running the non-volatile software programs, instructions, and modules stored in the memory 302, thereby implementing the Kubernetes container migration method.

[0058] Memory 302 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created using methods such as Kubernetes container migration. Furthermore, memory 302 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, memory 302 may optionally include memory remotely located relative to processor 301, and these remote memories may be connected to the local module via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0059] The computer instructions 303 corresponding to one or more Kubernetes container migration methods are stored in memory 302. When executed by processor 301, the Kubernetes container migration method in any of the above method embodiments is executed.

[0060] Any embodiment of the computer device that performs the above-described method for migrating Kubernetes containers can achieve the same or similar effects as any of the aforementioned method embodiments.

[0061] The present invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, performs a method for migrating Kubernetes containers.

[0062] like Figure 5 The diagram shown is a schematic representation of an embodiment of the computer storage medium for Kubernetes container migration provided by the present invention. Figure 5Taking the computer storage medium shown as an example, the computer-readable storage medium 401 stores a computer program 402 that, when executed by a processor, performs the above method.

[0063] Finally, it should be noted that those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program for the Kubernetes container migration method can be stored in a computer-readable storage medium. When executed, the program can include the processes of the embodiments of the above methods. The storage medium for the program can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc. The above computer program embodiments can achieve the same or similar effects as any of the corresponding foregoing method embodiments.

[0064] The above are exemplary embodiments disclosed in this invention. However, it should be noted that various changes and modifications can be made without departing from the scope of the embodiments of this invention as defined by the claims. The functions, steps, and / or actions of the methods according to the disclosed embodiments described herein do not need to be performed in any particular order. Furthermore, although the elements disclosed in the embodiments of this invention may be described or claimed individually, they may be understood as multiple unless explicitly limited to a singular number.

[0065] It should be understood that, as used herein, the singular form “a” is intended to include the plural form as well, unless the context clearly supports an exception. It should also be understood that, as used herein, “and / or” refers to any and all possible combinations of one or more of the associated listed items.

[0066] The embodiment numbers disclosed in the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0067] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0068] Those skilled in the art should understand that the discussion of any of the above embodiments is merely exemplary and is not intended to imply that the scope of the invention (including the claims) is limited to these examples. Within the framework of the invention, technical features of the above embodiments or different embodiments can be combined, and many other variations of different aspects of the invention exist, which are not provided in the details for the sake of brevity. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the invention should be included within the protection scope of the invention.

Claims

1. A method for migrating Kubernetes containers, characterized in that, Includes the following steps: Migrate the container image and file system, and request system resources on the target node to complete the creation of the Pod; Migrate the in-memory data of the Pod; Restore the Pod's identifier by setting key-value pairs based on the namespace, Pod name, and Pod IP address, and generating a virtual IP table based on these key-value pairs. This includes using the target node's Pod namespace and Pod name as the key, and the target node's Pod IP address as the value, forming key-value pairs based on the key and value. Based on the virtual IP table, the target Pod is determined according to the Pod's name and namespace, and the source Pod is cleared according to the target Pod. This includes finding all corresponding Pod entities stored in Etcd based on the Pod's name and namespace, and checking whether the IP addresses are consistent. In response to the IP addresses being consistent, the corresponding Pod entity is deleted and the virtual IP table is cleared. In response to the deletion of the corresponding Pod entity, the source Pod is deleted during source Kubelet synchronization.

2. The method according to claim 1, characterized in that, The identifier of the recovery Pod includes: Download the last backup file from OSS, synchronize the memory state of the containers in the Pod, restore the memory state of the corresponding containers in the Pod based on the container's memory image file, and synchronize the file content of the container's read / write layer.

3. A system for migrating Kubernetes containers, characterized in that, include: Create a module, configure it to migrate container images and file systems, and request system resources on the target node to complete the creation of the Pod; The migration module is configured to migrate the memory data of a Pod. The identification module configures the identifier for Pod recovery, sets key-value pairs based on the namespace, Pod name, and Pod IP address, and generates a virtual IP table based on the key-value pairs. This includes using the namespace and Pod name of the target node's Pod as the key value, the IP address of the target node's Pod as the value value, and forming key-value pairs based on the key value and value value. as well as The recovery module is configured to determine the target Pod based on the virtual IP table according to the Pod's name and namespace, and to clear the source Pod based on the target Pod. This includes finding all entities of the corresponding Pod stored in Etcd according to the Pod's name and namespace, and checking whether the IP addresses are consistent. In response to the IP addresses being consistent, the corresponding Pod entity is deleted and the virtual IP table is cleared. In response to the deletion of the corresponding Pod entity, the source Pod is deleted during source Kubelet synchronization.

4. The system according to claim 3, characterized in that, The identification module is configured to: Download the last backup file from OSS, synchronize the memory state of the containers in the Pod, restore the memory state of the corresponding containers in the Pod based on the container's memory image file, and synchronize the file content of the container's read / write layer.

5. A computer device, characterized in that, include: At least one processor; as well as A memory storing computer instructions executable on the processor, which, when executed by the processor, implement the steps of the method according to any one of claims 1-2.

6. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1-2.

Images