Open odsevs opened 2 months ago
Hi, this is working as intended. The descheduler does not know about cluster-level default constraints because it does not have access to the cluster's KubeSchedulerConfiguration.
/remove-kind bug /kind feature
Thanks for the reply. It's a strange design decision that the KubeSchedulerConfiguration is not accessible from within the cluster, but indeed in that case, there is not much you can do. I assume, if this would become a feature, that this configuration would unfortunately need to be duplicated between the kube-scheduler and the descheduler.
Yes, exactly. This has been discussed before if you'd like some more info: https://github.com/kubernetes-sigs/descheduler/issues/609
Essentially the KubeSchedulerConfiguration isn't an actual API object, it's just mounted to the scheduler pod. Users can also deploy custom or multiple schedulers so there isn't a good way to automatically know which default to go with.
What version of descheduler are you using?
descheduler version: 0.30.1
Does this issue reproduce with the latest release?
yes
Which descheduler CLI options are you using?
I installed the helm chart as-is with the values described below.
Please provide a copy of your descheduler policy config file
What k8s version are you using (
kubectl version
)?kubectl version
v1.28.11What did you do?
I defined a default topology spread constraint for the cluster, as described here: https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/#cluster-level-default-constraints
I then:
What did you expect to see? Descheduler kicks in to enforce the default pod topology constraint
What did you see instead? Descheduler does nothing. In the logs: