Change:
if notBestEffort { return lifecycle.PodAdmitResult{Admit: true} } <ins> // When node has memory pressure and TaintNodesByCondition is enabled, check BestEffort Pod's toleration: // admit it if tolerates memory pressure taint, fail for other tolerations, e.g. OutOfDisk. if utilfeature.DefaultFeatureGate.Enabled(features.TaintNodesByCondition) && v1helper.TolerationsTolerateTaint(attrs.Pod.Spec.Tolerations, &v1.Taint{ Key:    algorithm.TaintNodeMemoryPressure, Effect: v1.TaintEffectNoSchedule, }) { return lifecycle.PodAdmitResult{Admit: true} } </ins> } // reject pods when under memory pressure (if pod is best effort), or if under disk pressure.

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug Description: According to the preemption's doc, we'll take priority over Qos; but in , the higher priority BestEffort pod maybe rejected because of memory pressure. If TaintNodesByCondition enabled, the pod need memory pressure toleration. /cc , correct me if any mis-understanding.
/sig scheduling /sig node
If the node has memory pressure, it rejects all pods that do not tolerate it. This is orthogonal to QoS and Priority.
Preemption and node evictions do not work with the same exact metrics. Preemption is unaware of usage, while node eviction logic has pod and node resource usage information. Node eviction takes usage into account both when admitting a new pod and when evicting an existing pod. has recently sent out to update node eviction doc.
, but will also reject it if pod tolerate it :(
, please refer to for what I mean :). BTW, you need to configure out and predicates, and enable alpha feature. /cc
I'm not familiar with the Preemption/Priority design, so I don't know where is preemption happening (Node or control plane). But despite that I wouldn't read what you wrote as inconsistency. Priority takes precedence over QoS when it can. But if some QoS Pods are not allowed to run somewhere it's not an issue with preemption/priority or QoS. It's a separate predicate. Slight OT, but related to your proposal, I think we should go another way. We should prevent BE pods to get MemoryPressure toleration. Having this can result with bad user experience, as Pod will get scheduled on a Node, and then immediately killed, because Kubelet ignores tolerations. Or we can teach kubelet respect tolerations for NC created taints. I'd consider it a blocker for beta of TaintNodeByCondition.
Yes; but if BE pod has higher priority, the other pods with lower priority will be evicted by kubelet. This maybe better, no idea on which pod will be BE but with higher priority :) , do you think we should reject BE pod with MemoryPressure toleration, even it has a higher priority?

I would like to mention several points here: of all, I should say that a high priority BE pod is a result of bad configuration and we should not optimize for it, but given that it is not rejected by the system, we must handle it. BE pod will never cause preemption due to lack of resources, because a BE pod needs zero resources from scheduler's point of view. of point , I think we should not worry about a high priority BE pod getting rejected by kubelet or causing other pods to be evicted from a node. We should document the system behavior and have clear guidelines and point out the problems that could be caused by bad configurations. After that we should leave it to the user to decide if a configuration makes sense for their use-case.
Overall, I agree :). Personally, I'd like to keep components behavior align: reject by admission/kubelet or accept by them. Currently, apiserver/scheduler accept and handle it and kubelet will reject it.
Kubelet does not reject a BE pod with high priority either.
I mean BE pod with Memory Pressure toleration :)
I see. The pod may still be scheduled without any problem if another node in the cluster is found that does not have memory pressure. So, I wouldn't call this inconsistent behavior of components. Anyway, I leave it up to SIG node to decide whehter the current behavior should be changed.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale