A kubernetes quick migration method, device and medium

Abstract

The application discloses a kubernetes quick migration method and device in case of failure and a medium. The method comprises the following steps: in advance, a container copy in a cold backup state is prepared on each alternative node; real-time dynamic failure scheduling prediction is performed on each node in the cluster; when a node in the cluster fails, IP traffic is switched from the failed node to an alternative node according to the dynamic failure scheduling prediction, the container copy of the alternative node is switched from the cold backup state to the hot backup state, and the alternative node becomes a working node. The application analyzes the whole migration scheduling process, optimizes and reduces the actual migration process through distributed redundant copy pre-preparation, dynamic failure scheduling prediction and atomic-level scheduling, can optimize the time consumption of cluster failure migration to less than 200 ms, and significantly improves the performance of the kubernetes cluster.

Description

Technical Field

[0001] This invention belongs to the field of Kubernetes technology, specifically relating to a method, device, and medium for rapid migration during Kubernetes outages. Background Technology

[0002] When migrating an existing Kubernetes cluster after a failure, multiple interactions between the control plane and the data plane are required. After a failure event is triggered, the process involves the replica controller generating a new container replica, the scheduler scheduling the new container replica, selecting a suitable node, the node controller listening for events, and deploying the new replica locally. These steps require multiple interactions with the ETCD database, all of which incur time consumption.

[0003] The process following the aforementioned outage is too time-consuming: the current migration scheduling process involves multiple data interactions between several components, resulting in a lengthy process that takes more than 1 second. This cannot meet the requirements in measurement and control systems, industrial automation, edge computing, industrial simulation, and some business scenarios that demand ultimate performance. Summary of the Invention

[0004] To overcome the aforementioned technical deficiencies, this invention provides a method, device, and medium for rapid migration of Kubernetes after downtime. By analyzing the entire migration scheduling process, the actual migration process is significantly optimized and reduced through distributed redundant replica pre-provisioning, dynamic downtime scheduling prediction, and atomic scheduling.

[0005] To address the aforementioned problems, in a first aspect, this invention provides a method for rapid migration during Kubernetes crashes, comprising:

[0006] Prepare container copies in a cold standby state in advance on each alternative node;

[0007] Real-time dynamic downtime scheduling and prediction for each node in the cluster;

[0008] When a node in the cluster fails, IP traffic is switched from the failed node to a backup node based on dynamic failure scheduling prediction. The container replica of the backup node is switched from cold standby to hot standby, and the backup node becomes a worker node.

[0009] Furthermore, the provision of container replicas in a cold standby state on each candidate node in advance includes:

[0010] The replica controller generates both hot standby and cold standby container replicas simultaneously.

[0011] The scheduler schedules the container replica in the hot standby state to the worker node according to the conventional scheduling logic, and schedules the container replica in the cold standby state to the standby node;

[0012] The node controller of the standby node starts the container replica in the cold standby state, and keeps the container replica in a silent state;

[0013] The SDN controller of the standby node adds redundant SDN flow table data to the container replica in the cold standby state, and keeps the flow table rule silent and does not access IP traffic.

[0014] Further, the advance preparation of the container replica in the cold standby state on each standby node further comprises:

[0015] The node controller of the worker node starts the container replica in the hot standby state and allocates an IP address to it;

[0016] The SDN controller of the worker node adds SDN flow table data to the container replica in the hot standby state and accesses IP traffic to the container replica in the hot standby state.

[0017] Further, the real-time dynamic downtime scheduling prediction for each node in the cluster comprises:

[0018] The pre-scheduling controller establishes a dynamic downtime scheduling prediction table;

[0019] Each node controller listens to the API-Server to obtain container data that may be migrated to the node and the current running nodes of the containers, and maintains a local downtime monitoring table;

[0020] When the running relationship between nodes and containers in the cluster changes, the pre-scheduling controller adjusts the dynamic downtime scheduling prediction table data, and each node controller synchronously adjusts the local downtime monitoring table data and changes the monitoring behavior.

[0021] Further, when a node in the cluster goes down, according to the dynamic downtime scheduling prediction, the IP traffic is switched from the down node to a standby node, the container replica of the standby node is switched from the cold standby state to the hot standby state, and the standby node becomes a worker node, comprising:

[0022] The node controller of a certain standby node performs downtime monitoring on a plurality of target nodes according to the local downtime monitoring table;

[0023] When a certain target node is monitored to be down, the node controller of the standby node switches the local container replica from the cold standby state to the hot standby state according to the predicted container deployment requirements borne by itself;

[0024] The node controller notifies the SDN controller to switch the flow table data and switch the IP traffic on the down node to the container replica in the hot standby state on the node.

[0025] In a second aspect, the present invention provides a computer device including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the method described above.

[0026] Thirdly, the present invention provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the above-described method.

[0027] Compared with the prior art, the present invention has the following beneficial effects:

[0028] This invention discloses a method, device, and medium for rapid migration of Kubernetes outages. The method includes: pre-preparing container replicas in a cold standby state on each backup node; performing real-time dynamic outage scheduling prediction for each node in the cluster; when a node in the cluster goes down, switching IP traffic from the downed node to a backup node based on the dynamic outage scheduling prediction, and switching the container replicas of the backup node from a cold standby state to a hot standby state, making the backup node a working node. The method proposed in this invention analyzes the entire migration scheduling process, and through distributed redundant replica pre-preparation, dynamic outage scheduling prediction, and atomic scheduling, it significantly optimizes and reduces the actual migration process, reducing the cluster outage migration time to less than 200ms, and significantly improving Kubernetes cluster performance. Attached Figure Description

[0029] The specific embodiments of the present invention will be further described in detail below with reference to the accompanying drawings, wherein:

[0030] Figure 1 This is a flowchart of the Kubernetes fast migration method described in Example 1;

[0031] Figure 2 This is a schematic diagram of step S2 of the Kubernetes fast migration method described in Example 1;

[0032] Figure 3 This is a schematic diagram of the computer device described in Example 2. Detailed Implementation

[0033] The preferred embodiments of the present invention will be described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit the present invention.

[0034] Example 1

[0035] This embodiment discloses a method for rapid migration during Kubernetes crashes, such as...Figure 1 , comprising:

[0036] S1, in advance, place a container copy in a cold backup state at each alternative node.

[0037] Specifically, step S1 includes:

[0038] The replica controller simultaneously generates a container copy in a hot backup state and a container copy in a cold backup state.

[0039] The scheduler schedules the container copy in a hot backup state to the worker node and the container copy in a cold backup state to the alternative node according to the conventional scheduling logic.

[0040] The node controller of the worker node starts the container copy in a hot backup state and assigns an IP address to it according to the conventional scheduling logic.

[0041] The SDN controller of the worker node adds SDN flow table data for the container copy in a hot backup state and accesses IP traffic to the container copy in a hot backup state.

[0042] The node controller of the alternative node starts the container copy in a cold backup state and keeps the container copy in a silent state. The node controller of the alternative node also assigns an IP address to the container copy in a cold backup state, which is consistent with the IP address obtained by the container copy in a hot backup state in the worker node.

[0043] The SDN controller of the alternative node adds redundant SDN flow table data for the container copy in a cold backup state and keeps the flow table rule silent and does not access IP traffic.

[0044] S2, real-time dynamic downtime scheduling prediction is performed on each node in the cluster, providing real-time scheduling decision reference for subsequent node downtime scheduling.

[0045] In one embodiment, as Figure 2 , step S2 includes:

[0046] S21, the pre-scheduling controller establishes a dynamic downtime scheduling prediction table. Specifically, the pre-scheduling controller monitors the distribution data of each container copy in the cluster in real time, calculates the containers that need to be migrated when each worker node is down under the current deployment state, and the migration target nodes of these containers.

[0047] S22, each node controller listens to the API-Server to obtain container data that can be migrated to the node and the current running node of the containers, and maintains a local downtime monitoring table.

[0048] S23, each node controller listens to the state of the corresponding node according to the local downtime monitoring table.

[0049] S24, when the running relationship between the nodes in the cluster and the containers changes, the pre-scheduling controller adjusts the dynamic downtime scheduling prediction table data, and each node controller synchronously adjusts the local downtime monitoring table data to change the monitoring behavior. For example, when a certain standby node is no longer a standby node for all containers on a certain worker node, the node controller of the standby node adjusts the local downtime monitoring table and stops monitoring the worker node. Similarly, if a certain standby node is newly added as a standby node for any container on a new node that has not been monitored before, the node controller of the standby node adjusts the local downtime monitoring table and adds monitoring of the node.

[0050] S3, when a node in the cluster goes down, IP traffic is switched from the down node to a certain standby node according to the dynamic downtime scheduling prediction, the container replica of the standby node is switched from the cold standby state to the hot standby state, and the standby node becomes a worker node.

[0051] Specifically, step S3 includes:

[0052] The node controller of a certain standby node performs downtime monitoring on a plurality of target nodes according to the local downtime monitoring table.

[0053] When a certain target node is monitored to be down, the node controller of the standby node switches the local container replica from the cold standby state to the hot standby state according to the predicted container deployment requirements borne by itself.

[0054] The node controller notifies the SDN controller to switch the flow table data, and switches the IP traffic on the down node to the container replica in the hot standby state on the node.

[0055] Both the downtime monitoring and the downtime scheduling in the open source solution are monitored and operated by the control plane. The method provided by the application completes the monitoring of the scheduled down node, the triggering and execution of the scheduled down node by the node controller at the bottom layer of the cluster scheduling, realizes atomic-level scheduling, and reduces the path of downtime monitoring and downtime scheduling.

[0056] Compared with the multiple scheduling processes from the control plane to the data plane in the existing downtime migration event, the method provided by the application completes the scheduling process at the node level, realizes atomic-level scheduling, and realizes a substantial optimization of the time consumption of the entire migration process. By adopting distributed redundant replica pre-provisioning, dynamic downtime scheduling prediction, and atomic-level scheduling, more efficient and rapid downtime migration capability is realized, so that the time required for downtime migration is only the time of switching the container replica and switching the flow table data in atomic-level scheduling. The downtime migration time of more than 1s can be reduced to within 200ms, and the performance of kubernetes is significantly improved.

[0057] In addition, the container replica in the cold standby state is pre-provisioned in each standby node in advance, which does not occupy actual resources and does not require additional resource overhead.

[0058] Embodiment 2

[0059] This embodiment provides a computer device, which can be a server or a terminal integrated with a scheduler, and an internal structure diagram thereof can be as shown in the figure. Figure 3 The computer device includes a processor, a memory and a network interface connected through a system bus. The processor of the computer device is configured to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for running the operating system and the computer program in the non-volatile storage medium. The database of the computer device is configured to store data such as a mapping relationship between a shared video memory area and a virtual machine and a total load of the virtual machine. The network interface of the computer device is configured to communicate with an external terminal through a network connection. The computer program is executed by the processor to implement a kubernetes fast migration method in case of a failure.

[0060] Those skilled in the art can understand that Figure 3 The structure shown in the figure is only a block diagram of part of the structure related to the scheme of the present application, and does not constitute a limitation on the computer device to which the scheme of the present application is applied. The specific computer device can include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0061] In one embodiment, a computer device is provided, including a memory and a processor, the memory storing a computer program, and the processor implementing the following steps when executing the computer program:

[0062] A container replica in a cold standby state is prepared in advance on each alternative node;

[0063] Real-time dynamic failure scheduling prediction is performed on each node in the cluster;

[0064] When a node in the cluster fails, the IP traffic is switched from the failed node to an alternative node according to the dynamic failure scheduling prediction, the container replica of the alternative node is switched from the cold standby state to the hot standby state, and the alternative node becomes a working node.

[0065] In one of the embodiments, the processor further implements the following steps when executing the computer program:

[0066] The replica controller simultaneously generates a container replica in a hot standby state and a container replica in a cold standby state;

[0067] The scheduler schedules the container replica in the hot standby state to a working node and schedules the container replica in the cold standby state to an alternative node according to the conventional scheduling logic;

[0068] The node controller of the standby node starts the container replica in cold standby state and keeps the container replica in silence;

[0069] The SDN controller of the standby node adds redundant SDN flow table data for the container replica in cold standby state and keeps the flow table rules silent, not accessing IP traffic.

[0070] In one of the embodiments, the processor, when executing the computer program, also implements the following steps:

[0071] The node controller of the worker node starts the container replica in hot standby state and assigns an IP address to it;

[0072] The SDN controller of the worker node adds SDN flow table data for the container replica in hot standby state and accesses IP traffic to the container replica in hot standby state.

[0073] In one of the embodiments, the processor, when executing the computer program, also implements the following steps:

[0074] The pre-scheduling controller establishes a dynamic downtime scheduling prediction table;

[0075] Each node controller listens to the API-Server, obtains container data that can be migrated to the node and the current running nodes of the containers, and maintains a local downtime monitoring table;

[0076] When the node and container running relationship of the cluster changes, the pre-scheduling controller adjusts the data of the dynamic downtime scheduling prediction table, each node controller synchronously adjusts the data of the local downtime monitoring table, and changes the monitoring behavior.

[0077] In one of the embodiments, the processor, when executing the computer program, also implements the following steps:

[0078] The node controller of a certain standby node performs downtime monitoring on a plurality of target nodes according to the local downtime monitoring table;

[0079] When a certain target node is monitored to be down, the node controller of the standby node switches the local container replica from cold standby state to hot standby state according to the predicted container deployment requirements borne by itself;

[0080] The node controller notifies the SDN controller to switch the flow table data and switch the IP traffic on the down node to the container replica in hot standby state on the node.

[0081] Embodiment 3

[0082] The embodiment provides a computer readable storage medium, which stores a computer program, and the computer program, when executed by a processor, implements the following steps:

[0083] Pre-allocate container replicas in cold standby state in each candidate node;

[0084] Make real-time dynamic downtime scheduling prediction for each node in the cluster;

[0085] When a node in the cluster goes down, switch IP traffic from the down node to a candidate node, switch the container replica of the candidate node from cold standby state to hot standby state, and make the candidate node a working node.

[0086] In one embodiment, the computer program, when executed by the processor, further implements the following steps:

[0087] The replica controller generates both the container replica in hot standby state and the container replica in cold standby state at the same time;

[0088] The scheduler schedules the container replica in hot standby state to the working node and schedules the container replica in cold standby state to the candidate node according to the conventional scheduling logic;

[0089] The node controller of the candidate node starts the container replica in cold standby state and keeps the container replica in a silent state;

[0090] The SDN controller of the candidate node adds redundant SDN flow table data to the container replica in cold standby state and keeps the flow table rules silent, not accessing IP traffic.

[0091] In one embodiment, the computer program, when executed by the processor, further implements the following steps:

[0092] The node controller of the working node starts the container replica in hot standby state and assigns an IP address to it;

[0093] The SDN controller of the working node adds SDN flow table data to the container replica in hot standby state and accesses IP traffic to the container replica in hot standby state.

[0094] In one embodiment, the computer program, when executed by the processor, further implements the following steps:

[0095] The pre-scheduling controller establishes a dynamic downtime scheduling prediction table;

[0096] Each node controller listens to the API-Server to obtain container data that may be migrated to the node and the current running nodes of the containers, and maintains a local downtime monitoring table;

[0097] When there is a change in the running relationship between nodes and containers in the cluster, the pre-scheduling controller adjusts the dynamic downtime scheduling prediction table data, and each node controller synchronously adjusts the local downtime monitoring table data and changes the monitoring behavior.

[0098] In one embodiment, the computer program, when executed by the processor, further implements the following steps:

[0099] The node controller of the certain alternative node performs down monitoring on a plurality of target nodes according to the local down monitoring table;

[0100] When a certain target node is monitored to be down, the node controller of the alternative node switches the local container replica from the cold backup state to the hot backup state according to the prediction container deployment requirement borne by the node controller;

[0101] The node controller notifies the SDN controller to switch the flow table data, and switches the IP flow on the down node to the container replica in the hot backup state on the node.

[0102] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiments can be completed by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer readable storage medium. When the computer program is executed, it can include the processes of the above-mentioned embodiments. In the embodiments provided in the present application, any reference to memory, database or other medium can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (Read-Only Memory, ROM), magnetic tape, floppy disk, flash memory, optical storage, high-density embedded non-volatile memory, resistive memory (ReRAM), magnetoresistive memory (Magnetoresistive Random Access Memory, MRAM), ferroelectric memory (Ferroelectric Random Access Memory, FRAM), phase change memory (Phase Change Memory, PCM), graphene memory, etc. Volatile memory can include random access memory (Random Access Memory, RAM) or external cache memory, etc. As an illustration but not limitation, RAM can be in various forms, such as static random access memory (Static Random Access Memory, SRAM) or dynamic random access memory (Dynamic Random Access Memory, DRAM), etc. The database involved in the embodiments provided in the present application can include at least one of a relational database and a non-relational database. The non-relational database can include a distributed database based on blockchain, etc., but is not limited thereto. The processor involved in the embodiments provided in the present application can be a general-purpose processor, a central processing unit, a graphics processing unit, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, etc., but is not limited thereto.

[0103] Any technical features in the above embodiments can be combined, and for the sake of brevity, not all possible combinations are described above. Any combination of the technical features is deemed to be within the scope of the present disclosure.

[0104] The above embodiments only express several implementation manners of the present application, and the description is relatively specific and detailed, but it should not be understood as a limitation on the patent scope of the present application. It should be pointed out that, for ordinary skilled persons in the art, several modifications and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the appended claims.

[0105] The above is only a preferred embodiment of the present application, and does not limit the present application in any form. Any modification, equivalent change and modification made to the above embodiments according to the technical essence of the present application, without departing from the technical solution content of the present application, still belongs to the scope of the technical solution of the present application.

Claims

1. A method for rapid migration during Kubernetes outages, characterized in that, include: Prepare container copies in a cold standby state in advance on each alternative node; The provision of container replicas in a cold standby state on each candidate node in advance includes: The replica controller generates both hot standby and cold standby container replicas simultaneously. The scheduler schedules container replicas in hot standby mode to worker nodes and container replicas in cold standby mode to backup nodes according to the conventional scheduling logic. The node controller of the alternative node starts the container replica in cold standby state and keeps the container replica in a silent state. The SDN controller of the standby node adds redundant SDN flow table data to the container replicas in cold standby state and keeps the flow table rules silent, without accessing IP traffic. Real-time dynamic downtime scheduling prediction is performed for each node in the cluster; the real-time dynamic downtime scheduling prediction for each node in the cluster includes: The pre-scheduling controller establishes a dynamic downtime scheduling prediction table; Each node controller listens to the API-Server to obtain container data that may be migrated to this node and the current running nodes of these containers, and maintains the local downtime monitoring table; When the running relationship between nodes and containers changes in the cluster, the pre-scheduling controller adjusts the dynamic downtime scheduling prediction table data, and each node controller synchronously adjusts the local downtime monitoring table data and changes the monitoring behavior. When a node in the cluster fails, IP traffic is switched from the failed node to a backup node based on dynamic failure scheduling prediction. The container replica of the backup node is switched from cold standby to hot standby, and the backup node becomes a worker node.

2. The Kubernetes crash rapid migration method according to claim 1, characterized in that, The provision of container replicas in a cold standby state on each candidate node in advance also includes: The node controller of the worker node starts a hot standby container replica and assigns it an IP address; The SDN controller on the worker node adds SDN flow table data to the container replica in hot standby mode, allowing IP traffic to be routed to the container replica in hot standby mode.

3. The Kubernetes crash rapid migration method according to claim 2, characterized in that, When a node in the cluster fails, based on dynamic failure scheduling predictions, IP traffic is switched from the failed node to a backup node. The container replicas on this backup node are switched from cold standby to hot standby, and this backup node becomes a working node. The node controller of a candidate node monitors the downtime of several target nodes based on the local downtime monitoring table. When a target node is detected to be down, the node controller of the alternative node switches the local container replica from cold standby to hot standby based on the predicted container deployment requirements it carries. The node controller notifies the SDN controller to switch flow table data, switching IP traffic on the failed node to the container replica in hot standby mode on the local node.

4. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 3.

5. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 3.

Images