openshift/openshift-docs
1
0
Fork 0
mirror of https://github.com/openshift/openshift-docs.git synced 2026-02-05 12:46:18 +01:00
Code Issues Releases Activity

OCPBUGS-29656:scaling-worker-latency-profiles document issues

Browse Source
This commit is contained in:
GroceryBoyJr
2024-11-11 15:31:54 -05:00
committed by openshift-cherrypick-robot
parent 3652b90fea
commit eedd7c8e47
3 changed files with 7 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
modules/nodes-cluster-worker-latency-profiles-about.adoc
View File

@@ -6,7 +6,7 @@
[id="nodes-cluster-worker-latency-profiles-about_{context}"]
= Understanding worker latency profiles
Worker latency profiles are four different categories of carefully-tuned parameters. The four parameters which implement these values are `node-status-update-frequency`, `node-monitor-grace-period`, `default-not-ready-toleration-seconds` and `default-unreachable-toleration-seconds`. These parameters can use values which allow you control the reaction of the cluster to latency issues without needing to determine the best values using manual methods.
Worker latency profiles are four different categories of carefully-tuned parameters. The four parameters which implement these values are `node-status-update-frequency`, `node-monitor-grace-period`, `default-not-ready-toleration-seconds` and `default-unreachable-toleration-seconds`. These parameters can use values which allow you to control the reaction of the cluster to latency issues without needing to determine the best values by using manual methods.
[IMPORTANT]
====
@@ -35,11 +35,11 @@ ifdef::openshift-rosa,openshift-dedicated[]
Although the default configuration works in most cases, {product-title} offers a second worker latency profile for situations where the network is experiencing higher latency than usual. The two worker latency profiles are described in the following sections:
endif::openshift-rosa,openshift-dedicated[]
Default worker latency profile:: With the `Default` profile, each `Kubelet` updates its status every 10 seconds (`node-status-update-frequency`). The `Kube Controller Manager` checks the statuses of `Kubelet` every 5 seconds (`node-monitor-grace-period`).
Default worker latency profile:: With the `Default` profile, each `Kubelet` updates its status every 10 seconds (`node-status-update-frequency`). The `Kube Controller Manager` checks the statuses of `Kubelet` every 5 seconds.
+
The Kubernetes Controller Manager waits 40 seconds for a status update from `Kubelet` before considering the `Kubelet` unhealthy. If no status is made available to the Kubernetes Controller Manager, it then marks the node with the `node.kubernetes.io/not-ready` or `node.kubernetes.io/unreachable` taint and evicts the pods on that node.
The Kubernetes Controller Manager waits 40 seconds (`node-monitor-grace-period`) for a status update from `Kubelet` before considering the `Kubelet` unhealthy. If no status is made available to the Kubernetes Controller Manager, it then marks the node with the `node.kubernetes.io/not-ready` or `node.kubernetes.io/unreachable` taint and evicts the pods on that node.
+
If a pod on that node has the `NoExecute` taint, the pod is run according to `tolerationSeconds`. If the pod has no taint, it will be evicted in 300 seconds (`default-not-ready-toleration-seconds` and `default-unreachable-toleration-seconds` settings of the `Kube API Server`).
If a pod is on a node that has the `NoExecute` taint, the pod runs according to `tolerationSeconds`. If the node has no taint, it will be evicted in 300 seconds (`default-not-ready-toleration-seconds` and `default-unreachable-toleration-seconds` settings of the `Kube API Server`).
+
[cols="2,1,2,1"]
|===

2
modules/nodes-cluster-worker-latency-profiles-using-at-creation.adoc
View File

@@ -8,7 +8,7 @@
[IMPORTANT]
====
To edit the configuration of the installer, you will first need to use the command `openshift-install create manifests` to create the default node manifest as well as other manifest YAML files. This file structure must exist before we can add workerLatencyProfile. The platform on which you are installing may have varying requirements. Refer to the Installing section of the documentation for your specific platform.
To edit the configuration of the installation program, first use the command `openshift-install create manifests` to create the default node manifest and other manifest YAML files. This file structure must exist before you can add `workerLatencyProfile`. The platform on which you are installing might have varying requirements. Refer to the Installing section of the documentation for your specific platform.
====
The `workerLatencyProfile` must be added to the manifest in the following sequence:

4
snippets/worker-latency-profile-intro.adoc
View File

@@ -10,7 +10,7 @@
If the cluster administrator has performed latency tests for platform verification, they can discover the need to adjust the operation of the cluster to ensure stability in cases of high latency. The cluster administrator need change only one parameter, recorded in a file, which controls four parameters affecting how supervisory processes read status and interpret the health of the cluster. Changing only the one parameter provides cluster tuning in an easy, supportable manner.
If the cluster administrator has performed latency tests for platform verification, they can discover the need to adjust the operation of the cluster to ensure stability in cases of high latency. The cluster administrator needs to change only one parameter, recorded in a file, which controls four parameters affecting how supervisory processes read status and interpret the health of the cluster. Changing only the one parameter provides cluster tuning in an easy, supportable manner.
The `Kubelet` process provides the starting point for monitoring cluster health. The `Kubelet` sets status values for all nodes in the {product-title} cluster. The Kubernetes Controller Manager (`kube controller`) reads the status values every 10 seconds, by default.
If the `kube controller` cannot read a node status value, it loses contact with that node after a configured period. The default behavior is:
@@ -25,6 +25,6 @@ This behavior can cause problems if your network is prone to latency issues, esp
To avoid this problem, you can use _worker latency profiles_ to adjust the frequency that the `Kubelet` and the Kubernetes Controller Manager wait for status updates before taking action. These adjustments help to ensure that your cluster runs properly if network latency between the control plane and the worker nodes is not optimal.
These worker latency profiles contain three sets of parameters that are pre-defined with carefully tuned values to control the reaction of the cluster to increased latency. No need to experimentally find the best values manually.
These worker latency profiles contain three sets of parameters that are predefined with carefully tuned values to control the reaction of the cluster to increased latency. There is no need to experimentally find the best values manually.
You can configure worker latency profiles when installing a cluster or at any time you notice increased latency in your cluster network.