whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Update node.md to reflect changes to node controller (#1757)

Browse Source 
* Update node.md to reflect changes to node controller

* Review fixes.
This commit is contained in:
Anirudh Ramanathan
2016-12-02 14:32:55 -08:00
committed by Devin Donnelly
parent 35473ffbbe
commit 62f39021e8
2 changed files with 12 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/admin/node.md
+3 -4
View File
@@ -54,10 +54,9 @@ 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 more than five
minutes, then all of the pods on the node are terminated by the node
controller. (The timeout length is configurable by the `--pod-eviction-timeout`
parameter on the controller manager.)
If the Status of the Ready condition is "Unknown" or "False" for longer than the `pod-eviction-timeout`, an argument passed to the [kube-controller-manager](docs/admin/kube-controller-manager/), 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/user-guide/pods/#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.
### Capacity