Closed andrewhibbert closed 1 month ago
This issue is currently awaiting triage.
If Karpenter contributors determines this is a relevant issue, they will accept it by applying the triage/accepted
label and provide further guidance.
The triage/accepted
label can be added by org members by writing /triage accepted
in a comment.
This is an intentional design decision of Karpenter that is different in CAS. We intentionally decide not to use a threshold, as this can get you into unexpected edge cases. As an alternative we're discussing a price improvement threshold in https://github.com/kubernetes-sigs/karpenter/pull/1433. Closing this in favor of that
Description
What problem are you trying to solve?
Since v1 I am seeing nodes that are more utilised consolidated over those less utilized, I'd like to be able to set a threshold percentage to ignore nodes that are well utilized.
Example - this node is underutilized:
This is more utilized:
The latter node is then consolidated at 10:26:
I appreciate that this is largely due to
consolidateAfter
which we have set at 20 minutes but it is also a combination of this and kube-scheduler scheduling pods to least allocated nodes (as per comment in https://github.com/kubernetes-sigs/karpenter/issues/735#issuecomment-2218355057) and karpenter not having these controls to reduce disruption. In the above case I'd rather just leave it until memory and cpu requests are under 50%. Similar to how cluster autoscaler works - https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md#how-does-scale-down-work, but not blended as Karpenter can provision different size nodesI see an issue https://github.com/kubernetes-sigs/karpenter/issues/1440 which is kind of related but only for replace.
How important is this feature to you?
Important.