Code change:
Effect: v1.TaintEffectNoExecute, } <del> nodeConditionToTaintKeyMap = map[v1.NodeConditionType]string{ v1.NodeMemoryPressure:     algorithm.TaintNodeMemoryPressure, v1.NodeOutOfDisk:          algorithm.TaintNodeOutOfDisk, v1.NodeDiskPressure:       algorithm.TaintNodeDiskPressure, v1.NodeNetworkUnavailable: algorithm.TaintNodeNetworkUnavailable, v1.NodePIDPressure:        algorithm.TaintNodePIDPressure, </del> <ins> nodeConditionToTaintKeyStatusMap = map[v1.NodeConditionType]struct { taintKey string // noScheduleStatus is the condition under which the node should be tainted as not schedulable for this // NodeConditionType noScheduleStatus v1.ConditionStatus }{ v1.NodeReady: { taintKey:         algorithm.TaintNodeNotReady, noScheduleStatus: v1.ConditionFalse, }, v1.NodeMemoryPressure: { taintKey:         algorithm.TaintNodeMemoryPressure, noScheduleStatus: v1.ConditionTrue, }, v1.NodeOutOfDisk: { taintKey:         algorithm.TaintNodeOutOfDisk, noScheduleStatus: v1.ConditionTrue, }, v1.NodeDiskPressure: { taintKey:         algorithm.TaintNodeDiskPressure, noScheduleStatus: v1.ConditionTrue, }, v1.NodeNetworkUnavailable: { taintKey:         algorithm.TaintNodeNetworkUnavailable, noScheduleStatus: v1.ConditionTrue, }, v1.NodePIDPressure: { taintKey:         algorithm.TaintNodePIDPressure, noScheduleStatus: v1.ConditionTrue, }, </ins> } taintKeyToNodeConditionMap = map[string]v1.NodeConditionType{ <ins> algorithm.TaintNodeNotReady:           v1.NodeReady, </ins> algorithm.TaintNodeNetworkUnavailable: v1.NodeNetworkUnavailable, algorithm.TaintNodeMemoryPressure:     v1.NodeMemoryPressure, algorithm.TaintNodeOutOfDisk:          v1.NodeOutOfDisk,

Related discussion:
text: Is this a BUG REPORT or FEATURE REQUEST?: What happened: admission control plugin in apiserver. a deployment with 1 replica. The pod is successfully launched. By default the admission control plugin will add following toleration in the pod. the node where the above pod is running. of image locality policy and above toleration in the pod, scheduler still choose the node to launch the pod. The pod is in state and failed to create. What you expected to happen: The pod should be scheduled to healthy node and created successfully. How to reproduce it (as minimally and precisely as possible): See above steps. Anything else we need to know?: Environment: Kubernetes version (use ): v1.10 Cloud provider or hardware configuration: openstack OS (e.g. from /etc/os-release): Ubuntu 16.04 Kernel (e.g. ): 4.4.0-121-generic Install tools: N/A Others:
/sig scheduler
/sig scheduling /sig node
I think that we should avoid scheduling pods to nodes which is not ready even it can tolerate and , comments
As the pod already claimed to tolerate NotReady, this is an expected behavior. P.S. If the eviction dose not happen after 5m, that should be the bug. Please reopen the issue and modify the description. This is what tolerations is designed for :) And there are many use cases for pod to be scheduled to NotReady nodes (mostly during cluster deployment).
I think maybe you can configure effect to avoid scheduling to those nodes.
scheduler still choose the NotReady node to launch the pod For running, the toleration is used for graceful termination by ; if is enabled, it's better to also taint node with for .
Wondering how the pod can start to run if the Node is not ready at deployment time? Can you specify a use case here?
It won't need to start, system pod pending will be expected :) The point is, freedom for users to decide what tolerations they want matters here. I don't think it's reasonable to combine with in this case.
Perhaps, add to default toleration of admission control plugin could eliminate the confusion.
We should align the behavior when enabled or disabled : if is disabled, will not schedule pod to not-ready node. if is enabled, we should also taint node with .