Descheduler strategies as plugins

[ingvagabund]

Is your feature request related to a problem? Please describe.

The number of strategies is increasing and we still have code of all the strategies under the same directory. Which increases risk of identifier name collisions. It’s also currently impractical to add custom strategies into the Descheduler (in case someone decides to fork the code and integrate e.g. proprietary strategies.).

Evicting pods outside the strategies will free us from passing pod evictor into each strategy. It will also allow us to run the Descheduler as a simulator more easily. E.g. by checking which strategies are evicting the same pods, how one strategy impacts other, etc.

Describe the solution you'd like

Create a factory like initialization of plugins and a new strategy interface with Deschedule method

Describe alternatives you've considered
NONE

What version of descheduler are you using?

Any version

Additional context

Google doc for open discussion: https://docs.google.com/document/d/1VuqbwakL69H4sbsGP8J6C10x1NfEpeAQY_cHibrZY0M/edit#

[damemi]

+1, standardizing an interface for each strategy and moving them into their own packages is at the very least a big improvement for our code organization. I would go even further to say this is more than a feature, but a considerable redesign (and one well worth having).

I'll leave some comments on the doc, thanks for starting this @ingvagabund !
/kind design

[bytetwin]

This is a great refractor. I would be interested to pick this up as it will give some good understanding of the code base.
Is this in a shape to start? I can take a shot at it and raise doubts here/design doc or via PR as I encounter them

There is another recommendation of converting strategy params to an interface.
Can I attempt both in the same change ?

[damemi]

Can I attempt both in the same change ?

Let's keep different changes to their own PRs. Especially with refactorings like this, if something goes wrong that makes it easier to track down and revert

[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

[seanmalloy]

/remove-lifecycle stale

[MadhavJivrajani]

/remove-kind design
/kind feature
kind/design is migrated to kind/feature, see kubernetes/community#6144 for more details

[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

[ingvagabund]

/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

[ingvagabund]

/remove-lifecycle stale

[ingvagabund]

PoC in #781

[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

[damemi]

/remove-lifecycle stale
/lifecycle frozen

[knelasevero]

@ingvagabund @damemi @a7i should we close this one? Considering the title, strategies are moved to plugins now

[damemi]

I think it's worth keeping open until we've gotten off of the migration wrapper

[ingvagabund]

The migration wrapper removed through #1006.