From 35d2eef003e53dc141510e2c5857adf39ca81804 Mon Sep 17 00:00:00 2001 From: Prasad Katti Date: Tue, 31 Mar 2020 15:49:08 -0700 Subject: [PATCH 1/2] Update phrasing --- content/en/docs/concepts/architecture/nodes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/architecture/nodes.md b/content/en/docs/concepts/architecture/nodes.md index 97188ee9ad..3e3a52dfd8 100644 --- a/content/en/docs/concepts/architecture/nodes.md +++ b/content/en/docs/concepts/architecture/nodes.md @@ -72,7 +72,7 @@ The node condition is represented as a JSON object. For example, the following r ] ``` -If the Status of the Ready condition remains `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 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 the node. The decision to delete the pods cannot be communicated to the kubelet until communication with the apiserver is re-established. In the meantime, the pods that are scheduled for deletion may continue to run on the partitioned node. +If the Status of the Ready condition remains `Unknown` or `False` for longer than the `pod-eviction-timeout` (an argument passed to the [kube-controller-manager](/docs/admin/kube-controller-manager/)), all 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 the node. The decision to delete the pods cannot be communicated to the kubelet until communication with the apiserver is re-established. In the meantime, the pods that 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 From 7ea1a428595eb1d07a839a6da4da4e746e7b0c05 Mon Sep 17 00:00:00 2001 From: Prasad Katti Date: Tue, 31 Mar 2020 17:54:18 -0700 Subject: [PATCH 2/2] Update phrasing - 2 --- content/en/docs/concepts/architecture/nodes.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/en/docs/concepts/architecture/nodes.md b/content/en/docs/concepts/architecture/nodes.md index 3e3a52dfd8..6e62881451 100644 --- a/content/en/docs/concepts/architecture/nodes.md +++ b/content/en/docs/concepts/architecture/nodes.md @@ -83,8 +83,8 @@ Kubernetes causes all the Pod objects running on the node to be deleted from the The node lifecycle controller automatically creates [taints](/docs/concepts/configuration/taint-and-toleration/) that represent conditions. -When the scheduler is assigning a Pod to a Node, the scheduler takes the Node's taints -into account, except for any taints that the Pod tolerates. +The scheduler takes the Node's taints into consideration when assigning a Pod to a Node. +Pods can also have tolerations which let them tolerate a Node's taints. ### Capacity and Allocatable {#capacity}