-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
SharedInformer failure on reconnect can kill the watcher #4388
Comments
This is described in and addressed by #4365 |
Sorry I was mis-remembering the state of the code. In 5.12 it's still the watch manager that is handling this retry. Do you see the watch / informer completely stopping? Or is it just that you keep getting the too many requests responses for a while? The informer watcher should get unlimited reconnect attempts. I can't seem to find the existing issue, but in general the client does not handle the 429 response in the backoff loops. That of course can be added, but I don't think it's actually required for what you have posted here. |
I was going to use this issue to work the 429 logic, but that doesn't seem like it's worth the effort yet. The api server still uses 1 second as the backoff - https://github.com/kubernetes/apiserver/blob/master/pkg/server/filters/maxinflight.go#L38 and kubernetes/kubernetes#79805 |
This issue has been automatically marked as stale because it has not had any activity since 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions! |
Describe the bug
@lburgazzoli reproduced an issue where a
SharedInformer
fails to restart.From the logs, I think that this sequence of events is happening:
SharedInformer
lose connection with the API serverNote that this error happens using the Quarkus extension for JOSDK and the pod is not getting restarted as the exception gets swallowed.
Fabric8 Kubernetes Client version
5.12.3
Steps to reproduce
Expected behavior
The
SharedInformer
exception should be handled, ultimately restarting thePod
in case of necessity.Runtime
OpenShift
Kubernetes API Server version
1.23
Environment
Linux
Fabric8 Kubernetes Client Logs
Additional context
cc. @csviri @metacosm
The text was updated successfully, but these errors were encountered: