×

如果集群管理员已执行延迟测试以进行平台验证,他们可以发现需要调整集群的操作以确保在高延迟情况下保持稳定性。集群管理员只需要更改一个记录在文件中的参数,该参数控制四个影响监控进程读取状态和解释集群健康状况的参数。仅更改一个参数即可轻松、可支持地进行集群调整。

Kubelet 进程是监控集群健康状况的起点。Kubelet 为 OpenShift Container Platform 集群中的所有节点设置状态值。Kubernetes 控制器管理器 (kube controller) 默认每 10 秒读取一次状态值。如果kube controller无法读取节点状态值,则在配置的时间段后会失去与该节点的联系。默认行为是

  1. 控制平面上的节点控制器将节点健康状况更新为不健康,并将节点就绪条件标记为未知

  2. 作为响应,调度程序停止将 Pod 调度到该节点。

  3. 节点生命周期控制器添加一个具有NoExecute效果的node.kubernetes.io/unreachable污点到节点,并默认在五分钟后调度节点上的任何 Pod 进行驱逐。

如果您的网络容易出现延迟问题,尤其是在网络边缘有节点的情况下,此行为可能会导致问题。在某些情况下,由于网络延迟,Kubernetes 控制器管理器可能无法从健康节点接收更新。即使节点处于健康状态,Kubelet也会从节点中驱逐 Pod。

为了避免此问题,您可以使用工作节点延迟配置文件来调整Kubelet和 Kubernetes 控制器管理器在采取行动之前等待状态更新的频率。这些调整有助于确保您的集群在控制平面和工作节点之间的网络延迟不是最佳的情况下正常运行。

这些工作节点延迟配置文件包含三组参数,这些参数已预定义并经过精心调整的值,以控制集群对增加的延迟的反应。无需手动实验查找最佳值。

您可以在安装集群时或在任何时候注意到集群网络中的延迟增加时配置工作节点延迟配置文件。

了解工作节点延迟配置文件

工作节点延迟配置文件包含四类经过仔细调整的参数。实现这些值的四个参数是node-status-update-frequencynode-monitor-grace-perioddefault-not-ready-toleration-secondsdefault-unreachable-toleration-seconds。这些参数可以使用允许您控制集群对延迟问题的反应的值,而无需使用手动方法确定最佳值。

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

所有工作节点延迟配置文件都配置以下参数

node-status-update-frequency

指定 kubelet 向 API 服务器发送节点状态的频率。

node-monitor-grace-period

指定 Kubernetes Controller Manager 在标记节点为不健康状态并向节点添加node.kubernetes.io/not-readynode.kubernetes.io/unreachable taint 之前,等待 kubelet 更新的时间(秒)。

default-not-ready-toleration-seconds

指定 Kube API 服务器操作员在将节点标记为不健康状态后,等待多长时间(秒)再从该节点驱逐 Pod。

default-unreachable-toleration-seconds

指定 Kube API 服务器操作员在将节点标记为不可达后,等待多长时间(秒)再从该节点驱逐 Pod。

以下操作符监控工作节点延迟配置文件的变化并相应地做出响应

  • 机器配置操作符 (MCO) 更新工作节点上的node-status-update-frequency 参数。

  • Kubernetes Controller Manager 更新控制平面节点上的node-monitor-grace-period 参数。

  • Kubernetes API 服务器操作符更新控制平面节点上的default-not-ready-toleration-secondsdefault-unreachable-toleration-seconds 参数。

虽然默认配置在大多数情况下都能正常工作,但 OpenShift Container Platform 还为网络延迟高于平常的情况提供了另外两种工作节点延迟配置文件。以下部分描述了这三种工作节点延迟配置文件。

默认工作节点延迟配置文件

使用Default 配置文件时,每个Kubelet 每 10 秒更新一次其状态 (node-status-update-frequency)。Kube Controller Manager 每 5 秒检查一次Kubelet 的状态。

Kubernetes Controller Manager 等待 40 秒 (node-monitor-grace-period) 获取Kubelet 的状态更新,之后才会认为Kubelet 不健康。如果 Kubernetes Controller Manager 没有收到状态更新,则会用node.kubernetes.io/not-readynode.kubernetes.io/unreachable taint 标记该节点,并驱逐该节点上的 Pod。

如果 Pod 位于带有NoExecute taint 的节点上,则 Pod 运行时间取决于tolerationSeconds。如果节点没有 taint,则会在 300 秒内 (Kube API Serverdefault-not-ready-toleration-secondsdefault-unreachable-toleration-seconds 设置) 被驱逐。

配置文件 组件 参数

默认

kubelet

node-status-update-frequency

10s

Kubelet Controller Manager

node-monitor-grace-period

40s

Kubernetes API Server 操作符

default-not-ready-toleration-seconds

300s

Kubernetes API Server 操作符

default-unreachable-toleration-seconds

300s

中等工作节点延迟配置文件

如果网络延迟略高于平常,请使用MediumUpdateAverageReaction 配置文件。

MediumUpdateAverageReaction 配置文件将 kubelet 更新频率降低到 20 秒,并将 Kubernetes Controller Manager 等待这些更新的时间更改为 2 分钟。该节点上 Pod 的驱逐时间缩短为 60 秒。如果 Pod 具有tolerationSeconds 参数,则驱逐将等待该参数指定的时间。

Kubernetes Controller Manager 等待 2 分钟才会将节点视为不健康。再过一分钟,驱逐过程开始。

配置文件 组件 参数

MediumUpdateAverageReaction

kubelet

node-status-update-frequency

20s

Kubelet Controller Manager

node-monitor-grace-period

2m

Kubernetes API Server 操作符

default-not-ready-toleration-seconds

60s

Kubernetes API Server 操作符

default-unreachable-toleration-seconds

60s

低工作节点延迟配置文件

如果网络延迟极高,请使用LowUpdateSlowReaction 配置文件。

LowUpdateSlowReaction 配置文件将 kubelet 更新频率降低到 1 分钟,并将 Kubernetes Controller Manager 等待这些更新的时间更改为 5 分钟。该节点上 Pod 的驱逐时间缩短为 60 秒。如果 Pod 具有tolerationSeconds 参数,则驱逐将等待该参数指定的时间。

Kubernetes Controller Manager 等待 5 分钟才会将节点视为不健康。再过一分钟,驱逐过程开始。

配置文件 组件 参数

LowUpdateSlowReaction

kubelet

node-status-update-frequency

1m

Kubelet Controller Manager

node-monitor-grace-period

5m

Kubernetes API Server 操作符

default-not-ready-toleration-seconds

60s

Kubernetes API Server 操作符

default-unreachable-toleration-seconds

60s

在集群创建时实现工作节点延迟配置文件

要编辑安装程序的配置,首先使用命令openshift-install create manifests 创建默认节点清单和其他清单 YAML 文件。在添加workerLatencyProfile 之前,必须存在此文件结构。您安装所在的平台可能会有不同的要求。请参阅您特定平台的文档的“安装”部分。

必须按照以下顺序将workerLatencyProfile添加到清单中

  1. 创建构建集群所需的清单,使用适合您安装的文件夹名称。

  2. 创建 YAML 文件以定义config.node。该文件必须位于manifests 目录中。

  3. 首次在清单中定义workerLatencyProfile 时,请在集群创建时指定任何配置文件:DefaultMediumUpdateAverageReactionLowUpdateSlowReaction

验证
  • 这是一个清单创建示例,显示了清单文件中spec.workerLatencyProfileDefault

    $ openshift-install create manifests --dir=<cluster-install-dir>
  • 编辑清单并添加值。在此示例中,我们使用vi 来显示一个带有已添加“Default”workerLatencyProfile 值的示例清单文件

    $ vi <cluster-install-dir>/manifests/config-node-default-profile.yaml
    示例输出
    apiVersion: config.openshift.io/v1
    kind: Node
    metadata:
    name: cluster
    spec:
    workerLatencyProfile: "Default"

使用和更改工作节点延迟配置文件

要更改工作节点延迟配置文件以处理网络延迟,请编辑node.config 对象以添加配置文件的名称。随着延迟的增加或减少,您可以随时更改配置文件。

您必须一次移动一个工作节点延迟配置文件。例如,您不能直接从Default 配置文件移动到LowUpdateSlowReaction 工作节点延迟配置文件。您必须首先从Default 工作节点延迟配置文件移动到MediumUpdateAverageReaction 配置文件,然后移动到LowUpdateSlowReaction。同样,当返回到Default 配置文件时,您必须首先从低配置文件移动到中等配置文件,然后移动到Default

您还可以在安装 OpenShift Container Platform 集群时配置工作节点延迟配置文件。

步骤

要从默认工作节点延迟配置文件移动

  1. 移动到中等工作节点延迟配置文件

    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 指定中等工作节点延迟策略。

      在应用更改时,每个工作节点上的调度都将被禁用。

  2. 可选:移动到低工作节点延迟配置文件

    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 指定使用低工作节点延迟策略。

在应用更改时,每个工作节点上的调度都将被禁用。

验证
  • 当所有节点返回到就绪状态时,您可以使用以下命令查看 Kubernetes 控制器管理器以确保已应用该策略。

    $ 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参数设置为相应的值。

显示workerLatencyProfile结果值的示例步骤

您可以使用以下命令显示workerLatencyProfile中的值。

验证
  1. 检查Kube API服务器输出的default-not-ready-toleration-secondsdefault-unreachable-toleration-seconds字段。

    $ oc get KubeAPIServer -o yaml | grep -A 1 default-
    示例输出
    default-not-ready-toleration-seconds:
    - "300"
    default-unreachable-toleration-seconds:
    - "300"
  2. 检查Kube控制器管理器中node-monitor-grace-period字段的值。

    $ oc get KubeControllerManager -o yaml | grep -A 1 node-monitor
    示例输出
    node-monitor-grace-period:
    - 40s
  3. 检查Kubelet中的nodeStatusUpdateFrequency值。在调试shell中将目录/host设置为根目录。通过将根目录更改为/host,您可以运行主机可执行路径中包含的二进制文件。

    $ oc debug node/<worker-node-name>
    $ chroot /host
    # cat /etc/kubernetes/kubelet.conf|grep nodeStatusUpdateFrequency
    示例输出
      “nodeStatusUpdateFrequency”: “10s”

这些输出验证了工作节点延迟配置文件的一组计时变量。