loading table of contents...

Operations Basics / Version 2301

Table Of Contents Health Endpoints in the Context of a Kubernetes Deployment

In a Kubernetes deployment, you have three different probing mechanism to determine the state of your pod.

  • a startupProbe to delay adding the pod to the loadbalancing until it is ready for business. This probe is especially relevant if an application takes a long initialization time aside from being ready.

  • a readinessProbe to signal the loadbalancing that the application pod is ready to accept traffic.

  • a livenessProbe to signal that the application pod is alive and should not be removed for rescheduling.

In order to use these probes, there are dedicated endpoints below the health endpoint:

  • container:8081/actuator/health/readiness

  • container:8081/actuator/health/liveness

These endpoints are activated by the following Spring Boot properties, which are enabled by default in the Blueprint workspace:

In UAPI clients, the uapiConnectionReadiness health indicator can be added to the readiness health endpoint to signal Kubernetes an upcoming runlevel change of the content-server to remove the pod from loadbalancing and deny further traffic. The runlevel switch can then be triggered using the Section 4.10.7, “Content Server Runlevel Endpoint” with a grace period in the content-server pod during a preStop lifecycle hook followed by a sleep timeout equal to the grace period. This way, the grace period and the sleep timeout are defining the connection draining period of the client.

To include the uapiConnectionReadiness health endpoint in the readiness endpoint, you need to set the following Spring Boot properties:,uapiConnectionReadiness

Search Results

Table Of Contents

Your Internet Explorer is no longer supported.

Please use Mozilla Firefox, Google Chrome, or Microsoft Edge.