Cluster management method based on cloud management platform, and cloud management platform

Abstract

Disclosed in the present application are a cluster management method based on a cloud management platform, and a cloud management platform, which can maintain cross-cluster communication between micro-services of tenants and ensure the availability of an entire cloud service system, such that the service requirements of the tenants can be met. The method in the present application comprises: by means of a management interface, a cloud management platform receiving a management policy sent by a tenant for a cluster of the tenant, wherein the management policy is used for instructing the execution of a management operation on the cluster when a Core-DNS component or a Kube-proxy component or a micro-service is in an unavailable state; on the basis of the management policy, the cloud management platform creating a liveness probe component for the cluster, wherein the liveness probe component is used for performing a liveness probe on the Core-DNS component or the Kube-proxy component or the micro-service, so as to obtain a liveness probe result, and providing the liveness probe result to the cloud management platform; and if it is determined on the basis of the liveness probe result that the Core-DNS component or the Kube-proxy component or the micro-service is in the unavailable state, the cloud management platform executing the management operation on the cluster, wherein the management operation includes at least one of the following: migrating a node and draining traffic.

Description

A cluster management method based on cloud management platform and cloud management platform

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on February 8, 2024, with application number 202410178062.5 and invention name “A cluster management method and cloud management platform based on cloud management platform”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The embodiments of the present application relate to the field of cloud technology, and in particular to a cluster management method based on a cloud management platform and a cloud management platform. Background Art

[0003] With the widespread adoption of Kubernetes, more and more tenants are choosing to deploy their microservices in cloud service systems built on Kubernetes. In these cloud service systems, a tenant's microservice can run across multiple clusters provided by the system, effectively meeting tenants' business needs.

[0004] In related technologies, a cloud service system may include a cloud management platform and multiple clusters it creates for tenants. For any of the multiple clusters, the cluster may include multiple nodes, each of which runs a tenant's microservice. In this way, the microservice runs on each node in the tenant's multiple clusters. When a cluster receives traffic directed to the microservice, it can send the traffic to the microservice on each node in the multiple clusters for processing, thereby completing the tenant's business.

[0005] To ensure the smooth operation of tenant services, the cloud management platform must monitor the status of each cluster in real time. Typically, the cloud management platform monitors the interfaces (Kube-apisever) that connect each cluster to the cloud management platform. If the cloud management platform determines that a particular interface is functioning properly, it assumes that the corresponding cluster is functioning properly. However, if the interface is functioning properly but a fault occurs within the cluster, the cloud management platform will be unable to promptly address the faulty cluster, and the entire system will be unable to complete tenant services. Summary of the Invention

[0006] The embodiments of the present application provide a cluster management method and a cloud management platform based on a cloud management platform, which can maintain cross-cluster communication between tenants' microservices, ensure the availability of the entire cloud service system, and thus meet the business needs of tenants.

[0007] The first aspect of the embodiment of the present application provides a cluster management method based on a cloud management platform, which is used to manage a tenant's cluster, and the cluster includes a Core-DNS component and multiple nodes. For any one of the multiple nodes, the node includes a Kube-proxy component and multiple microservices of the tenant. When the source microservice of the node needs to access the target microservice, the source microservice of the node can generate traffic directed to the target microservice and send it to the Core-DNS component of the cluster. The Core-DNS component of the cluster can parse the relevant information of the target microservice for these traffics and return it to the source microservice of the node, so that the source microservice of the node forwards these traffics to the Kube-proxy component of the node based on the relevant information of the target microservice. In this way, the Kube-proxy component of the node can forward these traffics to the target microservices of each node for processing. The method includes:

[0008] When a tenant needs to develop a unique management policy for their cluster, the cloud management platform provides a management interface for the tenant, allowing the tenant to enter the management policy for the cluster through their client. It should be noted that the management policy for the cluster can be used to indicate that management operations should be performed on the cluster when the Core-DNS component of the cluster, the Kube-proxy component of each node of the cluster, or one or more microservices of the cluster are unavailable.

[0009] After obtaining the tenant's management policy for the cluster, the cloud management platform can create a dedicated liveness detection component for the cluster based on the cluster's management policy. This component can then perform real-time liveness detection on the cluster's Core-DNS component, the Kube-proxy component on each node, and each microservice on each node, generating liveness detection results and returning them to the cloud management platform.

[0010] After obtaining the detection results fed back by the detection component of the cluster, if the cloud management platform determines based on the detection results that the Core-DNS component of the cluster or the Kube-proxy component of each node in the cluster or a microservice in the cluster is in an unavailable state, the cloud management platform can perform management operations on the cluster as indicated by the management policy of the cluster.

[0011] The above method demonstrates that when a tenant needs to establish a dedicated management policy for a particular cluster, they can input the cluster-specific management policy into the management interface provided by the cloud management platform. This cluster-specific management policy indicates that management operations can be performed on the cluster when the cluster's Core-DNS component, the cluster's Kube-proxy component, or a microservice within the cluster is unavailable. The cloud management platform then creates a dedicated liveness detection component for the cluster based on the cluster-specific management policy. This liveness detection component detects the cluster's Core-DNS component, the cluster's Kube-proxy component, and the cluster's microservices, generating liveness detection results and providing them to the cloud management platform. Finally, if the liveness detection results determine that the cluster's Core-DNS component, the cluster's Kube-proxy component, or the cluster's microservice is unavailable, the cloud management platform performs the management operations indicated by the cluster-specific management policy on the cluster. These operations include migrating nodes within the cluster, migrating microservices within the cluster, and removing traffic directed to the cluster's microservices. In the above process, the cloud management platform can create a detection component for the cluster based on the management policy formulated by the tenant for its cluster. Therefore, the cloud management platform can use the detection component to determine whether the components within the cluster (for example, the Core-DNS component of the cluster or the Kube-proxy component of the cluster or the microservices of the cluster, etc.) are in an unavailable state. If so, the cloud management platform will execute the management operations indicated by the management policy on the cluster to avoid the impact of the unavailable cluster on other clusters, thereby maintaining cross-cluster communication between the tenant's microservices and ensuring the availability of the entire cloud service system, so as to meet the tenant's business needs.

[0012] In one possible implementation, the Core-DNS component is used to perform domain name resolution on traffic, obtain domain name resolution results, and enable the Kube-proxy component to send traffic to the microservice based on the domain name resolution results. The liveness detection component is used to enable the Core-DNS component to perform domain name resolution tasks to obtain liveness detection results, wherein if the Core-DNS component fails to successfully perform the domain name resolution task, the liveness detection result is used to indicate that the Core-DNS component is in an unavailable state. In the aforementioned implementation, for any one of the multiple nodes in the cluster, the node includes a Kube-proxy component and multiple microservices. The Core-DNS component of the cluster is used to perform domain name resolution on the received traffic directed to a certain microservice, so that the Kube-proxy component of the node forwards the traffic to the microservice of the node based on the domain name resolution results. Then, the liveness detection component of the cluster can send a domain name resolution task to the Core-DNS component of the cluster, so that the Core-DNS component of the cluster performs the domain name resolution task, thereby obtaining a liveness detection result. It should be noted that if the cluster's Core-DNS component fails to successfully perform domain name resolution, it may indicate a failure. Therefore, the liveness detection result can be used to indicate that the cluster's Core-DNS component is unavailable. Therefore, by probing the domain name resolution function of the cluster's Core-DNS component, you can accurately obtain the liveness detection result of the cluster's Core-DNS component.

[0013] In one possible implementation, the liveness detection component is used to enable the Core-DNS component to perform domain name resolution tasks multiple times to obtain a liveness detection result, wherein if the number of times the Core-DNS component fails to successfully perform the domain name resolution task is greater than or equal to a preset first threshold, the liveness detection result is used to indicate that the Core-DNS component is in an unavailable state. In the aforementioned implementation, the liveness detection component of the cluster can enable the Core-DNS component of the cluster to perform domain name resolution tasks multiple times, thereby obtaining a liveness detection result. It should be noted that if the number of times the Core-DNS component of the cluster fails to successfully perform the domain name resolution task is greater than or equal to a preset first threshold, the liveness detection result can be used to indicate that the Core-DNS component of the cluster is in an unavailable state. There may be two reasons why the Core-DNS component of the cluster cannot successfully perform the domain name resolution task. The first reason is that the Core-DNS component of the cluster has indeed failed and cannot successfully perform the domain name resolution task and is in an unavailable state. The second reason is that there is a problem in the network between the Core-DNS component of the cluster and the detection component of the cluster, which makes the Core-DNS component of the cluster unable to perform the domain name resolution task. Therefore, using this multiple detection method can more accurately obtain the detection results of the Core-DNS component of the cluster.

[0014] In one possible implementation, the Kube-proxy component is used to load balance the microservices based on the domain name resolution result, obtain the load balancing result, and distribute the traffic to the microservices based on the load balancing result. The liveness detection component is used to make the Kube-proxy component perform the load balancing task to obtain the liveness detection result, wherein, if the Kube-proxy component fails to successfully perform the load balancing task, the liveness detection result is used to indicate that the Kube-proxy component is in an unavailable state. In the aforementioned implementation, for any one of the multiple nodes in the cluster, the node includes the Kube-proxy component and multiple microservices of the tenant, and the Core-DNS component of the cluster is used to perform domain name resolution on the traffic received to a certain microservice, so as to provide the domain name resolution result and these traffic to the Kube-proxy component of the node in a certain manner. The Kube-proxy component of the node can coordinate with the other nodes to perform load balancing based on the domain name resolution result, so as to distribute these traffic to the corresponding microservices of all nodes based on the load balancing result. The cluster's liveness detection component can then send load balancing tasks to the Kube-proxy component of each node, ensuring that each node's Kube-proxy component performs the load balancing task, thereby obtaining a liveness detection result. It should be noted that if the Kube-proxy component of each node fails to successfully perform the load balancing task, the liveness detection result can be used to indicate that the Kube-proxy component of the cluster is unavailable. Therefore, by detecting the load balancing function of the cluster's Kube-proxy component, the liveness detection result of the cluster's Kube-proxy component can be accurately obtained.

[0015] In one possible implementation, a cluster includes multiple nodes, one node includes a Kube-proxy component, and the liveness detection component is used to enable multiple Kube-proxy components on multiple nodes to perform load balancing tasks to obtain liveness detection results, wherein, if, among multiple Kube-proxy components, the number of Kube-proxy components that have not successfully performed the load balancing task is greater than or equal to a preset second threshold, the liveness detection result is used to indicate that multiple Kube-proxy components are in an unavailable state. In the aforementioned implementation, the liveness detection component can use the following judgment rule: in the cluster, if the number of Kube-proxy components that have not successfully performed the load balancing task is greater than or equal to the preset second threshold, it means that a large proportion of the Kube-proxy components of the nodes in the cluster are unavailable, and the liveness detection result generated by the liveness detection component of the cluster can be used to indicate that multiple Kube-proxy components are in an unavailable state. It can be seen that by adopting this proportional judgment method, the liveness detection result of the Kube-proxy component of the cluster can be obtained more accurately.

[0016] In one possible implementation, the liveness detection component is further configured to collect microservice information and generate a liveness detection result based on the information. If the information indicates that the load of the microservice is greater than or equal to a preset third threshold, the liveness detection result indicates that the microservice is unavailable. In the aforementioned implementation, by detecting the load of the microservices in the cluster, the liveness detection results of the microservices in the cluster can be accurately obtained.

[0017] In one possible implementation, the liveness detection component is further configured to collect microservice information and generate a liveness detection result based on the information. If the information indicates that a microservice is inaccessible, the liveness detection result indicates that the microservice is unavailable. In the aforementioned implementation, by detecting the accessibility of the cluster's microservices, accurate liveness detection results for the cluster's microservices can be obtained.

[0018] In one possible implementation, the management policy is also used to indicate that when the cluster is in an operation and maintenance state, an operation and maintenance operation is performed on the cluster. The method also includes: the cloud management platform receives a state setting request sent by the tenant through the management interface, and the state setting request is used to instruct the tenant to set the state of the cluster to an operation and maintenance state; the cloud management platform performs an operation and maintenance operation on the cluster based on the state setting request, and the operation and maintenance operation includes: isolating the cluster. In the aforementioned implementation, the management policy for the cluster can also be used to indicate that when the cluster is in an operation and maintenance state, an operation and maintenance operation is performed on the cluster. Then, when the tenant needs to put the cluster into an operation and maintenance state, the tenant can input a state setting request for the cluster through the management interface provided by the cloud management platform, and the state setting request is used to instruct the tenant to set the state of the cluster to an operation and maintenance state. After receiving the state setting request, the cloud management platform can perform the operation and maintenance operation indicated by the management policy formulated by the tenant for the cluster based on the state setting request. For example, the cloud management platform can isolate the cluster, etc. It can be seen from this that when a tenant puts its cluster in the operation and maintenance state, the cloud management platform can isolate the cluster to ensure the stability of the cluster's business in the operation and maintenance state until it is released from the operation and maintenance state and enters normal working state.

[0019] In one possible implementation, the node, the Core-DNS component, and the liveness detection component are any of the following: a virtual machine, a container, a micro virtual machine, a physical server, and a bare metal server.

[0020] The second aspect of an embodiment of the present application provides a cloud management platform, which is used to manage a tenant's cluster. The cluster includes a Core-DNS component and a node. The node includes a Kube-proxy component and a microservice. The Core-DNS component is used to enable the Kube-proxy component to forward traffic directed to the microservice to the microservice. The cloud management platform includes: a receiving module, which is used to receive a management policy for the cluster sent by the tenant through a management interface. The management policy is used to indicate that when the Core-DNS component or the Kube-proxy component or the microservice is in an unavailable state, a management operation is performed on the cluster; a creation module, which is used to create a detection component for the cluster based on the management policy. The detection component is used to detect the Core-DNS component, the Kube-proxy component and the microservice, obtain the detection result, and provide the detection result to the cloud management platform; an execution module, which is used to perform management operations on the cluster if it is determined that the Core-DNS component or the Kube-proxy component or the microservice is in an unavailable state based on the detection result. The management operation includes at least one of the following: migrating nodes and removing traffic.

[0021] In one possible implementation, the Core-DNS component is used to perform domain name resolution on the traffic, obtain the domain name resolution result, and enable the Kube-proxy component to send the traffic to the microservice based on the domain name resolution result. The liveness detection component is used to enable the Core-DNS component to perform the domain name resolution task to obtain the liveness detection result. If the Core-DNS component fails to successfully perform the domain name resolution task, the liveness detection result is used to indicate that the Core-DNS component is in an unavailable state.

[0022] In one possible implementation, the liveness detection component is used to cause the Core-DNS component to perform the domain name resolution task multiple times to obtain a liveness detection result, wherein, if the number of times the Core-DNS component fails to successfully perform the domain name resolution task is greater than or equal to a preset first threshold, the liveness detection result is used to indicate that the Core-DNS component is in an unavailable state.

[0023] In one possible implementation, the Kube-proxy component is used to load balance microservices based on domain name resolution results, obtain load balancing results, and distribute traffic to microservices based on the load balancing results. The liveness detection component is used to enable the Kube-proxy component to perform load balancing tasks to obtain liveness detection results. If the Kube-proxy component fails to successfully perform the load balancing task, the liveness detection result is used to indicate that the Kube-proxy component is in an unavailable state.

[0024] In one possible implementation, a cluster includes multiple nodes, one node includes a Kube-proxy component, and the liveness detection component is used to enable multiple Kube-proxy components on multiple nodes to perform load balancing tasks to obtain liveness detection results, wherein, if, among the multiple Kube-proxy components, the number of Kube-proxy components that fail to successfully perform the load balancing task is greater than or equal to a preset second threshold, the liveness detection result is used to indicate that the multiple Kube-proxy components are in an unavailable state.

[0025] In one possible implementation, the activity detection component is also used to collect information about the microservice and generate an activity detection result based on the information, wherein if the information is used to indicate that the load of the microservice is greater than or equal to a preset third threshold, the activity detection result is used to indicate that the microservice is in an unavailable state.

[0026] In one possible implementation, the liveness detection component is further used to collect information about the microservice and generate a liveness detection result based on the information. If the information indicates that the microservice is inaccessible, the liveness detection result indicates that the microservice is in an unavailable state.

[0027] In one possible implementation, the management policy is also used to instruct the cluster to perform operation and maintenance operations on the cluster when it is in an operation and maintenance state. The receiving module is also used to receive a status setting request sent by the tenant through the management interface. The status setting request is used to instruct the tenant to set the status of the cluster to an operation and maintenance state. The execution module is also used to perform operation and maintenance operations on the cluster based on the status setting request. The operation and maintenance operations include: isolating the cluster.

[0028] In one possible implementation, the node, the Core-DNS component, and the liveness detection component are any of the following: a virtual machine, a container, a micro virtual machine, a physical server, and a bare metal server.

[0029] A third aspect of an embodiment of the present application provides a computing device cluster, which includes at least one computing device, each computing device including a processor and a memory: the memory is used to store instructions; the processor is used to enable the computing device cluster to execute the method described in the first aspect or any possible implementation method of the first aspect according to the instructions.

[0030] A fourth aspect of an embodiment of the present application provides a computer storage medium, which stores one or more instructions. When the instructions are executed by one or more computers, the one or more computers implement the method described in the first aspect or any possible implementation method of the first aspect.

[0031] A fifth aspect of the embodiments of the present application provides a computer program product, which stores instructions. When the instructions are executed by a computer, the computer implements the method described in the first aspect or any possible implementation method of the first aspect.

[0032] In an embodiment of the present application, when a tenant needs to formulate an exclusive management policy for a cluster of the tenant, the tenant can input the management policy for the cluster into the management interface provided by the cloud management platform. The management policy for the cluster is used to indicate that when the Core-DNS component of the cluster or the Kube-proxy component of the cluster or a microservice of the cluster is in an unavailable state, management operations can be performed on the cluster. Then, the cloud management platform can create an exclusive liveness detection component for the cluster based on the management policy for the cluster. The liveness detection component of the cluster can detect the Core-DNS component of the cluster, the Kube-proxy component of the cluster and the microservices of the cluster, thereby obtaining the liveness detection result and providing the liveness detection result to the cloud management platform. Finally, if it is determined based on the liveness detection result that the Core-DNS component of the cluster or the Kube-proxy component of the cluster or the microservice of the cluster is in an unavailable state, the cloud management platform performs the management operations indicated by the management policy for the cluster on the cluster. The management operations include migrating the nodes of the cluster, migrating the microservices of the cluster and removing the traffic directed to the microservices of the cluster, etc. In the above process, the cloud management platform can create a detection component for the cluster based on the management policy formulated by the tenant for its cluster. Therefore, the cloud management platform can use the detection component to determine whether the components within the cluster (for example, the Core-DNS component of the cluster or the Kube-proxy component of the cluster or the microservices of the cluster, etc.) are in an unavailable state. If so, the cloud management platform will execute the management operations indicated by the management policy on the cluster to avoid the impact of the unavailable cluster on other clusters, thereby maintaining cross-cluster communication between the tenant's microservices and ensuring the availability of the entire cloud service system, so as to meet the tenant's business needs. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] FIG1 is a schematic diagram of the structure of a cloud service system provided in an embodiment of the present application;

[0034] FIG2 is another schematic diagram of the structure of the cloud service system provided in an embodiment of the present application;

[0035] FIG3 is another schematic diagram of the structure of the cloud service system provided in an embodiment of the present application;

[0036] FIG4 is a flow chart of a cluster management method based on a cloud management platform according to an embodiment of the present application;

[0037] FIG5 is a schematic diagram of a tenant interface provided in an embodiment of the present application;

[0038] FIG6 is a schematic diagram of a tenant interface provided in an embodiment of the present application;

[0039] FIG7 is another schematic diagram of the structure of the cloud service system provided in an embodiment of the present application;

[0040] FIG8 is another structural diagram of the cloud service system provided in an embodiment of the present application;

[0041] FIG9 is another schematic diagram of a tenant interface provided in an embodiment of the present application;

[0042] FIG10 is a schematic diagram of the structure of a cloud management platform provided in an embodiment of the present application;

[0043] FIG11 is a schematic diagram of the structure of a computing device provided in an embodiment of the present application;

[0044] FIG12 is a schematic diagram of a structure of a computing device cluster provided in an embodiment of the present application;

[0045] FIG13 is a schematic diagram of computer devices in a computer cluster provided by an embodiment of the present application being connected via a network. DETAILED DESCRIPTION

[0046] The embodiments of the present application provide a cluster management method and a cloud management platform based on a cloud management platform, which can maintain cross-cluster communication between tenants' microservices, ensure the availability of the entire cloud service system, and thus meet the business needs of tenants.

[0047] The terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequential order. It should be understood that the terms used in this way can be interchangeable under appropriate circumstances, and this is merely a way of distinguishing the objects of the same attributes when describing them in the embodiments of the present application. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, so that the process, method, system, product or equipment comprising a series of units need not be limited to those units, but may include other units that are not clearly listed or inherent to these processes, methods, products or equipment.

[0048] With the widespread adoption of Kubernetes, more and more tenants are choosing to deploy their microservices in cloud service systems built on Kubernetes. In these cloud service systems, a tenant's microservice can run across multiple clusters provided by the system, effectively meeting tenants' business needs.

[0049] In related technologies, a cloud service system may include a cloud management platform and multiple clusters it creates for tenants. For any of the multiple clusters, the cluster may include multiple nodes, each of which runs a tenant's microservice. In this way, the microservice runs on each node in the tenant's multiple clusters. When a cluster receives traffic directed to the microservice, it can send the traffic to the microservice on each node in the multiple clusters for processing, thereby quickly and accurately completing the tenant's business.

[0050] To ensure the normal completion of tenants' businesses, the cloud management platform needs to monitor the status of each cluster in real time. Generally, the cloud management platform can monitor the interfaces through which each cluster accesses the cloud management platform. If the cloud management platform determines that an interface is working properly, it will assume that the cluster corresponding to the interface is working properly. If the cloud management platform determines that an interface has failed, it will assume that the cluster corresponding to the interface has failed. However, if the interface is working properly but a failure occurs within the cluster, the cloud management platform will mistakenly determine that the cluster is still working properly and will be unable to promptly process the failed cluster. If the failed cluster receives traffic directed to a microservice, the failed cluster will not be able to send the traffic to the microservice in each cluster for processing, resulting in the entire system being unable to complete the tenant's business.

[0051] To address the above issues, the present application provides a cluster management method based on a cloud management platform. This method can be implemented through a cloud service system. Figure 1 is a schematic diagram of the structure of the cloud service system provided by the present application. As shown in Figure 1, the cloud service system includes an infrastructure that can provide cloud services and a cloud management platform that manages the infrastructure. The cloud management platform and infrastructure are introduced separately below:

[0052] The cloud management platform can coordinate and manage the infrastructure of the entire cloud service system (for example, creating multiple tenant-specific clusters within the infrastructure, or managing these multiple clusters based on management policies established by tenants, etc.). It can also be open to tenants outside the cloud service system and respond to their requests. For example, the cloud management platform can provide various interfaces, such as login interfaces and management interfaces, for access by tenant clients (for example, terminal devices used by tenants or browsers on terminal devices, etc.). The cloud management platform can authenticate the tenant's client through the login interface and, upon successful authentication, allow the tenant's client to log in to the cloud management platform. For example, the cloud management platform can also allow tenants to send management policies established by tenants for their multiple clusters to the cloud management platform through their clients through the management interface. Based on the management policies, the cloud management platform can then perform multi-level probing on each of the multiple clusters to determine the status of each cluster, i.e., whether each cluster is in an available state (also referred to as a normal operating state) or an unavailable state (also referred to as a faulty state). If a cluster is determined to be in an unavailable state, the cloud management platform can perform management operations indicated by the management policy on that cluster. For example, the cloud management platform can also allow tenants to send status setting requests for a cluster to the cloud management platform through their clients through the management interface. The status setting request is used to instruct the tenant to mark a cluster as an operation and maintenance state. Therefore, the cloud management platform can also perform operation and maintenance operations indicated by the management policy on the cluster based on the status setting request, etc.

[0053] The infrastructure includes multiple clusters created by the cloud management platform for tenants. For any of these clusters, the cluster may include the Core-DNS (core-domain name system) component and multiple nodes. Each node includes the Kube-proxy component and multiple tenant microservices. It should be noted that a tenant owns multiple microservices, each running on nodes across multiple clusters. When a source microservice on a node in a cluster needs to access a target microservice, the source microservice on that node generates traffic directed to the target microservice and sends this traffic to the Core-DNS component of that cluster. The Core-DNS component of that cluster then processes this traffic, obtains information about the target microservice, and sends this information to the source microservice on that node. Based on the information about the target microservice, the source microservice on that node sends this traffic to the Kube-proxy component on that node. Then, based on the information about the target microservice, the Kube-proxy component on that node forwards this traffic to the target microservice on all nodes across the clusters for processing, thereby meeting the tenant's business needs. However, once the Core-DNS component, Kube-proxy component, and target microservice in the cluster fail, the traffic directed to the target microservice will not be sent or processed successfully. This will prevent the microservices within the system from communicating across clusters, and thus fail to meet the business needs of tenants.

[0054] For example, as shown in Figure 2 (Figure 2 is another structural diagram of the cloud service system provided by an embodiment of the present application), it is assumed that the cloud management platform has created cluster 1 and cluster 2 for the tenant, and cluster 1 includes Core-DNS component 1, node 1 and node 2, and cluster 2 includes Core-DNS component 2, node 3 and node 4. Among them, the tenant has microservice 1, microservice 2 and microservice 3, and Kube-proxy component 1, microservice 1, microservice 2 and microservice 3 are running on node 1, Kube-proxy component 2, microservice 1, microservice 2 and microservice 3 are running on node 2, Kube-proxy component 3, microservice 1, microservice 2 and microservice 3 are running on node 3, and Kube-proxy component 4, microservice 1, microservice 2 and microservice 3 are running on node 4. When the tenant side triggers microservice 1 of node 1 to generate traffic directed to microservice 2, microservice 1 of node 1 can first send this traffic to Core-DNS component 1. Next, Core-DNS component 1 can perform domain name resolution on these flows, thereby obtaining the internet protocol (IP) address (i.e., the domain name resolution result) of microservice 2 interconnected between the networks in cluster 1, and return the IP address to microservice 1 on node 1. Microservice 1 on node 1 can send the IP address and these flows to Kube-proxy component 1. Then, based on the IP address, Kube-proxy component 1 can determine that these flows are flows that need to be sent to microservice 2. Then, Kube-proxy component 1 performs load balancing and, according to the load balancing result, jointly distributes these flows to microservice 2 on node 1, microservice 2 on node 2, microservice 2 on node 3, and microservice 2 on node 4 with Kube-proxy component 2, Kube-proxy component 3, and Kube-proxy component 4, so that these microservices 2 can jointly process these flows. As can be seen, once the Core-DNS component 1, Kube-proxy component 1, or microservice 2 fails, these traffic will not be successfully forwarded or processed, affecting cross-cluster communication between tenants' microservices.

[0055] Based on this, as shown in Figure 3 (Figure 3 is another structural diagram of the cloud service system provided by an embodiment of the present application), after the cloud management platform receives the management policy for multiple clusters issued by the tenant, it can create a dedicated liveness detection component (cluster checker) for each cluster based on the management policy. The liveness detection component can also be regarded as a part of the infrastructure. Then, for any one of the multiple clusters, the liveness detection component of the cluster can detect the Core-DNS component, Kube-proxy component and target microservice of the cluster in real time to obtain the liveness detection result, and provide the liveness detection result to the cloud management platform, so that the cloud management platform can determine whether the cluster is in an available state or an unavailable state based on the liveness detection result. If the cluster is in an unavailable state, the cloud management platform can execute the management operation indicated by the management policy on the cluster to resolve the impact of the cluster's unavailability on the remaining clusters, thereby ensuring that the microservices in the system can still complete communication across clusters.

[0056] Generally speaking, for any one of the multiple clusters, the activity detection component of the cluster can access the cloud management platform through the interface (Kube-apisever) opened by the cloud management platform for the cluster, that is, the activity detection component of the cluster can send the activity detection results (also called activity detection reports) to the cloud management platform through the cluster interface, so that the cloud management platform can determine the status of the cluster.

[0057] Furthermore, the above-mentioned nodes, Core-DNS components and live detection components are all cloud instances in the infrastructure. Cloud instances can be presented in a variety of ways. For example, the cloud instance can be a physical server selected by the cloud management platform. For example, the cloud instance can also be a bare metal server selected by the cloud management platform. For example, the cloud instance can be a virtual machine (VM) created by the cloud management platform on the physical server through virtualization technology. For example, the cloud instance can also be a container (docker) created by the cloud management platform on the physical server through virtualization technology. For example, the cloud instance can also be a micro virtual machine (microVM) created by the cloud management platform on the physical server through virtualization technology, and so on.

[0058] Furthermore, for multiple clusters, multiple clusters can be located at the same site or multiple sites. The site can be presented in various forms. For example, the site can be a region in the infrastructure, or an availability zone in the infrastructure, or a data center (DC) in the infrastructure, or a room in the infrastructure, etc.

[0059] Based on the above cloud service system, it can be known that the tenant can send the management policy formulated by the tenant for its multiple clusters to the cloud management platform. For any of the multiple clusters, the cloud management platform can create a detection component for the cluster based on the management policy. Therefore, the cloud management platform can determine whether the cluster is in an unavailable state through the detection component. If so, the cloud management platform will perform the management operations indicated by the management policy on the cluster to avoid the impact of the unavailable cluster on the remaining clusters, thereby maintaining the cross-cluster communication between the tenant's microservices and ensuring that the system can meet the tenant's business needs. In order to further understand the process, the following is a further introduction to the process in conjunction with Figure 4. Figure 4 is a flow chart of the cluster management method based on the cloud management platform provided in an embodiment of the present application. The method can be implemented through the cloud service system shown in Figure 1 or Figure 3. The cloud service system includes an infrastructure for providing cloud services and a cloud management platform for managing the infrastructure. The infrastructure includes multiple clusters created by the cloud management platform for tenants. Since the operations performed by the cloud management platform for each of the multiple clusters are similar, any one of the clusters will be used for a schematic introduction below. The cluster includes a Core-DNS component and multiple nodes. For any one of the multiple nodes, the node contains a Kube-proxy component and multiple microservices of the tenant. When the source microservice of the node needs to access the target microservice, the source microservice of the node can generate traffic directed to the target microservice and send it to the Core-DNS component of the cluster. The Core-DNS component of the cluster can parse the relevant information of the target microservice for these traffics and return it to the source microservice of the node, so that the source microservice of the node forwards these traffics to the Kube-proxy component of the node based on the relevant information of the target microservice. In this way, the Kube-proxy component of the node can combine the Kube-proxy components of the remaining nodes to forward these traffics to the target microservices of each node for processing. The method includes:

[0060] 401. The cloud management platform receives a management policy for the cluster sent by the tenant through the management interface. The management policy is used to instruct the cluster to perform management operations when the Core-DNS component or the Kube-proxy component or the microservice is in an unavailable state.

[0061] In this embodiment, when a tenant needs to formulate an exclusive management policy for a certain (or certain) cluster that is exclusive to the tenant, the cloud management platform can provide a management interface to the tenant's client (for example, a template display bar for the management policy and a management policy input bar on the tenant interface, etc.). The management interface can provide a template for the management policy. After the tenant browses and formulates a management policy for the cluster according to the template for the management policy, the tenant can input the management policy formulated by the tenant for the cluster into the management interface through its client. It should be noted that the management policy for the cluster may include the identifier of the cluster, the management operations set by the tenant for the cluster, and the conditions that need to be met for performing management operations on the cluster, wherein the conditions that need to be met for performing management operations on the cluster may generally include that the components within the cluster are in an unavailable state, and the components within the cluster include the Core-DNS component of the cluster, the Kube-proxy component of each node in the cluster, and all microservices of each node in the cluster. Based on this, the management policy for the cluster can be used to indicate that when the Core-DNS component of the cluster, the Kube-proxy component of each node of the cluster, or one or some microservices of the cluster are in an unavailable state, management operations are performed on the cluster (for example, when the Core-DNS component of the cluster is in an unavailable state, all nodes of the cluster are migrated from the cluster to another cluster; for example, when the Kube-proxy component of each node of the cluster is in an unavailable state, the microservices of these nodes can be migrated from the cluster to another cluster; for example, when a microservice in the cluster is in an unavailable state, the traffic directed to the microservice in the cluster can be removed).

[0062] For example, as shown in Figure 5 (Figure 5 is a schematic diagram of a tenant interface provided in an embodiment of the present application), when a tenant needs to formulate a management policy for its cluster 1 (identified as shanghai-dc-01) and cluster 2 (identified as shanghai-dc-02), the cloud management platform can provide the tenant with a tenant interface that includes a management policy template display column and a management policy input column. The management policy template display column can display the following templates shown in Tables 1 and 2 to the tenant:

[0063] Table 1

[0064] Table 2(Conditions)

[0065] After browsing the above management policy template, the tenant can create a dedicated management policy for cluster 1 and cluster 2 and enter the management policy for cluster 1 and cluster 2 in the management policy input field:

[0066] Based on this, the cloud management platform can receive the management policies formulated by the tenant for cluster 1 and cluster 2 through the management policy input column.

[0067] Specifically, the management policy for the cluster may also include more information:

[0068] The management policy for the cluster may include not only the identification of the cluster, the management operations set by the tenant for the cluster, and the conditions required to perform management operations on the cluster, but also the operation and maintenance operations set by the tenant for the cluster and the conditions required to perform operation and maintenance operations on the cluster, wherein the conditions required to perform operation and maintenance operations on the cluster may generally include that the cluster as a whole is in an operation and maintenance state. Based on this, the management policy for the cluster can be used not only to indicate that management operations are performed on the cluster when the Core-DNS component of the cluster, the Kube-proxy component of each node of the cluster, or one or more microservices of the cluster are in an unavailable state, but also to indicate that operation and maintenance operations are performed on the cluster when the cluster as a whole is in an operation and maintenance state (for example, isolating the cluster from the system, etc.).

[0069] Still using the above example, as shown in FIG6 (FIG. 6 is a schematic diagram of a tenant interface provided in an embodiment of the present application, and FIG6 is drawn based on FIG5), in the tenant interface provided by the cloud management platform to the tenant, the management policy input field may include two input fields. The tenant may enter the first part of the management policy in the first input field (see the example shown in FIG5 for details), and may also enter the second part of the management policy in the second input field:

[0070] Based on this, the cloud management platform can receive the first part and the second part of the management policy formulated by the tenant for cluster 1 and cluster 2 through the two input fields of the management policy input field, which is equivalent to receiving the entire management policy.

[0071] 402. The cloud management platform creates a liveness detection component for the cluster based on the management policy. The liveness detection component is used to detect the liveness of the Core-DNS component, the Kube-proxy component, and the microservices, obtain the liveness detection results, and provide the liveness detection results to the cloud management platform.

[0072] After obtaining the tenant's management policy for the cluster, the cloud management platform can create a dedicated liveness detection component for the cluster based on the policy. This component can then perform real-time liveness detection on the cluster's Core-DNS component, the Kube-proxy component on each node, and each microservice on each node, generating liveness detection results and returning them to the cloud management platform.

[0073] Specifically, the cluster's liveness detection component can detect the cluster's Core-DNS component in the following ways:

[0074] Because the cluster includes the Core-DNS component and multiple nodes, any one of these nodes includes the Kube-proxy component and multiple tenant microservices. The cluster's Core-DNS component is responsible for performing domain name resolution on traffic it receives directed to a particular microservice (generated by another microservice on the node and sent to the cluster's Core-DNS component), and instructs the node's Kube-proxy component to forward this traffic to the microservice on the node based on the domain name resolution result. To test the status of the cluster's Core-DNS component, the cluster's liveness detection component can send a domain name resolution task to the cluster's Core-DNS component, causing it to perform the domain name resolution task and thereby obtain a liveness detection result. It should be noted that if the cluster's Core-DNS component successfully performs the domain name resolution task, the liveness detection result indicates that the cluster's Core-DNS component is available. If the cluster's Core-DNS component fails to perform the domain name resolution task, the liveness detection result indicates that the cluster's Core-DNS component is unavailable.

[0075] Still taking the above example as shown in FIG7 (FIG. 7 is another structural diagram of the cloud service system provided by an embodiment of the present application, and FIG7 is drawn on the basis of FIG6), after the cloud management platform receives the management policy formulated by the tenant for cluster 1 and cluster 2, it can create a detection component 1 for cluster 1 and a detection component 2 for cluster 2. The detection component 1 is schematically introduced below. The detection component 1 can send a domain name resolution task to the Core-DNS component 1 of cluster 1 in real time, so that the Core-DNS component 1 performs the domain name resolution task. If the Core-DNS component 1 fails to successfully perform the domain name resolution task, it means that the Core-DNS component 1 may have a fault and is in an unavailable state. Therefore, the detection component 1 can generate the following detection results:

[0076] Based on the liveness detection result obtained by the liveness detection component 1 for cluster 1, it can be known that the Core-DNS component 1 is in an unavailable state. Then, the liveness detection component 1 can return the liveness detection result to the cloud management platform.

[0077] More specifically, the cluster's liveness detection component can also detect the cluster's Core-DNS component in the following ways:

[0078] There are two possible reasons why the cluster's Core-DNS component may fail to successfully perform domain name resolution. The first is that the cluster's Core-DNS component has experienced a fault, failing to successfully perform domain name resolution and becoming unavailable. The second is that there is a network issue between the cluster's Core-DNS component and the cluster's liveness detection component, preventing the Core-DNS component from performing domain name resolution. Therefore, the cloud management platform can configure the cluster's liveness detection component to have multiple replica instances, each of which can send a domain name resolution task to the cluster's Core-DNS component once, allowing the cluster's Core-DNS component to perform domain name resolution tasks multiple times, thereby obtaining liveness detection results. It should be noted that if the number of times the cluster's Core-DNS component fails to successfully perform domain name resolution tasks is less than a preset first threshold (the threshold can be set based on actual needs and is not limited here), the liveness detection result indicates that the cluster's Core-DNS component is available. If the number of times the cluster's Core-DNS component fails to successfully perform domain name resolution tasks is greater than or equal to the preset first threshold, the liveness detection result indicates that the cluster's Core-DNS component is unavailable.

[0079] Still taking the above example, as shown in Figure 8 (Figure 8 is another structural diagram of the cloud service system provided by an embodiment of the present application, and Figure 8 is drawn based on Figure 7), it is assumed that the live detection component 1 created by the cloud management platform for cluster 1 includes three replica instances, namely replica instance 1, replica instance 2, and replica instance 3. Therefore, these three replica instances can send three domain name resolution tasks to the Core-DNS component 1, thereby causing the Core-DNS component 1 to perform three domain name resolution tasks. Assuming that the Core-DNS component 1 only successfully executes one domain name resolution task, the live detection component 1 can obtain the information summarized by the three replica instances:

[0080] Then, the activity detection component 1 can generate the aforementioned activity detection result based on this information (see the example shown in FIG6 for details) and feed it back to the cloud management platform.

[0081] More specifically, the cluster's liveness detection component can detect the cluster's Kube-proxy component in the following ways:

[0082] Since the cluster includes a Core-DNS component and multiple nodes, for any one of the multiple nodes, the node includes a Kube-proxy component and multiple microservices of the tenant. The Core-DNS component of the cluster is used to perform domain name resolution on the traffic it receives that is directed to a certain microservice (generated by another microservice of the node and sent to the Core-DNS component of the cluster), and (through another microservice of the node) provide these traffic and domain name resolution results to the Kube-proxy component of the node, so that the Kube-proxy component of the node can coordinate with the remaining nodes to perform load balancing for the microservice based on the domain name resolution result, and distribute these traffic to the microservice of all nodes based on the load balancing result. Then, in order to test the status of the Kube-proxy component of each node in the cluster, the liveness detection component of the cluster can send a load balancing task to the Kube-proxy component of each node, so that the Kube-proxy component of each node performs the load balancing task, thereby obtaining the liveness detection result. It should be noted that if the Kube-proxy components of each node successfully perform the load balancing task, the liveness result can be used to indicate that the various Kube-proxy components of the cluster are in an available state. If the Kube-proxy components of each node fail to successfully perform the load balancing task, the liveness result can be used to indicate that the various Kube-proxy components of the cluster are in an unavailable state.

[0083] Still using the example shown in Figure 7, liveness detection component 1 can send load balancing tasks to Kube-proxy component 1 of node 1 and Kube-proxy component 2 of node 2 in cluster 1 in real time, so that Kube-proxy component 1 and Kube-proxy component 2 perform the load balancing tasks. If Kube-proxy component 1 and Kube-proxy component 2 fail to successfully perform the load balancing tasks, it means that Kube-proxy component 1 and Kube-proxy component 2 may have failed and are in an unavailable state. Therefore, liveness detection component 1 can generate the following liveness detection results:

[0084] Based on the liveness detection result obtained by the liveness detection component 1 for cluster 1, it can be known that Kube-proxy component 1 and Kube-proxy component 2 are in an unavailable state. Then, the liveness detection component 1 can return the liveness detection result to the cloud management platform.

[0085] More specifically, the cluster's liveness detection component can also detect the cluster's Kube-proxy component in the following ways:

[0086] Considering that the liveness detection component of the cluster determines that the Kube-proxy components of each node in the cluster are in an unavailable state only when the Kube-proxy components of all nodes in the cluster fail to successfully perform load balancing tasks, this judgment rule is too strict and may not be applicable in actual application scenarios. Therefore, the liveness detection component can use the following judgment rule: in the cluster, if the number of Kube-proxy components that fail to successfully perform load balancing tasks is less than a preset second threshold (the value of this threshold can be set according to actual needs and is not limited here), it means that a large proportion of the Kube-proxy components of the nodes in the cluster are available, and the liveness detection result generated by the liveness detection component of the cluster can be used to indicate that the Kube-proxy components of each node in the cluster are in an available state. If the number of Kube-proxy components that fail to successfully perform load balancing tasks is greater than or equal to the preset second threshold, it means that a large proportion of the Kube-proxy components of the nodes in the cluster are unavailable, and the liveness detection result generated by the liveness detection component of the cluster can be used to indicate that multiple Kube-proxy components are in an unavailable state.

[0087] More specifically, the cluster's liveness detection component can detect the cluster's microservices in the following ways:

[0088] Since multiple microservices of tenants are deployed in the cluster, for any one of these microservices, the cluster's liveness detection component can collect information about the microservice. If the information of the microservice is used to indicate that the load of the microservice is greater than or equal to a preset third threshold (the size of the threshold can be set according to actual needs and is not limited here), or if the information of the microservice is used to indicate that the microservice cannot be accessed by the outside world, etc., the liveness detection result generated by the cluster's liveness detection component can be used to indicate that the microservice is in an unavailable state.

[0089] 403. If it is determined based on the liveness detection result that the Core-DNS component or Kube-proxy component or microservice is in an unavailable state, the cloud management platform performs a management operation on the cluster, and the management operation includes at least one of the following: migrating nodes and removing traffic.

[0090] After obtaining the liveness result fed back by the liveness detection component of the cluster, if the cloud management platform determines based on the liveness detection result that the Core-DNS component of the cluster or the Kube-proxy component of each node in the cluster or a microservice in the cluster is in an unavailable state, the cloud management platform can perform management operations indicated by the management policy on the cluster. For example, when the Core-DNS component of the cluster is in an unavailable state, the cloud management platform can migrate all nodes of the cluster from the cluster to another cluster of the tenant. For another example, when the Kube-proxy component of each node in the cluster is in an unavailable state, the cloud management platform can perform management operations indicated by the management policy on the cluster. For example, when a microservice in the cluster is in an unavailable state, the cloud management platform can migrate the microservices of these nodes from the cluster to the nodes of another cluster. For example, when a microservice in the cluster is in an unavailable state, the cloud management platform can remove the traffic directed to the microservice in the cluster. That is to say, the cloud management platform can use some method to enable the tenant side to only trigger the traffic directed to the microservice of the remaining clusters, and no longer trigger the traffic directed to the microservice of the cluster. For example, when a microservice in the cluster is in an unavailable state, the cloud management platform can delete the microservice in each node of the cluster (that is, take the microservice offline in the cluster), and so on.

[0091] Specifically, tenants can also define the operation and maintenance status of the cluster in the following ways so that the cloud management platform can perform operation and maintenance operations on the cluster:

[0092] Since the management policy formulated by the tenant for the cluster is also used to indicate that when the cluster as a whole is in an operation and maintenance state, operation and maintenance operations are performed on the cluster, when the tenant needs to put the cluster into an operation and maintenance state (for example, when the tenant needs to perform version updates on each microservice in the cluster, etc.), the tenant can input a state setting request for the cluster through its client to the management interface provided by the cloud management platform (for example, the cluster state setting bar, etc.). The state setting request is used to instruct the tenant to set the state of the cluster to an operation and maintenance state. After receiving the state setting request, the cloud management platform can perform the operation and maintenance operations indicated by the management policy formulated by the tenant for the cluster based on the state setting request. For example, the cloud management platform can isolate the cluster, etc. (for example, the cloud management platform prevents the cluster from deploying new microservices to maintain the business stability of the original microservice during the version update, until the tenant cancels the operation and maintenance state of the cluster after the update is completed. The cloud management platform can then put the cluster into normal working state and continue to undertake new microservice deployments, etc.).

[0093] Still using the above example, as shown in FIG9 ( FIG9 is another schematic diagram of the tenant interface provided in an embodiment of the present application), when the tenant needs to update each microservice in cluster 1, the tenant can enter the following status setting request for cluster 1 in the cluster status setting column of the tenant interface provided by the cloud management platform:

[0094] In the aforementioned state-setting request for Cluster 1, the tenant specifies the maintenance state as PreUpgrade via the maintenance field, indicating that the tenant wishes to update the microservices in Cluster 1. Upon receiving the state-setting request for Cluster 1 via the Cluster State Setting field, the cloud management platform can perform the maintenance operations indicated by the aforementioned management policy on Cluster 1 (see the example in Figure 6). This involves isolating Cluster 1, preventing the deployment of new microservices, and maintaining operational stability for the existing microservices during the update until the update is complete.

[0095] In an embodiment of the present application, when a tenant needs to formulate an exclusive management policy for a cluster of the tenant, the tenant can input the management policy for the cluster into the management interface provided by the cloud management platform. The management policy for the cluster is used to indicate that when the Core-DNS component of the cluster or the Kube-proxy component of the cluster or a microservice of the cluster is in an unavailable state, management operations can be performed on the cluster. Then, the cloud management platform can create an exclusive liveness detection component for the cluster based on the management policy for the cluster. The liveness detection component of the cluster can detect the Core-DNS component of the cluster, the Kube-proxy component of the cluster and the microservices of the cluster, thereby obtaining the liveness detection result and providing the liveness detection result to the cloud management platform. Finally, if it is determined based on the liveness detection result that the Core-DNS component of the cluster or the Kube-proxy component of the cluster or the microservice of the cluster is in an unavailable state, the cloud management platform performs the management operations indicated by the management policy for the cluster on the cluster. The management operations include migrating the nodes of the cluster, migrating the microservices of the cluster and removing the traffic directed to the microservices of the cluster, etc. In the above process, the cloud management platform can create a detection component for the cluster based on the management policy formulated by the tenant for its cluster. Therefore, the cloud management platform can use the detection component to determine whether the components within the cluster (for example, the Core-DNS component of the cluster or the Kube-proxy component of the cluster or the microservices of the cluster, etc.) are in an unavailable state. If so, the cloud management platform will execute the management operations indicated by the management policy on the cluster to avoid the impact of the unavailable cluster on other clusters, thereby maintaining cross-cluster communication between the tenant's microservices and ensuring the availability of the entire cloud service system, so as to meet the tenant's business needs.

[0096] The above is a detailed description of the cluster management method based on the cloud management platform provided by the embodiment of the present application. The cloud management platform provided by the embodiment of the present application will be introduced below. Figure 10 is a structural diagram of the cloud management platform provided by the embodiment of the present application. As shown in Figure 10, the cloud management platform is used to manage the tenant's cluster. The cluster includes a Core-DNS component and a node. The node includes a Kube-proxy component and a microservice. The Core-DNS component is used to enable the Kube-proxy component to forward traffic directed to the microservice to the microservice. The cloud management platform includes:

[0097] The receiving module 1001 is used to receive a management policy for the cluster sent by the tenant through the management interface, where the management policy is used to instruct the Core-DNS component or Kube-proxy component or microservice to perform management operations on the cluster when it is in an unavailable state; for example, the receiving module 1001 is used to implement step 401 of the embodiment shown in Figure 4.

[0098] Create module 1002, which is used to create a liveness detection component for the cluster based on the management policy. The liveness detection component is used to detect the Core-DNS component, Kube-proxy component and microservices, obtain the liveness detection results, and provide the liveness detection results to the cloud management platform; for example, create module 1002 to implement step 402 of the embodiment shown in Figure 4.

[0099] Execution module 1003 is configured to, if the Core-DNS component, Kube-proxy component, or microservice is determined to be unavailable based on the liveness detection result, perform a management operation on the cluster. The management operation includes at least one of the following: node migration and traffic removal. For example, execution module 1003 is configured to implement step 403 of the embodiment shown in FIG. 4 .

[0100] In an embodiment of the present application, when a tenant needs to formulate an exclusive management policy for a cluster of the tenant, the tenant can input the management policy for the cluster into the management interface provided by the cloud management platform. The management policy for the cluster is used to indicate that when the Core-DNS component of the cluster or the Kube-proxy component of the cluster or a microservice of the cluster is in an unavailable state, management operations can be performed on the cluster. Then, the cloud management platform can create an exclusive liveness detection component for the cluster based on the management policy for the cluster. The liveness detection component of the cluster can detect the Core-DNS component of the cluster, the Kube-proxy component of the cluster and the microservices of the cluster, thereby obtaining the liveness detection result and providing the liveness detection result to the cloud management platform. Finally, if it is determined based on the liveness detection result that the Core-DNS component of the cluster or the Kube-proxy component of the cluster or the microservice of the cluster is in an unavailable state, the cloud management platform performs the management operations indicated by the management policy for the cluster on the cluster. The management operations include migrating the nodes of the cluster, migrating the microservices of the cluster and removing the traffic directed to the microservices of the cluster, etc. In the above process, the cloud management platform can create a detection component for the cluster based on the management policy formulated by the tenant for its cluster. Therefore, the cloud management platform can use the detection component to determine whether the components within the cluster (for example, the Core-DNS component of the cluster or the Kube-proxy component of the cluster or the microservices of the cluster, etc.) are in an unavailable state. If so, the cloud management platform will execute the management operations indicated by the management policy on the cluster to avoid the impact of the unavailable cluster on other clusters, thereby maintaining cross-cluster communication between the tenant's microservices and ensuring the availability of the entire cloud service system, so as to meet the tenant's business needs.

[0101] In one possible implementation, the Core-DNS component is used to perform domain name resolution on the traffic, obtain the domain name resolution result, and enable the Kube-proxy component to send the traffic to the microservice based on the domain name resolution result. The liveness detection component is used to enable the Core-DNS component to perform the domain name resolution task to obtain the liveness detection result. If the Core-DNS component fails to successfully perform the domain name resolution task, the liveness detection result is used to indicate that the Core-DNS component is in an unavailable state.

[0102] In one possible implementation, the liveness detection component is used to cause the Core-DNS component to perform the domain name resolution task multiple times to obtain a liveness detection result, wherein, if the number of times the Core-DNS component fails to successfully perform the domain name resolution task is greater than or equal to a preset first threshold, the liveness detection result is used to indicate that the Core-DNS component is in an unavailable state.

[0103] In one possible implementation, the Kube-proxy component is used to load balance microservices based on domain name resolution results, obtain load balancing results, and distribute traffic to microservices based on the load balancing results. The liveness detection component is used to enable the Kube-proxy component to perform load balancing tasks to obtain liveness detection results. If the Kube-proxy component fails to successfully perform the load balancing task, the liveness detection result is used to indicate that the Kube-proxy component is in an unavailable state.

[0104] In one possible implementation, a cluster includes multiple nodes, one node includes a Kube-proxy component, and the liveness detection component is used to enable multiple Kube-proxy components on multiple nodes to perform load balancing tasks to obtain liveness detection results, wherein, if, among the multiple Kube-proxy components, the number of Kube-proxy components that fail to successfully perform the load balancing task is greater than or equal to a preset second threshold, the liveness detection result is used to indicate that the multiple Kube-proxy components are in an unavailable state.

[0105] In one possible implementation, the activity detection component is also used to collect information about the microservice and generate an activity detection result based on the information, wherein if the information is used to indicate that the load of the microservice is greater than or equal to a preset third threshold, the activity detection result is used to indicate that the microservice is in an unavailable state.

[0106] In one possible implementation, the liveness detection component is further used to collect information about the microservice and generate a liveness detection result based on the information. If the information indicates that the microservice is inaccessible, the liveness detection result indicates that the microservice is in an unavailable state.

[0107] In one possible implementation, the management policy is also used to indicate that when the cluster is in an operation and maintenance state, an operation and maintenance operation is performed on the cluster. The receiving module 1001 is also used to receive a status setting request sent by the tenant through the management interface. The status setting request is used to instruct the tenant to set the status of the cluster to an operation and maintenance state; the execution module 1003 is also used to perform an operation and maintenance operation on the cluster based on the status setting request. The operation and maintenance operation includes: isolating the cluster.

[0108] In one possible implementation, the node, the Core-DNS component, and the liveness detection component are any of the following: a virtual machine, a container, a micro virtual machine, a physical server, and a bare metal server.

[0109] It should be noted that the information interaction, implementation process, etc. between the modules / units of the above-mentioned device are based on the same concept as the method embodiment of the present application, and the technical effects they bring are the same as those of the method embodiment of the present application. For specific contents, please refer to the description in the method embodiment shown above in the embodiment of the present application, and no further details will be given here.

[0110] Please refer to Figure 11, which is a schematic diagram of the structure of a computing device provided in an embodiment of the present application. As shown in Figure 11, the computing device 1100 (which can be used to present the aforementioned cloud management platform) includes: a processor 1101, a memory 1102, a communication interface 1103, and a bus 1104. The processor 1101, the memory 1102, and the communication interface 1103 are coupled via a bus (not labeled in the figure). The memory 1102 stores instructions. When the execution instructions in the memory 1102 are executed, the computing device 1100 executes the method executed by the cloud management platform in the above method embodiment.

[0111] The computing device 1100 may be one or more integrated circuits configured to implement the above method, such as one or more application specific integrated circuits (ASICs), one or more digital signal processors (DSPs), one or more field programmable gate arrays (FPGAs), or a combination of at least two of these integrated circuit forms. For example, when a unit in the device can be implemented in the form of a processing element scheduler, the processing element can be a general-purpose processor, such as a central processing unit (CPU) or other processor that can call a program. For example, these units can be integrated together and implemented in the form of a system-on-a-chip (SOC).

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

[0113] Memory 1102 may be volatile memory or nonvolatile memory, or may include both volatile and nonvolatile memory. Nonvolatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory may be random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of RAM are available, such as static RAM (SRAM), dynamic random access memory (DRAM), synchronous DRAM (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link DRAM (SLDRAM), and direct rambus RAM (DR RAM).

[0114] Memory 1102 stores executable program code, and processor 1101 executes the executable program code to implement the functions of the aforementioned receiving module, creation module, and execution module, thereby implementing the aforementioned cloud management platform-based cluster management method. In other words, memory 1102 stores instructions for executing the aforementioned cloud management platform-based cluster management method.

[0115] The communication interface 1103 uses a transceiver module such as, but not limited to, a network interface card or a transceiver to implement communication between the computing device 1100 and other devices or a communication network.

[0116] In addition to the data bus, bus 1104 may also include a power bus, a control bus, and a status signal bus. The bus may be a Peripheral Component Interconnect Express (PCIe) bus, an Extended Industry Standard Architecture (EISA) bus, a unified bus (Ubus or UB), a Compute Express Link (CXL), or a Cache Coherent Interconnect for Accelerators (CCIX). Buses can be categorized as address buses, data buses, and control buses.

[0117] Please refer to Figure 12 , which is a schematic diagram of a computing device cluster provided in an embodiment of the present application. As shown in Figure 12 , the computing device cluster 1200 includes at least one computing device 1100 .

[0118] As shown in Figure 12, the computing device cluster 1200 includes at least one computing device 1100. The memory 1102 in one or more computing devices 1100 in the computing device cluster 1200 may store the same instructions for executing the above-mentioned cluster management method based on the cloud management platform.

[0119] In some possible implementations, the memory 1102 of one or more computing devices 1100 in the computing device cluster 1200 may also store partial instructions for executing the aforementioned cloud management platform-based cluster management method. In other words, the combination of one or more computing devices 1100 can collectively execute the aforementioned cloud management platform-based cluster management method.

[0120] It should be noted that the memory 1102 in different computing devices 1100 in the computing device cluster 1200 may store different instructions, each for executing a portion of the functions of the aforementioned cloud management platform. In other words, the instructions stored in the memory 1102 in different computing devices 1100 may implement the functions of one or more modules such as the receiving module, the creating module, and the executing module.

[0121] In some possible implementations, one or more computing devices 1100 in the computing device cluster 1200 may be connected via a network, which may be a wide area network or a local area network.

[0122] Please refer to Figure 13, which is a schematic diagram of computer devices in a computer cluster provided by an embodiment of the present application being connected via a network. As shown in Figure 13, two computing devices 1100A and 1100B are connected via a network. Specifically, each computing device is connected to the network via a communication interface.

[0123] In one possible implementation, the memory of the computing device 1100A stores instructions for executing functions of a receiving module and the like. Meanwhile, the memory of the computing device 1100B stores instructions for executing functions of a creating module and an executing module and the like.

[0124] It should be understood that the functions of the computing device 1100A shown in Figure 13 may also be completed by multiple computing devices. Similarly, the functions of the computing device 1100B may also be completed by multiple computing devices.

[0125] An embodiment of the present application also relates to a computer storage medium, in which a program for signal processing is stored. When the computer storage medium is run on a computer, the computer executes the steps executed by the cloud management platform in the embodiment shown in Figure 4.

[0126] An embodiment of the present application also relates to a computer program product, which stores instructions that, when executed by a computer, enable the computer to execute the steps performed by the cloud management platform in the embodiment shown in FIG4 .

[0127] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0128] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

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

[0130] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0131] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

Claims

1. A cluster management method based on a cloud management platform, characterized in that: The cloud management platform is used to manage a tenant's cluster, the cluster includes a Core-DNS component and a node, the node includes a Kube-proxy component and a microservice, the Core-DNS component is used to enable the Kube-proxy component to forward traffic directed to the microservice to the microservice, and the method includes: The cloud management platform receives a management policy for the cluster sent by the tenant through a management interface, where the management policy is used to instruct the Core-DNS component, the Kube-proxy component, or the microservice to perform a management operation on the cluster when the Core-DNS component, the Kube-proxy component, or the microservice is in an unavailable state; The cloud management platform creates a liveness detection component for the cluster based on the management policy, wherein the liveness detection component is used to detect the liveness of the Core-DNS component, the Kube-proxy component, and the microservice, obtain a liveness detection result, and provide the liveness detection result to the cloud management platform; If it is determined based on the detection result that the Core-DNS component or the Kube-proxy component or the microservice is in an unavailable state, the cloud management platform performs the management operation on the cluster, and the management operation includes at least one of the following: migrating the node and removing the traffic.

2. The method according to claim 1, characterized in that The Core-DNS component is used to perform domain name resolution on the traffic, obtain a domain name resolution result, and enable the Kube-proxy component to send the traffic to the microservice based on the domain name resolution result. The liveness detection component is used to enable the Core-DNS component to perform the domain name resolution task to obtain a liveness detection result. If the Core-DNS component fails to successfully perform the domain name resolution task, the liveness detection result is used to indicate that the Core-DNS component is in an unavailable state.

3. The method according to claim 2, characterized in that The liveness detection component is used to enable the Core-DNS component to perform the domain name resolution task multiple times to obtain a liveness detection result, wherein, if the number of times the Core-DNS component fails to successfully perform the domain name resolution task is greater than or equal to a preset first threshold, the liveness detection result is used to indicate that the Core-DNS component is in an unavailable state.

4. The method according to claim 2 or 3, characterized in that The Kube-proxy component is used to load balance the microservice based on the domain name resolution result to obtain a load balancing result, and distribute the traffic to the microservice based on the load balancing result. The liveness detection component is used to enable the Kube-proxy component to perform a load balancing task to obtain a liveness detection result. If the Kube-proxy component fails to successfully perform the load balancing task, the liveness detection result is used to indicate that the Kube-proxy component is in an unavailable state.

5. The method according to claim 4, characterized in that The cluster includes multiple nodes, each node includes a Kube-proxy component, and the liveness detection component is used to enable multiple Kube-proxy components on the multiple nodes to perform load balancing tasks to obtain liveness detection results, wherein, if the number of Kube-proxy components that fail to successfully perform the load balancing task among the multiple Kube-proxy components is greater than or equal to a preset second threshold, the liveness detection result is used to indicate that the multiple Kube-proxy components are in an unavailable state.

6. The method according to any one of claims 1 to 5, characterized in that The activity detection component is further used to collect information about the microservice and generate the activity detection result based on the information, wherein if the information is used to indicate that the load of the microservice is greater than or equal to a preset third threshold, the activity detection result is used to indicate that the microservice is in an unavailable state.

7. The method according to any one of claims 1 to 5, characterized in that The liveness detection component is further used to collect information about the microservice and generate the liveness detection result based on the information, wherein if the information is used to indicate that the microservice is inaccessible, the liveness detection result is used to indicate that the microservice is in an unavailable state.

8. The method according to any one of claims 1 to 7, characterized in that The management policy is further configured to instruct, when the cluster is in an operation and maintenance state, to perform an operation and maintenance operation on the cluster. The method further comprises: The cloud management platform receives a status setting request sent by the tenant through the management interface, wherein the status setting request is used to instruct the tenant to set the status of the cluster to an operation and maintenance state; The cloud management platform performs the operation and maintenance operation on the cluster based on the status setting request, where the operation and maintenance operation includes: isolating the cluster.

9. The method according to any one of claims 1 to 8, characterized in that The node, the Core-DNS component, and the liveness detection component are any one of the following: a virtual machine, a container, a micro virtual machine, a physical server, and a bare metal server.

10. A cloud management platform, characterized in that: The cloud management platform is used to manage the tenant's cluster, the cluster includes a Core-DNS component and a node, the node includes a Kube-proxy component and a microservice, the Core-DNS component is used to enable the Kube-proxy component to forward traffic directed to the microservice to the microservice, and the cloud management platform includes: A receiving module, configured to receive, through a management interface, a management policy for the cluster sent by the tenant, wherein the management policy is used to instruct the Core-DNS component, the Kube-proxy component, or the microservice to perform a management operation on the cluster when the Core-DNS component, the Kube-proxy component, or the microservice is in an unavailable state; A creation module is used to create a liveness detection component for the cluster based on the management policy, wherein the liveness detection component is used to detect the liveness of the Core-DNS component, the Kube-proxy component, and the microservice, obtain a liveness detection result, and provide the liveness detection result to the cloud management platform; An execution module is used to perform the management operation on the cluster if it is determined based on the detection result that the Core-DNS component or the Kube-proxy component or the microservice is in an unavailable state, and the management operation includes at least one of the following: migrating the node and removing the traffic.

11. The cloud management platform according to claim 10, characterized in that: The Core-DNS component is used to perform domain name resolution on the traffic, obtain a domain name resolution result, and enable the Kube-proxy component to send the traffic to the microservice based on the domain name resolution result. The liveness detection component is used to enable the Core-DNS component to perform the domain name resolution task to obtain a liveness detection result. If the Core-DNS component fails to successfully perform the domain name resolution task, the liveness detection result is used to indicate that the Core-DNS component is in an unavailable state.

12. The cloud management platform according to claim 11, characterized in that: The liveness detection component is used to enable the Core-DNS component to perform the domain name resolution task multiple times to obtain a liveness detection result, wherein, if the number of times the Core-DNS component fails to successfully perform the domain name resolution task is greater than or equal to a preset first threshold, the liveness detection result is used to indicate that the Core-DNS component is in an unavailable state.

13. The cloud management platform according to claim 11 or 12, characterized in that: The Kube-proxy component is used to load balance the microservice based on the domain name resolution result to obtain a load balancing result, and distribute the traffic to the microservice based on the load balancing result. The liveness detection component is used to enable the Kube-proxy component to perform a load balancing task to obtain a liveness detection result. If the Kube-proxy component fails to successfully perform the load balancing task, the liveness detection result is used to indicate that the Kube-proxy component is in an unavailable state.

14. The cloud management platform according to claim 13, characterized in that: The cluster includes multiple nodes, each node includes a Kube-proxy component, and the liveness detection component is used to enable multiple Kube-proxy components on the multiple nodes to perform load balancing tasks to obtain liveness detection results, wherein, if the number of Kube-proxy components that fail to successfully perform the load balancing task among the multiple Kube-proxy components is greater than or equal to a preset second threshold, the liveness detection result is used to indicate that the multiple Kube-proxy components are in an unavailable state.

15. The cloud management platform according to any one of claims 10 to 14, characterized in that: The activity detection component is further used to collect information about the microservice and generate the activity detection result based on the information, wherein if the information is used to indicate that the load of the microservice is greater than or equal to a preset third threshold, the activity detection result is used to indicate that the microservice is in an unavailable state.

16. The cloud management platform according to any one of claims 10 to 14, characterized in that: The liveness detection component is further used to collect information about the microservice and generate the liveness detection result based on the information, wherein if the information is used to indicate that the microservice is inaccessible, the liveness detection result is used to indicate that the microservice is in an unavailable state.

17. The cloud management platform according to any one of claims 10 to 16, characterized in that: The management policy is further configured to instruct the cluster to perform an operation and maintenance operation on the cluster when the cluster is in an operation and maintenance state. The receiving module is further configured to receive a state setting request sent by the tenant through the management interface, wherein the state setting request is configured to instruct the tenant to set the state of the cluster to an operation and maintenance state. The execution module is further configured to execute the operation and maintenance operation on the cluster based on the status setting request, where the operation and maintenance operation includes isolating the cluster.

18. The cloud management platform according to any one of claims 10 to 17, characterized in that: The node, the Core-DNS component, and the liveness detection component are any one of the following: a virtual machine, a container, a micro virtual machine, a physical server, and a bare metal server.

19. A computing device cluster, characterized in that: The computing device cluster includes at least one computing device, each computing device including a processor and a memory: The memory is used to store instructions; The processor is configured to cause the computing device cluster to execute the method according to any one of claims 1 to 9 according to the instructions.

20. A computer storage medium, characterized in that The computer storage medium stores one or more instructions, which, when executed by one or more computers, enable the one or more computers to implement the method according to any one of claims 1 to 9.

21. A computer program product, characterized in that The computer program product stores instructions, which, when executed by a computer, enable the computer to implement the method according to any one of claims 1 to 9.

Images