-
Notifications
You must be signed in to change notification settings - Fork 40k
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 clarity into container/image garbage collection in kubelet #15564
Comments
See #15115 for an example where the more clarity would have helped. |
What are the possible scenarios under which GC fails? If this is a binary state, one option is to generate an event and mark the node not schedulable. Metrics are useful for performance analysis. They are that helpful when it comes to cluster stability. |
I agree that in general metrics should be used for performance analysis, but it could be useful in cases where the failure is not fatal or cannot be solved by restarting kubelet. GC could fail sporadically if docker misbehaves, couldn't it? We don't kill kubelet if a single docker request fails or takes too long. E.g., there are bugs where docker is slow in removing images, e.g., moby/moby#16771, and restarts kubelet doesn't help at all. |
Issues go stale after 30d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or |
Stale issues rot after 30d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or |
I think this is still relevant, but would like input from @dashpole |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
Stale issues rot after 30d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
Rotten issues close after 30d of inactivity. Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
We've received plenty of user questions asking whether their container or image GC routine functions correctly. There are two most likely causes:
To provide more clarity for the second case, we can do:
kubelet.log
may not be the best experience (for users) as it could be noisy. We also don't want to add more to our logs.I am leaning towards option (3) since it's easier to customize the metrics we collect, and it's more user-friendly too.
Thoughts? @kubernetes/goog-node
The text was updated successfully, but these errors were encountered: