Method, device and equipment for detecting node status in k8s cluster and medium

Abstract

The application discloses a node state detection method and device in a k8s cluster, equipment and medium, relates to the technical field of clusters, and comprises the following steps: in response to a connection request sent by a current working node in a k8s cluster, obtaining a target control component copy from a plurality of control component copies deployed in the k8s cluster according to a hash algorithm, establishing a connection between the target control component copy and the current working node, receiving heartbeat information sent by the current working node through the established connection, and detecting the state of the current working node according to the heartbeat information and a timeout period previously configured for the current working node. The technical problem that improving the detection speed of nodes will affect the overall performance of the cluster in the prior art is solved, and the technical effect of improving the detection speed of nodes without affecting the overall performance of the cluster is achieved.

Description

Technical Field

[0001] This application relates to the field of cluster technology, and in particular to methods, apparatus, equipment and media for detecting the status of nodes in a Kubernetes cluster. Background Technology

[0002] With the development of deep learning cloud platforms, unified resource monitoring and scheduling based on Kubernetes (k8s) are implemented to improve the utilization of computing center resources and reduce costs. However, in practical applications, data center nodes may fail due to power outages, network outages, hardware failures, etc. Therefore, an efficient node status detection mechanism is needed to ensure cluster stability and business continuity.

[0003] In traditional technologies, Kubernetes primarily monitors node health through periodic heartbeat checks. The kubelet component on a node periodically sends heartbeat signals to the API Server (Application Programming Interface Server). The node controller in Kubernetes periodically checks whether the node status signal has been updated. If no heartbeat signal is received from the node within a preset time, Kubernetes marks the node as unavailable. Traditionally, achieving rapid detection of faulty Kubernetes nodes mainly relies on lowering the heartbeat reporting interval of the kubelet (Kubernetes' native proxy component) (default 10s) and lowering parameters such as the node status check interval (default 5s) and node failure wait interval (default 40s) of the kube controller manager. For example, changing the kubelet heartbeat reporting interval to 1s, the node status check interval to 1s, and the node failure wait interval to 3s can detect node disconnection within 2-4 seconds.

[0004] However, lowering parameters such as the detection period in traditional technologies directly results in a significant increase in the number of node heartbeat messages. These messages are quite extensive, and under stable cluster conditions, kubelet heartbeat messages account for 80% of the apiserver traffic. While this has little impact on small-scale clusters, it leads to excessive control plane bandwidth consumption in larger clusters. According to project data, a single collective node heartbeat in a 2500-node Kubernetes cluster generates over 300Mbps of control plane network traffic. Lowering the kubelet heartbeat period would cause significant congestion on the cluster's control plane network, impacting overall cluster performance. Summary of the Invention

[0005] This application provides a method, apparatus, device, and medium for detecting the status of nodes in a Kubernetes cluster, in order to at least solve the problem of low efficiency in node detection in related technologies.

[0006] This application provides a method for detecting the node status in a Kubernetes cluster, including:

[0007] In response to a connection request sent by the current worker node in the Kubernetes cluster, the target control component replica is obtained from multiple control component replicas deployed in the Kubernetes cluster according to a hash algorithm.

[0008] Establish a connection between the target control component copy and the current working node;

[0009] Receive heartbeat information sent by the current working node through the established connection;

[0010] The status of the current worker node is detected based on heartbeat information and the timeout duration pre-configured for the current worker node.

[0011] In one embodiment, the current worker node deploys a proxy component that obtains a target control component replica from multiple control component replicas deployed in the Kubernetes cluster according to a hash algorithm, including:

[0012] Obtain the identification information of the container group where the proxy component resides and the number of copies of the control component;

[0013] The identification information of the container group where the proxy component is located is encoded, and a hash calculation is performed based on the encoding result, the number of control component replicas, and the hash algorithm to obtain the first hash value;

[0014] Obtain the identification information of the container group where the control component copy resides, and encode it;

[0015] The second hash value is obtained by performing a hash calculation based on the encoding result corresponding to the identifier information of the container group where the control component replica is located, the number of control component replicas, and the hash algorithm.

[0016] The first hash value is compared with the second hash value, and the target control component copy is selected based on the comparison result.

[0017] In one embodiment, the identification information of the container group where the proxy component resides is encoded, and a hash calculation is performed based on the encoding result, the number of control component replicas, and a hash algorithm to obtain a first hash value, including:

[0018] The ASCII code values ​​of each character in the identifier information of the container group where the proxy component is located are converted to obtain the encoding result.

[0019] The sum of the ASCII values ​​of each character is obtained based on the encoding result;

[0020] The first hash value is obtained by performing a hash calculation based on the sum of the ASCII code values, the number of copies of the control component, and the hash algorithm.

[0021] In one embodiment, comparing a first hash value with a second hash value and selecting a target control component copy based on the comparison result includes:

[0022] The first hash value is compared with the second hash value, and the control component copy obtained when the comparison results are consistent is determined as the target control component copy.

[0023] In one embodiment, the method for detecting the node status in a Kubernetes cluster includes the following steps: when the comparison results are inconsistent, re-returning the response to the connection request sent by the current worker node in the Kubernetes cluster, and obtaining a target control component replica from multiple control component replicas deployed in the Kubernetes cluster according to a hash algorithm.

[0024] In one embodiment, the method for detecting the node status in a Kubernetes cluster includes the following steps: when one of the control component replicas fails, disconnecting the connection between each of the other control component replicas and the corresponding worker node, updating the control component replica of the control node, and returning the response to the connection request sent by the current worker node in the Kubernetes cluster, and obtaining the target control component replica from multiple control component replicas deployed in the Kubernetes cluster according to a hash algorithm.

[0025] In one embodiment, a method for detecting the status of a node in a Kubernetes cluster includes: creating a memory object for the current worker node based on a timeout duration, storing heartbeat information in the memory object, and detecting the status of the current worker node based on the heartbeat information and a timeout duration pre-configured for the current worker node, including: obtaining the latest heartbeat information from the memory object, and detecting the status of the current worker node based on the latest heartbeat information and the timeout duration.

[0026] In one embodiment, a method for detecting the status of a node in a Kubernetes cluster includes: updating heartbeat information to the lease resources of the Kubernetes cluster; detecting the status of the current worker node based on the heartbeat information and a timeout duration pre-configured for the current worker node; and obtaining the latest heartbeat information of the current node based on the lease resources of the Kubernetes cluster, and detecting the status of the current worker node based on the latest heartbeat information and the timeout duration.

[0027] In one embodiment, establishing a connection between the target control component copy and the current working node includes: establishing a long connection between the target control component copy and the current working node through a pre-defined network protocol.

[0028] This application also provides a device for detecting the status of nodes in a Kubernetes cluster, including:

[0029] The request module is used to respond to connection requests sent by the current worker node in the Kubernetes cluster and obtain the target control component replica from multiple control component replicas deployed in the Kubernetes cluster according to a hash algorithm.

[0030] The connection module is used to establish a connection between the target control component copy and the current working node;

[0031] The receiving module is used to receive heartbeat information sent by the current working node through the established connection;

[0032] The detection module is used to detect the status of the current working node based on heartbeat information and the timeout duration pre-configured for the current working node.

[0033] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for executing the computer program to implement the steps of any of the above-described methods for detecting the state of nodes in a Kubernetes cluster.

[0034] This application also provides a computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, it implements the steps of any of the above-described methods for detecting the state of nodes in a Kubernetes cluster.

[0035] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described methods for detecting the state of nodes in a Kubernetes cluster.

[0036] This application uses a hash algorithm to assign a corresponding target control component replica to each worker node, establishing a one-to-one dedicated connection. This distributes heartbeat processing tasks across multiple control component replicas. Even with a shortened reporting cycle, the load on a single control component will not surge with the increase in the number of nodes. This avoids the problem in traditional technologies where heartbeats from all nodes are centrally received by the API Server and processed by the node controller, leading to significant congestion on the cluster control plane network when the cycle is shortened. Each worker node transmits heartbeats with its corresponding target control component replica, reducing contention for shared resources and ensuring fast and stable transmission of heartbeat information. This avoids misjudgments or detection delays caused by transmission latency, thereby improving node detection efficiency. Attached Figure Description

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

[0038] Figure 1A schematic diagram illustrating the application environment of a node status detection method in a Kubernetes cluster provided in this embodiment of the application;

[0039] Figure 2 A flowchart illustrating a method for detecting the state of a node in a Kubernetes cluster, provided in an embodiment of this application;

[0040] Figure 3 A flowchart illustrating the steps of obtaining a target control component replica from multiple control component replicas deployed in a k8s cluster according to a hash algorithm, as provided in an embodiment of this application.

[0041] Figure 4 A schematic diagram of the initialization process provided for embodiments of this application;

[0042] Figure 5 A schematic diagram of the heartbeat reporting process provided in an embodiment of this application;

[0043] Figure 6 A schematic diagram of the internal structure of the node status detection device in the Kubernetes cluster provided in this application embodiment;

[0044] Figure 7 This is an internal structural diagram of a computer device provided in an embodiment of this application. Detailed Implementation

[0045] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0046] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0047] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0048] The specific application environment architecture or specific hardware architecture on which the node status detection method in the Kubernetes cluster depends is described here.

[0049] Please refer to Figure 1 , Figure 1 This is a schematic diagram illustrating the application environment of a method for detecting the node status in a Kubernetes cluster, provided as an exemplary embodiment of this application. For example... Figure 1 As shown, the application environment includes a control node 100 and a current worker node 101 in a k8s cluster. The control node 100 is deployed with multiple control component replicas 102, and the current worker node 101 is deployed with an agent component 103.

[0050] The current working node 101 is used to send a connection request to the control node 100 through the proxy component 103.

[0051] The control node 100 responds to the connection request sent by the current worker node 101 in the k8s cluster, obtains the target control component replica from multiple control component replicas 102 deployed in the k8s cluster according to the hash algorithm, establishes a connection between the target control component replica and the current worker node 101, receives the heartbeat information sent by the current worker node 101 through the established connection, and detects the status of the current worker node 101 according to the heartbeat information and the timeout duration pre-configured for the current worker node 101.

[0052] The control node 100 and the worker node 101 can be implemented using independent servers or a server cluster consisting of multiple servers.

[0053] This application provides a method for detecting the node status in a Kubernetes cluster, and the method is described in detail below, along with its execution flow. Figure 2 As shown, this method is applied to Figure 1 Taking the control node in the example, the following steps are included:

[0054] Step S21: In response to the connection request sent by the current worker node in the k8s cluster, obtain the target control component replica from multiple control component replicas deployed in the k8s cluster according to the hash algorithm.

[0055] Among them, Kubernetes (k8s) is an open-source application used to manage containerized applications on multiple hosts in a cloud platform. The goal of k8s is to make deploying containerized applications simple and efficient. k8s provides a mechanism for application deployment, planning, updating and maintenance.

[0056] Worker nodes are nodes in a Kubernetes cluster that are responsible for running containers, carrying components such as kubelet, and executing tasks issued by the control plane.

[0057] A hash algorithm is an algorithm that maps input data to a fixed output value (hash value).

[0058] The control component replica is a self-developed component instance added to enhance node status detection capabilities; it is not a native Kubernetes component. The control component replica is responsible for receiving and processing heartbeat information sent by worker nodes, monitoring node health status, and establishing dedicated communication connections with nodes. It undertakes the core task of node fault detection (such as determining whether a node is disconnected or abnormal). Its functionality is independent of native Kubernetes components, aiming to achieve load distribution through multi-replica deployment and improve the efficiency and stability of cluster node status detection.

[0059] The target control component replica refers to the specific replica that is matched for the current working node from multiple control component replicas using a hash algorithm, and is responsible for handling the node's heartbeat and status detection.

[0060] Specifically, control component replicas are deployed within the Kubernetes cluster as stateless load balancers. Multiple replicas can be deployed, exposing services externally via Kubernetes nodeport services. Replicas use a hash algorithm to shard nodes, with each replica responsible for a portion of the machine to achieve load balancing. The Kubernetes nodeport service method is a service exposure technique in Kubernetes that opens a static port on each node in the cluster, allowing external traffic to access services within the cluster via the node's IP address (Internet Protocol) combined with the static port, thus enabling network access from outside the cluster to internal services.

[0061] Step S22: Establish a connection between the target control component copy and the current working node.

[0062] Specifically, the current working node can obtain the network address of the target replica through the Kubernetes service discovery mechanism, establish a connection based on the network address, perform authentication before the connection is established, and maintain the communication link between the two parties after the authentication is successful (such as periodically sending heartbeat frames to keep the connection), thereby achieving stable information exchange.

[0063] Step S23: Receive heartbeat information sent by the current working node through the established connection.

[0064] Among them, heartbeat information is a data packet sent periodically by the working node to prove that its own status is normal. It usually contains key information such as the node's basic status (such as whether it is online, resource usage, component running status, etc.) and timestamps. In essence, it is a signal from the node to the control component that it is operating normally.

[0065] Specifically, after the target control component replica establishes a connection with the current working node, the control component replica continuously receives heartbeat information sent by the working node at certain intervals through this dedicated connection, thereby monitoring the health status of the node in real time and providing a basis for subsequent judgment on whether the node is faulty.

[0066] Step S24: Detect the status of the current working node based on the heartbeat information and the timeout duration pre-configured for the current working node.

[0067] The timeout duration is a pre-set threshold for determining whether a worker node is abnormal. For example, if the timeout is set to 30 seconds, it means that if the control component replica does not receive a heartbeat message from a worker node for 30 consecutive seconds, it will determine that the node may be faulty.

[0068] Specifically, the control component replica receives heartbeat information sent by the worker node through the established connection and combines it with the timeout period pre-configured for that node to detect the node status. It compares the time interval obtained by subtracting the latest heartbeat time from the current time with the timeout duration. If the time interval does not exceed the timeout duration, it means that the node is normal; if the obtained time interval exceeds the timeout duration, it is determined that the node status is abnormal.

[0069] This application allows configuring different timeout durations for different worker nodes. The timeout duration can be configured through a configuration file or the parameter setting interface of the management platform. If configured through a configuration file, parameters can be added to the deployment configuration of the control component to specify the timeout period. If a visual management platform is available, the corresponding duration can be directly set in the heartbeat settings of the node management module. After configuration, the control component will perform node status detection according to the set threshold.

[0070] In one embodiment, such as Figure 3 As shown, the current working node has a proxy component deployed. It retrieves the target control component replica from multiple control component replicas deployed in the Kubernetes cluster using a hash algorithm. This process includes: obtaining the identifier information of the container group where the proxy component resides and the number of control component replicas; encoding the identifier information of the container group where the proxy component resides; performing a hash calculation based on the encoding result, the number of control component replicas, and the hash algorithm to obtain a first hash value; obtaining the identifier information of the container group where the control component replica resides and encoding it; performing a hash calculation based on the encoding result of the identifier information of the container group where the control component replica resides, the number of control component replicas, and the hash algorithm to obtain a second hash value; comparing the first hash value with the second hash value; and selecting the target control component replica based on the comparison result.

[0071] In Kubernetes (k8s), a Pod is the smallest unit of deployment and management in a cluster. The identification information of a container group is characteristic data used to uniquely identify the container group. Specifically, the identification information of a container group can include the container group's name or ID number. In this application, the identification information of the container group is unique within the cluster and will not be duplicated with other container groups. Using a unique value as the hash input ensures that the hash result generated by each container group (and its associated proxy component or control component replica) is distinguishable, avoiding incorrect matching between different container groups. Furthermore, the identification information is relatively stable throughout the container group's lifecycle. Calculating the hash based on a stable input ensures that the matching relationship between proxy component and control component replicas does not easily change under normal circumstances, reducing unnecessary connection switching and state synchronization overhead.

[0072] Specifically, this application takes the remainder of the encoding result of the identifier information of the container group where the proxy component resides, modulo the number of control component replicas, to obtain a first hash value. Then, it takes the remainder of the encoding result of the identifier information of the container group where the control component replicas resides, modulo the number of control component replicas, to obtain a second hash value. The first hash value represents the number of the proxy component or the number of the node where the proxy component resides, and the second hash value represents the number corresponding to the control component replica.

[0073] Furthermore, by comparing the first hash value with all the second hash values, the control component replica that matches (or is closest to matching) is selected as the target control component replica, which is responsible for communicating with the node where the proxy component is located.

[0074] The beneficial effect of this embodiment is that by binding the proxy component to the control component replica through a hash algorithm, it is ensured that the heartbeat processing task of each worker node is fixedly assigned to a specific control component replica, thereby achieving a uniform distribution of the load among multiple replicas and avoiding overload of a single replica.

[0075] In one embodiment, the identification information of the container group where the proxy component is located is encoded, and a hash calculation is performed based on the encoding result, the number of control component replicas, and a hash algorithm to obtain a first hash value. This includes: converting each character in the identification information of the container group where the proxy component is located into its ASCII code value to obtain an encoding result; obtaining the sum of the ASCII code values ​​of each character based on the encoding result; and performing a hash calculation based on the sum of the ASCII code values, the number of control component replicas, and a hash algorithm to obtain the first hash value.

[0076] ASCII (American Standard Code for Information Interchange) is a character encoding system based on the Latin alphabet used to represent text information. Each ASCII character corresponds to an integer between 0 and 127, which is the ASCII code value.

[0077] Specifically, this application can obtain the identification information of the container group where the proxy component resides. Each character in the identification information of the container group where the proxy component resides is converted into its corresponding ASCII code value, resulting in a set of numerical values, i.e., the encoding result. The ASCII code values ​​of all characters are added together to obtain a sum. The remainder of the sum divided by the number of control component replicas is used to obtain the first hash value. The calculation process for the second hash value is similar.

[0078] The beneficial effect of this embodiment is that, in a distributed system, hash values ​​can be used to evenly distribute tasks or resources. This application uses a hash algorithm to distribute the heartbeat information processing tasks to different control component replicas.

[0079] In one embodiment, comparing a first hash value with a second hash value and selecting a target control component copy based on the comparison result includes: comparing the first hash value with the second hash value, and determining the control component copy obtained when the comparison results are consistent as the target control component copy.

[0080] Specifically, by comparing the first hash value and the second hash value, if they are the same, the corresponding control component copy is identified as the target control component copy.

[0081] This application uses hash value comparison to quickly determine which control component copy matches the container group where the proxy component resides, ensuring that the correct control component copy is found.

[0082] In one embodiment, the method for detecting the node status in a Kubernetes cluster further includes the step of: when the comparison results are inconsistent, returning to the connection request sent by the current worker node in the Kubernetes cluster, and obtaining a target control component copy from multiple control component copies deployed in the Kubernetes cluster according to a hash algorithm.

[0083] If the comparison results of the first hash value and the second hash value are inconsistent, the original process is re-executed: respond to the connection request sent by the current worker node in the Kubernetes cluster, and once again obtain the target control component replica from the multiple control component replicas deployed in the cluster through the hash algorithm.

[0084] If a match is successful, the connection is accepted; if a match is unsuccessful, the connection is rejected, and the process proceeds to the next round of matching until a matching copy of the target control component is found.

[0085] In one embodiment, the method for detecting the node status in a Kubernetes cluster further includes the following steps: when one of the control component replicas fails, disconnecting the connection between each of the other control component replicas and the corresponding worker node, updating the control component replica of the control node, and returning the response to the connection request sent by the current worker node in the Kubernetes cluster, and obtaining the target control component replica from multiple control component replicas deployed in the Kubernetes cluster according to a hash algorithm.

[0086] When a control component replica fails, the connections between other healthy control component replicas and their respective worker nodes are disconnected. The number of control component replicas on the control node is updated, and the process is re-executed: responding to connection requests from worker nodes in the Kubernetes cluster, the target control component replica is retrieved again from the updated pool of replicas using a hash algorithm. Because the number of available control component replicas decreases, the numbers of the remaining surviving replicas are automatically updated, ultimately ensuring that connections to the proxy component are automatically and evenly distributed among the remaining control component replicas.

[0087] The beneficial effect of this embodiment is that after a failure, the remaining replica numbers are updated, and the connections are redistributed in combination with a hash algorithm, ensuring that the long connections of the proxy component are evenly distributed among the surviving replicas, and avoiding excessive load on any one replica.

[0088] In one embodiment, please refer to Figure 4 and Figure 5 The node status detection method in the Kubernetes cluster also includes: creating a memory object for the current worker node based on the timeout duration, storing the heartbeat information in the memory object, and detecting the status of the current worker node based on the heartbeat information and the timeout duration pre-configured for the current worker node, including: obtaining the latest heartbeat information from the memory object, and detecting the status of the current worker node based on the latest heartbeat information and the timeout duration.

[0089] In this context, a memory object refers to a structured data entity created in the memory of the control node for temporary data storage.

[0090] Specifically, after the connection is established, the control node obtains the name of the current working node and the pre-configured timeout duration from the initialization message, creates a memory object, and when the proxy component sends heartbeat information, the target control component copy updates the latest heartbeat information of the corresponding memory object.

[0091] Furthermore, a scheduled task is initiated to obtain the latest heartbeat time from the latest heartbeat information. The latest heartbeat time is used as a set of timeout durations specific to the current working node to determine whether the node is abnormal. For the interval obtained by subtracting the latest heartbeat time from the current time, nodes that exceed the timeout duration are marked as unavailable nodes.

[0092] The advantages of this embodiment are: memory object access is much faster than disk or network interaction, enabling rapid reading of heartbeat information and completion of status checks, reducing latency. No network communication with the Kubernetes API server is required, thus avoiding additional traffic and performance degradation on Kubernetes compute nodes.

[0093] In one embodiment, the method for detecting the status of a node in a k8s cluster further includes: updating heartbeat information to the lease resources of the k8s cluster, and detecting the status of the current worker node based on the heartbeat information and the timeout duration pre-configured for the current worker node, including: obtaining the latest heartbeat information of the current node based on the lease resources of the k8s cluster, and detecting the status of the current worker node based on the latest heartbeat information and the timeout duration.

[0094] In a Kubernetes cluster, a lease resource is an API resource used to maintain the liveness status of nodes or components. It is primarily used for the heartbeat mechanism: worker nodes periodically update the information in the lease resource, and control component replicas determine node liveness by checking the lease update status. Lease resources have an expiration time; if the lease is not updated within the specified time, the node is considered potentially faulty.

[0095] Specifically, this application can update the heartbeat information of the current worker node to the corresponding lease resources in the Kubernetes cluster. When node detection is required, the latest heartbeat information of the worker node is read from the lease resources of the Kubernetes cluster, and the node status is determined by combining it with the pre-configured timeout duration. If the difference between the latest heartbeat time and the current time exceeds the timeout duration, the node is determined to be abnormal; otherwise, it is normal.

[0096] The beneficial effect of this embodiment is that the lease resources are stored in etcd (a distributed, reliable key-value store system), which is cluster-level shared data. All control components can access it through the Kubernetes API, ensuring that node status information is consistently visible within the cluster.

[0097] In one embodiment, establishing a connection between the target control component copy and the current working node includes: establishing a long connection between the target control component copy and the current working node through a pre-defined network protocol.

[0098] In network communication, a persistent connection refers to a connection established between a client and a server that remains open after its initial setup, allowing for multiple data transfers without requiring a new connection to be established and closed for each communication. WebSocket is a typical example of a persistent connection; once established, both parties can exchange data at any time until the connection is actively closed. WebSocket is a network protocol that enables full-duplex communication over a single TCP (Transmission Control Protocol) connection. It allows persistent connections between clients and servers, enabling bidirectional data transmission at any time without needing to re-establish a connection for each communication.

[0099] This application sends heartbeat messages via long-lived WebSocket connections to reduce the performance overhead of repeatedly establishing TCP connections. It also supports long-lived WebSocket connections via an independent heartbeat network, reducing the risk of data congestion when reusing the Kubernetes management network.

[0100] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0101] Embodiments of this application also provide a device for detecting the node status in a Kubernetes cluster, such as... Figure 6 As shown, the node status detection device in a Kubernetes cluster includes:

[0102] Request module 61 is used to respond to connection requests sent by the current worker node in the Kubernetes cluster and obtain the target control component replica from multiple control component replicas deployed in the Kubernetes cluster according to a hash algorithm.

[0103] Connection module 62 is used to establish a connection between the target control component copy and the current working node.

[0104] The receiving module 63 is used to receive heartbeat information sent by the current working node through the established connection.

[0105] The detection module 64 is used to detect the status of the current working node based on heartbeat information and the timeout duration pre-configured for the current working node.

[0106] In one embodiment, the current worker node has a proxy component deployed. The request module 61 can obtain the identification information of the container group where the proxy component resides and the number of replicas of the control component.

[0107] The identification information of the container group where the proxy component is located is encoded, and a hash calculation is performed based on the encoding result, the number of control component replicas, and the hash algorithm to obtain a first hash value. The identification information of the container group where the control component replica is located is obtained and encoded. A hash calculation is performed based on the encoding result of the identification information of the container group where the control component replica is located, the number of control component replicas, and the hash algorithm to obtain a second hash value. The first hash value and the second hash value are compared, and the target control component replica is selected based on the comparison result.

[0108] In one embodiment, the request module 61 can convert the ASCII values ​​of each character in the identification information of the container group where the proxy component is located to obtain the encoding result, obtain the sum of the ASCII values ​​of each character according to the encoding result, and perform hash calculation based on the sum of the ASCII values, the number of control component replicas, and the hash algorithm to obtain the first hash value.

[0109] In one embodiment, the request module 61 can compare the first hash value with the second hash value, and determine the control component copy obtained when the comparison results are consistent as the target control component copy.

[0110] In one embodiment, the request module 61 may, when the comparison results are inconsistent, return the step of retrieving the target control component copy from multiple control component copies deployed in the k8s cluster according to the hash algorithm in response to the connection request sent by the current worker node in the k8s cluster.

[0111] In one embodiment, when one of the control component replicas fails, the detection module 64 can disconnect the connections between each of the other control component replicas and the corresponding worker node, update the control component replica of the control node, and return to the steps of responding to the connection request sent by the current worker node in the Kubernetes cluster and obtaining the target control component replica from multiple control component replicas deployed in the Kubernetes cluster according to the hash algorithm.

[0112] In one embodiment, the detection module 64 can create a memory object for the current working node based on the timeout duration, store the heartbeat information in the memory object, and the detection module 64 can obtain the latest heartbeat information from the memory object and detect the status of the current working node based on the latest heartbeat information and the timeout duration.

[0113] In one embodiment, the detection module 64 can update the heartbeat information to the lease resources of the k8s cluster. The detection module 64 can obtain the latest heartbeat information of the current node based on the lease resources of the k8s cluster, and detect the status of the current working node based on the latest heartbeat information and the timeout duration.

[0114] In one embodiment, the connection module 62 can establish a long connection between the target control component copy and the current working node via a pre-defined network protocol.

[0115] For a description of the features of the embodiment of the node state detection device in the k8s cluster, please refer to the relevant description of the embodiment of the node state detection method in the k8s cluster, which will not be repeated here.

[0116] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps in any of the above embodiments of the method for detecting the state of nodes in a Kubernetes cluster.

[0117] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above embodiments of the method for detecting the node status in a Kubernetes cluster.

[0118] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0119] The embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above embodiments of the method for detecting the node status in a Kubernetes cluster.

[0120] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above embodiments of the method for detecting the node status in a Kubernetes cluster.

[0121] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0122] The above provides a detailed description of a node status detection method in a Kubernetes cluster. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of this application.

Claims

1. A method for detecting the state of nodes in a Kubernetes cluster, characterized in that, The method includes: In response to a connection request sent by the current worker node in the Kubernetes cluster, the identifier information of the container group where the proxy component deployed on the current worker node is located and the number of control component replicas deployed in the Kubernetes cluster are obtained according to a hash algorithm. The identification information of the container group where the proxy component is located is encoded, and a hash calculation is performed based on the encoding result, the number of replicas of the control component, and the hash algorithm to obtain a first hash value; Obtain the identification information of the container group where the control component copy is located, and encode it; A second hash value is obtained by performing a hash calculation based on the encoding result corresponding to the identifier information of the container group where the control component replica is located, the number of control component replicas, and the hash algorithm. The first hash value is compared with the second hash value, and the target control component replica is selected from the control component replicas according to the comparison result. The control component replica is deployed in the Kubernetes cluster in the form of a stateless load. The control component replica is used to receive and process the heartbeat information sent by the current worker node and monitor the health status of the current worker node. Establish a connection between the target control component copy and the current working node; Receive heartbeat information sent by the current working node through the established connection; The status of the current working node is detected based on the heartbeat information and the timeout duration pre-configured for the current working node; The method further includes: By opening static ports on each node of the Kubernetes cluster, external traffic can access the control component replica through the node's IP address and the static ports.

2. The method for detecting node status in a Kubernetes cluster according to claim 1, characterized in that, The process of encoding the identification information of the container group where the proxy component resides, and performing hash calculation based on the encoding result, the number of control component replicas, and the hash algorithm to obtain a first hash value includes: The ASCII code values ​​of each character in the identifier information of the container group where the proxy component is located are converted to obtain the encoding result; The sum of the ASCII codes of each character is obtained based on the encoding result; The first hash value is obtained by performing a hash calculation based on the sum of the ASCII code values, the number of copies of the control component, and the hash algorithm.

3. The method for detecting node status in a Kubernetes cluster according to claim 1, characterized in that, The step of comparing the first hash value with the second hash value and selecting the target control component copy based on the comparison result includes: The first hash value is compared with the second hash value, and the control component copy obtained when the comparison results are consistent is determined as the target control component copy.

4. The method for detecting node status in a Kubernetes cluster according to claim 3, characterized in that, The method further includes: When the comparison results are inconsistent, the process of responding to the connection request sent by the current worker node in the Kubernetes cluster and obtaining the target control component replica from multiple control component replicas deployed in the Kubernetes cluster according to the hash algorithm is returned.

5. The method for detecting node status in a Kubernetes cluster according to claim 1, characterized in that, The method further includes: When one of the control component replicas fails, disconnect all other control component replicas from the corresponding worker node; Update the control component replica of the control node and return the steps of responding to the connection request sent by the current worker node in the Kubernetes cluster and obtaining the target control component replica from multiple control component replicas deployed in the Kubernetes cluster according to the hash algorithm.

6. The method for detecting node status in a Kubernetes cluster according to claim 1, characterized in that, The method further includes: Create a memory object for the current working node based on the timeout duration; The heartbeat information is stored in the memory object; The step of detecting the status of the current working node based on the heartbeat information and the timeout duration pre-configured for the current working node includes: The latest heartbeat information is obtained from the memory object, and the status of the current working node is detected based on the latest heartbeat information and the timeout duration.

7. The method for detecting node status in a Kubernetes cluster according to claim 1, characterized in that, The method further includes: Update the heartbeat information to the lease resources of the Kubernetes cluster; The step of detecting the status of the current working node based on the heartbeat information and the timeout duration pre-configured for the current working node includes: Obtain the latest heartbeat information of the current node based on the lease resources of the Kubernetes cluster; The status of the current working node is detected based on the latest heartbeat information and the timeout duration.

8. The method for detecting node status in a Kubernetes cluster according to claim 1, characterized in that, The step of establishing a connection between the target control component copy and the current working node includes: Establish a long-lived connection between the target control component copy and the current working node using a pre-defined network protocol.

9. A device for detecting the status of nodes in a Kubernetes cluster, characterized in that, The device includes: The request module is used to respond to connection requests sent by the current worker node in the Kubernetes cluster. It retrieves a target control component replica from multiple control component replicas deployed in the Kubernetes cluster using a hash algorithm. It also retrieves the identifier information of the container group where the proxy component deployed on the current worker node resides, as well as the number of control component replicas deployed in the Kubernetes cluster, using the hash algorithm. The identifier information of the container group where the proxy component resides is encoded, and a hash calculation is performed based on the encoding result, the number of control component replicas, and the hash algorithm to obtain a first hash value. The module then retrieves and encodes the identifier information of the container group where the control component replica resides. A hash calculation is performed based on the encoding result of the identifier information of the container group where the control component replica resides, the number of control component replicas, and the hash algorithm to obtain a second hash value. The module compares the first hash value with the second hash value and selects a target control component replica from the control component replicas based on the comparison result. The control component replicas are deployed in the Kubernetes cluster in a stateless load balancing manner. These control component replicas are used to receive and process heartbeat information sent by the current worker node and monitor the health status of the current worker node. A connection module is used to establish a connection between the target control component copy and the current working node; The receiving module is used to receive heartbeat information sent by the current working node through the established connection; The detection module is used to detect the status of the current working node based on the heartbeat information and the timeout duration pre-configured for the current working node, and to allow external traffic to access the control component replica through the IP address of the node and the static port by opening a static port on each node of the Kubernetes cluster.

10. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the method for detecting the node state in a Kubernetes cluster as described in any one of claims 1 to 8 when executing the computer program.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein when the computer program is executed by a processor, it implements the steps of the method for detecting the node state in a Kubernetes cluster as described in any one of claims 1 to 8.

12. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the method for detecting the node status in a Kubernetes cluster as described in any one of claims 1 to 8.

Images