支持控制台（Console）开发人员开始试用联系人

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

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

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

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

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

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

这些 worker 延迟配置集包含三组参数，它们被预定义了 tuned 值，以控制集群的反应以增加延迟。不需要实验性地手动查找最佳值。

您可在安装集群时配置 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 的状态。

在考虑 Kubelet 不健康前，Kubernetes Controller Manager 会等待 40 秒(node-monitor-grace-period)从 Kubelet 进行状态更新。如果没有可用于 Kubernetes Controller Manager 的使用状态，它会使用 node.kubernetes.io/not-ready 或 node.kubernetes.io/unreachable 污点标记节点，并驱除该节点上的 pod。

如果 pod 位于具有 NoExecute 污点的节点上，则 pod 根据 tolerationSeconds 运行。如果节点没有污点，它将以 300 秒( Kube API Server的default-not-ready-toleration-seconds 和 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 延迟配置集改为：

  1. 中 worke worker 延迟配置集：

    1. 编辑 node.config 对象： 

      $ oc edit nodes.config/cluster

    2. 添加 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 节点上的调度都会被禁用。

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

    1. 编辑 node.config 对象： 

      $ oc edit nodes.config/cluster

    2. 将 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 参数设置为适当的值。

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

© 2024 Red Hat, Inc.