Allow user to set MinInstanceTypesForSpotToSpotConsolidation

[leoryu]

Description

What problem are you trying to solve?

At present, the MinInstanceTypesForSpotToSpotConsolidation is hard coded with 15. But sometime the users want the consolidation works enven the candidate spot instance types just one.

karpenter/pkg/controllers/disruption/consolidation.go

Line 47 in 140d35b

const MinInstanceTypesForSpotToSpotConsolidation = 15

How important is this feature to you?

I'm building an new provider, I think the karpenter core should give users more options when they want the spot-to-spot feature.

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

[k8s-ci-robot]

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.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[jonathan-innis]

But sometime the users want the consolidation works enven the candidate spot instance types just one

The reason we opted to not make this user-configurable is covered in the Original Spot to Spot Consolidation design but the essence of it is that if you make this number too small, you can race to the bottom and get constantly interrupted. Setting this value to a low value effectively reduces selecting spot instances down to selecting the cheapest spot instance -- which we're a bit weary of since it might cause a lot of application workload disruption.

[jonathan-innis]

I'm hesitant to say that we will accept this -- given the implications. What's your use-case for wanting to change this value and what value do you want to set this to?

[leoryu]

I'm hesitant to say that we will accept this -- given the implications. What's your use-case for wanting to change this value and what value do you want to set this to?

Since I have some workloads which are nice to have, these workloads are not required to work all the time. For this case, I don't want consolidation be blocked by the const, in other words, I want the value is just 1.

The default value is good for users to know the potential risks, but it is also makes sense to give users the accepting the risks option.