Change:
reasons: []PredicateFailureReason{&PredicateFailureError{nodeports.Name, nodeports.ErrReason}}, name:    "hostport conflict", }, <ins> { pod: &v1.Pod{ Spec: v1.PodSpec{ Tolerations: []v1.Toleration{ {Key: "foo"}, {Key: "bar"}, }, }, }, nodeInfo: schedulerframework.NewNodeInfo(), node: &v1.Node{ ObjectMeta: metav1.ObjectMeta{Name: "machine1"}, Spec: v1.NodeSpec{ Taints: []v1.Taint{ {Key: "foo", Effect: v1.TaintEffectNoSchedule}, {Key: "bar", Effect: v1.TaintEffectNoExecute}, }, }, Status: v1.NodeStatus{Capacity: makeResources(10, 20, 32, 0, 0, 0).Capacity, Allocatable: makeAllocatableResources(10, 20, 32, 0, 0, 0)}, }, name: "taint/toleration match", }, { pod:      &v1.Pod{}, nodeInfo: schedulerframework.NewNodeInfo(), node: &v1.Node{ ObjectMeta: metav1.ObjectMeta{Name: "machine1"}, Spec: v1.NodeSpec{ Taints: []v1.Taint{ {Key: "foo", Effect: v1.TaintEffectNoSchedule}, }, }, Status: v1.NodeStatus{Capacity: makeResources(10, 20, 32, 0, 0, 0).Capacity, Allocatable: makeAllocatableResources(10, 20, 32, 0, 0, 0)}, }, name: "NoSchedule taint/toleration not match", }, { pod:      &v1.Pod{}, nodeInfo: schedulerframework.NewNodeInfo(), node: &v1.Node{ ObjectMeta: metav1.ObjectMeta{Name: "machine1"}, Spec: v1.NodeSpec{ Taints: []v1.Taint{ {Key: "bar", Effect: v1.TaintEffectNoExecute}, }, }, Status: v1.NodeStatus{Capacity: makeResources(10, 20, 32, 0, 0, 0).Capacity, Allocatable: makeAllocatableResources(10, 20, 32, 0, 0, 0)}, }, reasons: []PredicateFailureReason{&PredicateFailureError{tainttoleration.Name, tainttoleration.ErrReasonNotMatch}}, name:    "NoExecute taint/toleration not match", }, { pod:      &v1.Pod{}, nodeInfo: schedulerframework.NewNodeInfo(), node: &v1.Node{ ObjectMeta: metav1.ObjectMeta{Name: "machine1"}, Spec: v1.NodeSpec{ Taints: []v1.Taint{ {Key: "baz", Effect: v1.TaintEffectPreferNoSchedule}, }, }, Status: v1.NodeStatus{Capacity: makeResources(10, 20, 32, 0, 0, 0).Capacity, Allocatable: makeAllocatableResources(10, 20, 32, 0, 0, 0)}, }, name: "PreferNoSchedule taint/toleration not match", }, { pod: &v1.Pod{ ObjectMeta: metav1.ObjectMeta{ Annotations: map[string]string{ types.ConfigSourceAnnotationKey: types.FileSource, }, }, }, nodeInfo: schedulerframework.NewNodeInfo(), node: &v1.Node{ ObjectMeta: metav1.ObjectMeta{Name: "machine1"}, Spec: v1.NodeSpec{ Taints: []v1.Taint{ {Key: "foo", Effect: v1.TaintEffectNoSchedule}, {Key: "bar", Effect: v1.TaintEffectNoExecute}, }, }, Status: v1.NodeStatus{Capacity: makeResources(10, 20, 32, 0, 0, 0).Capacity, Allocatable: makeAllocatableResources(10, 20, 32, 0, 0, 0)}, }, name: "static pods ignore taints", }, </ins> } for _, test := range resourceTests { t.Run(test.name, func(t *testing.T) {

Discussion:
The method doesn't check taints and tolerations. This is problematic in 2 scenarios: If the users bypass scheduler by setting a value in If the node restarts. The node would try to restart scheduled pods once it comes back up, even if it's not ready (has a not-ready taint). Kubelet to check taints and tolerations. a taint in a node. a Pod with set to the Node above, without a matching toleration. /sig node /sig scheduling
this reminds me of your kubelet sync PR ...
I don't think this is a syncing issue. The logic doesn't check taints at all.
scenario 1 is pretty bad, i will let the #sig-node slack know about this.
It doesn't sound like a syncing issue, but we seem to have multiple issues with pod admission/management on restart currently
I'm aware of that issue. This should be unrelated.
I would like to address this. /assign
I think it would be great to proceed after merging ref:
Please add me as reviewer
/triage accepted
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-contributor-experience at . /lifecycle stale
/remove-lifecycle stale PR in review:
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale