Change:
This page talks about but the page referred does not contain anything about . Looks like either Nodes is outdated or kube-controller-manager is missing this documentation.
Page:
was deprecated in k8s v1.26 and will remove in k8s v1.27 Here is the PR:
As it is deprecated we have to mention this as a note in the docs for v1.26 and in v1.27, remove this from the docs. Let's wait for others members, what they think about it.
/kind bug /sig apps
/retitle Stale or incorrect information in Nodes concept page
/remove-sig apps It's nice if people who deprecate a thing also track a docs update issue. However, I wouldn't expect SIG Apps to pick this up.
yeah, that will be really helpful.
/triage accepted
Could you please take a look?
/triage accepted
/assign
thanks for the PR. It is Ok for v1.27. But I have one concern regarding v1.26 if we click on as mentioned above, we can't find as it is deprecated in v1.26. Either we have to remove this from v1.26 also or mention the Note in v1.26 docs regarding the depreciation.
It is mentioned under till k8s v1.25. Here is the following link for it: https://v1-
Hi , Your thoughts on this
This issue has not been updated in over 1 year, and should be re-triaged. You can: Confirm that this issue is still relevant with (org members only) Close this issue with For more details on the triage process, see /remove-triage accepted
closing this issue, as it was resolved by PR /close
Closing this issue. <detailsIn response to : closing this issue, as it was resolved by PR Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details

Discussion:
] ``` <del> If the `status` of the Ready condition remains `Unknown` or `False` for longer than the `pod-eviction-timeout` (an argument passed to the {{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}), then the [node controller](#node-controller) triggers {{< glossary_tooltip text="API-initiated eviction" term_id="api-eviction" >}} for all Pods assigned to that node. The default eviction timeout duration is **five minutes**. In some cases when the node is unreachable, the API server 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 API server is re-established. In the meantime, the pods that are scheduled for deletion may continue to run on the partitioned node. The node controller does not force delete pods until it is confirmed that they have stopped running in the cluster. You can see the pods that might be running on an unreachable node as being in the `Terminating` or `Unknown` state. 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 the node to be deleted from the API server and frees up their names. </del> When problems occur on nodes, the Kubernetes control plane automatically creates [taints](/docs/concepts/scheduling-eviction/taint-and-toleration/) that match the conditions <del> affecting the node. The scheduler takes the Node's taints into consideration when assigning a Pod to a Node. Pods can also have {{< glossary_tooltip text="tolerations" term_id="toleration" >}} that let them run on a Node even though it has a specific taint. See [Taint Nodes by Condition](/docs/concepts/scheduling-eviction/taint-and-toleration/#taint-nodes-by-condition) </del> <ins> affecting the node.  An example of this is when the `status` of the Ready condition remains `Unknown` or `False` for longer than the kube-controller-manager's `NodeMonitorGracePeriod`, which defaults to 40 seconds.  This will cause either an `node.kubernetes.io/unreachable` taint, for an `Unknown` status, or a `node.kubernetes.io/not-ready` taint, for a `False` status, to be added to the Node. These taints affect pending pods as the scheduler takes the Node's taints into consideration when assigning a pod to a Node. Existing pods scheduled to the node may be evicted due to the application of `NoExecute` taints. Pods may also have {{< glossary_tooltip text="tolerations" term_id="toleration" >}} that let them schedule to and continue running on a Node even though it has a specific taint. See [Taint Based Evictions](/docs/concepts/scheduling-eviction/taint-and-toleration/#taint-based-evictions) and [Taint Nodes by Condition](/docs/concepts/scheduling-eviction/taint-and-toleration/#taint-nodes-by-condition) </ins> for more details. ### Capacity and Allocatable {#capacity}

with `NoExecute` effect. If the fault condition returns to normal the kubelet or node controller can remove the relevant taint(s). <ins> In some cases when the node is unreachable, the API server 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 API server is re-established. In the meantime, the pods that are scheduled for deletion may continue to run on the partitioned node. </ins> {{< note >}} The control plane limits the rate of adding node new taints to nodes. This rate limiting manages the number of evictions that are triggered when many nodes become unreachable at