You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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: #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:
The text was updated successfully, but these errors were encountered: