Add possibility to define custom readinessProbe

[mschmidt291]

• Chart version not bumped (the versions are all bumped and released at the same time)
• README.md updated with any new values or changes

[elasticmachine]

Since this is a community submitted pull request, a Jenkins build has not been kicked off automatically. Can an Elastic organization member please verify the contents of this patch and then kick off a build manually?

[fatmcgav]

@mschmidt291 are you able to elaborate on why you need to define a completely custom readiness probe?

The reason I ask is that the existing readiness probe has been written to handle multiple scenarios gracefully, such as initial cluster bootstrapping, rolling restarts, graceful cluster upgrades etc.
By defining a custom readiness probe, a lot of that functionality could end up being broken...

[mschmidt291]

@fatmcgav Oh damn, I actually closed the first PR because of the CLA which was missing. I forgot to write the link down here.

There is a bug in Kuberentes with exec readinessProbes, which results in a very high CPU usage. You can read more about it here: kubernetes/kubernetes#82440 We're currently in the process of moving every deployment which we use away from exec to a tcpProbe or httpProbe. This fixes the high CPU usage.

I also wrote a service which will run as a extraContainer, which handles the readinesscheck. (it's currently private, but I would be happy to release it publically) It just fetches the health api and returns either 200 status code if the cluster is healthy, or 503 if the desired status code is not yet there.

[fatmcgav]

@mschmidt291 cheers for the link... That's a pretty painful looking bug...

I'll raise this PR internally to see how we want to handle it.
On the surface it's a very trivial change; however as I eluded to above there's a lot of logic built into the existing readinessProbe to support the nuances of running an Elasticsearch cluster on k8s...

[Crazybus]

jenkins test this please

[Crazybus]

LGTM!

[jmlrt]

⛴