Cluster-based Multi-version Compatibility Method, Device, and Storage Medium

Abstract

The present application discloses a multi-version compatibility method, device, and storage medium based on a cluster. The multi-version compatibility method based on a cluster includes: in response to receiving a task request sent by a client, performing version comparison processing on the target cluster version in the task request and the current cluster version of the cluster in the cluster server to obtain a comparison result; in response to the comparison result indicating that the target cluster version does not exist in the cluster server, determining a target compatible cluster from each cluster in the cluster server, where the compatible version of the target compatible cluster is compatible with the target cluster version; performing conversion processing on the task request according to the compatible version to obtain a compatible request; and sending the compatible request to the target compatible cluster for request response. The above solution can improve the compatibility of the cluster.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, and in particular, to a multi-version compatibility method, device, and storage medium based on a cluster. Background Art

[0002] With the continuous development of cloud native technology, traditional services are increasingly migrating to the cloud, and the overall service environment has become more and more complex.

[0003] Different users have different requirements for the versions of the cloud system Kubernetes. Moreover, as the number of released versions of Kubernetes increases, users' requirements for multi-version compatibility, and even for seamless compatibility with different versions, are also getting higher and higher.

[0004] Currently, in the native cloud technology Kubernetes, multi-cluster technology is widely used, and it is also common to use different versions in different clusters. However, usually only one version is used in a single cluster, and users need to know and inform the server of the Kubernetes version they need, and then use the corresponding version of the API application interface to request services from the server. Due to the strong coupling in cloud native scenarios, whenever the Kubernetes version of the server changes, users need to perform compatibility adaptation on its API. Summary of the Invention

[0005] This application provides at least a multi-version compatibility method, device, equipment, and computer-readable storage medium based on a cluster.

[0006] In a first aspect of this application, a multi-version compatibility method based on a cluster is provided. The method is applied to a multi-version compatible device that is communicatively connected to a cluster server and a client. The method includes: in response to receiving a task request sent by the client, performing version comparison processing on the target cluster version in the task request and the current cluster version of the clusters in the cluster server to obtain a comparison result; in response to the comparison result indicating that the target cluster version does not exist in the cluster server, determining a target compatible cluster from the clusters in the cluster server, where the compatible version of the target compatible cluster is compatible with the target cluster version; performing conversion processing on the task request according to the compatible version to obtain a compatible request; and sending the compatible request to the target compatible cluster for request response.

[0007] In one embodiment, converting the task request according to the compatible version to obtain a compatible request includes: obtaining a preset conversion logic between the target cluster version and the compatible version; and performing a conversion process on the request path information of the task request according to the preset conversion logic to obtain the compatible request.

[0008] In one embodiment, before comparing the version of the task request received from the client with the current cluster version of the cluster in the cluster server according to the target cluster version in the task request to obtain a comparison result, the method further includes: obtaining interface information of each cluster; comparing the interface information of each cluster to obtain interface differences between the clusters; and determining compatible clusters that support conversion processing in each cluster according to the interface differences.

[0009] In one embodiment, after comparing the interface information of each cluster to obtain interface differences between the clusters, the method further includes: determining clusters to be compatible that do not support conversion processing in each cluster according to the interface differences; and generating a compatibility program for the clusters to be compatible in response to a compatibility program development instruction received for the clusters to be compatible, where the compatibility program is used to perform a conversion process on the task request.

[0010] In one embodiment, after determining compatible clusters that support conversion processing in each cluster according to the interface differences, the method further includes: establishing a compatibility mapping relationship for each compatible cluster; and in response to receiving the task request and the target cluster version not existing in the cluster server, searching for the target compatible cluster in each compatible cluster according to the target cluster version and the compatibility mapping relationship.

[0011] In one embodiment, after comparing the version of the task request received from the client with the current cluster version of the cluster in the cluster server according to the target cluster version in the task request to obtain a comparison result, the method further includes: in response to the comparison result indicating that there is a target cluster corresponding to the target cluster version in each cluster, obtaining a first running load of the target cluster; comparing the first running load with a first load threshold of the target cluster; and in response to the first running load being greater than the first load threshold, identifying a target compatible cluster corresponding to the target cluster version in each cluster.

[0012] In one embodiment, the identifying of the target compatible clusters corresponding to the target cluster version in each cluster in response to the first running load being greater than the first load threshold includes: in response to the first running load being greater than the first load threshold, obtaining the second running loads of the respective compatible clusters corresponding to the target cluster version; and determining the compatible clusters with the second running load less than or equal to the second load threshold as the target compatible clusters.

[0013] In one embodiment, before the comparing the target cluster version in the task request with the current cluster version of the clusters in the cluster server to obtain a comparison result in response to receiving the task request sent by the client, the method further includes: detecting whether the current cluster scenario is a single-cluster scenario or a multi-cluster scenario; and the comparing the target cluster version in the task request with the current cluster version of the clusters in the cluster server to obtain a comparison result in response to receiving the task request sent by the client includes: in response to the current cluster scenario being a multi-cluster scenario and receiving the task request, comparing the target cluster version in the task request with the current cluster versions of the respective clusters to obtain the comparison result.

[0014] A second aspect of the present application provides a multi-version compatibility device based on clusters, including: a version comparison module, configured to compare the target cluster version in the task request with the current cluster version of the clusters in the cluster server to obtain a comparison result in response to receiving the task request sent by the client; a compatibility determination module, configured to determine a target compatible cluster from the clusters in the cluster server in response to the comparison result indicating that the target cluster version does not exist in the cluster server, and the compatible version of the target compatible cluster is compatible with the target cluster version; a request conversion module, configured to convert the task request by using the compatible version to obtain a compatible request; and a request sending module, configured to send the compatible request to the target compatible cluster for request response.

[0015] A third aspect of the present application provides an electronic device, including a memory and a processor, and the processor is configured to execute program instructions stored in the memory to implement the above-mentioned multi-version compatibility method based on clusters.

[0016] A fourth aspect of the present application provides a computer-readable storage medium, on which program instructions are stored, and when the program instructions are executed by a processor, the above-mentioned multi-version compatibility method based on clusters is implemented.

[0017] In the above solution, when receiving a task request sent by a client, the target cluster version in the task request can be compared with the current cluster version of the cluster in the cluster server to obtain a comparison result, and then it can be determined whether there is a target cluster in the current cluster server that can directly process the task request; in response to the comparison result indicating that the target cluster version does not exist in the cluster server, the cluster in the current cluster server cannot directly process the task request, and it is necessary to determine a target compatible cluster that can be compatible with the target cluster from the clusters in the cluster server, and the compatible version of the target compatible cluster is compatible with the target cluster version of the target cluster; the task request is processed and converted according to the compatible version to obtain a compatible request that can be processed by the target compatible cluster; the compatible request is sent to the target compatible cluster for request response, so that users do not need to specify the cluster version when requesting the cluster service, and seamless compatibility between multiple versions and multiple clusters can be achieved.

[0018] It should be understood that the above general description and the following detailed description are only exemplary and explanatory, and do not limit this application. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] The accompanying drawings herein are incorporated into the specification and constitute a part of this specification. These drawings illustrate embodiments consistent with this application and are used together with the specification to explain the technical solutions of this application.

[0020] Figure 1 It is an example diagram of an application scenario in the multi-version compatibility method based on clusters of this application;

[0021] Figure 2 It is a schematic flowchart of an exemplary embodiment of the multi-version compatibility method based on clusters of this application;

[0022] Figure 3 It is a schematic diagram of the principle of an exemplary version interface compatibility service in the multi-version compatibility method based on clusters of this application;

[0023] Figure 4 It is a schematic diagram of the principle of an exemplary version cluster identification service in the multi-version compatibility method based on clusters of this application;

[0024] Figure 5 It is a schematic diagram of an exemplary single-cluster application scenario in the multi-version compatibility method based on clusters of this application;

[0025] Figure 6 It is a block diagram of a multi-version compatibility device based on clusters shown in an exemplary embodiment of this application;

[0026] Figure 7 It is a schematic structural diagram of an embodiment of an electronic device of this application;

[0027] Figure 8 It is a schematic structural diagram of an embodiment of the computer-readable storage medium of the present application. Detailed implementation manners

[0028] The solutions of the embodiments of the present application will be described in detail below with reference to the accompanying drawings of the specification.

[0029] In the following description, specific details such as specific system architectures, interfaces, and technologies are presented for the purpose of illustration rather than limitation, so as to thoroughly understand the present application.

[0030] The term "and / or" in this article is merely a description of the association relationship between associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A exists alone, A and B exist simultaneously, and B exists alone. In addition, the character " / " in this article generally represents an "or" relationship between the associated objects before and after. In addition, the term "multiple" in this article means two or more than two. In addition, the term "at least one" in this article represents any one of multiple types or any combination of at least two of multiple types. For example, including at least one of A, B, and C can represent including any one or more elements selected from the set composed of A, B, and C.

[0031] For the convenience of understanding, one of the applicable scenarios of the present application will be exemplarily described.

[0032] Currently, in the native cloud technology Kubernetes, the multi-cluster technology is widely used. At the same time, the scenario of using different versions in different clusters is also very common. However, usually only one version can be used in a cluster, and the client needs to know in advance and inform the cluster server of the Kubernetes version to be used, and then initiate a task request using the API application interface of the corresponding version to request the cluster server to provide services. When the Kubernetes version of the server changes, the client needs to perform API compatibility adaptation, and the coupling is too strong.

[0033] The multi-version compatibility method based on clusters provided by the present application can be applied to multi-version compatible devices. The multi-version compatible devices are communicatively connected to the cluster server and communicatively connected to the client. As Figure 1 shown Figure 1It is an example diagram of an application scenario in the cluster-based multi-version compatibility method of the present application. For example, the multi-version compatible device can be a gateway for communication between the client and the cluster server, that is, the client is communicatively connected to the gateway, and the cluster server is communicatively connected to the gateway. Additionally, the multi-version compatible device can also be a terminal device (such as a mobile phone, computer, and / or server, etc.) that has a communication connection with the gateway between the client and the cluster server, which is not limited here. Among them, the multi-version compatible device of the present application can at least run the version interface compatibility service, and on this basis, it can also provide services such as version cluster identification service and / or cluster load balancing service, etc., which is not limited here.

[0034] Please refer to Figure 2 , Figure 2 It is a schematic flowchart of an exemplary embodiment of the cluster-based multi-version compatibility method of the present application. The cluster-based multi-version compatibility method of the present application is applied to a multi-version compatible device, and the multi-version compatible device is communicatively connected to the cluster server and communicatively connected to the client. Specifically, it can include the following steps:

[0035] Step S110, in response to receiving a task request sent by the client, perform a version comparison process on the target cluster version in the task request and the current cluster version of the cluster in the cluster server to obtain a comparison result.

[0036] It can be understood that when the client sends a task request to the cluster server using the API application interface it is equipped with, the task request can carry version information of its API, etc. Therefore, when the multi-version compatible device receives the task request sent by the client, it can obtain the version information in the task request by parsing the task request.

[0037] The target cluster version refers to the version information of the target cluster that can respond to and process the task request. Exemplarily, the version information of the cluster can be characterized by the version of Kubernetes in the cluster.

[0038] It should be noted that there can be one or more clusters in the cluster server of the present application, and the cluster information (such as cluster version information, cluster configuration information, etc.) of different clusters can be the same or different. Also, since the clusters in the cluster server may have undergone upgrade and update processing, or replacement and modification processing, etc., the clusters in the cluster server may or may not directly support responding to and processing task requests.

[0039] Therefore, when receiving a task request sent by a client, it is necessary to compare the target cluster version in the task request with the current cluster version of the cluster in the cluster server to obtain a comparison result. And based on the comparison result, it is determined whether the cluster in the current cluster server can support processing the task request. Exemplarily, in this application, the current cluster versions of each cluster in the cluster server can be obtained and counted, and then stored in a specified data structure form (for example, generating a current cluster list for storage, or storing in an array form, or storing in a key-value pair form, etc., which is not limited here).

[0040] Step S120, in response to the comparison result indicating that the target cluster version does not exist in the cluster server, determine a target compatible cluster from each cluster in the cluster server, and the compatible version of the target compatible cluster is compatible with the target cluster version.

[0041] Combined with the foregoing steps, the comparison result between the target cluster version and the current cluster version can indicate whether the cluster in the current cluster server can directly respond to the task request sent by the client and process the request.

[0042] On the one hand, in response to the comparison result indicating that the target cluster version does not exist in the cluster server, that is, the cluster server does not have a target cluster that can directly respond to the task request. Therefore, it is necessary to determine a target compatible cluster from each cluster in the cluster server to replace the target cluster to process the task request. The compatible version of the target compatible cluster is compatible with the target cluster version of the target cluster, that is, the target compatible cluster can compatibly process the task request processed by the target cluster.

[0043] On the other hand, in response to the comparison result indicating that the target cluster version exists in the cluster server, that is, the cluster server has a target cluster that can directly respond to the task request. Therefore, this target cluster can be selected, and the task request is sent to this target cluster so that the target cluster can perform a request response based on the received task request.

[0044] Step S130, perform a conversion process on the task request according to the compatible version to obtain a compatible request.

[0045] Combined with the foregoing steps, after determining the compatible version, it is necessary to perform a conversion process on the task request to obtain a compatible request so that the target compatible cluster corresponding to the compatible version can process the converted task request (compatible request).

[0046] Exemplarily, the method for converting and processing a task request in this application may include, but is not limited to, modifying at least one of the request line, request header, and request body in the task request. For example, it may be to perform conversion processing on the URL information (uniform resource location) of the server requested by the client; and / or to process the data submitted by the client to the cluster (such as converting form data and JSON data (JavaScript Object Notation)), etc., which is not limited here.

[0047] Taking the URL information as an example, if the URL information carried in the task request is the path information for requesting the v2 version cluster, and there is only a v1 version cluster in the current cluster server of the cluster, the multi-version compatible device (such as a gateway) in this application will convert the URL information of the v2 version cluster in the task request into the URL information of the v1 version to obtain a compatible request.

[0048] Step S140, sending the compatible request to the target compatible cluster for request response.

[0049] Combined with the foregoing steps, after obtaining the compatible request, the compatible request can be sent to the target compatible cluster for request response, and the response result is returned to the client, thereby completing the compatible processing process of the task request.

[0050] It can be seen that when this application receives a task request sent by the client, it can perform version comparison processing on the target cluster version in the task request and the current cluster version of the cluster in the cluster server to obtain a comparison result, thereby determining whether there is a target cluster in the current cluster server that can directly process the task request; in response to the comparison result indicating that there is no target cluster version in the cluster server, the cluster in the current cluster server cannot directly process the task request, and it is necessary to determine a target compatible cluster that can be compatible with the target cluster from the clusters in the cluster server, and the compatible version of the target compatible cluster is compatible with the target cluster version of the target cluster; perform conversion processing on the task request according to the compatible version to obtain a compatible request that can be processed by the target compatible cluster; send the compatible request to the target compatible cluster for request response, thereby enabling the user to request the cluster service without specifying the cluster version and realizing seamless compatibility between multiple versions and multiple clusters.

[0051] In the container cloud platform based on Kubernetes of this application, if the Kubernetes version changes within a single cluster, users do not need to perceive the cluster version change and can still use the API of the original version to make requests. The cluster in this application can simultaneously support the function of at least two or more versions of the API. If there are multiple versions of Kubernetes in multiple clusters, users also do not need to explicitly perceive and inform the cluster server which cluster and which version of Kubernetes to use. By directly sending a task request to the cluster server, the cluster server can automatically identify the task request and determine which cluster to send the task request to. At the same time, it can also improve the cluster working performance by combining the cluster load balancing ability.

[0052] Based on the above embodiments, the embodiments of this application illustrate the steps of converting a task request according to a compatible version to obtain a compatible request. Specifically, the method of this embodiment includes the following steps:

[0053] Obtain the preset conversion logic between the target cluster version and the compatible version; convert the request path information of the task request according to the preset conversion logic to obtain a compatible request.

[0054] The preset conversion logic refers to the processing logic used to convert the task request. It can be preset before the step of performing the request conversion process. The specific processing logic needs to be set according to the actual application scenario and will not be elaborated here.

[0055] Exemplarily, combined with the foregoing embodiments, it can be seen that when converting a task request, it is necessary to convert its URL path information. Therefore, the preset conversion logic of this application can include converting the request path information of the task request to obtain a compatible request.

[0056] Another exemplarily, the preset conversion logic of this application can also include performing format conversion processing on the data carried in the request body of the task request to obtain a compatible request.

[0057] Still another exemplarily, the preset conversion logic of this application can also include performing conversion processing on the request method type of the request line in the task request (for example, converting the request method of the task request among methods such as GET, POST, PUT, DELETE, etc.) to obtain a compatible request.

[0058] In summary, the preset conversion logic of this application can selectively convert some or all of the information in the task request according to the actual application scenario, which is not limited here.

[0059] Based on the above embodiments, the embodiments of the present application describe the steps before comparing the target cluster version in the task request with the current cluster version of the cluster in the cluster server in response to receiving a task request from a client to obtain a comparison result. Specifically, the method of this embodiment includes the following steps:

[0060] Obtain the interface information of each cluster; compare the interface information of each cluster to obtain the interface differences between the clusters; determine the compatible clusters that support conversion processing in each cluster according to the interface differences.

[0061] The interface information refers to the information of the API application interfaces supported by the cluster, and each cluster can have one or more supported interface information. Therefore, the present application can determine the compatibility between the clusters by analyzing the interface information of each cluster.

[0062] Exemplarily, the method of this embodiment can be implemented by the version interface compatibility service in the multi-version compatible device. For example, by preset scripts and configured cluster addresses (such as cluster domain names, IP addresses, etc.), automatically scan all interface definitions of different clusters to obtain the interface information of each cluster. Then compare the interface information of each cluster to obtain the interface differences between the clusters. Determine the interfaces that can perform automatic request conversion and the interfaces that cannot perform automatic request conversion according to the interface differences, thereby distinguishing the compatible clusters that support request conversion processing and the clusters to be compatible that do not support conversion processing in each cluster.

[0063] Among them, it can be determined whether automatic request conversion can be performed between different clusters through their interfaces by judging whether the interface name of the application interface changes and / or whether the structure information of the application interface changes. For example, if there are structural differences between the application interface API1 of the v1 version cluster and the application interface API2 of the v2 version cluster, it can be determined that the application interface API1 and the application interface API2 cannot perform automatic request conversion.

[0064] It should be noted that after determining the compatible clusters, relevant information can also be stored by generating a compatible cluster list, etc., which will not be elaborated here.

[0065] Based on the above embodiments, the embodiments of the present application describe the steps after comparing the interface information of each cluster to obtain the interface differences between the clusters. Specifically, the method of this embodiment includes the following steps:

[0066] Determine the clusters to be compatible that do not support conversion processing in each cluster according to the interface differences; in response to receiving a compatible program development instruction for the clusters to be compatible, generate a compatible program for the clusters to be compatible, and the compatible program is used to perform conversion processing on the task request.

[0067] Based on the foregoing embodiments, after determining the clusters to be compatible that do not support conversion processing in each cluster, the information of the clusters to be compatible can also be output. After receiving the information of the clusters to be compatible, relevant developers can perform compatibility adaptation processing on the clusters to be compatible.

[0068] For example, reference can be made to Figure 3 as shown Figure 3 FIG. is a schematic diagram of the principle of an exemplary version interface compatibility service in the cluster-based multi-version compatibility method of the present application. In response to the compatibility program development instruction sent by the developer for the cluster to be compatible, a compatibility program corresponding to the cluster to be compatible is generated to achieve customized compatibility. The compatibility program is used to perform conversion processing on the task request. The newly generated compatibility program can also be associated with the version interface compatibility service to implement the compatibility function in the foregoing embodiments. Among them, after determining the compatible clusters, a current cluster list, a compatible cluster list, a cluster interface list, etc. can also be generated for storing and outputting relevant information.

[0069] Based on the above embodiments, the embodiments of the present application illustrate the steps after determining the compatible clusters that support conversion processing in each cluster according to the interface differences. Specifically, the method of this embodiment includes the following steps:

[0070] Establish a compatibility mapping relationship for each compatible cluster; in response to the received task request, and if the target cluster version does not exist in the cluster server, then according to the target cluster version and the compatibility mapping relationship, search for the target compatible cluster in each compatible cluster.

[0071] Based on the foregoing embodiments, the multi-version compatible device of the present application can also provide a version cluster identification service for identifying and selecting a target compatible cluster in each cluster of the cluster server.

[0072] Among them, the compatibility mapping relationship refers to the mapping relationship between every two clusters in the cluster that can be unidirectionally compatible or bidirectionally compatible. For example, in the foregoing embodiment, if the v1 version cluster can be compatible with the v2 version cluster, but the v2 version cluster cannot be compatible with the v1 version cluster, then the v1 version cluster can be unidirectionally compatible with the v2 version cluster. If the v1 version cluster can be compatible with the v2 version cluster, and the v2 version cluster can be compatible with the v1 version cluster, then the v1 version cluster and the v2 version cluster are bidirectionally compatible. The above examples can all represent that there is a certain compatibility mapping relationship between the v1 version cluster and the v2 version cluster.

[0073] Exemplarily, reference can be made to Figure 4 as shown Figure 4It is a schematic diagram of the principle of an exemplary version cluster recognition service in the cluster-based multi-version compatibility method of the present application. In this embodiment, relevant information can be obtained by pulling programs, such as the current cluster list, compatible cluster list, and cluster interface list output by the version interface compatibility service, and the compatible mapping relationships of each compatible cluster can be established based on this information. For example, the current cluster list includes v1, v2, and v3, which means that the clusters in the current cluster server include three versions: v1, v2, and v3; the compatible cluster list includes v1 and v4, and the preset conversion logic (compatible mechanism) includes v4-v1, that is, a task request of version v4 can be converted into a task request of version v1, which is equivalent to the v1 version cluster being compatible with the v4 version cluster, and the v1 version cluster and the v4 version cluster are compatible clusters. Therefore, the compatible mapping relationships of each compatible cluster can be established based on the above information.

[0074] Furthermore, the established compatible mapping relationships can be stored in the cache cache so that when a task request initiated by the client is received, the recognition program can obtain the relevant information in the above example from the cache, and identify whether the user request is within the version support range of the current cluster server, whether request compatibility conversion is required, and which clusters meet the conditions, so as to obtain the target cluster and / or target compatible cluster adapted to the task request to respond to the task request.

[0075] Based on the above embodiments, the embodiments of the present application illustrate the steps after obtaining the comparison result by comparing the target cluster version in the task request with the current cluster version of the clusters in the cluster server in response to receiving the task request sent by the client. Specifically, the method of this embodiment includes the following steps:

[0076] In response to the comparison result indicating that there is a target cluster corresponding to the target cluster version in each cluster, obtain the first running load of the target cluster; compare the first running load with the first load threshold of the target cluster; in response to the first running load being greater than the first load threshold, identify the target compatible clusters corresponding to the target cluster version in each cluster.

[0077] Illustrated in combination with the foregoing embodiments, the running load of each cluster can characterize its running state, and the same or different load thresholds can be set uniformly or separately for each cluster in the cluster server of the present application, which is not limited here. Among them, the running load and the load threshold can be characterized in the form of specific resource values or in the form of percentage values. For example, they can be determined based on at least one of the CPU resources, memory resources, disk resources, and cluster temperature of the cluster.

[0078] Exemplarily, after determining the target cluster in the current cluster server, the running load of the target cluster can be compared with the load threshold of the target cluster to determine whether the target cluster can normally receive the task request and respond to the processing. For example, obtain the first running load of the target cluster; compare the first running load with the first load threshold of the target cluster; in response to the first running load being greater than the first load threshold, it indicates that the running load of the target cluster is too large and it is temporarily unable to respond to the currently received task request for processing. Therefore, the target compatible cluster corresponding to the target cluster version in the cluster server can be identified, that is, the target compatible cluster that can compatibly run the task request. Similarly, the task request is then processed and converted according to the compatible version of the target compatible cluster to obtain a compatible request; the compatible request is sent to the target compatible cluster for request response.

[0079] In response to the first running load being less than or equal to the first load threshold, it indicates that the running load of the target cluster is not large and it can respond to the currently received task request for processing. Therefore, the task request can be sent to the target cluster for request response.

[0080] It can be understood that if there is no target compatible cluster corresponding to the target cluster, it still waits for the target cluster to respond to the task request for processing.

[0081] Based on the above embodiments, the embodiments of the present application will describe the step of identifying the target compatible cluster corresponding to the target cluster version in each cluster in response to the first running load being greater than the first load threshold. Specifically, the method of this embodiment includes the following steps:

[0082] In response to the first running load being greater than the first load threshold, obtain the second running loads of each compatible cluster corresponding to the target cluster version; determine the compatible clusters with the second running load less than or equal to the second load threshold as the target compatible clusters.

[0083] Combined with the foregoing embodiments for description, after it is determined in the present application that the running load of the target cluster is too large, when selecting the target compatible cluster corresponding to the target cluster, it is also necessary to judge the running load of the compatible cluster.

[0084] Exemplarily, in the present application, one cluster can correspond to one or more compatible clusters. For example, both the v1 version cluster and the v3 version cluster can compatibly process the task requests corresponding to the v2 version cluster, that is, both the v1 version cluster and the v3 version cluster are compatible clusters of the v2 version cluster. When a task request of the v2 version is obtained, if the first running load of the v2 version cluster is greater than the first load threshold, the second running load (v1 running load) of the v1 version cluster and the second running load (v3 running load) of the v3 version cluster are respectively obtained. Then, the second running load of each compatible cluster can be respectively compared with its corresponding second load threshold, and the compatible cluster with the second running load less than or equal to the second load threshold is determined as the target compatible cluster. For example, if the v1 running load is greater than the second load threshold and the v3 running load is less than the second load threshold, the v3 version cluster can be determined as the target compatible cluster to receive the task request and perform response processing.

[0085] Another exemplarily, if the second running loads of at least two compatible clusters are both less than or equal to the second load threshold, a compatible cluster with a smaller second running load can be selected from the compatible clusters as the target compatible cluster. For example, if the v1 running load is less than the second load threshold and the v3 running load is less than the second load threshold; the CPU resource occupancy rate of the v1 running load is 30% and the CPU resource occupancy rate of the v3 running load is 15%, the v3 version cluster can be determined as the target compatible cluster.

[0086] Yet another exemplarily, if the running loads of the target cluster and each compatible cluster corresponding to the target cluster are all greater than their respective load thresholds, the target cluster can still be waited for to perform response processing on the task request. Or, the amount of data to be processed and the data processing speed of the target cluster and each compatible cluster corresponding to the target cluster in the current running state are respectively obtained. The request waiting time of each cluster (the target cluster and its corresponding compatible clusters) is determined according to the amount of data to be processed and the data processing speed of each cluster (used to represent how long the task request needs to wait to be response processed), and the cluster with the shortest waiting time (which can be the target cluster or a compatible cluster) is selected to receive the task request for response processing.

[0087] Further, it can also be to calculate the time difference between the first waiting time of the target cluster and the second waiting times of each compatible cluster corresponding to the target cluster. In response to all the time differences being less than or equal to the preset time difference threshold, the task request can still be sent to the target cluster for processing. Thus, the request conversion process can be reduced when the time gaps are not obvious, the request conversion time can be saved, and it can also ensure that the data stability will not be affected due to request conversion. In response to one or more of the time differences being greater than the preset time difference threshold, and the second waiting times of the compatible clusters with these time differences being shorter than the first waiting time of the target cluster, the cluster with the shortest waiting time or the smallest running load can be selected from these compatible clusters as the target compatible cluster.

[0088] It should also be noted that in addition to selecting the cluster for processing the task request according to the running load or according to the waiting time as described above, it can also be to set corresponding selection weights for the running load and the waiting time respectively. When there are multiple optional clusters as in the above example, the running load and the waiting time of each optional cluster are processed by weighted summation to obtain the preference value of each optional cluster, and the cluster for responding to the task request is determined from the comparison results of the preference values of each optional cluster. Similarly, in addition to being able to incorporate the running load and the waiting time into the reference factors for selecting the cluster, more evaluation criteria (such as the number of currently docked clients of each cluster, the processing priority of each cluster, etc.) can be adaptively selected, which will not be elaborated here.

[0089] Based on the above embodiments, the embodiments of the present application illustrate the steps before comparing the target cluster version in the task request with the current cluster version of the cluster in the cluster server to obtain a comparison result in response to receiving the task request sent by the client, and the steps of comparing the target cluster version in the task request with the current cluster version of the cluster in the cluster server to obtain a comparison result in response to receiving the task request sent by the client. Specifically, the method of this embodiment includes the following steps:

[0090] Detect whether the current cluster scenario is a single-cluster scenario or a multi-cluster scenario; in response to the current cluster scenario being a multi-cluster scenario and receiving a task request, compare the target cluster version in the task request with the current cluster versions of each cluster to obtain a comparison result.

[0091] Illustrated in combination with the foregoing embodiments, there can be one cluster or multiple clusters in the cluster server of the present application.

[0092] If the application scenario of the present application is in multiple clusters, you can refer to the method provided in the above embodiment, use the version interface compatibility service, actively detect the current cluster version of each cluster in the current cluster service end, analyze the differences between the clusters, and convert the task request into a compatible request through a compatible program, so as to achieve compatible processing of task requests by clusters of different versions, and provide a compatible cluster list. The version cluster identification service can obtain relevant information such as the current cluster list, the compatible cluster list, and the cluster interface list from the version interface compatibility service, so as to identify which specific cluster (target cluster or compatible cluster of the target cluster) the task request should be forwarded to, and forward the task request to the corresponding cluster in combination with the gateway function. For example: multiple clusters include v1, v2, and v3 versions. Through the compatible service v1 cluster supports both v1 interface and v4 interface, then the received v2 task request and v3 task request will be forwarded to their corresponding v2 clusters and v3 clusters, and the received v1 task request and v4 task request will be forwarded to the v1 cluster.

[0093] If the application scenario of this application is in a single cluster, you can Figure 5 As shown, Figure 5 This is a schematic diagram of an exemplary single cluster application scenario in the cluster-based multi-version compatibility method of the present application. The compatible cluster list provided by the version interface compatible service can be used to directly determine whether the cluster supports processing the received task request, omitting the version cluster identification service in the aforementioned embodiment. For example, the client initiates a v1 version request; the version interface compatible service determines that the current cluster is a v1 version cluster through the current cluster version, and directly returns the comparison result through comparison. The gateway directly sends the task request to the v1 version cluster for response; and returns the response result to the client after the v1 version cluster responds. If the client initiates a v2 version request, the version interface compatible service confirms that the current cluster is a v1 version cluster, and determines that the v1 version cluster and the v2 version cluster are compatible through the compatible cluster list, then the v2 task request can be converted into a v1 task request according to the request conversion logic, and then the gateway sends the converted request to the v1 version cluster for response.

[0094] Compared with the multi-cluster scenario, the single-cluster scenario reduces the cluster selection and request forwarding process. It only needs to determine whether the single cluster in the current cluster server supports processing the received task request.

[0095] It should be noted that in the cluster-based multi-version compatibility method of the present application, cluster components (such as etcd components) are used to synchronize the underlying permission data of the cluster in real time, ensuring that the same permission authentication system can be used between different clusters to avoid permission authentication barriers.

[0096] In summary, the cluster-based multi-version compatibility method of the present application can keep the native authentication mechanism unchanged, and can access according to the native user authentication mechanism, so that the authentication mechanisms of any clusters are consistent. In a single-cluster scenario, multi-version task requests can be supported through compatibility technologies. In a multi-cluster scenario, the client does not need to perceive in advance which clusters exist in the cluster server and the version information corresponding to different clusters. Just know the version range supported by the cluster server as a whole, select the API application interface by itself, and then directly send a task request to the cluster server. It can support at least 2 or more versions of API application interfaces, and the cluster server can describe the supported version range in the form of a list. In terms of application scenarios, whether it is a single-cluster scenario or a multi-cluster scenario, it can achieve a seamless upgrade for Kubernetes. For example, seamless upgrade for single-cluster version extension compatibility, seamless upgrade for partial or full amount in multi-cluster scenarios, etc., which will not be elaborated here.

[0097] Further, it should be noted that the execution subject of the cluster-based multi-version compatibility method can be a cluster-based multi-version compatibility device. For example, the cluster-based multi-version compatibility method can be executed by a terminal device, a server, or other processing devices. Among them, the terminal device can be a user equipment (UE), a computer, a mobile device, a user terminal, a terminal, a cellular phone, a cordless phone, a personal digital assistant (PDA), a handheld device, a computing device, a vehicle-mounted device, a wearable device, etc. In some possible implementation manners, the cluster-based multi-version compatibility method can be implemented by a processor calling computer-readable instructions stored in a memory.

[0098] Figure 6 It is a block diagram of a cluster-based multi-version compatibility device shown in an exemplary embodiment of the present application. As Figure 6 shown, the exemplary cluster-based multi-version compatibility device 600 includes: a version comparison module 610, a compatibility determination module 620, a request conversion module 630, and a request sending module 640. Specifically:

[0099] The version comparison module 610 is configured to, in response to receiving a task request sent by a client, perform a version comparison process on the target cluster version in the task request and the current cluster version of the clusters in the cluster server to obtain a comparison result.

[0100] The compatibility determination module 620 is configured to, in response to the comparison result indicating that the target cluster version does not exist in the cluster server, determine a target compatible cluster from the clusters in the cluster server, and the compatible version of the target compatible cluster is compatible with the target cluster version.

[0101] A request conversion module 630 is configured to convert a task request using the above-mentioned compatible version to obtain a compatible request.

[0102] A request sending module 640 is configured to send the compatible request to a target compatible cluster for request response.

[0103] In this exemplary cluster-based multi-version compatibility device, when a task request sent by a client is received, the target cluster version in the task request can be compared with the current cluster version of the cluster in the cluster server to obtain a comparison result, thereby determining whether there is a target cluster in the current cluster server that can directly process the task request; in response to the comparison result indicating that there is no target cluster version in the cluster server, the cluster in the current cluster server cannot directly process the task request, and it is necessary to determine a target compatible cluster that can be compatible with the target cluster from the clusters in the cluster server. The compatible version of the target compatible cluster is compatible with the target cluster version of the target cluster; the task request is converted using the compatible version to obtain a compatible request that can be processed by the target compatible cluster; the compatible request is sent to the target compatible cluster for request response, thereby enabling the user to not need to specify the cluster version when requesting the cluster service, and realizing seamless compatibility between multiple versions and multiple clusters.

[0104] It should be noted that the device provided in the above embodiment and the method provided in the above embodiment belong to the same concept. The specific manners in which each module and unit perform operations have been described in detail in the method embodiment, and will not be repeated here. In practical applications, the device provided in the above embodiment can, according to needs, allocate the above functions to different functional modules, that is, divide the internal structure of the device into different functional modules to complete all or part of the functions described above. This is not limited here.

[0105] Among them, the functions of each module can be referred to in the embodiment of the cluster-based multi-version compatibility method, and will not be repeated here.

[0106] Please refer to Figure 7 , Figure 7 which is a schematic structural diagram of an embodiment of an electronic device of the present application. The electronic device 100 includes a memory 101 and a processor 102. The processor 102 is configured to execute program instructions stored in the memory 101 to implement the steps in any of the above-mentioned embodiments of the cluster-based multi-version compatibility method. In a specific implementation scenario, the electronic device 100 may include, but is not limited to: a microcomputer, a server. In addition, the electronic device 100 may also include mobile devices such as a laptop computer, a tablet computer, etc., which are not limited here.

[0107] Specifically, the processor 102 is used to control itself and the memory 101 to implement the steps in any of the above-described cluster-based multi-version compatibility method embodiments. The processor 102 can also be referred to as a CPU (Central Processing Unit). The processor 102 may be an integrated circuit chip with signal processing capabilities. The processor 102 can also be a general-purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc. Additionally, the processor 102 can be implemented jointly by integrated circuit chips.

[0108] In this exemplary electronic device, when a task request sent by a client is received, version comparison processing can be performed between the target cluster version in the task request and the current cluster version of the cluster in the cluster server to obtain a comparison result, thereby determining whether there is a target cluster in the current cluster server that can directly process the task request; in response to the comparison result indicating that there is no target cluster version in the cluster server, the cluster in the current cluster server cannot directly process the task request, and it is necessary to determine a target compatible cluster that can be compatible with the target cluster from the clusters in the cluster server, and the compatible version of the target compatible cluster is compatible with the target cluster version of the target cluster; the task request is processed and converted according to the compatible version to obtain a compatible request that can be processed by the target compatible cluster; the compatible request is sent to the target compatible cluster for request response, thereby enabling the user to not need to specify the cluster version when requesting cluster services, and realizing seamless compatibility between multiple versions and multiple clusters.

[0109] Please refer to Figure 8 , Figure 8 is a schematic structural diagram of an embodiment of the computer-readable storage medium of the present application. The computer-readable storage medium 110 stores program instructions 111 that can be run by a processor, and the program instructions 111 are used to implement the steps in any of the above-described cluster-based multi-version compatibility method embodiments.

[0110] In this exemplary storage medium, by running the program instructions in the storage medium, when a task request sent by a client is received, the target cluster version in the task request can be compared with the current cluster version of the cluster in the cluster server to obtain a comparison result, thereby determining whether there is a target cluster in the current cluster server that can directly process the task request; in response to the comparison result indicating that there is no target cluster version in the cluster server, the cluster in the current cluster server cannot directly process the task request, and it is necessary to determine a target compatible cluster that can be compatible with the target cluster from the clusters in the cluster server, and the compatible version of the target compatible cluster is compatible with the target cluster version of the target cluster; the task request is processed and converted according to the compatible version to obtain a compatible request that the target compatible cluster can process; the compatible request is sent to the target compatible cluster for request response, thereby enabling the user to not need to specify the cluster version when requesting the cluster service, and realizing seamless compatibility between multiple versions and multiple clusters.

[0111] In some embodiments, the functions or modules included in the device provided by the embodiments of the present disclosure can be used to execute the methods described in the above method embodiments. The specific implementation can refer to the description of the above method embodiments. For the sake of brevity, it will not be repeated here.

[0112] The descriptions of the above embodiments tend to emphasize the differences between the embodiments. The same or similar parts can be referred to each other. For the sake of brevity, they will not be repeated in this article.

[0113] In several embodiments provided in the present application, it should be understood that the disclosed methods and devices can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of modules or units is only a logical function division. In actual implementation, there may be other division methods. For example, 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 displayed or discussed mutual coupling or direct coupling or communication connection can be through some interfaces. The indirect coupling or communication connection of the device or unit can be in an electrical, mechanical or other form.

[0114] In addition, each functional unit in various embodiments of the present application may be integrated into one processing unit, or each unit may exist physically alone, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of a software functional unit. If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it may be stored in a computer-readable storage medium. Based on such an understanding, the technical solution of the present application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, may be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) or a processor to execute all or part of the steps of the methods in various embodiments of the present application. The aforementioned storage medium includes: various media that can store program codes such as USB flash drives, mobile hard disks, read-only memories (ROMs), random access memories (RAMs), magnetic disks, or optical discs.

Claims

1. A cluster-based multi-version compatibility method, characterized in that: The method is applied to a multi-version compatible device, the multi-version compatible device is connected to a cluster server for communication, and the multi-version compatible device is connected to a client for communication, and the method includes: Obtaining interface information of each cluster in the cluster server; comparing each interface information to obtain interface differences between each cluster; determining compatible clusters supporting conversion processing in each cluster according to the interface differences; establishing a compatible mapping relationship between each compatible cluster; In response to receiving the task request sent by the client, performing version comparison processing according to the target cluster version in the task request and the current cluster version of each cluster in the cluster server to obtain a comparison result; In response to the comparison result indicating that the target cluster version does not exist in the cluster server, a target compatible cluster is determined from each compatible cluster according to the compatible mapping relationship and the running load of each compatible cluster, and the compatible version of the target compatible cluster is compatible with the target cluster version; Convert the task request according to the compatible version to obtain a compatible request; The converting the task request according to the compatible version to obtain a compatible request includes: converting the request path information of the task request according to a preset conversion logic between the target cluster version and the compatible version to obtain the compatible request; The compatibility request is sent to the target compatible cluster for request response.

2. The method according to claim 1, characterized in that After comparing the interface information to obtain the interface differences of the clusters, the method further includes: Determine a compatible cluster that does not support conversion processing among the clusters according to the interface differences; In response to the received compatible program development instruction for the cluster to be compatible, a compatible program for the cluster to be compatible is generated, wherein the compatible program is used to perform conversion processing on the task request.

3. The method according to claim 1, characterized in that In the response to receiving the task request sent by the client, performing version comparison processing according to the target cluster version in the task request and the current cluster version of each cluster in the cluster server, after obtaining the comparison result, the method further includes: In response to the comparison result indicating that a target cluster corresponding to the target cluster version exists in each cluster, obtaining a first running load of the target cluster; comparing the first operating load with a first load threshold of the target cluster; In response to the first operating load being greater than the first load threshold, a target compatible cluster corresponding to the target cluster version is identified among the clusters.

4. The method according to claim 3, characterized in that In response to the first running load being greater than the first load threshold, identifying a target compatible cluster corresponding to the target cluster version in each cluster includes: In response to the first running load being greater than the first load threshold, obtaining a second running load of each compatible cluster corresponding to the target cluster version; A compatible cluster whose second operating load is less than or equal to a second load threshold is determined as the target compatible cluster.

5. The method according to claim 1, characterized in that In response to receiving the task request sent by the client, performing version comparison processing according to the target cluster version in the task request and the current cluster version of each cluster in the cluster server to obtain the comparison result, the method further includes: Detect whether the current cluster scenario is a single cluster scenario or a multi-cluster scenario; In response to receiving the task request sent by the client, performing version comparison processing according to the target cluster version in the task request and the current cluster version of each cluster in the cluster server to obtain a comparison result includes: In response to the current cluster scenario being a multi-cluster scenario and receiving the task request, the target cluster version in the task request is compared with the current cluster version of each cluster to obtain the comparison result.

6. An electronic device, characterized in that: The method comprises a memory and a processor, wherein the processor is used to execute program instructions stored in the memory to implement the method according to any one of claims 1 to 5.

7. A computer-readable storage medium having program instructions stored thereon, characterized in that: When the program instructions are executed by a processor, the method according to any one of claims 1 to 5 is implemented.

Images