Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Preemption for Coscheduling #581

Open
KunWuLuan opened this issue Apr 26, 2023 · 9 comments
Open

Preemption for Coscheduling #581

KunWuLuan opened this issue Apr 26, 2023 · 9 comments
Assignees

Comments

@KunWuLuan
Copy link
Member

I noticed that when using coscheduling, preempt only one pod a time is not enough.

So I am considering about implement a plugin to support preempt more than one pod a time.

I have implemented a prototype of batch preemption. The batch preemption plugin (will be called BP) will interact with other plugin. BP provide an interface with 2 functions for other plugins: 1. to query the list of pods ready for preemption and 2. do preemption if current pod schedule successfully or preempt successfully.
If a pod find some victims on a node, the plugin will record the result and do nothing.If some other plugins decide to do the preemption after a successful scheduling or successful preemption, they can call the interface, then BP will preempt all victims it has recorded.
Of course, the prototype has already taken into account the situation where the Pod in the record is preempted again by other Pods, or the Pod in the record is rescheduled. This is a bit complicated. If necessary, I will add it later

The point is that I believe the user interaction in the prototype is unreasonable.
In the prototype, BP's behavior is hard coded. I think we may need a CRD for BP to decide when to do preemption. Do you have some ideas?

@JasonChen86899
Copy link

It's a good idea I feel like there can be two ways

  1. Create your own plugin similar to what you mentioned
  2. Modify the preemptive logic of the scheduling framework to support plug-in transparent parameters to it

@KunWuLuan
Copy link
Member Author

/assign

@k8s-triage-robot
Copy link

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

@k8s-ci-robot k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Feb 13, 2024
@k8s-triage-robot
Copy link

The Kubernetes project currently lacks enough active 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 rotten
  • Close this issue with /close
  • Offer to help out with Issue Triage

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

/lifecycle rotten

@k8s-ci-robot k8s-ci-robot added lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Mar 14, 2024
@Huang-Wei
Copy link
Contributor

/remove-lifecycle rotten

@k8s-ci-robot k8s-ci-robot removed the lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. label Mar 14, 2024
@KunWuLuan KunWuLuan changed the title Discussion about batch preemption Preemption for podGroup Apr 12, 2024
@KunWuLuan KunWuLuan changed the title Preemption for podGroup Preemption for Coscheduling Apr 12, 2024
@k8s-triage-robot
Copy link

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

@k8s-ci-robot k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jul 11, 2024
@KunWuLuan
Copy link
Member Author

/remove-lifecycle stale

@k8s-ci-robot k8s-ci-robot removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jul 11, 2024
@shadowdsp
Copy link

Hi @KunWuLuan , is there any ideas on this issue?
Currently, we are encountering the problem that after postfilter checks the entire podgroup, it cannot set nominated node in batches.

@KunWuLuan
Copy link
Member Author

Hi @KunWuLuan , is there any ideas on this issue? Currently, we are encountering the problem that after postfilter checks the entire podgroup, it cannot set nominated node in batches.

@shadowdsp Yes, currently the preemption plugin will only set nominated node for the pod that triggers the preemption. We have a custom plugin to solve the problem, but currently it seems that the plugin is for the specific situation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants