IP consistency method for K3s service migration

Abstract

The invention discloses an IP consistency method for K3s service migration, and belongs to the technical field of K3s-based edge computing. In order to solve the problem of performance and fault tolerance of the transparency technology of a client caused by the existing realization of service migration, when service state migration is carried out, a source node service state migration module synchronizes request information to a target node service state migration module, and network configuration is modified; the source node IP migration module obtains IP information of a source service Pod and writes the IP information into an IP cache file, and the NFS synchronizes the IP cache file to the target node IP migration module; the target node network plug-in calls a target node IP migration module to read the IP cache file, and the target node network plug-in allocates the read IP to a target service Pod; and the target node service state transition module performs state recovery on the target service Pod by using the check point file, and the target node network state transition module modifies the network configuration of the target node.

Description

Technical Field

[0001] The present invention belongs to the field of edge computing technology based on K3s, and specifically relates to an IP consistency method for K3s service migration. Background Art

[0002] Edge computing, as an emerging computing model, deploys computing resources and services to edge locations close to data sources to reduce data transmission latency and network bandwidth pressure, and improve system response speed and user experience. In edge computing, K3s, as a lightweight Kubernetes distribution, is popular for its easy deployment and low resource usage, enabling edge devices to efficiently manage containerized applications. However, due to the instability and resource constraints of the edge environment, fault tolerance has become an important challenge in edge computing. In this context, service migration technology becomes crucial because it can achieve seamless migration of services in the face of node failures or insufficient resources, ensuring the continuous availability and stability of the system, thereby guaranteeing the quality of service for users.

[0003] Currently, there are studies on the migration of containerized services, such as using Docker and CRIU technology to generate checkpoints for containers and then use them to restore the state. These methods can save the running state of the container during the migration process, but cannot ensure that the service IP address remains unchanged before and after the migration, which will cause the client connection to be interrupted or need to reconnect, and cannot achieve a transparent and seamless migration for users.

[0004] In existing K3s-based edge computing environments, the following measures are usually taken to ensure that service migration is transparent to clients:

[0005] 1. Service proxy: Place an intermediate layer between the client and the service, responsible for receiving requests and forwarding them to the appropriate service instance. The service proxy can handle load balancing and failover of traffic. The client always accesses the proxy intermediate layer to request services, ensuring that service migration is not noticeable to users.

[0006] 2. K3s built-in resources - services: In K3s, a service is an abstract resource that defines the access policy for a set of Pods. It provides a stable way to access application instances running in Pods, solving the problem that the IP address of a Pod may change due to migration or scheduling to different nodes.

[0007] 3. DNS update: By dynamically updating DNS records, ensure that after the service migration, the client can access the service through a unified service name. This method allows the actual address of the service to change without modifying the client code, just ensure that the DNS resolution correctly points to the new service address.

[0008] Although existing technologies provide certain solutions for achieving transparency of service migration to clients, their main focus is on achieving service discovery by introducing intermediate layers such as service proxies, service resources, or DNS resolution, rather than ensuring that the actual IP address of the Pod remains unchanged before and after service migration. Such technologies have significant disadvantages: First, because requests need to go through additional forwarding and resolution steps, the latency of service responses will increase, affecting the user experience. Second, the introduction of intermediate layers increases the complexity of the system and may lead to more single points of failure. For example, if the service proxy or DNS service fails, it will directly affect the client's access to the service and increase the vulnerability of the system. Finally, the intermediate layer usually takes up additional computing and network resources, which may cause performance bottlenecks and affect system efficiency in resource-constrained edge computing environments. Therefore, although the existing technologies have solved the transparency problem of service migration to a certain extent, there is still room for improvement in terms of performance and fault tolerance. Summary of the invention

[0009] In order to solve the performance and fault tolerance problems brought about by the existing technology for realizing transparency of service migration to the client, the present invention proposes an IP consistency method for K3s service migration.

[0010] To achieve the above object, the present invention is implemented through the following technical solutions:

[0011] An IP consistency method for K3s service migration includes the following steps:

[0012] S1. Set the source node service state migration module, the source node IP migration module and the source node network state migration module at the source node, and set the target node service state migration module, the target node IP migration module and the target node network state migration module at the target node;

[0013] S2. When the client requests the source node service state migration module to migrate the service state, the source node service state migration module synchronizes the request information to the target node service state migration module, and the source node network state migration module modifies the network configuration;

[0014] S3. The source node IP migration module obtains the IP information of the source service Pod and writes it into the IP cache file. NFS synchronizes the IP cache file to the target node IP migration module.

[0015] S4. The target node network plug-in Flannel calls the target node IP migration module to read the IP cache file, and then the target node network plug-in Flannel assigns the read IP to the target service Pod;

[0016] S5. The target node service state migration module uses the checkpoint file to restore the state of the target service Pod. At the same time, the target node network state migration module modifies the network configuration of the target node to ensure that the migrated target service Pod communicates normally with the resources.

[0017] Furthermore, the specific implementation method of the service state migration module in step S2 is as follows:

[0018] S2.1. Generate a state checkpoint at the source node:

[0019] On the source node, the container status is represented as:

[0020] S src ={M,P,FD,NC}

[0021] Among them, M represents memory status, P represents process information, FD represents file descriptor, and NC represents network connection;

[0022] The process checkpoint and recovery tool CRIU is called to generate a state checkpoint. The expression is:

[0023] C checkpoint =CRIU(S src )→Save as a checkpoint file;

[0024] Among them, C checkpoint Checkpoint file for the container;

[0025] The checkpoint file includes the memory status, process information, file descriptors and network connection data of the container;

[0026] S2.2. Transfer the checkpoint file. Transfer the checkpoint file to the specified path of the target node through the NFS network. The expression is:

[0027] C checkpoint →C checkpoint_target

[0028] Among them, C checkpoint_target Checkpoint file for the target node;

[0029] S2.3. Container state recovery: On the target node, Docker starts the container instance and rebuilds the state as follows;

[0030] Initialize the target state S target :

[0031] S target =Docker_start(C checkpoint_target )

[0032] Use CRIU to read the checkpoint file:

[0033] S target =CRIU_restore(C checkpoint_target ) → S target ={M,P,FD,NC}

[0034] On the target node, Docker starts the corresponding container instance and uses CRIU to read the checkpoint file to rebuild the state of the container and restore it to the running state before the migration;

[0035] S2.4. Complete service status migration: The service status is migrated from the source node to the target node, and the migrated container service status S is obtained. migrated , the expression is:

[0036] S migrated =S target →S src

[0037] Eventually, the service status of the target node is consistent with the service status of the source node.

[0038] Furthermore, in step S3, the IP migration module modifies the IP allocation mechanism of the host-local plug-in, and sets the function called by host-local for IP allocation to the GetIter() function. The specific IP allocation process is as follows:

[0039] S3.1. Get iterator: First, call the GetIter() method to get an iterator pointing to the IP address range. The iterator will locate the last allocated IP address as the starting point for the next allocation.

[0040] S3.2. Check the last allocated IP address: In GetIter(), the last allocated IP address is checked first. If it exists, the iterator will point to it and prepare to allocate the next IP address.

[0041] S3.3. Allocate IP addresses: When a new IP address is requested, the Next() method is called to obtain the next available IP address; if the currently pointed IP address is empty, the starting IP address of the range is allocated; if the end of the range has been reached, the iterator is reset and loops back to the beginning of the address pool, implementing a round-robin strategy;

[0042] During the allocation process, if the current IP address is a subnet gateway or an occupied IP address, the iterator will call its own Next() method to skip the subnet gateway or the occupied IP address until an available IP address is found;

[0043] S3.4. Return result: When an available IP address is found, a structure containing the available IP address and its corresponding gateway is returned. If no available IP address is found in the entire range, an error message is returned indicating that there is no available address.

[0044] Furthermore, the last allocated IP address in step S3.2 is stored in / var / lib / cni / networks / last_reserved_ip.0 by default.

[0045] Furthermore, the specific implementation method of step S4 is implemented by the host-local plug-in of Flannel, including the following steps:

[0046] S4.1.IP pool management: Flannel allocates an IP address pool to each node. The IP address pool is dynamically generated by Flannel based on the CIDR range of the cluster. Each node maintains a local IP address manager.

[0047] S4.2. Allocate IP address when Pod starts: When a Pod starts, Flannel calls the host-local plugin to allocate an available IP address from the node's IP address pool. This address is assigned to the Pod and configured through Flannel's network interface. The process of calculating the IP address for the i-th Pod within the node's CIDR range is as follows:

[0048] IP Pod =CIDR Node +i,i∈{1,2,...,n}

[0049] Among them, IP Pod The specific IP address assigned to the Pod, CIDR Node is the CIDR range of the current node, and i is the offset assigned to the i-th Pod;

[0050] S4.3. Set the IP address assigned to the Pod to remain unchanged during the life cycle of the Pod until the Pod is deleted or restarted; when the Pod is restarted, Flannel reuses the previously assigned IP address to ensure the continuity of the IP address;

[0051] S4.4. Network configuration: Flannel is responsible for setting routing rules so that traffic can be correctly routed within and outside the cluster, ensuring communication between Pods and the ability to access external networks.

[0052] Further, in step S5, the target node network state migration module modifies the network configuration of the target node, including IP allocation and modification of the routing table;

[0053] S5.1.IP allocation: Modify the host-local network plug-in and use the IP of the source service Pod to modify the IP of the target service Pod to ensure that the actual IP address of the service Pod remains unchanged before and after the migration;

[0054] S5.2. Modify the routing table: Mark the route of the target Pod in the routing table of the target node to ensure that the traffic can correctly and directly reach the new Pod location. The process is described as follows:

[0055] Assume R dest The routing table of the target node, IP migrated is the IP address of the Pod after migration, local is the local address, and the modified routing table rules are:

[0056] R dest (IP migrated )=local

[0057] Indicates access to the IP on the target node migrated Directly access locally without going through a gateway.

[0058] Furthermore, the source node network configuration of the source node network state migration module includes IP blocking, modifying the routing table, and modifying Iptables.

[0059] Furthermore, the IP blocking is to lock the IP of the source Pod at the beginning of the service migration to prevent other new Pods from requesting to use the IP. The process is described as follows:

[0060] Set IP src is the IP address of the source node Pod, t0 is the time when the migration starts, and t end is the end time of migration, then in the time interval [t0,t end ], use the following conditions to lock the IP:

[0061] Lock(IP src )=(t0≤t&&t≤t end )? 1:0

[0062] Among them, Lock(IP src ) = 1, it means that the IP is locked and cannot be used by other Pods.

[0063] Furthermore, the process of modifying the route is as follows:

[0064] Assume R src is the routing table of the source node, IP migrated is the IP address of the Pod after migration, Node dest If it is the target node, the rules for route modification are as follows:

[0065] R src (IP migrated )=Node dest

[0066] Indicates access to the IP address on the source node migrated When the data packet is routed to the target node Node dest .

[0067] Further, the process of Iptables modification is described as follows:

[0068] Set IP src is the IP address of the source node, IP migrated is the IP address of the Pod after migration, IP nat is the disguised IP, then when the data packet is sent from the source node to the target Pod, the disguise rule is:

[0069] SNAT(IP src )→IP nat →IP migrated

[0070] Indicates that the source address IP src Change to the disguised IP address nat , to ensure that traffic can be correctly routed to the IP address of the migrated Pod migrated .

[0071] Beneficial effects of the present invention:

[0072] The IP consistency method for K3s service migration described in the present invention combines CRIU technology to realize checkpoint generation and recovery of service status, ensure the consistency of service status during the migration process, and further improve user experience. The present invention modifies the Flannel and host-local network plug-ins to ensure that the actual IP address of the Pod remains unchanged during the service migration process, avoids the impact of the introduction of the middle layer in the prior art, and ensures the transparency of the service address of the service migration process to the user. During the implementation process, the IP locking mechanism of the source node effectively prevents the new Pod from occupying the IP of the source Pod during the migration period, avoiding IP address conflicts. By dynamically adjusting the network status, it can be ensured that the migrated Pod can communicate normally with other resources and continue to provide services to users. BRIEF DESCRIPTION OF THE DRAWINGS

[0073] Figure 1 A flowchart of an IP consistency method for K3s service migration according to the present invention;

[0074] Figure 2 This is a basic flow chart of IP migration;

[0075] Figure 3 The overall architecture diagram for service IP migration;

[0076] Figure 4 Assign process diagram for Get() function IP;

[0077] Figure 5 This is the modified Get() function process diagram;

[0078] Figure 6 This is a test result diagram of the service address of the present invention;

[0079] Figure 7 This is a diagram of the communication test results of the present invention. DETAILED DESCRIPTION

[0080] In order to make the purpose, technical solution and advantages of the present invention more clear, the present invention is further described in detail below in conjunction with the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention, that is, the specific embodiments described are only part of the embodiments of the present invention, rather than all of the specific embodiments. The components of the specific embodiments of the present invention described and shown in the drawings herein can be arranged and designed in various different configurations, and the present invention can also have other embodiments.

[0081] Therefore, the following detailed description of the specific embodiments of the present invention provided in the accompanying drawings is not intended to limit the scope of the invention claimed for protection, but merely represents the selected specific embodiments of the present invention. Based on the specific embodiments of the present invention, all other specific embodiments obtained by those skilled in the art without making creative work are within the scope of protection of the present invention.

[0082] In order to further understand the content, features and effects of the present invention, the following specific implementation methods are given as examples, and the attached Figure 1 -Attached Figure 7 The detailed instructions are as follows: Specific implementation method one:

[0084] An IP consistency method for K3s service migration includes the following steps:

[0085] S1. Set the source node service state migration module, the source node IP migration module and the source node network state migration module at the source node, and set the target node service state migration module, the target node IP migration module and the target node network state migration module at the target node;

[0086] S2. When the client requests the source node service state migration module to migrate the service state, the source node service state migration module synchronizes the request information to the target node service state migration module, and the source node network state migration module modifies the network configuration;

[0087] Furthermore, the specific implementation method of the service state migration module in step S2 is as follows:

[0088] S2.1. Generate a state checkpoint at the source node:

[0089] On the source node, the container status is represented as:

[0090] S src ={M,P,FD,NC}

[0091] Among them, M represents memory status, P represents process information, FD represents file descriptor, and NC represents network connection;

[0092] The process checkpoint and recovery tool CRIU is called to generate a state checkpoint. The expression is:

[0093] C checkpoint =CRIU(S src )→Save as a checkpoint file;

[0094] Among them, C checkpoint It is the checkpoint file of the container, which contains the complete status of the container on the source node, including memory, processes, file descriptors, and network connections;

[0095] The checkpoint file includes the memory status, process information, file descriptors and network connection data of the container;

[0096] First, on the source node, the Docker controller stops the running container and calls CRIU to generate a checkpoint for the container. CRIU saves the container's memory status, process information, file descriptors, and network connections as a set of image files to ensure that the complete state of the container is recorded.

[0097] S2.2. Transfer the checkpoint file. Transfer the checkpoint file to the specified path of the target node through the NFS network. The expression is:

[0098] C checkpoint →C checkpoint_target

[0099] Among them, C checkpoint_target The checkpoint file of the target node, that is, the checkpoint file transmitted to the target node through the network, contains all the status information required for container recovery during the migration process;

[0100] S2.3. Container state recovery: On the target node, Docker starts the container instance and rebuilds the state as follows;

[0101] Initialize the target state S target :

[0102] S target =Docker_start(C checkpoint_target )

[0103] Use CRIU to read the checkpoint file:

[0104] S target =CRIU_restore(C checkpoint_target ) → S target ={M,P,FD,NC}

[0105] On the target node, Docker starts the corresponding container instance and uses CRIU to read the checkpoint file to rebuild the state of the container and restore it to the running state before the migration;

[0106] S2.4. Complete service status migration: The service status is migrated from the source node to the target node, and the migrated container service status S is obtained. migrated , that is, after the migration is completed, the container status on the target node has been restored to the original status of the source node, and the expression is:

[0107] S migrated =S target →S src

[0108] Eventually, the service status of the target node is consistent with the service status of the source node.

[0109] S3. The source node IP migration module obtains the IP information of the source service Pod and writes it into the IP cache file. NFS synchronizes the IP cache file to the target node IP migration module.

[0110] In the K3s network architecture, Flannel, as a container network interface (CNI) plug-in, is responsible for providing network connectivity and IP allocation for Pods. Flannel works by setting up a virtual network in the cluster so that each Pod can communicate in a flat network space.

[0111] Furthermore, in step S3, the IP migration module modifies the IP allocation mechanism of the host-local plug-in, and sets the function called by host-local for IP allocation to the GetIter() function, that is, the available IP address iteration function. The specific IP allocation process is as follows:

[0112] S3.1. Get iterator: First, call the GetIter() method to get an iterator pointing to the IP address range. The iterator will locate the last allocated IP address as the starting point for the next allocation.

[0113] S3.2. Check the last allocated IP address: In GetIter(), the last allocated IP address is checked first. If it exists, the iterator will point to it and prepare to allocate the next IP address.

[0114] S3.3. Allocate IP addresses: When a new IP address is requested, the Next() method is called to obtain the next available IP address; if the currently pointed IP address is empty, the starting IP address of the range is allocated; if the end of the range has been reached, the iterator is reset and loops back to the beginning of the address pool, implementing a round-robin strategy;

[0115] During the allocation process, if the current IP address is a subnet gateway or an occupied IP address, the iterator will call its own Next() method to skip the subnet gateway or the occupied IP address until an available IP address is found;

[0116] S3.4. Return result: When an available IP address is found, a structure containing the available IP address and its corresponding gateway is returned. If no available IP address is found in the entire range, an error message is returned indicating that there is no available address.

[0117] In this way, the polling algorithm can effectively allocate IPs in the IP address pool, ensuring fair use of resources while reducing the possibility of conflicts and duplicate allocations.

[0118] The modification process of fixed IP mainly involves the processing of migrated IP and the adjustment of IP allocation logic. Figure 4 As shown, the corresponding file path is generated according to the Pod name, and the file that saves the source Pod IP is checked in the path. If the IP file exists, the IP address in it is read and assigned to the current Pod. If the source Pod IP file does not exist, the regular IP allocation process is entered.

[0119] S4. The target node network plug-in Flannel calls the target node IP migration module to read the IP cache file, and then the target node network plug-in Flannel assigns the read IP to the target service Pod;

[0120] Furthermore, the specific implementation method of step S4 is implemented by the host-local plug-in of Flannel, including the following steps:

[0121] S4.1.IP pool management: Flannel allocates an IP address pool to each node. The IP address pool is dynamically generated by Flannel based on the CIDR range of the cluster. Each node maintains a local IP address manager.

[0122] S4.2. Allocate IP address when Pod starts: When a Pod starts, Flannel calls the host-local plugin to allocate an available IP address from the node's IP address pool. This address is assigned to the Pod and configured through Flannel's network interface. The process of calculating the IP address for the i-th Pod within the node's CIDR range is as follows:

[0123] IP Pod =CIDR Node +i,i∈{1,2,...,n}

[0124] Among them, IP Pod The specific IP address assigned to the Pod, CIDR Node is the CIDR range of the current node, and i is the offset assigned to the i-th Pod;

[0125] S4.3. Set the IP address assigned to the Pod to remain unchanged during the life cycle of the Pod until the Pod is deleted or restarted; when the Pod is restarted, Flannel reuses the previously assigned IP address to ensure the continuity of the IP address;

[0126] S4.4. Network configuration: Flannel is responsible for setting routing rules so that traffic can be correctly routed within and outside the cluster, ensuring communication between Pods and the ability to access external networks.

[0127] S5. The target node service state migration module uses the checkpoint file to restore the state of the target service Pod. At the same time, the target node network state migration module modifies the network configuration of the target node to ensure that the migrated target service Pod communicates normally with the resources.

[0128] Further, in step S5, the target node network state migration module modifies the network configuration of the target node, including IP allocation and modification of the routing table;

[0129] S5.1.IP allocation: Modify the host-local network plug-in and use the IP of the source service Pod to modify the IP of the target service Pod to ensure that the actual IP address of the service Pod remains unchanged before and after the migration;

[0130] S5.2. Modify the routing table: Mark the route of the target Pod in the routing table of the target node to ensure that the traffic can correctly and directly reach the new Pod location. The process is described as follows:

[0131] Assume R dest The routing table of the target node, IP migrated is the IP address of the Pod after migration, local is the local address, and the modified routing table rules are:

[0132] R dest (IP migrated )=local

[0133] Indicates access to the IP on the target node migrated Directly access locally without going through a gateway.

[0134] Furthermore, the source node network configuration of the source node network state migration module includes IP blocking, modifying the routing table, and modifying Iptables.

[0135] When performing service migration, an IP locking mechanism is implemented to prevent users from deploying new service Pods during the migration process and occupying the IP address of the source Pod.

[0136] The IP blocking is to lock the IP of the source Pod at the beginning of the service migration to prevent other new Pods from requesting to use the IP. The process is described as follows:

[0137] Set IP src is the IP address of the source node Pod, t0 is the time when the migration starts, and t end is the end time of migration, then in the time interval [t0,t end ], use the following conditions to lock the IP:

[0138] Lock(IP src )=(t0≤t&&t≤t end )? 1:0

[0139] Among them, Lock(IP src ) = 1, it means that the IP is locked and cannot be used by other Pods.

[0140] The source node does not need to go through a gateway to communicate with the source Pod, they can access each other directly. However, when these Pods migrate to the target node, in order to ensure that these migrated Pods can be accessed correctly, corresponding markings need to be made in the network routing. This means that when accessing the IP address of the migrated Pod, the network router needs to know that these requests should be redirected to the target node instead of the source node. In this way, it can be ensured that even if the physical location of the Pod changes, the source node can still access these migrated Pods through the correct routing.

[0141] The process of modifying the route is as follows:

[0142] Assume R src is the routing table of the source node, IP migrated is the IP address of the Pod after migration, Node dest If it is the target node, the rules for route modification are as follows:

[0143] R src (IP migrated )=Node dest

[0144] Indicates access to the IP address on the source node migrated When the data packet is routed to the target node Node dest .

[0145] Since the source node does not need to perform address masquerading through Iptables to access the source Pod, but when the source Pod is migrated to the target node, address masquerading is required to access these Pods to ensure that the traffic can be correctly routed to the new location. Therefore, it is necessary to mark these migrated Pods in Iptables to avoid access without address masquerading, so as to ensure that the target node can correctly identify the data packets accessing the migrated IP address. This mechanism ensures that the traffic is processed correctly.

[0146] The Iptables modification process is described as follows:

[0147] Set IP src is the IP address of the source node, IP migrated is the IP address of the Pod after migration, IP nat is the disguised IP, then when the data packet is sent from the source node to the target Pod, the disguise rule is:

[0148] SNAT(IP src )→IP nat →IP migrated

[0149] Indicates that the source address IP srcChange to the disguised IP address nat , to ensure that traffic can be correctly routed to the IP address of the migrated Pod migrated .

[0150] The experimental results are verified as follows:

[0151] The service IP migration technology under K3s was tested. Considering that the master node does not run the business container, three virtual machines with the same hardware and software configuration were selected as cluster nodes for the experiment. One is the K3s master node, and the other two are K3s slave nodes and serve as the source node and target node of the service migration. The hardware configuration of the virtual machine node is shown in Table 1:

[0152] Table 1 Virtual machine node hardware configuration

[0153]

[0154] In addition to the hardware configuration of the node, the test environment also requires software tools such as K3s and Docker to build. The selected software and its version are shown in Table 2:

[0155] Table 2 Software tools used in the test environment

[0156]

[0157] In the test, the network service is selected as the test case. The functional test of service IP migration is performed in the above test environment to better verify the network consistency. The client periodically (1ms) sends UDP data packets containing time information to port 12345 of the container. The server running in the container listens to port 12345 to receive the data packets and parses them, and then writes the parsed results to the file. The network service is deployed in K3s, and the client periodically sends data packets to simulate user requests. The consistency of the network status before and after the migration is verified by checking whether the external address of the service has changed before and after the migration and whether the target Pod can communicate normally after the migration.

[0158] The service address consistency test results are as follows: Figure 6 As shown in the figure, the network service is successfully migrated from edge node 1 to edge node 2, and the actual IP address of the Pod is always 10.240.2.7 before and after the migration, realizing the transparency of the service address of the service migration to the user.

[0159] Communication test results such as Figure 7 As shown in the figure, although the migrated Pod and edge node 2 are not in the same network segment, the network status migration ensures that the target Pod can communicate normally with other resources.

[0160] Definitions of Abbreviations and Key Terms

[0161] 1. K8s (Kubernetes): An open source container orchestration platform designed to automate the deployment, expansion, and management of applications. It provides an efficient way to manage the lifecycle of containerized applications and supports large-scale microservice architectures.

[0162] 2. K3s (Lightweight Kubernetes): A lightweight K8s distribution designed for resource-limited environments and edge computing, providing a simplified installation and operation experience.

[0163] 3. DNS (Domain Name System): provides mapping from domain names to IP addresses.

[0164] 4.Pod: A container collection unit, the smallest schedulable unit in K3s, usually sharing network and storage resources. Services are deployed in the K3s cluster in the form of Pods for client access.

[0165] 5.Docker: A container technology platform that allows developers to package an application and all its dependencies into a standardized unit (container), ensuring that the application can run consistently in any environment.

[0166] 6.Flannel: The default network plug-in of K3s, used for container networks in K3s clusters, providing a simple overlay network solution for internal cluster communication.

[0167] 7.host-local: A Flannel IP address allocation mode that allocates IP addresses according to the local configuration file of each node. It is suitable for small clusters or simple deployments.

[0168] 8.CRIU (Checkpoint / Restore In Userspace): A tool for process checkpoint and recovery. It allows a running process to be frozen, saved to disk, and restored at a later point in time. It is usually used for container migration and recovery.

[0169] 9.SNAT (Source Network Address Translation): A network address translation technology that converts the source IP address of a data packet into another IP address.

[0170] 10.NFS (Network File System): A protocol that allows computers to share files and directories over a network.

[0171] 11.Iptables: A user space tool in the Linux kernel used to set, maintain, and check IP packet filtering rules in the Linux kernel.

[0172] 12.CIDR (Classless Inter-Domain Routing): A standard for allocating IP addresses and routes.

[0173] 13.UDP (User Datagram Protocol): A network communication protocol used to transmit data in IP networks.

[0174] It should be noted that relational terms such as "first" and "second" are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the existence of other identical elements in the process, method, article or device including the elements.

[0175] Although the present application has been described above with reference to specific embodiments, various modifications may be made thereto and parts thereof may be replaced with equivalents without departing from the scope of the present application. In particular, as long as there is no structural conflict, the various features in the specific embodiments disclosed in the present application may be used in combination with each other in any manner, and the fact that these combinations are not exhaustively described in this specification is only for the sake of omitting space and saving resources. Therefore, the present application is not limited to the specific embodiments disclosed herein, but includes all technical solutions falling within the scope of the claims.

Claims

1. An IP consistency method for K3s service migration, characterized in that: The steps include: S1. Set the source node service state migration module, the source node IP migration module and the source node network state migration module at the source node, and set the target node service state migration module, the target node IP migration module and the target node network state migration module at the target node; S2. When the client requests the source node service state migration module to migrate the service state, the source node service state migration module synchronizes the request information to the target node service state migration module, and the source node network state migration module modifies the network configuration; S3. The source node IP migration module obtains the IP information of the source service Pod and writes it into the IP cache file. NFS synchronizes the IP cache file to the target node IP migration module. S4. The target node network plug-in Flannel calls the target node IP migration module to read the IP cache file, and then the target node network plug-in Flannel assigns the read IP to the target service Pod; S5. The target node service state migration module uses the checkpoint file to restore the state of the target service Pod. At the same time, the target node network state migration module modifies the network configuration of the target node to ensure that the migrated target service Pod communicates normally with the resources.

2. According to claim 1, an IP consistency method for K3s service migration is characterized in that: The specific implementation method of the service state migration module in step S2 is as follows: S2.

1. Generate a state checkpoint at the source node: On the source node, the container status is represented as: S src ={M,P,FD,NC} Among them, M represents memory status, P represents process information, FD represents file descriptor, and NC represents network connection; The process checkpoint and recovery tool CRIU is called to generate a state checkpoint. The expression is: C checkpoint =CRIU(S src )→Save as a checkpoint file; Among them, C checkpoint Checkpoint file for the container; The checkpoint file includes the memory status, process information, file descriptors and network connection data of the container; S2.

2. Transfer the checkpoint file. Transfer the checkpoint file to the specified path of the target node through the NFS network. The expression is: C checkpoint →C checkpoint_target Among them, C checkpoint_target Checkpoint file for the target node; S2.

3. Container state recovery: On the target node, Docker starts the container instance and rebuilds the state as follows; Initialize the target state S target : S target =Docker_start(C checkpoint_target ) Use CRIU to read the checkpoint file: S target =CRIU_restore(C checkpoint_target )→S target ={M,P,FD,NC} On the target node, Docker starts the corresponding container instance and uses CRIU to read the checkpoint file to rebuild the state of the container and restore it to the running state before the migration; S2.

4. Complete service status migration: The service status is migrated from the source node to the target node, and the migrated container service status S is obtained. migrated , the expression is: S migrated =S target →S src Eventually, the service status of the target node is consistent with the service status of the source node.

3. According to claim 2, an IP consistency method for K3s service migration is characterized in that: In step S3, the IP migration module modifies the IP allocation mechanism of the host-local plug-in and sets the function called by host-local to allocate IP to the GetIter() function. The specific IP allocation process is as follows: S3.

1. Get iterator: First, call the GetIter() method to get an iterator pointing to the IP address range. The iterator will locate the last allocated IP address as the starting point for the next allocation. S3.

2. Check the last allocated IP address: In GetIter(), the last allocated IP address is checked first. If it exists, the iterator will point to it and prepare to allocate the next IP address. S3.

3. Allocate IP address: When a new IP address is requested, call the Next() method to obtain the next available IP address; if the currently pointed IP address is empty, the starting IP address of the allocation range is used; If the end of the range has been reached, the iterator will reset and loop back to the beginning of the address pool, implementing a round-robin strategy; During the allocation process, if the current IP address is a subnet gateway or an occupied IP address, the iterator will call its own Next() method to skip the subnet gateway or the occupied IP address until an available IP address is found; S3.

4. Return result: When an available IP address is found, a structure containing the available IP address and its corresponding gateway is returned. If no available IP address is found in the entire range, an error message is returned indicating that there is no available address.

4. According to claim 3, an IP consistency method for K3s service migration is characterized in that: The last allocated IP address in step S3.2 is stored in / var / lib / cni / networks / last_reserved_ip.0 by default.

5. According to claim 4, an IP consistency method for K3s service migration is characterized in that: The specific implementation method of step S4 is implemented through the host-local plug-in of Flannel, including the following steps: S4.1.IP pool management: Flannel allocates an IP address pool to each node. The IP address pool is dynamically generated by Flannel based on the CIDR range of the cluster. Each node maintains a local IP address manager. S4.

2. Allocate IP address when Pod starts: When a Pod starts, Flannel calls the host-local plugin to allocate an available IP address from the node's IP address pool. This address is assigned to the Pod and configured through Flannel's network interface. The process of calculating the IP address for the i-th Pod within the node's CIDR range is as follows: IP Pod =CIDR Node +i,i∈{1,2,...,n} Among them, IP Pod The specific IP address assigned to the Pod, CIDR Node is the CIDR range of the current node, and i is the offset assigned to the i-th Pod; S4.

3. Set the IP address assigned to the Pod to remain unchanged during the life cycle of the Pod until the Pod is deleted or restarted; when the Pod is restarted, Flannel reuses the previously assigned IP address to ensure the continuity of the IP address; S4.

4. Network configuration: Flannel is responsible for setting routing rules so that traffic can be correctly routed within and outside the cluster, ensuring communication between Pods and the ability to access external networks.

6. The IP consistency method for K3s service migration according to claim 5, characterized in that: In step S5, the target node network state migration module modifies the network configuration of the target node, including IP allocation and modification of the routing table; S5.1.IP allocation: Modify the host-local network plug-in and use the IP of the source service Pod to modify the IP of the target service Pod to ensure that the actual IP address of the service Pod remains unchanged before and after the migration; S5.

2. Modify the routing table: Mark the route of the target Pod in the routing table of the target node to ensure that the traffic can correctly and directly reach the new Pod location. The process is described as follows: Assume R dest The routing table of the target node, IP migrated is the IP address of the Pod after migration, local is the local address, and the modified routing table rules are: R dest (IP migrated )=local Indicates access to the IP on the target node migrated Directly access locally without going through a gateway.

7. The IP consistency method for K3s service migration according to claim 6 is characterized in that: The source node network configuration of the source node network state migration module includes IP blocking, modifying the routing table, and modifying Iptables.

8. The IP consistency method for K3s service migration according to claim 7, characterized in that: The IP blocking is to lock the IP of the source Pod at the beginning of the service migration to prevent other new Pods from requesting to use the IP. The process is described as follows: Set IP src is the IP address of the source node Pod, t0 is the time when the migration starts, and t end is the end time of migration, then in the time interval [t0,t end ], use the following conditions to lock the IP: Lock(IP src )=(t0≤t&&t≤t end )?1:0 Among them, Lock(IP src ) = 1, it means that the IP is locked and cannot be used by other Pods.

9. The IP consistency method for K3s service migration according to claim 8, characterized in that: The process of modifying the route is as follows: Assume R src is the routing table of the source node, IP migrated is the IP address of the Pod after migration, Node dest If it is the target node, the rules for route modification are as follows: R src (IP migrated )=Node dest Indicates access to the IP address on the source node migrated When the data packet is routed to the target node Node dest .

10. The IP consistency method for K3s service migration according to claim 9, characterized in that: The Iptables modification process is described as follows: Set IP src is the IP address of the source node, IP migrated is the IP address of the Pod after migration, IP nat is the disguised IP, then when the data packet is sent from the source node to the target Pod, the disguise rule is: SNAT(IP src )→IP nat →IP migrated Indicates that the source address IP src Change to the disguised IP address nat , to ensure that traffic can be correctly routed to the IP address of the migrated Pod migrated .

Images