Ensure that pods are scheduled to nodes that meet preferred conditions, while satisfying a series of filter plugins for the scheduler. about kubernetes HOT 6 OPEN

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.

from kubernetes.

I assuming that your goal is to (try to)make sure a pod with preferred affinity and taint toleration to be scheduled to a node which matches node affinity and also has the tolerated taint?
Any specific user case for this behavior?

from kubernetes.

I assuming that your goal is to (try to)make sure a pod with preferred affinity and taint toleration to be scheduled to a node which matches node affinity and also has the tolerated taint? Any specific user case for this behavior?

In the case of available pod resources, I want pods to be scheduled onto specific nodes as much as possible. However, the numerous score plugins enabled in the cluster, along with their predefined weights set by SREs, make it challenging for users to dynamically adjust them. Meanwhile, due to performance considerations, the scheduler only traverses and evaluates a subset of nodes. This often leads to suboptimal scheduling results.

from kubernetes.

I get the point that this is trying to get ideal score result. But since the scheduler never guarantees that the pod will be scheduled to the node with the highest score, I'm still confused why this is needed(if you really want to match the node affinity, why not using requiredDuringScheduling).

Anyway, I think you can write a simple doc, and put it on the agenda of sig-scheduling(https://github.com/kubernetes/community/tree/master/sig-scheduling). Folks can have a discussion during the meeting then.

from kubernetes.

I get the point that this is trying to get ideal score result. But since the scheduler never guarantees that the pod will be scheduled to the node with the highest score, I'm still confused why this is needed(if you really want to match the node affinity, why not using requiredDuringScheduling).

Anyway, I think you can write a simple doc, and put it on the agenda of sig-scheduling(https://github.com/kubernetes/community/tree/master/sig-scheduling). Folks can have a discussion during the meeting then.

Okay, thank you. I understand your confusion. My main goal is to ensure that pods are always scheduled to preferred nodes first, rather than partial preferred, while meeting resource requirements

from kubernetes.

/cc

from kubernetes.