Mike Dame

@rsvalerio thanks for confirming that. If they backport this update upstream, then we should be able to pull it in to our versions by just updating the k8s deps and...

@aveshagarwal that is a good point, that having a node selector over only 1 node would hurt the performance of LowNodeUtilization specifically. However, I believe the error that's logged should...

I think RemoveDuplicates should be fine, because that doesn't require multi-node calculations to be effective. For example if I have nodes A, B, C and only want to keep duplicates...

The use case came from a user who wanted to test the Descheduler on a single node before expanding it to their entire cluster. My confusion was due to the...

I think how @lixiang233 described it is good, then we can just keep the one nodeinformer

/remove-lifecycle rotten

@bwmetcalf could you provide an example of how you're using HighNodeUtilization to drain the single node? (I think I get your use case from the other discussion we had but...

Sorry I've been slow on this. Just checking, you still seeing that panic with the deployment? The panic looks like the one from https://github.com/kubernetes-sigs/descheduler/issues/728, which should have been fixed in...

@rajivml have you looked at [topology spread constraints](https://kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/)? Your situation sounds similar to one that was mentioned above https://github.com/kubernetes-sigs/descheduler/issues/211#issuecomment-608200422

When we first implemented this it was brought up that there could be undesirable effects for some strategies, like removeduplicates (https://github.com/kubernetes-sigs/descheduler/pull/510#pullrequestreview-602849304). Thinking about it more now, I think RemoveDuplicates looks...