Add documentation for TaintNodesByCondition (#5352)

* Add documentation for TaintNodesByCondition * Update nodes.md * Update taint-and-toleration.md * Update daemonset.md * Update nodes.md * Update taint-and-toleration.md * Update daemonset.md
2017-09-13 00:55:49 +01:00
parent 7751e73961
commit 83509afbd2
3 changed files with 49 additions and 12 deletions
@@ -65,7 +65,27 @@ The node condition is represented as a JSON object. For example, the following r

 If the Status of the Ready condition is "Unknown" or "False" for longer than the `pod-eviction-timeout`, an argument is passed to the [kube-controller-manager](/docs/admin/kube-controller-manager) and all of the Pods on the node are scheduled for deletion by the Node Controller. The default eviction timeout duration is **five minutes**. In some cases when the node is unreachable, the apiserver is unable to communicate with the kubelet on it. The decision to delete the pods cannot be communicated to the kubelet until it re-establishes communication with the apiserver. In the meantime, the pods which are scheduled for deletion may continue to run on the partitioned node.

-In versions of Kubernetes prior to 1.5, the node controller would [force delete](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods) these unreachable pods from the apiserver. However, in 1.5 and higher, the node controller does not force delete pods until it is confirmed that they have stopped running in the cluster. One can see these pods which may be running on an unreachable node as being in the "Terminating" or "Unknown" states. In cases where Kubernetes cannot deduce from the underlying infrastructure if a node has permanently left a cluster, the cluster administrator may need to delete the node object by hand.  Deleting the node object from Kubernetes causes all the Pod objects running on it to be deleted from the apiserver, freeing up their names.
+In versions of Kubernetes prior to 1.5, the node controller would [force delete](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods)
+these unreachable pods from the apiserver. However, in 1.5 and higher, the node controller does not force delete pods until it is
+confirmed that they have stopped running in the cluster. One can see these pods which may be running on an unreachable node as being in
+the "Terminating" or "Unknown" states. In cases where Kubernetes cannot deduce from the underlying infrastructure if a node has
+permanently left a cluster, the cluster administrator may need to delete the node object by hand.  Deleting the node object from
+Kubernetes causes all the Pod objects running on it to be deleted from the apiserver, freeing up their names.
+
+Version 1.8 introduces an alpha feature that automatically creates
+[taints](/docs/concepts/configuration/taint-and-toleration) that represent conditions.
+To enable this behavior, pass an additional feature gate flag `--feature-gates=...,TaintNodesByCondition=true`
+to the API server, controller manager, and scheduler.
+When `TaintNodesByCondition` is enabled, the scheduler ignores conditions when considering a Node; instead
+it looks at the Node's taints and a Pod's tolerations.
+
+Now users can choose between the old scheduling model and a new, more flexible scheduling model.
+A Pod that does not have any tolerations gets scheduled according to the old model. But a Pod that 
+tolerates the taints of a particular Node can be scheduled on that Node.
+
+Note that because of small delay, usually less than one second, between time when condition is observed and a taint
+is created, it's possible that enabling this feature will slightly increase number of Pods that are successfully
+scheduled but rejected by the kubelet.

 ### Capacity

@@ -174,6 +194,9 @@ NodeController is responsible for adding taints corresponding to node problems l
 node unreachable or not ready. See [this documentation](/docs/concepts/configuration/taint-and-toleration)
 for details about `NoExecute` taints and the alpha feature.

+Starting in version 1.8, the node controller can be made responsible for creating taints that represent
+Node conditions. This is an alpha feature of version 1.8.
+
 ### Self-Registration of Nodes

 When the kubelet flag `--register-node` is true (the default), the kubelet will attempt to