5.4. 使用 worker 延迟配置集提高高延迟环境中的集群稳定性

如果集群管理员为平台验证执行了延迟测试，他们可以发现需要调整集群的操作，以确保高延迟的情况的稳定性。集群管理员只需要更改一个参数，该参数记录在一个文件中，它控制了 Supervisory 进程读取状态并解释集群的运行状况的四个参数。仅更改一个参数可以以方便、可支持的方式提供集群调整。

Kubelet 进程提供监控集群运行状况的起点。Kubelet 为 OpenShift Container Platform 集群中的所有节点设置状态值。Kubernetes Controller Manager (kube controller) 默认每 10 秒读取状态值。如果 kube 控制器无法读取节点状态值，它会在配置的时间后丢失与该节点联系。默认行为是：

control plane 上的节点控制器将节点健康状况更新为 Unhealthy，并奖节点 Ready 的条件标记为 'Unknown'。
因此，调度程序会停止将 pod 调度到该节点。
Node Lifecycle Controller 添加了一个 node.kubernetes.io/unreachable 污点，对节点具有 NoExecute 效果，默认在五分钟后调度节点上的任何 pod 进行驱除。

如果您的网络容易出现延迟问题，尤其是在网络边缘中有节点时，此行为可能会造成问题。在某些情况下，Kubernetes Controller Manager 可能会因为网络延迟而从健康的节点接收更新。Kubelet 会从节点中驱除 pod，即使节点处于健康状态。

要避免这个问题，您可以使用 worker 延迟配置集调整 kubelet 和 Kubernetes Controller Manager 在执行操作前等待状态更新的频率。如果在控制平面和 worker 节点间存在网络延迟，worker 节点没有处于最近状态，这个调整有助于集群可以正常工作。

这些 worker 延迟配置集包含预定义的三组参数，它们带有经过仔细调优的值，以控制集群对增加的延迟进行适当地响应。用户不需要手动进行实验以查找最佳值。

您可在安装集群时配置 worker 延迟配置集，或当您发现集群网络中的延迟增加时。

5.4.1. 了解 worker 延迟配置集

worker 延迟配置集带有四个不同的、包括经过仔细调优的参数的类别。实现这些值的四个参数是 node-status-update-frequency、node-monitor-grace-period、default-not-ready-toleration-seconds 和 default-unreachable-toleration-seconds。这些参数可让您使用这些值来控制集群对延迟问题的响应，而无需手动确定最佳值。

重要

不支持手动设置这些参数。参数设置不正确会影响集群的稳定性。

所有 worker 延迟配置集配置以下参数：

node-status-update-frequency: 指定 kubelet 将节点状态发布到 API 服务器的频率。
node-monitor-grace-period: 指定 Kubernetes Controller Manager 在节点不健康前等待更新的时间（以秒为单位），并将 node.kubernetes.io/not-ready 或 node.kubernetes.io/unreachable 污点添加到节点。
default-not-ready-toleration-seconds: 指定在标记节点不健康后，Kube API Server Operator 在从该节点驱除 pod 前等待的时间（以秒为单位）。
default-unreachable-toleration-seconds: 指定在节点无法访问后，Kube API Server Operator 在从该节点驱除 pod 前等待的时间（以秒为单位）。

以下 Operator 监控 worker 延迟配置集的更改并相应地响应：

Machine Config Operator (MCO) 更新 worker 节点上的 node-status-update-frequency 参数。
Kubernetes Controller Manager 更新 control plane 节点上的 node-monitor-grace-period 参数。
Kubernetes API Server Operator 更新 control plane 节点上的 default-not-ready-toleration-seconds 和 default-unreachable-toleration-seconds 参数。

虽然默认配置在大多数情况下可以正常工作，但 OpenShift Container Platform 会为网络遇到比通常更高的延迟的情况提供两个其他 worker 延迟配置集。以下部分描述了三个 worker 延迟配置集：

默认 worker 延迟配置集

使用 Default 配置集时，每个 Kubelet 每 10 秒更新其状态(node-status-update-frequency)。Kube Controller Manager 每 5 秒检查 Kubelet 的状态(node-monitor-grace-period)。

在认为 Kubelet 不健康前，Kubernetes Controller Manager 会等待 40 秒以获取来自 Kubelet 的状态更新。如果没有可用于 Kubernetes Controller Manager 的使用状态，它会使用 node.kubernetes.io/not-ready 或 node.kubernetes.io/unreachable 污点标记节点，并驱除该节点上的 pod。

如果该节点上的 pod 具有 NoExecute 污点，则 pod 会根据 tolerationSeconds 运行。如果 pod 没有污点，它将在 300 秒内被驱除(default-not-ready-toleration-seconds 和 Kube API Server的 default-unreachable-toleration-seconds 设置)。

profile	组件	参数	值
Default（默认）	kubelet	`node-status-update-frequency`	10s
	kubelet Controller Manager	`node-monitor-grace-period`	40s
	Kubernetes API Server Operator	`default-not-ready-toleration-seconds`	300s
	Kubernetes API Server Operator	`default-unreachable-toleration-seconds`	300s

中型 worker 延迟配置集

如果网络延迟比通常稍高，则使用 MediumUpdateAverageReaction 配置集。

MediumUpdateAverageReaction 配置集减少了 kubelet 更新频率为 20 秒，并将 Kubernetes Controller Manager 等待这些更新的时间更改为 2 分钟。该节点上的 pod 驱除周期会减少到 60 秒。如果 pod 具有 tolerationSeconds 参数，则驱除会等待该参数指定的周期。

Kubernetes Controller Manager 会先等待 2 分钟时间，才会认为节点不健康。另一分钟后，驱除过程会启动。

profile	组件	参数	值
MediumUpdateAverageReaction	kubelet	`node-status-update-frequency`	20s
	kubelet Controller Manager	`node-monitor-grace-period`	2m
	Kubernetes API Server Operator	`default-not-ready-toleration-seconds`	60s
	Kubernetes API Server Operator	`default-unreachable-toleration-seconds`	60s

低 worker 延迟配置集

如果网络延迟非常高，请使用 LowUpdateSlowReaction 配置集。

LowUpdateSlowReaction 配置集将 kubelet 更新频率减少为 1 分钟，并将 Kubernetes Controller Manager 等待这些更新的时间更改为 5 分钟。该节点上的 pod 驱除周期会减少到 60 秒。如果 pod 具有 tolerationSeconds 参数，则驱除会等待该参数指定的周期。

Kubernetes Controller Manager 在认为节点不健康前会等待 5 分钟。另一分钟后，驱除过程会启动。

profile	组件	参数	值
LowUpdateSlowReaction	kubelet	`node-status-update-frequency`	1m
	kubelet Controller Manager	`node-monitor-grace-period`	5m
	Kubernetes API Server Operator	`default-not-ready-toleration-seconds`	60s
	Kubernetes API Server Operator	`default-unreachable-toleration-seconds`	60s

5.4.2. 使用和更改 worker 延迟配置集

要更改 worker 延迟配置集以处理网络延迟，请编辑 node.config 对象以添加配置集的名称。当延迟增加或减少时，您可以随时更改配置集。

您必须一次移动一个 worker 延迟配置集。例如，您无法直接从 Default 配置集移到 LowUpdateSlowReaction worker 延迟配置集。您必须首先从 Default worker 延迟配置集移到 MediumUpdateAverageReaction 配置集，然后再移到 LowUpdateSlowReaction。同样，当返回到 Default 配置集时，您必须首先从低配置集移到中配置集，然后移到 Default。

注意

您还可以在安装 OpenShift Container Platform 集群时配置 worker 延迟配置集。

流程

将默认的 worker 延迟配置集改为：

中 worke worker 延迟配置集：

编辑 node.config 对象：
```
$ oc edit nodes.config/cluster
```

添加 spec.workerLatencyProfile: MediumUpdateAverageReaction ：

node.config 对象示例

apiVersion: config.openshift.io/v1
kind: Node
metadata:
  annotations:
    include.release.openshift.io/ibm-cloud-managed: "true"
    include.release.openshift.io/self-managed-high-availability: "true"
    include.release.openshift.io/single-node-developer: "true"
    release.openshift.io/create-only: "true"
  creationTimestamp: "2022-07-08T16:02:51Z"
  generation: 1
  name: cluster
  ownerReferences:
  - apiVersion: config.openshift.io/v1
    kind: ClusterVersion
    name: version
    uid: 36282574-bf9f-409e-a6cd-3032939293eb
  resourceVersion: "1865"
  uid: 0c0f7a4c-4307-4187-b591-6155695ac85b
spec:
  workerLatencyProfile: MediumUpdateAverageReaction 1

# ...

1: 指定中 worker 延迟策略。

随着更改被应用，每个 worker 节点上的调度都会被禁用。

可选：改为低 worker 延迟配置集：

编辑 node.config 对象：
```
$ oc edit nodes.config/cluster
```

将 spec.workerLatencyProfile 值更改为 LowUpdateSlowReaction ：

node.config 对象示例

apiVersion: config.openshift.io/v1
kind: Node
metadata:
  annotations:
    include.release.openshift.io/ibm-cloud-managed: "true"
    include.release.openshift.io/self-managed-high-availability: "true"
    include.release.openshift.io/single-node-developer: "true"
    release.openshift.io/create-only: "true"
  creationTimestamp: "2022-07-08T16:02:51Z"
  generation: 1
  name: cluster
  ownerReferences:
  - apiVersion: config.openshift.io/v1
    kind: ClusterVersion
    name: version
    uid: 36282574-bf9f-409e-a6cd-3032939293eb
  resourceVersion: "1865"
  uid: 0c0f7a4c-4307-4187-b591-6155695ac85b
spec:
  workerLatencyProfile: LowUpdateSlowReaction 1

# ...

1: 指定使用低 worker 延迟策略。

随着更改被应用，每个 worker 节点上的调度都会被禁用。

验证

当所有节点都返回到 Ready 条件时，您可以使用以下命令查看 Kubernetes Controller Manager 以确保应用它：

$ oc get KubeControllerManager -o yaml | grep -i workerlatency -A 5 -B 5

输出示例

# ...
    - lastTransitionTime: "2022-07-11T19:47:10Z"
      reason: ProfileUpdated
      status: "False"
      type: WorkerLatencyProfileProgressing
    - lastTransitionTime: "2022-07-11T19:47:10Z" 1
      message: all static pod revision(s) have updated latency profile
      reason: ProfileUpdated
      status: "True"
      type: WorkerLatencyProfileComplete
    - lastTransitionTime: "2022-07-11T19:20:11Z"
      reason: AsExpected
      status: "False"
      type: WorkerLatencyProfileDegraded
    - lastTransitionTime: "2022-07-11T19:20:36Z"
      status: "False"
# ...

1: 指定配置集被应用并激活。

要将中配置集改为默认，或将默认改为中，编辑 node.config 对象，并将 spec.workerLatencyProfile 参数设置为适当的值。

5.4. 使用 worker 延迟配置集提高高延迟环境中的集群稳定性

5.4.1. 了解 worker 延迟配置集

5.4.2. 使用和更改 worker 延迟配置集

学习

尝试、购买和销售

社区

关于红帽文档

让开源更具包容性

關於紅帽

Red Hat legal and privacy links

Red Hat legal and privacy links