×

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

node-maintenance-operator (NMO) 不再与 OpenShift Virtualization 一起提供。它作为独立的 Operator 从 Red Hat OpenShift Service on AWS Web 控制台中的**OperatorHub** 部署,或使用 OpenShift CLI (oc) 部署。

有关补救、隔离和维护节点的更多信息,请参见Red Hat OpenShift 的工作负载可用性文档。

虚拟机 (VM) 必须具有具有共享ReadWriteMany (RWX) 访问模式的持久卷声明 (PVC) 才能进行实时迁移。

节点维护操作符监视新的或已删除的NodeMaintenance CR。检测到新的NodeMaintenance CR 时,不会调度新的工作负载,并且节点将与集群的其余部分隔离开。所有可以驱逐的 Pod 都将从节点中驱逐。删除NodeMaintenance CR 时,CR 中引用的节点将可用于新的工作负载。

使用NodeMaintenance CR 执行节点维护任务可获得与使用标准 Red Hat OpenShift Service on AWS 自定义资源处理的oc adm cordonoc adm drain命令相同的结果。

逐出策略

将节点置于维护状态会将节点标记为不可调度,并从中驱逐所有虚拟机和 Pod。

您可以为虚拟机 (VM) 或集群配置逐出策略。

虚拟机逐出策略

虚拟机LiveMigrate逐出策略可确保如果节点被置于维护状态或被清空,虚拟机实例 (VMI) 不会中断。具有此逐出策略的 VMI 将实时迁移到另一个节点。

您可以使用 OpenShift Virtualization Web 控制台或命令行配置虚拟机 (VM) 的逐出策略。

默认逐出策略为LiveMigrate。具有LiveMigrate逐出策略的不可迁移 VM 可能会阻止节点清空或阻止基础设施升级,因为 VM 未从节点中逐出。除非手动关闭 VM,否则这种情况会导致迁移保持在PendingScheduling状态。

必须将不可迁移 VM 的逐出策略设置为LiveMigrateIfPossible(不会阻止升级)或None(对于不应迁移的 VM)。

使用命令行配置虚拟机逐出策略

您可以使用命令行配置虚拟机 (VM) 的逐出策略。

默认逐出策略为LiveMigrate。具有LiveMigrate逐出策略的不可迁移 VM 可能会阻止节点清空或阻止基础设施升级,因为 VM 未从节点中逐出。除非手动关闭 VM,否则这种情况会导致迁移保持在PendingScheduling状态。

必须将不可迁移 VM 的逐出策略设置为LiveMigrateIfPossible(不会阻止升级)或None(对于不应迁移的 VM)。

步骤
  1. 通过运行以下命令编辑VirtualMachine资源

    $ oc edit vm <vm_name> -n <namespace>
    逐出策略示例
    apiVersion: kubevirt.io/v1
    kind: VirtualMachine
    metadata:
      name: <vm_name>
    spec:
      template:
        spec:
          evictionStrategy: LiveMigrateIfPossible (1)
    # ...
    1 指定逐出策略。默认值为LiveMigrate
  2. 重新启动虚拟机以应用更改

    $ virtctl restart <vm_name> -n <namespace>

运行策略

配置了spec.running: true的虚拟机 (VM) 会立即重新启动。spec.runStrategy密钥提供了更大的灵活性,用于确定虚拟机在某些情况下的行为。

spec.runStrategyspec.running密钥是互斥的。只能使用其中一个。

同时包含这两个密钥的 VM 配置是无效的。

运行策略

spec.runStrategy密钥有四个可能的值

Always

在另一个节点上创建虚拟机 (VM) 时,虚拟机实例 (VMI) 始终存在。如果原始实例因任何原因停止,则会创建一个新的 VMI。这与running: true的行为相同。

RerunOnFailure

如果上一个实例失败,则会在另一个节点上重新创建 VMI。如果虚拟机成功停止(例如,当它被关闭时),则不会重新创建实例。

Manual

您可以使用startstoprestart virtctl 客户端命令手动控制 VMI 状态。虚拟机不会自动重新启动。

Halted

创建虚拟机时,不存在 VMI。这与running: false的行为相同。

virtctl startstoprestart命令的不同组合会影响运行策略。

下表描述了虚拟机在状态之间的转换。第一列显示虚拟机的初始运行策略。其余列显示 virtctl 命令以及运行该命令后的新运行策略。

表 1. virtctl 命令前后运行策略
初始运行策略 启动 停止 重启

Always

-

Halted

Always

RerunOnFailure

-

Halted

RerunOnFailure

Manual

Manual

Manual

Manual

Halted

Always

-

-

如果使用安装程序预配的基础设施安装的集群中的节点未能通过机器运行状况检查并且不可用,则运行策略为runStrategy: AlwaysrunStrategy: RerunOnFailure的虚拟机将在新节点上重新调度。

使用命令行配置虚拟机运行策略

您可以使用命令行配置虚拟机 (VM) 的运行策略。

spec.runStrategyspec.running密钥是互斥的。包含这两个密钥值的 VM 配置是无效的。

步骤
  • 通过运行以下命令编辑VirtualMachine资源

    $ oc edit vm <vm_name> -n <namespace>
    运行策略示例
    apiVersion: kubevirt.io/v1
    kind: VirtualMachine
    spec:
      runStrategy: Always
    # ...

维护裸机节点

在裸机基础设施上部署 Red Hat OpenShift Service on AWS 时,与在云基础设施上部署相比,需要考虑其他因素。与云环境中集群节点被视为临时节点不同,重新配置裸机节点需要花费更多时间和精力才能完成维护任务。

例如,当裸机节点发生故障(例如发生致命内核错误或 NIC 卡硬件故障)时,需要在问题节点得到修复或更换的同时,在集群中的其他位置重新启动故障节点上的工作负载。节点维护模式允许集群管理员优雅地关闭节点,将工作负载移动到集群的其他部分,并确保工作负载不会中断。在维护期间会提供详细的进度和节点状态详细信息。

其他资源