to add a feasible nodes cache for same type of pods in same workload

[lowang-bh]

What would you like to be added?

A cached feasible nodes list for a worklode, eg, deployment.

Why is this needed?

As predicating is a time consume step, especially in a large cluster.
And as we know, same type of pods in a workload have same constraint, such as deployment's pod, Job's replicas.
So the first pod's feasible nodes list is aslo available for the other pods in a workload.
Choose one from the cached nodes will save much time than re-run a predicating for next pod.

The same does the cache with a node list predicating failed.

Maybe it is more significant when scheduling a batch pods with gang-scheduling or co-scheduling policy.

[k8s-ci-robot]

This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

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-sigs/prow repository.

[AxeZhan]

/sig node

[zhifei92]

Which component do you want to implement this functionality in, is it the schdeuler? And If podAffinity is present, the distribution of pods in the deployment will be affected.

[chengjoey]

even through same type of pods in same workload, if set volume or TopologySpreadConstraint, then pass through the filter of plugins such as resource, affinity, feasible nodes should be a big difference

[AxeZhan]

/sig scheduling
Sorry, I didn't look into the details. As your purpose is to accelerating predicate, this belongs to sig-scheduling.

I think I can understand some of what you're trying to do.
For example, if we have a deployment with required nodeAffinity.
Then maybe we can store a affinity->node mapping, and then we can skip preFilter of nodeAffinity plugin for other pods in the same deployment.

However, the maintaining of this cache will also increase the burden on the scheduler, and brings additional complexity to the framework.
If you have implemented this somewhere, then maybe the results of a benchmark will be very convincing.

[lowang-bh]

And If podAffinity is present, the distribution of pods in the deployment will be affected.

all pods in a deployment have same predicate condition, include podAffinity, right？

[lowang-bh]

plugins such as resource, affinity, feasible nodes should be a big difference

Resource should be re-considered, of couse.

[lowang-bh]

However, the maintaining of this cache will also increase the burden on the scheduler, and brings additional complexity to the framework.

Yes, it is a heavy work. I just throw out this question and we can discuss it.

If you have implemented this somewhere, then maybe the results of a benchmark will be very convincing.

Some other schedulers based on kubernetes have this feature.
I will try to run a benchmarck if I can.

[AxeZhan]

Some other schedulers based on kubernetes have this feature.

Can you paste a reference here? :)

[basuotian]

Does this feature look like equivelance class cache which is removed in v1.23?

[lowang-bh]

Some other schedulers based on kubernetes have this feature.

Can you paste a reference here? :)

such as the godel-scheduler in bytedance's recent paper described.
and volcano has add it in volcano-sh/volcano#1165.

https://github.com/volcano-sh/volcano/blob/70a483b66653ee402babdc733505a92fff890f5f/pkg/scheduler/plugins/predicates/predicates.go#L434

[lowang-bh]

equivelance class cache

Yes, seem it has been discussed in
#17390,
#71013
#65714

removed in #71399