Node management method, apparatus, device, storage medium, and program product

Abstract

The embodiment of the present application discloses a node management method, device, equipment, storage medium and program product, and the method comprises the steps that the priority of a node to be processed in a kubernetes cluster is determined; and the update frequency of a lease corresponding to the node to be processed is determined according to the priority of the node to be processed.

Description

Technical Field

[0001] This application belongs to the technical field of cloud computing, and relates to, but is not limited to, a node management method, apparatus, device, storage medium, and program product. Background Technology

[0002] In a Kubernetes cluster, nodes need to periodically report their status to the control plane. In related technologies, this can be achieved by sending heartbeats to an Application Programming Interface (API) server via Kubelet instances, allowing the API server to obtain the status of nodes in the Kubernetes cluster. However, running a large number of Kubelet instances can be resource-intensive when simulating large-scale Kubernetes clusters. Summary of the Invention

[0003] This application provides a node management method, apparatus, device, storage medium, and program product.

[0004] This application provides a node management method, which includes:

[0005] Determine the priority of nodes to be processed in the Kubernetes cluster;

[0006] The update frequency of the lease corresponding to the node to be processed is determined based on the priority of the node to be processed.

[0007] This application also proposes a node management device, the device comprising:

[0008] The priority module is used to determine the priority of nodes to be processed in the Kubernetes cluster.

[0009] The processing module is used to determine the update frequency of the lease corresponding to the node to be processed based on the priority of the node to be processed.

[0010] This application also proposes an electronic device, which includes a processor and a memory for storing a computer program that can run on the processor; wherein the processor is used to run the computer program to execute any of the node management methods described above.

[0011] This application also proposes a computer storage medium storing a computer program that, when executed by a processor, implements any of the above-described node management methods.

[0012] This application also proposes a computer program product, including a computer program that, when executed by a processor, implements any of the above-described node management methods.

[0013] As can be seen, in this embodiment, the update frequency of the lease corresponding to the node to be processed can be accurately determined according to the priority of the node to be processed in the Kubernetes cluster. By updating the lease corresponding to the node to be processed, the heartbeat of the node to be processed can be simulated. Therefore, this embodiment can simulate node heartbeats without the need for Kubelet instances, so that the control plane can obtain the status of the node to be processed in the Kubernetes cluster in a timely manner. Compared with the related technologies, which send heartbeats to the API server by running a large number of Kubelet instances, this embodiment can reduce resource consumption to a certain extent. Attached Figure Description

[0014] Figure 1 This is a flowchart of a node management method according to an embodiment of this application;

[0015] Figure 2 This is a schematic diagram of the architecture of the hierarchical lease controller applied in the embodiments of this application;

[0016] Figure 3 This is a schematic diagram of the architecture of the application node stage controller in the embodiments of this application;

[0017] Figure 4 This is a schematic diagram of the node management device according to an embodiment of this application;

[0018] Figure 5 This is a schematic diagram of the composition structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0019] In related technologies, Kubernetes clusters primarily rely on real nodes and container groups (Pods) for testing and development. The first approach is a real cluster-based management scheme, where actual hardware or virtual machines are used to create and manage the Kubernetes cluster. This approach requires significant resources and time to start and maintain the cluster. The second approach is an simulator-based management scheme, where simulators (such as Minikube and Kind) are used to create local Kubernetes clusters. These simulators typically require running complete Kubernetes components, including kubelet and kube-apiserver. The third approach is a fake client-based management scheme, where fake clients (such as fake-client-go) are used to simulate Kubernetes API calls. This approach is typically used for unit testing but cannot simulate real cluster behavior.

[0020] The technical solutions of the related technologies have at least the following problems: 1) The first and second technical solutions of the related technologies have high resource consumption. Specifically, they require a large amount of hardware resources and time to start and maintain the cluster, resulting in high costs. 2) The technical solutions of the related technologies have a slow startup problem. Specifically, the process of creating and deleting clusters and nodes is slow, affecting development and testing efficiency. 3) The technical solutions of the related technologies are not flexible enough. Specifically, they cannot flexibly simulate different nodes in terms of type, label, taints, capacity, and conditions, and cannot meet the needs of various testing scenarios.

[0021] Furthermore, in related technologies, nodes need to periodically report their status to the control plane to ensure that the control plane confirms that the node's status is ready. For example, a Kubelet instance can send a heartbeat to the API server, allowing the API server to obtain the status of nodes in the Kubernetes cluster. However, running a large number of Kubelet instances consumes significant resources when simulating a large-scale Kubernetes cluster. Therefore, a lightweight method is needed to simulate node heartbeat reporting.

[0022] In view of the technical problems existing in related technologies, this application proposes technical solutions based on its embodiments.

[0023] The embodiments of this application will be further described in detail below with reference to the accompanying drawings and examples. It should be understood that the embodiments provided herein are merely illustrative of the embodiments of this application and are not intended to limit the embodiments of this application. Furthermore, the embodiments provided below are some embodiments for implementing this application, and not all embodiments for implementing this application. Unless otherwise specified, the technical solutions described in the embodiments of this application can be implemented in any combination.

[0024] It should be noted that, in the embodiments of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a method or apparatus that includes a list of elements includes not only the elements expressly described, but also other elements not expressly listed, or elements inherent to implementing the method or apparatus. Without further limitations, an element defined by the phrase "comprising a..." does not exclude the presence of other related elements (e.g., steps in the method or units in the apparatus, such as portions of circuitry, processors, programs, or software, etc.) in the method or apparatus that includes that element.

[0025] The node management method provided in this application includes a series of steps, but the node management method provided in this application is not limited to the steps described. Similarly, the node management device provided in this application includes a series of modules, but the device provided in this application is not limited to the modules explicitly described, and may also include modules that need to be set for obtaining relevant information or processing based on information.

[0026] Figure 1 This is a flowchart of the node management method according to an embodiment of this application, such as... Figure 1 As shown, the process includes:

[0027] Step 101: Determine the priority of nodes to be processed in the Kubernetes cluster.

[0028] Here, the node to be processed can be one node or multiple nodes. In practical applications, nodes to be processed can be filtered in the Kubernetes cluster according to predefined conditions. For example, the predefined conditions can be: nodes with specific labels or annotations, that is, nodes with specific labels or annotations can be selected as nodes to be processed.

[0029] The priority of a node to be processed can be a priority score or one of N priority levels, where N is an integer greater than or equal to 2. For example, when N equals 3, the N priority levels are high priority, medium priority, and low priority. When the priority of a node to be processed is high, it is a high-priority node, which provides critical services or is a data-intensive task node, requiring more frequent lease renewals. When the priority of a node to be processed is medium, it is a medium-priority node, a standard service node, suitable for performing routine tasks. When the priority of a node to be processed is low, it is a low-priority node, an auxiliary node or an idle node, with the lowest heartbeat simulation frequency. It should be noted that the three priority levels described above are merely illustrative examples, and this application does not limit the specific division of the N priority levels. For example, more levels of priority can be used to achieve more detailed maintenance of the lease status of nodes.

[0030] Step 102: Determine the lease update frequency for the node to be processed based on its priority.

[0031] In this embodiment of the application, the heartbeat of the node to be processed can be simulated by updating the lease corresponding to the node to be processed. Therefore, the update frequency of the lease corresponding to the node to be processed can reflect the simulated heartbeat frequency of the node to be processed.

[0032] In this step, the update frequency of the lease corresponding to the node to be processed is positively correlated with the priority of the node. Thus, for nodes with higher priority, the lease corresponding to the node can be updated more frequently, thereby increasing the heartbeat simulation frequency of the node. For nodes with lower priority, the lease corresponding to the node does not need to be updated frequently, thereby reducing the heartbeat simulation frequency to some extent. Therefore, this embodiment of the application can reasonably determine the heartbeat simulation frequency of the node to be processed based on its priority.

[0033] For example, leases for high-priority nodes can be designated as short-term leases to ensure the continuity of critical operations on high-priority nodes. For instance, the lease update frequency for high-priority nodes can be set to once per minute. Leases for medium-priority nodes can be designated as medium-term leases to balance the performance and resource consumption of medium-priority nodes. For instance, the lease update frequency for medium-priority nodes can be set to once every 5 minutes. Leases for low-priority nodes can be designated as long-term leases to conserve resources consumed by low-priority nodes. For instance, the lease update frequency for low-priority nodes can be set to once every 15 minutes.

[0034] In practical applications, steps 101 to 102 can be implemented based on a processor, which can be at least one of the following: Application Specific Integrated Circuit (ASIC), Digital Signal Processor (DSP), Digital Signal Processing Device (DSPD), Programmable Logic Device (PLD), Field Programmable Gate Array (FPGA), Central Processing Unit (CPU), Controller, Microcontroller, and Microprocessor.

[0035] As can be seen, in this embodiment, the update frequency of the lease corresponding to the node to be processed can be accurately determined according to the priority of the node to be processed in the Kubernetes cluster. By updating the lease corresponding to the node to be processed, the heartbeat of the node to be processed can be simulated. Therefore, this embodiment can simulate node heartbeats without the need for Kubelet instances, so that the control plane can obtain the status of the node to be processed in the Kubernetes cluster in a timely manner. Compared with the related technologies, which send heartbeats to the API server by running a large number of Kubelet instances, this embodiment can reduce resource consumption to a certain extent.

[0036] In some implementations of determining the node to be processed in a Kubernetes cluster, the node to be processed can be selected from the fake nodes in the Kubernetes cluster; that is, the node to be processed is a pre-selected fake node. Here, the fake node can be a pre-created virtual node.

[0037] As can be seen, the embodiments of this application can simulate the heartbeat of nodes in a Kubernetes cluster by determining the update frequency of the leases corresponding to fake nodes, even when the update frequency of the leases corresponding to real nodes in the Kubernetes cluster is uncertain. This can reduce the resource consumption caused by maintaining real nodes to a certain extent.

[0038] Regarding the management method of pending nodes, in some embodiments, a pending node can be created in the Kubernetes cluster when a node creation request is received; or, the status of the pending node can be updated when a node status update request is received; or, the pending node can be deleted when a node deletion request is received.

[0039] As can be seen, dummy nodes consume fewer maintenance and management resources compared to real nodes in a Kubernetes cluster. When the node to be processed is a dummy node, this embodiment can quickly create, update, or delete the node, improving development and testing efficiency. For example, this embodiment can achieve second-level operations (e.g., creation, deletion, and status update operations) on the Kubernetes cluster and the node to be processed, thereby enabling rapid startup and simulation of the Kubernetes cluster.

[0040] In some implementations of determining the priority of nodes to be processed in a Kubernetes cluster, the priority of nodes to be processed can be determined based on reference information, which includes at least one of the following: the resource utilization rate of the node to be processed and the priority setting value of the node to be processed.

[0041] For example, the resource utilization rate of the node to be processed can be the utilization rate of resources such as CPU and memory, and the value range of the resource utilization rate of the node to be processed can be [0, 100%]. When the node to be processed is node i, the resource utilization rate of the node to be processed can be denoted as Ui.

[0042] The priority setting value of the node to be processed can be determined based on the priority annotation information set by the administrator. For example, the priority annotation information set by the administrator for the node to be processed can be strings such as "High", "Medium", "Low" etc. The priority annotation information set by the administrator can be converted into a priority setting value in a certain way.

[0043] For example, when the node to be processed is node i, the priority annotation information set by the administrator for node i can be denoted as Ai. After determining the priority annotation information Ai for node i, the priority annotation information Ai can be converted into the priority setting value score(Ai) for node i. For example, if Ai="High", then score(Ai)=100; if Ai="Medium", then score(Ai)=50; if Ai="Low", then score(Ai)=0.

[0044] When the node to be processed is node i, the priority of the node to be processed can be denoted as Pi. For example, the priority Pi of node i can be high priority, medium priority or low priority.

[0045] In practical applications, a node priority allocation algorithm can be used to process the priority annotation information and / or resource utilization of the node to be processed, thereby obtaining the priority of the node to be processed. For example, Ai and Ui can be used as input data of the priority calculation model. In the priority calculation model, the node priority allocation algorithm is used to process the data to obtain the priority Pi of node i, and the priority Pi of node i is used as the output data of the priority calculation model.

[0046] As can be seen, the embodiments of this application can reasonably and accurately determine the priority of the node to be processed based on the resource utilization rate or priority setting value of the node to be processed.

[0047] In some embodiments of the implementation of determining the priority of a node to be processed based on reference information, the priority score of the node to be processed can be determined based on the reference information; and the priority of the node to be processed can be determined based on the priority score. In this way, the priority score of the node to be processed can be determined more reasonably and accurately based on the resource utilization rate or the priority setting value of the node to be processed, thereby determining the priority of the node to be processed more accurately based on the priority score.

[0048] In some embodiments, the priority score can be obtained by weighted summing of the resource utilization rate and the priority setting value when the reference information includes the resource utilization rate and the priority setting value.

[0049] Here, the weight of resource utilization can be denoted as R, where R represents the impact of resource utilization on priority score. The value of R can be adjusted according to actual needs. The value of R ranges from 0 to 1, for example, R = 0.6. The weight of priority setting value can be denoted as A, where A represents the impact of priority setting value on priority score. The value of A ranges from 0 to 1, for example, A = 0.4. For example, the sum of A and R is 1.

[0050] After determining the resource utilization rate of node i and the priority setting value of node i, the priority score Si of node i can be calculated according to formula (1).

[0051] Si = R * Ui + A * score(Ai) (1)

[0052] After determining the priority score Si of node i, the priority Pi of node i can be determined based on the priority score Si. For example, if Si ≥ 80, then Pi is a high priority; if 50 ≤ Si < 80, then Pi is a medium priority; and if Si < 50, then Pi is a low priority.

[0053] In a specific example, node i has a resource utilization rate Ui=75%, and its priority annotation Ai="Medium", R=0.6, A=0.4. According to formula (1), node i's priority score Si can be calculated as Si=0.6×75+0.4×50=45+20=65. Therefore, based on node i's priority score Si, Pi can be determined as a medium priority.

[0054] It should be noted that the above description is merely an example of a priority allocation algorithm, and other priority allocation algorithms may also be used in the embodiments of this application.

[0055] As can be seen, the embodiments of this application can determine the priority score of a node more accurately by comprehensively considering the node's resource utilization rate and priority setting value, which is conducive to accurately determining the priority of the node.

[0056] The embodiments of this application can also control the state of nodes. In some embodiments, after creating a node to be processed in a Kubernetes cluster, the current state of the node to be processed can be controlled according to the predetermined lifecycle information of the node to be processed. The lifecycle information is used to indicate the state of the node to be processed at different times within its own lifecycle.

[0057] To represent the state changes of nodes in a Kubernetes cluster throughout their entire lifecycle, the Node Stage Simulation Protocol (NSSP) can be used to describe lifecycle information. The NSSP not only describes the state of a node at a given stage but also continuously tracks the transition information from one state to another.

[0058] For example, a Custom Resource Definition (CRD) structure can be defined, and the defined CRD structure can be denoted as a NodeStage. The defined CRD structure carries the state of a single node in a single stage.

[0059] For example, the specific contents of a CRD structure include:

[0060] 1) Stage: String type, representing the stage identifier, such as "S0", "S1", "S2", etc.

[0061] 2) Node ID: String type, a unique identifier for a node. For example, a node's unique identifier can be "N1", "N2", etc.

[0062] 3) Status: String type, describes the specific status of the node in the current stage. The status can be "normal", "CPU high pressure", "not ready", etc.

[0063] 4) Duration: String type, describes the duration of the state.

[0064] 5) Identifier for the next stage. Here, the identifier for the next stage is optional; that is, in some embodiments, the CRD structure may not include the identifier for the next stage.

[0065] In a Kubernetes cluster, node lifecycle management is a complex and critical task. By introducing the CRD structure, different stages of a node's lifecycle can be defined and simulated.

[0066] For an implementation that uses a node phase simulation protocol to describe lifecycle information, for example, when using a CRD structure, the multiple phase descriptions of each node can be organized into a list, with each phase describing the changes in the node's state in sequence. For instance, Table 1 can describe the lifecycle information of a node whose identity document (ID) is used.

[0067] Table 1

[0068]

[0069] In practical applications, the controller can listen to events (creation, status update, deletion, etc.) of the above CRD structure and nodes. Through the CRD structure and node phase simulation protocol, the lifecycle of the node to be processed with a specific label can be dynamically managed.

[0070] When designating the node with ID N1 as the target node, refer to the lifecycle information shown in Table 1. After the target node enters the Kubernetes cluster, the controller can read and record the target node's metadata, such as creation time and current status. If the node's current status does not match the node status in the lifecycle information, the node's status can be modified to match the node status in the lifecycle information.

[0071] Referring to the lifecycle information shown in Table 1, the target node is in a normal state during phase S0. After 30 minutes following the creation of the target node, it enters phase S1. In phase S1, the controller can change the target node's state to high voltage to simulate a high CPU load scenario. After 30 minutes following phase S1, it enters phase S2. In phase S2, the controller can change the target node's state to not ready. This embodiment can also simulate the states of other nodes, thereby achieving state simulation for individual nodes or batches of nodes.

[0072] As can be seen, the embodiments of this application can flexibly control the current state of the node to be processed based on the predetermined life cycle information of the node to be processed. This is beneficial for simulating different states of the node within its own life cycle and for meeting the testing requirements of the test scenario for nodes in different states.

[0073] The embodiments of this application can simulate a large-scale Kubernetes cluster without consuming a lot of resources. By adopting techniques that simulate node and Pod lifecycles, virtual nodes are generated and node state updates are simulated, thus creating a Kubernetes cluster similar to a real cluster.

[0074] The node management method in this application embodiment can be implemented through a hierarchical lease controller and a node phase controller. The hierarchical lease controller can report node heartbeats by creating and updating node leases. The node phase controller can be used to select nodes to be simulated and simulate the life cycle of nodes by updating node states.

[0075] See Figure 2The API server can perform watch operations or other operations on nodes and leases. The hierarchical lease controller can perform watch operations on nodes and fake nodes, and perform operations such as creation, update, and deletion on the leases (fakeLease) corresponding to fake nodes.

[0076] In this embodiment, the heartbeats of multiple nodes can be simulated in parallel using a hierarchical lease controller. For example, the hierarchical lease controller can filter out dummy nodes that need to be processed based on predefined conditions. These filtered nodes need to be managed and simulated by the hierarchical lease controller. To ensure that the node phase controller effectively simulates the heartbeats of nodes and efficiently manages the selected dummy nodes, a hierarchical lease priority management protocol (HLPLM) can be used to determine the update frequency of the leases corresponding to the dummy nodes. That is, the update frequency of the leases corresponding to these dummy nodes can be determined based on the priority of the selected dummy nodes. The implementation method for determining the update frequency of the leases corresponding to nodes has been described in the foregoing embodiments and will not be repeated here.

[0077] By implementing a hierarchical priority lease management protocol, the node phase controller can not only more effectively simulate node heartbeats but also perform customized management based on the characteristics and dependencies of different nodes, thereby improving the stability and response speed of the Kubernetes cluster. The hierarchical priority lease management protocol is innovative in design and specifically addresses the node management problems in large-scale distributed systems.

[0078] In a Kubernetes cluster, node state is typically controlled by a Kubelet. In this embodiment, the node phase controller simulates node behavior by directly managing node resources. This approach avoids running a large number of Kubelet instances, thereby reducing resource consumption.

[0079] See Figure 3 The node stage controller can perform Watch operations on node stages, initialize information for dummy nodes, and maintain the state of dummy nodes based on their stages. For example, the node stage controller can continuously monitor all nodes in the Kubernetes cluster using a list and watch mechanism, and can capture node addition, modification, and deletion events. The node stage controller can also select nodes for state simulation based on predefined conditions. For the selected nodes requiring state simulation, node state management can be performed based on lifecycle information.

[0080] The node management method of this application has the advantage of low resource consumption. Specifically, by simulating node heartbeats and lifecycles, it can avoid running a large number of Kubelet instances, thereby reducing hardware resource and time consumption. Furthermore, in this application embodiment, by employing a node phase simulation protocol, different nodes can be flexibly defined and simulated in terms of type, label, taint, capacity, and conditions, thus meeting the needs of various testing scenarios. Furthermore, this application embodiment, by leveraging the node phase simulation protocol and controller to automatically manage node states, reduces the workload of manual intervention and improves the efficiency of node management.

[0081] The technical solution adopted in this application embodiment can quickly and flexibly simulate the behavior of large-scale Kubernetes cluster nodes and Pods with low resource consumption, and can quickly simulate different states and events of nodes in their life cycle, which significantly improves the development and testing efficiency of Kubernetes clusters, achieves the goal of cost reduction and efficiency improvement, and is applicable to various scenarios for developing, testing and learning Kubernetes clusters.

[0082] Those skilled in the art will understand that, in the above-described method of the specific implementation, the order in which each step is written does not imply a strict execution order and does not constitute any limitation on the implementation process. The specific execution order of each step should be determined by its function and possible internal logic.

[0083] Figure 4 This is a schematic diagram of the node management device according to an embodiment of this application, as shown below. Figure 4 As shown, the device includes:

[0084] Module 401 is used to determine the priority of nodes to be processed in the Kubernetes cluster;

[0085] The processing module 402 is used to determine the update frequency of the lease corresponding to the node to be processed based on the priority of the node to be processed.

[0086] In some embodiments, the determining module 401 is specifically used to determine the priority of the node to be processed based on reference information, the reference information including at least one of the following: the resource utilization rate of the node to be processed and the priority setting value of the node to be processed.

[0087] In some embodiments, the determining module 401 is specifically used to determine the priority score of the node to be processed based on the reference information; and to determine the priority of the node to be processed based on the priority score.

[0088] In some embodiments, the determining module 401 is specifically used to perform a weighted summation of the resource utilization rate and the priority setting value when the reference information includes the resource utilization rate and the priority setting value, to obtain the priority score.

[0089] In some embodiments, the update frequency is positively correlated with the priority.

[0090] In some embodiments, the processing module 402 is further configured to, after creating the node to be processed in the Kubernetes cluster, control the current state of the node to be processed according to the predetermined lifecycle information of the node to be processed; the lifecycle information is at least used to indicate the state of the node to be processed at different times within its own lifecycle.

[0091] In some embodiments, the node to be processed is a pre-selected dummy node.

[0092] In some embodiments, the processing module 402 is further configured to create the node to be processed in the Kubernetes cluster when a node creation request is received; or to update the status of the node to be processed when a node status update request is received; or to delete the node to be processed when a node deletion request is received.

[0093] In practical applications, the determination module 401 and the processing module 402 can be implemented based on a processor.

[0094] It should be noted that the description of the above device embodiments is similar to the description of the above method embodiments, and has similar beneficial effects. For technical details not disclosed in the device embodiments of this application, please refer to the description of the method embodiments of this application for understanding.

[0095] It should be noted that, in the embodiments of this application, if the above-described methods are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiments of this application, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a terminal, server, etc.) to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), magnetic disks, or optical disks. Thus, the embodiments of this application are not limited to any specific hardware and software combination.

[0096] Correspondingly, this application embodiment further provides a computer program product, the computer program product including computer executable instructions, which are used to implement any of the node management methods provided in this application embodiment.

[0097] Accordingly, this application embodiment further provides a computer storage medium storing computer-executable instructions, which are used to implement any of the node management methods provided in the above embodiments.

[0098] This application also provides an electronic device. Figure 5 This is a schematic diagram of the composition structure of an electronic device provided in an embodiment of this application, as shown below. Figure 5 As shown, the electronic device 50 may include:

[0099] Memory 501 is used to store executable instructions;

[0100] The processor 502 is used to implement any of the above-described node management methods when executing executable instructions stored in the memory 501.

[0101] The processor 502 mentioned above can be at least one of ASIC, DSP, DSPD, PLD, FPGA, CPU, controller, microcontroller, and microprocessor.

[0102] The aforementioned computer-readable storage medium and memory 501 may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a magnetic random access memory (FRAM), a flash memory, a magnetic surface memory, an optical disc, or a compact disc read-only memory (CD-ROM), etc.; or it may be various terminals that include one or any combination of the above-mentioned memories, such as mobile phones, computers, tablet devices, personal digital assistants, etc.

[0103] In some embodiments, the functions or modules of the apparatus provided in this application can be used to perform the methods described in the above method embodiments. The specific implementation can be referred to the description of the above method embodiments, and for the sake of brevity, it will not be repeated here.

[0104] The description of the various embodiments above tends to emphasize the differences between the various embodiments. The similarities or similarities between them can be referred to, and for the sake of brevity, they will not be repeated here.

[0105] The methods disclosed in the various method embodiments provided in this application can be arbitrarily combined to obtain new method embodiments without conflict.

[0106] The features disclosed in the various product embodiments provided in this application can be arbitrarily combined without conflict to obtain new product embodiments.

[0107] The features disclosed in the various method or device embodiments provided in this application can be arbitrarily combined without conflict to obtain new method or device embodiments.

[0108] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of 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. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0109] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the scope of protection of this application. All of these forms are within the protection scope of this application.

Claims

1. A node management method, characterized in that, The method includes: Determine the priority of nodes to be processed in the Kubernetes cluster; the nodes to be processed are one or more nodes selected from the Kubernetes cluster according to predefined conditions; the nodes to be processed include pre-selected dummy nodes, which are pre-created virtual nodes; The update frequency of the lease corresponding to the node to be processed is determined based on the priority of the node to be processed; the update frequency is positively correlated with the priority.

2. The method according to claim 1, characterized in that, Determining the priority of nodes to be processed in the Kubernetes cluster includes: The priority of the node to be processed is determined based on reference information, which includes at least one of the following: the resource utilization rate of the node to be processed and the priority setting value of the node to be processed.

3. The method according to claim 2, characterized in that, Determining the priority of the node to be processed based on reference information includes: The priority score of the node to be processed is determined based on the reference information; The priority of the node to be processed is determined based on the priority score.

4. The method according to claim 3, characterized in that, Determining the priority score of the node to be processed based on the reference information includes: When the reference information includes the resource utilization rate and the priority setting value, the priority score is obtained by weighted summation of the resource utilization rate and the priority setting value.

5. The method according to claim 1, characterized in that, The method further includes: After the node to be processed is created in the Kubernetes cluster, the current state of the node to be processed is controlled according to the pre-determined lifecycle information of the node to be processed; the lifecycle information is used to indicate the state of the node to be processed at different times within its own lifecycle.

6. The method according to claim 1, characterized in that, The method further includes: creating the node to be processed in the Kubernetes cluster when a node creation request is received; or updating the status of the node to be processed when a node status update request is received; or deleting the node to be processed when a node deletion request is received.

7. A node management device, characterized in that, The device includes: The determination module is used to determine the priority of nodes to be processed in the Kubernetes cluster; the nodes to be processed are one or more nodes selected from the Kubernetes cluster according to predefined conditions; the nodes to be processed include pre-selected dummy nodes, which are pre-created virtual nodes; The processing module is used to determine the update frequency of the lease corresponding to the node to be processed based on the priority of the node to be processed; the update frequency is positively correlated with the priority.

8. An electronic device, characterized in that, The electronic device includes a processor and a memory for storing computer programs capable of running on the processor; wherein, The processor is used to run the computer program to perform the node management method according to any one of claims 1 to 6.

9. A computer storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the node management method according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the node management method according to any one of claims 1 to 6.

Images