-
Notifications
You must be signed in to change notification settings - Fork 108
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
split liveness and readiness probes #247
split liveness and readiness probes #247
Conversation
split out liveness and readiness probes. The liveness will always respond when the application is running but the readiness will not respond when a large sync is in progress. fixes mittwald#215
Head branch was pushed to by a user without write access
b34feae
to
9c61e7d
Compare
rebased with the 1.18 updated |
@martin-helmich this should be good now |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍
@martin-helmich - Will this be added to a future release, or is this change already available in v2.7.3? |
:( I don't know if this is related, but I think it is, because the issue coincides with this change. I think most likely it's because i'm using the 'latest' image and the yaml changed in the master branch for an endpoint that isn't hosted by the 'latest' image (yet) - doh on my part I suppose. Still, I was following the 'Manual' install in your README.md and this occurred. Maybe that needs to be updated if the latest image is still 2.7.3. It's a simple tweak to get it working like was, but it did take me a while to finally realize what was happening. I've been using a manual install process for quite a while, and about 2 days ago I noticed Replicator's Ready == 0/1, and since then I've been trying to debug it. It appears that replicator is still actually replicating things successfully, but the readiness state never gets to 1/1 anymore. $ # Create roles and service accounts I run this on an AWS EKS cluster. The pod has an event where it's reporting Readiness as a 404 response. I've confirmed that using port forwarding and hitting the endpoint for it. http://localhost:9102/readyz I also noticed in the EKS logs this entry:
|
split out liveness and readiness probes. The liveness will always respond when the application is running but the readiness will not respond when a large sync is in progress.
fixes #215