-
Notifications
You must be signed in to change notification settings - Fork 597
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
KubeCPUOvercommit doesn't take node pools #481
Comments
I definitely love where you're going. I have a feeling that only an effort like kubernetes/enhancements#1916 could potentially go in this direction. Node pools are not well defined unfortunately, I actually poked around on sig-node yesterday if there might be possibilities to standardize this, but even if that were to lead to something, it's in the very beginning. I think this would make sense for node-pools where you are aware of the scheduling constraints, I don't think going as far as tolerations is really reasonable or possible, as we would essentially implement the scheduler again I think. |
Agreed, probably sufficient to link a pod to a node pool through a recording rule. |
Hi guys, Maybe my question is not directly related but I don't understand the expression of the alerting rule. I have a very small cluster with just 1 instance and that rule is always firing because For example: Let's say my containers reserved a total of 2 cpu on a single 4 cpu instance. The alerting rule give:
but in reality I just commit 50% of the CPU resource of the entire cluster so for me the expression should be:
Am I not understanding something here ? |
The alert message says:
So this alert is not applicable if you don't intend to run more than one node. |
I get your point but the message should be:
|
This issue has not had any activity in the past 30 days, so the
Thank you for your contributions! |
kubernetes-mixin/alerts/resource_alerts.libsonnet
Lines 25 to 41 in dc563cb
The KubeCPUOvercommit doesn't take node pools and tolerations into account and it might even be a stretch to cover that. Anyone has thoughts about that?
The text was updated successfully, but these errors were encountered: