[wildfly-dev] A look at Eclipse MicroProfile Healthcheck

[Rob Cernich]

> > 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/
> 
>