Re: [wildfly-dev] A look at Eclipse MicroProfile Healthcheck
> Regarding the probes, three states would be best, if you can
swing it, as
> OpenShift defines two probe types: liveness and readiness. Live is
> running, but unable to handle requests, while ready means it's running and
> able to handle requests. For example, while the server is initializing,
> it's alive, but not ready. Something to think about.
Three states (red/orange/green) was discussed when the healthcheck API was
proposed. It was rejected as it puts the burden on the consumer to determine
the overall healthiness.
Besides, Kubernetes expects a binary response from its probes. If the HTTP
status code is between 200 and 400, it is successful[1]. Anything else is
considered as a failure.
Kubernetes distinguishes between readiness and liveness. As defined, the
healthcheck API deals mainly with liveness.
But it could be possible provide some annotation to specify that some health
check procedures can determine when an application is ready.
For example, WildFly could be considered ready (i.e. Kubernetes will start to
route request to it) when:
* it status health check is “up and running”
* its deployment health check verifies that all its deployments are enabled.
I think this is a bit over simplistic, e.g. what happens if a deployment failed to start?
The pod would be marked as alive, but would never become ready. If the deployment failed,
presumably, the pod should be marked as dead. One use case we've seen is using JPA to
initialize a DB. If the DB isn't available, the deployment fails and the pod
continues to bounce until the DB is accessible. (Yes, this is not good practice, but it
illustrates the point, and some of our layered products actually do this, so...)
We could then provide a 2nd HTTP endpoint that Kubernetes could query to
check that the server is ready to serve requests.
jeff
[1]
https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#examples
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/