Fault detection and correction of API endpoints in container orchestration platforms

A method, system and computer program product for improving the availability of API endpoints in container orchestration platforms. A service request handler module of a microservice application programming interface (API) fault manager (MAFM) invokes a microservice API fault management service in response to detecting an unresponsive microservice managed by a container orchestration platform. An API inspection module of the MAFM identifies an unresponsive API of the unresponsive microservice. A remedial action module of the MAFM determines a remedial action to correct an unresponsive state of the unresponsive API. A container platform interface module of the MAFM communicates the remedial action to the container orchestration platform.

TECHNICAL FIELD

The present invention relates generally to a method, system, and computer program product for troubleshooting an unresponsive microservice. More particularly, the present invention relates to a method, system, and computer program product for improving the availability of API endpoints in container orchestration platforms.

BACKGROUND

A microservice architecture (MSA) is a variant of a service-oriented architecture (SOA) structural style and is one that arranges an application as a collection of loosely coupled services, commonly referred to as microservices due to their narrow scope in executing smaller tasks. It is common for MSA's to be adopted for cloud-native applications, and applications using lightweight container deployment. A consequence of following an MSA approach is that the individual microservices are independently deployable and can be individually scaled. In a monolithic approach, an application supporting a plurality of functions would have to be scaled in its entirety even if only one of these functions had a resource constraint. With microservices, only the microservice supporting the function with resource constraints would be scaled out.

Because of the large number of services as compared to monolithic application implementations, decentralized continuous delivery and DevOps with holistic service monitoring are used to effectively develop, maintain, and operate such applications. In this regard, container orchestration platforms have been developed for managing complex applications comprised of multiple microservices working together through application programming interfaces (APIs) that are not dependent on a specific code language. While containers and microservices exist independently and serve different purposes, they are often used together. Containers are an enabling technology for microservices, which is why microservices are often delivered in one or more containers. Since containers are isolated environments, containers can be used to deploy microservices quickly, regardless of code language used to create each microservice. When implementing and managing containers and microservices, DevOps teams must actively work to prevent problematic code, such as errant application code and unresponsive APIs.

SUMMARY

The illustrative embodiments provide a method, system, and computer program product. An embodiment includes a method that invokes, using a service request handler module of a microservice application programming interface (API) fault manager (MAFM) a microservice API fault management service, responsive to detecting an unresponsive microservice managed by a container orchestration platform. An embodiment identifies an unresponsive API of the unresponsive microservice using an API inspection module of the MAFM. An embodiment determines, using a remedial action module of the MAFM, a remedial action to correct an unresponsive state of the unresponsive API. An embodiment communicates, using a container platform interface module of the MAFM, the remedial action to the container orchestration platform.

DETAILED DESCRIPTION

The illustrative embodiments recognize that there is a need in a microservice operating environment that is managed by container orchestration platforms to ensure the validity of application programming interfaces (APIs), which are responsible for connecting the data and presentation layers of an application. Because the API layer directly touches both data and presentation layers, it is a key area for continuous testing for quality assurance (QA) and development teams. While there are many aspects of API testing, it generally consists of making requests to a single API endpoint or sometimes multiple API endpoints and validate the response, whether for performance, security, and/or functional correctness.

The illustrative embodiments further recognize that container orchestration platforms, such as KUBERNETES and DOCKER, when implemented to manage complex application environments having a large number of microservices, generally only provide capabilities to monitor and scale pods (i.e., individual microservices) in the event that there is a failure within a container associated with a plurality of microservices. Current container orchestration platform technologies are not designed to validate and take any remedial action(s) based on problems related to the actual application logic and the APIs running within the failing container. As a result, current container orchestration platforms may simply remedy a failing container by replacing it with a newly spawned container, which is identical in the number and organization of microservices and their supporting APIs when compared to the contents of the failed container. In this regard, current container orchestration platforms may mistakenly treat the newly spawned container as a healed container, when in reality one or more of the supporting APIs are unresponsive and the API's failed state remains undetectable to current container orchestration platforms. This causes the application as a whole to become unresponsive.

The illustrative embodiments also recognize that traditional third-party tools for monolithic applications, which provide fault tolerant and high availability solutions, are ineffective in microservice-based environments because of their inability to perform API validation and healing. Moreover, illustrative embodiments recognize that other solutions for monolithic environments, such as network devices and API gateways providing continuous API monitoring, carry the cost of performance degradation. Even other solutions designed for microservice-based environments fail to perform API validation and healing. Further, illustrative embodiments recognize that current microservice-based implementations employ application logics to perform checks on error codes and perform remedial actions based on the type of error code. However, even if a container orchestration platform terminates a pod and spawns another pod, such actions still do not guarantee individual API validation and healing.

The illustrative embodiments recognize that the presently available solutions do not address these needs or provide adequate solutions for these needs. The illustrative embodiments used to describe the invention generally address and solve the above-described problems and other problems related to improving the availability of API endpoints under the management of container orchestration platforms in a microservice operating environment.

An embodiment can be implemented as a software application. The application implementing an embodiment can be configured as a modification of an existing API gateway, a modification of an existing container orchestrator platform, as a separate application that operates in conjunction with an existing API gateway, as a separate application that operates in conjunction with an existing container orchestrator platform, a standalone application, or some combination thereof. Particularly, some illustrative embodiments provide a method that facilitates improving the availability of API endpoints under the management of container orchestration platforms in a microservice operating environment.

An embodiment configures a microservice application programming interface fault manager (MAFM) to identify an unresponsive API and to determine a remedial action. According to one embodiment, the MAFM operations are triggered by a fault that is detected and communicated to a service request handler of the MAFM by third party monitoring tools, such as PROMETHEUS and GRAFANA. In other embodiments, the MAFM operations are triggered by a fault that is detected and communicated to the MAFM by an API gateway that is unable to gain a response from a requested API. In this regard, the fault detected by the API gateway appears to originate at a requested API, but it is not conclusive to be the actual source of the fault, as the requested API may itself depend upon other nested APIs.

Another embodiment configures an API inspection module of the MAFM to identify the particular, unresponsive API(s). According to one embodiment, the API inspection module inspects APIs that that have been predetermined by the application developer to be critical to the operation of the microservice. The API inspection module then runs one or more sample input data requests through API gateway to test and pinpoint the immediate API source of the fault. According to another embodiment, after detecting the unresponsive API, a remedial action module of the MAFM is configured to determine an appropriate remedial action. According to one embodiment, the remedial action module inputs the identified, unresponsive API into a machine-learning model and determines a remedial action outcome. According to one embodiment, the remedial action includes terminating a container of the microservice associated with the unresponsive API and launching a new container of the microservice. According to another embodiment, the remedial action is rescaling a number of containers. Each container is associated with a microservice employing at least one API.

According to one embodiment, the remedial action decision is communicated to a container platform interface module of the MAFM. The container platform interface, in turn, interfaces with a container orchestration platform (e.g., KUBERNETES, DOCKER), which performs the actual remedial action by leveraging its native APIs. According to another embodiment, a monitoring scheduler module of the MAFM monitors a validity of the state of the API identified as unresponsive. The monitoring scheduler inputs test inputs to determine whether the once faulty API has been repaired by the remedial action. According to another embodiment, the monitoring process continues after a predetermined period of time. According to another embodiment, the monitoring process continues after a predetermined number of successful responses to API requests. If any fault continues to be detected, the negative outcome is reported and stored in an API monitoring database as a source for historical outcome information. The historical outcome information, whether indicating a successful or unsuccessful outcome, is fed to the machine learning algorithm of the remedial action module and assists in further refinements to the remedial action determination model.

In view of the foregoing embodiments, the availability of API endpoints in container orchestration platforms is improved within a microservices environment. The examples described herein of improving the availability of API endpoints in a microservices environment that employs a container orchestration platform are not meant to be limiting in any way. From this disclosure, those of ordinary skill in the art will be able to conceive many other ways of implementing the above enhancement. and the same are contemplated within the scope of the illustrative embodiments.

The manner of repairing faulty APIs within a microservices environment that employs a container orchestration platform, as described herein, is unavailable in the presently available methods in the technological field of endeavor pertaining to API monitoring and fault remediation in microservice environments. A method of an embodiment described herein, when implemented to execute on a device or data processing system, comprises substantial advancement of the functionality of that device or data processing system by providing a centralized, MAFM that works in cooperation with an existing API gateway and container orchestration platforms.

The illustrative embodiments are described with respect to certain types of processing elements, API gateways, container orchestration platforms, third-party monitoring tools, API inspection tools, machine learning tools, debugger programs, computer memories, storage devices, containers, cloud computing systems, virtual computing systems, operating systems, computing systems, server systems, data processing systems, networked computing environments, devices, other environments, components, and applications only as examples. Any specific manifestations of these and other similar artifacts are not intended to be limiting to the invention. Any suitable manifestation of these and other similar artifacts can be selected within the scope of the illustrative embodiments.

Furthermore, the illustrative embodiments may be implemented with respect to any type of data instruction, data source, instruction source, access to a data source over a data network, or access to an instruction source over a data network. Any type of storage device may provide the data or instruction to an embodiment of the invention, either locally at a data processing system or over a data network, within the scope of the invention.

Only as an example, and without implying any limitation to such architecture,FIG. 1depicts certain components that are usable in an example implementation of an embodiment. For example, servers104and106, and clients110,112,114, are depicted as servers and clients only as example and not to imply a limitation to a client-server architecture. As another example, an embodiment is distributed across several data processing systems and a data network as shown, whereas another embodiment is implemented on a single data processing system within the scope of the illustrative embodiments. Data processing systems104,106,110,112, and114also represent example nodes in a cluster, partitions, and other configurations suitable for implementing an embodiment.

Application105on a server-side implements an embodiment described herein. According to one embodiment, the application105maintains a microservice application programming interface (API) fault manager (MAFM). In other embodiments described herein, application105is implemented on a client-side (e.g., in clients110-114, and device132). Further description of the MAFM is disclosed herein with reference toFIGS. 3-5below.

A database109, such as a database for tracking historical outcomes of a remedial action taken in response to an API fault, may be stored in storage108as shown or supplied by another source (not shown). Application105can also execute in any of data processing systems104,106,110,112, and114. Servers104and106, storage unit108, and clients110,112, and114, and device132may couple to network102using wired connections, wireless communication protocols, or other suitable data connectivity. Clients110,112, and114may be, for example, personal computers or network computers.

Instructions for the operating system, the object-oriented programming system, and applications or programs, such as client-side application113or server-side application105inFIG. 1, are located on storage devices, such as in the form of code226A on hard disk drive226, and may be loaded into at least one of one or more memories, such as main memory208, for execution by processing unit206. The processes of the illustrative embodiments may be performed by processing unit206using computer implemented instructions, which may be located in a memory, such as, for example, main memory208, read only memory224, or in one or more peripheral devices.

With reference toFIG. 3, an example is shown of a microservice API fault manager (MAFM)300configured to identify an unresponsive API and to determine a remedial action, according to one embodiment of the invention. As shown, the MAFM300includes a service request handler module302, a monitoring scheduler module304, an API inspection module306, a container platform interface module308, and a remedial action module310.

According to an embodiment, service request handler module302invokes, using a service request handler module of a microservice application programming interface (API) fault manager (MAFM), a microservice API fault management service. According to one embodiment, the MAFM300operations are triggered by a fault that is detected and communicated to service request handler302of the MAFM300by third party monitoring tools (not shown), such as PROMETHEUS and GRAFANA. In other embodiments, the MAFM300operations are triggered by a fault that is detected and communicated to the MAFM300by an API gateway (404, shown inFIG. 4) that is unable to gain a response from a requested API. In this regard, each API request is transmitted via the API gateway and each API that is requested is associated with a particular address. In this regard, it is important to appreciate that although a fault detected by the API gateway404appears to originate at a requested API, such a detection is not necessarily conclusive that the requested API is the underlying source of the fault. According to one example embodiment, the requested API itself depends upon other API(s), whose unresponsiveness causes the requested API to also be unresponsive.

According to an embodiment, API inspection module306inspects APIs that that have been predetermined by the application developer to be critical to the operation of the microservice. In one example embodiment, the API inspection module306runs one or more sample input data requests through API gateway404to test and pinpoint the immediate API source of the fault. According to one embodiment, the sample input data requests are drawn from historical API requests that are previously stored in a database for machine learning and monitoring.

According to an embodiment, remedial action module310of the MAFM is configured to determine an appropriate remedial action. According to one embodiment, the remedial action module310inputs the identified, unresponsive API into a machine-learning model and determines a remedial action outcome. The machine-learning model is updated based on historical data accumulated over the execution lifetime of the application.

According to an embodiment, container platform interface module308serves as an interface with container orchestration platform (410inFIG. 4). Container orchestration platform is responsible for executing the determined remedial action by leveraging its own native APIs.

According to an embodiment, a monitoring scheduler module304monitors a validity state of the API identified as unresponsive. The monitoring scheduler module304inputs test inputs to determine whether the once faulty API has indeed been repaired by the remedial action.

With reference toFIG. 4, a block diagram of a microservice operating environment400incorporating the MAFM300and its interoperability with container orchestration platform410and API gateway404is shown, according to one embodiment of the invention. In the example embodiment shown, three distinct application services: service A, B, C403a-crespectively send service requests through API gateway404. The API gateway404handles these requests for particular APIs that are needed to successfully execute each discrete microservice that work together to execute the complex application. For example, application service A402arequires microservice D406for successful execution. In particular, application service A402arequires access to API1408a, which for purposes of this example is successfully accessed. However, continuing with the above example embodiment, application service B402balso requires microservice D406and in particular requires access to API2408b. In this example embodiment, however, application service B402bis unable to access API2408band its microservice request times out. In this regard, API gateway404is responsible for handling the microservice request and is responsible for alerting MAFM300of the unresponsive event. In particular, the alert is communicated to service request handler302, which invokes the microservice API fault management service. Service request handler302initiates API inspection module306, which inspects APIs that that have been predetermined by the application developer to be critical to the operation of the unresponsive microservice D406. In the example embodiment, API inspection module306identifies that both API2408band API3408care unresponsive.

Once API inspection module306has identified the API responsible for the microservice's failure, API inspection module306initiates the services of remedial action module310. In the example embodiment shown, remedial action module310is configured to determine an appropriate remedial action to heal the unresponsive state of the unresponsive API2408band API3408c. According to one embodiment, the remedial action module inputs the identified, unresponsive APIs408b-cinto a machine-learning model and determines a remedial action outcome. According to the example embodiment, the remedial action includes terminating the container of the unresponsive microservice D406associated with the unresponsive APIs and launching a new container of the microservice, e.g., new microservice D412, having newly spawned APIs1-3414a-c.

The remedial action decision is communicated to container platform interface module308. Container platform interface module308interfaces with container orchestration platform410, which performs the remedial action by leveraging its native APIs. However, it should be appreciated that the remedial action may not resolve the unresponsiveness of the microservice. For this reason, monitoring scheduler module304monitors a validity of the state of the new APIs that were previously identified in microservice D406as unresponsive. Monitoring scheduler module304invokes test cases as inputs to determine whether the once faulty APIs2and3408b-chave been repaired by the remedial action of respawning microservice D412and creating APIs2and3414b-c. According to one embodiment, the monitoring process continues after a predetermined period of time. According to another embodiment, the monitoring process continues after a predetermined number of successful responses to API requests, indicative of a stable API. If any fault continues to be detected, the negative outcome is reported and stored in an API monitoring database416as a source for historical outcome information. The historical outcome information, whether indicating a successful or unsuccessful outcome, is supplied to the machine learning algorithm of the remedial action module310and assists in further refinements to the remedial action determination model. According to the example embodiment, having terminated the previous container of microservice D406and spawning a working microservice D412, application service C402cis shown to request microservice D412and in particular require access to API3414c. In this example embodiment, application service C402cis able to access API3414c, whose now terminated predecessor API3408cwould have not been accessible.

With reference toFIG. 5, this figure depicts a flowchart of an example process500for API fault detection and remediation in a microservice operating environment as described inFIG. 4. The process begins at block502and proceeds to block504, where an application service is initiated (e.g., application service A-C402a-c), which includes the requesting of one or more microservices (e.g., microservice D410) via API gateway404. From block504, the process continues to decision block506, where it is determined by API gateway404whether the requested microservice is responsive to the request. If the microservice is responsive, the process terminates at block524. However, if it is determined that the requested microservice is unresponsive, the process continues to block508, where API gateway404alerts service request handler302, which invokes the microservice API fault management service. From block508, the process continues to block510, where API inspection module306identifies the unresponsive API(s). After identifying the unresponsive API(s), the process continues to block512, where remedial action module310determines a remedial action to correct the unresponsive state of the API(s) (e.g., APIs2and3;408b-c). The process continues to block514, where container platform interface module308communicates the remedial action (e.g., spawn new microservice/container D412) to container orchestration platform410, which then executes the remedial action using its native APIs (block516). From block516, the process continues to decision block518, where monitoring scheduler module304verifies whether the remedial action has resulted in a valid state for the requested API (e.g., newly spawned APIs2and3;414b-c). If a valid state is determined, the process flows to block520, where monitoring scheduler module304reports the positive outcome to API monitoring database416. The API monitoring database416stores the historical outcome data and is in communication with remedial action module310, which accesses the outcome data to further refine the remedial action determination model. From block520, the process ends at block524. However, if an invalid state of the API is determined in decision block518, the process continues to block522, where monitoring scheduler module304reports the negative outcome to API monitoring database416. The API monitoring database416stores the historical outcome data and is in communication with remedial action module310, which accesses the outcome data to further refine the remedial action determination model. From block522, the process loops back to block510, where API inspection module306seeks again to identify the source of the unresponsiveness.