anchor.diff:    effect: "NoExecute"
   ----
   
  -In this case, the pod cannot be scheduled onto the node, because there is no toleration matching the third taint. The pod continues running if it is already running on the node when the taint is added, because the third taint is the only
  -one of the three that is not tolerated by the pod.
  +In this case, the Pod cannot be scheduled onto the node, because there is no toleration matching the third taint. The Pod continues running if it is already running on the node when the taint is added, because the third taint is the only
  +one of the three that is not tolerated by the Pod.
   
   [id="nodes-scheduler-taints-tolerations-about-prevent_{context}"]
   == Preventing pod eviction for node problems
   
  -{product-title} can be configured to represent *node unreachable* and *node not ready* conditions as taints.  This allows per-pod specification of how long to remain bound to a node that becomes unreachable or not ready, rather than using the default of five minutes.
  -
  -The Taint-Based Evictions feature is enabled by default. The taints are automatically added by the node controller and the normal logic for evicting pods from `Ready` nodes is disabled.
  -
  -* If a node enters a not ready state, the `node.kubernetes.io/not-ready:NoExecute`  taint is added and pods cannot be scheduled on the node. Existing pods remain for the toleration seconds period.
  -* If a node enters a not reachable state, the `node.kubernetes.io/unreachable:NoExecute` taint is added and pods cannot be scheduled on the node. Existing pods remain for the toleration seconds period.
  -
  -This feature, in combination with `tolerationSeconds`, allows a pod to specify how long it should stay bound to a node that has one or both of these problems.
  +The Taint-Based Evictions feature, enabled by default, adds a taint with the `NoExecute` effect to nodes that are not ready or are unreachable. This allows you to specify how long a Pod should remain bound to a node that becomes unreachable or not ready, rather than using the default of five minutes. For example, you might want to allow a Pod on an unreachable node if the workload is safe to remain running while a networking issue resolves.
  +
  +If a node enters a not ready state, the node controller adds the `node.kubernetes.io/not-ready:NoExecute` taint to the node. If a node enters an unreachable state, the  the node controller adds the `node.kubernetes.io/unreachable:NoExecute` taint to the node. 
  +
  +The `NoExecute` taint affects Pods that are already running on the node as follows: 
  +
  +* Pods that do not tolerate the taint are evicted immediately.
  +* Pods that tolerate the taint without specifying `tolerationSeconds` in their toleration specification remain bound forever.
  +* Pods that tolerate the taint with a specified `tolerationSeconds` remain bound for the specified amount of time.
   
   [id="nodes-scheduler-taints-tolerations-about-taintNodesByCondition_{context}"]
   == Understanding pod scheduling and node conditions (Taint Node by Condition)
   
  -{product-title} automatically taints nodes that report conditions such as memory pressure and disk pressure. If a node reports a condition, a taint is added until the condition clears. The taints have the `NoSchedule` effect, which means no pod can be scheduled on the node, unless the pod has a matching toleration. This feature, *Taint Nodes By Condition*, is enabled by default. 
  +{product-title} automatically taints nodes that report conditions such as memory pressure and disk pressure. If a node reports a condition, a taint is added until the condition clears. The taints have the `NoSchedule` effect, which means no Pod can be scheduled on the node, unless the Pod has a matching toleration. This feature, *Taint Nodes By Condition*, is enabled by default. 
    
  -The scheduler checks for these taints on nodes before scheduling pods. If the taint is present, the pod is scheduled on a different node. Because the scheduler checks for taints and not the actual Node conditions, you configure the scheduler to ignore some of these node conditions by adding appropriate Pod tolerations. 
  +The scheduler checks for these taints on nodes before scheduling Pods. If the taint is present, the Pod is scheduled on a different node. Because the scheduler checks for taints and not the actual Node conditions, you configure the scheduler to ignore some of these node conditions by adding appropriate Pod tolerations. 
   
   The DaemonSet controller automatically adds the following tolerations to all daemons, to ensure backward compatibility: 
   
   * node.kubernetes.io/memory-pressure
   * node.kubernetes.io/disk-pressure
  -* node.kubernetes.io/out-of-disk (only for critical pods)
  +* node.kubernetes.io/out-of-disk (only for critical Pods)
   * node.kubernetes.io/unschedulable (1.10 or later)
   * node.kubernetes.io/network-unavailable (host network only)
   
  
positive.code: [id="nodes-scheduler-taints-tolerations-about-taintBasedEvictions_{context}"]
  == Understanding evicting pods by condition (Taint-Based Evictions)
  
  The Taint-Based Evictions feature, enabled by default, evicts pods from a node that experiences specific conditions, such as `not-ready` and `unreachable`. 
  When a node experiences one of these conditions, {product-title} automatically adds taints to the node, and starts evicting and rescheduling the pods on different nodes.
  
  Taint Based Evictions has a `NoExecute` effect, where any pod that does not tolerate the taint will be evicted immediately and any pod that does tolerate the taint will never be evicted.
  
  [NOTE]
  ====
  {product-title} evicts pods in a rate-limited way to prevent massive pod evictions in scenarios such as the master becoming partitioned from the nodes.
  ====
  
  This feature, in combination with `tolerationSeconds`, allows you to specify how long a pod should stay bound to a node that has a node condition. If the condition still exists after the `tolerationSections` period, the taint remains on the node and the pods are evicted in a rate-limited manner. If the condition clears before the `tolerationSeconds` period, pods are not removed. 
  
  {product-title} automatically adds a toleration for `node.kubernetes.io/not-ready` and `node.kubernetes.io/unreachable` with `tolerationSeconds=300`, unless the pod configuration specifies either toleration.
  
  [source,yaml]
  ----
  
negative.code: $ oc adm taint nodes node1 key2=value2:NoSchedule
  ----
  
  * The Pod has the following tolerations:
  +
  [source, yaml]
  ----
  