Cluster service high availability method, device, computer equipment and storage medium

Abstract

The application provides a cluster service high availability method, device, computer equipment and storage medium. The method comprises the following steps: judging whether there is a compatibility risk when more than two pods execute a target cluster service; if there is no compatibility risk, generating more than two pods to execute the target cluster service simultaneously; if there is a compatibility risk, judging whether there is a corresponding elimination means for the compatibility risk; if there is a corresponding elimination means for the compatibility risk, taking the corresponding elimination means for the compatibility risk, and generating more than two pods to execute the target cluster service simultaneously; if there is no corresponding elimination means for the compatibility risk, generating more than two pods, and selecting one pod from the more than two pods to execute the target cluster service by using a master selection mode. The method effectively realizes the cluster service high availability in Kubernetes, improves the number of replicas of a single service, guarantees the stability of the cluster, and reduces the service interruption time.

Description

Technical Field

[0001] This application relates to the field of container technology, and in particular to a method, apparatus, computer device, and storage medium for high availability of cluster services. Background Technology

[0002] With the rapid development of the open-source platform Kubernetes (K8s), many service providers have begun deploying their services to Kubernetes clusters to provide services to the outside world. However, due to the possibility of software and hardware failures as well as human error, there is a risk of forced service interruption in the cluster. Traditional cluster services do not have the characteristics of high availability, which means that services cannot be provided to users during failures, negatively impacting users who rely on cluster services. Summary of the Invention

[0003] The purpose of this application is to at least address one of the aforementioned technical deficiencies, particularly the technical deficiency of poor high availability of cluster services in the prior art.

[0004] Firstly, this application provides a method for high availability of cluster services, including: determining whether there is a compatibility risk when two or more pods execute the target cluster service; if there is no compatibility risk, generating two or more pods to execute the target cluster service simultaneously; if there is a compatibility risk, determining whether there is a corresponding elimination method for the compatibility risk; if there is a corresponding elimination method for the compatibility risk, adopting the elimination method corresponding to the compatibility risk and generating two or more pods to execute the target cluster service simultaneously; if there is no corresponding elimination method for the compatibility risk, generating two or more pods and selecting one pod from them using a leader election mode to execute the target cluster service.

[0005] In one embodiment, before selecting a pod from the generated pods to execute the target cluster service using the master election mode, the process includes: exposing the target cluster service to the outside world to receive service access requests; selecting a pod from the generated pods to execute the target cluster service using the master election mode, which includes: selecting a pod from the generated pods as the master pod and the remaining pods as slave pods; and redirecting the service access request to the master pod.

[0006] In one embodiment, any pod, after being selected as the primary pod, sets its own identifier to a first identifier, and after being selected as a secondary pod, sets its own identifier to a second identifier; redirecting service access requests to the primary pod includes: setting the selection identifier of the Kubernetes Service to the first identifier so that service access requests are distributed to the primary pod.

[0007] In one embodiment, the compatibility risk includes a first risk, which involves determining whether there is a compatibility risk when two or more pods execute the target cluster service. This includes: determining whether there is a fixed-time periodic task based on the code logic of the target cluster service; a fixed-time periodic task is a task that is executed at a fixed time point in each execution cycle; if a fixed-time periodic task exists, then the first risk is determined to exist.

[0008] In one embodiment, the means of eliminating the first risk includes: modifying the code logic of the target cluster service to change the fixed-point periodic task into a random periodic task; the random periodic task is a task executed at a random time point in each execution cycle.

[0009] In one embodiment, the compatibility risk includes a second risk. Determining whether there is a compatibility risk when the target cluster service is executed by two or more pods includes: determining whether there are statements that read the local cache based on the code logic of the target cluster service; if there are statements that read the local cache, then it is determined that there is a second risk.

[0010] In one embodiment, the means of eliminating the second risk includes modifying the code logic of the target cluster service to change the statement that reads the local cache to a statement that reads the remote shared cache.

[0011] In one embodiment, generating two or more pods to simultaneously execute the target cluster service includes: configuring the ReplicaSet with redundancy to generate two or more pods to simultaneously execute the target cluster service.

[0012] Secondly, embodiments of this application provide a high-availability cluster service device, comprising: a risk assessment module for determining whether there is a compatibility risk when two or more pods execute a target cluster service; a first execution module for generating two or more pods to execute the target cluster service simultaneously if there is no compatibility risk; a means assessment module for determining whether there is a corresponding means to eliminate the compatibility risk if there is a compatibility risk; a second execution module for taking the corresponding means to eliminate the compatibility risk if there is a compatibility risk, and generating two or more pods to execute the target cluster service simultaneously if there is no corresponding means to eliminate the compatibility risk; and a third execution module for generating two or more pods and selecting one pod from them to execute the target cluster service using a leader election mode if there is no corresponding means to eliminate the compatibility risk.

[0013] Thirdly, embodiments of this application provide a computer device including one or more processors and a memory storing computer-readable instructions. When the computer-readable instructions are executed by one or more processors, they perform the steps of the cluster service high availability method in any of the above embodiments.

[0014] Fourthly, embodiments of this application provide a storage medium storing computer-readable instructions. When executed by one or more processors, the computer-readable instructions cause the one or more processors to perform the steps of the cluster service high availability method in any of the above embodiments.

[0015] As can be seen from the above technical solutions, the embodiments of this application have the following advantages:

[0016] Based on any of the above embodiments, for any target cluster service, it is first determined whether increasing the number of pods running the service simultaneously to improve the high availability of the target cluster service will bring compatibility risks. If there are no compatibility risks or the compatibility risks can be eliminated, high availability is enhanced by generating two or more pods to run the target cluster service simultaneously. If the compatibility risks brought by this method cannot be eliminated, high availability is enhanced by utilizing Kubernetes' leader election mode. This method effectively achieves high availability of cluster services in Kubernetes, increases the number of replicas of a single service, and avoids the occurrence of single points of failure. After the cluster service achieves high availability, the stability of the cluster is improved. When some service nodes fail and become unusable, other replicas can continue to provide services, reducing service interruption time. For different target cluster services, a suitable refactoring scheme can be selected based on the two determinations in this application (e.g., it can be determined whether the source code needs to be modified), effectively reducing the workload of refactoring the cluster service to high availability. Attached Figure Description

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

[0018] Figure 1 A flowchart illustrating the high availability method for cluster services provided in this application embodiment;

[0019] Figure 2 A module structure diagram of the high availability device for cluster services provided in the embodiments of this application;

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

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

[0022] Firstly, this application provides a method for high availability of cluster services; please refer to [link to relevant documentation]. Figure 1 This includes steps S102 to S110.

[0023] S102 determines whether there are compatibility risks when two or more pods execute the target cluster service.

[0024] As is understandable, a cluster typically consists of several master nodes and worker nodes. A cluster can integrate host resources and manage resources such as network, storage, CPU, and memory. This application focuses on clusters managed by Kubernetes, where containers are more lightweight and have better scalability. The target cluster service is a service deployed within the cluster.

[0025] A pod is the smallest deployable service unit created and managed in Kubernetes. To enhance high availability, a common approach is to have two or more pods simultaneously provide services to the target cluster, so that if one pod fails, the remaining healthy pods can continue providing service. However, different cluster services have different business logic, and there may be target cluster services that are unsuitable for using more than two pods; that is, using this approach may pose compatibility risks. Specifically, compatibility risks can be divided into at least two main categories: consistency risks and duplicate operation risks. Consistency risks refer to inconsistencies in data sources between different pods, leading to problems in processing external requests. Duplicate operation risks refer to different pods repeatedly processing the same task, which wastes resources and may also cause service errors.

[0026] Therefore, before running the target cluster service using two or more pods simultaneously, it is necessary to determine whether there are any compatibility risks. If so, proceed to step S104; otherwise, proceed to step S106. Methods for determining compatibility risks include analyzing the code logic of the target cluster service and recording the code logic with compatibility risks. Alternatively, during the testing phase, run the target cluster service using two or more pods simultaneously. When errors occur and vulnerabilities are patched, determine whether the error is caused by a compatibility risk (i.e., whether the same error occurs when running the service using a single pod). If so, determine that the code logic corresponding to the error has a compatibility risk and record it. As the risk record becomes richer, the ability to determine compatibility risks also gradually improves.

[0027] S104 If there is no compatibility risk, generate two or more pods to run the target cluster service simultaneously.

[0028] Understandably, when there are no compatibility risks, two or more pods can be created to run the target cluster service simultaneously. Kubernetes will automatically terminate failed pods and create new pods, ensuring a stable number of replicas and achieving high availability. In one embodiment, redundancy (replicas) can be configured on the ReplicaSet to create two or more pods to run the target cluster service simultaneously.

[0029] S106 If there is a compatibility risk, determine whether there are corresponding means to eliminate the compatibility risk.

[0030] It is understandable that different code logics can be used to achieve the same functionality. When compatibility risks exist, some can be eliminated by modifying the code logic, meaning there are corresponding elimination methods. If the compatibility risk can be eliminated, high availability can still be enhanced by using two or more pods to run the target cluster service simultaneously. Therefore, when a compatibility risk is identified, it can be further analyzed to determine if there are corresponding elimination methods. If so, proceed to step S108; otherwise, proceed to step S110.

[0031] S108 If there are corresponding elimination methods for compatibility risks, then the corresponding elimination methods for compatibility risks will be adopted, and two or more pods will be generated to execute the target cluster service simultaneously.

[0032] It's understandable that after implementing measures to eliminate compatibility risks, these risks will be removed, allowing two or more pods to run the modified target cluster service simultaneously without issues. Therefore, even after eliminating compatibility risks, the approach of generating two or more pods to run the target cluster service concurrently is still used to enhance high availability.

[0033] S110 If there is no corresponding means to eliminate the compatibility risk, then generate two or more pods and select one of them to execute the target cluster service using the leader election mode.

[0034] Understandably, if compatibility risks cannot be eliminated, this embodiment chooses another method to enhance high availability: utilizing Kubernetes' leader election mode. A leader election is held between two or more pods, and the elected pod becomes the leader, while the others become followers. Only the leader pod executes the target cluster service and provides external services. Follower pods monitor the leader pod's status, and if the leader pod loses its leader position, all pods restart the leader election process. In Kubernetes, leader election is generally based on resource locks. Pods created to serve the target cluster attempt to acquire resource locks. The pod that acquires the lock immediately becomes the leader pod, and can maintain its position by updating the lock's holding time (renewTime). Other follower pods continue to attempt to lock resources. If the leader fails to update its holding time within the configured time period, it immediately loses its leader position, and the pod that acquired the lock becomes the new leader.

[0035] Based on the high availability method for cluster services in this embodiment, for any target cluster service, it first determines whether increasing the number of pods running the service simultaneously to improve its high availability will introduce compatibility risks. If no compatibility risks are introduced or the risks can be eliminated, high availability is enhanced by generating two or more pods to run the target cluster service simultaneously. If the compatibility risks cannot be eliminated, high availability is enhanced using Kubernetes' leader election mode. This method effectively achieves high availability for cluster services in Kubernetes, increases the number of replicas for a single service, and avoids single points of failure. After achieving high availability, the stability of the cluster is improved. When some service nodes become unusable due to anomalies, other replicas can continue to provide services, reducing service interruption time. For different target cluster services, a suitable refactoring scheme can be selected based on the two determinations in this application (e.g., determining whether source code modification is required), effectively reducing the workload of refactoring high availability for cluster services.

[0036] In one embodiment, the applicant discovered that while using traditional master election methods to improve availability, the traditional approach did not expose the target cluster service's interface. This caused Kubernetes to distribute traffic evenly across all pods generated for the target cluster service, resulting in user requests being rejected when traffic was received by a pod. Therefore, this embodiment, to better route user requests to the master pod, includes the following steps before selecting a pod to execute the target cluster service using the master election pattern: exposing the target cluster service's interface to receive service access requests. After exposing the target cluster service's interface, the master election pattern is used to select a pod as the master pod from the generated pods, with the remaining pods acting as slave pods, and service access requests are redirected to the master pod. This ensures that the master pod handles service access requests, preventing user requests from being rejected by slave pods that are not providing services.

[0037] In one embodiment, to ensure that service access requests are accurately routed to the master pod, this embodiment utilizes Kubernetes Service resources. The Service is configured with a selector, and it distributes traffic based on the selection identifier in the selector. Specifically, the Service routes service access requests to pods with the same selection identifier as the selector. Therefore, it is necessary to configure at least two pods corresponding to the target cluster service so that any pod, when selected as the master pod, sets its identifier to the first identifier, and when selected as a slave pod, sets its identifier to the second identifier. The different identifiers between the master and slave pods allow the Service to accurately allocate requests to the master pod for processing. After this configuration, a pod that becomes the master pod actively modifies its identifier to the first identifier to indicate its master pod status. When it loses its master pod status and becomes a slave pod, it also actively modifies its identifier to the second identifier to prevent service rejection. After completing the above configuration for the pods, by setting the Kubernetes Service's selection identifier to the first identifier, service access requests can be allocated to the master pod.

[0038] In one embodiment, the compatibility risk includes a first risk, determining whether there is a compatibility risk when the target cluster service is executed by two or more pods, including:

[0039] (1) Determine whether there are fixed-point periodic tasks based on the code logic of the target cluster service.

[0040] Understandably, Kubernetes provides two resource objects, Job and CronJob, to address the need for time-based job scheduling. Configuring a CronJob allows tasks to run periodically at a given time; tasks executed at a fixed time in each execution cycle are called fixed-time periodic tasks. However, if more than two pods are configured to serve the target cluster, the fixed-time periodic task may be processed concurrently by more than two pods, leading to consistency risks. Of course, in this case, the fixed-time periodic task is essentially being executed repeatedly by more than two pods, and the primary risk is also the risk of duplicate operations.

[0041] (2) If there are fixed-point periodic tasks, then the first risk is identified.

[0042] When code related to fixed-point periodic tasks is found in the target cluster service, a first risk can be identified. This first risk is one that can be mitigated by modifying the code logic. Specifically, in one embodiment, the elimination method for the first risk includes modifying the code logic of the target cluster service to change the fixed-point periodic tasks into random periodic tasks. Random periodic tasks are tasks executed at random times within each execution cycle. That is, by changing periodic tasks to execute at random times, the possibility of two or more pods executing tasks at the same time can be reduced, thus eliminating the first risk.

[0043] In one embodiment, the compatibility risk includes a second risk, determining whether there is a compatibility risk when the target cluster service is executed by two or more pods, including:

[0044] (1) Determine whether there is a statement that reads the local cache based on the code logic of the target cluster service.

[0045] It's understandable that local caches between different pods cannot be shared. Data with the same name might yield different results when read from the local caches of different pods, such as lists and dictionaries defined in the main function of a service. This leads to data inconsistency issues between different pods, i.e., consistency risks.

[0046] (2) If there is a statement that reads the local cache, then the second risk is identified.

[0047] When statements that read local cache are found in the target cluster service, a second risk can be identified. This second risk is one that can be mitigated by modifying the code logic. Specifically, in one embodiment, the elimination method for the second risk includes modifying the code logic of the target cluster service to change the statements that read local cache to statements that read remote shared cache. That is, the data of two or more pods corresponding to the target cluster service uses the same remote shared cache (Redis), which ensures the consistency of read and write operations, sharing the same cache, and thus avoiding the second risk.

[0048] Secondly, embodiments of this application provide a cluster service high availability device; please refer to [link to relevant documentation]. Figure 2 The system includes a risk assessment module 210, a first execution module 220, a means assessment module 230, a second execution module 240, and a third execution module 250. The risk assessment module 210 determines whether there is a compatibility risk when two or more pods execute the target cluster service. The first execution module 220 generates two or more pods to execute the target cluster service simultaneously when there is no compatibility risk. The means assessment module 230 determines whether there is a corresponding means to eliminate the compatibility risk when it exists. The second execution module 240 takes the corresponding means to eliminate the compatibility risk when it exists, and generates two or more pods to execute the target cluster service simultaneously. The third execution module 250 generates two or more pods when there is no corresponding means to eliminate the compatibility risk, and selects one pod from them using a leader election mode to execute the target cluster service.

[0049] In one embodiment, the third execution module 250 further includes an interface exposure unit and a traffic allocation unit. The interface exposure unit is used to expose interfaces of the target cluster service to receive service access requests. The traffic allocation unit is used to select one pod from the generated pods as the master pod using a master election mode, with the remaining pods as slave pods, and to redirect service access requests to the master pod.

[0050] In one embodiment, any pod, after being selected as the primary pod, sets its own identifier to a first identifier, and after being selected as a secondary pod, sets its own identifier to a second identifier. The traffic allocation unit is used to set the selection identifier of the Kubernetes Service to the first identifier.

[0051] In one embodiment, the risk assessment module 210 is used to determine whether a fixed-time periodic task exists based on the code logic of the target cluster service. A task executed at a fixed time point in each execution cycle is called a fixed-time periodic task. The risk assessment module 210 is also used to determine the existence of a first risk when it is determined that a fixed-time periodic task exists.

[0052] In one embodiment, the second execution module 240 is used to modify the code logic of the target cluster service to change the fixed-point periodic task into a random periodic task. A random periodic task is a task that is executed at a random time point in each execution cycle.

[0053] In one embodiment, the risk assessment module 210 is used to determine whether there is a statement that reads the local cache based on the code logic of the target cluster service. The risk assessment module 210 is also used to determine the existence of a second risk if it determines that a statement that reads the local cache exists.

[0054] In one embodiment, the second execution module 240 is used to modify the code logic of the target cluster service to change the statement that reads the local cache to a statement that reads the remote shared cache.

[0055] Specific limitations regarding the high availability device for cluster services can be found in the limitations of the high availability method for cluster services described above, and will not be repeated here. Each module in the aforementioned high availability device for cluster services can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the computer device in hardware form, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module. It should be noted that the module division in this embodiment is illustrative and only represents a logical functional division; other division methods may be used in actual implementation.

[0056] Thirdly, embodiments of this application provide a computer device, including one or more processors and a memory. The memory stores computer-readable instructions. When the computer-readable instructions are executed by one or more processors, they perform the following: determining whether there is a compatibility risk when two or more pods execute the target cluster service; if there is no compatibility risk, generating two or more pods to execute the target cluster service simultaneously; if there is a compatibility risk, determining whether there is a corresponding elimination method for the compatibility risk; if there is a corresponding elimination method for the compatibility risk, adopting the elimination method corresponding to the compatibility risk and generating two or more pods to execute the target cluster service simultaneously; if there is no corresponding elimination method for the compatibility risk, generating two or more pods and selecting one pod from them using a leader election mode to execute the target cluster service.

[0057] In one embodiment, when computer-readable instructions are executed by one or more processors, the steps of the cluster service high availability method in any of the above embodiments are performed.

[0058] Indicatively, such as Figure 3 As shown, Figure 3This is a schematic diagram of the internal structure of a computer device 300 provided in an embodiment of this application. The computer device 300 can be provided as a server. (Refer to...) Figure 3 The computer device 300 includes a processing component 302, which further includes one or more processors, and memory resources represented by memory 301 for storing instructions, such as applications, that can be executed by the processing component 302. The applications stored in memory 301 may include one or more modules, each corresponding to a set of instructions. Furthermore, the processing component 302 is configured to execute instructions to perform the cluster service high availability method of any of the above embodiments.

[0059] The computer device 300 may also include a power supply component 303 configured to perform power management of the computer device 300, a wired or wireless network interface 304 configured to connect the computer device 300 to a network, and an input / output (I / O) interface 305. The computer device 300 may operate on an operating system stored in memory 301, such as Windows Server™, Mac OS X™, Unix™, Linux™, Free BSD™, or similar.

[0060] Those skilled in the art will understand that Figure 3 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0061] Fourthly, embodiments of this application provide a storage medium storing computer-readable instructions. When executed by one or more processors, the computer-readable instructions cause the one or more processors to perform the following: determine whether there is a compatibility risk when two or more pods execute the target cluster service; if there is no compatibility risk, generate two or more pods to execute the target cluster service simultaneously; if there is a compatibility risk, determine whether there is a corresponding elimination method for the compatibility risk; if there is a corresponding elimination method for the compatibility risk, adopt the elimination method corresponding to the compatibility risk and generate two or more pods to execute the target cluster service simultaneously; if there is no corresponding elimination method for the compatibility risk, generate two or more pods and select one pod from them using a leader election mode to execute the target cluster service.

[0062] In one embodiment, when computer-readable instructions are executed by one or more processors, the one or more processors cause the one or more processors to perform the steps of the cluster service high availability method in any of the above embodiments.

[0063] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0064] The various embodiments in this specification are described in a progressive manner. Each embodiment focuses on the differences from other embodiments. The various embodiments can be combined as needed, and the same or similar parts can be referred to each other.

[0065] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for high availability of cluster services, characterized in that, include: Determine if there are compatibility risks when two or more pods are running services on the target cluster. If the aforementioned compatibility risk does not exist, then generate two or more pods to simultaneously execute the target cluster service; If the aforementioned compatibility risk exists, then determine whether there are corresponding means to eliminate the compatibility risk; If there is a corresponding elimination method for the compatibility risk, then the elimination method corresponding to the compatibility risk shall be adopted, and two or more pods shall be generated to execute the target cluster service simultaneously. If there is no corresponding elimination method for the compatibility risk, then two or more pods are generated, and a pod is selected from them using the leader election mode to execute the target cluster service.

2. The method according to claim 1, characterized in that, Before selecting a pod from the selected pods using the leader election mode to execute the target cluster service, the process includes: exposing the target cluster service to external interfaces to receive service access requests; The step of selecting a pod from the cluster using a leader election mode to execute the target cluster service includes: Using the master selection mode, select one pod from the generated pods as the master pod, and the remaining pods as slave pods; The service access request is redirected to the main pod.

3. The method according to claim 2, characterized in that, When a pod is selected as the master pod, it sets its own identifier to the first identifier; when it is selected as the slave pod, it sets its own identifier to the second identifier. The step of redirecting the service access request to the main pod includes: Set the selection identifier of the Kubernetes Service to the first identifier so that the service access request is assigned to the master pod.

4. The method according to claim 1, characterized in that, The compatibility risk includes a first risk. The determination of whether there is a compatibility risk when the target cluster service is executed by two or more pods includes: Based on the code logic of the target cluster service, determine whether there are fixed-point periodic tasks; the fixed-point periodic task is a task that is executed at a fixed time point in each execution cycle. If the aforementioned fixed-point periodic task exists, then the first risk is determined to exist.

5. The method according to claim 4, characterized in that, The elimination measures corresponding to the first risk include: The code logic of the target cluster service is modified to change the fixed-point periodic task into a random periodic task; the random periodic task is a task executed at a random time point in each execution cycle.

6. The method according to claim 1, characterized in that, The compatibility risk includes a second risk. The determination of whether there is a compatibility risk when the target cluster service is executed by two or more pods includes: Based on the code logic of the target cluster service, determine whether there are statements that read the local cache; If the statement that reads the local cache exists, then the second risk is determined to exist.

7. The method according to claim 6, characterized in that, The elimination measures corresponding to the second risk include: The code logic of the target cluster service is modified to change the statement that reads the local cache to a statement that reads the remote shared cache.

8. The method according to claim 1, characterized in that, The process of generating two or more pods to simultaneously execute the target cluster service includes: Configure redundancy in the ReplicaSet to generate two or more pods that simultaneously run the target cluster service.

9. A high-availability device for cluster services, characterized in that, include: The risk assessment module is used to determine whether there are compatibility risks when two or more pods execute the target cluster service; The first execution module is used to generate two or more pods to execute the target cluster service simultaneously when there is no compatibility risk. The means determination module is used to determine whether there are corresponding means to eliminate the compatibility risk when the compatibility risk exists; The second execution module is used to take the elimination method corresponding to the compatibility risk when the compatibility risk exists, and generate two or more pods to execute the target cluster service simultaneously. The third execution module is used to generate two or more pods when there is no corresponding elimination method for the compatibility risk, and select one pod from them using the leader election mode to execute the target cluster service.

10. A computer device, characterized in that, It includes one or more processors and a memory storing computer-readable instructions that, when executed by the one or more processors, perform the steps of the cluster service high availability method as described in any one of claims 1 to 8.

11. A storage medium, characterized in that, The storage medium stores computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of the cluster service high availability method as described in any one of claims 1 to 8.

Images