补救、隔离和维护

Workload Availability for Red Hat OpenShift 23.2

工作负载可用性补救、隔离和维护

Red Hat Customer Content Services

摘要

有关工作负载可用性操作器及其用法的信息

前言

为 Red Hat OpenShift 文档提供有关工作负载可用性的反馈

我们感谢您对我们文档的反馈。让我们了解如何改进它。要做到这一点:

  1. 进入 JIRA 网站。
  2. Summary 字段中输入描述性标题。
  3. Description 字段中输入您对改进的建议。包括文档相关部分的链接。
  4. Reporter 字段中输入您的用户名。
  5. Affects Version/s 字段中输入受影响的版本。
  6. 点对话框底部的 Create

第 1 章 关于节点补救、隔离和维护

硬件是 imperfect,软件包含 bug。当节点级别的故障(如内核挂起或网络接口控制器(NIC))失败时,集群所需的工作不会减少,并且受影响节点的工作负载需要在哪里重启。但是,一些工作负载(如 ReadWriteOnce (RWO) 卷和 StatefulSets)可能需要最少的语义。

影响这些工作负载的风险、损坏或两者的故障。在启动恢复工作负载(称为 补救 和理想情况)之前,确保节点达到安全状态(称为 隔离 )。

并不总是依赖于管理员干预来确认节点和工作负载的真正状态。为了便于此类干预,Red Hat OpenShift 提供多个组件来自动化失败检测、隔离和修复。

1.1. 自助服务修复

Self Node Remediation Operator 是一个 Red Hat OpenShift 附加组件 operator,它实现了隔离的外部系统,并补救重启不健康的节点并删除资源,如 Pod 和 VolumeAttachments。重启可确保工作负载被隔离,资源删除会加快重新调度受影响工作负载。与其他外部系统不同,自助节点修复不需要任何管理界面,如智能平台管理接口 (IPMI) 或用于节点置备的 API。

失败的检测系统可以使用自助服务修复,如 Machine Health Check 或 Node Health Check。

1.2. 机器健康检查

Machine Health Check 使用 Red Hat OpenShift 内置故障检测、隔离和补救系统,用于监控机器的状态以及节点状况。机器健康检查可以被配置为触发外部隔离和修复系统,如自助节点修复。

1.3. 节点健康检查

Node Health Check Operator 是一个 Red Hat OpenShift 附加组件 operator,它实现了一个监控节点状况的失败检测系统。它没有内置的隔离或补救系统,因此必须使用提供此类功能的外部系统进行配置。默认情况下,它被配置为使用 Self Node Remediation 系统。

1.4. 节点维护

管理员面临需要中断集群的情况,例如替换驱动器、RAM 或 NIC。

在此维护之前,应该对受影响的节点进行封锁并排空。当节点被封锁时,无法将新的工作负载调度到该节点上。当节点排空时,为了避免或最小化停机时间,受影响节点上的工作负载将传送到其他节点。

虽然此维护可以使用命令行工具实现,但 Node Maintenance Operator 提供了使用自定义资源来实现此目的的声明方法。当节点存在此类资源时,Operator 会封锁并排空节点,直到资源被删除为止。

第 2 章 使用自节点修复

您可以使用 Self Node Remediation Operator 自动重新引导不健康的节点。此补救策略可最小化有状态应用程序和 ReadWriteOnce (RWO) 卷的停机时间,并在发生临时故障时恢复计算容量。

2.1. 关于自助服务修复 Operator

Self Node Remediation Operator 在集群节点上运行,并重启被识别为不健康的节点。Operator 使用 MachineHealthCheckNodeHealthCheck 控制器来检测集群中节点的健康状态。当节点识别为不健康时,MachineHealthCheckNodeHealthCheck 资源会创建 SelfNodeRemediation 自定义资源(CR),这会触发 Self Node Remediation Operator。

SelfNodeRemediation CR 类似于以下 YAML 文件:

apiVersion: self-node-remediation.medik8s.io/v1alpha1
kind: SelfNodeRemediation
metadata:
  name: selfnoderemediation-sample
  namespace: openshift-operators
spec:
  remediationStrategy: <remediation_strategy> 1
status:
  lastError: <last_error_message> 2
1
指定节点的补救策略。
2
显示补救过程中发生的最后错误。当补救成功或没有发生错误时,字段会留空。

Self Node Remediation Operator 最小化有状态应用程序的停机时间,并在出现临时故障时恢复计算容量。无论 IPMI 或 API 等管理界面如何置备节点,都可使用此 Operator 来置备节点,无论集群安装类型是什么,如安装程序置备的基础架构或用户置备的基础架构。

2.1.1. 关于 watchdog 设备

watchdog 设备可以是以下任意一种:

  • 独立电源的硬件设备
  • 与它们控制的主机共享电源的硬件设备
  • 软件或 softdog中实施的虚拟设备

硬件 watchdog 和 softdog 设备分别具有电子计时器和软件计时器。这些 watchdog 设备用于确保在检测到错误条件时机器进入安全状态。集群需要重复重置 watchdog 定时器以证明它处于健康状态。此计时器可能会因为出现错误条件而造成问题,如死锁、CPU 不足以及网络或磁盘访问的丢失。如果计时器过期,watchdog 设备会假设发生了错误,设备会触发强制重置节点。

硬件 watchdog 设备比 softdog 设备更可靠。

2.1.1.1. 了解 watchdog 设备的自助服务修复 Operator 行为

Self Node Remediation Operator 根据存在的 watchdog 设备决定补救策略。

如果配置了硬件 watchdog 设备并可用,Operator 会使用它进行补救。如果没有配置硬件 watchdog 设备,Operator 会启用并使用 softdog 设备进行补救。

如果既不支持 watchdog 设备,无论是系统或配置,Operator 都会使用软件重启来修复节点。

2.2. control plane 隔离

在早期版本中,您可以在 worker 节点上启用自节点修复和 Node Health Check。如果节点失败,您现在可以在 control plane 节点上遵循补救策略。

在两种主要场景中进行自助服务修复。

  • API 服务器连接

    • 在这种情况下,要修复的 control plane 节点不会被隔离。它可以直接连接到 API 服务器,或者可以通过 worker 节点或 control-plane 节点间接连接到 API 服务器,这些节点直接连接到 API 服务器。
    • 当有 API 服务器连接时,只有在 Node Health Check Operator 为节点创建了 SelfNodeRemediation 自定义资源(CR)时,才会修复 control plane 节点。
  • 没有 API 服务器连接

    • 在这种情况下,要修复的 control plane 节点与 API 服务器隔离。节点无法直接连接或间接连接到 API 服务器。
    • 如果没有 API 服务器连接,则 control plane 节点将按照以下步骤进行修复:

      • 使用大多数对等 worker 节点检查 control plane 节点的状态。如果无法访问大多数对等 worker 节点,则会进一步分析该节点。

        • 自我诊断 control plane 节点的状态

          • 如果通过自我诊断,则不会执行任何操作。
          • 如果自我诊断失败,则该节点将被隔离并修复。
          • 目前支持的自诊断是使用 opt in 配置检查 kubelet 服务状态,以及检查端点的可用性。
      • 如果节点没有管理与大多数 worker 对等点通信,请检查 control plane 节点与其他 control plane 节点的连接。如果节点可以与任何其他 control plane peer 通信,则不会执行任何操作。否则,节点将被隔离并修复。

2.3. 使用 web 控制台安装 Self Node Remediation Operator

您可以使用 Red Hat OpenShift Web 控制台安装 Self Node Remediation Operator。

注意

Node Health Check Operator 还将 Self Node Remediation Operator 安装为默认的补救提供程序。

先决条件

  • 以具有 cluster-admin 特权的用户身份登录。

流程

  1. 在 Red Hat OpenShift Web 控制台中导航至 OperatorsOperatorHub
  2. 从可用的 Operator 列表中选择 Self Node Remediation Operator,然后点 Install
  3. 保留安装模式命名空间的默认选择,以确保将 Operator 安装到 openshift-operators 命名空间中。
  4. Install

验证

确认安装成功:

  1. 进入到 OperatorsInstalled Operators 页面。
  2. 检查 Operator 是否安装在 openshift-operators 命名空间中,其状态是否为 Succeeded

如果 Operator 没有成功安装:

  1. 导航到 OperatorsInstalled Operators 页面,并检查 Status 列中是否有任何错误或故障。
  2. 进入到 WorkloadsPods 页面,检查 openshift-operators 项目中的 self-node-remediation-controller-manager pod 和 self-node-remediation-ds pod 的日志。

2.4. 使用 CLI 安装自助服务 Operator

您可以使用 OpenShift CLI(oc)安装 Self Node Remediation Operator。

您可以在自己的命名空间中或 openshift-operators 命名空间中安装 Self Node Remediation Operator。

要在您自己的命名空间中安装 Operator,请按照以下步骤执行。

要在 openshift-operators 命名空间中安装 Operator,请跳至步骤 3,因为需要新的 Namespace 自定义资源(CR)和 OperatorGroup CR 的步骤。

先决条件

  • 安装 OpenShift CLI(oc)。
  • 以具有 cluster-admin 特权的用户身份登录。

流程

  1. 为 Self Node Remediation Operator 创建 Namespace 自定义资源(CR):

    1. 定义 Namespace CR 并保存 YAML 文件,如 self-node-remediation-namespace.yaml

      apiVersion: v1
      kind: Namespace
      metadata:
        name: self-node-remediation
    2. 要创建 Namespace CR,请运行以下命令:

      $ oc create -f self-node-remediation-namespace.yaml
  2. 创建 OperatorGroup CR:

    1. 定义 OperatorGroup CR 并保存 YAML 文件,如 self-node-remediation-operator-group.yaml

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: self-node-remediation-operator
        namespace: self-node-remediation
    2. 要创建 OperatorGroup CR,请运行以下命令:

      $ oc create -f self-node-remediation-operator-group.yaml
  3. 创建一个 Subscription CR:

    1. 定义 Subscription CR 并保存 YAML 文件,如 self-node-remediation-subscription.yaml

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
          name: self-node-remediation-operator
          namespace: self-node-remediation 1
      spec:
          channel: stable
          installPlanApproval: Manual 2
          name: self-node-remediation-operator
          source: redhat-operators
          sourceNamespace: openshift-marketplace
          package: self-node-remediation
      1
      指定要安装 Self Node Remediation Operator 的命名空间。要在 openshift-operators 命名空间中安装 Self Node Remediation Operator,在 Subscription CR 中指定 openshift-operators
      2
      如果您的指定版本被目录中的后续版本取代,则将批准策略设置为 Manual。此计划阻止自动升级到更新的版本,且需要在启动 CSV 可以完成安装前手动批准。
    2. 要创建 Subscription CR,请运行以下命令:

      $ oc create -f self-node-remediation-subscription.yaml

验证

  1. 检查 CSV 资源来验证安装是否成功:

    $ oc get csv -n self-node-remediation

    输出示例

    NAME                               DISPLAY                          VERSION   REPLACES   PHASE
    self-node-remediation.v.0.6.0      Self Node Remediation Operator   v.0.6.0              Succeeded

  2. 验证 Self Node Remediation Operator 是否正在运行:

    $ oc get deploy -n self-node-remediation

    输出示例

    NAME                                        READY   UP-TO-DATE   AVAILABLE   AGE
    self-node-remediation-controller-manager    1/1     1            1           28h

  3. 验证 Self Node Remediation Operator 是否已创建 SelfNodeRemediationConfig CR:

    $ oc get selfnoderemediationconfig -n self-node-remediation

    输出示例

    NAME                           AGE
    self-node-remediation-config   28h

  4. 验证每个自节点补救 pod 是否已调度并在每个 worker 节点和 control plane 节点上运行:

    $ oc get daemonset -n self-node-remediation

    输出示例

    NAME                      DESIRED  CURRENT  READY  UP-TO-DATE  AVAILABLE  NODE SELECTOR  AGE
    self-node-remediation-ds  6        6        6      6           6          <none>         28h

2.5. 配置自节点修复 Operator

Self Node Remediation Operator 创建 SelfNodeRemediationConfig CR 和 SelfNodeRemediationTemplate 自定义资源定义(CRD)。

2.5.1. 了解 Self Node Remediation Operator 配置

Self Node Remediation Operator 创建了名为 self-node-remediation-configSelfNodeRemediationConfig CR。CR 在 Self Node Remediation Operator 的命名空间中创建。

SelfNodeRemediationConfig CR 的更改重新创建 Self Node Remediation 守护进程集。

SelfNodeRemediationConfig CR 类似于以下 YAML 文件:

apiVersion: self-node-remediation.medik8s.io/v1alpha1
kind: SelfNodeRemediationConfig
metadata:
  name: self-node-remediation-config
  namespace: openshift-operators
spec:
  safeTimeToAssumeNodeRebootedSeconds: 180 1
  watchdogFilePath: /dev/watchdog 2
  isSoftwareRebootEnabled: true 3
  apiServerTimeout: 15s 4
  apiCheckInterval: 5s 5
  maxApiErrorThreshold: 3 6
  peerApiServerTimeout: 5s 7
  peerDialTimeout: 5s 8
  peerRequestTimeout: 5s 9
  peerUpdateInterval: 15m 10
1
指定 Operator 在恢复不健康节点上运行的受影响工作负载前等待的时间。在仍然在故障节点上运行时启动替换 pod 可能会导致数据崩溃并违反运行一次语义。要防止这种情况的发生,Operator 忽略低于 ApiServerTimeout,ApiCheckInterval,maxApiErrorThreshold,peerDialTimeout, 和 peerRequestTimeout 字段计算的值。
2
指定节点中 watchdog 设备的文件路径。如果您为 watchdog 设备输入了一个错误的路径,则 Self Node Remediation Operator 会自动检测到 softdog 设备路径。

如果 watchdog 设备不可用,则 SelfNodeRemediationConfig CR 将使用软件重启。

3
指定是否启用不健康节点的软件重启。默认情况下,SoftwareRebootEnabled 的值设置为 true。要禁用软件重启,请将参数设置为 false
4
指定检查每个 API 服务器的连接的超时持续时间。此超过了此持续时间,Operator 会启动补救。超时持续时间必须大于或等于 10 毫秒。
5
指定检查每个 API 服务器的连接的频率。超时持续时间必须大于或等于 1 秒。
6
指定一个阈值。达到这个阈值后,节点开始联系其同级服务器。阈值必须大于或等于 1 秒。
7
指定对等对等服务器连接 API 服务器的超时时间。超时持续时间必须大于或等于 10 毫秒。
8
指定与对等连接建立超时的持续时间。超时持续时间必须大于或等于 10 毫秒。
9
指定超时从对等点获得响应的时长。超时持续时间必须大于或等于 10 毫秒。
10
指定更新对等信息的频率,如 IP 地址。超时持续时间必须大于或等于 10 秒。
注意

您可以编辑由 Self Node Remediation Operator 创建的 self-node-remediation-config CR。但是,当您尝试为 Self Node Remediation Operator 创建新 CR 时,日志中会显示以下信息:

controllers.SelfNodeRemediationConfig
ignoring selfnoderemediationconfig CRs that are not named 'self-node-remediation-config'
or not in the namespace of the operator:
'openshift-operators' {"selfnoderemediationconfig":
"openshift-operators/selfnoderemediationconfig-copy"}

2.5.2. 了解自助节点修复模板配置

Self Node Remediation Operator 还创建 SelfNodeRemediationTemplate 自定义资源定义(CRD)。此 CRD 为节点定义补救策略。可用的补救策略如下:

ResourceDeletion
此补救策略移除节点上的 pod 和关联的卷附加,而不是删除节点对象。此策略可以更快地恢复工作负载。ResourceDeletion 是默认的补救策略。
OutOfServiceTaint
此补救策略隐式会导致在节点上删除 pod 和关联的卷附加,而不是移除节点对象。它通过将 OutOfServiceTaint 策略放在节点上来实现此目的。此策略可以更快地恢复工作负载。自 OpenShift Container Platform 版本 4.13 起,此策略在技术预览上被支持,从 OpenShift Container Platform 版本 4.15 开始正式发布。

Self Node Remediation Operator 为策略 self-node-remediation-resource-deletion-template 创建 SelfNodeRemediationTemplate CR,其 ResourceDeletion 补救策略使用。

SelfNodeRemediationTemplate CR 类似于以下 YAML 文件:

apiVersion: self-node-remediation.medik8s.io/v1alpha1
kind: SelfNodeRemediationTemplate
metadata:
  creationTimestamp: "2022-03-02T08:02:40Z"
  name: self-node-remediation-<remediation_object>-deletion-template 1
  namespace: openshift-operators
spec:
  template:
    spec:
      remediationStrategy: <remediation_strategy>  2
1
根据补救策略指定补救模板的类型。将 <remediation_object> 替换为 resourcenode; 例如 self-node-remediation-resource-deletion-template
2
指定补救策略。补救策略是 ResourceDeletion

2.5.3. 对自节点修复 Operator 进行故障排除

2.5.3.1. 常规故障排除

问题
您需要使用自助服务修复 Operator 排除问题。
解决方案
检查 Operator 日志。

2.5.3.2. 检查守护进程集

问题
已安装 Self Node Remediation Operator,但守护进程集不可用。
解决方案
检查 Operator 日志中的错误或警告。

2.5.3.3. 失败的补救

问题
一个不健康的节点没有被修复。
解决方案

运行以下命令验证 selfNodeRemediation CR 是否已创建:

$ oc get snr -A

当节点处于不健康状态时,如果 MachineHealthCheck 控制器没有创建 SelfNodeRemediation CR,请检查 MachineHealthCheck 控制器的日志。此外,请确保 MachineHealthCheck CR 包含使用补救模板所需的规范。

如果创建了 SelfNodeRemediation CR,请确保其名称与不健康的节点或机器对象匹配。

2.5.3.4. 即使在卸载了 Operator 后,守护进程集和其他自节点修复 Operator 资源也存在

问题
即使卸载 Operator 后,也会存在 Self Node Remediation Operator 资源,如守护进程集、配置 CR 和补救模板 CR。
解决方案

要删除 Self Node Remediation Operator 资源,请运行以下命令来删除每种资源类型的资源:

$ oc delete ds <self-node-remediation-ds> -n <namespace>
$ oc delete snrc <self-node-remediation-config> -n <namespace>
$ oc delete snrt <self-node-remediation-template> -n <namespace>

2.5.4. 收集自节点修复 Operator 的数据

要收集有关自助服务修复 Operator 的调试信息,请使用 must-gather 工具。有关 Self Node Remediation Operator 的 must-gather 镜像的详情,请参考 收集有关特定功能的数据

2.5.5. 其他资源

第 3 章 使用机器健康检查修复节点

机器健康检查自动修复特定机器池中不健康的机器。

3.1. 关于机器健康检查

注意

您只能对使用 control plane 机器集的集群中的 control plane 机器应用机器健康检查。

要监控机器的健康状况,创建资源来定义控制器的配置。设置要检查的条件(例如,处于 NotReady 状态达到五分钟或 node-problem-detector 中显示了持久性状况),以及用于要监控的机器集合的标签。

监控 MachineHealthCheck 资源的控制器会检查定义的条件。如果机器无法进行健康检查,则会自动删除机器并创建一个机器来代替它。删除机器之后,您会看到机器被删除事件。

为限制删除机器造成的破坏性影响,控制器一次仅清空并删除一个节点。如果目标机器池中不健康的机器池中不健康的机器数量大于 maxUnhealthy 的值,则补救会停止,需要启用手动干预。

注意

请根据工作负载和要求仔细考虑超时。

  • 超时时间较长可能会导致不健康的机器上的工作负载长时间停机。
  • 超时时间太短可能会导致补救循环。例如,检查 NotReady 状态的超时时间必须足够长,以便机器能够完成启动过程。

要停止检查,请删除资源。

3.1.1. 部署机器健康检查时的限制

部署机器健康检查前需要考虑以下限制:

  • 只有机器集拥有的机器才可以由机器健康检查修复。
  • 如果机器的节点从集群中移除,机器健康检查会认为机器不健康,并立即修复机器。
  • 如果机器对应的节点在 nodeStartupTimeout 之后没有加入集群,则会修复机器。
  • 如果 Machine 资源阶段为 Failed,则会立即修复机器。

3.2. 配置机器健康检查以使用 Self Node Remediation Operator

使用以下步骤将 worker 或 control-plane 机器健康检查配置为使用 Self Node Remediation Operator 作为补救供应商。

注意

要使用 Self Node Remediation Operator 作为机器健康检查的补救供应商,机器必须在集群中有一个关联的节点。

先决条件

  • 安装 OpenShift CLI(oc)。
  • 以具有 cluster-admin 特权的用户身份登录。

流程

  1. 创建 SelfNodeRemediationTemplate CR:

    1. 定义 SelfNodeRemediationTemplate CR:

      apiVersion: self-node-remediation.medik8s.io/v1alpha1
      kind: SelfNodeRemediationTemplate
      metadata:
        namespace: openshift-machine-api
        name: selfnoderemediationtemplate-sample
      spec:
        template:
          spec:
            remediationStrategy: ResourceDeletion 1
      1
      指定补救策略。默认策略是 ResourceDeletion
    2. 要创建 SelfNodeRemediationTemplate CR,请运行以下命令:

      $ oc create -f <snrt-name>.yaml
  2. 创建或更新 MachineHealthCheck CR 以指向 SelfNodeRemediationTemplate CR:

    1. 定义或更新 MachineHealthCheck CR:

      apiVersion: machine.openshift.io/v1beta1
      kind: MachineHealthCheck
      metadata:
        name: machine-health-check
        namespace: openshift-machine-api
      spec:
        selector:
          matchLabels: 1
            machine.openshift.io/cluster-api-machine-role: "worker"
            machine.openshift.io/cluster-api-machine-type: "worker"
        unhealthyConditions:
        - type:    "Ready"
          timeout: "300s"
          status: "False"
        - type:    "Ready"
          timeout: "300s"
          status: "Unknown"
        maxUnhealthy: "40%"
        nodeStartupTimeout: "10m"
        remediationTemplate: 2
          kind: SelfNodeRemediationTemplate
          apiVersion: self-node-remediation.medik8s.io/v1alpha1
          name: selfnoderemediationtemplate-sample
      1
      选择机器健康检查是否为 worker 还是 control-plane 节点。标签也可以是用户定义的。
      2
      指定补救模板的详情。
    2. 要创建 MachineHealthCheck CR,请运行以下命令:

      $ oc create -f <mhc-name>.yaml
    3. 要更新 MachineHealthCheck CR,请运行以下命令:

      $ oc apply -f <mhc-name>.yaml

第 4 章 使用节点健康检查修复节点

您可以使用 Node Health Check Operator 来识别不健康的节点。Operator 使用 Self Node Remediation Operator 来修复不健康的节点。

如需有关 Self Node Remediation Operator 的更多信息,请参阅使用自节点修复 章节。

注意

由于 Red Hat OpenShift Service on AWS (ROSA)集群上存在预安装的机器健康检查,Node Health Check Operator 无法在此环境中正常工作。

4.1. 关于 Node Health Check Operator

Node Health Check Operator 检测到集群中的节点的健康状态。NodeHealthCheck 控制器创建 NodeHealthCheck 自定义资源(CR),它定义了一组条件和阈值来确定节点的健康状态。

Node Health Check Operator 还将 Self Node Remediation Operator 安装为默认的补救提供程序。

当 Node Health Check Operator 检测到不健康的节点时,它会创建一个补救 CR 触发补救供应商。例如,控制器创建 SelfNodeRemediation CR,它会触发 Self Node Remediation Operator 来修复不健康的节点。

NodeHealthCheck CR 类似以下 YAML 文件,带有 self-node-remediation 作为补救供应商:

apiVersion: remediation.medik8s.io/v1alpha1
kind: NodeHealthCheck
metadata:
  name: nodehealthcheck-sample
spec:
  minHealthy: 51% 1
  pauseRequests: 2
    - <pause-test-cluster>
  remediationTemplate: 3
    apiVersion: self-node-remediation.medik8s.io/v1alpha1
    name: self-node-remediation-resource-deletion-template
    namespace: openshift-operators
    kind: SelfNodeRemediationTemplate
  escalatingRemediations: 4
    - remediationTemplate:
        apiVersion: self-node-remediation.medik8s.io/v1alpha1
        name: self-node-remediation-resource-deletion-template
        namespace: openshift-operators
        kind: SelfNodeRemediationTemplate
    order: 1
    timeout: 300s
  selector: 5
    matchExpressions:
      - key: node-role.kubernetes.io/worker
        operator: Exists
  unhealthyConditions: 6
    - type: Ready
      status: "False"
      duration: 300s 7
    - type: Ready
      status: Unknown
      duration: 300s 8
1
指定补救供应商同时修复目标池中节点所需的健康节点数量(以百分比或数量)。如果健康节点的数量等于或超过 minHealthy 设定的限制,则会出现补救。默认值为 51%。
2
防止任何新的补救启动,同时允许持续补救保留。默认值为空。但是,您可以输入字符串数组来识别暂停补救的原因。例如 pause-test-cluster
注意

在升级过程中,集群中的节点可能会临时不可用,并被识别为不健康。对于 worker 节点,当 Operator 检测到集群正在升级时,它会停止修复新的不健康节点,以防止此类节点重新引导。

3
指定补救供应商的补救模板。例如,通过 Self Node Remediation Operato。remediationTemplateescalatingRemediations 相互排斥。
4
使用 order 和 timeout 字段指定 RemediationTemplates 列表。要获取健康的节点,请使用此字段序列并配置多个补救。此策略会增加获取健康节点的可能性,而不是依赖于可能不成功的单一补救。order 字段决定调用补救的顺序(低顺序 = 早期调用)。timeout 字段决定何时调用下一个补救。escalatingRemediationsremediationTemplate 相互排斥。
5
指定与要检查的标签或表达式匹配的选择器。避免在一个 CR 中同时选择 control-plane 和 worker 节点。
6
指定决定节点是否被视为不健康的条件列表。
7 8
指定节点状况的超时持续时间。如果在超时时间内满足了条件,则会修复该节点。超时时间较长可能会导致不健康节点上的工作负载长时间停机。

NodeHealthCheck CR 类似以下 YAML 文件,带有 metal3 作为补救供应商:

apiVersion: remediation.medik8s.io/v1alpha1
kind: NodeHealthCheck
metadata:
  name: nhc-worker-metal3
spec:
  minHealthy: 30%
  remediationTemplate:
    apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
    kind: Metal3RemediationTemplate
    name: metal3-remediation
    namespace: openshift-machine-api
  selector:
    matchExpressions:
    - key: node-role.kubernetes.io/worker
      operator: Exists
  unhealthyConditions:
  - duration: 300s
    status: 'False'
    type: Ready
  - duration: 300s
    status: 'Unknown'
    type: Ready
注意

matchExpressions 只是示例;您必须根据具体需求映射您的机器组。

Metal3RemediationTemplate 类似于以下 YAML 文件,metal3 作为补救供应商:

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: Metal3RemediationTemplate
metadata:
  name: metal3-remediation
  namespace: openshift-machine-api
spec:
  template:
    spec:
      strategy:
        retryLimit: 1
        timeout: 5m0s
        type: Reboot
注意

除了创建 NodeHealthCheck CR 外,还必须创建 Metal3RemediationTemplate

4.1.1. 了解 Node Health Check Operator 工作流

当节点标识为不健康状态时,Node Health Check Operator 会检查其他节点不健康的数量。如果健康的节点数量超过 NodeHealthCheck CR 的 minHealthy 字段中指定的数量,控制器会从补救供应商在外部补救模板中提供的详细信息创建一个补救 CR。补救后,kubelet 会更新节点的健康状况。

当节点处于健康状态时,控制器会删除外部补救模板。

4.1.2. 关于节点健康检查如何防止与机器健康检查冲突

当同时部署节点健康检查和机器健康检查时,节点健康检查会避免与机器健康检查冲突。

注意

Red Hat OpenShift 将 machine-api-termination-handler 部署为默认的 MachineHealthCheck 资源。

以下列表概述了部署节点健康检查和机器健康检查时的系统行为:

  • 如果只有默认机器健康检查,则节点健康检查将继续识别不健康的节点。但是,节点健康检查会忽略处于 Terminating 状态的不健康节点。默认机器健康检查处理处于 Terminating 状态的不健康节点。

    日志消息示例

    INFO MHCChecker	ignoring unhealthy Node, it is terminating and will be handled by MHC	{"NodeName": "node-1.example.com"}

  • 如果修改了默认机器健康检查(例如,unhealthyConditionsReady),或者是否创建额外的机器健康检查,则节点健康检查被禁用。

    日志消息示例

    INFO controllers.NodeHealthCheck disabling NHC in order to avoid conflict with custom MHCs configured in the cluster {"NodeHealthCheck": "/nhc-worker-default"}

  • 当只存在默认的机器健康检查,则会重新启用节点健康检查。

    日志消息示例

    INFO controllers.NodeHealthCheck re-enabling NHC, no conflicting MHC configured in the cluster {"NodeHealthCheck": "/nhc-worker-default"}

4.2. control plane 隔离

在早期版本中,您可以在 worker 节点上启用自节点修复和 Node Health Check。如果节点失败,您现在可以在 control plane 节点上遵循补救策略。

不要将相同的 NodeHealthCheck CR 用于 worker 节点和 control plane 节点。将 worker 节点和 control plane 节点分组在一起可能会导致评估最小健康节点数,并导致意外或缺失的补救。这是因为 Node Health Check Operator 处理 control plane 节点的方式。您应该在自己的组中对 control plane 节点进行分组,并在自己的组中对 worker 节点进行分组。如果需要,您还可以创建多个 worker 节点组。

补救策略的注意事项:

  • 避免涉及多个配置的节点健康检查配置重叠同一节点,因为它们可能会导致意外行为。本建议适用于 worker 和 control plane 节点。
  • Node Health Check Operator 实现了一个硬性限制,用于一次修复一个 control plane 节点。不应该同时修复多个 control plane 节点。

4.3. 使用 Web 控制台安装 Node Health Check Operator

您可以使用 Red Hat OpenShift Web 控制台安装 Node Health Check Operator。

先决条件

  • 以具有 cluster-admin 特权的用户身份登录。

流程

  1. 在 Red Hat OpenShift Web 控制台中导航至 OperatorsOperatorHub
  2. 搜索 Node Health Check Operator,然后点 Install
  3. 保留安装模式命名空间的默认选择,以确保将 Operator 安装到 openshift-operators 命名空间中。
  4. 确保 Console 插件 被设置为 Enable
  5. Install

验证

确认安装成功:

  1. 进入到 OperatorsInstalled Operators 页面。
  2. 检查 Operator 是否安装在 openshift-operators 命名空间中,其状态是否为 Succeeded

如果 Operator 没有成功安装:

  1. 导航到 OperatorsInstalled Operators 页面,并检查 Status 列中是否有任何错误或故障。
  2. 导航到 WorkloadsPods 页面,并检查 openshift-operators 项目中报告问题的 pod 的日志。

4.4. 使用 CLI 安装 Node Health Check Operator

您可以使用 OpenShift CLI (oc)安装 Node Health Check Operator。

要在您自己的命名空间中安装 Operator,请按照以下步骤执行。

要在 openshift-operators 命名空间中安装 Operator,请跳至步骤 3,因为需要新的 Namespace 自定义资源(CR)和 OperatorGroup CR 的步骤。

先决条件

  • 安装 OpenShift CLI(oc)。
  • 以具有 cluster-admin 特权的用户身份登录。

流程

  1. 为 Node Health Check Operator 创建 Namespace 自定义资源 (CR):

    1. 定义 Namespace CR 并保存 YAML 文件,如 node-health-check-namespace.yaml

      apiVersion: v1
      kind: Namespace
      metadata:
        name: node-health-check
    2. 要创建 Namespace CR,请运行以下命令:

      $ oc create -f node-health-check-namespace.yaml
  2. 创建 OperatorGroup CR:

    1. 定义 OperatorGroup CR 并保存 YAML 文件,如 node-health-check-operator-group.yaml

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: node-health-check-operator
        namespace: node-health-check
    2. 要创建 OperatorGroup CR,请运行以下命令:

      $ oc create -f node-health-check-operator-group.yaml
  3. 创建一个 Subscription CR:

    1. 定义 Subscription CR 并保存 YAML 文件,如 node-health-check-subscription.yaml

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
          name: node-health-check-operator
          namespace: node-health-check 1
      spec:
          channel: stable 2
          installPlanApproval: Manual 3
          name: node-healthcheck-operator
          source: redhat-operators
          sourceNamespace: openshift-marketplace
          package: node-healthcheck-operator
      1
      指定您要安装 Node Health Check Operator 的命名空间。要在 openshift-operators 命名空间中安装 Node Health Check Operator,请在 Subscription CR 中指定 openshift-operators
      2
      指定订阅的频道名称。要升级到 Node Health Check Operator 的最新版本,您必须手动将订阅的频道名称从 candidate 改为 stable
      3
      如果您的指定版本被目录中的后续版本取代,则将批准策略设置为 Manual。此计划阻止自动升级到更新的版本,且需要在启动 CSV 可以完成安装前手动批准。
    2. 要创建 Subscription CR,请运行以下命令:

      $ oc create -f node-health-check-subscription.yaml

验证

  1. 检查 CSV 资源来验证安装是否成功:

    $ oc get csv -n openshift-operators

    输出示例

    NAME                              DISPLAY                     VERSION  REPLACES PHASE
    node-healthcheck-operator.v0.5.0. Node Health Check Operator  0.5.0             Succeeded

  2. 验证 Node Health Check Operator 是否正在运行:

    $ oc get deploy -n openshift-operators

    输出示例

    NAME                                           READY   UP-TO-DATE   AVAILABLE   AGE
    node-health-check-operator-controller-manager  1/1     1            1           10d

4.5. 创建节点健康检查

使用 Web 控制台,您可以创建一个节点健康检查来标识不健康的节点,并指定补救类型和策略来修复它们。

流程

  1. 从 Red Hat OpenShift Web 控制台的 Administrator 视角中,点 ComputeNodeHealthChecksCreateNodeHealthCheck
  2. 指定是否使用 Form viewYAML 视图配置节点健康检查。
  3. 输入节点健康检查的名称。名称必须包含小写、字母数字字符、'-' 或 '.',且必须以字母数字字符开头和结尾。
  4. 指定 Remediator 类型,以及 Self node remediation其他。Self 节点补救选项是安装 Node Health Check Operator 的 Self Node Remediation Operator 的一部分。选择 Other 需要输入 API 版本KindNameNamespace,然后指向补救器的补救模板资源。
  5. 通过指定要修复的 Nodes 标签来创建节点选择。选择与要检查的标签匹配。如果指定了多个标签,节点必须包含每个标签。默认值为空,用于选择 worker 和 control-plane 节点。

    注意

    使用 Self Node Remediation Operator 创建节点健康检查时,您必须选择 node-role.kubernetes.io/workernode-role.kubernetes.io/control-plane 作为值。

  6. 使用 NodeHealthCheck 来修复目标池中的节点所需的最小健康节点数量(百分比或数字)。如果健康的节点数量等于或超过 Min healthy 设定的限制,则会出现补救。默认值为 51%。
  7. 指定一个非健康条件列表,在决定一个端点被认为是非健康以及需要的补救时使用这些条件。您可以指定 TypeStatusDuration。您还可以创建自己的自定义类型。
  8. Create 创建节点健康检查。

验证

  • 进入到 ComputeNodeHealthCheck 页面,再验证是否列出了对应的节点健康检查,并且显示其状态。创建后,可以暂停、修改和删除节点健康检查。

4.6. 收集 Node Health Check Operator 的数据

要收集有关 Node Health Check Operator 的调试信息,请使用 must-gather 工具。有关 Node Health Check Operator 的 must-gather 镜像的详情,请参阅收集有关特定功能的数据

4.7. 其他资源

第 5 章 使用 Node Maintenance Operator 将节点置于维护模式

您可以使用 oc adm 实用程序或 NodeMaintenance 自定义资源(CR)来使用 Node Maintenance Operator 将节点置于维护模式。

5.1. 关于 Node Maintenance Operator

Node Maintenance Operator 监视是否有新的或删除的 NodeMaintenance CR。当检测到新的 NodeMaintenance CR 时,不会调度新的工作负载,并且该节点从集群的其余部分中分离。所有可被驱除的 pod 都会从节点上驱除。删除 NodeMaintenance CR 时,CR 中引用的节点将可用于新工作负载。

注意

使用 NodeMaintenance CR 进行节点维护任务可实现与 oc adm cordonoc adm drain 命令相同的结果,使用标准 Red Hat OpenShift CR 处理。

5.2. 安装 Node Maintenance Operator

您可以使用 Web 控制台或 OpenShift CLI(oc)安装 Node Maintenance Operator。

注意

如果在集群中安装了 OpenShift Virtualization 版本 4.10 或更少,它包括了一个过时的 Node Maintenance Operator 版本。

5.2.1. 使用 Web 控制台安装 Node Maintenance Operator

您可以使用 Red Hat OpenShift Web 控制台安装 Node Maintenance Operator。

先决条件

  • 以具有 cluster-admin 特权的用户身份登录。

流程

  1. 在 Red Hat OpenShift Web 控制台中导航至 OperatorsOperatorHub
  2. 搜索 Node Maintenance Operator,然后点 Install
  3. 保留安装模式命名空间的默认选择,以确保将 Operator 安装到 openshift-operators 命名空间中。
  4. Install

验证

确认安装成功:

  1. 进入到 OperatorsInstalled Operators 页面。
  2. 检查 Operator 是否安装在 openshift-operators 命名空间中,其状态是否为 Succeeded

如果 Operator 没有成功安装:

  1. 导航到 OperatorsInstalled Operators 页面,并检查 Status 列中是否有任何错误或故障。
  2. 进入到 OperatorsInstalled OperatorsNode Maintenance OperatorDetails 页面,并在创建 pod 前检查 Conditions 部分是否有错误。
  3. 进入到 WorkloadsPods 页面,在已安装的命名空间中搜索 Node Maintenance Operator pod,并在 Logs 选项卡中检查日志。

5.2.2. 使用 CLI 安装 Node Maintenance Operator

您可以使用 OpenShift CLI(oc)安装 Node Maintenance Operator。

您可以在自己的命名空间中或 openshift-operators 命名空间中安装 Node Maintenance Operator。

要在您自己的命名空间中安装 Operator,请按照以下步骤执行。

要在 openshift-operators 命名空间中安装 Operator,请跳至步骤 3,因为需要新的 Namespace 自定义资源(CR)和 OperatorGroup CR 的步骤。

先决条件

  • 安装 OpenShift CLI(oc)。
  • 以具有 cluster-admin 特权的用户身份登录。

流程

  1. 为 Node Maintenance Operator 创建一个 Namespace CR:

    1. 定义 Namespace CR 并保存 YAML 文件,如 node-maintenance-namespace.yaml

      apiVersion: v1
      kind: Namespace
      metadata:
        name: nmo-test
    2. 要创建 Namespace CR,请运行以下命令:

      $ oc create -f node-maintenance-namespace.yaml
  2. 创建 OperatorGroup CR:

    1. 定义 OperatorGroup CR 并保存 YAML 文件,如 node-maintenance-operator-group.yaml

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: node-maintenance-operator
        namespace: nmo-test
    2. 要创建 OperatorGroup CR,请运行以下命令:

      $ oc create -f node-maintenance-operator-group.yaml
  3. 创建一个 Subscription CR:

    1. 定义 Subscription CR,并保存 YAML 文件,如 node-maintenance-subscription.yaml

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: node-maintenance-operator
        namespace: nmo-test 1
      spec:
        channel: stable
        installPlanApproval: Automatic
        name: node-maintenance-operator
        source: redhat-operators
        sourceNamespace: openshift-marketplace
        package: node-maintenance-operator
      1
      指定您要安装 Node Maintenance Operator 的命名空间
      重要

      要在 openshift-operators 命名空间中安装 Node Maintenance Operator,请在 Subscription CR 中指定 openshift-operators

    2. 要创建 Subscription CR,请运行以下命令:

      $ oc create -f node-maintenance-subscription.yaml

验证

  1. 检查 CSV 资源来验证安装是否成功:

    $ oc get csv -n openshift-operators

    输出示例

    NAME                               DISPLAY                     VERSION   REPLACES  PHASE
    node-maintenance-operator.v5.0.0   Node Maintenance Operator   5.0.0               Succeeded

  2. 验证 Node Maintenance Operator 是否正在运行:

    $ oc get deploy -n openshift-operators

    输出示例

    NAME                                           READY   UP-TO-DATE   AVAILABLE   AGE
    node-maintenance-operator-controller-manager   1/1     1            1           10d

受限网络环境中支持 Node Maintenance Operator。如需更多信息,请参阅在受限网络中使用 Operator Lifecycle Manager

5.3. 将节点设置为维护模式

您可以通过 web 控制台或 CLI 使用 NodeMaintenance CR 将节点置于维护模式。

5.3.1. 使用 Web 控制台将节点设置为维护模式

要将节点设置为维护模式,您可以使用 Web 控制台创建 NodeMaintenance 自定义资源(CR)。

先决条件

  • 以具有 cluster-admin 权限的用户身份登录。
  • OperatorHub 安装 Node Maintenance Operator。

流程

  1. 从 Web 控制台中的 Administrator 视角,导航到 OperatorsInstalled Operators
  2. 从 Operator 列表中选择 Node Maintenance Operator。
  3. Node Maintenance 选项卡中,点 Create NodeMaintenance
  4. Create NodeMaintenance 页面中,选择 Form viewYAML 视图来 配置 NodeMaintenance CR。
  5. 要应用您配置的 NodeMaintenance CR,请点击 Create

验证

Node Maintenance 选项卡中,检查 Status 列并验证其状态是否为 Succeeded

5.3.2. 使用 CLI 将节点设置为维护模式

您可以使用 NodeMaintenance 自定义资源(CR)将节点置于维护模式。应用 NodeMaintenance CR 时,所有允许的 pod 都会被驱除,且节点不可调度。被驱除的 pod 会被放入到集群中的另一节点中。

先决条件

  • 安装 Red Hat OpenShift CLI oc
  • 以具有 cluster-admin 权限的用户身份登录集群。

流程

  1. 创建以下 NodeMaintenance CR,并将文件保存为 nodemaintenance-cr.yaml

    apiVersion: nodemaintenance.medik8s.io/v1beta1
    kind: NodeMaintenance
    metadata:
      name: nodemaintenance-cr  1
    spec:
      nodeName: node-1.example.com 2
      reason: "NIC replacement" 3
    1
    节点维护 CR 的名称。
    2
    要置于维护模式的节点名称。
    3
    有关维护原因的纯文本描述。
  2. 运行以下命令来应用节点维护 CR:

    $ oc apply -f nodemaintenance-cr.yaml

验证

  1. 运行以下命令,检查维护任务的进度:

    $ oc describe node <node-name>

    其中 <node-name> 是节点的名称,如 node-1.example.com

  2. 检查输出示例:

    Events:
      Type     Reason                     Age                   From     Message
      ----     ------                     ----                  ----     -------
      Normal   NodeNotSchedulable         61m                   kubelet  Node node-1.example.com status is now: NodeNotSchedulable

5.3.3. 检查当前 NodeMaintenance CR 任务的状态

您可以检查当前 NodeMaintenance CR 任务的状态。

先决条件

  • 安装 Red Hat OpenShift CLI oc
  • 以具有 cluster-admin 权限的用户身份登录。

流程

  • 运行以下命令,检查当前节点维护任务的状态,如 NodeMaintenance CR 或 nm 对象:

    $ oc get nm -o yaml

    输出示例

    apiVersion: v1
    items:
    - apiVersion: nodemaintenance.medik8s.io/v1beta1
      kind: NodeMaintenance
      metadata:
    ...
      spec:
        nodeName: node-1.example.com
        reason: Node maintenance
      status:
        drainProgress: 100   1
        evictionPods: 3   2
        lastError: "Last failure message" 3
        lastUpdate: "2022-06-23T11:43:18Z" 4
        phase: Succeeded
        totalpods: 5 5
    ...

    1
    排空节点完成的百分比。
    2
    调度用于驱除的 pod 数量。
    3
    最新的驱除错误(若有)。
    4
    最后一次更新状态的时间。
    5
    节点进入维护模式前的 pod 总数。

5.4. 从维护模式恢复节点

您可以通过 web 控制台或使用 NodeMaintenance CR 从维护模式恢复节点。恢复节点会使节点退出维护模式,并使其可再次调度。

5.4.1. 使用 Web 控制台从维护模式恢复节点

要从维护模式恢复节点,您可以使用 Web 控制台删除 NodeMaintenance 自定义资源(CR)。

先决条件

  • 以具有 cluster-admin 权限的用户身份登录。
  • OperatorHub 安装 Node Maintenance Operator。

流程

  1. 从 Web 控制台中的 Administrator 视角,导航到 OperatorsInstalled Operators
  2. 从 Operator 列表中选择 Node Maintenance Operator。
  3. Node Maintenance 选项卡中,选择您要删除的 NodeMaintenance CR。
  4. 点击节点末尾的 Options 菜单 kebab 并选择 Delete NodeMaintenance

验证

  1. 在 Red Hat OpenShift 控制台中,点 Compute → Nodes
  2. 检查您删除 NodeMaintenance CR 的节点的 Status 列,并验证其状态是否为 Ready

5.4.2. 使用 CLI 从维护模式恢复节点

您可以通过删除 NodeMaintenance CR,从 NodeMaintenance CR 启动的维护模式恢复节点。

先决条件

  • 安装 Red Hat OpenShift CLI oc
  • 以具有 cluster-admin 权限的用户身份登录集群。

流程

  • 节点维护任务完成后,删除活跃的 NodeMaintenance CR:

    $ oc delete -f nodemaintenance-cr.yaml

    输出示例

    nodemaintenance.nodemaintenance.medik8s.io "maintenance-example" deleted

验证

  1. 运行以下命令,检查维护任务的进度:

    $ oc describe node <node-name>

    其中 <node-name> 是节点的名称,如 node-1.example.com

  2. 检查输出示例:

    Events:
      Type     Reason                  Age                   From     Message
      ----     ------                  ----                  ----     -------
      Normal   NodeSchedulable         2m                    kubelet  Node node-1.example.com status is now: NodeSchedulable

5.5. 使用裸机节点

对于使用裸机节点的集群,您可以使用 web 控制台 Actions 控制将节点置于维护模式,并从维护模式恢复节点。

注意

具有裸机节点的集群也可以将节点置于维护模式,并使用 web 控制台和 CLI 从维护模式恢复节点。这些方法通过使用 Web 控制台 Actions 控制,仅适用于裸机集群。

5.5.1. 维护裸机节点

在裸机基础架构上部署 Red Hat OpenShift 时,与在云基础架构上部署相比,您必须考虑其他注意事项。与云环境不同,集群节点被视为临时的,重新置备裸机节点需要大量时间和精力来进行维护任务。

当因为内核错误或 NIC 卡硬件故障造成裸机节点失败时,故障节点上的工作负载需要在集群中的另一个节点上重启,同时问题节点被修复或替换。节点维护模式允许集群管理员安全关闭节点,将工作负载移到集群的其它部分,并确保工作负载不会中断。详细进度和节点状态详情会在维护过程中提供。

5.5.2. 将裸机节点设置为维护模式

使用 ComputeNodes 列表中每个节点上 kebab 的 Options 菜单,或使用 Node Details 屏幕的 Actions 控制,将裸机节点设置为维护模式。

流程

  1. 从 Web 控制台的 Administrator 视角中,点 ComputeNodes
  2. 您可从此屏幕将节点设置为维护,这有助于对多个虚拟机执行操作,也可通过 Node Details 屏幕进行,其中可查看所选节点的综合详情:

    • 点击节点 kebab 末尾的 Options 菜单并选择 Start Maintenance
    • 点击节点名称以打开 Node Details 屏幕,然后点击 ActionsStart Maintenance
  3. 在确认窗口中点击 Start Maintenance

该节点不可调度。如果已有带有 LiveMigration 驱除策略的虚拟机,则会实时迁移它们。该节点上的所有其他 pod 和虚拟机均被删除,并会在另一节点上重新创建。

验证

  • 进入到 ComputeNodes 页面,验证对应节点的状态是否为 Under Maintenance

5.5.3. 从维护模式恢复裸机节点

使用 ComputeNodes 列表中每个节点上 kebab 的 Options 菜单,或使用 Node Details 屏幕的 Actions 控制,从维护模式恢复裸机节点。

流程

  1. 从 Web 控制台的 Administrator 视角中,点 ComputeNodes
  2. 您可从此屏幕恢复节点,这有助于对多个虚拟机执行操作,也可从 Node Details 屏幕,其中可查看所选节点的综合详情:

    • 点击节点 kebab 末尾的 Options 菜单并选择 Stop Maintenance
    • 点击节点名称以打开 Node Details 屏幕,然后点击 ActionsStop Maintenance
  3. 在确认窗口中点击 Stop Maintenance

节点变为可调度。如果在维护之前已有该节点上运行的虚拟机实例,则它们不会自动迁移回该节点。

验证

  • 进入到 ComputeNodes 页面,验证对应节点的状态是否为 Ready

5.6. 收集 Node Maintenance Operator 的数据

要收集有关 Node Maintenance Operator 的调试信息,请使用 must-gather 工具。有关 Node Maintenance Operator 的 must-gather 镜像的信息,请参阅收集有关特定功能的数据

5.7. 其他资源

法律通告

Copyright © 2024 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.