-
Notifications
You must be signed in to change notification settings - Fork 67
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
deployer: add info generating commands under resource-allocation #3337
deployer: add info generating commands under resource-allocation #3337
Conversation
This comment was marked as resolved.
This comment was marked as resolved.
d7fcda1
to
83279dd
Compare
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.
🚀 Thanks @consideRatio
deployer/commands/generate/resource_allocation/daemonset_overhead.py
Outdated
Show resolved
Hide resolved
deployer/commands/generate/resource_allocation/daemonset_overhead.py
Outdated
Show resolved
Hide resolved
deployer/commands/generate/resource_allocation/daemonset_overhead.yaml
Outdated
Show resolved
Hide resolved
Thank you for reviewing this @GeorgianaElena! I've not resolved all comments, but will get it done soonish! |
Co-authored-by: Georgiana <georgiana.dolocan@gmail.com>
5854d47
to
baaea25
Compare
Thank you for reviewing this @GeorgianaElena!!!
I'll go for a merge here at this point! |
🎉🎉🎉🎉 Monitor the deployment of the hubs here 👉 https://github.com/2i2c-org/infrastructure/actions/runs/6754266612 |
This PR adds two commands of relevance towards refining the resource-allocation script to meet more needs. The added commands are updating their separate .yaml file's with collected information.
Script overview
daemonset-requests
summarizes the requests from all daemonsets, and clarifies what daemonsets contributed to the requests and what daemonset didn't.The script makes us better understand and clarify differences observed. It helped me verify that the current overhead is mostly cloud provoider specific, to some extent cluster specific (feature and k8s version differences), and to a small extent instance type/node pool specific (gpu drivers).
A caveat of this implementation strategy is that it doesn't intelligently rule out that a daemonset may not only be schedule on some nodes, for example core nodes only, or on nodes with gpus. I've filtered out the gpu related daemonsets manually, and not observed any core node pool only daemonsets.
instance-capacities
scrapes thekubectl get node
reportedcapacity
andallocatable
(allocatable capacity), and saves both the lowest and highest reported value to help us overview the spread of these values across clusters. It turns out that there is a slight spread, but its very low.With
update-node-info
, why these commands?These are iterations on
update-node-info
, but they are added separately asupdate-node-info
directly hooks into theresource-allocation choices
command, making an update to it break the existing behavior.