LowNodeUtilization does not take into account podAntiAffinity when choosing a pod to evict

[ForbesLindesay]

I have a node that is over-utilized and a node that is under-utilized. There is also a deployment with a pod on both nodes, and an anti-affinity rule that prevents those pods being scheduled on the same node. Unfortunately, each time the descheduler runs, it evicts the pod for this app, which is promptly re-scheduled on the same node, since it cannot be moved to the under-utilized node. There are other pods that could be chosen.

[lixiang233]

Yes, descheduler won't check if pods will be properly evicted to other nodes before evicting, so I think it would make sense to add some mechanism to check this and turn to other pods if checks failed.

[seanmalloy]

/kind feature

@ForbesLindesay thanks for opening this issue. In general it would be great if the descheduler had the ability to more intelligently select which pods to evict for all strategies. There is a desire to be able to import the kube-scheduler code into the descheduler which would allow leveraging the kube-scheduler's filtering and scoring capabilities. This has been discussed in #184 and #283

There is some work that needs to be completed before the kube-scheduler can be easily imported. See kubernetes/kubernetes#89930.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[seanmalloy]

/remove-lifecycle stale

[codablock]

fyi, the same issue happens with pods that are bound to specific availability zones due to persistent volume claims being only attachable in one specific zone. If such pods are evicted, they will always be scheduled to the same zone, which might mean that it will be the same node if there is only one node per zone.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[damemi]

/remove-lifecycle stale

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[seanmalloy]

/remove-lifecycle stale

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[k8s-triage-robot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten

[seanmalloy]

/remove-lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[jecnua]

Still valid.

[damemi]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[ghostsquad]

/remove-lifecycle stale

[ghostsquad]

stale-bot is annoying..
kubernetes/kubernetes#103151

@lixiang233 - can this issue be marked as a desired feature as to avoid needing to keep it alive (protection from stale-bot)?

[damemi]

@ghostsquad I skimmed that thread, but maybe you could point me to what we need to do to mark this as desired? We have other issues that would benefit from that too

[ghostsquad]

@damemi https://www.kubernetes.dev/docs/guide/issue-triage/#if-an-issue-has-no-activity-after-90-days

TLDR /lifecycle frozen

And

https://www.kubernetes.dev/docs/guide/issue-triage/#step-three-define-priority

[damemi]

/lifecycle frozen
thanks @ghostsquad :)