[Coscheduling] make podGroup a queueing unit

[kerthcet]

Area

• Scheduler
• Controller
• Helm Chart
• Documents

Other components

No response

What happened?

Currently, we use queuedPodInfo's InitialAttemptTimestamp in ordering, it's a static value which will lead to starvation, earlier submitted podGroups will always block the queue if unschedulable(backoff queue can somehow mitigate this but not solve this problem).

	creationTime1 := cs.pgMgr.GetCreationTimestamp(podInfo1.Pod, *podInfo1.InitialAttemptTimestamp)
	creationTime2 := cs.pgMgr.GetCreationTimestamp(podInfo2.Pod, *podInfo2.InitialAttemptTimestamp)

What I want to do is make podGroup's queueing timestamp as a criteria, it will be refreshed together with a new scheduling cycle, the general idea is we'll maintain a podGroups cache in coscheduling. I'll write an updated KEP to detail the design.

What did you expect to happen?

1. pods of podGroup will be ordered based on the podGroup's queueing timestamp
2. podGroup's queueing timestamp will be refreshed in a new scheduling cycle
3. pods of the same podGroup will be popped out sequentially as today

How can we reproduce it (as minimally and precisely as possible)?

No response

Anything else we need to know?

Related issues:
#110
#429

Kubernetes version

None

Scheduler Plugins version

None

[kerthcet]

/remove-kind bug
/kind feature

[kerthcet]

cc @Huang-Wei

[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

[k8s-triage-robot]

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-triage-robot]

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

This bot triages 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:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

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

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

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

This bot triages 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:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

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

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[tenzen-y]

@kerthcet @Huang-Wei Do we have no plan for this improvement?

[Huang-Wei]

I think it's a valid feature. I may need some volunteer to pick it up.

[tenzen-y]

/remove-lifecycle rotten

[tenzen-y]

I think it's a valid feature. I may need some volunteer to pick it up.

I think that @kerthcet already took this since he submitted the proposal here: #661

[Huang-Wei]

I think that @kerthcet already took this since he submitted the proposal here: #661

ah i missed that (for so long). Will review by this weekend.

[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