支持控制台（Console）开发人员开始试用联系人

14.6. 安装程序置备的安装后配置

成功部署安装程序置备的集群后，请考虑以下安装后流程。

14.6.1. 为断开连接的集群配置 NTP

OpenShift Container Platform 在集群节点上安装 chrony 网络时间协议(NTP)服务。使用以下步骤在 control plane 节点上配置 NTP 服务器，并将计算节点配置为成功部署后，将 worker 节点配置为 control plane 节点的 NTP 客户端。

为断开连接的集群配置 NTP

OpenShift Container Platform 节点必须在日期和时间上达成一致才能正确运行。当计算节点从 control plane 节点上的 NTP 服务器检索日期和时间时，它会启用未连接到可路由网络的集群的安装和操作，因此无法访问更高的 stratum NTP 服务器。

流程

  1. 使用以下命令在安装主机上安装 Butane： 

    $ sudo dnf -y install butane

  2. 为 control plane 节点创建一个 Butane 配置 99-master-chrony-conf-override.bu，包括 chrony.conf 文件的内容。

    注意

    如需有关 Butane 的信息，请参阅"使用 Butane 创建机器配置"。

    但ane 配置示例

    variant: openshift
version: 4.17.0
metadata:
  name: 99-master-chrony-conf-override
  labels:
    machineconfiguration.openshift.io/role: master
storage:
  files:
    - path: /etc/chrony.conf
      mode: 0644
      overwrite: true
      contents:
        inline: |
          # Use public servers from the pool.ntp.org project.
          # Please consider joining the pool (https://www.pool.ntp.org/join.html).

          # The Machine Config Operator manages this file
          server openshift-master-0.<cluster-name>.<domain> iburst 1
          server openshift-master-1.<cluster-name>.<domain> iburst
          server openshift-master-2.<cluster-name>.<domain> iburst

          stratumweight 0
          driftfile /var/lib/chrony/drift
          rtcsync
          makestep 10 3
          bindcmdaddress 127.0.0.1
          bindcmdaddress ::1
          keyfile /etc/chrony.keys
          commandkey 1
          generatecommandkey
          noclientlog
          logchange 0.5
          logdir /var/log/chrony

          # Configure the control plane nodes to serve as local NTP servers
          # for all compute nodes, even if they are not in sync with an
          # upstream NTP server.

          # Allow NTP client access from the local network.
          allow all
          # Serve time even if not synchronized to a time source.
          local stratum 3 orphan

    1
    您必须将 <cluster-name> 替换为集群名称，并将 <domain> 替换为完全限定域名。

  3. 使用 Butane 生成 MachineConfig 对象文件 99-master-chrony-conf-override.yaml，其中包含要发送到 control plane 节点的配置： 

    $ butane 99-master-chrony-conf-override.bu -o 99-master-chrony-conf-override.yaml

  4. 为引用 control plane 节点上的 NTP 服务器的计算节点创建 Butane 配置 99-worker-chrony-conf-override.bu，包括 chrony.conf 文件的内容。

    但ane 配置示例

    variant: openshift
version: 4.17.0
metadata:
  name: 99-worker-chrony-conf-override
  labels:
    machineconfiguration.openshift.io/role: worker
storage:
  files:
    - path: /etc/chrony.conf
      mode: 0644
      overwrite: true
      contents:
        inline: |
          # The Machine Config Operator manages this file.
          server openshift-master-0.<cluster-name>.<domain> iburst 1
          server openshift-master-1.<cluster-name>.<domain> iburst
          server openshift-master-2.<cluster-name>.<domain> iburst

          stratumweight 0
          driftfile /var/lib/chrony/drift
          rtcsync
          makestep 10 3
          bindcmdaddress 127.0.0.1
          bindcmdaddress ::1
          keyfile /etc/chrony.keys
          commandkey 1
          generatecommandkey
          noclientlog
          logchange 0.5
          logdir /var/log/chrony

    1
    您必须将 <cluster-name> 替换为集群名称，并将 <domain> 替换为完全限定域名。

  5. 使用 Butane 生成 MachineConfig 对象文件 99-worker-chrony-conf-override.yaml，其中包含要交付至 worker 节点的配置： 

    $ butane 99-worker-chrony-conf-override.bu -o 99-worker-chrony-conf-override.yaml

  6. 将 99-master-chrony-conf-override.yaml 策略应用到 control plane 节点。 

    $ oc apply -f 99-master-chrony-conf-override.yaml

    输出示例

    machineconfig.machineconfiguration.openshift.io/99-master-chrony-conf-override created

  7. 将 99-worker-chrony-conf-override.yaml 策略应用到计算节点。 

    $ oc apply -f 99-worker-chrony-conf-override.yaml

    输出示例

    machineconfig.machineconfiguration.openshift.io/99-worker-chrony-conf-override created

  8. 检查应用的 NTP 设置的状态。 

    $ oc describe machineconfigpool

14.6.2. 安装后启用置备网络

通过为裸机集群提供支持的安装程序和安装程序置备安装，可以在没有 provisioning 网络的情况下部署集群。当每个节点的基板管理控制器可以通过 baremetal 网络 路由时，此功能适用于概念验证集群或仅使用 Redfish 虚拟介质单独部署的情况。

您可在安装后使用 Cluster Baremetal Operator(CBO)启用 置备 网络。

先决条件

  • 必须存在专用物理网络，连接到所有 worker 和 control plane 节点。
  • 您必须隔离原生、未标记的物理网络。
  • 当 provisioningNetwork 配置设置为 Managed 时，网络无法有一个 DHCP 服务器。
  • 您可以省略 OpenShift Container Platform 4.10 中的 provisioningInterface 设置，以使用 bootMACAddress 配置设置。

流程

  1. 设置 provisioningInterface 设置时，首先确定集群节点的调配接口名称。例如： eth0 or eno1。
  2. 在集群节点的 调配 网络接口上启用预引导执行环境(PXE)。

  3. 检索 provisioning 网络的当前状态，并将其保存到 provisioning 自定义资源(CR)文件中： 

    $ oc get provisioning -o yaml > enable-provisioning-nw.yaml

  4. 修改 provisioning CR 文件： 

    $ vim ~/enable-provisioning-nw.yaml

    向下滚动到 provisioningNetwork 配置设置，并将它从 Disabled 改为 Managed。然后，在 provisioningNetwork 设置后添加 provisioningIP、provisioningNetworkCIDR、provisioningDHCPRange、provisioningInterface 和 watchAllNameSpaces 配置设置。为每项设置提供适当的值。 

    apiVersion: v1
items:
- apiVersion: metal3.io/v1alpha1
  kind: Provisioning
  metadata:
    name: provisioning-configuration
  spec:
    provisioningNetwork: 1
    provisioningIP: 2
    provisioningNetworkCIDR: 3
    provisioningDHCPRange: 4
    provisioningInterface: 5
    watchAllNameSpaces: 6
    1
    provisioningNetwork 是 Managed、Unmanaged 或 Disabled 之一。当设置为 Managed 时，Metal3 管理调配网络，CBO 使用配置的 DHCP 服务器部署 Metal3 pod。当设置为 Unmanaged 时，系统管理员手动配置 DHCP 服务器。
    2
    provisioningIP 是 DHCP 服务器和 ironic 用于调配网络的静态 IP 地址。这个静态 IP 地址必须在 provisioning 子网内，且不在 DHCP 范围内。如果配置这个设置，它必须具有有效的 IP 地址，即使 provisioning 网络是 Disabled。静态 IP 地址绑定到 metal3 pod。如果 metal3 pod 失败并移动到其他服务器，静态 IP 地址也会移到新服务器。
    3
    无类别域间路由(CIDR)地址。如果配置这个设置，它必须具有有效的 CIDR 地址，即使 provisioning 网络是 Disabled。例如：192.168.0.1/24。
    4
    DHCP 范围。此设置仅适用于 受管 置备网络。如果 provisioning 网络为 Disabled，则省略此配置设置。例如：192.168.0.64, 192.168.0.253。
    5
    集群节点上 置备 接口的 NIC 名称。provisioningInterface 设置仅适用于 受管和非受管 置备 网络。如果 provisioning 网络为 Disabled，忽略 provisioningInterface 配置设置。省略 provisioningInterface 配置设置，以使用 bootMACAddress 配置设置。
    6
    如果您希望 metal3 监视默认 openshift-machine-api 命名空间以外的命名空间，请将此设置设置为 true。默认值为 false。
  5. 保存对 provisioning CR 文件的更改。

  6. 将 provisioning CR 文件应用到集群： 

    $ oc apply -f enable-provisioning-nw.yaml

14.6.2.1. 创建包含自定义 br-ex 网桥的清单对象

除了使用 configure-ovs.sh shell 脚本在裸机平台上设置自定义 br-ex 网桥，一个替代的选择是创建一个包括自定义 br-ex 网桥网络配置的 NodeNetworkConfigurationPolicy 自定义资源（CR）。

重要

创建包含自定义 br-ex 网桥的 NodeNetworkConfigurationPolicy CR 只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议（SLA）支持，且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能，并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的更多信息，请参阅技术预览功能支持范围。

此功能支持以下任务：

  • 修改集群的最大传输单元 (MTU)。
  • 修改不同绑定接口的属性，如 MIImon （媒体独立接口监控器）、绑定模式或服务质量 (QoS)。
  • 更新 DNS 值。

请考虑以下用例：创建包含自定义 br-ex 网桥的清单对象：

  • 您需要对网桥进行安装后更改，如更改 Open vSwitch (OVS) 或 OVN-Kubernetes br-ex 网桥网络。configure-ovs.sh shell 脚本不支持对网桥进行安装后更改。
  • 您希望将网桥部署到与主机或服务器 IP 地址上可用的接口不同的接口上。
  • 您希望通过 configure-ovs.sh shell 脚本对网桥进行高级配置。对这些配置使用脚本可能会导致网桥无法连接多个网络接口，并无法正确处理接口之间的数据转发。

先决条件

  • 您可以使用 configure-ovs 的替代方法来设置一个自定义的 br-ex。
  • 已安装 Kubernetes NMState Operator。

流程

  1. 创建 NodeNetworkConfigurationPolicy (NNCP) CR，并定义自定义的 br-ex 网桥网络配置。根据您的需要，请确保为 ipv4.address.ip、ipv6.address.ip 或这两个参数设置了一个伪装 IP。伪装 IP 地址必须与正在使用的 IP 地址块匹配。

    设置 IPv6 和 IPv4 伪装 IP 地址的 NNCP CR 示例

    apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: worker-0-br-ex 1
spec:
  nodeSelector:
    kubernetes.io/hostname: worker-0
    desiredState:
    interfaces:
    - name: enp2s0 2
      type: ethernet 3
      state: up 4
      ipv4:
        enabled: false 5
      ipv6:
        enabled: false
    - name: br-ex
      type: ovs-bridge
      state: up
      ipv4:
        enabled: false
        dhcp: false
      ipv6:
        enabled: false
        dhcp: false
      bridge:
        port:
        - name: enp2s0 6
        - name: br-ex
    - name: br-ex
      type: ovs-interface
      state: up
      copy-mac-from: enp2s0
      ipv4:
        enabled: true
        dhcp: true
        address:
        - ip: "169.254.169.2"
          prefix-length: 29
      ipv6:
        enabled: false
        dhcp: false
        address:
        - ip: "fd69::2"
        prefix-length: 125

    1
    策略的名称。
    2
    接口的名称。
    3
    以太网的类型。
    4
    创建后接口的请求状态。
    5
    在这个示例中禁用 IPv4 和 IPv6。
    6
    网桥附加到的节点 NIC。

14.6.3. 使用 Bare Metal Operator 配置

在裸机主机上部署 OpenShift Container Platform 时，有时在置备前或之后需要更改主机。这包括检查主机的硬件、固件和固件详情。它还可以包含格式化磁盘或更改可修改的固件设置。

您可以使用 Bare Metal Operator (BMO)来置备、管理和检查集群中的裸机主机。BMO 可以完成以下操作：

  • 使用特定镜像置备裸机主机到集群。
  • 打开或关闭主机。
  • 检查主机的硬件详情，并将它们报告到裸机主机。
  • 将主机的固件升级或降级到特定版本。
  • 检查固件并配置 BIOS 设置。
  • 在置备主机之前或之后清理主机的磁盘内容。

BMO 使用以下资源来完成这些任务：

  • BareMetalHost
  • HostFirmwareSettings
  • FirmwareSchema
  • HostFirmwareComponents

BMO 通过将每个裸机主机映射到 BareMetalHost 自定义资源定义的实例来维护集群中的物理主机清单。每个 BareMetalHost 资源都有硬件、软件和固件详情。BMO 持续检查集群中的裸机主机，以确保每个 BareMetalHost 资源准确详细说明相应主机的组件。

BMO 还使用 HostFirmwareSettings 资源、FirmwareSchema 资源和 HostFirmwareComponents 资源来详细说明固件规格，以及为裸机主机升级或降级固件。

使用 Ironic API 服务在集群中的裸机主机的 BMO 接口。Ironic 服务使用主机上的 Baseboard Management Controller (BMC) 来与机器进行接口。

14.6.3.1. 裸机 Operator 架构

Bare Metal Operator (BMO) 使用以下资源来置备、管理和检查集群中的裸机主机。下图演示了这些资源的架构：

BMO 架构概述

BareMetalHost

BareMetalHost 资源定义物理主机及其属性。将裸机主机置备到集群时，您必须为该主机定义 BareMetalHost 资源。对于主机的持续管理，您可以检查 BareMetalHost 中的信息或更新此信息。

BareMetalHost 资源具有置备信息，如下所示：

  • 部署规格，如操作系统引导镜像或自定义 RAM 磁盘
  • 置备状态
  • 基板管理控制器 (BMC) 地址
  • 所需的电源状态

BareMetalHost 资源具有硬件信息，如下所示：

  • CPU 数量
  • NIC 的 MAC 地址
  • 主机的存储设备的大小
  • 当前电源状态

HostFirmwareSettings

您可以使用 HostFirmwareSettings 资源来检索和管理主机的固件设置。当主机进入 Available 状态时，Ironic 服务读取主机的固件设置并创建 HostFirmwareSettings 资源。BareMetalHost 资源和 HostFirmwareSettings 资源之间存在一对一映射。

您可以使用 HostFirmwareSettings 资源来检查主机的固件规格，或更新主机的固件规格。

注意

在编辑 HostFirmwareSettings 资源的 spec 字段时，您必须遵循特定于供应商固件的 schema。这个模式在只读 FirmwareSchema 资源中定义。

FirmwareSchema

固件设置因硬件供应商和主机模型而异。FirmwareSchema 资源是一个只读资源，其中包含每个主机模型中每个固件设置的类型和限制。数据通过使用 Ironic 服务直接从 BMC 传递。FirmwareSchema 资源允许您识别 HostFirmwareSettings 资源的 spec 字段中可以指定的有效值。

如果 schema 相同，则 FirmwareSchema 资源可应用到许多 BareMetalHost 资源。

HostFirmwareComponents

Metal3 提供了 HostFirmwareComponents 资源，它描述了 BIOS 和基板管理控制器 (BMC) 固件版本。您可以通过编辑 HostFirmwareComponents 资源的 spec 字段，将主机的固件升级到一个特定版本。这在使用针对特定固件版本测试的验证模式部署时很有用。

其他资源

14.6.3.2. 关于 BareMetalHost 资源

裸机3 引入了 BareMetalHost 资源的概念，它定义了物理主机及其属性。BareMetalHost 资源包含两个部分：

  1. BareMetalHost 规格
  2. BareMetalHost 状态
14.6.3.2.1. BareMetalHost 规格

BareMetalHost 资源的 spec 部分定义了主机所需状态。

表 14.13. BareMetalHost spec
参数描述

automatedCleaningMode

在置备和取消置备过程中启用或禁用自动清理的接口。当设置为 disabled 时，它将跳过自动清理。当设置为 metadata 时，会自动清理会被启用。默认设置为 metadata。 

bmc:
  address:
  credentialsName:
  disableCertificateVerification:

bmc 配置设置包含主机上基板管理控制器(BMC)的连接信息。这些字段包括：

  • address ：与主机的 BMC 控制器通信的 URL。
  • credentialsName ：引用包含 BMC 的用户名和密码的 secret。
  • disableCertificateVerification ：当设置为 true 时跳过证书验证的布尔值。

bootMACAddress

用于置备主机的 NIC 的 MAC 地址。

bootMode

主机的引导模式。它默认为 UEFI，但也可以设置为 legacy 用于 BIOS 引导，或 UEFISecureBoot。

consumerRef

对使用主机的另一个资源的引用。如果另一个资源目前没有使用主机，则它可能为空。例如，当 machine-api 使用主机时，Machine 资源可能会使用主机。

description

提供的字符串，用于帮助识别主机。

externallyProvisioned

指明主机置备和取消置备是在外部管理的布尔值。当设置时：

  • 仍可使用在线字段管理电源状态。
  • 将监控硬件清单，但不会在主机上执行置备或取消置备操作。

firmware

包含有关裸机主机的 BIOS 配置的信息。目前，只有 iRMC、S iDRAC、i iLO4 和 iLO5 BMC 支持 firmware。子字段有：

  • simultaneousMultithreadingEnabled：允许单个物理处理器内核显示为多个逻辑处理器。有效设置为 true 或 false。
  • sriovEnabled: SR-IOV 支持可让虚拟机监控程序创建 PCI-express 设备的虚拟实例，这可能会提高性能。有效设置为 true 或 false。
  • virtualizationEnabled：支持平台硬件的虚拟化。有效设置为 true 或 false。 
image:
  url:
  checksum:
  checksumType:
  format:

image 配置设置包含要部署到主机上的镜像的详细信息。Ironic 需要镜像字段。但是，当 externallyProvisioned 配置设置被设置为 true，且外部管理不需要电源控制时，字段可以为空。此设置支持以下字段：

  • url：部署到主机的镜像的 URL。
  • checksum ：位于 image.url 的镜像的实际校验和值，或包括镜像的校验和的文件 URL。
  • checksumType ：指定 checksum 算法。目前，Image.checksumType 只支持 md5、sha256 和 sha512。默认 checksum 类型为 md5。
  • format ：镜像的磁盘格式。它可以是 raw, qcow2, vdi, vmdk, live-iso 或不设置。把它设置为 raw 可为该镜像在 Ironic 代理中进行原始镜像流处理。将它设置为 live-iso 会启用 iso 镜像在没有部署到磁盘的情况下进行实时引导，它会忽略 checksum 字段。

networkData

对包含网络配置数据及其命名空间的 secret 的引用，以便在主机引导以设置网络前将其附加到主机。

online

指示主机是否应开启的布尔值，true 代表开启，false 代表关闭。更改此值将触发对物理主机的电源状态变化。 

raid:
  hardwareRAIDVolumes:
  softwareRAIDVolumes:

（可选）包含有关裸机主机的 RAID 配置的信息。如果没有指定，它会保留当前的配置。

注意

OpenShift Container Platform 4.17 支持 BMC 的硬件 RAID，包括：

  • Fujitsu iRMC 支持 RAID 0、1、5、6 和 10
  • Dell iDRAC 使用带有固件版本 6.10.30.20 或更高版本和 RAID 级别 0、1 和 5 的 Redfish API

OpenShift Container Platform 4.17 不支持软件 RAID。

请参见以下配置设置：

  • hardwareRAIDVolumes ：包含硬件 RAID 的逻辑驱动器列表，并在硬件 RAID 中定义所需的卷配置。如果没有指定 rootDeviceHints，则第一个卷是 root 卷。子字段是：

    • level ：逻辑驱动器的 RAID 级别。支持以下级别：0,1,2,5,6,1+0,5+0,6+0.
    • name ：卷名称（字符串）。它在服务器中应该是唯一的。如果未指定，则自动生成卷名称。
    • numberOfPhysicalDisks ：物理驱动器的数量，作为用于逻辑 drove 的整数。默认为特定 RAID 级别所需的最小磁盘驱动器数。
    • physicalDisks ：物理磁盘驱动器的名称列表作为字符串。这是可选字段。如果指定，还必须指定 controller 字段。
    • controller ：（可选）RAID 控制器的名称作为要在硬件 RAID 卷中使用的字符串。
    • rotational ：如果设为 true，则它只会选择轮转磁盘驱动器。如果设置为 false，它将只选择固态和 NVMe 驱动器。如果没有设置，则会选择任何驱动器类型，这是默认行为。
    • sizeGibibytes ：逻辑驱动器的大小作为在 GiB 中创建的整数。如果未指定或设置为 0，它将为逻辑驱动器使用物理驱动器的最大容量。

  • softwareRAIDVolumes: OpenShift Container Platform 4.17 不支持软件 RAID。以下信息仅供参考。这个配置包含软件 RAID 的逻辑磁盘列表。如果没有指定 rootDeviceHints，则第一个卷是 root 卷。如果您设置了 HardwareRAIDVolumes，则此项将无效。软件 RAID 总是被删除。创建的软件 RAID 设备的数量必须是 1 或 2。如果只有一个软件 RAID 设备，它必须是 RAID-1。如果有两个 RAID 设备，则第一个设备必须是 RAID-1，而第二个设备的 RAID 级别可以为 0, 1, 或 1+0。第一个 RAID 设备将是部署设备。因此，当设备出现故障时，强制 RAID-1 降低了非引导节点的风险。softwareRAIDVolume 字段定义软件 RAID 中卷所需的配置。子字段是：

    • level ：逻辑驱动器的 RAID 级别。支持以下级别：0,1,1+0。
    • physicalDisks ：设备提示列表.项目数量应大于或等于 2。
    • sizeGibibytes ：逻辑磁盘驱动器的大小作为整数，以 GiB 为单位创建。如果未指定或设置为 0，它将为逻辑驱动器使用物理驱动器的最大容量。

您可以将 hardwareRAIDVolume 设置为空片段，以清除硬件 RAID 配置。例如： 

spec:
   raid:
     hardwareRAIDVolume: []

如果您收到出错信息表示驱动程序不支持 RAID，则将 raid, hardwareRAIDVolumes 或 softwareRAIDVolumes 设置为 nil。您可能需要确保主机具有 RAID 控制器。 

rootDeviceHints:
  deviceName:
  hctl:
  model:
  vendor:
  serialNumber:
  minSizeGigabytes:
  wwn:
  wwnWithExtension:
  wwnVendorExtension:
  rotational:

rootDeviceHints 参数启用将 RHCOS 镜像置备到特定设备。它会按照发现设备的顺序检查设备，并将发现的值与 hint 值进行比较。它使用第一个与 hint 值匹配的发现设备。该配置可组合多个 hints，但设备必须与所有提示都匹配才能被选择。这些字段包括：

  • deviceName：包含类似 /dev/vda 的 Linux 设备名称的字符串。hint 必须与实际值完全匹配。
  • hctl ：包含类似 0:0:0:0 的 SCSI 总线地址的字符串。hint 必须与实际值完全匹配。
  • model ：包含特定厂商的设备标识符的字符串。hint 可以是实际值的子字符串。
  • vendor ：包含该设备厂商或制造商名称的字符串。hint 可以是实际值的子字符串。
  • serialNumber ：包含设备序列号的字符串。hint 必须与实际值完全匹配。
  • minSizeGigabytes ：一个整数，代表设备的最小大小（以 GB 为单位）。
  • wwn ：包含唯一存储标识符的字符串。hint 必须与实际值完全匹配。
  • wwnWithExtension ：包含附加厂商扩展的唯一存储标识符的字符串。hint 必须与实际值完全匹配。
  • wwnVendorExtension ：包含唯一厂商存储标识符的字符串。hint 必须与实际值完全匹配。
  • rotational ：指示该设备应该是旋转磁盘(true)还是非旋转磁盘(false)的布尔值。
14.6.3.2.2. BareMetalHost 状态

BareMetalHost 状态代表主机的当前状态，包括经过测试的凭证、当前的硬件详情和其他信息。

表 14.14. BareMetalHost 状态
参数描述

goodCredentials

对 secret 及其命名空间的引用，其中包含最近一组基板管理控制器(BMC)凭证，以便系统能够验证。

errorMessage

置备后端的最后一个错误的详情（若有）。

errorType

表示导致主机进入错误状态的问题类别。错误类型包括：

  • provisioned registration error：当控制器无法重新注册已置备的主机时发生。
  • registration error ：当控制器无法连接到主机的基板管理控制器时，请注意。
  • inspection error ：尝试从主机获取硬件详细信息时发生错误。
  • preparation error ：在清理失败时生成。
  • provisioning error ：当控制器无法置备或取消置备主机时会发生。
  • power management error ：当控制器无法修改主机的电源状态时会发生。
  • detach error: 当控制器无法从置备程序卸载主机时会发生。 
hardware:
  cpu
    arch:
    model:
    clockMegahertz:
    flags:
    count:

系统中的 CPU 的 hardware.cpu 字段详情。这些字段包括：

  • arch ：CPU 的架构。
  • model: CPU 系列（字符串）
  • clockMegahertz ：CPU 的速度（MHz）。
  • flags: CPU 标记列表。例如，'mmx','sse','sse2','vmx' 等。
  • count: 系统中可用的 CPU 数量。 
hardware:
  firmware:

包含 BIOS 固件信息。例如，硬件供应商和版本。 

hardware:
  nics:
  - ip:
    name:
    mac:
    speedGbps:
    vlans:
    vlanId:
    pxe:

hardware.nics 字段包含主机的网络接口列表。这些字段包括：

  • ip：NIC 的 IP 地址，如果在发现代理运行时是否被分配。
  • name: 标识网络设备的字符串。例如，nic-1。
  • mac: NIC 的 MAC 地址。
  • speedGbps: 设备的速度（Gbps）。
  • vlans: 保存此 NIC 可用的所有 VLAN 的列表。
  • vlanId ：未标记的 VLAN ID。
  • pxe: NIC 是否能够使用 PXE 引导。 
hardware:
  ramMebibytes:

主机的内存量（兆字节(MiB)）。 

hardware:
  storage:
  - name:
    rotational:
    sizeBytes:
    serialNumber:

hardware.storage 字段包含可用于主机的存储设备列表。这些字段包括：

  • name: 标识存储设备的字符串。例如，disk 1 (boot).
  • rotational ：指示磁盘是否为轮转的，返回 true 或 false。
  • sizeBytes ：存储设备的大小。
  • serialNumber ：设备的序列号。 
hardware:
  systemVendor:
    manufacturer:
    productName:
    serialNumber:

包含主机的 manufacturer, productName, 和 serialNumber 的信息。

lastUpdated

主机状态最后一次更新的时间戳。

operationalStatus

服务器的状态。状态为以下之一：

  • OK ：指示主机的所有详细信息均为已知、正确配置、正常工作和可以管理。
  • discovered: 指定某些主机的详细信息无法正常工作或缺失。例如，BMC 地址已知，但登录凭证未知。
  • error: 指示系统发现某种不可恢复的错误。如需更多详细信息，请参阅 status 部分中的 errorMessage 字段。
  • delayed：指示置备延迟来限制同时置备多个主机。
  • detached: 指示主机被标记为 unmanaged。

poweredOn

指明主机是否开机的布尔值。 

provisioning:
  state:
  id:
  image:
  raid:
  firmware:
  rootDeviceHints:

provisioning 字段包含与主机部署镜像相关的值。子字段包括：

  • state: 任何持续置备操作的当前状态。状态包括：

    • <empty string>: 目前没有进行置备。
    • unmanaged: 没有足够的信息来注册主机。
    • registering: 用来检查主机的 BMC 详情的代理
    • match profile ：代理将主机上发现的硬件详情与已知的配置集进行比较。
    • available: 主机可用于置备。这个状态之前被称为 ready。
    • preparing ：现有配置将被删除，新的配置将在主机上设置。
    • provisioning ：置备程序正在将镜像写入主机的存储。
    • provisioned: 置备程序已将镜像写入主机的存储。
    • externally provisioned: Metal3 不管理主机上的镜像。
    • deprovisioning: 置备程序正在从主机的存储中清除镜像。
    • inspecting: 代理正在收集主机的硬件详情。
    • deleting: 代理正在从集群中删除。
  • id: 底层调配工具中服务的唯一标识符。
  • Image ：最近部署到主机的镜像。
  • raid: 最近设定的硬件或软件 RAID 卷列表。
  • firmware: 裸机服务器的 BIOS 配置。
  • rootDeviceHints ：用于最新置备操作的根设备选择说明。

triedCredentials

对 secret 及其命名空间的引用，其中包含发送到置备后端的最后一个 BMC 凭证集合。

14.6.3.3. 获取 BareMetalHost 资源

BareMetalHost 资源包含物理主机的属性。您必须获取物理主机的 BareMetalHost 资源才能查看其属性。

流程

  1. 获取 BareMetalHost 资源列表： 

    $ oc get bmh -n openshift-machine-api -o yaml
    注意

    您可以使用 baremetalhost 作为 oc get 命令的 bmh 长形式。

  2. 获取主机列表： 

    $ oc get bmh -n openshift-machine-api

  3. 获取特定主机的 BareMetalHost 资源： 

    $ oc get bmh <host_name> -n openshift-machine-api -o yaml

    其中 <host_name> 是主机的名称。

    输出示例

    apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
  creationTimestamp: "2022-06-16T10:48:33Z"
  finalizers:
  - baremetalhost.metal3.io
  generation: 2
  name: openshift-worker-0
  namespace: openshift-machine-api
  resourceVersion: "30099"
  uid: 1513ae9b-e092-409d-be1b-ad08edeb1271
spec:
  automatedCleaningMode: metadata
  bmc:
    address: redfish://10.46.61.19:443/redfish/v1/Systems/1
    credentialsName: openshift-worker-0-bmc-secret
    disableCertificateVerification: true
  bootMACAddress: 48:df:37:c7:f7:b0
  bootMode: UEFI
  consumerRef:
    apiVersion: machine.openshift.io/v1beta1
    kind: Machine
    name: ocp-edge-958fk-worker-0-nrfcg
    namespace: openshift-machine-api
  customDeploy:
    method: install_coreos
  online: true
  rootDeviceHints:
    deviceName: /dev/disk/by-id/scsi-<serial_number>
  userData:
    name: worker-user-data-managed
    namespace: openshift-machine-api
status:
  errorCount: 0
  errorMessage: ""
  goodCredentials:
    credentials:
      name: openshift-worker-0-bmc-secret
      namespace: openshift-machine-api
    credentialsVersion: "16120"
  hardware:
    cpu:
      arch: x86_64
      clockMegahertz: 2300
      count: 64
      flags:
      - 3dnowprefetch
      - abm
      - acpi
      - adx
      - aes
      model: Intel(R) Xeon(R) Gold 5218 CPU @ 2.30GHz
    firmware:
      bios:
        date: 10/26/2020
        vendor: HPE
        version: U30
    hostname: openshift-worker-0
    nics:
    - mac: 48:df:37:c7:f7:b3
      model: 0x8086 0x1572
      name: ens1f3
    ramMebibytes: 262144
    storage:
    - hctl: "0:0:0:0"
      model: VK000960GWTTB
      name: /dev/disk/by-id/scsi-<serial_number>
      sizeBytes: 960197124096
      type: SSD
      vendor: ATA
    systemVendor:
      manufacturer: HPE
      productName: ProLiant DL380 Gen10 (868703-B21)
      serialNumber: CZ200606M3
  lastUpdated: "2022-06-16T11:41:42Z"
  operationalStatus: OK
  poweredOn: true
  provisioning:
    ID: 217baa14-cfcf-4196-b764-744e184a3413
    bootMode: UEFI
    customDeploy:
      method: install_coreos
    image:
      url: ""
    raid:
      hardwareRAIDVolumes: null
      softwareRAIDVolumes: []
    rootDeviceHints:
      deviceName: /dev/disk/by-id/scsi-<serial_number>
    state: provisioned
  triedCredentials:
    credentials:
      name: openshift-worker-0-bmc-secret
      namespace: openshift-machine-api
    credentialsVersion: "16120"

14.6.3.4. 编辑 BareMetalHost 资源

在裸机上部署 OpenShift Container Platform 集群后，您可能需要编辑节点的 BareMetalHost 资源。请考虑以下示例：

  • 您可以使用 Assisted Installer 部署集群，并需要添加或编辑基板管理控制器 (BMC) 主机名或 IP 地址。
  • 您需要在不取消置备的情况下将节点从一个集群移到另一个集群。

先决条件

  • 确保节点处于 Provisioned, ExternallyProvisioned, 或 Available 状态。

流程

  1. 获取节点列表： 

    $ oc get bmh -n openshift-machine-api

  2. 在编辑节点的 BareMetalHost 资源前，运行以下命令从 Ironic 分离节点： 

    $ oc annotate baremetalhost <node_name> -n openshift-machine-api 'baremetalhost.metal3.io/detached=true' 1
    1
    将 <node_name> 替换为节点的名称。

  3. 运行以下命令来编辑 BareMetalHost 资源： 

    $ oc edit bmh <node_name> -n openshift-machine-api

  4. 运行以下命令，将节点重新附加到 Ironic： 

    $ oc annotate baremetalhost <node_name> -n openshift-machine-api 'baremetalhost.metal3.io/detached'-

14.6.3.5. 删除 BareMetalHost 资源时的延迟故障排除

当 Bare Metal Operator (BMO)删除 BareMetalHost 资源时，Ironic 会使用名为 cleaning 的进程取消置备裸机主机。当清理失败时，Ironic 会重试清理过程三次，这是延迟的来源。清理过程可能无法成功，从而导致裸机主机的置备状态无限期处于 deleting 状态。当发生这种情况时，请使用以下步骤禁用清理过程。

警告

不要从 BareMetalHost 资源中删除终结器。

流程

  1. 如果清理过程失败并重启，请等待它完成。这大约可能需要 5 分钟。
  2. 如果置备状态处于 delete 状态，请通过修改 BareMetalHost 资源并将 automatedCleaningMode 字段设置为 disabled 来禁用清理过程。

如需了解更多详细信息，请参阅"编辑 BareMetalHost 资源"。

14.6.3.6. 将不可启动的 ISO 附加到裸机节点

您可以使用 DataImage 资源将通用、不可启动的 ISO 虚拟介质镜像附加到置备的节点上。在应用了资源后，操作系统引导后，ISO 镜像将可以被操作系统访问。这可用于在置备操作系统后配置节点，并在节点第一次引导前配置节点。

先决条件

  • 节点必须使用 Redfish 或从中派生的驱动程序来支持此功能。
  • 节点必须处于 Provisioned 或 ExternallyProvisioned 状态。
  • 名称必须与其在 BareMetalHost 资源中定义的节点名称相同。
  • 有 ISO 镜像的有效 url。

流程

  1. 创建一个 DataImage 资源： 

    apiVersion: metal3.io/v1alpha1
kind: DataImage
metadata:
  name: <node_name> 1
spec:
  url: "http://dataimage.example.com/non-bootable.iso" 2
    1
    指定其在 BareMetalHost 资源中定义的节点名称。
    2
    指定 ISO 镜像的 URL 和路径。

  2. 运行以下命令，将 DataImage 资源保存到文件中： 

    $ vim <node_name>-dataimage.yaml

  3. 运行以下命令来应用 DataImage 资源： 

    $ oc apply -f <node_name>-dataimage.yaml -n <node_namespace> 1
    1
    替换 <node_namespace>，以便命名空间与 BareMetalHost 资源的命名空间匹配。例如，openshift-machine-api。

  4. 重新引导节点。

    注意

    要重新引导节点，请附加 reboot.metal3.io 注解，或重置 BareMetalHost 资源中的 online 状态。对裸机节点强制重启会使节点的状态在一段事件内变为 NotReady。例如，5 分钟或更长时间。

  5. 运行以下命令来查看 DataImage 资源： 

    $ oc get dataimage <node_name> -n openshift-machine-api -o yaml

    输出示例

    apiVersion: v1
items:
- apiVersion: metal3.io/v1alpha1
  kind: DataImage
  metadata:
    annotations:
      kubectl.kubernetes.io/last-applied-configuration: |
        {"apiVersion":"metal3.io/v1alpha1","kind":"DataImage","metadata":{"annotations":{},"name":"bmh-node-1","namespace":"openshift-machine-api"},"spec":{"url":"http://dataimage.example.com/non-bootable.iso"}}
    creationTimestamp: "2024-06-10T12:00:00Z"
    finalizers:
    - dataimage.metal3.io
    generation: 1
    name: bmh-node-1
    namespace: openshift-machine-api
    ownerReferences:
    - apiVersion: metal3.io/v1alpha1
      blockOwnerDeletion: true
      controller: true
      kind: BareMetalHost
      name: bmh-node-1
      uid: 046cdf8e-0e97-485a-8866-e62d20e0f0b3
    resourceVersion: "21695581"
    uid: c5718f50-44b6-4a22-a6b7-71197e4b7b69
  spec:
    url: http://dataimage.example.com/non-bootable.iso
  status:
    attachedImage:
      url: http://dataimage.example.com/non-bootable.iso
    error:
      count: 0
      message: ""
    lastReconciled: "2024-06-10T12:05:00Z"

14.6.3.7. 关于 HostFirmwareSettings 资源

您可以使用 HostFirmwareSettings 资源来检索和管理主机的 BIOS 设置。当主机进入 Available 状态时，Ironic 会读取主机的 BIOS 设置并创建 HostFirmwareSettings 资源。资源包含从基板管理控制器(BMC)返回的完整 BIOS 配置。BareMetalHost 资源中的 firmware 字段会返回三个供应商独立的字段，HostFirmwareSettings 资源通常包含每个主机中特定供应商的字段的许多 BIOS 设置。

HostFirmwareSettings 资源包含两个部分：

  1. HostFirmwareSettings spec。
  2. HostFirmwareSettings 状态。
14.6.3.7.1. HostFirmwareSettings spec

HostFirmwareSettings 资源的 spec 部分定义了主机的 BIOS 所需的状态，默认为空。Ironic 使用 spec.settings 部分中的设置，在主机处于 Preparing 状态时更新基板管理控制器(BMC)。使用 FirmwareSchema 资源，确保不向主机发送无效的名称/值对。如需了解更多详细信息，请参阅 "About the FirmwareSchema resource"。

示例

spec:
  settings:
    ProcTurboMode: Disabled1

1
在foregoing示例中，spec.settings 部分包含一个 name/value 对，它将把 ProcTurboMode BIOS 设置为 Disabled。
注意

status 部分中列出的整数参数显示为字符串。例如，"1"。当在 spec.settings 部分中设置整数时，这些值应设置为不带引号的整数。例如，1.

14.6.3.7.2. HostFirmwareSettings 状态

status 代表主机的 BIOS 的当前状态。

表 14.15. HostFirmwareSettings
参数描述
status:
  conditions:
  - lastTransitionTime:
    message:
    observedGeneration:
    reason:
    status:
    type:

conditions 字段包含状态更改列表。子字段包括：

  • lastTransitionTime ：状态更改最后一次的时间。
  • message: 状态更改的描述。
  • observedGeneration ：当前 status 的世代。如果 metadata.generation 和此字段不同，则 status.conditions 可能已过时。
  • reason: 状态更改的原因。
  • status: 状态更改的状态。状态可以是 True, False 或 Unknown。
  • type: 状态更改的类型。类型为 Valid 和 ChangeDetected。 
status:
  schema:
    name:
    namespace:
    lastUpdated:

固件设置的 FirmwareSchema。这些字段包括：

  • name: 引用该模式的名称或唯一标识符。
  • namespace ：存储 schema 的命名空间。
  • lastUpdated: 资源最后一次更新的时间。 
status:
  settings:

settings 字段包含主机当前 BIOS 设置的名称/值对列表。

14.6.3.8. 获取 HostFirmwareSettings 资源

HostFirmwareSettings 资源包含物理主机的特定于供应商的 BIOS 属性。您必须获取物理主机的 HostFirmwareSettings 资源才能查看其 BIOS 属性。

流程

  1. 获取 HostFirmwareSettings 资源的详细列表： 

    $ oc get hfs -n openshift-machine-api -o yaml
    注意

    您可以使用 hostfirmwaresettings 作为 oc get 命令的 hfs 长形式。

  2. 获取 HostFirmwareSettings 资源列表： 

    $ oc get hfs -n openshift-machine-api

  3. 获取特定主机的 HostFirmwareSettings 资源 

    $ oc get hfs <host_name> -n openshift-machine-api -o yaml

    其中 <host_name> 是主机的名称。

14.6.3.9. 编辑 HostFirmwareSettings 资源

您可以编辑已置备的主机的 HostFirmwareSettings。

重要

您只能在主机处于 provisioned 状态时编辑主机，不包括只读值。您不能编辑状态为 externally provisioned 的主机。

流程

  1. 获取 HostFirmwareSettings 资源列表： 

    $ oc get hfs -n openshift-machine-api

  2. 编辑主机的 HostFirmwareSettings 资源： 

    $ oc edit hfs <host_name> -n openshift-machine-api

    其中 <host_name> 是置备的主机的名称。HostFirmwareSettings 资源将在终端的默认编辑器中打开。

  3. 将 name/value 对添加到 spec.settings 部分：

    示例

    spec:
  settings:
    name: value 1

    1
    使用 FirmwareSchema 资源来识别主机的可用设置。您不能设置只读值。
  4. 保存更改并退出编辑器。

  5. 获取主机的机器名称： 

     $ oc get bmh <host_name> -n openshift-machine name

    其中 <host_name> 是主机的名称。机器名称会出现在 CONSUMER 字段下。

  6. 注解机器将其从 machineset 中删除： 

    $ oc annotate machine <machine_name> machine.openshift.io/delete-machine=true -n openshift-machine-api

    其中 <machine_name> 是要删除的机器的名称。

  7. 获取节点列表并计算 worker 节点数量： 

    $ oc get nodes

  8. 获取 machineset： 

    $ oc get machinesets -n openshift-machine-api

  9. 缩放 machineset： 

    $ oc scale machineset <machineset_name> -n openshift-machine-api --replicas=<n-1>

    其中 <machineset_name> 是 machineset 的名称，<n-1> 是 worker 节点数量的减少。

  10. 当主机进入 Available 状态时，扩展 machineset，使 HostFirmwareSettings 资源更改生效： 

    $ oc scale machineset <machineset_name> -n openshift-machine-api --replicas=<n>

    其中 <machineset_name> 是 machineset 的名称，<n> 是 worker 节点的数量。

14.6.3.10. 验证 HostFirmware Settings 资源是否有效

当用户编辑 spec.settings 部分以更改为 HostFirmwareSetting(HFS)资源时，BMO 会针对 FimwareSchema 资源验证更改，这是只读资源。如果设置无效，BMO 会将 status.Condition 的 Type 值设置为 False，并生成事件并将其存储在 HFS 资源中。使用以下步骤验证资源是否有效。

流程

  1. 获取 HostFirmwareSetting 资源列表： 

    $ oc get hfs -n openshift-machine-api

  2. 验证特定主机的 HostFirmwareSettings 资源是否有效： 

    $ oc describe hfs <host_name> -n openshift-machine-api

    其中 <host_name> 是主机的名称。

    输出示例

    Events:
  Type    Reason            Age    From                                    Message
  ----    ------            ----   ----                                    -------
  Normal  ValidationFailed  2m49s  metal3-hostfirmwaresettings-controller  Invalid BIOS setting: Setting ProcTurboMode is invalid, unknown enumeration value - Foo

    重要

    如果响应返回 ValidationFailed，资源配置中会出现一个错误，您必须更新这些值以符合 FirmwareSchema 资源。

14.6.3.11. 关于 FirmwareSchema 资源

BIOS 设置因硬件供应商和主机模型而异。FirmwareSchema 资源是一个只读资源，其中包含每个主机模型中的每个 BIOS 设置的类型和限值。数据直接通过 Ironic 来自 BMC。FirmwareSchema 允许您识别 HostFirmwareSettings 资源的 spec 字段中可以指定的有效值。FirmwareSchema 资源具有从其设置和限值派生的唯一标识符。相同的主机模型使用相同的 FirmwareSchema 标识符。HostFirmwareSettings 的多个实例可能使用相同的 FirmwareSchema。

表 14.16. FirmwareSchema 规格
参数描述
<BIOS_setting_name>
  attribute_type:
  allowable_values:
  lower_bound:
  upper_bound:
  min_length:
  max_length:
  read_only:
  unique:

spec 是由 BIOS 设置名称和设置的限制组成的简单映射。这些字段包括：

  • attribute_type ：设置类型。支持的类型有：

    • Enumeration
    • 整数
    • 字符串
    • 布尔值
  • allowable_values ：当 attribute_type 是 Enumeration 时，允许值的列表。
  • lower_bound ： attribute_type 为 Integer 时允许的最小值。
  • upper_bound ： attribute_type 为 Integer 时允许的最大值。
  • min_length ：当 attribute_type 为 String 时，值的字符串最短长度。
  • max_length ：当 attribute_type 为 String 时，值第字符串最长长度。
  • read_only ： 设置为只读，不可修改。
  • unique ：该设置特定于此主机。

14.6.3.12. 获取 FirmwareSchema 资源

每个供应商的每个主机模型都有不同的 BIOS 设置。在编辑 HostFirmwareSettings 资源的 spec 部分时，您设置的名称/值对必须符合该主机的固件模式。要确保设置有效的名称/值对，请获取主机的 FirmwareSchema 并查看它。

流程

  1. 要获得 FirmwareSchema 资源实例列表，请执行以下操作： 

    $ oc get firmwareschema -n openshift-machine-api

  2. 要获得特定 FirmwareSchema 实例，请执行： 

    $ oc get firmwareschema <instance_name> -n openshift-machine-api -o yaml

    其中 <instance_name> 是 HostFirmwareSettings 资源中所述的 schema 实例的名称（请参阅表 3）。

14.6.3.13. 关于 HostFirmwareComponents 资源

Metal3 提供了 HostFirmwareComponents 资源，它描述了 BIOS 和基板管理控制器 (BMC) 固件版本。HostFirmwareComponents 资源包含两个部分：

  1. HostFirmwareComponents spec
  2. HostFirmwareComponents 状态
14.6.3.13.1. HostFirmwareComponents spec

HostFirmwareComponents 资源的 spec 部分定义主机的 BIOS 和 BMC 版本的所需状态。

表 14.17. HostFirmwareComponents spec
参数描述
updates:
  component:
  url:

updates 配置设置包含要更新的组件。这些字段包括：

  • component：组件的名称。有效设置为 bios 或 bmc。
  • url : 组件固件规格和版本的 URL。
14.6.3.13.2. HostFirmwareComponents 状态

HostFirmwareComponents 资源的 status 部分返回主机的 BIOS 和 BMC 版本的当前状态。

表 14.18. HostFirmwareComponents 状态
参数描述
components:
  component:
  initialVersion:
  currentVersion:
  lastVersionFlashed:
  updatedAt:

components 部分包含组件的状态。这些字段包括：

  • component ：固件组件的名称。它返回 bios 或 bmc。
  • initialVersion ：组件的初始固件版本。在创建 BareMetalHost 资源时，Ironic 会检索此信息。您不能更改它。
  • currentVersion ：组件的当前固件版本。最初，该值与 initialVersion 值匹配，直到 Ironic 更新了裸机主机上的固件。
  • lastVersionFlashed: 在裸机主机上闪存的组件的最新版本。此字段返回 null，直到 Ironic 更新了固件。
  • updatedAt ：Ironic 更新裸机主机的固件时的时间戳。 
updates:
  component:
  url:

updates 配置设置包含更新的组件。这些字段包括：

  • component：组件的名称。
  • url : 组件固件规格和版本的 URL。

14.6.3.14. 获取 HostFirmwareComponents 资源

HostFirmwareComponents 资源包含 BIOS 的特定固件版本，以及物理主机的基板管理控制器 (BMC)。您必须获取物理主机的 HostFirmwareComponents 资源，才能查看固件版本和状态。

流程

  1. 获取 HostFirmwareComponents 资源的详细列表： 

    $ oc get hostfirmwarecomponents -n openshift-machine-api -o yaml

  2. 获取 HostFirmwareComponents 资源列表： 

    $ oc get hostfirmwarecomponents -n openshift-machine-api

  3. 获取特定主机的 HostFirmwareComponents 资源： 

    $ oc get hostfirmwarecomponents <host_name> -n openshift-machine-api -o yaml

    其中 <host_name> 是主机的名称。

    输出示例

    ---
apiVersion: metal3.io/v1alpha1
kind: HostFirmwareComponents
metadata:
  creationTimestamp: 2024-04-25T20:32:06Z"
  generation: 1
  name: ostest-master-2
  namespace: openshift-machine-api
  ownerReferences:
  - apiVersion: metal3.io/v1alpha1
    blockOwnerDeletion: true
    controller: true
    kind: BareMetalHost
    name: ostest-master-2
    uid: 16022566-7850-4dc8-9e7d-f216211d4195
  resourceVersion: "2437"
  uid: 2038d63f-afc0-4413-8ffe-2f8e098d1f6c
spec:
  updates: []
status:
  components:
  - component: bios
    currentVersion: 1.0.0
    initialVersion: 1.0.0
  - component: bmc
    currentVersion: "1.00"
    initialVersion: "1.00"
  conditions:
  - lastTransitionTime: "2024-04-25T20:32:06Z"
    message: ""
    observedGeneration: 1
    reason: OK
    status: "True"
    type: Valid
  - lastTransitionTime: "2024-04-25T20:32:06Z"
    message: ""
    observedGeneration: 1
    reason: OK
    status: "False"
    type: ChangeDetected
  lastUpdated: "2024-04-25T20:32:06Z"
  updates: []

14.6.3.15. 编辑 HostFirmwareComponents 资源

您可以编辑节点的 HostFirmwareComponents 资源。

流程

  1. 获取 HostFirmwareComponents 资源的详细列表： 

    $ oc get hostfirmwarecomponents -n openshift-machine-api -o yaml

  2. 编辑主机的 HostFirmwareComponents 资源： 

    $ oc edit <host_name> hostfirmwarecomponents -n openshift-machine-api 1
    1
    其中 <host_name> 是主机的名称。HostFirmwareComponents 资源将在终端的默认编辑器中打开。

    输出示例

    ---
apiVersion: metal3.io/v1alpha1
kind: HostFirmwareComponents
metadata:
  creationTimestamp: 2024-04-25T20:32:06Z"
  generation: 1
  name: ostest-master-2
  namespace: openshift-machine-api
  ownerReferences:
  - apiVersion: metal3.io/v1alpha1
    blockOwnerDeletion: true
    controller: true
    kind: BareMetalHost
    name: ostest-master-2
    uid: 16022566-7850-4dc8-9e7d-f216211d4195
  resourceVersion: "2437"
  uid: 2038d63f-afc0-4413-8ffe-2f8e098d1f6c
spec:
  updates:
    - name: bios 1
      url: https://myurl.with.firmware.for.bios 2
    - name: bmc 3
      url: https://myurl.with.firmware.for.bmc 4
status:
  components:
  - component: bios
    currentVersion: 1.0.0
    initialVersion: 1.0.0
  - component: bmc
    currentVersion: "1.00"
    initialVersion: "1.00"
  conditions:
  - lastTransitionTime: "2024-04-25T20:32:06Z"
    message: ""
    observedGeneration: 1
    reason: OK
    status: "True"
    type: Valid
  - lastTransitionTime: "2024-04-25T20:32:06Z"
    message: ""
    observedGeneration: 1
    reason: OK
    status: "False"
    type: ChangeDetected
  lastUpdated: "2024-04-25T20:32:06Z"

    1
    要设置 BIOS 版本，请将 name 属性设置为 bios。
    2
    要设置 BIOS 版本，请将 url 属性设置为 BIOS 固件版本的 URL。
    3
    要设置 BMC 版本，请将 name 属性设置为 bmc。
    4
    要设置 BMC 版本，请将 url 属性设置为 BMC 固件的 URL。
  3. 保存更改并退出编辑器。

  4. 获取主机的机器名称： 

    $ oc get bmh <host_name> -n openshift-machine name 1
    1
    其中 <host_name> 是主机的名称。机器名称会出现在 CONSUMER 字段下。

  5. 注解机器将其从机器集中删除： 

    $ oc annotate machine <machine_name> machine.openshift.io/delete-machine=true -n openshift-machine-api 1
    1
    其中 <machine_name> 是要删除的机器的名称。

  6. 获取节点列表并计算 worker 节点数量： 

    $ oc get nodes

  7. 获取机器集： 

    $ oc get machinesets -n openshift-machine-api

  8. 扩展机器集： 

    $ oc scale machineset <machineset_name> -n openshift-machine-api --replicas=<n-1> 1
    1
    其中 <machineset_name> 是集群集的名称，<n-1> 是减少的 worker 节点数量。

  9. 当主机进入 Available 状态时，扩展 machineset，使 HostFirmwareComponents 资源更改生效： 

    $ oc scale machineset <machineset_name> -n openshift-machine-api --replicas=<n> 1
    1
    其中 <machineset_name> 是机器集的名称，<n> 是 worker 节点的数量。
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

© 2024 Red Hat, Inc.