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/daemons.md
+2 -2
View File
@@ -21,8 +21,8 @@ Some typical uses of a DaemonSet are:
https://github.com/prometheus/node_exporter), `collectd`, New Relic agent, or Ganglia `gmond`.
In a simple case, one DaemonSet, covering all nodes, would be used for each type of daemon.
A more complex setup might use multiple DaemonSets would be used for a single type of daemon,
but with different flags and/or different memory and cpu requests for different hardware types.
A more complex setup might use multiple DaemonSets for a single type of daemon, but with
different flags and/or different memory and cpu requests for different hardware types.
## Writing a DaemonSet Spec
docs/admin/garbage-collection.md
+1 -1
View File
@@ -51,7 +51,7 @@ Default is -1, which means there is no global limit.
Containers can potentially be garbage collected before their usefulness has expired. These containers
can contain logs and other data that can be useful for troubleshooting. A sufficiently large value for
`maximum-dead-containers-per-container` is highly recommended to allow at least 1 dead container to be
retained per expected container. A higher value for `maximum-dead-containers` is also recommended for a
retained per expected container. A larger value for `maximum-dead-containers` is also recommended for a
similar reason.
See [this issue](https://github.com/kubernetes/kubernetes/issues/13287) for more details.
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.