-
Notifications
You must be signed in to change notification settings - Fork 1.9k
[elasticsearch] Readiness probe is failing again with 8.0.0-SNAPSHOT and default config #1443
Comments
elastic/elasticsearch#77231 was merged weeks ago, it's strange if we just started seeing these failures. From the logs I can see that elasticsearch fails to start because security is enabled and TLS is not configured for the transport layer.
We only made this change elastic/elasticsearch#79602 recently, but AFAIU the nodes deployed with the default example here start with a basic license by default so this change shouldn't affect them. If anything, this should have been failing since we had changed the default value of In short, we can't have multi-node clusters with security enabled and no TLS configuration for the transport layer when running in production mode ( es bound to 0.0.0.0 ). Is a valid option making the security example the default one ? Happy to work with you folks to determine why this started breaking just now if that's valuable |
+1 to using a secure configuration by default. If folks explicitly disable security, fine, but since TLS example uses autogenerated certs it's not like it's more "effort" for users. In a production scenario folks will obviously want this stuff enabled and will provide their own certs. |
👋 do we have any update on this? @jkakavas shall we turn the security example the default one? |
We had a discussion with @jmlrt @nkammah @framsouza and I spent some time with @framsouza kind help figuring out what happens. In summary:
Path forward: I think we need to do something similar to what we do for docker compose where we generate the TLS keys/certificates before starting the node. Something very similar to what the security example already does, but figure out a way to incorporate the |
In my case, I found errors from readinessProbe that said: "[[ unexpected operator". Further investigate indicated that despite probe to Elasticsearch cluster health (enabled with TLS and basic authentication) has returned successful, instead the script reported failed. I generated a copy of the manifest and changed from this:
To this... which I suspect it was related to the compatibility of bash in the base image:
Here onwards the readinessProbe works as expected. Please note I am using image version 7.16.0. Hopefully this help the issue here. |
It's simply the default shell of the container which is not capable to use double square-brackets. Change it to
|
Hi @gohmc @mloeschner, this is a different issue. We are working toward fixing it and should publish a new 7.16.1 release soon. |
@jmlrt is there an issue link for this one? Thanks EDIT: Couldn't spot one. Opened #1473 |
I got the same error as @jmlrt when deploying to Docker Desktop on my laptop. |
Chart version:
8.0.0-SNAPSHOT
Kubernetes version: all
Kubernetes provider: all
Helm Version: all
helm get release
output:Output of helm get release
Describe the bug:
When using
8.0.0-SNAPSHOT
and default values (default elasticsearch config, security not enforced), Elasticsearch chart fails to deploy, with pods never reaching ready state due to Readiness probe failing:This seems to be related to the new behavior where Elasticsearch generates TLS certificates by default: elastic/elasticsearch#77231
cc @elastic/es-delivery @jkakavas @mgreau @nkammah
Steps to reproduce:
Expected behavior: Readiness probe should success.
Provide logs and/or server output (if relevant):
Elasticsearch logs
Any additional context:
The text was updated successfully, but these errors were encountered: