anchor.diff:        effect: NoSchedule
   ----
   
  -* Daemon sets can use labels to ensure that a workload runs on a matching worker node. 
  +* Daemon sets can use labels to ensure that a workload runs on a matching worker node.
   
  -* You can use an {product-title} service endpoint to load balance daemon set pods. 
  +* You can use an {product-title} service endpoint to load balance daemon set pods.
   
   [NOTE]
   ====
  -Daemon sets do not schedule pods after a reboot of the node if {product-title} cannot reach the node. 
  +Daemon sets do not schedule pods after a reboot of the node if {product-title} cannot reach the node.
   ====
   --
   
  
positive.code: 
  [id="nodes-edge-remote-workers-strategies-tolerations_{context}"]
  Tolerations::
  You can use pod tolerations to mitigate the effects if the on-premise node controller adds a `node.kubernetes.io/unreachable` taint with a `NoExecute` effect to a node it cannot reach. 
  
  A taint with the `NoExecute` effect affects pods that are running on the node in the following ways:
  
  
negative.code: Daemon sets::
  Daemon sets are the best approach to managing pods on remote worker nodes for the following reasons:
  --
  * Daemon sets do not typically need rescheduling behavior. If a node disconnects from the cluster, pods on the node can continue to run. {product-title} does not change the state of daemon set pods, and leaves the pods in the state they last reported. For example, if a daemon set pod is in the `Running` state, when a node stops communicating, the pod keeps running and is assumed to be running by {product-title}.
  
  * Daemon set pods, by default, are created with `NoExecute` tolerations for the `node.kubernetes.io/unreachable` and `node.kubernetes.io/not-ready` taints with no `tolerationSeconds` value. These default values ensure that daemon set pods are never evicted if the control plane cannot reach a node. For example:
  +
  