7.3. 部署机器健康检查
理解并部署机器健康检查。
您只能在 Machine API 操作的集群中使用高级机器管理和扩展功能。具有用户置备的基础架构的集群需要额外的验证和配置才能使用 Machine API。
具有基础架构平台类型 none 的集群无法使用 Machine API。即使附加到集群的计算机器安装在支持该功能的平台上，也会应用这个限制。在安装后无法更改此参数。
要查看集群的平台类型，请运行以下命令：
$ oc get infrastructure cluster -o jsonpath='{.status.platform}'7.3.1. 关于机器健康检查
机器健康检查自动修复特定机器池中不健康的机器。
要监控机器的健康状况，创建资源来定义控制器的配置。设置要检查的条件（例如，处于 NotReady 状态达到五分钟或 node-problem-detector 中显示了持久性状况），以及用于要监控的机器集合的标签。
您不能对具有 master 角色的机器进行机器健康检查。
监控 MachineHealthCheck 资源的控制器会检查定义的条件。如果机器无法进行健康检查，则会自动删除机器并创建一个机器来代替它。删除机器之后，您会看到机器被删除事件。
为限制删除机器造成的破坏性影响，控制器一次仅清空并删除一个节点。如果目标机器池中不健康的机器池中不健康的机器数量大于 maxUnhealthy 的值，则补救会停止，需要启用手动干预。
请根据工作负载和要求仔细考虑超时。
- 超时时间较长可能会导致不健康的机器上的工作负载长时间停机。
-
超时时间太短可能会导致补救循环。例如，检查
NotReady状态的超时时间必须足够长，以便机器能够完成启动过程。
要停止检查，请删除资源。
7.3.1.1. 部署机器健康检查时的限制
部署机器健康检查前需要考虑以下限制：
- 只有机器集拥有的机器才可以由机器健康检查修复。
- 目前不支持 control plane 机器，如果不健康，则不会被修复。
- 如果机器的节点从集群中移除，机器健康检查会认为机器不健康，并立即修复机器。
-
如果机器对应的节点在
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
matchLabels 只是示例; 您必须根据具体需要映射您的机器组。
7.3.2.1. 短路机器健康检查补救
短路可确保仅在集群健康时机器健康检查修复机器。通过 MachineHealthCheck 资源中的 maxUnhealthy 字段配置短路。
如果用户在修复任何机器前为 maxUnhealthy 字段定义了一个值，MachineHealthCheck 会将 maxUnhealthy 的值与它决定不健康的目标池中的机器数量进行比较。如果不健康的机器数量超过 maxUnhealthy 限制，则不会执行补救。
如果没有设置 maxUnhealthy，则默认值为 100%，无论集群状态如何，机器都会被修复。
适当的 maxUnhealthy 值取决于您部署的集群规模以及 MachineHealthCheck 覆盖的机器数量。例如，您可以使用 maxUnhealthy 值覆盖多个可用区间的多个机器集，以便在丢失整个区时，maxUnhealthy 设置可以在集群中阻止进一步补救。在没有多个可用区的全局 Azure 区域，您可以使用可用性集来确保高可用性。
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 资源
您可以为集群中的所有 MachineSet 创建 MachineHealthCheck 资源。您不应该创建针对 control plane 机器的 MachineHealthCheck 资源。
先决条件
-
安装
oc命令行界面。
流程
-
创建一个
healthcheck.yml文件，其中包含您的机器健康检查的定义。 将
healthcheck.yml文件应用到您的集群：$ oc apply -f healthcheck.yml
7.3.4. 手动扩展机器集
要在机器集中添加或删除机器实例，您可以手动扩展机器集。
这个指南与全自动的、安装程序置备的基础架构安装相关。自定义的、用户置备的基础架构安装没有机器集。
先决条件
-
安装 OpenShift Container Platform 集群和
oc命令行。 -
以具有
cluster-admin权限的用户身份登录oc。
流程
查看集群中的机器集：
$ oc get machinesets -n openshift-machine-api
机器集以
<clusterid>-worker-<aws-region-az>的形式列出。查看集群中的机器：
$ oc get machine -n openshift-machine-api
在您要删除的机器上设置注解：
$ oc annotate machine/<machine_name> -n openshift-machine-api machine.openshift.io/cluster-api-delete-machine="true"
运行以下命令来扩展机器集：
$ oc scale --replicas=2 machineset <machineset> -n openshift-machine-api
或者：
$ oc edit machineset <machineset> -n openshift-machine-api
提示您还可以应用以下 YAML 来扩展机器集：
apiVersion: machine.openshift.io/v1beta1 kind: MachineSet metadata: name: <machineset> namespace: openshift-machine-api spec: replicas: 2
您可以扩展或缩减机器集。需要过几分钟以后新机器才可用。
重要默认情况下，机器控制器会尝试排空在机器上运行的节点，直到成功为止。在某些情况下，如错误配置了 pod 中断预算，排空操作可能无法成功。如果排空操作失败，机器控制器无法继续删除机器。
您可以通过在特定机器上注解
machine.openshift.io/exclude-node-draining来跳过排空节点。
验证
验证删除预期的机器：
$ oc get machines
7.3.5. 了解机器集和机器配置池之间的区别
MachineSet 对象描述了与云或机器供应商相关的 OpenShift Container Platform 节点。
MachineConfigPool 对象允许 MachineConfigController 组件在升级过程中定义并提供机器的状态。
MachineConfigPool 对象允许用户配置如何将升级应用到机器配置池中的 OpenShift Container Platform 节点。
NodeSelector 对象可以被一个到 MachineSet 对象的引用替换。
