OpenShift 文档正在迁移，很快将只在 docs.redhat.com（所有 Red Hat 产品文档的中心）提供。立即体验 新的文档体验。
  1. 文档
    2. history bug_report picture_as_pdf
×

部署机器健康检查

您可以配置和部署机器健康检查以自动修复机器池中损坏的机器。

只有在 Machine API 可运行的集群中，才能使用高级机器管理和扩展功能。具有用户预配基础设施的集群需要额外的验证和配置才能使用 Machine API。

基础设施平台类型为none的集群无法使用 Machine API。即使连接到集群的计算机器安装在支持此功能的平台上，此限制也适用。此参数安装后无法更改。

要查看集群的平台类型，请运行以下命令

$ oc get infrastructure cluster -o jsonpath='{.status.platform}'

关于机器健康检查

您只能将机器健康检查应用于由计算机器集或控制平面机器集管理的机器。

要监控机器健康状况，请创建一个资源来定义控制器的配置。设置要检查的条件，例如在NotReady状态下停留五分钟或在节点问题检测器中显示永久性条件，以及要监控的机器集的标签。

观察MachineHealthCheck资源的控制器会检查定义的条件。如果机器未能通过健康检查，则会自动删除该机器，并创建一个机器来代替它。删除机器时，您会看到machine deleted事件。

为了限制机器删除的破坏性影响，控制器一次只排空并删除一个节点。如果目标机器池中的不健康机器数量超过maxUnhealthy阈值允许的数量，则修复将停止，从而允许手动干预。

仔细考虑超时时间，并考虑工作负载和要求。

  • 较长的超时时间会导致不健康机器上的工作负载长时间停机。

  • 超时时间太短会导致修复循环。例如，检查NotReady状态的超时时间必须足够长，以允许机器完成启动过程。

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

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

部署机器健康检查之前，需要考虑一些限制

  • 只有机器集拥有的机器才会由机器健康检查修复。

  • 如果机器的节点从集群中移除，则机器健康检查会认为该机器不健康并立即修复它。

  • 如果机器的相应节点在nodeStartupTimeout之后没有加入集群，则会修复该机器。

  • 如果Machine资源阶段为Failed，则会立即修复机器。

其他资源

示例 MachineHealthCheck 资源

所有基于云的安装类型以及除裸机以外的其他类型的MachineHealthCheck资源类似于以下 YAML 文件

apiVersion: machine.openshift.io/v1beta1
kind: MachineHealthCheck
metadata:
  name: example (1)
  namespace: openshift-machine-api
spec:
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-machine-role: <role> (2)
      machine.openshift.io/cluster-api-machine-type: <role> (2)
      machine.openshift.io/cluster-api-machineset: <cluster_name>-<label>-<zone> (3)
  unhealthyConditions:
  - type:    "Ready"
    timeout: "300s" (4)
    status: "False"
  - type:    "Ready"
    timeout: "300s" (4)
    status: "Unknown"
  maxUnhealthy: "40%" (5)
  nodeStartupTimeout: "10m" (6)
1 指定要部署的机器健康检查的名称。
2 为要检查的机器池指定一个标签。
3 以<集群名称>-<标签>-<区域>格式指定要跟踪的机器集。例如，prod-node-us-east-1a。
4 指定节点条件的超时持续时间。如果条件在超时持续时间内满足，则将修复该机器。较长的超时时间会导致不健康机器上的工作负载长时间停机。
5 指定在目标池中允许同时修复的机器数量。这可以设置为百分比或整数。如果不健康机器的数量超过maxUnhealthy设置的限制，则不会执行修复。
6 指定机器健康检查必须等待节点加入集群之前才能确定机器不健康的超时持续时间。

matchLabels仅为示例；您必须根据您的具体需求映射您的机器组。

短路机器健康检查修复

短路确保机器健康检查仅在集群健康时才修复机器。短路是通过MachineHealthCheck资源中的maxUnhealthy字段配置的。

如果用户为maxUnhealthy字段定义了一个值，则在修复任何机器之前，MachineHealthCheck会将maxUnhealthy的值与其目标池中已确定为不健康的机器数量进行比较。如果不健康机器的数量超过maxUnhealthy限制，则不会执行修复。

如果未设置maxUnhealthy，则其值默认为100%，并且无论集群状态如何都会修复机器。

合适的maxUnhealthy值取决于您部署的集群规模以及MachineHealthCheck涵盖的机器数量。例如，您可以使用maxUnhealthy值来覆盖多个可用区中的多个计算机器集，以便如果您丢失整个可用区，您的maxUnhealthy设置将阻止集群内进一步的修复。在没有多个可用区的全球 Azure 区域中，您可以使用可用性集来确保高可用性。

如果您为控制平面配置MachineHealthCheck资源，请将maxUnhealthy的值设置为1。

此配置可确保当多个控制平面机器似乎不健康时，机器健康检查不采取任何操作。多个不健康的控制平面机器可能表示 etcd 集群已降级，或者正在进行替换故障机器的缩放操作。

如果 etcd 集群已降级，则可能需要手动干预。如果缩放操作正在进行中，则机器健康检查应允许其完成。

maxUnhealthy字段可以设置为整数或百分比。根据maxUnhealthy值，存在不同的修复实现。

使用绝对值设置 maxUnhealthy

如果maxUnhealthy设置为2

  • 如果 2 个或更少的节点不健康，将执行修复

  • 如果 3 个或更多节点不健康，将不会执行修复

这些值与机器健康检查正在检查的机器数量无关。

使用百分比设置 maxUnhealthy

如果maxUnhealthy设置为40%，并且正在检查 25 台机器

  • 如果 10 个或更少的节点不健康，将执行修复

  • 如果 11 个或更多节点不健康，将不会执行修复

如果maxUnhealthy设置为40%，并且正在检查 6 台机器

  • 如果 2 个或更少的节点不健康，将执行修复

  • 如果 3 个或更多节点不健康，将不会执行修复

当被检查的maxUnhealthy机器的百分比不是整数时，允许的机器数量将向下取整。

创建机器健康检查资源

您可以为集群中的机器集创建MachineHealthCheck资源。

您只能将机器健康检查应用于由计算机器集或控制平面机器集管理的机器。
先决条件

  • 安装oc命令行界面。

步骤

  1. 创建一个包含机器健康检查定义的healthcheck.yml文件。

  2. 将healthcheck.yml文件应用到您的集群

    $ oc apply -f healthcheck.yml

您可以配置和部署机器健康检查以检测和修复不健康的裸机节点。

关于裸机的基于电源的修复

在裸机集群中，节点修复对于确保集群的整体健康至关重要。物理修复集群可能具有挑战性，任何将机器置于安全或可操作状态的延迟都会增加集群保持降级状态的时间，以及后续故障可能使集群脱机的风险。基于电源的修复有助于应对这些挑战。

基于电源的修复不重新配置节点，而是使用电源控制器关闭无法运行的节点。这种类型的修复也称为电源隔离。

OpenShift Container Platform 使用MachineHealthCheck控制器检测故障的裸机节点。基于电源的修复速度很快，它会重新启动故障节点，而不是将其从集群中移除。

基于电源的修复提供以下功能：

  • 允许恢复控制平面节点

  • 降低超融合环境中数据丢失的风险

  • 减少恢复物理机器相关的停机时间

裸机上的 MachineHealthChecks

裸机集群上的机器删除会触发裸机主机的重新配置。通常，裸机重新配置是一个漫长的过程，在此期间集群缺少计算资源，并且应用程序可能会中断。

有两种方法可以将默认的修复过程从机器删除更改为主机电源循环：

  1. 使用machine.openshift.io/remediation-strategy: external-baremetal注释注释MachineHealthCheck资源。

  2. 创建一个Metal3RemediationTemplate资源，并在MachineHealthCheck的spec.remediationTemplate中引用它。

使用上述方法之一后，将使用基板管理控制器 (BMC) 凭据对不健康的机器进行电源循环。

了解基于注释的修复过程

修复过程如下：

  1. MachineHealthCheck (MHC) 控制器检测到节点不健康。

  2. MHC 通知裸机机器控制器，后者请求关闭不健康的节点。

  3. 电源关闭后，节点将被删除，这允许集群将受影响的工作负载重新调度到其他节点。

  4. 裸机机器控制器请求打开节点电源。

  5. 节点启动后，节点会重新向集群注册，从而创建新的节点。

  6. 节点重新创建后，裸机机器控制器将恢复在节点删除之前存在于不健康节点上的注释和标签。

如果电源操作未完成，除非这是控制平面节点或外部配置的节点，否则裸机机器控制器将触发不健康节点的重新配置。

了解基于 Metal3 的修复过程

修复过程如下：

  1. MachineHealthCheck (MHC) 控制器检测到节点不健康。

  2. MHC 为 Metal3 修复控制器创建一个 Metal3 修复自定义资源，后者请求关闭不健康的节点。

  3. 电源关闭后，节点将被删除，这允许集群将受影响的工作负载重新调度到其他节点。

  4. Metal3 修复控制器请求打开节点电源。

  5. 节点启动后，节点会重新向集群注册，从而创建新的节点。

  6. 节点重新创建后，Metal3 修复控制器将恢复在节点删除之前存在于不健康节点上的注释和标签。

如果电源操作未完成，除非这是控制平面节点或外部配置的节点，否则 Metal3 修复控制器将触发不健康节点的重新配置。

为裸机创建 MachineHealthCheck 资源

先决条件

  • OpenShift Container Platform 是使用安装程序预配置的基础设施 (IPI) 安装的。

  • 访问 BMC 凭据（或对每个节点的 BMC 访问权限）。

  • 访问不健康节点的 BMC 接口的网络。

步骤

  1. 创建一个包含机器健康检查定义的healthcheck.yaml文件。

  2. 使用以下命令将healthcheck.yaml文件应用到您的集群

    $ oc apply -f healthcheck.yaml
裸机基于注释的修复的MachineHealthCheck资源示例
apiVersion: machine.openshift.io/v1beta1
kind: MachineHealthCheck
metadata:
  name: example (1)
  namespace: openshift-machine-api
  annotations:
    machine.openshift.io/remediation-strategy: external-baremetal (2)
spec:
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-machine-role: <role> (3)
      machine.openshift.io/cluster-api-machine-type: <role> (3)
      machine.openshift.io/cluster-api-machineset: <cluster_name>-<label>-<zone> (4)
  unhealthyConditions:
  - type:    "Ready"
    timeout: "300s" (5)
    status: "False"
  - type:    "Ready"
    timeout: "300s" (5)
    status: "Unknown"
  maxUnhealthy: "40%" (6)
  nodeStartupTimeout: "10m" (7)
1 指定要部署的机器健康检查的名称。
2 对于裸金属集群，必须在annotations部分包含machine.openshift.io/remediation-strategy: external-baremetal注释以启用电源循环修复。使用此修复策略，不健康的节点将被重启，而不是从集群中移除。
3 为要检查的机器池指定一个标签。
4 指定要跟踪的计算机器集，格式为<集群名称>-<标签>-<区域>。例如：prod-node-us-east-1a。
5 指定节点条件的超时时长。如果条件在超时时长内持续满足，则机器将被修复。较长的超时时间可能导致不健康机器上的工作负载长时间停机。
6 指定在目标池中允许同时修复的机器数量。这可以设置为百分比或整数。如果不健康机器的数量超过maxUnhealthy设置的限制，则不会执行修复。
7 指定机器健康检查必须等待节点加入集群之前才能确定机器不健康的超时持续时间。

matchLabels仅为示例；您必须根据您的具体需求映射您的机器组。
裸金属、基于Metal3的修复的MachineHealthCheck资源示例
apiVersion: machine.openshift.io/v1beta1
kind: MachineHealthCheck
metadata:
  name: example
  namespace: openshift-machine-api
spec:
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-machine-role: <role>
      machine.openshift.io/cluster-api-machine-type: <role>
      machine.openshift.io/cluster-api-machineset: <cluster_name>-<label>-<zone>
  remediationTemplate:
    apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
    kind: Metal3RemediationTemplate
    name: metal3-remediation-template
    namespace: openshift-machine-api
  unhealthyConditions:
  - type:    "Ready"
    timeout: "300s"
裸金属、基于Metal3的修复的Metal3RemediationTemplate资源示例
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: Metal3RemediationTemplate
metadata:
  name: metal3-remediation-template
  namespace: openshift-machine-api
spec:
  template:
    spec:
      strategy:
        type: Reboot
        retryLimit: 1
        timeout: 5m0s

matchLabels仅为示例；您必须根据您的特定需求映射您的机器组。annotations部分不适用于基于Metal3的修复。基于注释的修复和基于Metal3的修复是互斥的。

基于电源的修复问题的故障排除

要对基于电源的修复问题进行故障排除，请验证以下内容：

  • 您可以访问BMC。

  • BMC连接到负责运行修复任务的控制平面节点。