安装后配置 - 在裸机上部署安装程序置备的集群 | 安装 | OpenShift Container Platform 4.17

为断开连接的集群配置 NTP

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

Configuring NTP for disconnected clusters

OpenShift Container Platform 节点必须就日期和时间达成一致才能正常运行。当计算节点从控制平面节点上的 NTP 服务器检索日期和时间时，它允许安装和操作未连接到可路由网络且因此无法访问更高层 NTP 服务器的集群。

步骤

使用以下命令在安装主机上安装 Butane
```
$ sudo dnf -y install butane
```

创建一个 Butane 配置文件，99-master-chrony-conf-override.bu，其中包含控制平面节点的chrony.conf文件的内容。

有关 Butane 的信息，请参见“使用 Butane 创建机器配置”。

Butane 配置示例

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>`替换为完全限定域名。

使用 Butane 生成一个MachineConfig对象文件，99-master-chrony-conf-override.yaml，其中包含要传递到控制平面节点的配置。
```
$ butane 99-master-chrony-conf-override.bu -o 99-master-chrony-conf-override.yaml
```

创建一个 Butane 配置文件，99-worker-chrony-conf-override.bu，其中包含引用控制平面节点上的 NTP 服务器的计算节点的chrony.conf文件的内容。

Butane 配置示例

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>`替换为完全限定域名。

使用 Butane 生成一个MachineConfig对象文件，99-worker-chrony-conf-override.yaml，其中包含要传递到工作节点的配置。
```
$ butane 99-worker-chrony-conf-override.bu -o 99-worker-chrony-conf-override.yaml
```

将99-master-chrony-conf-override.yaml策略应用于控制平面节点。

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

示例输出

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

将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

检查已应用的 NTP 设置的状态。
```
$ oc describe machineconfigpool
```

安装后启用配置网络

裸机集群的辅助安装程序和安装程序预配安装提供了在没有provisioning网络的情况下部署集群的功能。此功能适用于概念验证集群或在每个节点的基板管理控制器通过baremetal网络可路由时专门使用 Redfish 虚拟介质进行部署的场景。

安装后，您可以使用集群裸机操作符 (CBO) 启用provisioning网络。

先决条件

必须存在连接到所有工作节点和控制平面节点的专用物理网络。
必须隔离本机未标记的物理网络。
当provisioningNetwork配置设置为Managed时，网络不能有DHCP服务器。
在OpenShift Container Platform 4.10中，您可以省略provisioningInterface设置以使用bootMACAddress配置设置。

步骤

设置provisioningInterface设置时，首先确定集群节点的配置接口名称。例如，eth0或eno1。
在集群节点的provisioning网络接口上启用预启动执行环境 (PXE)。
检索provisioning网络的当前状态并将其保存到配置自定义资源 (CR) 文件中。
```
$ oc get provisioning -o yaml > enable-provisioning-nw.yaml
```

修改配置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范围之外。如果配置此设置，即使`provisioning`网络为`Disabled`，它也必须具有有效的IP地址。静态IP地址绑定到metal3 pod。如果metal3 pod 失败并移动到另一台服务器，静态IP地址也会移动到新服务器。
3	无类别域间路由 (CIDR) 地址。如果配置此设置，即使`provisioning`网络为`Disabled`，它也必须具有有效的CIDR地址。例如：`192.168.0.1/24`。
4	DHCP范围。此设置仅适用于`Managed`配置网络。如果`provisioning`网络为`Disabled`，则省略此配置设置。例如：`192.168.0.64, 192.168.0.253`。
5	集群节点上`provisioning`接口的网卡名称。`provisioningInterface`设置仅适用于`Managed`和`Unmanaged`配置网络。如果`provisioning`网络为`Disabled`，则省略`provisioningInterface`配置设置。省略`provisioningInterface`配置设置以改用`bootMACAddress`配置设置。
6	如果希望metal3监视除默认`openshift-machine-api`命名空间以外的其他命名空间，则将此设置为`true`。默认值为`false`。

将更改保存到配置CR文件。

将配置CR文件应用到集群。

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

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

作为使用configure-ovs.sh shell脚本在裸机平台上设置自定义br-ex桥的替代方法，您可以创建一个包含自定义br-ex桥网络配置的NodeNetworkConfigurationPolicy自定义资源 (CR)。

创建包含自定义br-ex桥的NodeNetworkConfigurationPolicy CR 仅为技术预览功能。技术预览功能不受 Red Hat 生产服务级别协议 (SLA) 的支持，并且可能功能不完整。Red Hat 不建议在生产环境中使用它们。这些功能可让您抢先体验即将推出的产品功能，使客户能够在开发过程中测试功能并提供反馈。

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

此功能支持以下任务：

修改集群的最大传输单元 (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 运算符。

步骤

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

作为安装后任务，您可以配置在现有 NNCP CR 中定义的自定义br-ex桥的大多数参数，但 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	桥连接到的节点网卡。

用户管理的负载均衡器的服务

您可以将 OpenShift Container Platform 集群配置为使用用户管理的负载均衡器来代替默认负载均衡器。

配置用户管理的负载均衡器取决于您的供应商的负载均衡器。

本节中的信息和示例仅供指导之用。请咨询供应商文档以获取有关供应商负载均衡器的更多具体信息。

Red Hat 支持以下用户管理负载均衡器的服务：

入口控制器
OpenShift API
OpenShift MachineConfig API

您可以选择是否要为用户管理的负载均衡器配置一项或所有这些服务。仅配置入口控制器服务是一个常见的配置选项。为了更好地理解每项服务，请查看以下图表：

An image that shows an example network workflow of an Ingress Controller operating in an OpenShift Container Platform environment.

图 1. 显示入口控制器在 OpenShift Container Platform 环境中运行的示例网络工作流

An image that shows an example network workflow of an OpenShift API operating in an OpenShift Container Platform environment.

图 2. 显示 OpenShift API 在 OpenShift Container Platform 环境中运行的示例网络工作流

An image that shows an example network workflow of an OpenShift MachineConfig API operating in an OpenShift Container Platform environment.

图 3. 显示 OpenShift MachineConfig API 在 OpenShift Container Platform 环境中运行的示例网络工作流

以下配置选项受用户管理的负载均衡器支持：

使用节点选择器将入口控制器映射到特定节点集。您必须为此集合中的每个节点分配静态 IP 地址，或将每个节点配置为从动态主机配置协议 (DHCP) 接收相同的 IP 地址。基础设施节点通常会收到此类配置。
定位子网上的所有 IP 地址。此配置可以减少维护开销，因为您可以在这些网络中创建和销毁节点而无需重新配置负载均衡器目标。如果您使用机器集在较小的网络（例如 /27 或 /28）上部署入口 Pod，则可以简化负载均衡器目标。

您可以通过检查机器配置池的资源来列出网络中存在的所有 IP 地址。

在为 OpenShift Container Platform 集群配置用户管理的负载均衡器之前，请考虑以下信息：

对于前端 IP 地址，您可以使用相同的 IP 地址作为前端 IP 地址、Ingress Controller 的负载均衡器和 API 负载均衡器。请检查厂商文档以了解此功能。
对于后端 IP 地址，请确保 OpenShift Container Platform 控制平面节点的 IP 地址在用户管理的负载均衡器的生命周期内不会更改。您可以通过完成以下操作之一来实现此目的
- 为每个控制平面节点分配静态 IP 地址。
- 配置每个节点，使其每次请求 DHCP 租约时都从 DHCP 接收相同的 IP 地址。根据厂商的不同，DHCP 租约可能是 IP 预留或静态 DHCP 分配。
在用户管理的负载均衡器中手动定义运行 Ingress Controller 的每个节点，用于 Ingress Controller 后端服务。例如，如果 Ingress Controller 移动到未定义的节点，则可能会发生连接中断。

配置用户管理的负载均衡器

您可以将 OpenShift Container Platform 集群配置为使用用户管理的负载均衡器来代替默认负载均衡器。

在配置用户管理的负载均衡器之前，请确保您已阅读“用户管理负载均衡器的服务”部分。

阅读以下适用于您要为用户管理的负载均衡器配置的服务的先决条件。

在集群上运行的 MetalLB 充当用户管理的负载均衡器。

OpenShift API 先决条件

您已定义前端 IP 地址。
负载均衡器的前端 IP 地址上公开了 TCP 端口 6443 和 22623。请检查以下项目
- 端口 6443 提供对 OpenShift API 服务的访问。
- 端口 22623 可以为节点提供启动配置。
所有位于 OpenShift Container Platform 集群外部位置的系统用户都可以访问前端 IP 地址和端口 6443。
只有 OpenShift Container Platform 节点才能访问前端 IP 地址和端口 22623。
负载均衡器后端可以与 OpenShift Container Platform 控制平面节点的 6443 和 22623 端口进行通信。

Ingress Controller 先决条件

您已定义前端 IP 地址。
负载均衡器的前端 IP 地址上公开了 TCP 端口 443 和 80。
所有位于 OpenShift Container Platform 集群外部位置的系统用户都可以访问前端 IP 地址、端口 80 和端口 443。
OpenShift Container Platform 集群中运行的所有节点都可以访问前端 IP 地址、端口 80 和端口 443。
负载均衡器后端可以与运行 Ingress Controller 的 OpenShift Container Platform 节点的 80、443 和 1936 端口进行通信。

健康检查 URL 规范的先决条件

您可以通过设置健康检查 URL 来配置大多数负载均衡器，这些 URL 用于确定服务是可用还是不可用。OpenShift Container Platform 为 OpenShift API、机器配置 API 和 Ingress Controller 后端服务提供这些健康检查。

以下示例显示了前面列出的后端服务的健康检查规范

Kubernetes API 健康检查规范示例

Path: HTTPS:6443/readyz
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 10
Interval: 10

机器配置 API 健康检查规范示例

Path: HTTPS:22623/healthz
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 10
Interval: 10

Ingress Controller 健康检查规范示例

Path: HTTP:1936/healthz/ready
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 5
Interval: 10

步骤

配置 HAProxy Ingress Controller，以便您可以通过负载均衡器访问 6443、22623、443 和 80 端口上的集群。根据您的需求，您可以在 HAProxy 配置中指定单个子网的 IP 地址或多个子网的 IP 地址。

列出一个子网的 HAProxy 配置示例

# ...
listen my-cluster-api-6443
    bind 192.168.1.100:6443
    mode tcp
    balance roundrobin
  option httpchk
  http-check connect
  http-check send meth GET uri /readyz
  http-check expect status 200
    server my-cluster-master-2 192.168.1.101:6443 check inter 10s rise 2 fall 2
    server my-cluster-master-0 192.168.1.102:6443 check inter 10s rise 2 fall 2
    server my-cluster-master-1 192.168.1.103:6443 check inter 10s rise 2 fall 2

listen my-cluster-machine-config-api-22623
    bind 192.168.1.100:22623
    mode tcp
    balance roundrobin
  option httpchk
  http-check connect
  http-check send meth GET uri /healthz
  http-check expect status 200
    server my-cluster-master-2 192.168.1.101:22623 check inter 10s rise 2 fall 2
    server my-cluster-master-0 192.168.1.102:22623 check inter 10s rise 2 fall 2
    server my-cluster-master-1 192.168.1.103:22623 check inter 10s rise 2 fall 2

listen my-cluster-apps-443
    bind 192.168.1.100:443
    mode tcp
    balance roundrobin
  option httpchk
  http-check connect
  http-check send meth GET uri /healthz/ready
  http-check expect status 200
    server my-cluster-worker-0 192.168.1.111:443 check port 1936 inter 10s rise 2 fall 2
    server my-cluster-worker-1 192.168.1.112:443 check port 1936 inter 10s rise 2 fall 2
    server my-cluster-worker-2 192.168.1.113:443 check port 1936 inter 10s rise 2 fall 2

listen my-cluster-apps-80
   bind 192.168.1.100:80
   mode tcp
   balance roundrobin
  option httpchk
  http-check connect
  http-check send meth GET uri /healthz/ready
  http-check expect status 200
    server my-cluster-worker-0 192.168.1.111:80 check port 1936 inter 10s rise 2 fall 2
    server my-cluster-worker-1 192.168.1.112:80 check port 1936 inter 10s rise 2 fall 2
    server my-cluster-worker-2 192.168.1.113:80 check port 1936 inter 10s rise 2 fall 2
# ...

列出多个子网的 HAProxy 配置示例

# ...
listen api-server-6443
    bind *:6443
    mode tcp
      server master-00 192.168.83.89:6443 check inter 1s
      server master-01 192.168.84.90:6443 check inter 1s
      server master-02 192.168.85.99:6443 check inter 1s
      server bootstrap 192.168.80.89:6443 check inter 1s

listen machine-config-server-22623
    bind *:22623
    mode tcp
      server master-00 192.168.83.89:22623 check inter 1s
      server master-01 192.168.84.90:22623 check inter 1s
      server master-02 192.168.85.99:22623 check inter 1s
      server bootstrap 192.168.80.89:22623 check inter 1s

listen ingress-router-80
    bind *:80
    mode tcp
    balance source
      server worker-00 192.168.83.100:80 check inter 1s
      server worker-01 192.168.83.101:80 check inter 1s

listen ingress-router-443
    bind *:443
    mode tcp
    balance source
      server worker-00 192.168.83.100:443 check inter 1s
      server worker-01 192.168.83.101:443 check inter 1s

listen ironic-api-6385
    bind *:6385
    mode tcp
    balance source
      server master-00 192.168.83.89:6385 check inter 1s
      server master-01 192.168.84.90:6385 check inter 1s
      server master-02 192.168.85.99:6385 check inter 1s
      server bootstrap 192.168.80.89:6385 check inter 1s

listen inspector-api-5050
    bind *:5050
    mode tcp
    balance source
      server master-00 192.168.83.89:5050 check inter 1s
      server master-01 192.168.84.90:5050 check inter 1s
      server master-02 192.168.85.99:5050 check inter 1s
      server bootstrap 192.168.80.89:5050 check inter 1s
# ...

使用 `curl` CLI 命令验证用户管理的负载均衡器及其资源是否正在运行

通过运行以下命令并观察响应，验证集群机器配置 API 是否可被 Kubernetes API 服务器资源访问

$ curl https://<loadbalancer_ip_address>:6443/version --insecure

如果配置正确，您将收到 JSON 对象作为响应

{
  "major": "1",
  "minor": "11+",
  "gitVersion": "v1.11.0+ad103ed",
  "gitCommit": "ad103ed",
  "gitTreeState": "clean",
  "buildDate": "2019-01-09T06:44:10Z",
  "goVersion": "go1.10.3",
  "compiler": "gc",
  "platform": "linux/amd64"
}

通过运行以下命令并观察输出，验证集群机器配置 API 是否可被机器配置服务器资源访问
```
$ curl -v https://<loadbalancer_ip_address>:22623/healthz --insecure
```
如果配置正确，命令的输出将显示以下响应
```
HTTP/1.1 200 OK
Content-Length: 0
```

通过运行以下命令并观察输出，验证控制器是否可被 80 端口上的 Ingress Controller 资源访问

$ curl -I -L -H "Host: console-openshift-console.apps.<cluster_name>.<base_domain>" http://<load_balancer_front_end_IP_address>

如果配置正确，命令的输出将显示以下响应

HTTP/1.1 302 Found
content-length: 0
location: https://console-openshift-console.apps.ocp4.private.opequon.net/
cache-control: no-cache

通过运行以下命令并观察输出，验证控制器是否可被 443 端口上的 Ingress Controller 资源访问

$ curl -I -L --insecure --resolve console-openshift-console.apps.<cluster_name>.<base_domain>:443:<Load Balancer Front End IP Address> https://console-openshift-console.apps.<cluster_name>.<base_domain>

如果配置正确，命令的输出将显示以下响应

HTTP/1.1 200 OK
referrer-policy: strict-origin-when-cross-origin
set-cookie: csrf-token=UlYWOyQ62LWjw2h003xtYSKlh1a0Py2hhctw0WmV2YEdhJjFyQwWcGBsja261dGLgaYO0nxzVErhiXt6QepA7g==; Path=/; Secure; SameSite=Lax
x-content-type-options: nosniff
x-dns-prefetch-control: off
x-frame-options: DENY
x-xss-protection: 1; mode=block
date: Wed, 04 Oct 2023 16:29:38 GMT
content-type: text/html; charset=utf-8
set-cookie: 1e2670d92730b515ce3a1bb65da45062=1bf5e9573c9a2760c964ed1659cc1673; path=/; HttpOnly; Secure; SameSite=None
cache-control: private

配置集群的 DNS 记录以指向用户管理的负载均衡器的前端 IP 地址。您必须更新集群 API 和通过负载均衡器访问应用程序的 DNS 服务器的记录。
修改后的 DNS 记录示例
```
<load_balancer_ip_address>  A  api.<cluster_name>.<base_domain>
A record pointing to Load Balancer Front End
```
```
<load_balancer_ip_address>   A apps.<cluster_name>.<base_domain>
A record pointing to Load Balancer Front End
```
每个 DNS 记录的传播可能需要一些时间才能可用。请确保每个 DNS 记录都已传播后再进行验证。

为了让您的 OpenShift Container Platform 集群使用用户管理的负载均衡器，您必须在集群的 `install-config.yaml` 文件中指定以下配置

# ...
platform:
    loadBalancer:
      type: UserManaged (1)
      apiVIPs:
      - <api_ip> (2)
      ingressVIPs:
      - <ingress_ip> (3)
# ...

1	为 `type` 参数设置 `UserManaged`，以指定集群的用户管理的负载均衡器。此参数默认为 `OpenShiftManagedDefault`，表示默认的内部负载均衡器。对于在 `openshift-kni-infra` 命名空间中定义的服务，用户管理的负载均衡器可以将 `coredns` 服务部署到集群中的 Pod，但会忽略 `keepalived` 和 `haproxy` 服务。
2	指定用户管理的负载均衡器时所需的參數。指定用户管理的负载均衡器的公共 IP 地址，以便 Kubernetes API 可以与用户管理的负载均衡器进行通信。
3	指定用户管理的负载均衡器时所需的參數。指定用户管理的负载均衡器的公共 IP 地址，以便用户管理的负载均衡器可以管理集群的入口流量。

验证

使用 `curl` CLI 命令验证用户管理的负载均衡器和 DNS 记录配置是否正在运行

通过运行以下命令并观察输出，验证您是否可以访问集群 API

$ curl https://api.<cluster_name>.<base_domain>:6443/version --insecure

如果配置正确，您将收到 JSON 对象作为响应

{
  "major": "1",
  "minor": "11+",
  "gitVersion": "v1.11.0+ad103ed",
  "gitCommit": "ad103ed",
  "gitTreeState": "clean",
  "buildDate": "2019-01-09T06:44:10Z",
  "goVersion": "go1.10.3",
  "compiler": "gc",
  "platform": "linux/amd64"
  }

通过运行以下命令并观察输出，验证您是否可以访问集群机器配置
```
$ curl -v https://api.<cluster_name>.<base_domain>:22623/healthz --insecure
```
如果配置正确，命令的输出将显示以下响应
```
HTTP/1.1 200 OK
Content-Length: 0
```

通过运行以下命令并观察输出，验证您是否可以访问每个集群应用程序的端口

$ curl http://console-openshift-console.apps.<cluster_name>.<base_domain> -I -L --insecure

如果配置正确，命令的输出将显示以下响应

HTTP/1.1 302 Found
content-length: 0
location: https://console-openshift-console.apps.<cluster-name>.<base domain>/
cache-control: no-cacheHTTP/1.1 200 OK
referrer-policy: strict-origin-when-cross-origin
set-cookie: csrf-token=39HoZgztDnzjJkq/JuLJMeoKNXlfiVv2YgZc09c3TBOBU4NI6kDXaJH1LdicNhN1UsQWzon4Dor9GWGfopaTEQ==; Path=/; Secure
x-content-type-options: nosniff
x-dns-prefetch-control: off
x-frame-options: DENY
x-xss-protection: 1; mode=block
date: Tue, 17 Nov 2020 08:42:10 GMT
content-type: text/html; charset=utf-8
set-cookie: 1e2670d92730b515ce3a1bb65da45062=9b714eb87e93cf34853e87a92d6894be; path=/; HttpOnly; Secure; SameSite=None
cache-control: private

通过运行以下命令并观察输出，验证您是否可以访问每个集群应用程序的 443 端口

$ curl https://console-openshift-console.apps.<cluster_name>.<base_domain> -I -L --insecure

如果配置正确，命令的输出将显示以下响应

HTTP/1.1 200 OK
referrer-policy: strict-origin-when-cross-origin
set-cookie: csrf-token=UlYWOyQ62LWjw2h003xtYSKlh1a0Py2hhctw0WmV2YEdhJjFyQwWcGBsja261dGLgaYO0nxzVErhiXt6QepA7g==; Path=/; Secure; SameSite=Lax
x-content-type-options: nosniff
x-dns-prefetch-control: off
x-frame-options: DENY
x-xss-protection: 1; mode=block
date: Wed, 04 Oct 2023 16:29:38 GMT
content-type: text/html; charset=utf-8
set-cookie: 1e2670d92730b515ce3a1bb65da45062=1bf5e9573c9a2760c964ed1659cc1673; path=/; HttpOnly; Secure; SameSite=None
cache-control: private

使用裸机运算符进行配置

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

您可以使用裸机运算符 (BMO) 来预配、管理和检查集群中的裸机主机。BMO 可以完成以下操作

使用特定映像将裸机主机预配到集群。
打开或关闭主机。
检查宿主机硬件详细信息并将其报告给裸机主机。
将宿主机固件升级或降级到特定版本。
检查固件并配置 BIOS 设置。
在准备主机之前或之后清理主机磁盘内容。

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

BareMetalHost
HostFirmwareSettings
FirmwareSchema
HostFirmwareComponents

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

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

BMO 通过使用 Ironic API 服务与集群中的裸机主机进行交互。Ironic 服务使用主机上的底板管理控制器 (BMC) 与机器进行交互。

裸机操作员架构

裸机操作员 (BMO) 使用以下资源来配置、管理和检查集群中的裸机主机。下图说明了这些资源的架构

BareMetalHost

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

BareMetalHost资源包含以下配置信息：

部署规范，例如操作系统引导映像或自定义 RAM 磁盘
配置状态
底板管理控制器 (BMC) 地址
所需的电源状态

BareMetalHost资源包含以下硬件信息：

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

HostFirmwareSettings

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

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

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

FirmwareSchema

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

如果模式相同，一个FirmwareSchema资源可以应用于许多BareMetalHost资源。

HostFirmwareComponents

Metal³ 提供HostFirmwareComponents资源，该资源描述了 BIOS 和底板管理控制器 (BMC) 固件版本。您可以通过编辑HostFirmwareComponents资源的spec字段来将主机的固件升级或降级到特定版本。这在使用针对特定固件版本测试过的经过验证的模式进行部署时非常有用。

其他资源

关于 BareMetalHost 资源

Metal³ 引入了BareMetalHost资源的概念，该资源定义物理主机及其属性。BareMetalHost资源包含两部分

BareMetalHost规范
BareMetalHost状态

BareMetalHost 规范

BareMetalHost资源的spec部分定义了主机的期望状态。

参数描述

automatedCleaningMode

一个接口，用于在配置和取消配置期间启用或禁用自动清理。设置为disabled时，它将跳过自动清理。设置为metadata时，启用自动清理。默认设置为metadata。

bmc:
  address:
  credentialsName:
  disableCertificateVerification:

bmc配置设置包含主机上底板管理控制器 (BMC) 的连接信息。字段如下：

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

bootMACAddress

用于配置主机的网卡的 MAC 地址。

bootMode

主机的启动模式。默认为UEFI，但也可以设置为legacy（BIOS 启动）或UEFISecureBoot。

consumerRef

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

description

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

externallyProvisioned

一个布尔值，指示主机配置和取消配置是否由外部管理。设置时

仍然可以使用 online 字段管理电源状态。
将监控硬件清单，但不会对主机执行任何配置或取消配置操作。

firmware

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

simultaneousMultithreadingEnabled：允许单个物理处理器核心显示为多个逻辑处理器。有效设置为true或false。
sriovEnabled：SR-IOV 支持使虚拟机管理程序能够创建 PCI-express 设备的虚拟实例，从而 potentially 提高性能。有效设置为true或false。
virtualizationEnabled：支持平台硬件的虚拟化。有效设置为true或false。

image:
  url:
  checksum:
  checksumType:
  format:

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

url：要部署到主机的映像的 URL。
checksum：image.url处映像的实际校验和或包含校验和文件的 URL。
checksumType：您可以指定校验和算法。当前image.checksumType仅支持md5、sha256和sha512。默认校验和类型为md5。
format：这是镜像的磁盘格式。它可以是raw、qcow2、vdi、vmdk、live-iso之一，也可以不设置。将其设置为raw可在Ironic代理中启用该镜像的原始镜像流。将其设置为live-iso允许iso镜像在不部署到磁盘的情况下进行实时启动，并且会忽略checksum字段。

networkData

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

online

一个布尔值，指示主机应打开电源（true）还是关闭电源（false）。更改此值将触发物理主机的电源状态更改。

raid:
  hardwareRAIDVolumes:
  softwareRAIDVolumes:

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

OpenShift Container Platform 4.17支持安装驱动器上的硬件RAID，用于BMC，包括：

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

OpenShift Container Platform 4.17不支持安装驱动器上的软件RAID。

请参阅以下配置设置：

hardwareRAIDVolumes：包含硬件RAID逻辑驱动器的列表，并定义硬件RAID中所需的卷配置。如果您未指定rootDeviceHints，则第一个卷为根卷。子字段为：
- level：逻辑驱动器的RAID级别。支持以下级别：0、1、2、5、6、1+0、5+0、6+0。
- name：卷的名称（字符串）。它在服务器内必须唯一。如果未指定，则将自动生成卷名。
- numberOfPhysicalDisks：要用于逻辑驱动器的物理驱动器数量（整数）。默认为特定RAID级别所需的最小磁盘驱动器数量。
- physicalDisks：物理磁盘驱动器名称的列表（字符串）。这是一个可选字段。如果指定，则也必须指定controller字段。
- controller：（可选）硬件RAID卷中使用的RAID控制器的名称（字符串）。
- rotational：如果设置为true，则仅选择旋转磁盘驱动器。如果设置为false，则仅选择固态硬盘和NVMe驱动器。如果未设置，则选择任何驱动器类型，这是默认行为。
- sizeGibibytes：要创建的逻辑驱动器大小（整数，以GiB为单位）。如果未指定或设置为0，则将使用物理驱动器的最大容量作为逻辑驱动器。
softwareRAIDVolumes：OpenShift Container Platform 4.17不支持安装驱动器上的软件RAID。此配置包含软件RAID逻辑磁盘的列表。如果您未指定rootDeviceHints，则第一个卷为根卷。如果您设置了HardwareRAIDVolumes，则此项将无效。软件RAID将始终被删除。创建的软件RAID设备数量必须为1或2。如果只有一个软件RAID设备，它必须是RAID-1。如果有两个RAID设备，第一个设备必须是RAID-1，而第二个设备的RAID级别可以是0、1或1+0。第一个RAID设备将是部署设备，它不能是软件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镜像置备到特定设备。它按发现设备的顺序检查设备，并将发现的值与提示值进行比较。它使用第一个与提示值匹配的已发现设备。配置可以组合多个提示，但设备必须匹配所有提示才能被选中。字段包括：

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

BareMetalHost状态

BareMetalHost状态表示主机的当前状态，包括已测试的凭据、当前硬件详细信息和其他信息。

表2. BareMetalHost状态
参数	描述
`goodCredentials`	对密钥及其命名空间的引用，其中包含系统能够验证为有效的最后一组基板管理控制器 (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:	`hardware.cpu`字段详细说明了系统中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`：表示系统发现某种不可恢复的错误。有关更多详细信息，请参阅状态部分中的 `errorMessage` 字段。 `delayed`：表示为了限制同时配置多个主机而延迟了配置。 `detached`：表示主机标记为`unmanaged`（未管理）。
`poweredOn`	布尔值，指示主机是否已启动。
provisioning: state: id: image: raid: firmware: rootDeviceHints:	`provisioning` 字段包含与将镜像部署到主机相关的值。子字段包括： `state`：任何正在进行的配置操作的当前状态。状态包括： `<空字符串>`：目前没有进行任何配置操作。 `unmanaged`：没有足够的信息来注册主机。 `registering`：代理正在检查主机的 BMC 详细信息。 `match profile`：代理正在将主机上发现的硬件详细信息与已知配置文件进行比较。 `available`：主机可用于配置。此状态以前称为 `ready`。 `preparing`：将删除现有配置，并在主机上设置新配置。 `provisioning`：配置程序正在将镜像写入主机的存储。 `provisioned`：配置程序已将镜像写入主机的存储。 `externally provisioned`：Metal³ 不管理主机上的镜像。 `deprovisioning`：配置程序正在从主机的存储中擦除镜像。 `inspecting`：代理正在收集主机的硬件详细信息。 `deleting`：代理正在从集群中删除。 `id`：底层配置工具中服务的唯一标识符。 `image`：最近配置到主机的镜像。 `raid`：最近设置的硬件或软件 RAID 卷的列表。 `firmware`：裸机服务器的 BIOS 配置。 `rootDeviceHints`：最近配置操作中使用的根设备选择指令。
`triedCredentials`	对密钥及其命名空间的引用，其中包含发送到配置后端的最后一组 BMC 凭据。

获取 BareMetalHost 资源

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

步骤

获取 BareMetalHost 资源列表
```
$ oc get bmh -n openshift-machine-api -o yaml
```
您可以使用 baremetalhost（bmh 的长格式）和 oc get 命令。
获取主机列表
```
$ oc get bmh -n openshift-machine-api
```

获取特定主机的 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"

编辑 BareMetalHost 资源

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

您使用 Assisted Installer 部署集群，并且需要添加或编辑底板管理控制器 (BMC) 主机名或 IP 地址。
您想将节点从一个集群移动到另一个集群，而无需取消其配置。

先决条件

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

步骤

获取节点列表
```
$ oc get bmh -n openshift-machine-api
```
在编辑节点的 BareMetalHost 资源之前，请通过运行以下命令将节点从 Ironic 中分离：
```
$ oc annotate baremetalhost <node_name> -n openshift-machine-api 'baremetalhost.metal3.io/detached=true' (1)
```
1 将 <node_name> 替换为主机的名称。

通过运行以下命令编辑 BareMetalHost 资源：

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

通过运行以下命令将节点重新连接到 Ironic：

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

解决删除 BareMetalHost 资源时的延迟问题

当裸机操作员 (BMO) 删除 BareMetalHost 资源时，Ironic 会使用称为清理的过程取消裸机主机的配置。当清理失败时，Ironic 会重试清理过程三次，这是延迟的根源。清理过程可能不会成功，导致裸机主机的配置状态无限期地保持在 **deleting** 状态。当这种情况发生时，请使用以下步骤禁用清理过程。

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

步骤

如果清理过程失败并重新启动，请等待其完成。这可能需要大约 5 分钟。
如果配置状态仍然处于 **deleting** 状态，请通过修改 BareMetalHost 资源并将 automatedCleaningMode 字段设置为 disabled 来禁用清理过程。

有关更多详细信息，请参阅“编辑 BareMetalHost 资源”。

将非可引导 ISO 附加到裸机节点

您可以使用 DataImage 资源将通用的非可引导 ISO 虚拟媒体镜像附加到已配置的节点。应用资源后，ISO 镜像在操作系统启动后即可访问。这对于在配置操作系统后以及节点首次启动之前配置节点非常有用。

先决条件

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

步骤

创建 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 和路径。

通过运行以下命令将 DataImage 资源保存到文件：
```
$ vim <node_name>-dataimage.yaml
```
运行以下命令应用DataImage资源
```
$ oc apply -f <node_name>-dataimage.yaml -n <node_namespace> (1)
```
1 替换<node_namespace>，使其命名空间与BareMetalHost资源的命名空间匹配。例如，openshift-machine-api。

重启节点。

要重启节点，请添加reboot.metal3.io注释，或重置BareMetalHost资源中的online状态。裸机节点的强制重启会使节点状态暂时变为NotReady。例如，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"

关于HostFirmwareSettings资源

您可以使用HostFirmwareSettings资源来检索和管理主机的BIOS设置。当主机状态变为Available时，Ironic会读取主机的BIOS设置并创建HostFirmwareSettings资源。该资源包含从底板管理控制器（BMC）返回的完整的BIOS配置。而BareMetalHost资源中的firmware字段返回三个与厂商无关的字段，HostFirmwareSettings资源通常包含每个主机许多厂商专有的BIOS设置。

HostFirmwareSettings资源包含两部分

HostFirmwareSettings规范。
HostFirmwareSettings状态。

`HostFirmwareSettings`规范

HostFirmwareSettings资源的spec部分定义了主机BIOS的期望状态，默认为空。当主机处于Preparing状态时，Ironic使用spec.settings部分中的设置来更新底板管理控制器（BMC）。使用FirmwareSchema资源确保您不会向主机发送无效的名称/值对。有关更多详细信息，请参阅“关于FirmwareSchema资源”。

示例

spec:
  settings:
    ProcTurboMode: Disabled(1)

1	在上例中，`spec.settings`部分包含一个名称/值对，它将`ProcTurboMode` BIOS设置设置为`Disabled`。

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

`HostFirmwareSettings`状态

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

表3. 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`：存储模式的命名空间。 `lastUpdated`：资源最后一次更新的时间。
status: settings:	`settings`字段包含主机当前BIOS设置的名称/值对列表。

获取HostFirmwareSettings资源

HostFirmwareSettings资源包含物理主机的厂商专用BIOS属性。您必须获取物理主机的HostFirmwareSettings资源才能查看其BIOS属性。

步骤

获取HostFirmwareSettings资源的详细列表
```
$ oc get hfs -n openshift-machine-api -o yaml
```
您可以使用hostfirmwaresettings作为hfs的长形式，结合oc get命令。
获取HostFirmwareSettings资源列表
```
$ oc get hfs -n openshift-machine-api
```
获取特定主机的HostFirmwareSettings资源
```
$ oc get hfs <host_name> -n openshift-machine-api -o yaml
```
其中 <host_name> 是主机的名称。

编辑HostFirmwareSettings资源

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

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

步骤

获取HostFirmwareSettings资源列表
```
$ oc get hfs -n openshift-machine-api
```
编辑主机的HostFirmwareSettings资源
```
$ oc edit hfs <host_name> -n openshift-machine-api
```
其中<host_name>是已配置主机的名称。HostFirmwareSettings资源将在您的终端的默认编辑器中打开。
向spec.settings部分添加名称/值对
示例
```
spec:
  settings:
    name: value (1)
```
1 使用FirmwareSchema资源来识别主机可用的设置。您不能设置只读值。
保存更改并退出编辑器。
获取主机的机器名称
```
 $ oc get bmh <host_name> -n openshift-machine name
```
其中<host_name>是主机的名称。机器名称显示在CONSUMER字段下。

为机器添加注释以将其从machineset中删除

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

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

获取节点列表并计算工作节点的数量
```
$ oc get nodes
```

获取machineset

$ oc get machinesets -n openshift-machine-api

调整machineset的规模
```
$ oc scale machineset <machineset_name> -n openshift-machine-api --replicas=<n-1>
```
其中<machineset_name>是machineset的名称，<n-1>是工作节点数量减1后的值。
当主机进入Available状态时，请向上扩展machineset以使HostFirmwareSettings资源更改生效
```
$ oc scale machineset <machineset_name> -n openshift-machine-api --replicas=<n>
```
其中<machineset_name>是machineset的名称，<n>是工作节点的数量。

验证HostFirmware Settings资源是否有效

当用户编辑spec.settings部分以更改HostFirmwareSetting (HFS) 资源时，裸机操作符 (BMO) 会根据FimwareSchema资源（这是一个只读资源）验证更改。如果设置无效，BMO将把status.Condition设置的Type值设置为False，还会生成一个事件并将其存储在HFS资源中。请使用以下步骤验证资源是否有效。

步骤

获取HostFirmwareSetting资源列表
```
$ oc get hfs -n openshift-machine-api
```

验证特定主机的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资源。

关于FirmwareSchema资源

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

表4. FirmwareSchema规范
参数	描述
<BIOS_setting_name> attribute_type: allowable_values: lower_bound: upper_bound: min_length: max_length: read_only: unique:	`spec`是一个简单的映射，包含BIOS设置名称和设置的限制。字段包括： `attribute_type`：设置的类型。支持的类型为： `枚举` `整数` `字符串` `布尔值` `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`：该设置特定于此主机。

获取FirmwareSchema资源

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

步骤

要获取FirmwareSchema资源实例的列表，请执行以下操作：
```
$ oc get firmwareschema -n openshift-machine-api
```
要获取特定的FirmwareSchema实例，请执行：
```
$ oc get firmwareschema <instance_name> -n openshift-machine-api -o yaml
```
其中<instance_name>是在HostFirmwareSettings资源中声明的架构实例的名称（参见表3）。

关于HostFirmwareComponents资源

Metal³提供HostFirmwareComponents资源，该资源描述了BIOS和底板管理控制器（BMC）的固件版本。HostFirmwareComponents资源包含两个部分：

HostFirmwareComponents规范
HostFirmwareComponents状态

HostFirmwareComponents规范

HostFirmwareComponents资源的spec部分定义了主机BIOS和BMC版本的期望状态。

表5. HostFirmwareComponents规范
参数	描述
updates: component: url:	`updates`配置设置包含要更新的组件。字段如下： `component`：组件的名称。有效设置为`bios`或`bmc`。 `url`：组件固件规范和版本的URL。

HostFirmwareComponents状态

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

表6. HostFirmwareComponents状态
参数	描述
components: component: initialVersion: currentVersion: lastVersionFlashed: updatedAt:	`components`部分包含组件的状态。字段如下： `component`：固件组件的名称。返回`bios`或`bmc`。 `initialVersion`：组件的初始固件版本。创建`BareMetalHost`资源时，Ironic会检索此信息。您无法更改它。 `currentVersion`：组件的当前固件版本。最初，该值与`initialVersion`值匹配，直到Ironic更新裸机主机的固件。 `lastVersionFlashed`：在裸机主机上刷写的组件的最后一个固件版本。在Ironic更新固件之前，此字段返回`null`。 `updatedAt`：Ironic更新裸机主机固件的时间戳。
updates: component: url:	`updates`配置设置包含已更新的组件。字段如下： `component`：组件的名称。 `url`：组件固件规范和版本的URL。

获取HostFirmwareComponents资源

HostFirmwareComponents资源包含物理主机的BIOS和底板管理控制器（BMC）的特定固件版本。您必须获取物理主机的HostFirmwareComponents资源以查看固件版本和状态。

步骤

获取HostFirmwareComponents资源的详细列表：

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

获取HostFirmwareComponents资源列表：

$ oc get hostfirmwarecomponents -n openshift-machine-api

获取特定主机的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: []

编辑HostFirmwareComponents资源

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

步骤

获取HostFirmwareComponents资源的详细列表：

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

编辑主机的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。

保存更改并退出编辑器。
获取主机的机器名称
```
$ oc get bmh <host_name> -n openshift-machine name (1)
```
1 其中<host_name>是主机的名称。机器名称显示在CONSUMER字段下。

注释机器以将其从机器集删除

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

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

获取节点列表并计算工作节点的数量
```
$ oc get nodes
```

获取机器集

$ oc get machinesets -n openshift-machine-api

调整机器集规模
```
$ oc scale machineset <machineset_name> -n openshift-machine-api --replicas=<n-1> (1)
```
1 其中<machineset_name>是机器集的名称，<n-1>是减少的工作节点数量。
当主机进入Available状态时，请扩大机器集规模以使HostFirmwareComponents资源更改生效
```
$ oc scale machineset <machineset_name> -n openshift-machine-api --replicas=<n> (1)
```
1 其中<machineset_name>是机器集的名称，<n>是工作节点的数量。

安装程序预配的安装后配置

为断开连接的集群配置 NTP

安装后启用配置网络

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

用户管理的负载均衡器的服务

配置用户管理的负载均衡器

使用裸机运算符进行配置

裸机操作员架构

关于 BareMetalHost 资源

BareMetalHost 规范

BareMetalHost状态

获取 BareMetalHost 资源

编辑 BareMetalHost 资源

解决删除 BareMetalHost 资源时的延迟问题

将非可引导 ISO 附加到裸机节点

关于HostFirmwareSettings资源

HostFirmwareSettings规范

HostFirmwareSettings状态

获取HostFirmwareSettings资源

编辑HostFirmwareSettings资源

验证HostFirmware Settings资源是否有效

关于FirmwareSchema资源

获取FirmwareSchema资源

关于HostFirmwareComponents资源

HostFirmwareComponents规范

HostFirmwareComponents状态

获取HostFirmwareComponents资源

编辑HostFirmwareComponents资源

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

`HostFirmwareSettings`规范

`HostFirmwareSettings`状态