KEP-1397: descheduler integration with evacuation API as an alternative to eviction API

[ingvagabund]

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

The descheduler eviction policy is built on top of the eviction API. The API currently does not support eviction requests that are not completed right away. Instead, any eviction needs to either succeed or be rejected in response. Nevertheless, there are cases where an eviction request is expected to only initiate eviction. While getting confirmation or rejection of the eviction initiation (or its promise).

User Stories:

• As a cluster admin running a K8s cluster with a descheduler, I want to evict KubeVirt pods that may require live migration of VMs before a pod can be evicted. A VM live migration can take minutes to complete or may require retries.
• As an end user deploying my application on a K8s cluster with a descheduler, I want to evict pods while performing pod live migration to persist pod's state without storing any necessary data into pod-independent persistent storage.
• As a developer I want to be able to implement a custom eviction policy to address various company use cases that are not supported by default when running a descheduler instance.
• As a descheduler plugin developer I want to be aware of evictions in progress to improve pod nomination and thus avoid unnecessary disruptions.
• As a security professional I want to make sure any live migration adhers to security policies and protects sensitive data.

Describe the solution you'd like

Utilize evacuation API as an alternative to eviction API. As an interim solution (until the evacuation API is available) allow to interpret pods with a special annotation as a request for eviction initiation instead of expecting an immediate eviction.

Describe alternatives you've considered

Part of the upcoming proposal.

What version of descheduler are you using?

descheduler version: 0.29

Additional context

[ingvagabund]

Implementation PR: #1466

[k8s-triage-robot]

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

This bot triages un-triaged issues 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 as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle stale