A method for electing master and standby nodes based on Kubernetes distributed locks

Abstract

This invention relates to the field of microservices technology and provides a method for electing master and standby nodes based on Kubernetes distributed locks. The method includes: generating a unique identifier for each node based on a timestamp during node initialization; electing a node as the master node from the initialized nodes based on the identifier; locking the elected master node using a distributed lock; and continuously monitoring the state of the distributed lock and updating the master node based on the monitored state. The method for electing master and standby nodes based on Kubernetes distributed locks according to exemplary embodiments of this invention can improve the high availability, load balancing, and automation of applications.

Description

Technical Field

[0001] This invention relates to the field of microservices technology, and in particular to a method for electing master and standby nodes based on Kubernetes distributed locks. Background Technology

[0002] In the Kubernetes platform, the election of microservices is typically handled by the application's own logic, rather than by the Kubernetes platform. For example, in Kubernetes, a microservice is deployed using a Deployment object with multiple replicas. When a replica fails, Kubernetes automatically starts a new one to replace it. However, if these replicas require some form of coordination or election, since Kubernetes itself doesn't handle the election between microservices but leaves this task to the application itself, this logic needs to be implemented within the application. Distributed algorithms are typically used to implement elections, running containerized applications with multiple replicas in Kubernetes; however, this approach is labor-intensive and difficult to implement.

[0003] Therefore, how to provide a method for implementing high-availability master-slave election, so that all microservices can quickly implement their own high-availability functions in this way, thereby improving the high availability and scalability of microservices, has become an urgent technical problem to be solved. Summary of the Invention

[0004] In view of this, in order to overcome the shortcomings of the prior art, the present invention aims to provide a method for electing master and standby nodes based on Kubernetes distributed locks, which can be used to improve the high availability and scalability of microservices.

[0005] This invention provides a method for electing master and standby nodes based on Kubernetes distributed locks, comprising:

[0006] Step S1: When initializing the startup node, generate a unique identifier for each node based on the timestamp;

[0007] Step S2: Elect a node as the master node from the nodes that were initialized based on the identification code;

[0008] Step S3: Use a distributed lock to lock the elected master node;

[0009] Step S4: Continuously monitor the state of the distributed lock in real time and update the master node according to the monitored state.

[0010] As a preferred embodiment of the present invention, step S2 includes: obtaining the timestamp of each node through the identification code, obtaining the creation time of the node from the obtained timestamp, electing the node with the earliest creation time as the master node, and using the remaining nodes as backup nodes.

[0011] As a preferred embodiment of the present invention, step S2 further includes: when there are multiple nodes with the earliest creation time, electing one node as the master node from among the multiple nodes with the same creation time, and all other nodes as backup nodes.

[0012] As a preferred embodiment of the present invention, step S3 includes: setting the identification code of the elected master node as the identification code of the distributed lock, and updating the state of the distributed lock to the locked state.

[0013] As a preferred embodiment of the present invention, the distributed lock in step S3 is a resource object stored in the Etcd key-value storage system, wherein the resource object includes a ConfigMap resource object, a Lease resource object, and a Secret resource object.

[0014] As a preferred embodiment of the present invention, step S4 includes:

[0015] All backup nodes, except the master node, continuously monitor the state of the distributed lock in real time.

[0016] When the backup node detects that the distributed lock is in a locked state, the state of the backup node is maintained.

[0017] When a standby node detects that the distributed lock is in an unlocked state, it selects a node from the standby nodes to match the distributed lock based on the identification code, and determines whether to update the master node based on the matching result.

[0018] As a preferred embodiment of the present invention, step S4, selecting a node from the backup nodes to match the distributed lock based on the identification code, includes: obtaining the timestamp of each backup node through the identification code, obtaining the creation time of the backup node from the obtained timestamp, and matching the backup node with the earliest creation time with the distributed lock.

[0019] As a preferred embodiment of the present invention, step S4, selecting a node from the backup nodes to match the distributed lock based on the identification code, further includes: when there are multiple backup nodes with the earliest creation time, selecting a node from the multiple backup nodes with the same creation time to match the distributed lock.

[0020] As a preferred embodiment of the present invention, step S4, determining whether to update the master node based on the matching result, includes:

[0021] When the identification code of the elected backup node matches the identification code of the distributed lock, the backup node is updated to the new master node, and the distributed lock is used to lock the new master node.

[0022] If the identifier of the elected backup node does not match the identifier of the distributed lock, maintain the state of the backup node and continuously monitor the state of the distributed lock in real time.

[0023] Finally, the present invention also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the above-described method for electing master and standby nodes based on Kubernetes distributed locks.

[0024] The present invention provides a method for electing master and standby nodes based on Kubernetes distributed locks, which has the following advantages:

[0025] 1. It ensures high availability of the application. When the master node Pod fails, it helps Kubernetes determine which existing Pod is the most suitable to replace the failed master Pod.

[0026] 2. It can dynamically distribute traffic to available Pods, ensuring load balancing across Pods and preventing performance degradation caused by an overloaded Pod.

[0027] 3. The system can select the most suitable Pod based on pre-set rules and strategies, reducing the burden of manual intervention and improving the stability and reliability of the system. Attached Figure Description

[0028] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0029] Figure 1 This is a flowchart illustrating a method for electing master and backup nodes based on a Kubernetes distributed lock, as an exemplary first embodiment of the present invention.

[0030] Figure 2 This is a schematic diagram of a method for electing master and backup nodes based on a Kubernetes distributed lock, which is an exemplary fourth embodiment of the present invention.

[0031] Figure 3 This is a schematic diagram of the structure of the device provided by the present invention. Detailed Implementation

[0032] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0033] It should be noted that, in the absence of conflict, the following embodiments and features can be combined with each other; and, based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0034] It should be noted that various aspects of embodiments within the scope of the appended claims are described below. It will be apparent that the aspects described herein can be embodied in a wide variety of forms, and any particular structure and / or function described herein is merely illustrative. Based on this disclosure, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects set forth herein can be used to implement the device and / or practice the method. Additionally, this device and / or method can be implemented using structures and / or functionalities other than one or more of the aspects set forth herein.

[0035] The technical principle of this invention is as follows:

[0036] Distributed locks are implemented using resource objects stored in the Etcd key-value store system. Specifically, this can be achieved using various resources on Kubernetes, such as configmap, lease, and secret stored in Etcd; any one of these can be chosen. The main purpose is to store two key pieces of information: the lock's identification code (ID) and its state. Each node can access all the data it stores in real time. Applications distributed across different nodes can access the same data, thus solving the problem of distributed data inconsistencies.

[0037] Each node competes for the distributed lock through an election mechanism. The node that wins the distributed lock first is promoted to master node, and the rest become backup nodes. The distributed lock can store the lock identification code and the lock state. The lock identification code is used to identify the lock. The lock state has two types: locked and unlocked. During initialization, the lock is in the unlocked state. When a node wins the election to become the master node, it sets the lock state to locked. At this time, other nodes are in a waiting state to be elected.

[0038] The terms used in the following embodiments are explained below:

[0039] Kubernetes is an open-source container orchestration platform initiated and maintained by Google. It aims to simplify the deployment, scaling, and management of containerized applications. It provides a declarative way to define operations such as deployment, service discovery, load balancing, autoscaling, and automatic fault recovery for containerized applications.

[0040] Etcd is a highly available, distributed key-value store designed for building distributed systems. It is typically used as the underlying data storage for Kubernetes clusters, storing cluster configuration information, service discovery information, and more.

[0041] ConfigMap: A resource object in Kubernetes used to separate configuration data from applications and store it as key-value pairs. ConfigMaps can store different types of data, such as strings, integers, or files. This data can be used by containerized applications without being hard-coded into the container image.

[0042] Lease: A resource object in Kubernetes used to hold a specific name for a period of time. Lease can be used to ensure that only one process or instance can access certain shared resources, thereby avoiding race conditions.

[0043] Secret: A resource object in Kubernetes used to store sensitive data such as passwords, API keys, and certificates. Similar to ConfigMap, Secret can also store different types of data, such as strings, integers, or files.

[0044] Figure 1 This is a flowchart illustrating a method for electing master and backup nodes based on a Kubernetes distributed lock according to an exemplary first embodiment of the present invention. Figure 1 As shown, the method in this embodiment includes:

[0045] Step S1: When initializing the startup node, generate a unique identifier for each node based on the timestamp;

[0046] Step S2: Elect a node as the master node from the nodes that were initialized based on the identification code;

[0047] Step S3: Use a distributed lock to lock the elected master node;

[0048] Step S4: Continuously monitor the state of the distributed lock in real time and update the master node according to the monitored state.

[0049] The second exemplary embodiment of the present invention provides a method for electing master and standby nodes based on Kubernetes distributed locks. This embodiment is... Figure 1 A preferred embodiment of the method shown.

[0050] In practical applications, step S2 of this embodiment is implemented as follows: The timestamp of each node is obtained through the identification code; the creation time of the node is obtained from the obtained timestamps; the node with the earliest creation time is elected as the master node, and the remaining nodes are designated as backup nodes. When multiple nodes have the earliest creation time, one node is elected as the master node from among the nodes with the same creation time, and all other nodes are designated as backup nodes.

[0051] The third exemplary embodiment of the present invention provides a method for electing master and standby nodes based on Kubernetes distributed locks. This embodiment is... Figure 1 A preferred embodiment of the method shown.

[0052] In practical applications, step S3 of this embodiment is implemented as follows: the identification code of the elected master node is set as the identification code of the distributed lock, and the state of the distributed lock is updated to the locked state. Specifically, the distributed lock in this embodiment is a resource object stored in the Etcd key-value storage system, and the resource object includes a ConfigMap resource object, a Lease resource object, and a Secret resource object.

[0053] Figure 2 This is a schematic diagram illustrating a method for electing master and standby nodes based on a Kubernetes distributed lock according to an exemplary fourth embodiment of the present invention. This embodiment is... Figure 1 A preferred embodiment of the method shown.

[0054] like Figure 2 As shown, step S4 of the method in this embodiment includes:

[0055] All backup nodes, except the master node, continuously monitor the state of the distributed lock in real time.

[0056] When the backup node detects that the distributed lock is in a locked state, the state of the backup node is maintained.

[0057] When a standby node detects that the distributed lock is in an unlocked state, it selects a node from the standby nodes to match the distributed lock based on the identification code, and determines whether to update the master node based on the matching result.

[0058] Specifically, in practical applications, in step S4 of this embodiment, a node is selected from the backup nodes to match the distributed lock based on the identification code, which is implemented in the following way:

[0059] The timestamp of each backup node is obtained through the identification code. The creation time of the backup node is obtained from the obtained timestamp. The backup node with the earliest creation time is matched with the distributed lock.

[0060] When there are multiple backup nodes with the earliest creation time, a node is selected from the multiple backup nodes with the same creation time to be matched with the distributed lock.

[0061] Specifically, in practical applications, step S4 of the method in this embodiment, determining whether to update the master node based on the matching result, includes:

[0062] When the identifier of the elected backup node matches the identifier of the distributed lock, the backup node is updated to become the new master node. The distributed lock is then used to lock the new master node, which is responsible for executing stateful tasks.

[0063] If the identifier of the elected backup node does not match the identifier of the distributed lock, the backup node's state is maintained and the state of the distributed lock is monitored in real time, ready to become the master node at any time.

[0064] like Figure 3 As shown, the present invention also provides a device including a processor 110, a communication interface 120, a memory 130 for storing processor-executable computer programs, and a communication bus 140. The processor 110, communication interface 120, and memory 130 communicate with each other via the communication bus 140. The processor 110 implements the aforementioned method for electing master and standby nodes based on Kubernetes distributed locks by running the executable computer program.

[0065] The computer program in memory 130, when implemented as a software functional unit and sold or used as an independent product, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0066] The system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected based on actual needs to achieve the purpose of this embodiment. Those skilled in the art can understand and implement this without any creative effort.

[0067] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., including several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods of various embodiments or some parts of embodiments.

[0068] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for electing master and standby nodes based on Kubernetes distributed locks, characterized in that, The method includes: Step S1: When initializing the startup node, generate a unique identifier for each node based on the timestamp; Step S2: Elect a node as the master node from the nodes that were initialized based on the identification code; Step S3: Use a distributed lock to lock the elected master node; Step S4: Continuously monitor the state of the distributed lock in real time and update the master node according to the detected state; Step S3 includes: setting the identification code of the elected master node as the identification code of the distributed lock, and updating the state of the distributed lock to the locked state; Step S4 includes: All backup nodes, except the master node, continuously monitor the state of the distributed lock in real time. When the backup node detects that the distributed lock is in a locked state, the state of the backup node is maintained. When a standby node detects that the distributed lock is in an unlocked state, it selects a node from the standby nodes to match the distributed lock based on the identification code, and determines whether to update the master node based on the matching result; In step S4, determining whether to update the master node based on the matching result includes: When the identification code of the elected backup node matches the identification code of the distributed lock, the backup node is updated to the new master node, and the distributed lock is used to lock the new master node. If the identifier of the elected backup node does not match the identifier of the distributed lock, maintain the state of the backup node and continuously monitor the state of the distributed lock in real time.

2. The method for electing master and standby nodes based on Kubernetes distributed locks according to claim 1, characterized in that, Step S2 includes: obtaining the timestamp of each node through the identification code, obtaining the creation time of the node from the obtained timestamp, electing the node with the earliest creation time as the master node, and the remaining nodes as backup nodes.

3. The method for electing master and standby nodes based on Kubernetes distributed locks according to claim 2, characterized in that, Step S2 also includes: when there are multiple nodes with the earliest creation time, elect one node as the master node from among the multiple nodes with the same creation time, and all other nodes as backup nodes.

4. The method for electing master and standby nodes based on Kubernetes distributed locks according to claim 1, characterized in that, The distributed lock in step S3 is a resource object stored in the Etcd key-value storage system, which includes ConfigMap resource objects, Lease resource objects, and Secret resource objects.

5. The method for electing master and standby nodes based on Kubernetes distributed locks according to claim 1, characterized in that, In step S4, a node is selected from the backup nodes to match the distributed lock based on the identification code. This includes: obtaining the timestamp of each backup node through the identification code, obtaining the creation time of the backup node from the obtained timestamp, and matching the backup node with the earliest creation time with the distributed lock.

6. The method for electing master and standby nodes based on Kubernetes distributed locks according to claim 1, characterized in that, In step S4, selecting a node from the backup nodes to match the distributed lock based on the identification code also includes: when there are multiple backup nodes with the earliest creation time, selecting a node from the multiple backup nodes with the same creation time to match the distributed lock.

7. A computer device, characterized in that, The computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the method according to any one of claims 1-6.

Images