-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Add liveness and readiness probes #1855
Comments
@ncdc: Please ensure the request meets the requirements listed here. If this request no longer meets these requirements, the label can be removed In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
@ncdc I would like to work on this if possible |
/assign @prankul88 |
/cc |
This will be important for the e2e tests. I pretty much have to resort to retrying my creates until the webhook services are ready to respond. Would be happy to work with you @prankul88 if you'd like, feel free to reach out on slack or here. No obligation though, if you'd like to tackle it yourself that works for me too. |
Note, whatever we don't won't be 100% accurate and may still flake because the goroutine our readiness checks run in is different from the goroutine for the webhook server. See kubernetes-sigs/controller-runtime#723 for more details. |
@chuckha Thanks. Would love your help. Give me some time to have a little more knowledge about it. Will reach out to you:) |
Currently, manager pods turn Ready as soon as their binary starts. However, it takes ~40 more seconds for the webhook to actually start serving requests. In order to avoid that, we introduce a readiness probe that marks the pod as Ready only once the server starts. Please note that there is no way to do it properly with the current controller-runtime. We don't have a hook point that would get executed once the webhook has started. Therefore we have a Sleep there. That should be dropped once kubernetes-sigs/cluster-api#1855 is implemented. Signed-off-by: Petr Horacek <[email protected]>
There is work in progress for CAPA here: kubernetes-sigs/cluster-api-provider-aws#1487. We should be consistent. |
User Story
As a developer/user/operator I would like to have liveness and readiness probes for the Cluster API manager so that I am better informed when it is operational and ready to receive requests.
Detailed Description
See user story.
Anything else you would like to add:
It would be ideal if the readiness probe could only return true once the webhook server is online and ready to receive requests. I'm not sure how feasible this is, though.
/kind feature
/milestone v0.3.0
/priority important-soon
/help
The text was updated successfully, but these errors were encountered: