Release Notes / Version 10.2107
Table Of Contents
When the Content Server is switched to runlevel MAINTENANCE either during startup or manually, the
health/runlevel
endpoint signals the server is UP. This makes it impossible to use the indicator for a readiness probe in Kubernetes, because the pod will be added to the services endpoint too early and UAPI clients that listen on a services availability would fail during the creation of the repository connection.
This change fixes the health state in the MAINTENANCE runlevel to down and includes the indicator in the
health/readiness
endpoint.
The content-server can therefore be in one of the following states:
runlevel=OFFLINE, Liveness State=BROKEN, Readiness State=REFUSING_TRAFFIC
runlevel=MAINTENANCE, Liveness State=CORRECT, Readiness State=REFUSING_TRAFFIC
runlevel=ADMINISTRATION, Liveness State=CORRECT, Readiness State=REFUSING_TRAFFIC
runlevel=ONLINE, Liveness State=CORRECT, Readiness State=ACCEPTING_TRAFFIC
If your health check logic depended on MAINTENANCE level being a 200 HTTP result, disable the runlevel endpoint by setting
management.health.runlevel.enabled=false management.endpoint.health.group.readiness.include=readinessState
Please be reminded, that using the health actuator to automatically trigger a redeployment of a pod / container is not advised and can be dangerous due to health indicator that monitor connections to remote systems. This can cause chain reactions taking multiple services down.
Instead use the
host:8081/actuator/health/liveness
endpoint instead.
(CMS-21355)