8.8. 使用 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 延迟配置集包含三组参数,它们被预定义了 tuned 值,以控制集群的反应以增加延迟。不需要实验性地手动查找最佳值。
您可在安装集群时配置 worker 延迟配置集,或当您发现集群网络中的延迟增加时。
8.8.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
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
8.8.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
参数设置为适当的值。