Node determination method of Kubernetes system and related equipment

Abstract

The invention provides a node determination method of a Kubernetes system and related equipment, the method is applied to a target node, the target node is any node in each node of the Kubernetes system, the method comprises the following steps: obtaining state data of each preset target service in each node of the Kubernetes system; determining the running state of each node according to the weight and state data of each target service of each node; and determining a main node and a standby node in the nodes according to the running state of each node. The main and standby nodes can be switched according to the running state of each node.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a node determination method and related equipment of a Kubernetes system. Background Art

[0002] With the rapid development of science and technology, the dependence of industrial systems on IT infrastructure has become increasingly significant, and this trend is particularly prominent in the widespread application of industrial automation, intelligent manufacturing and Internet of Things (IoT) technologies. The application of these emerging technologies has not only greatly improved production efficiency, but also put forward more stringent requirements on the stability, reliability and flexibility of industrial systems.

[0003] In traditional industrial control systems, centralized architectures dominate. The core of centralized architectures is that all data processing and control logic are concentrated on one or a few core components. Although this architecture has played an important role in early industrial control systems, its inherent single point failure risk cannot be ignored. Once these core components fail, the operation of the entire production line will be directly affected, and may even lead to production stagnation, causing huge economic losses to the company. Summary of the invention

[0004] The technical problem to be solved by this application is to provide a node determination method and related equipment for a Kubernetes system, which can accurately determine the active and standby nodes according to the operating status of each node, so that the active and standby switching can be quickly realized. The specific scheme is as follows:

[0005] A node determination method for a Kubernetes system is applied to a target node, where the target node is any node among the nodes of the Kubernetes system, and the method comprises:

[0006] Obtain status data of each preset target service in each of the nodes of the Kubernetes system;

[0007] Determining the operating status of each of the nodes according to the weights and status data of each of the target services of each of the nodes;

[0008] A master node and a backup node are determined from among the nodes according to the running status of each node.

[0009] In the above method, optionally, obtaining the status data of each preset service in each node of the Kubernetes system includes:

[0010] Monitor the status data of each preset target service of the target node through the custom resource CRD preset by the target node;

[0011] Send a query request to nodes other than the target node to obtain status data of each preset target service of the nodes other than the target node.

[0012] Optionally, the method described above, determining the operating status of each node according to the weight and status data of each target service of each node, includes:

[0013] For each of the nodes, the target services in an unhealthy state are determined based on the status data of each target service of the node; the unhealthy score of the node is obtained based on the weight calculation of the target services in an unhealthy state; when the unhealthy score of the node is not less than a preset threshold, the operating state of the node is determined to be a healthy state; when the unhealthy score of the node is greater than a preset threshold, the operating state of the node is determined to be an unhealthy state.

[0014] In the above method, optionally, determining a master node and a backup node in each of the nodes according to the running status of each of the nodes includes:

[0015] determining a historical role for each of said nodes;

[0016] A master node and a backup node are determined among the nodes according to the historical role of each node and the operation status of each node.

[0017] The above method, optionally, after determining the master node and the backup node in each of the nodes according to the running status of each of the nodes, further comprises:

[0018] When it is determined that the target node is a standby node, the target node is controlled to release the VIP.

[0019] A node determination device of a Kubernetes system, applied to a target node, wherein the target node is any node among the nodes of the Kubernetes system, and the device comprises:

[0020] An acquisition unit, used to acquire status data of each preset target service in each of the nodes of the Kubernetes system;

[0021] A first determining unit, configured to determine the operating state of each of the nodes according to the weight and state data of each of the target services of each of the nodes;

[0022] The second determining unit is used to determine a master node and a backup node among the nodes according to the running status of each node.

[0023] In the above device, optionally, the acquisition unit includes:

[0024] A monitoring unit, configured to monitor the status data of each preset target service of the target node through a custom resource CRD preset by the target node;

[0025] The query unit is used to send a query request to nodes other than the target node to obtain status data of each preset target service of the nodes other than the target node.

[0026] In the above device, optionally, the first determining unit includes:

[0027] An execution subunit is used to determine, for each of the nodes, a target service that is in an unhealthy state based on the status data of each target service of the node; obtain an unhealthy score of the node based on the weight calculation of the target service in an unhealthy state; if the unhealthy score of the node is not less than a preset threshold, determine that the operating state of the node is a healthy state; if the unhealthy score of the node is greater than a preset threshold, determine that the operating state of the node is an unhealthy state.

[0028] A storage medium includes stored instructions, wherein when the instructions are executed, a device where the storage medium is located is controlled to execute the node determination method of the Kubernetes system as described above.

[0029] An electronic device includes a memory and one or more instructions, wherein the one or more instructions are stored in the memory and are configured to be executed by one or more processors to perform the node determination method of the Kubernetes system as described above.

[0030] The present application implements a node determination method and related equipment of a Kubernetes system, the method is applied to a target node, the target node is any node in the various nodes of the Kubernetes system, and the method includes: obtaining the status data of each preset target service in each of the nodes of the Kubernetes system; determining the operating status of each of the nodes according to the weight and status data of each of the target services of each of the nodes; determining the master node and the standby node in each of the nodes according to the operating status of each of the nodes. Applying the method provided in the embodiment of the present application, the master and standby nodes can be accurately determined according to the operating status of each node, so that the master-standby switching can be quickly realized. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0032] Figure 1 A method flow chart of a node determination method for a Kubernetes system provided in this application;

[0033] Figure 2 A flowchart of a process for determining a master node and a backup node in each node according to the operating status of each node provided in the present application;

[0034] Figure 3 A schematic diagram of the structure of a dual-machine redundant system provided for this application;

[0035] Figure 4 A structural diagram of another dual-machine redundant system provided for this application;

[0036] Figure 5 A flowchart of a node switching process provided by this application;

[0037] Figure 6 A flowchart of the proxy process of a master node executor provided in this application;

[0038] Figure 7 A flowchart of a proxy process of a standby node executor provided in this application;

[0039] Figure 8 A schematic diagram of the structure of a node determination device for a Kubernetes system provided in this application;

[0040] Fig. 9 A schematic diagram of the structure of an electronic device provided in this application. DETAILED DESCRIPTION

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

[0042] In this application, the terms "comprises", "comprising" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the sentence "comprising a ..." does not exclude the presence of other identical elements in the process, method, article or device comprising the element.

[0043] The present application embodiment provides a node determination method for a Kubernetes system, which is applied to a target node, wherein the target node is any node among the nodes of the Kubernetes system, and each node can be a cluster. The method flow chart of the method is as follows: Figure 1 As shown, specifically including:

[0044] S101: Obtain status data of each preset target service in each of the nodes of the Kubernetes system.

[0045] In this embodiment, the state data of the target service may indicate whether the current state of the target service is healthy.

[0046] Optionally, the target service may be a predetermined key service, which may be selected based on the importance of business requirements of each service.

[0047] Optionally, each node is provided with an arbitrator, a coordinator, an executor and a state machine.

[0048] In this embodiment, the arbitrator is used to implement the VRRP protocol and has the function of preempting and releasing VIP (virtual IP). The coordinator is used to calculate the health status of the current node to ensure that the roles and health status of the two nodes are consistent. In addition, the coordinator is also used to perform fault tolerance detection and rationality coordination. The executor is used to collect or monitor the health detection interface of key services, and calculate the health status of these services according to the business rules of CRD resources. And report the calculation results to the state machine for synchronization to the peer node. Depending on the key services that need to be monitored, various types of executors can be derived. These executors follow the same logical process. The state machine is used to persistently store the current role and health status, and synchronize data with the state machine of the peer. At the same time, the running status of the executor is also monitored to ensure that each executor is not offline or abnormal.

[0049] In an embodiment provided in the present application, based on the above solution, optionally, obtaining the status data of each preset service in each node of the Kubernetes system includes:

[0050] Monitor the status data of each preset target service of the target node through the custom resource CRD preset by the target node;

[0051] Send a query request to nodes other than the target node to obtain status data of each preset target service of the nodes other than the target node.

[0052] In this embodiment, the executor in each node can monitor the health status of one or more target services according to the CRD and regularly report status data to the state machine. For different types of target services, multiple executors can be defined and implemented according to business scenarios.

[0053] For example, two collection rules, default and coreBizSer, are configured in the following CRD instance:

[0054] monitoring-rules:

[0055] default: #Default validation rules

[0056] resources:nodes

[0057] names:["ubuntu20-1276"]#Default system name

[0058] Weight: 80

[0059] expression:"object.status.phase==Running||object.status.phase==

[0060] Pending

[0061] coreBizSer:#Add validation rules based on business scenarios

[0062] resources:pods

[0063] namespace:"supos"

[0064] labelSelector:"app=myapp"

[0065] Weight: 70

[0066] expression:"object.status.phase==Running||object.status.phase==

[0067] Succeeded||object.status.phas==Pending"

[0068] In this embodiment, according to the declaration in the collection rule default, the executor will assemble a URL (for example: / api / v1 / nodes / ubuntu20-1276) according to these rules and initiate a request to the URL. After the request returns, the executor will obtain the metadata of the nodes and use the CEL (Common Expression Language) expression to calculate the specified expression. If the calculation result of the CEL expression is true, the node is judged to be in a healthy state; if it is false, it is judged to be in an unhealthy state. Finally, the executor will report a piece of status data to the state machine, including: default (as a unique identifier), 80 (indicating weight), and health status (healthy or unhealthy, determined by the calculation result of the CEL expression).

[0069] In addition, the executor will assemble another URL (for example: / api / v1 / namespaces / supos / pods?labelSelector=app=myapp) according to the rules defined in coreBizSer, and initiate a request to the URL. After the request returns, the executor will perform CEL expression calculations on the metadata and specified expressions of each computing unit pod. If the CEL expression calculation results of all pods are true, coreBizSer is judged to be in a healthy state; if the calculation results of one or more pods are false, it is judged to be in an unhealthy state. Finally, the executor will report another piece of status data to the state machine, including: coreBizSer (as a unique identifier), weight 70, and health status (determined by the CEL expression calculation results of the pod).

[0070] In this embodiment, the state machine periodically scans the last reporting time of each executor. If the configured maximum heartbeat time is exceeded, the executor is considered to be offline abnormally. The state table of the state machine is shown in Table 1:

[0071] Table 1

[0072] Unique ID Weight Health status Last reporting time default 80 healthy 20xx-08-2711:32:45 coreBizSer 80 Unhealthy 20xx-08-2711:32:44 xxxx 20 Offline 20xx-08-2611:32:44

[0073] S102: Determine the operating status of each of the nodes according to the weight and status data of each of the target services of each of the nodes.

[0074] In this embodiment, each node carries one or more target services, and the weight of the target service can be used to indicate the importance or priority of the target service.

[0075] Optionally, the running state of the node may be one of a healthy state and an unhealthy state.

[0076] In an embodiment provided by the present application, based on the above solution, optionally, determining the operating status of each node according to the weight and status data of each target service of each node includes:

[0077] For each of the nodes, the target services in an unhealthy state are determined based on the status data of each target service of the node; the unhealthy score of the node is obtained based on the weight calculation of the target services in an unhealthy state; when the unhealthy score of the node is not less than a preset threshold, the operating state of the node is determined to be a healthy state; when the unhealthy score of the node is greater than a preset threshold, the operating state of the node is determined to be an unhealthy state.

[0078] In this embodiment, the coordinator in the node can obtain the status data of all actuators. Each actuator will set a weight value according to its business characteristics and impact, and submit this weight value each time the status is reported. The coordinator will accumulate the weight values ​​of all actuators in an unhealthy state. If the accumulated weight value is greater than or equal to the threshold defined in the configuration file, the coordinator will consider the current node to be unhealthy; conversely, if the accumulated weight value is less than the threshold, the current node is considered to be in a healthy state.

[0079] The following example illustrates the node status data as shown in Table 2:

[0080] Table 2

[0081]

[0082]

[0083] Scenario 1: The accumulated weight value of the unhealthy executor is 100>=threshold 80, so the running status of the node is: unhealthy.

[0084] Scenario 2: The accumulated weight value of the unhealthy executor is 70 < the threshold value 75, so the running status of the node is: healthy.

[0085] Scenario 3: The accumulated weight value of the unhealthy executor is 60>=threshold 60, so the running status of the node is: unhealthy status.

[0086] S103: Determine a master node and a backup node from among the nodes according to the running status of each node.

[0087] In an embodiment provided in the present application, based on the above solution, optionally, the process of determining the master node and the backup node in each of the nodes according to the running status of each of the nodes is as follows: Figure 2 As shown, including:

[0088] S201: Determine the historical role of each of the nodes.

[0089] In this embodiment, in the initial state, the historical role of each node can be set to a pending role, for example, an “unknown role.” In a non-initial state, the historical role of each node can be determined according to the ruling result of the previous round.

[0090] S202: Determine a master node and a backup node among the nodes according to the historical role of each node and the operation status of each node.

[0091] In this embodiment, a node in a healthy state is determined. If there is only one node in a healthy state, the node in a healthy state can be determined as the master node, and the remaining nodes can be determined as standby nodes. If there are multiple nodes in a healthy state, the master node and the standby node can be determined in each healthy node based on the historical role of the node in a healthy state. For each node in a healthy state, if the historical role of the node is the master node role, the node can be preferentially determined as the master node; if the historical role of the node is the standby node role, the node can be preferentially determined as the standby node. In some embodiments, if the historical roles of the nodes in a healthy state are all candidate node roles or unknown node roles, a node in a healthy state can be randomly selected as the master node, and the remaining nodes can be used as standby nodes.

[0092] In an embodiment provided by the present application, based on the above solution, optionally, after determining the master node and the backup node in each of the nodes according to the running status of each of the nodes, the method further includes:

[0093] When it is determined that the target node is a standby node, the target node is controlled to release a VIP (virtual IP).

[0094] See also Figure 3 , which is a structural example diagram of a dual-machine redundant system provided in this application. The dual-machine redundant system includes two Kubernetes system nodes, each of which is provided with an arbitrator, a coordinator, an executor and a state machine.

[0095] In order to ensure the stability and reliability of the entire redundant system, the system uses a coordinator algorithm to assign three roles to each node: master node, backup node, or unknown role. In the initialization phase, all nodes are set to unknown roles, and then the node's health status is used to determine whether it becomes a master node or a backup node. Before receiving an update notification from the arbitrator (or decision maker), the node will maintain its previous role status unchanged. The health status of a node is mainly divided into healthy and unhealthy.

[0096] Among them, both the master and standby nodes need to complete the election of their corresponding roles. The mechanism is as follows: Figure 4 As shown in the figure, the node's executor monitors the health status of one or more key services based on the CRD resources and regularly reports the status data to the state machine. For different types of key services, multiple executors can be defined and implemented according to business scenarios. The state machine regularly scans the last reporting time of each executor. If it exceeds the configured maximum heartbeat time, the executor is considered to be offline abnormally.

[0097] The coordinator periodically obtains the health status of each executor from the state machine and performs health calculations on the nodes. After calculating the health status, it decides whether to perform fault tolerance processing based on business needs. Before the coordinator applies for arbitration, it can combine the status information of the peer node to ensure that the role applied for is reasonable. If it cannot connect to the peer node, the coordinator will apply for arbitration based on its own health status. The arbitrator uses its built-in health check mechanism to regularly access the coordinator's interface, obtain and make arbitration based on the calculated health status. This process involves the preemption and release of VIP (virtual IP). When the arbitrator successfully competes for the VIP or releases the VIP, it triggers a script request through its event mechanism to notify the coordinator that the role has changed. After receiving this notification, the coordinator will update the master node role in the state machine and regularly check whether the current role is consistent with the VIP mounting status, so as to actively apply for verification to avoid the problem of VIP mounting and role inconsistency caused by incorrect processing of the arbitrator notification or request loss.

[0098] The executor of the standby node also monitors the health status of the corresponding stateful service and reports this information to the state machine. The state machine of the standby node also periodically scans the last reporting time of each executor. If it exceeds the preset maximum heartbeat time, the executor is considered to be offline or abnormal. The coordinator of the standby node periodically obtains the health status of each executor from the state machine and calculates the node health. Before the calculation, it defaults to an unknown role.

[0099] Before the standby node coordinator applies for arbitration, it will perform calculations based on the status information of the first node. For example, if it is healthy and the peer node is also healthy and is the primary node, the calculated result is a standby node. If the standby node coordinator determines that the calculated role is inconsistent with the current unknown role, it will send a role arbitration request to the arbitrator. After receiving the role arbitration request, the arbitrator of the standby node will execute the VIP release process and notify the coordinator of the release result. If the release process fails, the status of the second node will continue to remain as an unknown role, waiting for the next round of arbitration. After receiving this notification, the coordinator of the standby node will update the standby node role to the state machine.

[0100] See also Figure 5 , is a flowchart of a node switching process provided by the present application, wherein the role of the node coordinator is in an unknown state when it is started. At this time, it needs to read the old archive file to obtain the previous role information. If the coordinator cannot read the role information, it will carry the unknown role identifier and calculate the current health status through the health detection process. After the coordinator calculates the health status, the arbitrator needs to combine the status information of the peer node to determine the master node or the backup node.

[0101] Specifically, the coordinator obtains the status data of all executors. Each executor will be assigned a weight value based on its business characteristics and impact, and this weight value will be submitted with each status report. The coordinator will accumulate the weight values ​​of all unhealthy executors. When this accumulated value is greater than or equal to the threshold defined in the configuration file, the current node is considered unhealthy; otherwise, the current node is considered to be in a healthy state.

[0102] If the role determined by the arbitrator is the master node, or the previous role read by the coordinator at startup is the master node, the coordinator will carry the role identifier of the current master node for the next round of health detection and arbitration.

[0103] If the role determined by the arbitrator is a standby node, or the previous role read by the coordinator at startup is a standby node, the coordinator will carry the role identifier of the current standby node for the next round of health detection and arbitration.

[0104] As shown in Table 3, the normal scenarios in which the coordinator can apply for arbitration are shown:

[0105] Table 3

[0106]

[0107] In addition to the above three situations, there are two abnormal scenarios, as shown in Table 4:

[0108] Table 4

[0109]

[0110] From the above role status analysis, VIP should be mounted on the peer node. In order to prevent the risk that the arbitrator's primary and backup arbitration notification may be sent only once and there is a very small probability of loss or failure to process normally, each coordinator will regularly check the actual mounting status of the VIP and take corresponding corrective measures as appropriate. For example, if the current node has mounted the VIP but its role is a backup node, and the peer node is the primary node and is in a healthy state, the current node will actively initiate a backup node arbitration process to release the VIP.

[0111] When many application services are started, they need to perform operations such as database updates, or they need to regularly operate data, messages, caches and other resources during their operation. In a dual-node redundant architecture, when application services are started on the standby node, they may try to perform these update operations or logic. However, most relational databases and middleware only support active-standby mode in dual-node redundant mode, which means that relational databases and middleware running on the standby node can usually only synchronize data from the primary node, but cannot push data to the primary node. Even if some services support active-active mechanisms, they usually rely on complex locking mechanisms to ensure data consistency, which will have a significant impact on operational performance.

[0112] In the solution provided in the embodiment of the present application, it can be ensured that when the application service on the standby node accesses the corresponding database and middleware, it actually accesses the service on the primary node, not the service on the standby node. When the primary and standby states are switched, the connection can be automatically adjusted to ensure service continuity and data consistency.

[0113] See also Figure 6 When a cluster is deployed, it registers a CRD (Custom Resource Definition) with Kubernetes. This CRD defines the rules for finding the service to be proxied (SVC), as well as the subsequent control logic and declaration mechanism. Its fields include but are not limited to: ......

[0115] serviceBroker:

[0116] description: Detailed information about the proxy service.

[0117] type:object

[0118] properties:

[0119] namespace:

[0120] type:string

[0121] description: The namespace where the service is located.

[0122] nodePort:

[0123] type:int

[0124] description: Specifies the port number of the NodePort SVC. If not specified, it will be automatically assigned by Kubernetes.

[0125] svcNames:

[0126] type:string

[0127] description: The name of the proxy service.

[0128] masterNotify:

[0129] type:string

[0130] description: callback URL when upgrading the master node (optional).

[0131] slaveNotify:

[0132] type:string

[0133] description: callback URL when downgrading a standby node (optional). ......

[0135] Optionally, one or more CRD instances can be registered based on application needs. Examples are as follows: ......

[0137] serviceBroker:

[0138] -namespace:"service"

[0139] nodePort:33306#If not specified, it will be automatically allocated by k8s.

[0140] svcNames:"mysql"

[0141] masterNotify: http: / / xxx / xxx / xxx / toxxxSvcMaster#Optional, callback notification for upgrading to master node

[0142] salveNotify:http: / / xxx / xxx / xxx / toxxxSvcSalve#Optional, callback notification for downgrading the standby node ......

[0144] This example declares a mysql SVC registered for the mysql application.

[0145] When the master node executor starts, it will call the watch interface according to the above CRD to listen to the registration and changes of the instance, so as to identify the Kubernetes service (SVC) that needs to be controlled. When it is found that the masterNotify callback address is set in the instance, it will initiate a request call when it is downgraded to a standby node, and notify the interface to switch the middleware to the master node role. Subsequently, the executor will automatically create a new SVC according to the instance declaration. The SVC will create a NodePort according to the instance declaration and point the relevant network traffic to the workload defined by the application SVC, so that the service (SVC) in the standby node can access the workload of the master node across nodes. At the same time, the executor will also fill the applied NodePort back into the status information of the CRD instance, and subscribe to the SVC changes of these applications through the watch mechanism. When the SVC in the application changes, the executor will call the apply interface to adjust the new SVC according to the relevant changes. Due to the use of the CRD mechanism, different instances can be created for different applications, so that different application SVCs can be managed and controlled accordingly.

[0146] The executor on the master node provides a query interface for the executor on the standby node to query the latest proxy service CRD instance information.

[0147] The executor of the standby node will periodically access the query interface of the master node executor to obtain the custom resource definition (CRD) instance information and obtain the corresponding NodePort information from the status information.

[0148] The executor of the standby node will create a corresponding CRD instance locally with the information obtained. When the standby node executor detects that the slaveNotify callback address is set in the CRD instance, it will initiate a request call when it is downgraded to a standby node, notifying the interface to switch the middleware to the standby node role.

[0149] The proxy service controller in the executor of the standby node monitors the change events of the proxy service CRD instance through the watch mechanism. It will check whether the source IP and port of the endpoint corresponding to each proxy's SVC have been proxied to the master node. If it is found that the endpoint corresponding to the SVC has not yet pointed to the master node, the executor will automatically update the Endpoint resource to ensure that it correctly points to the master node, thereby completing the proxy setting. The effect after the proxy setting is completed is as follows Figure 7 shown.

[0150] The key points of the embodiments of the present application are:

[0151] 1. The CRD mechanism is used to dynamically increase, decrease or modify the election algorithm strategy through declaration, which reduces the difficulty of use or expansion.

[0152] 2. A more detailed and flexible configuration method is adopted, which allows specific configuration support for the business type of workload, and can accurately meet the needs of various specific business scenarios to ensure the efficiency and adaptability of business operations.

[0153] 3. In addition to the CRD declaration extension mechanism, it also supports users to develop executors to report status and participate in election calculations based on business scenarios.

[0154] 4. Provides an automatic proxy access control mechanism that allows middleware and databases that do not support active-active to also use hot standby dual nodes.

[0155] By applying the solution provided by the embodiment of the present application, high availability can be achieved with only two nodes, effectively reducing the risk of system crash in the industrial environment, and meeting the stringent requirements of the industrial field on hardware cost and performance, reducing the total cost of ownership (TCO). And allow the standby node to seamlessly access the middleware or database service on the master node. This mechanism allows developers to not need to perceive the existence of the master-standby middleware, reducing the difficulty of implementation. It is also possible to ensure data consistency by cleverly controlling the master-standby relationship while avoiding the sacrifice of performance caused by not supporting the dual-active middleware to achieve data consistency. The cross-node master service automatic proxy access control mechanism can dynamically adjust the proxy settings according to the automatic conversion of the master-standby role, thereby reducing the cost of manually maintaining the proxy relationship. This automated proxy control strategy not only improves the reliability and flexibility of the system, but also reduces the burden on the operation and maintenance team. It can also help developers quickly achieve state synchronization between the master and standby nodes without modifying the existing source code, thereby improving development efficiency.

[0156] and Figure 1 Corresponding to the method, the embodiment of the present application also provides a node determination device of a Kubernetes system, which is applied to a target node, wherein the target node is any node among the nodes of the Kubernetes system, and the device is used to determine the node of the Kubernetes system. Figure 1 The specific implementation of the method is shown in the following diagram: Figure 8 As shown, including:

[0157] An acquisition unit 801 is used to acquire status data of each preset target service in each node of the Kubernetes system;

[0158] A first determining unit 802, configured to determine the operating state of each of the nodes according to the weight and state data of each of the target services of each of the nodes;

[0159] The second determining unit 803 is configured to determine a master node and a backup node from among the nodes according to the running status of each node.

[0160] In an embodiment provided in the present application, based on the above solution, optionally, the acquisition unit 801 includes:

[0161] A monitoring unit, configured to monitor the status data of each preset target service of the target node through a custom resource CRD preset by the target node;

[0162] The query unit is used to send a query request to nodes other than the target node to obtain status data of each preset target service of the nodes other than the target node.

[0163] In an embodiment provided in the present application, based on the above solution, optionally, the first determining unit 802 includes:

[0164] An execution subunit is used to determine, for each of the nodes, a target service that is in an unhealthy state based on the status data of each target service of the node; obtain an unhealthy score of the node based on the weight calculation of the target service in an unhealthy state; if the unhealthy score of the node is not less than a preset threshold, determine that the operating state of the node is a healthy state; if the unhealthy score of the node is greater than a preset threshold, determine that the operating state of the node is an unhealthy state.

[0165] The specific principles and execution processes of each unit and module in the node determination device of the Kubernetes system disclosed in the above-mentioned embodiment of the present application are the same as the node determination method of the Kubernetes system disclosed in the above-mentioned embodiment of the present application. Please refer to the corresponding parts of the node determination method of the Kubernetes system provided in the above-mentioned embodiment of the present application, and will not be repeated here.

[0166] An embodiment of the present application further provides a storage medium, which includes stored instructions, wherein when the instructions are executed, a device where the storage medium is located is controlled to execute the node determination method of the Kubernetes system.

[0167] The present application also provides an electronic device, whose structural diagram is as follows: Fig. 9As shown, it specifically includes a memory 901 and one or more instructions 902, wherein the one or more instructions 902 are stored in the memory 901 and are configured to be executed by one or more processors 903 to perform the following operations:

[0168] Obtain status data of each preset target service in each of the nodes of the Kubernetes system;

[0169] Determining the operating status of each of the nodes according to the weights and status data of each of the target services of each of the nodes;

[0170] A master node and a backup node are determined from among the nodes according to the running status of each node.

[0171] It should be noted that each embodiment in this specification is described in a progressive manner, and each embodiment focuses on the differences from other embodiments, and the same or similar parts between the embodiments can be referred to each other. For the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0172] Finally, it should be noted that, in this article, relational terms such as first and second, etc. are merely used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations.

[0173] For the convenience of description, the above device is described in various units according to their functions. Of course, when implementing the present application, the functions of each unit can be implemented in the same or multiple software and / or hardware.

[0174] It can be known from the description of the above implementation methods that those skilled in the art can clearly understand that the present application can be implemented by means of software plus a necessary general hardware platform. Based on such an understanding, the technical solution of the present application can be essentially or partly contributed to the prior art in the form of a software product, which can be stored in a storage medium such as ROM / RAM, a magnetic disk, an optical disk, etc., and includes several instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in the various embodiments of the present application or certain parts of the embodiments.

[0175] The above is a detailed introduction to a node determination method for a Kubernetes system provided by the present application. This article uses specific examples to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method of the present application and its core idea; at the same time, for general technical personnel in this field, according to the idea of ​​the present application, there will be changes in the specific implementation method and application scope. In summary, the content of this specification should not be understood as a limitation on the present application.

Claims

1. A node determination method for a Kubernetes system, characterized in that: Applied to a target node, the target node being any node in the Kubernetes system, the method comprising: Obtain status data of each preset target service in each of the nodes of the Kubernetes system; Determining the operating status of each of the nodes according to the weights and status data of each of the target services of each of the nodes; A master node and a backup node are determined from among the nodes according to the running status of each node.

2. The method according to claim 1, characterized in that The obtaining of status data of each preset service in each node of the Kubernetes system includes: Monitor the status data of each preset target service of the target node through the custom resource CRD preset by the target node; Send a query request to nodes other than the target node to obtain status data of each preset target service of the nodes other than the target node.

3. The method according to claim 1, characterized in that Determining the operating status of each of the nodes according to the weights and status data of each of the target services of each of the nodes includes: For each of the nodes, the target services in an unhealthy state are determined based on the status data of each target service of the node; the unhealthy score of the node is obtained based on the weight calculation of the target services in an unhealthy state; when the unhealthy score of the node is not less than a preset threshold, the operating state of the node is determined to be a healthy state; when the unhealthy score of the node is greater than a preset threshold, the operating state of the node is determined to be an unhealthy state.

4. The method according to claim 1, characterized in that: Determining a master node and a standby node from each of the nodes according to the running status of each of the nodes includes: determining a historical role for each of said nodes; A master node and a backup node are determined among the nodes according to the historical role of each node and the operation status of each node.

5. The method according to claim 1, characterized in that After determining the master node and the backup node in each of the nodes according to the running status of each of the nodes, the method further includes: When it is determined that the target node is a standby node, the target node is controlled to release the VIP.

6. A node determination device for a Kubernetes system, characterized in that: Applied to a target node, the target node is any node in the Kubernetes system, the device includes: An acquisition unit, used to acquire status data of each preset target service in each of the nodes of the Kubernetes system; A first determining unit, configured to determine the operating state of each of the nodes according to the weight and state data of each of the target services of each of the nodes; The second determining unit is used to determine a master node and a backup node among the nodes according to the running status of each node.

7. The device according to claim 6, characterized in that The acquisition unit comprises: A monitoring unit, configured to monitor the status data of each preset target service of the target node through a custom resource CRD preset by the target node; The query unit is used to send a query request to nodes other than the target node to obtain status data of each preset target service of the nodes other than the target node.

8. The device according to claim 6, characterized in that The first determining unit includes: An execution subunit is used to determine, for each of the nodes, a target service that is in an unhealthy state based on the status data of each target service of the node; obtain an unhealthy score of the node based on the weight calculation of the target service in an unhealthy state; if the unhealthy score of the node is not less than a preset threshold, determine that the operating state of the node is a healthy state; if the unhealthy score of the node is greater than a preset threshold, determine that the operating state of the node is an unhealthy state.

9. A storage medium, characterized in that: The storage medium includes storage instructions, wherein when the instructions are executed, the device where the storage medium is located is controlled to execute the node determination method of the Kubernetes system according to any one of claims 1 to 5.

10. An electronic device, characterized in that: It includes a memory and one or more instructions, wherein the one or more instructions are stored in the memory and are configured to be executed by one or more processors to perform the node determination method of the Kubernetes system as described in any one of claims 1 to 5.

Images