Failover process for pods running applications in high availability mode.

Abstract

The techniques disclosed herein enable a service manager of a container orchestration platform to handle failover of pods running an application in high availability mode. In a particular example, the method includes receiving pod information, which includes a unique application identifier generated by the application and an indication of which of the pods is active and which is standby. The method further includes configuring the service objects provided by the container orchestration platform for the pods to correspond to each of the pods based on the unique application identifier. The method also includes receiving updated pod information indicating that a first pod, which was a standby, is now active, having a first application identifier among the unique application identifiers previously assigned to a second pod that failed. In addition, the method includes reconfiguring the service object associated with the first application identifier to correspond to the first pod instead of the second pod.

Description

Background Art

[0001] Background Container orchestration platforms such as Kubernetes (registered trademark) generally manage the deployment of containerized applications in what is commonly referred to as a pod. Each pod can contain one or more containers for running application processes within it. Kubernetes is at least one platform that does not natively include a function to support the high availability of applications running in pods. For example, an application that supports high availability may specify a set of active pods and a set of standby pods. If one of the active pods fails, the application designates one of the standby pods to take over the failed pod. However, since Kubernetes does not support the failover function of applications, a service object that makes one or more pods available on the network still indicates the failed pod even after the pod has been regenerated within the standby set as instructed by the application. The service does not indicate the pod activated by the application to take over the failed pod.

Summary of the Invention

[0002] Summary The techniques disclosed herein enable a service manager of a container orchestration platform to handle failover of pods running an application in high availability mode. In a particular example, the method includes receiving pod information about a pod. The pod information includes a unique application identifier generated for the pod by the application, and an indication of which of the pods is active and which is standby. The pods are orchestrated by the container orchestration platform. The method further includes configuring service objects provided by the container orchestration platform to correspond to each of the pods based on their unique application identifiers. The service objects expose the corresponding pods to the network. The method also includes receiving updated pod information indicating that a first pod, which was previously standby, is now active, having a first application identifier that was previously assigned to a second pod, which was a failed pod. In addition, the method includes reconfiguring the service object associated with the first application identifier to correspond to the first pod instead of the second pod.

[0003] In other examples, the device performs the methods described above, and program instructions stored on a computer-readable storage medium instruct the processing system to perform the methods described above. [Brief explanation of the drawing]

[0004] [Figure 1] This figure shows an embodiment for handling failover of pods running applications in high availability mode. [Figure 2] This diagram illustrates the behavior for handling failover of pods running applications in high availability mode. [Figure 3A]This diagram shows an operational scenario for handling failover of pods running applications in high availability mode. [Figure 3B] This diagram shows an operational scenario for handling failover of pods running applications in high availability mode. [Figure 3C] This diagram shows an operational scenario for handling failover of pods running applications in high availability mode. [Figure 4] This diagram shows a computing system for handling failover of pods running applications in high-availability mode. [Modes for carrying out the invention]

[0005] Detailed explanation Container orchestration platforms, which organize containers into pods, can use service objects (often simply called services) to make those pods available to the communication network. When data on the network is targeted to applications running in the pods, the container orchestration platform handles this, and the service object corresponding to the pod directs the data to the pod. Kubernetes is one example of a container orchestration platform that uses service objects, but other container orchestration platforms can use service objects, or something similar, in a similar manner. Traditionally, if a pod fails, the service object continues its association with that pod. Therefore, communication with the pod and processing by the pod are suspended until the pod recovers (e.g., is regenerated by the container orchestration platform). Even if the pod recovers in a relatively short time, that time may be enough to negatively impact the functionality provided by the application running in the pod. For example, if the application provides transcoding functionality for real-time user communication sessions, a pod failure may cause undesirable gaps in communication or cause sessions to drop completely.

[0006] Applications can be configured to operate in high-availability mode across pods to avoid problems caused by pod failures. If an active pod fails, the application can activate another standby pod to take its place. However, the service object for the failed pod does not automatically switch its association from the failed pod to the newly activated pod, preventing the application in the newly activated pod from taking over from the application in the failed pod. The service manager described in the following example reconfigures its service object when a failure occurs in the pod associated with it. The service manager identifies the newly activated pod and associates the service object with the newly activated pod instead of the failed pod. At this point, communications that would have been exchanged with the failed pod can be exchanged with the newly activated pod instead.

[0007] Figure 1 shows an embodiment 100 for handling failover of pods running applications in high availability mode. Embodiment 100 includes a service manager 101, an active pod 122, a standby pod 123, an active service 124, a standby service 125, a server 107, and a communication network 108. The active pod 122, the standby pod 123, the active service 124, and the standby service 125 are implemented by a container orchestration platform 106 and run on one or more servers 107 (however, other types of computing systems may be used). The communication network 108 links the servers 107 to each other and can connect the servers 107 to other systems and networks (e.g., the Internet). The service manager 101 is an application process run by the server 107 to manage the active service 124 and the standby service 125. The service manager 101 can be implemented in pods running on the server 107. In some examples, the service manager 101 may be a process that runs on a computing system other than the server 107 and communicates with the server 107 via a communication network 108.

[0008] In operation, application 111 is an application that supports running in high-availability mode within a pod orchestrated by the container orchestration platform 106. Application 111 can perform any type of processing function. In this example, application 111 is running in one or more active pods 122 and a standby pod 123. An instance of application 111 running in an active pod 122 is active and ready to perform as configured (e.g., processing incoming communications) if it is not already actively running. An instance of application 111 running in a standby pod 123 is standby and does not perform actively until activated (e.g., when one of the active pods 122 fails). Active service 124 is a service object that exposes the active pods 122 to the network (i.e., makes the active pods 122 accessible), and the active pods 122 can exchange communications over this network. The network may be a logical network connecting the pods. Similarly, service object 105 is a service object that exposes standby pod 123 to the network. However, since standby pod 123 is a standby, such communication with standby pod 123 is usually little to no.

[0009] While a single service object in other examples can serve multiple pods, in this example, service objects have a one-to-one correspondence with the pods associated with them. For example, service object 104 is one of the active services 124 and is associated with pod 102 of the active pods 122. Different service objects of active service 124 are then associated with other pods of active pods 122. Similarly, service object 105 is one of the standby services 125 and is associated with pod 103 of the standby pods 123. Different service objects of standby service 125 are then associated with other pods of standby pods 123. The service manager 101 maintains this one-to-one correspondence to ensure that even if one of the active pods 122 fails, one of the active services 124 will still be connected to one of the active pods 122.

[0010] Figure 2 shows operation 200 for handling failover of pods running an application in high availability mode. In operation 200, service manager 101 receives pod information (201) for pods 122-123. The pod information includes a unique application identifier generated by application 111 for pods 122-123, and indications of which of the pods is active (i.e., contained in active pod 122) and which is standby (i.e., contained in standby pod 123). The unique application identifier can be any data (e.g., letters, strings, numbers, etc.) that is unique at least within active pod 122, but can also be unique across all of pods 122 and 123. For simplicity, in this example, the unique application identifier is a single digit number. For example, 1 is the unique application identifier for pod 102, and 2 is the unique application identifier for pod 103. A unique application identifier may be assigned by application 111 (for example, application 111 on each pod may assign itself a unique application identifier after ensuring the uniqueness of the unique application identifier) ​​or by the application controller for application 111. Pods 122-123 are identified to service manager 101 by their respective labels. Similar to the unique application identifier, the label can be any data that uniquely identifies a particular pod from the others among pods 122-123. For clarity, the pod labels in this example are closely related to the reference numbers used in embodiment 100 for pods 122-123 (for example, the label for pod 102 is POD-102).

[0011] Therefore, the received pod information informs the service manager 101 which pods identified by their unique labels are active or standby, and which unique application identifiers are assigned to application 111 on that pod. For example, the pod information indicates that pod label POD-102 is associated with the active pod having unique application identifier 1, and pod label POD-103 is associated with the standby pod having unique application identifier 2. The same type of information is received for the rest of pods 122-123. In this example, each of pods 122-123 sends pod information for its respective portion to the service manager 101. In another example, an application controller for application 111 could collect pod information from pods 122-123 and pass the pod information to the service manager 101. The pod information can be pushed to the service manager 101 or sent in response to a request from the service manager 101.

[0012] The service manager 101 configures the service objects 124-125 provided by the container orchestration platform 106 to correspond to each of the pods 122-123, respectively, based on a unique application identifier (202). If one or more of the service objects 124-125 do not yet exist, configuring the service objects 124-125 includes creating those service objects that do not yet exist. Each of the service objects 124-125 is configured to correspond to one of the pods 122-123. In this example, each of the service objects 124-125 includes a label selector for selecting the pod that the service object is exposing to the network. The label selector can be configured with multiple labels to allow the label selector to select from multiple pods. For example, the label selector of a service object may include three labels for the pods that can be selected. The label selector can then select one of the three pods to handle incoming network traffic, which may be useful for load balancing across the pods. In this case, each of the service objects 124-125 corresponds to a single pod from pods 122-123, rather than multiple pods, so the label selectors for service objects 124-125 are given only one pod label for selecting a pod. For example, service manager 101 configures the label selector for service object 104 to select label POD-102 and the label selector for service object 105 to select label POD-103. Service manager 101 further associates each of the service objects 124-125 with a unique application identifier of the pod that has the label configured to be selected by the label selector.For example, service object 104 is associated with unique application identifier 1 because pod 102 is assigned unique application identifier 1, and service object 105 is associated with unique application identifier 2 because pod 103 is associated with unique application identifier 2. The service manager 101 can track associations internally (e.g., in a data structure) or configure service objects 124-125 to indicate associations (e.g., tag service objects 124-125 with their respective unique application identifiers).

[0013] After configuring service objects 124-125 based on the pod information, the service manager 101 receives the updated pod information (203). In this example, the updated pod information indicates that pod 103, which was previously standby, is now active and associated with the unique application identifier 1 that was previously assigned to pod 102. Pod 103 is now active because pod 102 failed, and application 111 activated pod 103 to replace pod 102 in the active pod 122. When activating pod 103, application 111 assigns the unique application identifier of the failed pod 102 to the newly activated pod 103, thereby enabling application 111 on pod 103 to take over the tasks of application 111 on pod 102. The remaining instances of application 111 on the pods can negotiate amongst themselves to determine which of the standby pods 123 should be activated in response to a determination that pod 102 has failed, or a control instance of application 111 can determine which of the standby pods 123 should be activated. Similar to the pod information described above, updated pod information can be received directly from pod 103 or from the application controller.

[0014] In response to being notified in the updated pod information that pod 103 has a unique application identifier 1 and is currently active, the service manager 101 reconfigures service object 104 to correspond to pod 103 instead of pod 102 (204). To reconfigure service object 104, the service manager 101 can first identify the service object associated with the unique application identifier 1 from within the active service 124, which in this case is service object 104. The service manager 101 can then change the label selector of service object 104 to select the label for pod 103, i.e., POD-103. After reconfiguration, since service object 104 is still associated with the pod that has the unique application identifier 1, network traffic that service object 104 would have directed to pod 102 is instead directed to pod 103.

[0015] The service object 105 associated with pod 103 when pod 103 was in standby mode may not be reconfigured by the service manager 101, at least not immediately. Since service object 105 is one of the standby services 125, it is not a problem if service object 105 still has a label selector configured to select pod 103, because standby services 125 do not actually handle traffic due to their standby role. When pod 102 recovers from its failure, the service manager 101 can receive updated pod information notifying the service manager 101 that pod 102 has recovered. For example, the updated pod information may indicate that a pod with label POD-102 is in standby mode and has a unique application identifier 2. The service manager 101 can then identify service object 105 as one of the standby services 125 associated with the unique application identifier 2 and configure the label selector of service object 105 to select pod label POD-103.

[0016] Figure 3A shows an operational scenario 300 for handling failover of pods running an application in high availability mode. In operational scenario 300, application 311 runs in pods 321-325 and supports high availability. Application 311 is managed by application controller 312, which runs in pod 326. Application controller 312 coordinates the number of pods running application 311, which of those pods are active versus standby, and handles updating pod information to service manager 301. In other examples, instead of being a remote process, one instance of application 311 can be designated as the master and perform similar functions to those described for application controller 312. Similar to application controller 312, service manager 301 runs in pod 327 and manages service objects 331-325 for each of pods 321-325. Although not shown, pods 321-327 and service objects 331-335 are running on a container orchestration platform such as container orchestration platform 106, and on a computing system such as server 107.

[0017] During the operation scenario 300, the application controller 312 determines that application 311 will run with three active application pods and two standby application pods. The number of active pods versus standby pods can be defined by the user, coded to the application controller 312, requested by application 311, or indicated from some other source. In some examples, the number of active pods for application 311 can depend on the demand for application 311, and the number of standby pods can be determined as a ratio to the active pods. In this example, the ratio can indicate that the number of standby pods should be 40% of the number of active pods, which leads to a 3:2 ratio of active pods to standby pods. Thus, the application controller 312 instructs the container orchestration platform to create pods 321-325, which contain application 311, and in step 1, assigns a unique application identifier and role to each of the pods 321-325. Similar to the example above, the unique application identifier for each of the pods 321-325 is a single-digit number, but can be any data that is unique among the others of pods 321-325. In this example, application controller 312 designates pods 321-323 as active and pods 324-325 as standby. Pods 321-325 are also shown to have pod labels associated with their reference numbers in the operational scenario 300, but other unique identifiers can be used for the labels. Pod labels can be assigned automatically by the container orchestration platform, assigned by application controller 312, or assigned by some other source.

[0018] In step 2, the application controller 312 also sends a unique application identifier to the service manager 301 along with their associated pod labels and roles. Based on the information received from the application controller 312, the service manager 301 knows which pods identified by their labels are active / standby and their respective unique application identifiers. In response to the information, in step 3, the service manager 301 labels the service objects 331-335 and configures them to correspond to each of the pods 321-325. The labels for the service objects 331-335 can be arbitrary data, but in this example, the service manager 301 uses labels to indicate information about the pod to which each of the service objects 331-335 is associated. For example, the label selector for service object 331 is configured to select the label POD-321 to select pod 321. Since pod 321 is active and has a unique application identifier 1, the service manager 301 labels service object 331 Active-svc-1. Similarly, service object 334 is labeled Standby-svs-4 because the label selector for service object 334 is configured to select the label POD-324 for pod 324, which is the standby pod. The remaining service objects 331-335 are also similarly labeled and configured based on their corresponding pods 321-325. When processing network traffic, each of the configured service objects 331-335 selects one of the single corresponding pods 321-325 in step 4.

[0019] Figure 3B shows additional steps in operational scenario 300 for handling failover of a pod running an application in high availability mode. In this example, pod 322 fails. In response to determining that pod 322 has failed, in step 5, the application controller 312 reassigns the unique application identifier 2 that was assigned to pod 322 to pod 324 and changes the role of pod 324 to active. The application controller 312 may have determined that pod 322 has failed based on the fact that pod 322 has stopped responding to messages from the application controller 312, the application controller 312 has stopped receiving heartbeat messages from pod 322, or some other indication that pod 322 has failed. Since simply changing pod 324 to active would not allow pod 324 to take over pod 322, the application controller 312 sends the updated information to the service manager 301 in step 6. The updated information indicates that the pod with label POD-324 (i.e., pod 324) is now associated with the unique application identifier 2. The updated information may explicitly indicate that pod 322 is no longer associated with the unique application identifier 2 and / or has failed, or the service manager 301 may infer from the updated information that pod 322 is no longer active and has the unique application identifier 2.

[0020] In response to receiving the updated information, the service manager 301 identifies service object 332 as the service object corresponding to the unique application identifier 2, and in step 7, updates the label selector of service object 332 to select label POD-324 instead of POD-322, which was previously the pod label associated with the unique application identifier 2. The label of service object 332 itself does not need to be changed, as it is still associated with the active pod that has the unique application identifier 2. By updating the label selector in service object 332, in step 8, service object 332 will select pod 324 to handle network traffic instead of selecting pod 322, which it would have selected previously.

[0021] Figure 3C shows further steps of operational scenario 300 for handling failover of a pod running an application in high availability mode. Pod 322 recovers from the aforementioned failure (e.g., is regenerated by the container orchestration platform). When application controller 312 recognizes that pod 322 has recovered, application controller 312, in step 9, reassigns the unique application identifier 4 to pod 322 and puts pod 322 into standby. The unique application identifier 4 was the unique application identifier that was assigned to pod 324 before pod 324 was activated. Application controller 312 assigns the unique application identifier 4 rather than a different unique application identifier because the service object (i.e., service object 334) was already associated with the unique application identifier 4 when pod 324 was assigned the unique application identifier 4.

[0022] In step 10, application controller 312 sends the updated information to service manager 301. The updated information indicates that the pod with label POD-322 (i.e., pod 322) is currently associated with unique application identifier 4. In response to receiving the updated information, service manager 301 identifies service object 334 as the service object corresponding to unique application identifier 4, and in step 11, updates the label selector of service object 334 to select label POD-322 instead of POD-324, which was the pod label previously associated with unique application identifier 4. Since the label of service object 334 itself is still associated with the standby pod having unique application identifier 4, it does not need to be changed. By updating the label selector in service object 334, in step 12, service object 334 selects pod 322 to process network traffic instead of selecting pod 324, which would have been selected previously. However, since pod 324 is a standby pod, the likelihood of traffic being exchanged between pod 324 and service object 334 is low.

[0023] FIG. 4 shows a computing system 400 that represents any system or collection of systems capable of implementing the various processes, systems, programs, services, and scenarios disclosed herein. Examples of computing system 400 include, but are not limited to, desktop computers, laptop computers, server computers, routers, web servers, cloud computing platforms, and data center equipment, as well as any other type of physical or virtual server machine, physical or virtual router, container, and any variations or combinations thereof, in addition to distributed computing systems. It should be understood that virtualized components are running on physical hardware such as the physical hardware of computing system 400.

[0024] Computing system 400 may be implemented as a single device, system, or apparatus, or may be implemented in a distributed manner as multiple devices, systems, or apparatuses. Computing system 400 may include, without limitation, a processing system 415, a storage system 405, software 425, a communication interface system 410, and a user interface system 420. The processing system 415 may be operably coupled to the storage system 405, the communication interface system 410, and the user interface system 420.

[0025] The processing system 415 may read and execute software 425 from the storage system 405. The software 425 may include and implement a process 430, which may represent any of the operations for handling the failover of pods that execute an application in high availability mode (e.g., operation 200). Thus, the computing system 400 may be a service manager 101, or may be a host system for a virtualized instance of the service manager 101 (e.g., service manager 301). The computing system 400 may also represent a physical server 107 (including combinations thereof). When executed by the processing system 415, the software 425 may instruct the processing system 415 to operate as described herein for at least the various processes, operation scenarios, and sequences described in the foregoing embodiments. The computing system 400 may optionally include additional devices, features, or functions not described for the sake of brevity.

[0026] In some embodiments, the processing system 415 may include a microprocessor and other circuitry that retrieves and executes software 425 from the storage system 405. The processing system 415 may be implemented within a single processing device, or it may be distributed across multiple processing devices or subsystems that cooperate in executing program instructions. Examples of the processing system 415 may include a general-purpose central processing unit, a graphical processing unit, an application-specific processor, and a logic device, as well as any other type of processing device, combinations thereof, or variations thereof.

[0027] The storage system 405 may include any memory device or computer-readable storage medium capable of storing software 425, which is readable by the processing system 415. The storage system 405 may include volatile and non-volatile, removable and non-removable media implemented in any way or technique for storing information such as computer-readable instructions, data structures, program modules, or other data. Examples of storage media include random-access memory, read-only memory, magnetic disks, optical disks, optical media, flash memory, virtual and non-virtual memory, magnetic cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, or any other suitable storage media. The computer-readable storage medium is not a transient form of signal transmission (often referred to as the "signal itself"), such as a propagating electrical or electromagnetic signal or carrier wave.

[0028] In addition to a computer-readable storage medium, in some embodiments, the storage system 405 may also include a computer-readable communication medium through which at least a portion of the software 425 can be transmitted internally or externally. The storage system 405 may be implemented as a single storage device, or it may be implemented in multiple storage devices or subsystems located in the same location or distributed relative to one another. The storage system 405 may include additional elements, such as a controller, that can communicate with the processing system 415 or possibly other systems.

[0029] The software 425 (including, in particular, the processes 430) may be implemented by program instructions, which, when executed by the processing system 415, can instruct the processing system 415 to operate as described with respect to the various operable scenarios, sequences, and processes illustrated herein. For example, the software 425 may include program instructions for receiving pod information about pods orchestrated by the container orchestration platform, configuring service objects provided by the container orchestration platform to correspond to each of the pods based on the information, receiving updated pod information indicating that a standby pod is currently active and has the application identifier of the failed pod, and reconfiguring the service objects associated with the application identifier to correspond to the newly activated pod in place of the failed pod.

[0030] More specifically, the program instructions may include various components or modules that cooperate or otherwise interact to perform the various processes and operable scenarios described herein. These various components or modules may be embodied in instructions that are compiled or interpreted, or in any other variation or combination of instructions. These various components or modules may be executed synchronously or asynchronously, sequentially or in parallel, in a single-threaded or multi-threaded environment, or according to any other suitable execution paradigm, variation, or combination thereof. Software 425 may include additional processes, programs, or components, such as operating system software, virtualization software, or other application software. Software 425 may also include firmware or any other form of machine-readable processing instructions executable by the processing system 415.

[0031] Generally, when loaded into and executed by the processing system 415, the software 425 may transform an entire appropriate apparatus, system, or device (of which the computing system 400 is a typical example) from a general-purpose computing system to a dedicated computing system customized to function, for example, as a connectivity balancer as described herein. In fact, the physical structure of the storage system 405 may be transformed by encoding the software 425 on the storage system 405. The specific transformation of the physical structure may depend on various factors in the various embodiments of this description. Examples of such factors, but not limited to, include the technology used to implement the storage medium of the storage system 405, whether the computer storage medium is characterized as primary or secondary storage, and other factors.

[0032] For example, if a computer-readable storage medium is implemented as semiconductor-based memory, the software 425 may transform the physical state of the semiconductor memory by, for example, transforming the state of transistors, capacitors, or other individual circuit elements that make up the semiconductor memory when program instructions are encoded within the semiconductor memory. Similar transformations may occur with respect to magnetic or optical media. Other transformations of physical media are possible without departing from the scope of this description, and the examples described above are provided solely to facilitate this description.

[0033] The communication interface system 410 may include communication connections and devices that enable communication with other computing systems (not shown) via a communication network (not shown). Examples of communication connections and devices that enable inter-system communication together may include network interface cards, antennas, power amplifiers, radio-frequency (RF) circuits, transceivers, and other communication circuits. The communication connections and devices may communicate via a communication medium such as metal, glass, air, or any other suitable communication medium to exchange communications with other computing systems or networks of systems.

[0034] Communication between computing system 400 and other computing systems (not shown) may occur via one or more communication networks, according to various communication protocols, combinations of protocols, or variations thereof. Examples include intranets, internets, the Internet, local area networks, wide area networks, wireless networks, wired networks, virtual networks, software-defined networks, data center buses and backplanes, or any other type of network, combination of networks, or variations thereof.

[0035] As will be understood by those skilled in the art, aspects of the present invention may be embodied as systems, methods, or computer program products, and other configurable systems. Accordingly, aspects of the present invention may take the form of entirely hardware embodiments, entirely software embodiments (including firmware, resident software, microcode, etc.), or embodiments combining software and hardware embodiments, all of which may be commonly referred to herein as “circuits,” “modules,” or “systems.” Furthermore, aspects of the present invention may take the form of computer program products embodied in one or more memory devices or computer-readable media in which computer-readable program code is embodied.

[0036] Unless the context specifically requires otherwise, throughout this description and the claims, words such as “equipped with,” “equipped with,” etc., should be interpreted in an inclusive sense, as opposed to an exclusive or exhaustive sense, i.e., “includes but not limited to.” When used herein, the terms “connected,” “joined,” or any variation thereof, mean any direct or indirect connection or combination between two or more elements, which may be physical, logical, or a combination thereof. Furthermore, when used herein, the words “as herein,” “above,” “below,” and words of similar meaning, refer to the application as a whole and not to any particular part thereof. Where the context allows, words in the above detailed description that use singular or plural may also include plural or singular. The word “or” refers to a list of two or more items, encompassing all interpretations of this word, including any of the items in the list, all of the items in the list, and any combination of the items in the list.

[0037] The phrases "in some embodiments," "according to some embodiments," "in the shown embodiments," and "in other embodiments" usually mean that the specific features, structures, or characteristics that follow these phrases are included in at least one embodiment of the Art, and may be included in two or more embodiments. In addition, such phrases do not necessarily refer to the same embodiment, nor to a different embodiment.

[0038] The above detailed description of examples of the Art is not intended to be exhaustive, nor to limit the Art to the exact forms disclosed above. Specific examples of the Art are described above for illustrative purposes, but various equivalent modifications are possible within the scope of the Art, as those skilled in the art will recognize. For example, while processes or blocks are presented in a particular order, alternative embodiments may employ routines comprising steps or systems comprising blocks in a different order, and some processes or blocks may be deleted, moved, added, split, combined, and / or modified to provide alternative means or partial combinations. Each of these processes or blocks may be implemented in a wide variety of ways. Also, while processes or blocks may be shown as being executed in series, these processes or blocks may instead be executed or implemented in parallel, or at different times. Furthermore, any specific number mentioned herein is merely illustrative, and alternative embodiments may employ different values ​​or ranges.

[0039] The teachings of the Art provided herein may be applied to systems other than those described herein. The elements and actions of the various examples described above can be combined to provide further embodiments of the Art. Some alternative embodiments of the Art may include additional elements to those embodiments described above, or they may include fewer elements.

[0040] These and other modifications may be made to the Art in light of the detailed description above. While the above description describes an example of the Art and the intended best mode, the Art can be practiced in many ways, no matter how detailed the above text may seem. System details may vary considerably in particular embodiments, but are still encompassed within the Art disclosed herein. As stated above, any particular term used to describe a particular feature or aspect of the Art should not be taken as meaning that the term is redefined herein to be limited to any particular characteristic, feature, or aspect of the Art to which the term is associated. In general, the terms used in the following claims should not be interpreted as limiting the Art to the specific examples disclosed herein unless such terms are explicitly defined in the detailed description section above. Thus, the actual scope of the Art includes not only the disclosed examples but also all equivalent methods of practicing or implementing the Art in accordance with the claims.

[0041] To reduce the number of claims, certain aspects of the Art are presented below in the form of certain claims, but the applicant intends to present various aspects of the Art in the form of any number of claims. For example, one aspect of the Art is given as a claim for a computer-readable medium, but other aspects may be embodied in other forms, such as being embodied as a claim for a computer-readable medium or in a means-plus-function claim. All claims intended to be treated pursuant to 35 U.S. SC § 112(f) begin with the words “means for,” but the use of the term “for” in all other contexts is not intended to cause treatment pursuant to 35 U.S. SC § 112(f). Accordingly, the applicant reserves the right to pursue additional claim forms in this application or in a continuation application, or to pursue such additional claims after the filing of this application.

[0042] The aspects of the subject matter described herein are defined in the following numbered sections. 1. A method for a service manager to handle failover of pods running applications in high availability mode, This includes receiving pod information about the pods. The pod information includes a unique application identifier generated for the pod by the application, and instructions on which of the pods are active and which are standby, and the pods are orchestrated by a container orchestration platform.

[0043] The method is, This further includes configuring the service objects provided by the container orchestration platform to correspond to each pod based on a unique application identifier. The service objects expose the corresponding pods to the network.

[0044] The method is, The first pod, which was previously in standby mode, receives updated pod information indicating that it is now active, and that it has the first application identifier of the unique application identifiers previously assigned to the second pod, which was one of the failed pods. Reconfiguring the service object among the service objects associated with the first application identifier so that it corresponds to the first pod instead of the second pod, It also includes. 2. The method described in paragraph 1, The process further includes receiving a second updated pod information, which indicates that the second pod is currently in standby mode and has a second application identifier from among the previous application identifiers previously assigned to the first pod.

[0045] The method is, This further includes reconfiguring the second service object among the service objects associated with the second application identifier to correspond to the second pod instead of the first pod. 3. The pod transmits pod information in the manner described in paragraph 1. 4. The controller pod for the application manages the application in the manner described in paragraph 1. The controller pod transmits pod information after receiving it from the pod. 5. The method described in Section 4, wherein the controller pod generates a unique application identifier on behalf of the application. 6. The method described in paragraph 1, wherein the pod information includes the unique pod name indicated in the label assigned to the pod. Reconfiguring a service object is This includes configuring the service object to select a label from among the labels assigned to the first pod. 7. The method described in paragraph 1, which constitutes a service object, This includes labeling service objects with labels that include the application identifier of each pod. 8. The method described in paragraph 1, wherein the pod information includes the service name from the application and constitutes a service object, This includes naming service objects using names generated based on pod information. Each name includes the service name, the application identifier of the corresponding pod, and whether the corresponding pod is active or standby. 9. The method described in paragraph 1, wherein the service manager is implemented in a separate pod of the container orchestration platform. 10. A device for handling failover of pods running an application in high availability mode, wherein the device is: One or more computer-readable storage media, A processing system operably coupled to a tera computer-readable storage medium, It comprises program instructions stored in one or more computer-readable storage media. When these program instructions are read and executed by a processing system, the device, Instructions are given to receive pod information about the pods, which includes a unique application identifier generated for the pods by the application, and instructions on which of the pods are active and which are standby, and the pods are orchestrated by a container orchestration platform. Further instructions are given to configure the service objects provided by the container orchestration platform to correspond to each pod based on a unique application identifier, and the service objects expose the corresponding pods to the network. The first pod, which was previously in standby mode, has received updated pod information indicating that it is now active, and has the first application identifier of the unique application identifiers previously assigned to the second pod, which was one of the failed pods. Reconfigure the service objects associated with the first application identifier so that they correspond to the first pod instead of the second pod. Give further instructions. 11. The apparatus described in paragraph 10, wherein the program instructions are used in the processing system. The system is instructed to receive a second updated pod information. The second updated pod information indicates that the second pod is currently on standby and has a second application identifier from the previous application identifiers previously assigned to the first pod.

[0046] Program instructions are Further instruct the system to reconfigure the second service object among the service objects associated with the second application identifier so that it corresponds to the second pod instead of the first pod. 12. The device described in paragraph 10, wherein the pod transmits pod information. 13. The device described in Section 10, wherein a controller pod for the application manages the application. The controller pod transmits pod information after receiving it from the pod. 14. The device described in paragraph 13, wherein the controller pod generates a unique application identifier on behalf of the application. 15. The device described in paragraph 10, wherein the pod information includes a unique pod name as indicated on the label assigned to the pod. To reconfigure the service object, the program instructions are sent to the processing system. This instructs the service object to configure itself to select a label from among the labels assigned to the first pod. 16. In the device described in paragraph 10, program instructions for constituting a service object are provided to the processing system. This instructs the system to label service objects using labels that include the application identifier of each pod. 17. The device described in paragraph 10, where the pod information includes the service name from the application. To reconstruct the service object, the program instructions are sent to the processing system. This instructs the system to name the service object using a name generated based on the pod information. Each name includes the service name, the application identifier of the corresponding pod, and whether the corresponding pod is active or standby. 18. The apparatus described in paragraph 10, wherein program instructions are executed via another pod of a container orchestration platform running on the apparatus. 19. One or more computer-readable storage media containing program instructions for handling failover of pods running an application in high availability mode, wherein when the program instructions are read and executed by the processing system, the processing system will: Instructions are given to receive pod information about the pods, which includes a unique application identifier generated for the pods by the application, and instructions on which of the pods are active and which are standby, and the pods are orchestrated by a container orchestration platform. Further instructions are given to configure the service objects provided by the container orchestration platform to correspond to each pod based on a unique application identifier, and the service objects expose the corresponding pods to the network. The first pod, which was previously in standby mode, has received updated pod information indicating that it is now active, and has the first application identifier of the unique application identifiers previously assigned to the second pod, which was one of the failed pods. Reconfigure the service objects associated with the first application identifier so that they correspond to the first pod instead of the second pod. Give further instructions. 20. One or more computer-readable storage media as described in paragraph 19, wherein program instructions are transmitted to a processing system. The system is instructed to receive a second updated pod information. The second updated pod information indicates that the second pod is currently on standby and has a second application identifier from the previous application identifiers previously assigned to the first pod.

[0047] Program instructions are Further instruct the system to reconfigure the second service object among the service objects associated with the second application identifier so that it corresponds to the second pod instead of the first pod.

Claims

1. A method for a service manager to handle failover of pods running an application in high availability mode, the method being: This includes receiving pod information relating to the pod, the pod information including a unique application identifier generated for the pod by the application, and an indication of which of the pods is active and which is standby, and the pods are orchestrated by a container orchestration platform. The aforementioned method, The further includes configuring the service objects provided by the container orchestration platform to correspond to each of the pods based on the unique application identifier, the service objects to expose the corresponding pods to the network, The aforementioned method, The first pod, which was previously in standby mode, receives updated pod information indicating that it is now active, and has the first application identifier among the unique application identifiers previously assigned to the second pod, which experienced a failure. Reconfiguring the service object among the service objects associated with the first application identifier so that it corresponds to the first pod instead of the second pod, Methods that further include this.

2. The aforementioned method, The process includes receiving a second updated pod information, the second updated pod information indicating that the second pod is currently in standby, and has a second application identifier from the previous application identifiers previously assigned to the first pod. The aforementioned method, The method according to claim 1, further comprising reconfiguring the second service object among the service objects associated with the second application identifier to correspond to the second pod instead of the first pod.

3. The method according to claim 1, wherein the pod transmits the pod information.

4. The method according to claim 1, wherein a controller pod for the application manages the application, and the controller pod transmits the pod information after receiving the pod information from the pod.

5. The method according to claim 4, wherein the controller pod generates the unique application identifier on behalf of the application.

6. The pod information includes the unique pod name indicated in the label assigned to the pod, and the service object is reconstructed as follows: The method according to claim 1, comprising configuring the service object to select a label from among the labels assigned to the first pod.

7. Configuring the aforementioned service object means The method according to claim 1, comprising labeling the service object with a label that includes the application identifier of each of the pods.

8. The pod information includes the service name from the application, and the service object is composed of the following: The method according to claim 1, comprising naming the service object using a name generated based on the pod information, each of which name indicates the service name, the application identifier of the corresponding pod, and whether the corresponding pod is active or standby.

9. The method according to claim 1, wherein the service manager is implemented in another pod of the container orchestration platform.

10. A device for handling failover of pods running applications in high availability mode, wherein the device is: One or more computer-readable storage media, A processing system operably coupled to the aforementioned one or more computer-readable storage media, An apparatus comprising one or more computer-readable storage media containing program instructions, wherein, when the program instructions are read and executed by the processing system, the apparatus instructs the apparatus to perform the method according to any one of the preceding claims.

11. One or more computer-readable storage media storing program instructions for handling failover of pods running an application in high availability mode, wherein, when read and executed by a processing system, the program instructions instruct the processing system to perform the method according to any one of claims 1 to 9.

12. A computer program product comprising a program that, when executed, performs the method described in any one of claims 1 to 9.

Images