Node migration method and device, equipment and storage medium

Abstract

The embodiment of the invention relates to the technical field of cloud computing, in particular to a node migration method and device, equipment and a storage medium, and aims to ensure normal operation of pod while realizing node migration. The method comprises the following steps: a container platform sends container group information of a container group in a target node in a first cluster to a second cluster; the container platform migrates the target node from the first cluster to the second cluster; the controller in the second cluster sends a container group creation request to a central node of the second cluster according to the container group information, monitors a container group operation initiated by the container platform, and executes a corresponding operation; the container group management component intercepts the container group creation request and receives the container group operation; and the container group management component processes the container group operation according to the operation target and the operation type of the container group operation, so that the container group normally runs in the target node.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of cloud computing technology, and more specifically, to a node migration method, apparatus, device, and storage medium. Background Art

[0002] There are multiple clusters in the cloud environment. Different clusters are located in different regions and have different numbers of edge nodes. Due to business reasons, it is usually necessary to transfer the edge nodes in one cluster to another cluster. In the prior art, if an edge machine that has been managed wants to access another cluster, the conventional operation is to first remove the machine from the shelf, delete the node from the original cluster, and delete the old stand-alone business container Pod. Then, it is re-uploaded to the new cluster and a new stand-alone business container Pod is created. In the prior art, if the machine is first removed from the shelf and then put back on the shelf, the pod on the edge node will be deleted and then created, resulting in online business interruption. Summary of the invention

[0003] The embodiments of the present application provide a node migration method, apparatus, device and storage medium, aiming to achieve node migration while ensuring the normal operation of the pod.

[0004] A first aspect of an embodiment of the present application provides a node migration method, the method comprising: The container platform sends the container group information of the container group in the target node in the first cluster to the second cluster; The container platform migrates the target node from the first cluster to the second cluster; The controller in the second cluster sends a container group creation request for the target node to the central node of the second cluster according to the container group information, listens to the container group operation initiated by the container platform, and performs the corresponding operation; The container group management component in the central node intercepts the container group creation request and receives the container group operation; The container group management component processes the container group operation according to the operation target and the operation type of the container group operation, so that the container group runs normally in the target node.

[0005] Optionally, before the controller in the second cluster sends a container group creation request for the target node to the central node of the second cluster according to the container group information, the method further includes: The container platform queries a database of the first cluster for a label corresponding to the target node in the first cluster; The container platform adds the label to the target node in the second cluster; When the tag is detected, the controller determines that the target node joins the second cluster.

[0006] Optionally, the method further includes: when the target node migrates to the second cluster, reporting container group status information to the central node; The central node queries the database of the second cluster for corresponding data of the container group according to the container group name included in the container group status information; When the central node cannot find the corresponding data in the database of the second cluster, the central node sends a deletion command to the target node; The container group management component intercepts the deletion command.

[0007] Optionally, the container platform sends the container group information of the container group in the target node in the first cluster to the second cluster, including: The container platform stores the container group information in a container group configuration file, wherein the container group information includes at least each container group name in the target node and a corresponding node name, each container group name in the target node and a corresponding container group number, and all container group names corresponding to the target node; The container platform sends the container group configuration file to the second cluster.

[0008] Optionally, the container platform migrates the target node from the first cluster to the second cluster, including: The container platform establishes a network connection between the target node and the second cluster; The container platform adds the target node to the whitelist of the firewall of the second cluster; The container platform backs up the certificate and configuration file of the target node in the first cluster; The container platform obtains authentication information from the second cluster; When the container platform obtains the authentication information, writing the network address of the central node of the second cluster into the configuration file; The container platform restarts the container group management component in the target node to migrate the target node from the first cluster to the second cluster.

[0009] Optionally, the controller in the second cluster sends a container group creation request for the target node to the central node of the second cluster according to the container group information, listens to the container group operation initiated by the container platform, and performs corresponding operations, including: The controller determines, when detecting that the target node joins the second cluster, whether a node name of the target node matches a node name stored in the container group information; The controller determines, when a node name of the target node matches a node name stored in the container group information, whether the container group creation request has been sent to the target node; When determining that the container group creation request has not been sent to the target node, the controller queries the container group information for a container group name corresponding to the target node; The controller sends the container group creation request to the central node, where the name field in the container group creation request is the container group name; The controller determines, when monitoring that the container group operation is an update operation, whether a deletion timestamp corresponding to the container group is nil; The controller deletes the container group information if the deletion timestamp is not nil; The controller deletes the container group information when it is detected that the container group operation is a deletion operation.

[0010] Optionally, the container group management component processes the container group operation according to an operation target and an operation type of the container group operation, including: The container group management component determines, if the operation type of the container group operation is an update operation, whether the operation target of the container group operation is the container group in the target node according to the container group information; The container group management component determines, when the operation target is a container group in the target node, whether a deletion timestamp corresponding to the container group is nil; The container group management component replaces the container group number in the container group operation with the container group number corresponding to the container group when the deletion timestamp is not nil; The container group management component determines, if the operation type of the container group is a deletion operation, whether the operation target of the container group operation is the container group in the target node according to the container group information; The container group management component replaces the container group number in the container group operation with the container group number corresponding to the container group when the operation target is the container group in the target node; The container group management component transmits the container group operation to the target node; The container group management component releases the container group operation when the operation target is not the container group in the target node.

[0011] A second aspect of an embodiment of the present application provides a node migration device, the device comprising: A container group information sending module, used for the container platform to send the container group information of the container group in the target node in the first cluster to the second cluster; A node migration module, used by the container platform to migrate the target node from the first cluster to the second cluster; A controller operation module, configured for the controller in the second cluster to send a container group creation request for the target node to the central node of the second cluster according to the container group information, and to listen to the container group operation initiated by the container platform and perform corresponding operations; An operation interception module, used for the container group management component in the central node to intercept the container group creation request and receive the container group operation; The container group manager operation module is used for the container group management component to process the container group operation according to the operation target and operation type of the container group operation, so that the container group can run normally in the target node.

[0012] Optionally, the device further comprises: A label acquisition module, used by the container platform to query the label corresponding to the target node in the first cluster from the database of the first cluster; A label adding module, used for the container platform to add the label to the target node in the second cluster; The node determination module is used for the controller to determine that the target node joins the second cluster when the tag is detected.

[0013] Optionally, the device further includes: an information reporting module, configured to report container group status information to the central node when the target node is migrated to the second cluster; A data query module, configured for the central node to query corresponding data of the container group in the database of the second cluster according to the container group name included in the container group status information; A deletion command issuing module, used for issuing a deletion command to the target node when the central node cannot find the corresponding data in the database of the second cluster; The deletion command interception module is used for the container group management component to intercept the deletion command.

[0014] Optionally, the container group information sending module includes: An information storage submodule, configured for the container platform to store the container group information in a container group configuration file, wherein the container group information includes at least each container group name in the target node and the corresponding node name, each container group name in the target node and the corresponding container group number, and all container group names corresponding to the target node; The file sending submodule is used for the container platform to send the container group configuration file to the second cluster.

[0015] Optionally, the node migration module includes: A network connection establishment submodule, used for the container platform to establish a network connection between the target node and the second cluster; A whitelist submodule, configured for the container platform to add the target node to a whitelist of the firewall of the second cluster; A certificate acquisition submodule, used for the container platform to back up the certificate and configuration file of the target node in the first cluster; An authentication information acquisition submodule, used for the container platform to acquire authentication information from the second cluster; A network address writing submodule, configured to write the network address of the central node of the second cluster into the configuration file when the container platform obtains the authentication information; The restart submodule is used for the container platform to restart the container group management component in the target node to migrate the target node from the first cluster to the second cluster.

[0016] Optionally, the controller operation module includes: a first controller operation submodule, configured for the controller to determine whether a node name of the target node matches a node name stored in the container group information when detecting that the target node joins the second cluster; A second controller operation submodule, configured for the controller to determine, when a node name of the target node matches a node name stored in the container group information, whether the container group creation request has been sent to the target node; A third controller operation submodule, configured for the controller to query the container group name corresponding to the target node in the container group information when determining that the container group creation request has not been sent to the target node; A fourth controller operation submodule, configured for the controller to send the container group creation request to the central node, wherein the name field in the container group creation request is the container group name; A fifth controller operation submodule, configured for the controller to determine whether a deletion timestamp corresponding to the container group is nil when it is detected that the container group operation is an update operation; A sixth controller operation submodule, configured for the controller to delete the container group information when the deletion timestamp is not nil; The seventh controller operation submodule is used for the controller to delete the container group information when it is detected that the container group operation is a deletion operation.

[0017] Optionally, the container group manager operation module includes: A first container group manager operation submodule, configured for the container group management component to determine, when the operation type of the container group operation is an update operation, whether the operation target of the container group operation is the container group in the target node according to the container group information; A second container group manager operation submodule, configured for the container group management component to determine whether a deletion timestamp corresponding to the container group is nil when the operation target is a container group in the target node; A third container group manager operation submodule, configured for the container group management component to replace the container group number in the container group operation with the container group number corresponding to the container group when the deletion timestamp is not nil; a fourth container group manager operation submodule, configured for the container group management component to determine, according to the container group information, whether the operation target of the container group operation is the container group in the target node when the operation type of the container group is a deletion operation; a fifth container group manager operation submodule, configured for the container group management component to replace the container group number in the container group operation with the container group number corresponding to the container group when the operation target is the container group in the target node; a sixth container group manager operation submodule, configured for the container group management component to transmit the container group operation to the target node; The seventh container group manager operation submodule is configured to allow the container group management component to release the container group operation when the operation target is not the container group in the target node.

[0018] A third aspect of an embodiment of the present application provides a readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the steps in the method described in the first aspect of the present application are implemented.

[0019] A fourth aspect of an embodiment of the present application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, the steps of the method described in the first aspect of the present application are implemented.

[0020] Using the node migration method provided by the present application, the container platform sends container group information of the container group in the target node in the first cluster to the second cluster; the container platform migrates the target node from the first cluster to the second cluster; the controller in the second cluster sends a container group creation request for the target node to the central node of the second cluster according to the container group information, and listens to the container group operation initiated by the container platform to perform the corresponding operation; the container group management component in the central node intercepts the container group creation request and receives the container group operation; the container group management component processes the container group operation according to the operation target and operation type of the container group operation, so that the container group operates normally in the target node.

[0021] In this method, the container group information in the first cluster is sent to the second cluster, the target node in the first cluster is migrated to the second cluster, the container group creation operation of the controller is intercepted by the container group management component, and the container group operation of the container platform for the target node is processed, so that the container group does not create a new container group in the target node, and at the same time, it is ensured that the container group operation of the container platform for the target node can be mapped to the original container group of the target node, so as to ensure that the container group in the target node can operate normally, thereby ensuring that the business corresponding to the container group is not interrupted, and realizing smooth migration of edge nodes. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the description of the embodiments of the present application will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0023] Figure 1 is a flow chart of a node migration method proposed in an embodiment of the present application; Figure 2 This is a schematic diagram of smooth migration proposed in an embodiment of the present application; Figure 3 is a flow chart of a node migration method proposed in one embodiment of the present application; Figure 4 is a schematic diagram of a container platform architecture proposed in an embodiment of the present application; Figure 5This is a schematic diagram of cluster migration proposed in an embodiment of the present application; Figure 6 It is a schematic diagram of the controller execution process proposed in an embodiment of the present application; Figure 7 It is a schematic diagram of the process flow of the container group management component proposed in an embodiment of the present application; Figure 8 It is a schematic diagram of the operation process proposed in an embodiment of the present application; Fig. 9 is a schematic diagram of a node migration device proposed in an embodiment of the present application; Fig.10 It is a schematic diagram of an electronic device proposed in an embodiment of the present application. DETAILED DESCRIPTION

[0024] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0025] For the convenience of explanation, the professional terms appearing in the embodiments are first explained: KubeEdge (Container Group Management Component): KubeEdge is an open source system that extends native containerized business processes and device management to edge hosts. It is built on Kubernetes and provides core infrastructure support for networking, application deployment, and metadata synchronization between the cloud and the edge. KubeEdge mainly consists of two parts: cloudcore and edgecore. Cloudcore runs on the central node and edgecore runs on the edge node. Edge node: A machine located on the edge side that is connected to the central node of the central cluster through KubeEdge.

[0026] Playbook: Ansible is used to configure, deploy, and manage controlled nodes. Through the detailed description of the playbook and the execution of the tasks in it, the remote host can reach the expected state.

[0027] Currently, more and more companies are using Kubernetes to build and deploy their application services. The main reason is that Kubernetes provides powerful and flexible container orchestration and management capabilities, which can help companies build and manage highly scalable cloud-native applications. Kubernetes allows companies to dynamically adjust the scale of applications according to load requirements, thereby achieving elastic expansion. It can automatically handle the scheduling and resource allocation of containers, reducing the burden on operation and maintenance personnel while ensuring that applications have high availability and scalability. Companies using Kubernetes can help them build modern, scalable, and highly reliable applications, improve development efficiency, reduce operation and maintenance costs, and achieve cross-platform and multi-cloud flexibility and portability.

[0028] KubeEdge is an extensible plug-in based on K8s and relies on Kubernetes. For enterprises, edge machines are located all over the country, and the network channel distances between them and the central node are different. Traditional Kubernetes access requires real-time performance. Considering the instability of the network, KubeEdge access can achieve edge autonomy. The performance of the cloud-edge channel is improved through the underlying optimized multiplexed message channel, thereby reducing the network bandwidth requirements between the edge and the cloud. The plug-in approach also ensures its lightweight and performance.

[0029] Currently, there are multiple clusters in the production environment based on CDN services. Different clusters are located in different regions and have different numbers of edge nodes. In addition, due to the CDN business scenario, the production environment uses the DaemonSet controller to deploy business containers. A single component on a single machine has only one business container Pod.

[0030] If an edge machine that has been managed wants to connect to another cluster, the normal operation is to first remove the machine from the shelf, delete the node from the original cluster, delete the old stand-alone business container Pod, and then put it back on the new cluster to create a new stand-alone business container Pod. The entire process involves the removal and re-listing of the machine, which will cause the Pod on the edge node to be deleted and then created, and the online business will be briefly interrupted. The embodiment of the present application adopts the concept of cloud native, and proposes a system and method for smooth migration of edge nodes based on KubeEdge, which completes the smooth migration of edge nodes from the original cluster to the new cluster, avoids the deletion and creation of Pods, and ultimately achieves the goal of smooth migration without business interruption, and maintains the load performance of the edge cluster.

[0031] refer to Figure 1 , Figure 1 This is a schematic diagram of cluster node migration, such as Figure 1As shown in the figure, when node3 is migrated, pod1, pod2, and pod3 are deleted. After node3 is added to edge cluster 2, pod4, pod5, and pod6 are created.

[0032] The embodiment of the present application proposes a system and method for smooth migration of edge nodes based on KubeEdge. Based on the ConfigMap (configuration file that stores node and container information) feature, the relevant information of the edge node is stored and sent to the pre-access cluster. Based on the event monitoring of Informer, the controller initiates a request to create a Pod and cleans up the data of ConfigMap at the edge node. Based on the KubeEdge edge computing framework, a special "mapping" of the new and old Pods of the edge node is implemented, ultimately achieving the purpose of smooth transition of the edge node.

[0033] refer to Figure 2 , Figure 2 is a schematic diagram of smooth migration proposed in an embodiment of the present application, such as Figure 2 As shown in the figure, after node3 is migrated from edge cluster 1 to edge cluster 2, the original pod1, pod2, and pod3 are mapped to edge cluster 2. There is no need to shut down the original pod, thus ensuring uninterrupted business.

[0034] refer to Figure 3 , Figure 3 : is a flowchart of a node migration method proposed in an embodiment of the present application. Figure 3 As shown, the method comprises the following steps: S11: The container platform sends container group information of the container group in the target node in the first cluster to the second cluster.

[0035] refer to Figure 4 , Figure 4 is a schematic diagram of a container platform architecture proposed in an embodiment of the present application, such as Figure 4 As shown in the figure, the container platform connects multiple edge clusters. Each edge cluster has a central node (master) and multiple edge nodes (node1, node2). The edge node that needs to be migrated is the target node. The central node has api-server (one of the core components of the Kubernetes cluster, responsible for processing all RESTful API requests to the cluster, and is the interface between users, external tools, and internal components of the system.) and cloudcoer (container group management component). The edgecore in the edge node is also part of the container group management component. The controller is located in the central node and is used to create container groups and manage container group information. The container platform is a platform for managing container groups (pods) in the cluster.

[0036] In this embodiment, the container platform manages multiple clusters, and the multiple clusters are located in different regions and have different numbers of nodes. When a node wants to migrate from the original cluster (the first cluster) to the new cluster (the second cluster), in order to ensure smooth migration of the business, the container group information stored in the first cluster must first be stored in the container group configuration file (ConfigMap) in the specified format, and then sent to the second cluster.

[0037] In this embodiment, the specific steps of the container platform sending the container group information of the container group in the target node in the first cluster to the second cluster include: S11-1: The container platform stores the container group information in a container group configuration file, where the container group information includes at least each container group name in the target node and the corresponding node name, each container group name in the target node and the corresponding container group number, and all container group names corresponding to the target node.

[0038] refer to Figure 5 , Figure 5 is a schematic diagram of cluster migration proposed in an embodiment of the present application, such as Figure 5 As shown, the operation and maintenance personnel first select the machine to be migrated, that is, the target node. During the pre-migration process, the container group information is first added to the container group configuration file, and then sent to the expected cluster (the second cluster). The container group information includes at least three subordinate ConfigMaps: white-pod-node, all podNames (container group names) and their corresponding node names (key-value pairs: podName:nodeName,) on the migration node, which are mainly used to query the ConfigMap to clean up other ConfigMap information sent by the container platform after the original Pod of the edge node is deleted. white-pods: podName and podUid (container group number) of all pods on the migration node (key-value pair: podName:PodUid), which are mainly used to tamper with the message transmission of the new and old Pods on the central end and the edge segment, so as to achieve a smooth transition of the business. white-nodes: all podNames corresponding to a single node of the migration node (key-value pair: nodeName:podName1,podName2), which are mainly used for the controller to initiate a request to create a new Pod with the same name as the old Pod of the original cluster in the expected cluster.

[0039] S11-2: The container platform sends the container group configuration file to the second cluster.

[0040] In this embodiment, the container platform sends the container group configuration file to the second cluster, and the second cluster obtains the corresponding container group information.

[0041] S12: The container platform migrates the target node from the first cluster to the second cluster.

[0042] In this embodiment, the container platform migrates the target node from the first cluster to the second cluster. The specific steps include: S12-1: The container platform establishes a network connection between the target node and the second cluster.

[0043] In this embodiment, the container platform establishes a network connection between the target node and the second cluster.

[0044] S12-2: The container platform adds the target node to the whitelist of the firewall of the second cluster.

[0045] In this embodiment, the container platform adds the target node to the whitelist of the firewall of the second cluster to ensure that the connection between the target node and the second cluster is not intercepted.

[0046] S12-3: The container platform backs up the certificate and configuration file of the target node in the first cluster.

[0047] In this embodiment, the container platform backup target receives your certificate and configuration file in the first cluster. The certificate is used to ensure the security of information transmission in the cluster, and the data can be authenticated through the certificate.

[0048] S12-4: The container platform obtains authentication information from the second cluster.

[0049] In this embodiment, the container platform obtains authentication information from the second cluster, and can access the second cluster only after obtaining the authentication information.

[0050] S12-5: When the container platform obtains the authentication information, the network address of the central node of the second cluster is written into the configuration file.

[0051] In this embodiment, when the container platform obtains the authentication information, the network address of the central node of the second cluster is written into the configuration file.

[0052] S12-6: The container platform restarts the container group management component in the target node to migrate the target node from the first cluster to the second cluster.

[0053] In this embodiment, the container platform restarts the container group management component in the target node, loads the configuration file, and then migrates the target node from the first cluster to the second cluster.

[0054] In this embodiment, Figure 5As shown in the figure, playbook (whitening) opens the network between the edge node and the desired migration cluster, whitens the firewall to prevent the edge node from connecting to the cluster center node. At the same time, the platform stores the Pod information of the edge node running in the old cluster in ConfigMap and sends it to the desired cluster. After whitening and sending ConfigMap, playbook (migration) backs up the certificate and configuration file of the original cluster, then obtains the authentication token (authentication information) from the desired cluster, writes the IP value of the center node into the configuration file, restarts edgecore, and edgecore will connect to the desired cluster.

[0055] In this embodiment, if the connection fails, the original certificate and configuration file are restored through playbook (recovery), so that the edge node can reconnect to the original cluster, and the platform side deletes the relevant data in ConfigMap.

[0056] In this embodiment, the method further includes: S12-7: The container platform queries the database of the first cluster for a label corresponding to the target node in the first cluster.

[0057] In this embodiment, the label of the target node is a label set by the container platform for the target cluster, which is used to characterize the service characteristics of the container group in the target node.

[0058] In this embodiment, after the migration is completed, the container platform queries the database of the first cluster for the label corresponding to the target node in the first cluster.

[0059] S12-8: The container platform adds the label to the target node in the second cluster.

[0060] In this embodiment, the container platform adds the label of the target node in the first cluster to the target node in the second cluster to maintain the consistency of the service labels of the target nodes in the two clusters.

[0061] S12-9: When the tag is detected, the controller determines that the target node joins the second cluster.

[0062] In this embodiment, the controller in the second cluster determines that the target node joins the second cluster when detecting a label on the target node.

[0063] S13: The controller in the second cluster sends a container group creation request for the target node to the central node of the second cluster according to the container group information, listens to the container group operation initiated by the container platform, and performs corresponding operations.

[0064] In this embodiment, the controller in the second cluster sends a container group creation request to the central node of the second cluster according to the container group information to create a new container group for the target node, and listens to the container group operation initiated by the container platform, and performs corresponding operations according to the container group operation. The specific steps include: S13 - 1 : When detecting that the target node has joined the second cluster, the controller determines whether the node name of the target node matches the node name stored in the container group information.

[0065] In this embodiment, Figure 6 is a schematic diagram of a controller execution flow proposed in an embodiment of the present application, such as Figure 6 As shown, when the controller detects that the target node has joined the second cluster, it determines whether the node name of the target node matches the node name stored in the container group information, queries the ConfigMap (white-nodes), which stores the node name of the migrated node, and determines whether the node name of the node where the new pod needs to be created exists. If it does not exist, it means that it is a normally listed machine, not a migrated machine, and the new Pod can be named randomly.

[0066] S13 - 2 : When the node name of the target node matches the node name stored in the container group information, the controller determines whether the container group creation request has been sent to the target node.

[0067] In this embodiment, Figure 6 As shown, when the node name of the target node matches the node name stored in the container group information, the controller determines whether a container group creation request has been sent to the target node, queries the PodInformer (container group information list), and determines whether a new Pod has been created before. If so, it is created randomly. This query is mainly for the upgrade scenario (create a new Pod first, then delete the old Pod). In the upgrade scenario, the original container group will be upgraded, which can ensure that the business is not interrupted and avoid conflicts.

[0068] S13-3: When the controller determines that the container group creation request has not been sent to the target node, it queries the container group information for a container group name corresponding to the target node.

[0069] In this embodiment, Figure 6The controller determines that no container group creation request has been sent to the target node, that is, when creating a container for the target node for the first time, it queries the container group name corresponding to the target node in the container group information. When the controller creates a new Pod for the node for the first time, it matches the workload name with the podName corresponding to the nodeName stored in white-nodes to find the corresponding podName to be created.

[0070] S13-4: The controller sends the container group creation request to the central node, where the name field in the container group creation request is the container group name.

[0071] In this embodiment, Figure 6 As shown in the figure, the controller initiates a request to create a pod to the api-server of the central node. The Name field of the pod in the request is set to the PodName queried in the previous step.

[0072] S13-5: When the controller detects that the container group operation is an update operation, the controller determines whether the deletion timestamp corresponding to the container group is nil.

[0073] In this embodiment, Figure 6 As shown in the figure, when the controller creates the Pod for the migrated node for the first time, when the platform deletes the Pod, the real Pod of the old cluster will also be deleted. To avoid the subsequent creation of the corresponding component Pod still querying the corresponding podName from ConfigMap (white-nodes) and causing the creation request to be intercepted by cloudcore, it is necessary to monitor the pod event and clean up the container group configuration information sent by the container platform.

[0074] In this embodiment, when the controller detects that the container group operation is an update operation, it determines whether the delete timestamp (deleteTimeStamp) corresponding to the container group is nil (empty character). If the delete timestamp is not nil, it means that the update operation is an update event before the delete event, and the container group information needs to be deleted. If the delete timestamp is nil, it means that it is a common update event, and the container group information does not need to be deleted.

[0075] S13-6: When the deletion timestamp is nil, the controller deletes the container group information.

[0076] In this embodiment, when the deletion timestamp is nil, the controller deletes the corresponding container group information in the target node. It is determined whether deleteTimeStamp is nil. If deleteTimeStamp is not nil, the corresponding data in white-nodes, white-pods, and white-pod-node is deleted.

[0077] S13-7: When the controller detects that the container group operation is a deletion operation, the controller deletes the container group information.

[0078] In this embodiment, when the controller detects that the container group operation is a delete operation, it deletes the container group information and deletes the corresponding data in white-nodes, white-pods, and white-pod-node.

[0079] S14: The container group management component in the central node intercepts the container group creation request and receives the container group operation.

[0080] In this embodiment, reference Figure 7 , Figure 7 : is a schematic diagram of a container group management component process proposed in an embodiment of the present application, such as Figure 7 As shown, the edge node establishes a connection through kubeEdge and registers the node to the central node. When the central node and the edge node establish a connection, the edge node reports the podStatus of the original old pod to the central node. Under normal circumstances, when the central node receives the status message reported by the edge, it will query the pod data from the apiserver and update the status. However, because the old Pod is not stored in the database of the central node of the expected cluster, it will be deleted by the central node because it cannot be queried. Modification is required to prevent the old Pod from being deleted. Secondly, after the controller detects the access of the new node and adds the corresponding label, the controller will initiate a request to create a new Pod with the same name. In order to achieve a smooth transition of the business, the new Pod is not allowed to be created on the edge, and the corresponding request needs to be intercepted. Therefore, it is necessary to modify the cloudcore end of kubeEdge.

[0081] In this embodiment, the container group management component in the central node intercepts the container group creation request and receives the container group operation.

[0082] In this embodiment, the request to create a new pod with the same name sent by the controller is transmitted to the DownStreamController of the central node cloudcore through the api-server for message distribution and processing.

[0083] S15: The container group management component processes the container group operation according to the operation target and operation type of the container group operation, so that the container group runs normally in the target node.

[0084] In this embodiment, the container group management component processes the container group operation according to the operation target and operation type of the container group operation, so that the container group runs normally in the target node. The specific steps include: S15-1: When the operation type of the container group operation is an update operation, the container group management component determines, according to the container group information, whether the operation target of the container group operation is a container group in the target node.

[0085] In this embodiment, reference Figure 8 , Figure 8 is a schematic diagram of an operation process proposed in an embodiment of the present application, such as Figure 8 As shown, when the operation type of the container group operation is an update operation, the container group management component determines whether the operation target of the container group operation is a container group in the target node.

[0086] S15-2: When the operation target is a container group in the target node, the container group management component determines whether a deletion timestamp corresponding to the container group is nil.

[0087] In this embodiment, Figure 8 As shown, when the operation target is the container group in the target node, the container group management component determines whether the deletion timestamp corresponding to the container group is nil. If it is not nil, it means that the operation is an update operation before the deletion operation. If it is nil, it means that it is a normal update operation.

[0088] S15-3: When the deletion timestamp is not nil, the container group management component replaces the container group number in the container group operation with the container group number corresponding to the container group.

[0089] In this embodiment, Figure 8 As shown, when the deletion timestamp is not nil, the container group management component replaces the container group number (podUid) in the container group operation with the container group number corresponding to the container group, and then sends the container group operation to the edge node (target node). If the deletion timestamp is nil, the container group operation is intercepted.

[0090] S15-4: When the operation type of the container group is a deletion operation, the container group management component determines, according to the container group information, whether the operation target of the container group operation is the container group in the target node.

[0091] In this embodiment, Figure 8 As shown, when the operation type of the container group is a delete operation, the container group management component determines whether the operation target of the container group operation is a container group in the target node according to the container group information.

[0092] S15-5: When the operation target is a container group in the target node, the container group management component replaces the container group number in the container group operation with the container group number corresponding to the container group.

[0093] In this embodiment, Figure 8 As shown, when the operation target is a container group in a target node, the container group management component replaces the container group number in the container group operation with the container group number corresponding to the container group in the target node.

[0094] S15-6: The container group management component transmits the container group operation to the target node.

[0095] In this embodiment, Figure 8 As shown, the container group management component transmits the container group operation to the target node after replacing the container group number.

[0096] S15-7: The container group management component releases the container group operation when the operation target is not the container group in the target node.

[0097] In this embodiment, Figure 8 As shown, when the operation target is not the container group in the target node, the container group management component determines that the container group operation is not for the container group in the target node, and then releases the container group operation.

[0098] In this embodiment, Figure 8As shown, for the creation operation (add), first query white-pods to determine whether it is a migrated pod of the migration node. If not, it means that it is a regular pod and is released normally. If it is, the message needs to be intercepted to prevent the message from being delivered to the edge end (i.e., the target node). For the update operation (modify), first query white-pods to determine whether it is a migrated pod of the migration node. If not, it means that it is a regular pod and is released normally. If it is, determine whether the content deleteTimeStamp of the update event is nil. If not, intercept the message. If it is to replace the PodUid in the message, release the message to the edge end. The edge segment queries the old POD based on PodUid and PodName to complete the mapping of the new and old Pods. The new pod is not actually created in the target node, but it is considered to be a new pod in the concept of the central node. For the deletion event (delete), first query white-pods to determine whether it is a migrated pod of the migration node. If not, it means that it is a regular pod and is released normally. If it is, replace the PodUid in the message and release the message to the edge node.

[0099] In this embodiment, the main purpose of different event processing methods is to complete the special mapping between the old Pod of the migration node and the newly created Pod of the controller by tampering with the messages communicated between the cloud and the edge. Although the new Pod created by the controller is not created on the edge node, because it has the same name as the old Pod and the data is stored in the cloud database, the PodStatus reported by the edge will be transmitted and synchronized to the PodStatus of the new Pod, and finally the smooth transition of the edge node is completed, and the business is not interrupted. When the central node deletes the new pod, due to the tampering of the cloud and edge messages, the original old Pod of the edge node will eventually be deleted, completing the smooth migration.

[0100] In this embodiment, the method further includes: S17: when the target node is migrated to the second cluster, reporting container group status information to the central node.

[0101] In this embodiment, the container group status information (PodStatus) includes the life cycle status of the current container group.

[0102] In this embodiment, Figure 7 As shown, when the target node migrates to the second cluster, it reports the container group status information to the central node.

[0103] S18: The central node queries the database of the second cluster for corresponding data of the container group according to the container group name included in the container group status information.

[0104] In this embodiment, Figure 7 As shown, the central node queries the corresponding data of the container group in the database of the second cluster according to the container group name included in the container group status information.

[0105] S19: When the central node cannot find the corresponding data in the database of the second cluster, the central node sends a deletion command to the target node.

[0106] In this embodiment, Figure 7 As shown, when the central node cannot find the corresponding data in the database of the second cluster, it sends a deletion command to the target node because the container group information of the target node is not stored in the database of the second cluster.

[0107] S110: The container group management component intercepts the deletion command.

[0108] In this embodiment, the container group manager intercepts the deletion command to prevent the container group of the target node from being deleted.

[0109] In this embodiment, Figure 7 As shown in the figure, the edge node reports the podStatus status message, which is passed to the UpStreamController component through cloudhub. UpStreamController queries the information from apiServer based on podName. If the information can be found, the pod's Status is updated normally. If the information cannot be found, it queries white-pods again to see if it exists. If it does not exist, the pod is deleted normally. If it exists, it means that it is an old pod of the migration node. The deletion message is intercepted to prevent the old pod from being deleted, which will cause business interruption.

[0110] In the above embodiment of the present application, a system and method for smooth migration of edge nodes based on KubeEdge are proposed. The storage, distribution and cleaning of Pod data and Node data are completed based on the event callback of ConfigMap and Informer. By tampering with the content of kubeEdge cloud and edge node messages and intercepting messages of different scenarios, the central node thinks that it is sending messages to the newly established container group, and the actual operation can be mapped to the original container group in the target node after processing, and the original container group is used to execute the business in the target node to achieve uninterrupted business. In terms of business stability, the conventional edge node migration from one cluster to another requires a process of delisting and relisting. The original Pod will be deleted and the business will be interrupted. The smooth migration of edge nodes completed based on KubeEdge will not cause the container to be deleted, and the stable operation of the business can be guaranteed. In terms of maintaining cluster load performance, different clusters in the production environment have different numbers of nodes. If some clusters have too many edge nodes, the pressure on the central end will be high, resulting in performance problems. The smooth migration of edge nodes can maintain the access of edge nodes, control the number of nodes between different clusters, and do not affect the business. Therefore, while implementing edge node migration, services on the edge nodes are not interrupted.

[0111] Based on the same inventive concept, an embodiment of the present application provides a node migration device. Fig. 9 , Fig. 9 FIG. 9 is a schematic diagram of a node migration device 900 proposed in an embodiment of the present application. Fig. 9 As shown, the device comprises: The container group information sending module 901 is used for the container platform to send the container group information of the container group in the target node in the first cluster to the second cluster; A node migration module 902, used by the container platform to migrate the target node from the first cluster to the second cluster; A controller operation module 903, configured for the controller in the second cluster to send a container group creation request for the target node to the central node of the second cluster according to the container group information, and to listen to the container group operation initiated by the container platform and perform the corresponding operation; An operation interception module 904, configured for the container group management component in the central node to intercept the container group creation request and receive the container group operation; The container group manager operation module 905 is used for the container group management component to process the container group operation according to the operation target and operation type of the container group operation, so that the container group can run normally in the target node.

[0112] Optionally, the device further comprises: A label acquisition module, used for the container platform to query the label corresponding to the target node in the first cluster from the database of the first cluster; A label adding module, used for the container platform to add the label to the target node in the second cluster; The node determination module is used for the controller to determine that the target node joins the second cluster when the tag is detected.

[0113] Optionally, the device further includes: an information reporting module, configured to report container group status information to the central node when the target node is migrated to the second cluster; A data query module, configured for the central node to query corresponding data of the container group in the database of the second cluster according to the container group name always included in the container group status information; A deletion command issuing module, used for issuing a deletion command to the target node when the central node cannot find the corresponding data in the database of the second cluster; The deletion command interception module is used for the container group management component to intercept the deletion command.

[0114] Optionally, the container group information sending module includes: An information storage submodule, configured for the container platform to store the container group information in a container group configuration file, wherein the container group information includes at least each container group name in the target node and the corresponding node name, each container group name in the target node and the corresponding container group number, and all container group names corresponding to the target node; The file sending submodule is used for the container platform to send the container group configuration file to the second cluster.

[0115] Optionally, the node migration module includes: A network connection establishment submodule, used for the container platform to establish a network connection between the target node and the second cluster; A whitelist submodule, configured for the container platform to add the target node to a whitelist of the firewall of the second cluster; A certificate acquisition submodule, used for the container platform to back up the certificate and configuration file of the target node in the first cluster; An authentication information acquisition submodule, used for the container platform to acquire authentication information from the second cluster; A network address writing submodule, configured to write the network address of the central node of the second cluster into the configuration file when the container platform obtains the authentication information; The restart submodule is used for the container platform to restart the container group management component in the target node to migrate the target node from the first cluster to the second cluster.

[0116] Optionally, the controller operation module includes: a first controller operation submodule, configured for the controller to determine whether a node name of the target node matches a node name stored in the container group information when detecting that the target node joins the second cluster; A second controller operation submodule, configured for the controller to determine, when a node name of the target node matches a node name stored in the container group information, whether the container group creation request has been sent to the target node; A third controller operation submodule, configured for the controller to query the container group name corresponding to the target node in the container group information when determining that the container group creation request has not been sent to the target node; A fourth controller operation submodule, configured for the controller to send the container group creation request to the central node, wherein the name field in the container group creation request is the container group name; A fifth controller operation submodule, configured for the controller to determine whether a deletion timestamp corresponding to the container group is nil when it is detected that the container group operation is an update operation; A sixth controller operation submodule, configured for the controller to delete the container group information when the deletion timestamp is not nil; The seventh controller operation submodule is used for the controller to delete the container group information when it is detected that the container group operation is a deletion operation.

[0117] Optionally, the container group manager operation module includes: A first container group manager operation submodule, configured for the container group management component to determine, when the operation type of the container group operation is an update operation, whether the operation target of the container group operation is the container group in the target node according to the container group information; A second container group manager operation submodule, configured for the container group management component to determine whether a deletion timestamp corresponding to the container group is nil when the operation target is a container group in the target node; A third container group manager operation submodule, configured for the container group management component to replace the container group number in the container group operation with the container group number corresponding to the container group when the deletion timestamp is not nil; a fourth container group manager operation submodule, configured for the container group management component to determine, according to the container group information, whether the operation target of the container group operation is the container group in the target node when the operation type of the container group is a deletion operation; a fifth container group manager operation submodule, configured for the container group management component to replace the container group number in the container group operation with the container group number corresponding to the container group when the operation target is the container group in the target node; a sixth container group manager operation submodule, configured for the container group management component to transmit the container group operation to the target node; The seventh container group manager operation submodule is configured to allow the container group management component to release the container group operation when the operation target is not the container group in the target node.

[0118] Based on the same inventive concept, another embodiment of the present application provides a readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps in the node migration method described in any of the above embodiments of the present application.

[0119] Based on the same inventive concept, another embodiment of the present application provides an electronic device, Fig.10 It is a schematic diagram of an electronic device 1000 proposed in one embodiment of the present application, including a memory 1001, a processor 1002 and a computer program stored in the memory and executable on the processor, and when the processor is executed, the steps in the node migration method described in any of the above embodiments of the present application are implemented.

[0120] As for the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0121] The various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referenced to each other.

[0122] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, devices, or computer program products. Therefore, the embodiments of the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the embodiments of the present application may adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program codes.

[0123] The embodiments of the present application are described with reference to the flowcharts and / or block diagrams of the methods, terminal devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing terminal device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing terminal device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0124] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing terminal device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce a manufactured product including an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0125] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal device so that a series of operating steps are executed on the computer or other programmable terminal device to produce a computer-implemented process, thereby providing instructions for executing on the computer or other programmable terminal device to implement the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0126] Although the preferred embodiments of the present application have been described, those skilled in the art may make additional changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the embodiments of the present application.

[0127] Finally, it should be noted that, in this article, relational terms such as first and second, etc. are only used 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 terminal 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 terminal 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 terminal device including the elements.

[0128] The node migration method, device, equipment and storage medium provided by the present application are introduced in detail above. Specific examples are used in this article to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method of the present application and its core idea; at the same time, for general technical personnel in this field, according to the idea of ​​the present application, there will be changes in the specific implementation method and application scope. In summary, the content of this specification should not be understood as a limitation on the present application.

Claims

1. A node migration method, characterized in that: The method comprises: The container platform sends the container group information of the container group in the target node in the first cluster to the second cluster; The container platform migrates the target node from the first cluster to the second cluster; The controller in the second cluster sends a container group creation request for the target node to the central node of the second cluster according to the container group information, listens to the container group operation initiated by the container platform, and performs the corresponding operation; The container group management component in the central node intercepts the container group creation request and receives the container group operation; The container group management component processes the container group operation according to the operation target and the operation type of the container group operation, so that the container group runs normally in the target node.

2. The node migration method according to claim 1, characterized in that: Before the controller in the second cluster sends a container group creation request for the target node to the central node of the second cluster according to the container group information, the method further includes: The container platform queries a database of the first cluster for a label corresponding to the target node in the first cluster; The container platform adds the label to the target node in the second cluster; When the tag is detected, the controller determines that the target node joins the second cluster.

3. The node migration method according to claim 1, characterized in that: The method further includes: the target node reporting container group status information to the central node when migrating to the second cluster; The central node queries the database of the second cluster for corresponding data of the container group according to the container group name included in the container group status information; When the central node cannot find the corresponding data in the database of the second cluster, the central node sends a deletion command to the target node; The container group management component intercepts the deletion command.

4. The node migration method according to claim 1, characterized in that: The container platform sends container group information of the container group in the target node in the first cluster to the second cluster, including: The container platform stores the container group information in a container group configuration file, wherein the container group information includes at least each container group name in the target node and a corresponding node name, each container group name in the target node and a corresponding container group number, and all container group names corresponding to the target node; The container platform sends the container group configuration file to the second cluster.

5. The node migration method according to claim 1, characterized in that: The container platform migrates the target node from the first cluster to the second cluster, including: The container platform establishes a network connection between the target node and the second cluster; The container platform adds the target node to the whitelist of the firewall of the second cluster; The container platform backs up the certificate and configuration file of the target node in the first cluster; The container platform obtains authentication information from the second cluster; When the container platform obtains the authentication information, writing the network address of the central node of the second cluster into the configuration file; The container platform restarts the container group management component in the target node to migrate the target node from the first cluster to the second cluster.

6. The node migration method according to claim 1, characterized in that: The controller in the second cluster sends a container group creation request for the target node to the central node of the second cluster according to the container group information, listens to the container group operation initiated by the container platform, and performs corresponding operations, including: The controller determines, when detecting that the target node joins the second cluster, whether a node name of the target node matches a node name stored in the container group information; The controller determines, when a node name of the target node matches a node name stored in the container group information, whether the container group creation request has been sent to the target node; When determining that the container group creation request has not been sent to the target node, the controller queries the container group information for a container group name corresponding to the target node; The controller sends the container group creation request to the central node, where the name field in the container group creation request is the container group name; The controller determines, when monitoring that the container group operation is an update operation, whether a deletion timestamp corresponding to the container group is nil; The controller deletes the container group information if the deletion timestamp is not nil; The controller deletes the container group information when it is detected that the container group operation is a deletion operation.

7. The node migration method according to claim 1, characterized in that: The container group management component processes the container group operation according to the operation target and the operation type of the container group operation, including: The container group management component determines, if the operation type of the container group operation is an update operation, whether the operation target of the container group operation is the container group in the target node according to the container group information; The container group management component determines, when the operation target is a container group in the target node, whether a deletion timestamp corresponding to the container group is nil; The container group management component replaces the container group number in the container group operation with the container group number corresponding to the container group when the deletion timestamp is not nil; The container group management component determines, if the operation type of the container group is a deletion operation, whether the operation target of the container group operation is the container group in the target node according to the container group information; The container group management component replaces the container group number in the container group operation with the container group number corresponding to the container group when the operation target is the container group in the target node; The container group management component transmits the container group operation to the target node; The container group management component releases the container group operation when the operation target is not the container group in the target node.

8. A node migration device, characterized in that: The device comprises: A container group information sending module, used for the container platform to send the container group information of the container group in the target node in the first cluster to the second cluster; A node migration module, used by the container platform to migrate the target node from the first cluster to the second cluster; A controller operation module, configured for the controller in the second cluster to send a container group creation request for the target node to the central node of the second cluster according to the container group information, and to listen to the container group operation initiated by the container platform and perform corresponding operations; An operation interception module, used for the container group management component in the central node to intercept the container group creation request and receive the container group operation; The container group manager operation module is used for the container group management component to process the container group operation according to the operation target and operation type of the container group operation, so that the container group can run normally in the target node.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps in the method according to any one of claims 1 to 7 are implemented.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 7 are implemented.

Images