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

Merge branches 'release-1.6' and 'master' of https://github.com/kubernetes/kubernetes.github.io into release-1.6

Browse Source 
* 'release-1.6' of https://github.com/kubernetes/kubernetes.github.io:

* 'master' of https://github.com/kubernetes/kubernetes.github.io: (23 commits)
  Apply changes from PR #2787
  rephrase the sentence to make expression clear (#2789)
  update index.md (#2788)
  Apply changes from PR #2784 (#2950)
  The link URL of  [kube-controller-manager] is wrong
  Added pod name in run command
  Fix grammar in docs/admin/daemon.md
  update index.md (#2755)
  Update garbage-collection.md (#2732)
  Fix typo (#2842)
  Fix typo
  Fix the typos
  Apply typo fixes from #2791 (#2949)
  Fix typo in kubectl_completion.md
  fix typeo (#2856)
  Use kubectl config current-context to simplify the instructions
  fix a typo in /docs/user-guide/configmap/index.md
  Fix monitor-node-health.md
  amend monitor-node-health.md
  Update manage-compute-resources-container.md
  ...

# Conflicts:
#	docs/tools/index.md
This commit is contained in:
Andrew Chen
2017-03-21 19:04:37 -07:00
parent 4541c229ca 043a6941fe
commit 7215af010f
8 changed files with 20 additions and 23 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/admin/node.md
+1 -1
View File
@@ -61,7 +61,7 @@ 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 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.
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.