Kubernetes cluster construction method and device based on Kube-vip module, electronic equipment, medium and program product

By deploying the Kube-vip module on the control node of the Kubernetes cluster, using the leader-election mechanism to select the main control node and bind the VIP address, the problem of server resource waste and brain split in the existing technology is solved, and Kubernetes services with high availability and load balancing is realized.

CN119629048APending Publication Date: 2025-03-14SHANGHAI INFINIGENCE AI INTELLIGENT TECHNOLOGY CO LTD
View PDF 4 Cites 0 Cited by

Patent Information

Application Number
CN202411772262.X
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2024-12-04
Publication Date
2025-03-14

AI Technical Summary

Technical Problem

When building a highly available Kubernetes cluster, existing technologies such as Keepalived+HAProxy schemes require additional server resources and are prone to split brain phenomena, resulting in unavailability of services.

Method used

Using the construction method based on Kube-vip module, by deploying the Kube-vip module to the control node, using the leader-election mechanism to select the main control node, and binding the VIP address to the main control node, achieving high availability and load balancing.

Benefits of technology

While ensuring load balancing, it provides highly available Kubernetes services, saves server resources, and avoids split brain problems.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119629048A_ABST
    Figure CN119629048A_ABST
Patent Text Reader

Abstract

The invention provides a construction method and device of a Kubernetes cluster based on a Kube-vip module, electronic equipment, a medium and a program product. The invention discloses a Kubernetes cluster construction method based on a Kube-vip module, the Kubernetes cluster comprises a plurality of control nodes and one or more working nodes, the method comprises the following steps: deploying the Kube-vip module to the control nodes of the Kubernetes cluster, but not deploying the Kube-vip module to the working nodes; selecting one of the control nodes as a main control node through a leader-selection mechanism; binding a virtual internet protocol (VIP) address to the master control node, and notifying the unselected control node, the unselected control node being used as a slave control node; when the master control node breaks down, a new master control node is selected from the slave control nodes through a leader-selection mechanism, and the VIP address is bound to the new master control node; and when the fault of the master control node is recovered and a new master control node is found through a leader-selection mechanism, the Kube-vip module of the master control node does not execute the VIP address binding operation any more, so that the master control node is converted into the slave control node.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present application relates to the field of cloud computing technology, and in particular to a method, device, electronic device, medium and program product for constructing a Kubernetes cluster based on a Kube-vip module. Background Art

[0002] With the widespread development of public cloud today, load balancing service has become a basic capability that all cloud service providers must provide. Using load balancing service can easily build various high availability (High Availability, abbreviated as HA, refers to the ability of the system to perform its functions without interruption) services, but in the enterprise's private computer room, there is no load balancing service available. The usual solution is to use Keepalived+HAProxy technology to achieve it. Keepalived is a solution based on VRRP protocol (Virtual Router Redundancy Protocol) to achieve high availability of LVS (Linux Virtual Server, Linux Virtual Server) service, which can solve the single point failure problem of static routing. HAProxy is a solution that can provide high availability, load balancing, and TCP and HTTP-based application proxy. Using Keepalived+HAProxy to achieve load balancing requires at least 2 additional server resources and 1 virtual Internet Protocol (IP, Internet Protocol) address resource. During normal operation, one server is the master role, and the other server is the slave role. The virtual IP is dynamically bound to the master role server. If the network communication between two servers is abnormal, it may cause a brain split (the two servers cannot contact each other and both regard themselves as the master), resulting in service unavailability. It can be seen that the main disadvantages of the Keepalived+HAProxy solution are two points. One is that at least two additional server resources are required, and the other is that when the communication between the master and slave nodes is abnormal, a brain split may occur, resulting in service interruption.

[0003] A high-availability cluster generally means that when any node in the cluster fails, all tasks on the node will be automatically transferred to other normal nodes, and this process does not affect the operation of the entire cluster. Kubernetes (K8s for short) is a container orchestration platform. It is an open source system for automatically deploying, scaling, and managing containerized applications. It is used to manage containerized applications on multiple hosts in a cloud platform. When building a highly available Kubernetes cluster, in order to achieve cluster load balancing, if the above-mentioned Keepalived+HAProxy solution is adopted, kube-apiserver (one of the core components of Kubernetes, responsible for processing application programming interface API requests from inside and outside the cluster) needs to be configured as the backend of HAProxy to provide highly available Kubernetes services. However, such an operation still cannot avoid the above-mentioned shortcomings. Summary of the invention

[0004] The present application overcomes one of the deficiencies of the prior art and provides a method for constructing a Kubernetes cluster based on the Kube-vip module and related equipment, so that high-availability Kubernetes services can be provided while ensuring load balancing, saving server resources and avoiding brain split problems.

[0005] According to one aspect of the present disclosure, a method for constructing a Kubernetes cluster based on a Kube-vip module is proposed, wherein the Kubernetes cluster includes multiple control nodes and one or more working nodes, and the method includes:

[0006] Deploy the Kube-vip module to the control node of the Kubernetes cluster instead of to the working node of the Kubernetes cluster;

[0007] Select one of the control nodes of the Kubernetes cluster as the main control node through the leader-election mechanism of the Kube-vip module;

[0008] Binding a virtual Internet Protocol VIP address to the master control node through the Kube-vip module, and notifying an unselected control node in the Kubernetes cluster, wherein the unselected control node serves as a slave control node;

[0009] When the master control node fails, a new master control node is selected from the slave control nodes through the leader-election mechanism of the Kube-vip module of the slave control node, and the VIP address is bound to the new master control node;

[0010] When the master control node recovers from the fault, when the leader-election mechanism of the Kube-vip module of the master control node finds the existence of the new master control node, the Kube-vip module of the master control node no longer performs the VIP address binding operation, so that the master control node is transformed into a slave control node of the Kubernetes cluster.

[0011] In a possible implementation, deploying the Kube-vip module to the control node of the Kubernetes cluster includes:

[0012] The Kube-vip module is deployed on all control nodes of the Kubernetes cluster in a daemonSet manner, and the daemonSet deployment file is placed in the pod-manifest-path directory of the kubelet component of the working node of the Kubernetes cluster.

[0013] In a possible implementation, selecting one of the control nodes of the Kubernetes cluster as the master control node through the leader-election mechanism of the Kube-vip module includes:

[0014] After the kubelet component is started, the daemonSet service of the Kube-vip module is pulled up, so that the Kube-vip module calls the kube-apiserver interface of the control node of the Kubernetes cluster, thereby realizing the leader-election mechanism of the Kube-vip module.

[0015] In a possible implementation, before deploying the Kube-vip module to the control node of the Kubernetes cluster, the method further includes:

[0016] Initialize the configuration parameters of the Kube-vip module, including working mode parameters, leaderElection parameters, controlplane parameters and taint parameters.

[0017] In a possible implementation, the working mode parameter of the Kube-vip module is specified as an arp parameter representing an address resolution protocol ARP mode.

[0018] According to another aspect of the present disclosure, a device for constructing a Kubernetes cluster based on a Kube-vip module is proposed, wherein the Kubernetes cluster includes a plurality of control nodes and one or more working nodes, and the device includes:

[0019] A deployment module, used to select one of the control nodes of the Kubernetes cluster as the main control node through the leader-election mechanism of the Kube-vip module, instead of deploying the Kube-vip to the working node of the Kubernetes cluster;

[0020] A first selection module, used to select one of the control nodes of the Kubernetes cluster as the main control node through the leader-election mechanism of the Kube-vip module;

[0021] A notification module, used to bind a virtual Internet Protocol VIP address to the master control node through the Kube-vip module, and notify unselected control nodes in the Kubernetes cluster, wherein the unselected control nodes of the Kubernetes cluster serve as slave control nodes;

[0022] A second selection module is used to select a new master control node from the slave control node through the leader-election mechanism of the Kube-vip module of the slave control node when the master control node fails, and bind the VIP address to the new master control node;

[0023] A discovery module is used for, when the master control node recovers from a fault, when the leader-election mechanism of the Kube-vip module of the master control node discovers the existence of the new master control node, the Kube-vip module of the master control node no longer performs the VIP address binding operation, so that the master control node is transformed into a slave control node of the Kubernetes cluster.

[0024] According to another aspect of the present disclosure, a Kubernetes cluster built based on a Kube-vip module is proposed, wherein the Kubernetes cluster includes multiple control nodes and one or more working nodes, and the Kubernetes cluster is constructed by the construction method of a Kubernetes cluster based on a Kube-vip module according to an embodiment of the present application.

[0025] According to another aspect of the present disclosure, an electronic device is proposed, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, a method for constructing a Kubernetes cluster based on the Kube-vip module according to an embodiment of the present application is implemented.

[0026] According to another aspect of the present disclosure, a computer-readable storage medium is proposed, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method for constructing a Kubernetes cluster based on the Kube-vip module according to an embodiment of the present application is implemented.

[0027] According to another aspect of the present disclosure, a computer program product is proposed, which includes a computer program, and when the computer program is executed by a processor, the computer program implements a method for constructing a Kubernetes cluster based on a Kube-vip module according to an embodiment of the present application.

[0028] In the method for constructing a Kubernetes cluster based on the Kube-vip module proposed in the present disclosure, the Kubernetes cluster includes multiple control nodes and one or more working nodes, the Kube-vip module is deployed to the control node of the Kubernetes cluster, but not to the working node of the Kubernetes cluster; one of the control nodes of the Kubernetes cluster is selected as the main control node through the leader-election mechanism of the Kube-vip module; a virtual Internet Protocol VIP address is bound to the main control node through the Kube-vip module, and the unselected control nodes in the Kubernetes cluster are notified, wherein the unselected control nodes As a slave control node; when the master control node fails, a new master control node is selected from the slave control node through the leader-election mechanism of the Kube-vip module of the slave control node, and the VIP address is bound to the new master control node; when the master control node recovers from the failure, when the leader-election mechanism of the Kube-vip module of the master control node finds that there is a new master control node, the Kube-vip module of the master control node no longer performs the VIP address binding operation, so that the master control node is transformed into a slave control node of the Kubernetes cluster, thereby ensuring load balancing while providing high-availability Kubernetes services, saving server resources, and avoiding brain split problems. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] The accompanying drawings are used to provide a further understanding of the technical solution of the present application or the prior art, and constitute a part of the specification. Among them, the accompanying drawings expressing the embodiments of the present application are used together with the embodiments of the present application to explain the technical solution of the present application, but do not constitute a limitation on the technical solution of the present application.

[0030] Figure 1 A flow chart of a method for constructing a Kubernetes cluster based on a Kube-vip module according to an embodiment of the present disclosure is shown;

[0031] Figure 2 A schematic diagram of a Kubernetes cluster based on a Kube-vip module according to an embodiment of the present disclosure is shown;

[0032] Figure 3 A schematic diagram showing a principle when a master control node of a Kubernetes cluster based on a Kube-vip module fails according to an embodiment of the present disclosure;

[0033] Figure 4 A schematic diagram showing the principle of failure recovery of a master control node of a Kubernetes cluster based on a Kube-vip module according to an embodiment of the present disclosure is shown;

[0034] Figure 5 A schematic diagram of the structure of a device for building a Kubernetes cluster based on a Kube-vip module according to an embodiment of the present disclosure is shown;

[0035] Figure 6 An electronic device according to an embodiment of the present disclosure is shown. DETAILED DESCRIPTION

[0036] The following will describe the implementation methods of the present application in detail with reference to the accompanying drawings and embodiments, so that the implementation process of how the present application applies technical means to solve technical problems and achieve corresponding technical effects can be fully understood and implemented accordingly. The embodiments of the present application and the various features in the embodiments can be combined with each other without conflict, and the technical solutions formed are all within the scope of protection of the present application.

[0037] In addition, the steps shown in the flowchart of the accompanying drawings can be executed in a computer such as a set of computer executable instructions. Also, although a logical sequence is shown in the flowchart, in some cases, the steps shown or described can be performed in a sequence different from that here.

[0038] Figure 1 The flowchart of the method for constructing a Kubernetes cluster based on the Kube-vip module according to an embodiment of the present disclosure is shown. Figure 1 As shown, the method may include:

[0039] Step S1: deploy the Kube-vip module to the control node of the Kubernetes cluster instead of deploying it to the working node of the Kubernetes cluster.

[0040] An example of a Kubernetes cluster is Figure 2 shown. Figure 2 A schematic diagram of a Kubernetes cluster based on a Kube-vip module according to an embodiment of the present disclosure is shown. Figure 2 The Kubernetes cluster in shows multiple master nodes (control nodes) and one worker node (working node). Of course, the Kubernetes cluster may also include multiple worker nodes. A Pod can be run on each node in the Kubernetes cluster. Pod is the smallest scheduling unit of Kubernetes. A Pod is a container group that can manage the life cycle of multiple containers. Containers are a new way to deploy applications, with fast and lightweight characteristics. The nodes of a Kubernetes cluster can be virtual machines, physical machines, or resources provided by cloud service providers, etc., which can provide storage resources and computing resources for Pods or cloud resources. The Kubernetes cluster in this application can, for example, be a Kubernetes cluster that can provide high availability for cloud computing (e.g., for distributed training of large models).

[0041] Kube-vip (also referred to as Kube-vip module in this application) is an open source project that provides high availability and load balancing for the inside and outside of the Kubernetes cluster. In order to load balance the Kubernetes cluster and provide high availability services, this application uses Kube-vip to replace the previous Keepalived+HAProxy solution. In an embodiment of the present application, the Kube-vip module is only deployed to the master node (control node) of the Kubernetes cluster, and not to the worker node (working node) of the Kubernetes cluster. Thus, the respective roles of the master node and the worker node can be clarified, while ensuring that the load balancing and high availability of the Kubernetes cluster are achieved without using additional server resources.

[0042] The Kube-vip module supports two working modes: ARP (Address Resolution Protocol) and BGP (Border Gateway Protocol). Among them, ARP can be used to convert a 32-bit IP address into a MAC (Media Access Control) address. When a host needs to communicate with another host, it first needs to know the MAC address of the target host. ARP obtains the MAC address of the target host by sending a broadcast request. BGP is an external gateway protocol used for routing between different autonomous systems. BGP uses path vectors as routing metrics and selects the best path by comparing path attributes. A peer relationship is established between BGP routers, and a routing table is established by exchanging path attributes. Since BGP uses policy routing to control routing selection behavior, it requires support from the router side to meet specific network requirements. In general private enterprises, it is difficult to implement if there are no professional network operation and maintenance personnel. Therefore, in the embodiment of the present application, the ARP mode is used as an example to communicate between LANs, which is simpler, more efficient and easy to deploy. It should be understood that the method according to the embodiment of the present application is not limited to the ARP mode. If the conditions on the router side can be met, the BGP mode can also be used.

[0043] In one example, before deploying the Kube-vip module to the control node of the Kubernetes cluster, for example, the configuration parameters of the Kube-vip module can be initialized first. The configuration parameters can include, for example, working mode parameters, leaderElection parameters, controlplane parameters, and taint parameters. In one example, the working mode of the Kube-vip module can be specified as the address resolution protocol ARP mode, and the corresponding configuration parameters are arp parameters. Specifically, for example, the command lines "--arp", "--leaderElection", "--controlplane", "--taint", etc. can be used to initialize the configuration parameters of the Kube-vip module. Among them, arp specifies that the working mode of the Kube-vip module is ARP mode; leaderElection means enabling the leader-election mechanism to select the main control node; controlplane means enabling control plane related functions; taint means configuring nodeAffinity (being able to select qualified nodes to run Pods) and tolerance (allowing the scheduler of the control node to schedule Pods with corresponding taints) to ensure that the Kube-vip module can and only runs on the master node (control node).

[0044] In one example, deploying the Kube-vip module to the control node of the Kubernetes cluster may include deploying the Kube-vip module on all control nodes of the Kubernetes cluster in a daemonSet manner. Figure 2 The Kube-vip module is deployed on the three control nodes k8s-master01, k8s-master02 and k8s-master03. Therefore, even if the selected master control node fails, other control nodes can be selected as master control nodes, thereby achieving high availability. DaemonSet is used to ensure that all or some nodes must run a Pod's workload resources (daemon process). When a new node joins the Kubernetes cluster, daemonSet will also add a Pod to the node. Deploy the Kube-vip module on the control node of the Kubernetes cluster as a daemonSet to ensure that all qualified nodes run a copy of the Pod. Specifically, for example, the daemonSet deployment file can be placed in the pod-manifest-path directory of the kubelet component of the worker node (working node) of the Kubernetes cluster. The Kubelet component is an important component of the worker node of the Kubernetes cluster, responsible for maintaining the life cycle of the Pod and interacting with the master node. For example Figure 2 The kubelet component is deployed on the worker node k8s-worker01 in the example. For example, you can start the kubelet component process to regularly scan the pod-manifest-path directory and create or delete static pods based on the yaml / json files that appear or disappear in the pod-manifest-path directory.

[0045] Step S2: Select one of the control nodes of the Kubernetes cluster as the main control node through the leader-election mechanism of the Kube-vip module.

[0046] In some aspects of the present disclosure, leader-election refers to selecting a leader (main control node) from control nodes through election in a Kubernetes cluster, and ensuring that only one leader (main control node) exists at the same time.

[0047] In one example, selecting one of the control nodes of the Kubernetes cluster as the main control node through the leader-election mechanism of the Kube-vip module may include, for example: when the kubelet component is started, the daemonSet service of the Kube-vip module can be pulled up, so that the Kube-vip module can call the kube-apiserver interface of the control node of the Kubernetes cluster, thereby implementing the leader-election mechanism of the Kube-vip module to select a control node from the control nodes of the Kubernetes cluster as the main control node of the Kubernetes cluster. The Kube-apiserver interface is the core component of the control node of the Kubernetes cluster, responsible for processing internal and external requests of the cluster. For example, Figure 2 The kube-apiserver interface is deployed on the three control nodes k8s-master01, k8s-master02 and k8s-master03.

[0048] Step S3: Bind the virtual Internet Protocol VIP address to the master control node through the Kube-vip module, and notify the unselected control nodes in the Kubernetes cluster, wherein the unselected control nodes serve as slave control nodes.

[0049] In some aspects of the present disclosure, VIP (Virtual IP) is a virtual IP used for requesting kube-apiserver between nodes of a Kubernetes cluster.

[0050] For example, Figure 2 As shown, if the control node k8s-master01 of the Kubernetes cluster is selected as the master control node through the leader-election mechanism of the Kube-vip module, VIP192.168.10.20 can be bound to the designated network card of the master control node k8s-master01 through the Kube-vip module. The master control node k8s-master01, for example, notifies k8s-master02 and k8s-master03 in the cluster that are not selected as the master control node through the ARP protocol, and k8s-master02 and k8s-master03 can be used as slave control nodes. The deployment of the master control node and the slave control node can be completed through steps S1-S3.

[0051] Step S4: When the master control node fails, a new master control node is selected from the slave control nodes through the leader-election mechanism of the Kube-vip module of the slave control node, and the VIP address is bound to the new master control node.

[0052] Figure 3 A schematic diagram of the principle of a Kubernetes cluster based on the Kube-vip module when a failure occurs according to an embodiment of the present disclosure is shown.

[0053] like Figure 3 As shown in the figure, when a fault occurs, it is assumed that VIP is currently bound to the master control node k8s-master01, and the current faulty node is k8s-master01. After the fault occurs, the Kube-vip modules of the slave control nodes k8s-master02 and k8s-master03 will conduct a new round of leader-election and bind VIP to the designated network card of the newly selected leader (master control node). Figure 3 In the example, the control node k8s-master02 is selected as the new master control node. As a result, the control node k8s-master02 replaces the failed control node k8s-master01 as the master control node. The fact that the control node k8s-master02 is selected as the new master control node can also be notified to other slave control nodes (for example, through the ARP protocol) Figure 3 In this way, even if the master control node fails, there is a new master control node and the normal use of VIP is guaranteed, thus achieving high availability.

[0054] Step S5: When the original master control node recovers from the fault, if the leader-election mechanism of the Kube-vip module of the original master control node finds that there is a new master control node, the Kube-vip module of the original master control node no longer performs the VIP address binding operation, so that the original master control node is transformed into a slave control node of the Kubernetes cluster.

[0055] Figure 4 A schematic diagram of the principle of failure recovery of the main control node of a Kubernetes cluster based on the Kube-vip module according to an embodiment of the present disclosure is shown.

[0056] like Figure 4As shown in the figure, when the control node k8s-master01 recovers from the failure, the Kube-vip module on the control node k8s-master01 will initiate a leader-election. When the leader-election finds that there is already a leader ( Figure 4 When the control node k8s-master02 in the cluster exists, no VIP binding or other actions are performed, and the control node k8s-master01 is transformed into a slave control node. This ensures that there is only one leader (master control node) at the same time, and brain split will not occur.

[0057] It is particularly important to note that the daemonSet of the Kube-vip module needs to use hostNetwork (host network) and set hosts (host) to specify the listening interface 127.0.0.1, and correctly configure kubeconfig (the core file of Kubernetes cluster access configuration, which contains the authentication information required to access the Kubernetes cluster (such as certificates, keys, tokens, etc.) and cluster address information), so as to ensure that the startup of the Kube-vip module does not depend on the CNI (Container Network Interface) network plug-in. In this way, VIP can be used to configure the CNI network plug-in to achieve high availability and load balancing of the entire cluster.

[0058] This application uses the Kube-vip module to build a highly available kubernetes cluster. The Kube-vip module can run directly on all k8s-master nodes (control nodes), no longer requiring additional servers, and reducing server resource waste. In addition, the leader-election mechanism is used to automatically select the leader, which can ensure that only one node is the leader (main control node) when there is a problem with communication between nodes, avoiding the brain split problem.

[0059] The following is an embodiment of the device of the present application, which can be used to execute the embodiment of the method of the present application. For details not disclosed in the embodiment of the device of the present application, please refer to the embodiment of the method of the present application.

[0060] Figure 5 The schematic diagram of the structure of a device for constructing a Kubernetes cluster based on the Kube-vip module according to an embodiment of the present disclosure is shown; the device includes any module for implementing the above-mentioned method for constructing a Kubernetes cluster. Figure 5 As shown, the construction device may include:

[0061] A deployment module 501 is used to deploy the Kube-vip module to the control node of the Kubernetes cluster instead of to the working node of the Kubernetes cluster;

[0062] A first selection module 502, configured to select one of the control nodes of the Kubernetes cluster as a master control node through a leader-election mechanism of the Kube-vip module;

[0063] A notification module 503 is used to bind a virtual Internet Protocol VIP address to the master control node through the Kube-vip module, and notify an unselected control node in the Kubernetes cluster, wherein the unselected control node of the Kubernetes cluster serves as a slave control node;

[0064] The second selection module 504 is used to select a new master control node from the slave control nodes through the leader-election mechanism of the Kube-vip module of the slave control node when the master control node fails, and bind the VIP address to the new master control node;

[0065] The discovery module 505 is used for, when the leader-election mechanism of the Kube-vip module of the master control node discovers the existence of the new master control node after the master control node fails and the Kube-vip module of the master control node no longer performs the VIP address binding operation, so that the master control node is transformed into a slave control node of the Kubernetes cluster.

[0066] It should be understood that the size of the serial numbers of the steps in the above embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0067] Figure 6 Schematic diagram of the structure of the electronic device 3 provided in the embodiment of the present application. Figure 6 As shown, the electronic device 3 of this embodiment includes: a processor 301, a memory 302, and a computer program 303 stored in the memory 302 and executable on the processor 301. When the processor 301 executes the computer program 303, the steps in the above-mentioned method embodiments are implemented. Alternatively, when the processor 301 executes the computer program 303, the functions of the modules / units in the above-mentioned device embodiments are implemented.

[0068] Exemplarily, the computer program 303 may be divided into one or more modules / units, which are stored in the memory 302 and executed by the processor 301 to complete the present application. The one or more modules / units may be a series of computer program instruction segments capable of completing specific functions, which are used to describe the execution process of the computer program 303 in the electronic device 3.

[0069] The electronic device 3 may be a desktop computer, a notebook, a PDA, a cloud server, or other electronic device. The electronic device 3 may include, but is not limited to, a processor 301 and a memory 302. Those skilled in the art will appreciate that Figure 6 It is only an example of the electronic device 3 and does not constitute a limitation of the electronic device 3. It may include more or fewer components than shown in the figure, or a combination of certain components, or different components. For example, the electronic device may also include input and output devices, network access devices, buses, etc.

[0070] The processor 301 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or the processor may be any conventional processor, etc.

[0071] The memory 302 may be an internal storage unit of the electronic device 3, for example, a hard disk or memory of the electronic device 3. The memory 302 may also be an external storage device of the electronic device 3, for example, a plug-in hard disk, a smart memory card (SmartMedia Card, SMC), a secure digital (Secure Digital, SD) card, a flash card (Flash Card), etc. equipped on the electronic device 3. Further, the memory 302 may also include both an internal storage unit of the electronic device 3 and an external storage device. The memory 302 is used to store computer programs and other programs and data required by the electronic device. The memory 302 may also be used to temporarily store data that has been output or is to be output.

[0072] The technicians in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In practical applications, the above-mentioned function allocation can be completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiment can be integrated in a processing unit, or each unit can exist physically separately, or two or more units can be integrated in one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units and modules are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application. The specific working process of the units and modules in the above-mentioned system can refer to the corresponding process in the aforementioned method embodiment, which will not be repeated here.

[0073] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0074] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments applied for herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0075] In the embodiments provided in the present application, it should be understood that the disclosed devices / computer equipment and methods can be implemented in other ways. For example, the device / computer equipment embodiments described above are only schematic. For example, the division of modules or units is only a logical function division. There may be other division methods in actual implementation. Multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0076] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0077] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0078] In addition, if the integrated module / unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the present application implements all or part of the processes in the above-mentioned embodiment method, and can also be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium, and the computer program can implement the steps of the above-mentioned various method embodiments when executed by the processor. The computer program may include computer program code, and the computer program code may be in source code form, object code form, executable file or some intermediate form. The computer-readable medium may include: any entity or device capable of carrying computer program code, recording medium, U disk, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal and software distribution medium. It should be noted that the content contained in the computer-readable medium can be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, the computer-readable medium does not include electric carrier signals and telecommunication signals.

[0079] In addition, an embodiment of the present application also relates to a computer program product, which includes a computer program, and when the computer program is executed by a processor, the steps in the aforementioned method embodiment are implemented.

[0080] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application, and should all be included in the protection scope of the present application.

Claims

1. A method for constructing a Kubernetes cluster based on the Kube-vip module, characterized in that: The Kubernetes cluster includes multiple control nodes and one or more working nodes, and the method includes: Deploy the Kube-vip module to the control node of the Kubernetes cluster instead of to the working node of the Kubernetes cluster; Select one of the control nodes of the Kubernetes cluster as the main control node through the leader-election mechanism of the Kube-vip module; Binding a virtual Internet Protocol VIP address to the master control node through the Kube-vip module, and notifying an unselected control node in the Kubernetes cluster, wherein the unselected control node serves as a slave control node; When the master control node fails, a new master control node is selected from the slave control nodes through the leader-election mechanism of the Kube-vip module of the slave control node, and the VIP address is bound to the new master control node; When the master control node recovers from the fault, when the leader-election mechanism of the Kube-vip module of the master control node finds the existence of the new master control node, the Kube-vip module of the master control node no longer performs the VIP address binding operation, so that the master control node is transformed into a slave control node of the Kubernetes cluster.

2. The method for constructing a Kubernetes cluster according to claim 1, characterized in that: Deploying the Kube-vip module to the control node of the Kubernetes cluster includes: The Kube-vip module is deployed on all control nodes of the Kubernetes cluster in a daemonSet manner, and the daemonSet deployment file is placed in the pod-manifest-path directory of the kubelet component of the working node of the Kubernetes cluster.

3. The method for constructing a Kubernetes cluster according to claim 2, characterized in that: The selecting one of the control nodes of the Kubernetes cluster as the main control node through the leader-election mechanism of the Kube-vip module includes: After the kubelet component is started, the daemonSet service of the Kube-vip module is pulled up, so that the Kube-vip module calls the kube-apiserver interface of the control node of the Kubernetes cluster, thereby realizing the leader-election mechanism of the Kube-vip module.

4. The method for constructing a Kubernetes cluster according to claim 1, characterized in that: Before deploying the Kube-vip module to the control node of the Kubernetes cluster, the method further includes: Initialize the configuration parameters of the Kube-vip module, including working mode parameters, leaderElection parameters, controlplane parameters and taint parameters.

5. The method for constructing a Kubernetes cluster according to claim 4, characterized in that: The working mode parameter of the Kube-vip module is specified as an arp parameter representing the Address Resolution Protocol ARP mode.

6. A device for constructing a Kubernetes cluster based on Kube-vip, characterized in that: The Kubernetes cluster includes multiple control nodes and one or more working nodes, and the device includes: A deployment module, used to deploy the Kube-vip module to the control node of the Kubernetes cluster instead of to the working node of the Kubernetes cluster; A first selection module, used to select one of the control nodes of the Kubernetes cluster as the main control node through the leader-election mechanism of the Kube-vip module; A notification module, used to bind a virtual Internet Protocol VIP address to the master control node through the Kube-vip module, and notify unselected control nodes in the Kubernetes cluster, wherein the unselected control nodes of the Kubernetes cluster serve as slave control nodes; A second selection module is used to select a new master control node from the slave control node through the leader-election mechanism of the Kube-vip module of the slave control node when the master control node fails, and bind the VIP address to the new master control node; A discovery module is used for, when the master control node recovers from a fault, when the leader-election mechanism of the Kube-vip module of the master control node discovers the existence of the new master control node, the Kube-vip module of the master control node no longer performs the VIP address binding operation, so that the master control node is transformed into a slave control node of the Kubernetes cluster.

7. A Kubernetes cluster built based on the Kube-vip module, characterized in that: The Kubernetes cluster includes multiple control nodes and one or more working nodes, and the Kubernetes cluster is constructed by the method described in any one of claims 1 to 5.

8. An electronic device, characterized in that: The device comprises a memory, a processor and a computer program stored in the memory and executable on the processor, and the processor implements the method according to any one of claims 1 to 5 when executing the program.

9. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 1 to 5 is implemented.

10. A computer program product, comprising a computer program, which, when executed by a processor, implements the method according to any one of claims 1 to 5.

Citation Information

Patent Citations

  • Method for selecting and switching standbys under distributed cluster

    CN106713056A

  • Main / standby switching method and device of operating system and related equipment

    CN110908723A

  • Method and system for realizing high availability of distributed cluster and computer readable medium

    CN112887367A

  • Deployment tuning method of single K8S cluster in large-scale edge node scene

    CN116647458A