This repository has been archived by the owner on May 16, 2023. It is now read-only.
[elasticsearch] Tweak the 'readinessProbe' command to verify that master nodes are available. #380
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
nodes are available. The behaviour of the `/` endpoint changed[0] between 6.x and 7.x, whereby previously it would return a HTTP `503` response when the cluster was blocked, it now returns a HTTP `200` response even if there are no masters available. This change updates the behaviour of the `readinessProbe` command during normal running to verify that the local node is responding and that there are master nodes available. [1] The desired behaviour here is that if the data nodes are unable to talk to their master nodes for whatever reason, then the data nodes will become `Unready` and therefore be removed from the Service load-balancer until the master nodes are available again. Refs: [0] elastic/elasticsearch#29045 [1] elastic/elasticsearch#34897 (comment)
|
Related issue - #376 |
jmlrt
added a commit
to jmlrt/helm-charts
that referenced
this pull request
Apr 17, 2020
This PR update readiness probe endpoint to check only `/` endpoint instead of `/_cluster/health?timeout=0s` when Elasticsearch is already running. This revert to initial config which was changed in elastic#380 with the exception that 503 HTTP code is accepted for 6.x (see elastic/elasticsearch#8902 for more details about why 503 is OK on Elasticsearch 6.x).
4 tasks
jmlrt
added a commit
to jmlrt/helm-charts
that referenced
this pull request
Apr 17, 2020
This PR update readiness probe endpoint to check only `/` endpoint instead of `/_cluster/health?timeout=0s` when Elasticsearch is already running. This revert to initial config which was changed in elastic#380 with the exception that 503 HTTP code is accepted for 6.x (see elastic/elasticsearch#8902 for more details about why 503 is OK on Elasticsearch 6.x).
galina-tochilkin
pushed a commit
to mtp-devops/3d-party-helm
that referenced
this pull request
Dec 20, 2022
This PR update readiness probe endpoint to check only `/` endpoint instead of `/_cluster/health?timeout=0s` when Elasticsearch is already running. This revert to initial config which was changed in elastic/helm-charts#380 with the exception that 503 HTTP code is accepted for 6.x (see elastic/elasticsearch#8902 for more details about why 503 is OK on Elasticsearch 6.x).
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The behaviour of the
/endpoint changed[0] between 6.x and 7.x, wherebypreviously it would return a HTTP
503response when the cluster wasblocked, it now returns a HTTP
200response even if there are no mastersavailable.
This change updates the behaviour of the
readinessProbecommand duringnormal running to verify that the local node is responding and that there
are master nodes available. [1]
The desired behaviour here is that if the data nodes are unable to talk to
their master nodes for whatever reason, then the data nodes will become
Unreadyand therefore be removed from the Service load-balancer untilthe master nodes are available again.
Refs:
[0] elastic/elasticsearch#29045
[1] elastic/elasticsearch#34897 (comment)
[ ] README.md updated with any new values or changes${CHART}/tests/*.py[ ] Updated integration tests in${CHART}/examples/*/test/goss.yaml