Operations Basics / Version 2307
Table Of ContentsIn 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:
management.endpoint.health.probes.enabled=true management.health.livenessstate.enabled=true management.health.readinessstate.enabled=true
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:
management.health.uapiConnectionReadiness.enabled=true management.endpoint.health.group.readiness.include=readinessState,uapiConnectionReadiness