proposal KEP-697: descheduler for karmada

[Garrybest]

What type of PR is this?
/kind design

What this PR does / why we need it:
The proposal for #697

Which issue(s) this PR fixes:
Fixes #

Special notes for your reviewer:

Does this PR introduce a user-facing change?:

This KEP proposes a new component, Descheduler, which has a similar behavior with Descheduler for Kubernetes, based on its policy, finds some replicas that can be moved and evicts them from a cluster.

[RainbowMango]

Let's merge it and continue the discussion.
/lgtm
/approve

[karmada-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: RainbowMango

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 [RainbowMango]

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

[RainbowMango]

Find the non-desired ones, i.e., whose desired replicas are less than ready replicas, and then request scheduler-estimator to get the replicas that need to be evicted.

How the descheduler detects non-desired replicas?

[RainbowMango]

Modify scheduling result in resourcebindings.spec.clusters for eviction, i.e., substract unscheduable pods number in the relevant field resourcebindings.spec.clusters.

The .spec.clusters field is managed by karmada-scheduler, If descheduler updates this field, what else do you expect from scale scheduling? (since all decisions have been done by descheduler.)

[Garrybest]

How the descheduler detects non-desired replicas?

Good question. It calls scheduler-estimator by gRPC to detect unscheduable replicas. We should add a new gRPC service interface into scheduler-estimator for detection.

[Garrybest]

The .spec.clusters field is managed by karmada-scheduler, If descheduler updates this field, what else do you expect from scale scheduling? (since all decisions have been done by descheduler.)

Let me give a sample. Imagine we have a workload with 9 desired replicas. Now cluster1 has some nodes broken and 2 pods have been recreated. However, there are no more resource for them to be scheduled.

Firstly, descheduler find 2 pods are in failed-scheduled condition, it just decreases desired replicas of cluster1 from 6 to 4. And then scheduler finds the workload needs a scale scheduling, so it calls all scheduler-estimator for collecting max available replicas and make a scheduling decision to schedule the 2 replicas. In this case, the desired replicas of cluster1 will be changed from 3 to 5.

[RainbowMango]

Yeah, got it, thanks. The descheduler only decrease the replica, then karmada-scheduler scale the replica to other available clusters.