Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

7.3. 部署机器健康检查

理解并部署机器健康检查。

重要

您只能在 Machine API 操作的集群中使用高级机器管理和扩展功能。具有用户置备的基础架构的集群需要额外的验证和配置才能使用 Machine API。

具有基础架构平台类型 none 的集群无法使用 Machine API。即使附加到集群的计算机器安装在支持该功能的平台上，也会应用这个限制。在安装后无法更改此参数。

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

$ oc get infrastructure cluster -o jsonpath='{.status.platform}'
Copy to Clipboard Toggle word wrap

7.3.1. 关于机器健康检查
复制链接

注意

您只能对由计算机器集或 control plane 机器集管理的机器应用机器健康检查。

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

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

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

注意

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

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

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

7.3.1.1. 部署机器健康检查时的限制
复制链接

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

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

7.3.2. 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>
3 

      machine.openshift.io/cluster-api-machineset: <cluster_name>-<label>-<zone>
4 

  unhealthyConditions:
  - type:    "Ready"
    timeout: "300s"
5 

    status: "False"
  - type:    "Ready"
    timeout: "300s"
6 

    status: "Unknown"
  maxUnhealthy: "40%"
7 

  nodeStartupTimeout: "10m"
8
Copy to Clipboard Toggle word wrap
1
指定要部署的机器健康检查的名称。
2 3
为要检查的机器池指定一个标签。
4
以 <cluster_name>-<label>-<zone> 格式 指定要跟踪的机器集。例如，prod-node-us-east-1a。
5 6
指定节点条件的超时持续时间。如果在超时时间内满足了条件，则会修复机器。超时时间较长可能会导致不健康的机器上的工作负载长时间停机。
7
指定目标池中允许同时修复的机器数量。这可设为一个百分比或一个整数。如果不健康的机器数量超过 maxUnhealthy 设定的限制，则不会执行补救。
8
指定机器健康检查在决定机器不健康前必须等待节点加入集群的超时持续时间。
注意

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

7.3.2.1. 短路机器健康检查补救
复制链接

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

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

重要

如果没有设置 maxUnhealthy，则默认值为 100%，无论集群状态如何，机器都会被修复。

适当的 maxUnhealthy 值取决于您部署的集群规模以及 MachineHealthCheck 覆盖的机器数量。例如，您可以使用 maxUnhealthy 值覆盖多个可用区间的多个计算机器集，以便在丢失整个区时，maxUnhealthy 设置可以在集群中防止进一步补救。在没有多个可用区的全局 Azure 区域，您可以使用可用性集来确保高可用性。

重要

如果您为 control plane 配置 MachineHealthCheck 资源，请将 maxUnhealthy 的值设置为 1。

此配置可确保当多个 control plane 机器显示为不健康时，机器健康检查不会采取任何操作。多个不健康的 control plane 机器可能会表示 etcd 集群已降级或扩展操作来替换失败的机器。

如果 etcd 集群降级，可能需要手动干预。如果扩展操作正在进行，机器健康检查应该允许它完成。

maxUnhealthy 字段可以设置为整数或百分比。根据 maxUnhealthy 值，有不同的补救实现。

7.3.2.1.1. 使用绝对值设置 maxUnhealthy
复制链接

如果将 maxUnhealthy 设为 2:

  • 如果 2 个或更少节点不健康，则可执行补救
  • 如果 3 个或更多节点不健康，则不会执行补救

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

7.3.2.1.2. 使用百分比设置 maxUnhealthy
复制链接

如果 maxUnhealthy 被设置为 40%，有 25 个机器被检查：

  • 如果有 10 个或更少节点处于不健康状态，则可执行补救
  • 如果 11 个或多个节点不健康，则不会执行补救

如果 maxUnhealthy 被设置为 40%，有 6 个机器被检查：

  • 如果 2 个或更少节点不健康，则可执行补救
  • 如果 3 个或更多节点不健康，则不会执行补救
注意

当被检查的 maxUnhealthy 机器的百分比不是一个整数时，允许的机器数量会被舍入到一个小的整数。

7.3.3. 创建机器健康检查资源
复制链接

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

注意

您只能对由计算机器集或 control plane 机器集管理的机器应用机器健康检查。

先决条件

  • 安装 oc 命令行界面。

流程

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

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

    $ oc apply -f healthcheck.yml
    Copy to Clipboard Toggle word wrap

7.3.4. 手动扩展计算机器集
复制链接

要在计算机器集中添加或删除机器实例，您可以手动扩展计算机器集。

这个指南与全自动的、安装程序置备的基础架构安装相关。自定义的、用户置备的基础架构安装没有计算机器集。

先决条件

  • 安装 OpenShift Container Platform 集群和 oc 命令行。
  • 以具有 cluster-admin 权限的用户身份登录 oc。

流程

  1. 运行以下命令，查看集群中的计算机器： 

    $ oc get machinesets -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

    计算机器集以 <clusterid>-worker-<aws-region-az> 的形式列出。

  2. 运行以下命令，查看集群中的计算机器： 

    $ oc get machine -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

  3. 运行以下命令，在要删除的计算机器上设置注解： 

    $ oc annotate machine/<machine_name> -n openshift-machine-api machine.openshift.io/delete-machine="true"
    Copy to Clipboard Toggle word wrap

  4. 运行以下命令来扩展计算机器集： 

    $ oc scale --replicas=2 machineset <machineset> -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

    或者： 

    $ oc edit machineset <machineset> -n openshift-machine-api
    Copy to Clipboard Toggle word wrap
    提示

    您还可以应用以下 YAML 来扩展计算机器集： 

    apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  name: <machineset>
  namespace: openshift-machine-api
spec:
  replicas: 2
    Copy to Clipboard Toggle word wrap

    您可以扩展或缩减计算机器。需要过几分钟以后新机器才可用。

    重要

    默认情况下，机器控制器会尝试排空在机器上运行的节点，直到成功为止。在某些情况下，如错误配置了 pod 中断预算，排空操作可能无法成功。如果排空操作失败，机器控制器无法继续删除机器。

    您可以通过在特定机器上注解 machine.openshift.io/exclude-node-draining 来跳过排空节点。

验证

  • 运行以下命令，验证删除所需的机器： 

    $ oc get machines
    Copy to Clipboard Toggle word wrap

MachineSet 对象描述了与云或机器供应商相关的 OpenShift Container Platform 节点。

MachineConfigPool 对象允许 MachineConfigController 组件在升级过程中定义并提供机器的状态。

MachineConfigPool 对象允许用户配置如何将升级应用到机器配置池中的 OpenShift Container Platform 节点。

NodeSelector 对象可以被一个到 MachineSet 对象的引用替换。

返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

Theme

© 2025 Red Hat