6 Application health

The combination of Kubernetes and the microservices architecture have caused a fundamental shift in how developers create applications. What used to be dozens of large monolithic applications are now becoming hundreds (or thousands) of smaller, more nimble microservice instances. The more application instances running, the larger the odds of an individual application instance failing. The increased odds of failure could be a significant challenge in production if application health is not a first-class concern in Kubernetes.

Let’s begin with a quick review of how monolithic applications running in application servers react to unhealthy applications.

6.1 The growing role of developers in application health

Many enterprise Java developers have experience with Java application servers, dating back to the late 1990s. During most of that time, developers created monolithic, three-tier applications with little awareness of exposing an application’s health. From a developer’s perspective, monitoring an application’s health was the responsibility of system administrators whose job descriptions are to keep applications up and running in production.

6.2 MicroProfile Health

6.2.1 Liveness vs. readiness

6.2.2 Determining liveness and readiness status

6.3 Getting started with MicroProfile Health

6.3.1 Account service MicroProfile Health liveness

6.3.2 Creating an Account service liveness health check

6.3.3 Account service MicroProfile Health readiness

6.3.4 Disabling vendor readiness health checks

6.3.5 Creating a readiness health check

6.3.6 Quarkus health groups

6.3.7 Displaying the Quarkus Health UI

6.4 Kubernetes liveness and readiness probes

6.4.1 Customizing health check properties

6.4.2 Deploying to Kubernetes

6.4.3 Testing the readiness health check in Kubernetes

Summary