5.3. 部署机器健康检查
理解并部署机器健康检查。
此过程不适用于使用手动置备的机器的集群。您只能在 Machine API 操作的集群中使用高级机器管理和扩展功能。
5.3.1. 关于机器健康检查
机器健康检查自动修复特定机器池中不健康的机器。
要监控机器的健康状况,创建资源来定义控制器的配置。设置要检查的条件(例如,处于 NotReady
状态达到五分钟或 node-problem-detector 中显示了持久性状况),以及用于要监控的机器集合的标签。
您不能对具有 master 角色的机器进行机器健康检查。
监控 MachineHealthCheck
资源的控制器会检查定义的条件。如果机器无法进行健康检查,则会自动删除机器并创建一个机器来代替它。删除机器之后,您会看到机器被删除
事件。
为限制删除机器造成的破坏性影响,控制器一次仅清空并删除一个节点。如果目标机器池中不健康的机器池中不健康的机器数量大于 maxUnhealthy
的值,则补救会停止,需要启用手动干预。
请根据工作负载和要求仔细考虑超时。
- 超时时间较长可能会导致不健康的机器上的工作负载长时间停机。
-
超时时间太短可能会导致补救循环。例如,检查
NotReady
状态的超时时间必须足够长,以便机器能够完成启动过程。
要停止检查,请删除资源。
例如,您应该在升级过程中停止检查,因为集群中的节点可能会临时不可用。MachineHealthCheck
可能会识别不健康的节点,并重新引导它们。为避免重新引导这样的节点,请在更新集群前删除您部署的任何 MachineHealthCheck
资源。但是,默认部署的 MachineHealthCheck
资源(如 machine-api-termination-handler
)不能被删除并重新创建。
5.3.1.1. 部署机器健康检查时的限制
部署机器健康检查前需要考虑以下限制:
- 只有机器集拥有的机器才可以由机器健康检查修复。
- 目前不支持 control plane 机器,如果不健康,则不会被修复。
- 如果机器的节点从集群中移除,机器健康检查会认为机器不健康,并立即修复机器。
-
如果机器对应的节点在
nodeStartupTimeout
之后没有加入集群,则会修复机器。 -
如果
Machine
资源阶段为Failed
,则会立即修复机器。
5.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
只是示例; 您必须根据具体需要映射您的机器组。
5.3.2.1. 短路机器健康检查补救
短路可确保仅在集群健康时机器健康检查修复机器。通过 MachineHealthCheck
资源中的 maxUnhealthy
字段配置短路。
如果用户在修复任何机器前为 maxUnhealthy
字段定义了一个值,MachineHealthCheck
会将 maxUnhealthy
的值与它决定不健康的目标池中的机器数量进行比较。如果不健康的机器数量超过 maxUnhealthy
限制,则不会执行补救。
如果没有设置 maxUnhealthy
,则默认值为 100%
,无论集群状态如何,机器都会被修复。
适当的 maxUnhealthy
值取决于您部署的集群规模以及 MachineHealthCheck
覆盖的机器数量。例如,您可以使用 maxUnhealthy
值覆盖多个可用区间的多个机器集,以便在丢失整个区时,maxUnhealthy
设置可以在集群中阻止进一步补救。
maxUnhealthy
字段可以设置为整数或百分比。根据 maxUnhealthy
值,有不同的补救实现。
5.3.2.1.1. 使用绝对值设置 maxUnhealthy
如果将 maxUnhealthy
设为 2
:
- 如果 2 个或更少节点不健康,则可执行补救
- 如果 3 个或更多节点不健康,则不会执行补救
这些值与机器健康检查要检查的机器数量无关。
5.3.2.1.2. 使用百分比设置 maxUnhealthy
如果 maxUnhealthy
被设置为 40%
,有 25 个机器被检查:
- 如果有 10 个或更少节点处于不健康状态,则可执行补救
- 如果 11 个或多个节点不健康,则不会执行补救
如果 maxUnhealthy
被设置为 40%
,有 6 个机器被检查:
- 如果 2 个或更少节点不健康,则可执行补救
- 如果 3 个或更多节点不健康,则不会执行补救
当被检查的 maxUnhealthy
机器的百分比不是一个整数时,允许的机器数量会被舍入到一个小的整数。
5.3.3. 创建 MachineHealthCheck 资源
您可以为集群中的所有 MachineSet
创建 MachineHealthCheck
资源。您不应该创建针对 control plane 机器的 MachineHealthCheck
资源。
先决条件
-
安装
oc
命令行界面。
流程
-
创建一个
healthcheck.yml
文件,其中包含您的机器健康检查的定义。 将
healthcheck.yml
文件应用到您的集群:$ oc apply -f healthcheck.yml
5.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"
进行 cordon 操作,排空您要删除的节点:
$ oc adm cordon <node_name> $ oc adm drain <node_name>
扩展机器集:
$ 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
您可以扩展或缩减机器集。需要过几分钟以后新机器才可用。
验证
验证删除预期的机器:
$ oc get machines
5.3.5. 了解机器集和机器配置池之间的区别
MachineSet
对象描述了与云或机器供应商相关的 OpenShift Container Platform 节点。
MachineConfigPool
对象允许 MachineConfigController
组件在升级过程中定义并提供机器的状态。
MachineConfigPool
对象允许用户配置如何将升级应用到机器配置池中的 OpenShift Container Platform 节点。
NodeSelector
对象可以被一个到 MachineSet
对象的引用替换。