Release Notes / Version 11.2310
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)
