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: with timeout is used for graceful termination of 'running pods' for feature. We should not re-schedule pod to not-ready unless tolerating it explicitly.
reopen this for more discussion :)
Let me extracted the mixed problems in this issue :-) First one: These two default tolerations attached to the pod by means: if the node is tainted as or , wait for 300s before the pod is evicted from the node. While according to the issue description, is working as expected (pods are not evicted immediately). This part should be closed. Second one: The discussion raised is actually about taint during eviction: if TaintNodesByCondition is enabled, we should also taint node with NotReady:NoSchedule. My thoughts is: it's reasonable to taint node with as well for consistency consideration (but I'm hesitate if only for eliminating confusion as pods are expected to pending on NotReady nodes) I think it should be clearer now.
I open a PR If TaintNodesByCondition is enable, taint node with NotReady:NoSchedule and Unreachable:NoSchedule.
, we did not catch 1.11 release, so this issue will be handled in 1.12 :)
in 1.9.7enable the TaintNodesByCondition and taint nodee.g. node01 with NotReady:NoSchedulethen pod also can not be scheduled to node01 even when node01 is healthy. What you expected to happen: The pod should be scheduled to node01 when it is healthy node and not be scheduled to node01 when it is not ready. Thanks
How did you do that? by kubectl? The fix is not ready until 1.12.
YesI tried "kubectl taint nodes node01 ",and also tried "kubectl taint nodes node01 "
this feature did not handle taint manually
Ok, thanks a lot! So I can not solve the problem manually now and what I should do is just waiting for the version 1.12, right?