Allow configuring defaultConstraints at the karpenter spec level

[softcane]

Description

What problem are you trying to solve?

Karpenter depends on the topologySpreadConstraints in the deployment spec, which becomes difficult to manage in a large system, as developers need to invest development time to comply with the new system-wide distribution.

The issue arises when Karpenter bypasses the logic of the kube scheduler. For instance, the Cluster Autoscaler typically depends on the kube scheduler and adheres to the default k8s topology constraints.

I suggest considering it as a feature request for Karpenter to honour the default topology constraints set at the cluster level or allowing the system administrator to inject topology constraints they think optimal for the cluster's use case.

Karpenter should prioritize the topology constraints specified at the deployment level, falling back to default constraints if none are provided.

Example

defaultConstraints:
  - maxSkew: 3
    topologyKey: "kubernetes.io/hostname"
    whenUnsatisfiable: ScheduleAnyway
  - maxSkew: 5
    topologyKey: "topology.kubernetes.io/zone"
    whenUnsatisfiable: ScheduleAnyway

How important is this feature to you?

• 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