Drop descheduler server from strategies

[ingvagabund]

Removing sigs.k8s.io/descheduler/cmd/descheduler/app/options dependency from all strategies so they can be run independently of options.DeschedulerServer.

Building on top of #266

[damemi]

maybe we could initialize a map of name:strategyFunction and put these all in a loop? That would look more like what the scheduler does and could open us up for better user configuration in the future (like being able to specify a custom ordering of the strategies to run). Something like

type strategyFunction func(clientset.Interface, []v1*Node, bool, *evictions.PodEvictor)

strategyFuncs := map[string]strategyFunction{
  "RemoveDuplicates": strategies.RemoveDuplicatePods,
  "LowNodeUtilization": strategies.LowNodeUtilization,
  "RemovePodsViolatingInterPodAntiAffinity": strategies.RemovePodsViolatingInterPodAntiAffinity,
  "RemovePodsViolatingNodeAffinity": strategies.RemovePodsViolatingNodeAffinity,
  "RemovePodsViolatingNodeTaints": strategies.RemovePodsViolatingNodeTaints,
}

for name, f := range strategyFuncs {
  if s := deschedulerPolicy.Strategies[name]; s.Enabled {
    f(rs.Client, nodes, rs.EvictLocalStoragePods, podEvictor)
  }
}

The map could be declared at the package level so we have a good DefaultStrategy map

[ingvagabund]

Yeah, I wanted to talk about this in more detail. Right now every strategy has free will about arguments that go in. Should we create an interface for a strategy? Or, use a data type for it as you suggest? Interface might be too restrictive atm. Private strategyFunction is a low hanging fruit that can be extended as other strategies goes in.

tldr; Though, the list of arguments might grow too much. Later, we might implement some initialization/factory part that will get the config and produces a list of enabled strategies so we don't have to check for s.Enabled at all. Each strategy might register itself (as is done in the scheduler) as plugins. The factory will just accept rs.EvictLocalStoragePods and rs.Client for now. Each strategy implementing Run([]*v1.Node, *evictions.PodEvictor)

[damemi]

I agree, there is a lot of discussion that could be had around implementing more of a "framework" for the descheduler strategies. I was just thinking my change could be a quick fix to clean up the chain of if-statements, but with the side benefit of suggesting a starting framework somewhere down the line. I don't think we need to get too much into it for this PR though

[damemi]

/lgtm

[ravisantoshgudimetla]

Mostly LGTM just a nit, it's fine if you don't want to address it

[ravisantoshgudimetla]

/approve

Thanks for working on this @ingvagabund

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ingvagabund, ravisantoshgudimetla

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [ravisantoshgudimetla]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment