在受限网络上安装用户预配的裸机集群

先决条件
关于受限网络中的安装
- 其他限制
OpenShift Container Platform 的互联网访问
具有用户预配基础设施的集群的要求
准备用户预配的基础设施
验证用户预配基础设施的 DNS 解析
为集群节点 SSH 访问生成密钥对
手动创建安装配置文件
创建 Kubernetes 清单文件和 Ignition 配置文件
配置 chrony 时间服务
安装 RHCOS 并启动 OpenShift Container Platform 引导过程
等待引导过程完成
使用 CLI 登录集群
批准您的机器的证书签名请求
初始 Operator 配置
- 禁用默认的 OperatorHub 目录源
- 镜像注册表存储配置
完成在用户预配的基础设施上的安装
OpenShift Container Platform 的遥测访问
后续步骤

在 OpenShift Container Platform 4.17 中，您可以在您在受限网络中预配的裸机基础设施上安装集群。

虽然您也许能够按照此过程在虚拟化或云环境中部署集群，但您必须了解非裸机平台的其他注意事项。在尝试在这样的环境中安装 OpenShift Container Platform 集群之前，请查看在未经测试的平台上部署 OpenShift Container Platform 的指南中的信息。

先决条件

您已查看有关OpenShift Container Platform 安装和更新过程的详细信息。
您已阅读有关选择集群安装方法并为用户准备它的文档。
您已在镜像主机上创建了一个注册表，并获得了 OpenShift Container Platform 版本的 imageContentSources 数据。

由于安装介质位于镜像主机上，您可以使用该计算机完成所有安装步骤。
您已为您的集群预配了持久性存储。要部署私有镜像注册表，您的存储必须提供 ReadWriteMany 访问模式。
如果您使用防火墙并计划使用遥测服务，您已将防火墙配置为允许您的集群需要访问的站点。

如果您正在配置代理，请务必也查看此站点列表。

关于受限网络中的安装

在 OpenShift Container Platform 4.17 中，您可以执行不需要主动连接到互联网即可获取软件组件的安装。受限网络安装可以使用安装程序预配的基础设施或用户预配的基础设施完成，具体取决于您要向其安装集群的云平台。

如果您选择在云平台上执行受限网络安装，您仍然需要访问其云 API。某些云功能（例如 Amazon Web Service 的 Route 53 DNS 和 IAM 服务）需要互联网访问。根据您的网络，您可能需要较少的互联网访问才能在裸机硬件、Nutanix 或 VMware vSphere 上进行安装。

要完成受限网络安装，您必须创建一个注册表，该注册表镜像 OpenShift 镜像注册表的内容并包含安装介质。您可以在可以访问互联网和封闭网络的镜像主机上创建此注册表，或者使用满足您限制的其他方法。

由于用户预配安装的配置复杂，请考虑在尝试使用用户预配的基础设施进行受限网络安装之前，先完成标准的用户预配基础设施安装。完成此测试安装可能会更容易隔离和排除在受限网络中安装期间可能出现的任何问题。

其他限制

受限网络中的集群具有以下其他限制和约束

ClusterVersion 状态包含 无法检索可用更新 错误。
默认情况下，您无法使用开发者目录的内容，因为您无法访问所需的镜像流标签。

OpenShift Container Platform 的互联网访问

在 OpenShift Container Platform 4.17 中，您需要访问互联网才能获取安装集群所需的镜像。

您必须具有互联网访问权限才能：

访问OpenShift 集群管理器以下载安装程序并执行订阅管理。如果集群具有互联网访问权限并且您没有禁用遥测，则该服务会自动授权您的集群。
访问Quay.io以获取安装集群所需的软件包。
获取执行集群更新所需的软件包。

具有用户预配基础设施的集群的要求

对于包含用户预配基础设施的集群，您必须部署所有必需的机器。

本节介绍在用户预配的基础设施上部署 OpenShift Container Platform 的要求。

集群安装所需的机器

最小的 OpenShift Container Platform 集群需要以下主机：

表 1. 最低所需主机
主机	描述
一台临时引导机器	集群需要引导机器才能在三台控制平面机器上部署 OpenShift Container Platform 集群。安装集群后，您可以移除引导机器。
三台控制平面机器	控制平面机器运行构成控制平面的 Kubernetes 和 OpenShift Container Platform 服务。
至少两台计算机器，也称为工作机器。	OpenShift Container Platform 用户请求的工作负载在计算机器上运行。

作为例外，您可以在仅包含三台控制平面机器的裸机集群中运行零台计算机器。这为集群管理员和开发人员提供了更小、更高效的集群，可用于测试、开发和生产。不支持运行一台计算机器。

为了保持集群的高可用性，请为这些集群机器使用单独的物理主机。

引导机器和控制平面机器必须使用 Red Hat Enterprise Linux CoreOS (RHCOS) 作为操作系统。但是，计算机器可以在 Red Hat Enterprise Linux CoreOS (RHCOS)、Red Hat Enterprise Linux (RHEL) 8.6 及更高版本之间进行选择。

请注意，RHCOS 基于 Red Hat Enterprise Linux (RHEL) 9.2，并继承其所有硬件认证和要求。请参见 Red Hat Enterprise Linux 技术能力和限制。

集群安装的最低资源要求

每个集群机器必须满足以下最低要求

表 2. 最低资源要求
机器	操作系统	CPU ^[1]	RAM	存储	每秒输入/输出次数 (IOPS)^[2]
引导程序	RHCOS	4	16 GB	100 GB	300
控制平面	RHCOS	4	16 GB	100 GB	300
计算节点	RHCOS、RHEL 8.6 及更高版本 ^[3]	2	8 GB	100 GB	300

当未启用同时多线程 (SMT) 或超线程时，一个 CPU 等效于一个物理核心。启用时，使用以下公式计算相应的比率：（每个核心的线程数 × 核心数）× 插槽数 = CPU 数。
OpenShift Container Platform 和 Kubernetes 对磁盘性能非常敏感，建议使用更快的存储，特别是对于控制平面节点上的 etcd，其需要 10 毫秒 p99 fsync 持续时间。请注意，在许多云平台上，存储大小和 IOPS 成正比，因此您可能需要过度分配存储卷以获得足够的性能。
与所有用户配置的安装一样，如果您选择在集群中使用 RHEL 计算机器，则您需要负责所有操作系统生命周期管理和维护，包括执行系统更新、应用补丁以及完成所有其他必需的任务。RHEL 7 计算机器的使用已弃用，并在 OpenShift Container Platform 4.10 及更高版本中移除。

从 OpenShift Container Platform 4.13 版本开始，RHCOS 基于 RHEL 9.2 版本，这更新了微架构要求。以下列表包含每个架构所需的最低指令集架构 (ISA)：

x86-64 架构需要 x86-64-v2 ISA
ARM64 架构需要 ARMv8.0-A ISA
IBM Power 架构需要 Power 9 ISA
s390x 架构需要 z14 ISA

更多信息，请参见 RHEL 架构。

如果平台的实例类型满足集群机器的最低要求，则支持在 OpenShift Container Platform 中使用。

其他资源

优化存储

证书签名请求管理

因为当您使用您自己配置的基础设施时，您的集群对自动机器管理的访问权限有限，因此您必须提供一种机制来在安装后批准集群证书签名请求 (CSR)。kube-controller-manager 仅批准 kubelet 客户端 CSR。machine-approver 无法保证使用 kubelet 凭据请求的服务证书的有效性，因为它无法确认正确的机器发出了请求。您必须确定并实现一种验证 kubelet 服务证书请求的有效性并批准它们的方法。

其他资源

有关在裸机环境中部署三节点集群的详细信息，请参见配置三节点集群。
有关安装后批准集群证书签名请求的更多信息，请参见批准机器的证书签名请求。

用户配置基础设施的网络要求

所有 Red Hat Enterprise Linux CoreOS (RHCOS) 机器都需要在启动期间在 initramfs 中配置网络才能获取其 Ignition 配置文件。

在初始启动期间，机器需要通过 DHCP 服务器设置或通过提供必要的引导选项静态设置 IP 地址配置。建立网络连接后，机器将从 HTTP 或 HTTPS 服务器下载其 Ignition 配置文件。然后使用 Ignition 配置文件来设置每台机器的确切状态。安装后，机器配置操作员将对机器进行更多更改，例如应用新的证书或密钥。

建议使用 DHCP 服务器来长期管理集群机器。确保 DHCP 服务器配置为向集群机器提供持久性 IP 地址、DNS 服务器信息和主机名。

如果您的用户配置基础设施没有可用的 DHCP 服务，则可以在 RHCOS 安装时向节点提供 IP 网络配置和 DNS 服务器地址。如果您是从 ISO 映像安装，则可以将其作为引导参数传递。有关静态 IP 配置和高级网络选项的更多信息，请参见“安装 RHCOS 并启动 OpenShift Container Platform 引导过程”部分。

Kubernetes API 服务器必须能够解析集群机器的节点名称。如果 API 服务器和工作节点位于不同的区域，您可以配置默认的 DNS 搜索区域以允许 API 服务器解析节点名称。另一种支持的方法是在节点对象和所有 DNS 请求中始终使用其完全限定域名来引用主机。

通过 DHCP 设置集群节点主机名

在 Red Hat Enterprise Linux CoreOS (RHCOS) 机器上，主机名通过 NetworkManager 设置。默认情况下，机器通过 DHCP 获取其主机名。如果主机名未由 DHCP 提供、通过内核参数静态设置或其他方法设置，则通过反向 DNS 查询获取。反向 DNS 查询在节点上的网络初始化后发生，并且解析可能需要一些时间。其他系统服务可以在此之前启动并检测主机名为 localhost 或类似名称。您可以通过使用 DHCP 为每个集群节点提供主机名来避免这种情况。

此外，通过 DHCP 设置主机名可以绕过在具有 DNS 分割视野实现的环境中的任何手动 DNS 记录名称配置错误。

网络连接要求

您必须配置机器之间的网络连接以允许 OpenShift Container Platform 集群组件进行通信。每台机器必须能够解析集群中所有其他机器的主机名。

本节提供有关所需端口的详细信息。

表 3. 用于所有机器到所有机器通信的端口
协议	端口	描述
ICMP	N/A	网络可达性测试
TCP	`1936`	指标
	`9000`-`9999`	主机级服务，包括端口 `9100`-`9101` 上的节点导出器和端口 `9099` 上的集群版本操作员。
	`10250`-`10259`	Kubernetes 保留的默认端口
UDP	`4789`	VXLAN
	`6081`	Geneve
	`9000`-`9999`	主机级服务，包括端口 `9100`-`9101` 上的节点导出器。
	`500`	IPsec IKE 数据包
	`4500`	IPsec NAT-T 数据包
	`123`	UDP 端口 `123` 上的网络时间协议 (NTP) 如果配置了外部 NTP 时间服务器，则必须打开 UDP 端口 `123`。
TCP/UDP	`30000`-`32767`	Kubernetes 节点端口
ESP	N/A	IPsec 封装安全有效负载 (ESP)

表 4. 用于所有机器到控制平面通信的端口
协议	端口	描述
TCP	`6443`	Kubernetes API

表 5. 用于控制平面机器到控制平面机器通信的端口
协议	端口	描述
TCP	`2379`-`2380`	etcd 服务器和对等端口

用户配置基础设施的 NTP 配置

OpenShift Container Platform 集群默认配置为使用公共网络时间协议 (NTP) 服务器。如果您想使用本地企业 NTP 服务器，或者您的集群部署在断开连接的网络中，您可以将集群配置为使用特定的时间服务器。更多信息，请参见配置 chrony 时间服务文档。

如果 DHCP 服务器提供 NTP 服务器信息，Red Hat Enterprise Linux CoreOS (RHCOS) 机器上的 chrony 时间服务将读取这些信息，并可以与 NTP 服务器同步时钟。

其他资源

配置 chrony 时间服务

用户配置的 DNS 需求

在 OpenShift Container Platform 部署中，以下组件需要 DNS 名称解析：

Kubernetes API
OpenShift Container Platform 应用通配符
引导程序、控制平面和计算机器

Kubernetes API、引导程序机器、控制平面机器和计算机器也需要反向 DNS 解析。

DNS A/AAAA 或 CNAME 记录用于名称解析，PTR 记录用于反向名称解析。反向记录非常重要，因为 Red Hat Enterprise Linux CoreOS (RHCOS) 使用反向记录来设置所有节点的主机名，除非主机名由 DHCP 提供。此外，反向记录还用于生成 OpenShift Container Platform 运行所需的证书签名请求 (CSR)。

建议使用 DHCP 服务器为主机名提供给每个集群节点。有关更多信息，请参见用户配置的基础设施的 DHCP 建议部分。

用户配置的 OpenShift Container Platform 集群需要以下 DNS 记录，并且必须在安装之前到位。在每个记录中，<cluster_name> 是集群名称，<base_domain> 是您在 install-config.yaml 文件中指定的基域。完整的 DNS 记录格式为：<component>.<cluster_name>.<base_domain>.。

组件记录描述

Kubernetes API

api.<cluster_name>.<base_domain>.

一个 DNS A/AAAA 或 CNAME 记录和一个 DNS PTR 记录，用于标识 API 负载均衡器。集群外部的客户端和集群内的所有节点都必须能够解析这些记录。

api-int.<cluster_name>.<base_domain>.

一个 DNS A/AAAA 或 CNAME 记录和一个 DNS PTR 记录，用于在内部标识 API 负载均衡器。集群内的所有节点都必须能够解析这些记录。

API 服务器必须能够通过 Kubernetes 中记录的主机名解析工作节点。如果 API 服务器无法解析节点名称，则代理的 API 调用可能会失败，并且您无法检索 Pod 日志。

路由

*.apps.<cluster_name>.<base_domain>.

一个通配符 DNS A/AAAA 或 CNAME 记录，指向应用程序入口负载均衡器。应用程序入口负载均衡器指向运行 Ingress Controller Pod 的机器。Ingress Controller Pod 默认运行在计算机器上。集群外部的客户端和集群内的所有节点都必须能够解析这些记录。

例如，console-openshift-console.apps.<cluster_name>.<base_domain> 用作 OpenShift Container Platform 控制台的通配符路由。

引导程序机器

bootstrap.<cluster_name>.<base_domain>.

一个 DNS A/AAAA 或 CNAME 记录和一个 DNS PTR 记录，用于标识引导程序机器。集群内的节点必须能够解析这些记录。

控制平面机器

<control_plane><n>.<cluster_name>.<base_domain>.

DNS A/AAAA 或 CNAME 记录和 DNS PTR 记录，用于标识每个控制平面节点的机器。集群内的节点必须能够解析这些记录。

计算机器

<compute><n>.<cluster_name>.<base_domain>.

DNS A/AAAA 或 CNAME 记录和 DNS PTR 记录，用于标识每个工作节点的机器。集群内的节点必须能够解析这些记录。

在 OpenShift Container Platform 4.4 及更高版本中，您无需在 DNS 配置中指定 etcd 主机和 SRV 记录。

您可以使用 dig 命令验证名称和反向名称解析。有关详细的验证步骤，请参见验证用户配置的基础设施的 DNS 解析部分。

用户配置集群的 DNS 配置示例

本节提供满足在用户配置的基础设施上部署 OpenShift Container Platform 的 DNS 需求的 A 和 PTR 记录配置示例。这些示例并非旨在提供有关选择一种 DNS 解决方案而非另一种解决方案的建议。

在这些示例中，集群名称为 ocp4，基域为 example.com。

用户配置集群的 DNS A 记录配置示例

以下示例是一个 BIND 区域文件，其中显示了用户配置集群中名称解析的 A 记录示例。

DNS 区域数据库示例

$TTL 1W
@	IN	SOA	ns1.example.com.	root (
			2019070700	; serial
			3H		; refresh (3 hours)
			30M		; retry (30 minutes)
			2W		; expiry (2 weeks)
			1W )		; minimum (1 week)
	IN	NS	ns1.example.com.
	IN	MX 10	smtp.example.com.
;
;
ns1.example.com.		IN	A	192.168.1.5
smtp.example.com.		IN	A	192.168.1.5
;
helper.example.com.		IN	A	192.168.1.5
helper.ocp4.example.com.	IN	A	192.168.1.5
;
api.ocp4.example.com.		IN	A	192.168.1.5 (1)
api-int.ocp4.example.com.	IN	A	192.168.1.5 (2)
;
*.apps.ocp4.example.com.	IN	A	192.168.1.5 (3)
;
bootstrap.ocp4.example.com.	IN	A	192.168.1.96 (4)
;
control-plane0.ocp4.example.com.	IN	A	192.168.1.97 (5)
control-plane1.ocp4.example.com.	IN	A	192.168.1.98 (5)
control-plane2.ocp4.example.com.	IN	A	192.168.1.99 (5)
;
compute0.ocp4.example.com.	IN	A	192.168.1.11 (6)
compute1.ocp4.example.com.	IN	A	192.168.1.7 (6)
;
;EOF

提供 Kubernetes API 的名称解析。该记录指向 API 负载均衡器的 IP 地址。

提供 Kubernetes API 的名称解析。该记录指向 API 负载均衡器的 IP 地址，并用于内部集群通信。

提供通配符路由的名称解析。该记录指向应用程序入口负载均衡器的 IP 地址。应用程序入口负载均衡器指向运行 Ingress Controller Pod 的机器。Ingress Controller Pod 默认运行在计算机器上。

在示例中，Kubernetes API 和应用程序入口流量使用相同的负载均衡器。在生产环境中，您可以分别部署 API 和应用程序入口负载均衡器，以便您可以独立地扩展每个负载均衡器基础设施。

提供引导程序机器的名称解析。

提供控制平面机器的名称解析。

提供计算机器的名称解析。

用户配置集群的 DNS PTR 记录配置示例

以下示例 BIND 区域文件显示了用户配置集群中反向名称解析的 PTR 记录示例。

反向记录的 DNS 区域数据库示例

$TTL 1W
@	IN	SOA	ns1.example.com.	root (
			2019070700	; serial
			3H		; refresh (3 hours)
			30M		; retry (30 minutes)
			2W		; expiry (2 weeks)
			1W )		; minimum (1 week)
	IN	NS	ns1.example.com.
;
5.1.168.192.in-addr.arpa.	IN	PTR	api.ocp4.example.com. (1)
5.1.168.192.in-addr.arpa.	IN	PTR	api-int.ocp4.example.com. (2)
;
96.1.168.192.in-addr.arpa.	IN	PTR	bootstrap.ocp4.example.com. (3)
;
97.1.168.192.in-addr.arpa.	IN	PTR	control-plane0.ocp4.example.com. (4)
98.1.168.192.in-addr.arpa.	IN	PTR	control-plane1.ocp4.example.com. (4)
99.1.168.192.in-addr.arpa.	IN	PTR	control-plane2.ocp4.example.com. (4)
;
11.1.168.192.in-addr.arpa.	IN	PTR	compute0.ocp4.example.com. (5)
7.1.168.192.in-addr.arpa.	IN	PTR	compute1.ocp4.example.com. (5)
;
;EOF

1	提供 Kubernetes API 的反向 DNS 解析。PTR 记录指向 API 负载均衡器的记录名称。
2	提供 Kubernetes API 的反向 DNS 解析。PTR 记录指向 API 负载均衡器的记录名称，并用于内部集群通信。
3	提供引导程序机器的反向 DNS 解析。
4	提供控制平面机器的反向 DNS 解析。
5	提供计算机器的反向 DNS 解析。

OpenShift Container Platform 应用程序通配符不需要 PTR 记录。

其他资源

验证用户预配基础设施的 DNS 解析

用户配置的基础设施的负载均衡需求

在安装 OpenShift Container Platform 之前，您必须预配 API 和应用程序入口负载均衡基础设施。在生产环境中，您可以分别部署 API 和应用程序入口负载均衡器，以便您可以独立地扩展每个负载均衡器基础设施。

如果您想使用 Red Hat Enterprise Linux (RHEL) 实例部署 API 和应用程序入口负载均衡器，则必须单独购买 RHEL 订阅。

负载均衡基础设施必须满足以下要求：

API 负载均衡器：为用户（人和机器）提供一个共同的端点来与平台交互和配置平台。配置以下条件：

仅限第 4 层负载均衡。这可以称为原始 TCP 或 SSL 直通模式。
无状态负载均衡算法。选项因负载均衡器实现而异。

不要为 API 负载均衡器配置会话持久性。为 Kubernetes API 服务器配置会话持久性可能会导致 OpenShift Container Platform 集群以及集群内运行的 Kubernetes API 的应用程序流量过载，从而影响性能。

在负载均衡器的前后端配置以下端口

表 7. API 负载均衡器
端口	后端机器（池成员）	内部	外部	描述
`6443`	引导程序和控制平面。引导程序机器初始化集群控制平面后，您需要将其从负载均衡器中移除。您必须为 API 服务器健康检查探针配置`/readyz`端点。	X	X	Kubernetes API 服务器
`22623`	引导程序和控制平面。引导程序机器初始化集群控制平面后，您需要将其从负载均衡器中移除。	X		机器配置服务器

负载均衡器必须在 API 服务器关闭/readyz端点到将 API 服务器实例从池中移除之间的时间内最多花费 30 秒。在/readyz返回错误或恢复正常后的时间范围内，必须已移除或添加了该端点。经过良好测试的值是每 5 或 10 秒探测一次，两次成功的请求变为健康状态，三次变为不健康状态。

应用程序 Ingress 负载均衡器：为从集群外部流入的应用程序流量提供入口点。OpenShift Container Platform 集群需要 Ingress 路由器的正常配置。

配置以下条件

仅限第 4 层负载均衡。这可以称为原始 TCP 或 SSL 直通模式。
建议根据可用选项和平台上将要托管的应用程序类型，使用基于连接的或基于会话的持久性。

如果应用程序 Ingress 负载均衡器可以看到客户端的真实 IP 地址，则启用基于源 IP 的会话持久性可以提高使用端到端 TLS 加密的应用程序的性能。

在负载均衡器的前后端配置以下端口

表 8. 应用程序 Ingress 负载均衡器
端口	后端机器（池成员）	内部	外部	描述
`443`	默认情况下，运行 Ingress Controller Pod 的机器，计算节点或工作节点。	X	X	HTTPS 流量
`80`	默认情况下，运行 Ingress Controller Pod 的机器，计算节点或工作节点。	X	X	HTTP 流量

如果您部署的是具有零计算节点的三节点集群，则 Ingress Controller Pod 将在控制平面节点上运行。在三节点集群部署中，您必须将应用程序 Ingress 负载均衡器配置为将 HTTP 和 HTTPS 流量路由到控制平面节点。

用户配置集群的负载均衡器配置示例

本节提供了一个满足用户配置集群的负载均衡要求的 API 和应用程序 Ingress 负载均衡器配置示例。该示例是 HAProxy 负载均衡器的/etc/haproxy/haproxy.cfg配置。本示例并非旨在提供关于选择一种负载均衡解决方案而非另一种解决方案的建议。

如果您使用 HAProxy 作为负载均衡器并且 SELinux 设置为enforcing，则必须确保 HAProxy 服务可以通过运行setsebool -P haproxy_connect_any=1绑定到已配置的 TCP 端口。

API 和应用程序 Ingress 负载均衡器配置示例

global
  log         127.0.0.1 local2
  pidfile     /var/run/haproxy.pid
  maxconn     4000
  daemon
defaults
  mode                    http
  log                     global
  option                  dontlognull
  option http-server-close
  option                  redispatch
  retries                 3
  timeout http-request    10s
  timeout queue           1m
  timeout connect         10s
  timeout client          1m
  timeout server          1m
  timeout http-keep-alive 10s
  timeout check           10s
  maxconn                 3000
listen api-server-6443 (1)
  bind *:6443
  mode tcp
  option  httpchk GET /readyz HTTP/1.0
  option  log-health-checks
  balance roundrobin
  server bootstrap bootstrap.ocp4.example.com:6443 verify none check check-ssl inter 10s fall 2 rise 3 backup (2)
  server master0 master0.ocp4.example.com:6443 weight 1 verify none check check-ssl inter 10s fall 2 rise 3
  server master1 master1.ocp4.example.com:6443 weight 1 verify none check check-ssl inter 10s fall 2 rise 3
  server master2 master2.ocp4.example.com:6443 weight 1 verify none check check-ssl inter 10s fall 2 rise 3
listen machine-config-server-22623 (3)
  bind *:22623
  mode tcp
  server bootstrap bootstrap.ocp4.example.com:22623 check inter 1s backup (2)
  server master0 master0.ocp4.example.com:22623 check inter 1s
  server master1 master1.ocp4.example.com:22623 check inter 1s
  server master2 master2.ocp4.example.com:22623 check inter 1s
listen ingress-router-443 (4)
  bind *:443
  mode tcp
  balance source
  server compute0 compute0.ocp4.example.com:443 check inter 1s
  server compute1 compute1.ocp4.example.com:443 check inter 1s
listen ingress-router-80 (5)
  bind *:80
  mode tcp
  balance source
  server compute0 compute0.ocp4.example.com:80 check inter 1s
  server compute1 compute1.ocp4.example.com:80 check inter 1s

1 端口6443处理 Kubernetes API 流量并指向控制平面机器。

2 引导程序条目必须在 OpenShift Container Platform 集群安装之前到位，并且必须在引导程序过程完成后将其移除。

3 端口22623处理机器配置服务器流量并指向控制平面机器。

4 端口443处理 HTTPS 流量并指向运行 Ingress Controller Pod 的机器。Ingress Controller Pod 默认运行在计算机器上。

端口80处理 HTTP 流量并指向运行 Ingress Controller Pod 的机器。Ingress Controller Pod 默认运行在计算机器上。

如果您使用 HAProxy 作为负载均衡器，则可以通过在 HAProxy 节点上运行netstat -nltupe来检查haproxy进程是否正在监听端口6443、22623、443和80。

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

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

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

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

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

您想对桥进行安装后更改，例如更改 Open vSwitch (OVS) 或 OVN-Kubernetes br-ex桥网络。configure-ovs.sh shell 脚本不支持对桥进行安装后更改。
您想在与主机或服务器 IP 地址上可用的接口不同的接口上部署桥。
您想对桥进行configure-ovs.sh shell 脚本无法实现的高级配置。对于这些配置使用该脚本可能会导致桥无法连接多个网络接口并促进接口之间的数据转发。

如果您需要具有单个网络接口控制器 (NIC) 和默认网络设置的环境，请使用configure-ovs.sh shell 脚本。

安装 Red Hat Enterprise Linux CoreOS (RHCOS) 并系统重新启动后，Machine Config Operator 会将 Ignition 配置文件注入集群中的每个节点，以便每个节点都收到br-ex桥网络配置。为了防止配置冲突，configure-ovs.sh shell 脚本会收到一个信号以不配置br-ex桥。

先决条件

可选：您已安装nmstate API，以便您可以验证 NMState 配置。

步骤

创建一个 NMState 配置文件，其中包含您自定义的br-ex桥网络的解码 base64 信息

自定义br-ex桥网络的 NMState 配置示例

interfaces:
- name: enp2s0 (1)
  type: ethernet (2)
  state: up (3)
  ipv4:
    enabled: false (4)
  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 (5)
    - name: br-ex
- name: br-ex
  type: ovs-interface
  state: up
  copy-mac-from: enp2s0
  ipv4:
    enabled: true
    dhcp: true
  ipv6:
    enabled: false
    dhcp: false
# ...

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

使用cat命令对 NMState 配置的内容进行 base64 编码
```
$ cat <nmstate_configuration>.yaml | base64 (1)
```
1 将<nmstate_configuration>替换为您 NMState 资源 YAML 文件的名称。

创建一个MachineConfig清单文件，并定义一个类似于以下示例的自定义br-ex桥接网络配置。

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker (1)
  name: 10-br-ex-worker (2)
spec:
  config:
    ignition:
      version: 3.2.0
    storage:
      files:
      - contents:
          source: data:text/plain;charset=utf-8;base64,<base64_encoded_nmstate_configuration> (3)
        mode: 0644
        overwrite: true
        path: /etc/nmstate/openshift/cluster.yml
# ...

1	为集群中的每个节点指定节点的主机名路径和机器类型的base-64编码的Ignition配置文件数据。如果您在`/etc/nmstate/openshift/cluster.yml`配置文件中指定了一个单一的全局配置，并希望将其应用于集群中的所有节点，则无需为每个节点指定主机名路径。`worker`角色是集群中节点的默认角色。在`MachineConfig`清单文件中为每个节点或所有节点指定主机名路径时，`.yaml`扩展名无效。
2	策略的名称。
3	将编码的base64信息写入指定路径。

将每个机器集扩展到计算节点

要将自定义的br-ex桥接配置应用于OpenShift Container Platform集群中的所有计算节点，必须编辑MachineConfig自定义资源(CR)并修改其角色。此外，必须创建一个BareMetalHost CR，该CR定义了裸机的信息，例如主机名、凭据等。

配置这些资源后，必须扩展机器集，以便机器集可以将资源配置应用于每个计算节点并重新启动节点。

先决条件

您创建了一个包含自定义br-ex桥接配置的MachineConfig清单对象。

步骤

通过输入以下命令来编辑MachineConfig CR

$ oc edit mc <machineconfig_custom_resource_name>

将每个计算节点配置添加到CR中，以便CR可以管理集群中每个已定义计算节点的角色。
创建一个名为extraworker-secret的Secret对象，该对象具有最小的静态IP配置。
通过输入以下命令将extraworker-secret密钥应用于集群中的每个节点。此步骤为每个计算节点提供对Ignition配置文件的访问权限。
```
$ oc apply -f ./extraworker-secret.yaml
```

创建一个BareMetalHost资源，并在preprovisioningNetworkDataName参数中指定网络密钥。

带有附加网络密钥的BareMetalHost资源示例

apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
spec:
# ...
  preprovisioningNetworkDataName: ostest-extraworker-0-network-config-secret
# ...

要在集群的openshift-machine-api命名空间中管理BareMetalHost对象，请通过输入以下命令切换到该命名空间
```
$ oc project openshift-machine-api
```
获取机器集
```
$ oc get machinesets
```
通过输入以下命令来扩展每个机器集。必须为每个机器集运行此命令。
```
$ oc scale machineset <machineset_name> --replicas=<n> (1)
```
1 其中<machineset_name>是机器集的名称，<n>是计算节点的数量。

准备用户预配的基础设施

在用户预配的基础设施上安装OpenShift Container Platform之前，必须准备底层基础设施。

本节详细介绍了在准备OpenShift Container Platform安装时设置集群基础设施所需的高级步骤。这包括为集群节点配置IP网络和网络连接，通过防火墙启用所需端口，以及设置所需的DNS和负载均衡基础设施。

准备之后，集群基础设施必须满足“用户预配基础设施的集群要求”部分中概述的要求。

先决条件

您已查看OpenShift Container Platform 4.x 测试集成页面。
您已查看“用户预配基础设施的集群要求”部分中详细介绍的基础设施要求。

步骤

如果使用DHCP为集群节点提供IP网络配置，请配置DHCP服务。

为节点的DHCP服务器配置中添加持久IP地址。在配置中，将相关网络接口的MAC地址与每个节点的预期IP地址匹配。

当使用DHCP为集群机器配置IP地址时，机器也通过DHCP获取DNS服务器信息。通过DHCP服务器配置定义集群节点使用的持久DNS服务器地址。

如果不使用DHCP服务，则必须在RHCOS安装时为节点提供IP网络配置和DNS服务器地址。如果从ISO映像安装，则可以将其作为启动参数传递。有关静态IP配置和高级网络选项的更多信息，请参阅“安装RHCOS并启动OpenShift Container Platform引导过程”部分。

在DHCP服务器配置中定义集群节点的主机名。有关主机名注意事项的详细信息，请参阅“通过DHCP设置集群节点主机名”部分。

如果不使用DHCP服务，则集群节点将通过反向DNS查找获取其主机名。

确保网络基础设施提供集群组件之间所需的网络连接。有关要求的详细信息，请参阅“用户预配基础设施的网络要求”部分。

配置防火墙以启用OpenShift Container Platform集群组件通信所需的端口。有关所需端口的详细信息，请参阅“用户预配基础设施的网络要求”部分。

默认情况下，OpenShift Container Platform集群可以访问端口1936，因为每个控制平面节点都需要访问此端口。

避免使用Ingress负载均衡器来公开此端口，因为这样做可能会导致公开敏感信息，例如与Ingress控制器相关的统计信息和指标。

设置集群所需的DNS基础设施。
1. 配置Kubernetes API、应用程序通配符、引导机器、控制平面机器和计算机器的DNS名称解析。
2. 配置Kubernetes API、引导机器、控制平面机器和计算机器的反向DNS解析。
  
  有关OpenShift Container Platform DNS要求的更多信息，请参阅“用户预配DNS要求”部分。
验证DNS配置。
1. 从安装节点运行针对Kubernetes API、通配符路由和集群节点的记录名称的DNS查找。验证响应中的IP地址是否对应于正确的组件。
2. 从安装节点运行针对负载均衡器和集群节点的IP地址的反向DNS查找。验证响应中的记录名称是否对应于正确的组件。
  
  有关详细的DNS验证步骤，请参阅“验证用户预配基础设施的DNS解析”部分。
预配所需的API和应用程序入口负载均衡基础设施。有关要求的更多信息，请参阅“用户预配基础设施的负载均衡要求”部分。

某些负载均衡解决方案要求在初始化负载均衡之前已到位集群节点的DNS名称解析。

其他资源

验证用户预配基础设施的DNS解析

可以在用户预配的基础设施上安装OpenShift Container Platform之前验证DNS配置。

在安装集群之前，必须成功执行本节中详细介绍的验证步骤。

先决条件

您已为用户预配的基础设施配置了所需的DNS记录。

步骤

从您的安装节点运行针对 Kubernetes API 记录名称、通配符路由和集群节点的 DNS 查询。验证响应中包含的 IP 地址是否与正确的组件相对应。

对 Kubernetes API 记录名称执行查询。检查结果是否指向 API 负载均衡器的 IP 地址。
```
$ dig +noall +answer @<nameserver_ip> api.<cluster_name>.<base_domain> (1)
```
1 将<nameserver_ip>替换为名称服务器的 IP 地址，将<cluster_name>替换为您的集群名称，并将<base_domain>替换为您的基础域名。
示例输出
```
api.ocp4.example.com.		604800	IN	A	192.168.1.5
```

对 Kubernetes 内部 API 记录名称执行查询。检查结果是否指向 API 负载均衡器的 IP 地址。

$ dig +noall +answer @<nameserver_ip> api-int.<cluster_name>.<base_domain>

示例输出

api-int.ocp4.example.com.		604800	IN	A	192.168.1.5

测试一个示例*.apps.<cluster_name>.<base_domain> DNS 通配符查询。所有应用程序通配符查询都必须解析到应用程序入口负载均衡器的 IP 地址。

$ dig +noall +answer @<nameserver_ip> random.apps.<cluster_name>.<base_domain>

示例输出

random.apps.ocp4.example.com.		604800	IN	A	192.168.1.5

在示例输出中，相同的负载均衡器用于 Kubernetes API 和应用程序入口流量。在生产环境中，您可以分别部署 API 和应用程序入口负载均衡器，以便您可以隔离地扩展每个负载均衡器基础设施。

您可以将random替换为另一个通配符值。例如，您可以查询到 OpenShift Container Platform 控制台的路由。

$ dig +noall +answer @<nameserver_ip> console-openshift-console.apps.<cluster_name>.<base_domain>

示例输出

console-openshift-console.apps.ocp4.example.com. 604800 IN	A 192.168.1.5

对引导 DNS 记录名称运行查询。检查结果是否指向引导节点的 IP 地址。

$ dig +noall +answer @<nameserver_ip> bootstrap.<cluster_name>.<base_domain>

示例输出

bootstrap.ocp4.example.com.		604800	IN	A	192.168.1.96

使用此方法对控制平面和计算节点的 DNS 记录名称执行查询。检查结果是否与每个节点的 IP 地址相对应。

从您的安装节点运行针对负载均衡器和集群节点 IP 地址的反向 DNS 查询。验证响应中包含的记录名称是否与正确的组件相对应。
1. 对 API 负载均衡器的 IP 地址执行反向查询。检查响应是否包含 Kubernetes API 和 Kubernetes 内部 API 的记录名称。
  $ dig +noall +answer @<nameserver_ip> -x 192.168.1.5
  示例输出
  5.1.168.192.in-addr.arpa. 604800 IN PTR api-int.ocp4.example.com. (1) 5.1.168.192.in-addr.arpa. 604800 IN PTR api.ocp4.example.com. (2)
  1 提供 Kubernetes 内部 API 的记录名称。
  
  2 提供 Kubernetes API 的记录名称。
  
  OpenShift Container Platform 应用程序通配符不需要 PTR 记录。不需要对应用程序入口负载均衡器的 IP 地址执行反向 DNS 解析的验证步骤。
2. 对引导节点的 IP 地址执行反向查询。检查结果是否指向引导节点的 DNS 记录名称。
  $ dig +noall +answer @<nameserver_ip> -x 192.168.1.96
  示例输出
  96.1.168.192.in-addr.arpa. 604800 IN PTR bootstrap.ocp4.example.com.
3. 使用此方法对控制平面和计算节点的 IP 地址执行反向查询。检查结果是否与每个节点的 DNS 记录名称相对应。

其他资源

生成用于集群节点 SSH 访问的密钥对

在 OpenShift Container Platform 安装过程中，您可以向安装程序提供 SSH 公钥。该密钥通过其 Ignition 配置文件传递给 Red Hat Enterprise Linux CoreOS (RHCOS) 节点，并用于验证对节点的 SSH 访问。该密钥将添加到每个节点上core用户的~/.ssh/authorized_keys列表中，从而启用无密码身份验证。

密钥传递到节点后，您可以使用密钥对以core用户身份通过 SSH 登录到 RHCOS 节点。要通过 SSH 访问节点，必须由您本地用户的 SSH 管理私钥身份。

如果您想通过 SSH 登录到您的集群节点以执行安装调试或灾难恢复，则必须在安装过程中提供 SSH 公钥。./openshift-install gather命令也需要在集群节点上安装 SSH 公钥。

在需要灾难恢复和调试的生产环境中，不要跳过此步骤。

您必须使用本地密钥，而不是使用平台特定方法（例如AWS 密钥对）配置的密钥。

步骤

如果您的本地计算机上没有现有的 SSH 密钥对可用于对集群节点进行身份验证，请创建一个。例如，在使用 Linux 操作系统的计算机上，运行以下命令：

$ ssh-keygen -t ed25519 -N '' -f <path>/<file_name> (1)

1	指定新 SSH 密钥的路径和文件名，例如`~/.ssh/id_ed25519`。如果您有现有的密钥对，请确保您的公钥位于您的`~/.ssh`目录中。

如果您计划安装一个使用已提交给 NIST 以进行 FIPS 140-2/140-3 验证的 RHEL 加密库的 OpenShift Container Platform 集群（仅限于x86_64、ppc64le和s390x架构），请不要创建使用ed25519算法的密钥。而是创建一个使用rsa或ecdsa算法的密钥。

查看 SSH 公钥
```
$ cat <path>/<file_name>.pub
```
例如，运行以下命令查看~/.ssh/id_ed25519.pub公钥：
```
$ cat ~/.ssh/id_ed25519.pub
```
如果尚未添加，请将 SSH 私钥身份添加到本地用户的 SSH 代理。SSH 代理管理密钥对于对集群节点进行无密码 SSH 身份验证是必需的，或者如果您想使用./openshift-install gather命令。

在某些发行版中，默认的 SSH 私钥身份（例如~/.ssh/id_rsa和~/.ssh/id_dsa）会自动管理。
1. 如果本地用户的ssh-agent进程尚未运行，请将其作为后台任务启动：
  $ eval "$(ssh-agent -s)"
  示例输出
  Agent pid 31874
  如果您的集群处于 FIPS 模式，则只能使用符合 FIPS 的算法来生成 SSH 密钥。密钥必须是 RSA 或 ECDSA。
将您的 SSH 私钥添加到ssh-agent：
```
$ ssh-add <path>/<file_name> (1)
```
1 指定 SSH 私钥的路径和文件名，例如~/.ssh/id_ed25519。
示例输出
```
Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
```

后续步骤

安装 OpenShift Container Platform 时，请向安装程序提供 SSH 公钥。如果您在您自己配置的基础架构上安装集群，则必须向安装程序提供密钥。

其他资源

验证节点运行状况

手动创建安装配置文件

安装集群需要您手动创建安装配置文件。

先决条件

您在本地计算机上有一个 SSH 公钥，可以提供给安装程序。该密钥将用于对集群节点进行 SSH 身份验证，以便进行调试和灾难恢复。
您已获得 OpenShift Container Platform 安装程序和集群的拉取密钥。
从镜像存储库的命令输出中获取imageContentSources部分。
获取镜像注册表证书的内容。

步骤

创建一个安装目录来存储您所需的安装资产。

$ mkdir <installation_directory>

您必须创建一个目录。某些安装资产（如引导 X.509 证书）的有效期很短，因此您不能重用安装目录。如果您想重用来自另一个集群安装的单个文件，您可以将它们复制到您的目录中。但是，安装资产的文件名在不同版本之间可能会更改。从早期 OpenShift Container Platform 版本复制安装文件时，请谨慎操作。

自定义提供的示例install-config.yaml文件模板，并将其保存在<installation_directory>中。

您必须将此配置文件命名为install-config.yaml。

除非您使用 RHCOS 默认信任的注册表（例如docker.io），否则您必须在additionalTrustBundle部分中提供镜像存储库证书的内容。在大多数情况下，您必须提供镜像的证书。
您必须包含从镜像存储库命令输出中获取的imageContentSources部分。

ImageContentSourcePolicy文件是在镜像过程完成后作为oc mirror的输出生成的。
oc mirror命令会生成一个ImageContentSourcePolicy文件，其中包含定义ImageContentSourcePolicy所需的 YAML。复制此文件中的文本，并将其粘贴到您的install-config.yaml文件中。
您必须运行两次“oc mirror”命令。第一次运行oc mirror命令时，您将获得完整的ImageContentSourcePolicy文件。第二次运行oc mirror命令时，您只会获得第一次运行和第二次运行之间的差异。由于此行为，您必须始终备份这些文件，以防您需要将它们合并到一个完整的ImageContentSourcePolicy文件中。保留这两个输出文件的备份可以确保您拥有完整的ImageContentSourcePolicy文件。

备份install-config.yaml文件，以便您可以使用它安装多个集群。

install-config.yaml文件将在安装过程的下一步中使用。您现在必须备份它。

其他资源

裸机的安装配置参数

裸机安装的`install-config.yaml`文件示例

您可以自定义install-config.yaml文件以指定有关OpenShift Container Platform集群平台的更多详细信息，或修改所需参数的值。

apiVersion: v1
baseDomain: example.com (1)
compute: (2)
- hyperthreading: Enabled (3)
  name: worker
  replicas: 0 (4)
controlPlane: (2)
  hyperthreading: Enabled (3)
  name: master
  replicas: 3 (5)
metadata:
  name: test (6)
networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14 (7)
    hostPrefix: 23 (8)
  networkType: OVNKubernetes (9)
  serviceNetwork: (10)
  - 172.30.0.0/16
platform:
  none: {} (11)
fips: false (12)
pullSecret: '{"auths":{"<local_registry>": {"auth": "<credentials>","email": "[email protected]"}}}' (13)
sshKey: 'ssh-ed25519 AAAA...' (14)
additionalTrustBundle: | (15)
  -----BEGIN CERTIFICATE-----
  ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
  -----END CERTIFICATE-----
imageContentSources: (16)
- mirrors:
  - <local_registry>/<local_repository_name>/release
  source: quay.io/openshift-release-dev/ocp-release
- mirrors:
  - <local_registry>/<local_repository_name>/release
  source: quay.io/openshift-release-dev/ocp-v4.0-art-dev

1 集群的基本域名。所有DNS记录都必须为此基本域的子域名，并且包含集群名称。

2 controlPlane部分是一个单映射，但compute部分是映射序列。为了满足不同数据结构的要求，compute部分的第一行必须以连字符-开头，而controlPlane部分的第一行则不能。仅使用一个控制平面池。

指定是启用还是禁用同时多线程 (SMT) 或超线程。默认情况下，启用 SMT 以提高机器中内核的性能。您可以将其参数值设置为Disabled将其禁用。如果禁用 SMT，则必须在所有集群机器中禁用它；这包括控制平面机器和计算机器。

默认情况下启用同时多线程 (SMT)。如果您的 BIOS 设置中未启用 SMT，则hyperthreading参数无效。

如果您在 BIOS 或install-config.yaml文件中禁用了hyperthreading，请确保您的容量规划考虑到了机器性能的大幅下降。

在用户预配的基础架构上安装 OpenShift Container Platform 时，必须将此值设置为0。在安装程序预配的安装中，该参数控制集群为您创建和管理的计算机器数量。在用户预配的安装中，您必须在完成集群安装之前手动部署计算机器。

如果您要安装三节点集群，请在安装 Red Hat Enterprise Linux CoreOS (RHCOS) 机器时不要部署任何计算机器。

5 您添加到集群的控制平面机器的数量。由于集群使用这些值作为集群中 etcd 端点的数量，因此该值必须与您部署的控制平面机器的数量匹配。

6 您在 DNS 记录中指定的集群名称。

分配 Pod IP 地址的 IP 地址块。此块不得与现有物理网络重叠。这些 IP 地址用于 Pod 网络。如果您需要从外部网络访问 Pod，则必须配置负载均衡器和路由器来管理流量。

E 类 CIDR 范围预留供将来使用。要使用 E 类 CIDR 范围，您必须确保您的网络环境接受 E 类 CIDR 范围内的 IP 地址。

8 分配给每个节点的子网前缀长度。例如，如果hostPrefix设置为23，则每个节点将从给定的cidr分配一个/23子网，允许 510 (2^(32 - 23) - 2) 个 Pod IP 地址。如果您需要从外部网络访问节点，请配置负载均衡器和路由器来管理流量。

9 要安装的集群网络插件。默认值OVNKubernetes是唯一支持的值。

10 用于服务 IP 地址的 IP 地址池。您只能输入一个 IP 地址池。此块不得与现有物理网络重叠。如果您需要从外部网络访问服务，则必须配置负载均衡器和路由器来管理流量。

您必须将平台设置为none。您不能为您的平台提供其他平台配置变量。

使用平台类型none安装的集群无法使用某些功能，例如使用 Machine API 管理计算机器。即使连接到集群的计算机器安装在通常支持该功能的平台上，此限制也适用。此参数安装后无法更改。

是否启用或禁用 FIPS 模式。默认情况下，未启用 FIPS 模式。如果启用 FIPS 模式，则运行 OpenShift Container Platform 的 Red Hat Enterprise Linux CoreOS (RHCOS) 机器将绕过默认的 Kubernetes 加密套件，并改用 RHCOS 提供的加密模块。

要为您的集群启用 FIPS 模式，您必须从配置为在 FIPS 模式下运行的 Red Hat Enterprise Linux (RHEL) 计算机运行安装程序。有关在 RHEL 上配置 FIPS 模式的更多信息，请参阅将 RHEL 切换到 FIPS 模式。

在运行在 FIPS 模式下启动的 Red Hat Enterprise Linux (RHEL) 或 Red Hat Enterprise Linux CoreOS (RHCOS) 时，OpenShift Container Platform 核心组件仅在 x86_64、ppc64le 和 s390x 架构上使用已提交给 NIST 进行 FIPS 140-2/140-3 验证的 RHEL 加密库。

13 对于<local_registry>，请指定镜像注册表用于提供内容的注册表域名，以及可选的端口。例如，registry.example.com或registry.example.com:5000。对于<credentials>，请指定镜像注册表的 Base64 编码用户名和密码。

Red Hat Enterprise Linux CoreOS (RHCOS) 中core用户的 SSH 公钥。

对于要执行安装调试或灾难恢复的生产 OpenShift Container Platform 集群，请指定您的ssh-agent进程使用的 SSH 密钥。

15 提供您用于镜像注册表的证书文件的内容。

根据您用于镜像存储库的命令的输出提供imageContentSources部分。

使用oc adm release mirror命令时，请使用imageContentSources部分的输出。
使用oc mirror命令时，请使用运行命令生成的ImageContentSourcePolicy文件的repositoryDigestMirrors部分。
ImageContentSourcePolicy已弃用。有关更多信息，请参见*配置镜像注册表存储库镜像*。

其他资源

有关 API 和应用程序入口负载均衡要求的更多信息，请参见用户预配基础架构的负载均衡要求。

在安装期间配置集群范围的代理

生产环境可能会拒绝直接访问互联网，而是提供 HTTP 或 HTTPS 代理。您可以通过在install-config.yaml文件中配置代理设置来配置新的 OpenShift Container Platform 集群以使用代理。

对于裸机安装，如果您没有从install-config.yaml文件中networking.machineNetwork[].cidr字段中指定的范围内分配节点 IP 地址，则必须将其包含在proxy.noProxy字段中。

先决条件

您已拥有现有的install-config.yaml文件。

您已检查集群需要访问的站点，并确定其中哪些站点需要绕过代理。默认情况下，所有集群出口流量都会被代理，包括对托管云提供商 API 的调用。如有必要，您可以将站点添加到Proxy对象的spec.noProxy字段中以绕过代理。

Proxy对象的status.noProxy字段将填充安装配置中的networking.machineNetwork[].cidr、networking.clusterNetwork[].cidr和networking.serviceNetwork[]字段的值。

对于在 Amazon Web Services (AWS)、Google Cloud Platform (GCP)、Microsoft Azure 和 Red Hat OpenStack Platform (RHOSP) 上的安装，Proxy对象的status.noProxy字段还会填充实例元数据端点 (169.254.169.254)。

步骤

编辑您的install-config.yaml文件并添加代理设置。例如：

apiVersion: v1
baseDomain: my.domain.com
proxy:
  httpProxy: http://<username>:<pswd>@<ip>:<port> (1)
  httpsProxy: https://<username>:<pswd>@<ip>:<port> (2)
  noProxy: example.com (3)
additionalTrustBundle: | (4)
    -----BEGIN CERTIFICATE-----
    <MY_TRUSTED_CA_CERT>
    -----END CERTIFICATE-----
additionalTrustBundlePolicy: <policy_to_add_additionalTrustBundle> (5)

1	用于创建集群外部 HTTP 连接的代理 URL。URL 方案必须为`http`。
2	用于创建集群外部 HTTPS 连接的代理 URL。
3	要从代理中排除的目标域名、IP 地址或其他网络 CIDR 的逗号分隔列表。在域名前加`.`以仅匹配子域名。例如，`.y.com`匹配`x.y.com`，但不匹配`y.com`。使用`*`绕过所有目标的代理。
4	如果提供，安装程序将生成一个名为`user-ca-bundle`的 config map，位于`openshift-config`命名空间中，其中包含一个或多个代理 HTTPS 连接所需的额外 CA 证书。集群网络操作员随后将创建一个`trusted-ca-bundle` config map，并将这些内容与 Red Hat Enterprise Linux CoreOS (RHCOS) 信任捆绑包合并，并且此 config map 在`Proxy`对象的`trustedCA`字段中引用。除非代理的身份证书由 RHCOS 信任捆绑包中的授权机构签名，否则需要`additionalTrustBundle`字段。
5	可选：确定`Proxy`对象的配置以在`trustedCA`字段中引用`user-ca-bundle` config map 的策略。允许的值为`Proxyonly`和`Always`。使用`Proxyonly`仅在配置`http/https`代理时引用`user-ca-bundle` config map。使用`Always`始终引用`user-ca-bundle` config map。默认值为`Proxyonly`。

安装程序不支持代理readinessEndpoints字段。

如果安装程序超时，请重新启动，然后使用安装程序的wait-for命令完成部署。例如：

$ ./openshift-install wait-for install-complete --log-level debug

保存文件并在安装 OpenShift Container Platform 时引用它。

安装程序创建一个名为cluster的集群范围代理，该代理使用提供的install-config.yaml文件中的代理设置。如果未提供代理设置，则仍然会创建cluster Proxy对象，但它将具有 nil spec。

仅支持名为cluster的Proxy对象，并且无法创建其他代理。

配置三节点集群

您可以选择在一个仅包含三个控制平面机器的裸机集群中部署零计算机器。这为集群管理员和开发人员提供了更小、更高效的集群，可用于测试、开发和生产。

在三节点 OpenShift Container Platform 环境中，三个控制平面机器是可调度的，这意味着您的应用程序工作负载将安排在这些机器上运行。

先决条件

您已拥有现有的install-config.yaml文件。

步骤

确保在您的install-config.yaml文件中将计算副本的数量设置为0，如下所示的compute段落：

compute:
- name: worker
  platform: {}
  replicas: 0

在用户预配的基础架构上安装 OpenShift Container Platform 时，无论您部署的计算机器数量是多少，都必须将计算机器的replicas参数值设置为0。在安装程序预配的安装中，此参数控制集群为您创建和管理的计算机器数量。这并不适用于用户预配的安装，其中计算机器是手动部署的。

对于三节点集群安装，请遵循以下步骤：

如果您正在部署一个具有零计算节点的三节点集群，则 Ingress Controller Pod 将在控制平面节点上运行。在三节点集群部署中，您必须配置您的应用程序入口负载均衡器以将 HTTP 和 HTTPS 流量路由到控制平面节点。有关更多信息，请参阅“用户预配基础架构的负载均衡要求”部分。
在以下过程中创建 Kubernetes 清单文件时，请确保<installation_directory>/manifests/cluster-scheduler-02-config.yml文件中的mastersSchedulable参数设置为true。这允许您的应用程序工作负载在控制平面节点上运行。
创建 Red Hat Enterprise Linux CoreOS (RHCOS) 机器时，请勿部署任何计算节点。

创建 Kubernetes 清单和 Ignition 配置文件

因为您必须修改一些集群定义文件并手动启动集群机器，所以您必须生成集群配置机器所需的 Kubernetes 清单和 Ignition 配置文件。

安装配置文件转换为 Kubernetes 清单。清单打包到 Ignition 配置文件中，稍后用于配置集群机器。

OpenShift Container Platform 安装程序生成的 Ignition 配置文件包含在 24 小时后过期的证书，然后在此时续订。如果集群在续订证书之前关闭，并且集群在 24 小时后重新启动，则集群会自动恢复过期的证书。例外情况是，您必须手动批准挂起的node-bootstrapper证书签名请求 (CSR) 以恢复 kubelet 证书。有关更多信息，请参阅“从过期的控制平面证书中恢复”文档。
建议您在生成 Ignition 配置文件后 12 小时内使用它们，因为 24 小时证书会在集群安装后 16 到 22 小时之间轮换。在 12 小时内使用 Ignition 配置文件，可以避免在安装过程中运行证书更新时安装失败。

先决条件

您已获得 OpenShift Container Platform 安装程序。对于受限网络安装，这些文件位于您的镜像主机上。
您已创建install-config.yaml安装配置文件。

步骤

更改到包含 OpenShift Container Platform 安装程序的目录，并为集群生成 Kubernetes 清单：
```
$ ./openshift-install create manifests --dir <installation_directory> (1)
```
1 对于<installation_directory>，请指定包含您创建的install-config.yaml文件的安装目录。

如果您正在安装三节点集群，请跳过以下步骤以允许控制平面节点可调度。

当您将控制平面节点从默认的不可调度状态配置为可调度状态时，需要额外的订阅。这是因为控制平面节点随后将成为计算节点。
检查<installation_directory>/manifests/cluster-scheduler-02-config.yml Kubernetes 清单文件中的mastersSchedulable参数是否设置为false。此设置可防止 Pod 在控制平面机器上调度。
1. 打开<installation_directory>/manifests/cluster-scheduler-02-config.yml文件。
2. 找到mastersSchedulable参数并确保将其设置为false。
3. 保存并退出文件。
要创建 Ignition 配置文件，请从包含安装程序的目录运行以下命令：
```
$ ./openshift-install create ignition-configs --dir <installation_directory> (1)
```
1 对于<installation_directory>，请指定相同的安装目录。

将在安装目录中为引导程序、控制平面和计算节点创建 Ignition 配置文件。kubeadmin-password和kubeconfig文件将创建在./<installation_directory>/auth目录中。
```
.
├── auth
│   ├── kubeadmin-password
│   └── kubeconfig
├── bootstrap.ign
├── master.ign
├── metadata.json
└── worker.ign
```

其他资源

有关恢复 kubelet 证书的更多信息，请参阅恢复已过期的控制平面证书。

配置 chrony 时间服务

您必须通过修改 chrony.conf 文件的内容并将这些内容作为机器配置传递到您的节点，来设置 chrony 时间服务 (chronyd) 使用的时间服务器和相关设置。

步骤

创建一个包含 chrony.conf 文件内容的 Butane 配置。例如，要在工作节点上配置 chrony，请创建一个 99-worker-chrony.bu 文件。

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

variant: openshift
version: 4.17.0
metadata:
  name: 99-worker-chrony (1)
  labels:
    machineconfiguration.openshift.io/role: worker (1)
storage:
  files:
  - path: /etc/chrony.conf
    mode: 0644 (2)
    overwrite: true
    contents:
      inline: |
        pool 0.rhel.pool.ntp.org iburst (3)
        driftfile /var/lib/chrony/drift
        makestep 1.0 3
        rtcsync
        logdir /var/log/chrony

1	在控制平面节点上，在这两个位置将 `worker` 替换为 `master`。
2	在机器配置文件中为 `mode` 字段指定八进制值模式。创建文件并应用更改后，`mode` 将转换为十进制值。您可以使用命令 `oc get mc <mc-name> -o yaml` 检查 YAML 文件。
3	指定任何有效且可访问的时间源，例如 DHCP 服务器提供的时间源。

使用 Butane 生成一个 MachineConfig 对象文件 99-worker-chrony.yaml，其中包含要传递到节点的配置。
```
$ butane 99-worker-chrony.bu -o 99-worker-chrony.yaml
```
可以通过以下两种方式之一应用配置
- 如果集群尚未运行，则在生成清单文件后，将 MachineConfig 对象文件添加到 <installation_directory>/openshift 目录，然后继续创建集群。
- 如果集群已经在运行，则应用该文件。
  $ oc apply -f ./99-worker-chrony.yaml

安装 RHCOS 并启动 OpenShift Container Platform 引导过程

要在您配置的裸机基础架构上安装 OpenShift Container Platform，您必须在机器上安装 Red Hat Enterprise Linux CoreOS (RHCOS)。安装 RHCOS 时，必须提供由 OpenShift Container Platform 安装程序为要安装的机器类型生成的 Ignition 配置文件。如果您已配置合适的网络、DNS 和负载均衡基础架构，则 RHCOS 机器重新启动后，OpenShift Container Platform 引导过程将自动开始。

要安装 RHCOS，请按照使用 ISO 镜像或网络 PXE 引导的步骤操作。

此安装文档中包含的计算节点部署步骤是特定于 RHCOS 的。如果您选择部署基于 RHEL 的计算节点，则您将负责所有操作系统生命周期管理和维护，包括执行系统更新、应用补丁以及完成所有其他必需的任务。仅支持 RHEL 8 计算机器。

您可以使用以下方法在 ISO 和 PXE 安装过程中配置 RHCOS

内核参数：您可以使用内核参数来提供特定于安装的信息。例如，您可以指定已上传到 HTTP 服务器的 RHCOS 安装文件的位置以及要安装的节点类型的 Ignition 配置文件的位置。对于 PXE 安装，您可以使用 APPEND 参数将参数传递到实时安装程序的内核。对于 ISO 安装，您可以中断实时安装引导过程以添加内核参数。在这两种安装情况下，您可以使用特殊的 coreos.inst.* 参数来指导实时安装程序，以及用于打开或关闭标准内核服务的标准安装引导参数。
Ignition 配置：OpenShift Container Platform Ignition 配置文件 (*.ign) 是特定于您正在安装的节点类型的。您在 RHCOS 安装期间传递引导程序、控制平面或计算节点 Ignition 配置文件的位置，以便它在第一次启动时生效。在特殊情况下，您可以创建一个单独的、有限的 Ignition 配置文件以传递到实时系统。该 Ignition 配置文件可以执行某些任务，例如在完成安装后向预配系统报告成功。此特殊的 Ignition 配置文件由 coreos-installer 使用，并在安装的系统的第一次启动时应用。不要将标准的控制平面和计算节点 Ignition 配置文件直接提供给实时 ISO。
coreos-installer：您可以将实时 ISO 安装程序引导到 shell 提示符，这允许您在第一次启动之前以多种方式准备永久系统。特别是，您可以运行 coreos-installer 命令来识别要包含的各种工件、处理磁盘分区以及设置网络。在某些情况下，您可以配置实时系统上的功能并将它们复制到已安装的系统。

使用 ISO 安装还是 PXE 安装取决于您的情况。PXE 安装需要可用的 DHCP 服务和更多准备工作，但这可以使安装过程更加自动化。ISO 安装是一个更手动过程，如果您正在设置多个机器，则可能会很不方便。

从 OpenShift Container Platform 4.6 开始，RHCOS ISO 和其他安装工件支持在具有 4K 扇区的磁盘上安装。

使用 ISO 镜像安装 RHCOS

您可以使用 ISO 镜像在机器上安装 RHCOS。

先决条件

您已为集群创建了 Ignition 配置文件。
您已配置合适的网络、DNS 和负载均衡基础架构。
您有一个可以从您的计算机以及您创建的机器访问的 HTTP 服务器。
您已查看“高级 RHCOS 安装配置”部分，了解配置功能（例如网络和磁盘分区）的不同方法。

步骤

获取每个 Ignition 配置文件的 SHA512 散列值。例如，您可以在运行 Linux 的系统上使用以下命令获取 bootstrap.ign Ignition 配置文件的 SHA512 散列值
```
$ sha512sum <installation_directory>/bootstrap.ign
```
在后面的步骤中，将散列值提供给 coreos-installer 以验证集群节点上 Ignition 配置文件的真实性。

将安装程序创建的引导程序、控制平面和计算节点 Ignition 配置文件上传到您的 HTTP 服务器。记下这些文件的 URL。

您可以在将 Ignition 配置文件保存到 HTTP 服务器之前添加或更改其中的配置设置。如果您计划在安装完成后向集群添加更多计算机器，请不要删除这些文件。

从安装主机验证 Ignition 配置文件是否在 URL 上可用。以下示例获取引导节点的 Ignition 配置文件

$ curl -k http://<HTTP_server>/bootstrap.ign (1)

示例输出

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0{"ignition":{"version":"3.2.0"},"passwd":{"users":[{"name":"core","sshAuthorizedKeys":["ssh-rsa...

在命令中将 bootstrap.ign 替换为 master.ign 或 worker.ign 以验证控制平面和计算节点的 Ignition 配置文件是否也可用。

虽然可以从 RHCOS 镜像镜像页面获取您首选的操作系统实例安装方法所需的 RHCOS 镜像，但推荐的方法是从 openshift-install 命令的输出中获取正确版本的 RHCOS 镜像。

$ openshift-install coreos print-stream-json | grep '\.iso[^.]'

示例输出

"location": "<url>/art/storage/releases/rhcos-4.17-aarch64/<release>/aarch64/rhcos-<release>-live.aarch64.iso",
"location": "<url>/art/storage/releases/rhcos-4.17-ppc64le/<release>/ppc64le/rhcos-<release>-live.ppc64le.iso",
"location": "<url>/art/storage/releases/rhcos-4.17-s390x/<release>/s390x/rhcos-<release>-live.s390x.iso",
"location": "<url>/art/storage/releases/rhcos-4.17/<release>/x86_64/rhcos-<release>-live.x86_64.iso",

RHCOS 镜像可能不会随着每次 OpenShift Container Platform 版本的发布而更改。您必须下载版本号小于或等于您安装的 OpenShift Container Platform 版本的镜像。如果可用，请使用与您的 OpenShift Container Platform 版本匹配的镜像版本。此过程仅使用 ISO 镜像。此安装类型不支持 RHCOS qcow2 镜像。

ISO 文件名类似于以下示例

rhcos-<version>-live.<architecture>.iso

使用 ISO 启动 RHCOS 安装。使用以下安装选项之一
- 将ISO镜像刻录到磁盘并直接启动。
- 使用带外管理 (LOM) 接口进行ISO重定向。
启动RHCOS ISO镜像，无需指定任何选项或中断实时启动序列。等待安装程序在RHCOS实时环境中启动到shell提示符。

可以中断RHCOS安装启动过程以添加内核参数。但是，对于此ISO过程，应使用以下步骤中概述的coreos-installer命令，而不是添加内核参数。

运行coreos-installer命令并指定满足安装要求的选项。至少必须指定指向节点类型Ignition配置文件的URL以及要安装到的设备。

$ sudo coreos-installer install --ignition-url=http://<HTTP_server>/<node_type>.ign <device> --ignition-hash=sha512-<digest> (1) (2)

1	必须使用`sudo`运行`coreos-installer`命令，因为`core`用户没有执行安装所需的root权限。
2	当通过HTTP URL获取Ignition配置文件时，需要`--ignition-hash`选项来验证集群节点上Ignition配置文件的真实性。`<digest>`是在前一步获得的Ignition配置文件SHA512摘要。

如果要通过使用TLS的HTTPS服务器提供Ignition配置文件，可以在运行coreos-installer之前将内部证书颁发机构 (CA) 添加到系统信任存储区。

以下示例将引导节点安装初始化到/dev/sda设备。引导节点的Ignition配置文件是从具有IP地址192.168.1.2的HTTP Web服务器获取的。

$ sudo coreos-installer install --ignition-url=http://192.168.1.2:80/installation_directory/bootstrap.ign /dev/sda --ignition-hash=sha512-a5a2d43879223273c9b60af66b44202a1d1248fc01cf156c46d4a79f552b6bad47bc8cc78ddf0116e80c59d2ea9e32ba53bc807afbca581aa059311def2c3e3b

监控机器控制台上RHCOS安装的进度。

在开始OpenShift Container Platform安装之前，请确保每个节点上的安装都成功。观察安装过程也可以帮助确定可能出现的RHCOS安装问题的根本原因。
RHCOS安装完成后，必须重新启动系统。在系统重新启动期间，它会应用您指定的Ignition配置文件。

检查控制台输出以验证Ignition是否已运行。

示例命令

Ignition: ran on 2022/03/14 14:48:33 UTC (this boot)
Ignition: user-provided config was applied

继续为您的集群创建其他机器。

此时必须创建引导程序和控制平面机器。如果控制平面机器未设置为可调度状态，则在安装OpenShift Container Platform之前，还需创建至少两台计算机器。

如果网络、DNS和负载均衡器基础设施已就绪，则RHCOS节点重新启动后，OpenShift Container Platform引导过程将自动开始。

RHCOS节点不包含core用户的默认密码。您可以通过运行ssh core@<node>.<cluster_name>.<base_domain>作为具有访问权限的用户来访问节点，该用户可以访问与您在install_config.yaml文件中指定的公钥配对的SSH私钥。运行RHCOS的OpenShift Container Platform 4集群节点是不可变的，并依赖于Operator来应用集群更改。不建议使用SSH访问集群节点。但是，在调查安装问题时，如果OpenShift Container Platform API不可用，或者kubelet在目标节点上运行不正常，则可能需要SSH访问权限进行调试或灾难恢复。

使用PXE或iPXE启动安装RHCOS

您可以使用PXE或iPXE启动在机器上安装RHCOS。

先决条件

您已为集群创建了 Ignition 配置文件。
您已配置合适的网络、DNS 和负载均衡基础架构。
您已配置合适的PXE或iPXE基础设施。
您有一个可以从您的计算机以及您创建的机器访问的 HTTP 服务器。
您已查看“高级 RHCOS 安装配置”部分，了解配置功能（例如网络和磁盘分区）的不同方法。

步骤

将安装程序创建的引导程序、控制平面和计算节点 Ignition 配置文件上传到您的 HTTP 服务器。记下这些文件的 URL。

从安装主机验证 Ignition 配置文件是否在 URL 上可用。以下示例获取引导节点的 Ignition 配置文件

$ curl -k http://<HTTP_server>/bootstrap.ign (1)

示例输出

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0{"ignition":{"version":"3.2.0"},"passwd":{"users":[{"name":"core","sshAuthorizedKeys":["ssh-rsa...

在命令中将 bootstrap.ign 替换为 master.ign 或 worker.ign 以验证控制平面和计算节点的 Ignition 配置文件是否也可用。

虽然可以从RHCOS镜像镜像页面获取安装操作系统实例所需的首选方法所需的RHCOSkernel、initramfs和rootfs文件，但获取正确版本的RHCOS文件的推荐方法是从openshift-install命令的输出中获取。

$ openshift-install coreos print-stream-json | grep -Eo '"https.*(kernel-|initramfs.|rootfs.)\w+(\.img)?"'

示例输出

"<url>/art/storage/releases/rhcos-4.17-aarch64/<release>/aarch64/rhcos-<release>-live-kernel-aarch64"
"<url>/art/storage/releases/rhcos-4.17-aarch64/<release>/aarch64/rhcos-<release>-live-initramfs.aarch64.img"
"<url>/art/storage/releases/rhcos-4.17-aarch64/<release>/aarch64/rhcos-<release>-live-rootfs.aarch64.img"
"<url>/art/storage/releases/rhcos-4.17-ppc64le/49.84.202110081256-0/ppc64le/rhcos-<release>-live-kernel-ppc64le"
"<url>/art/storage/releases/rhcos-4.17-ppc64le/<release>/ppc64le/rhcos-<release>-live-initramfs.ppc64le.img"
"<url>/art/storage/releases/rhcos-4.17-ppc64le/<release>/ppc64le/rhcos-<release>-live-rootfs.ppc64le.img"
"<url>/art/storage/releases/rhcos-4.17-s390x/<release>/s390x/rhcos-<release>-live-kernel-s390x"
"<url>/art/storage/releases/rhcos-4.17-s390x/<release>/s390x/rhcos-<release>-live-initramfs.s390x.img"
"<url>/art/storage/releases/rhcos-4.17-s390x/<release>/s390x/rhcos-<release>-live-rootfs.s390x.img"
"<url>/art/storage/releases/rhcos-4.17/<release>/x86_64/rhcos-<release>-live-kernel-x86_64"
"<url>/art/storage/releases/rhcos-4.17/<release>/x86_64/rhcos-<release>-live-initramfs.x86_64.img"
"<url>/art/storage/releases/rhcos-4.17/<release>/x86_64/rhcos-<release>-live-rootfs.x86_64.img"

RHCOS工件可能不会随着OpenShift Container Platform的每次发布而更改。必须下载版本号小于或等于要安装的OpenShift Container Platform版本的镜像。对于此过程，仅使用下面描述的适当kernel、initramfs和rootfs工件。此安装类型不支持RHCOS QCOW2镜像。

文件名包含OpenShift Container Platform版本号。它们类似于以下示例：

kernel: rhcos-<version>-live-kernel-<architecture>
initramfs: rhcos-<version>-live-initramfs.<architecture>.img
rootfs: rhcos-<version>-live-rootfs.<architecture>.img

将rootfs、kernel和initramfs文件上传到您的HTTP服务器。

如果计划在安装完成后向集群添加更多计算机器，请不要删除这些文件。
配置网络启动基础设施，以便在RHCOS安装到机器上后，机器从本地磁盘启动。

为RHCOS镜像配置PXE或iPXE安装并开始安装。

修改适合您环境的以下示例菜单项之一，并验证镜像和Ignition文件是否可正确访问。

对于PXE (x86_64)

DEFAULT pxeboot
TIMEOUT 20
PROMPT 0
LABEL pxeboot
    KERNEL http://<HTTP_server>/rhcos-<version>-live-kernel-<architecture> (1)
    APPEND initrd=http://<HTTP_server>/rhcos-<version>-live-initramfs.<architecture>.img coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/bootstrap.ign (2) (3)

1	指定已上传到HTTP服务器的实时`kernel`文件的位置。URL必须是HTTP、TFTP或FTP；不支持HTTPS和NFS。
2	如果使用多个网卡，请在`ip`选项中指定单个接口。例如，要在名为`eno1`的网卡上使用DHCP，请设置`ip=eno1:dhcp`。
3	指定已上传到HTTP服务器的RHCOS文件的位置。`initrd`参数值是`initramfs`文件的位置，`coreos.live.rootfs_url`参数值是`rootfs`文件的位置，`coreos.inst.ignition_url`参数值是引导Ignition配置文件的位置。还可以向`APPEND`行添加更多内核参数以配置网络或其他启动选项。

此配置不会在具有图形控制台的机器上启用串行控制台访问。要配置不同的控制台，请向APPEND行添加一个或多个console=参数。例如，添加console=tty0 console=ttyS0可将第一个PC串行端口设置为主要控制台，并将图形控制台设置为辅助控制台。有关更多信息，请参阅如何在Red Hat Enterprise Linux中设置串行终端和/或控制台？以及“高级RHCOS安装配置”部分中的“为PXE和ISO安装启用串行控制台”。

对于iPXE (x86_64 + aarch64)

kernel http://<HTTP_server>/rhcos-<version>-live-kernel-<architecture> initrd=main coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/bootstrap.ign (1) (2)
initrd --name main http://<HTTP_server>/rhcos-<version>-live-initramfs.<architecture>.img (3)
boot

1	指定已上传到HTTP服务器的RHCOS文件的位置。`kernel`参数值是`kernel`文件的位置，`initrd=main`参数对于在UEFI系统上启动是必需的，`coreos.live.rootfs_url`参数值是`rootfs`文件的位置，`coreos.inst.ignition_url`参数值是引导Ignition配置文件的位置。
2	如果使用多个网卡，请在`ip`选项中指定单个接口。例如，要在名为`eno1`的网卡上使用DHCP，请设置`ip=eno1:dhcp`。
3	指定已上传到HTTP服务器的`initramfs`文件的位置。

此配置不会在具有图形控制台的机器上启用串行控制台访问。要配置不同的控制台，请向kernel行添加一个或多个console=参数。例如，添加console=tty0 console=ttyS0可将第一个PC串行端口设置为主控制台，并将图形控制台设置为辅助控制台。更多信息，请参见如何在Red Hat Enterprise Linux中设置串行终端和/或控制台？以及“高级RHCOS安装配置”部分中的“为PXE和ISO安装启用串行控制台”。

要在aarch64架构上网络启动CoreOS kernel，需要使用启用了IMAGE_GZIP选项的iPXE版本。请参见iPXE中的IMAGE_GZIP选项。

对于aarch64上的PXE（使用UEFI和Grub作为第二阶段）

menuentry 'Install CoreOS' {
    linux rhcos-<version>-live-kernel-<architecture>  coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/bootstrap.ign (1) (2)
    initrd rhcos-<version>-live-initramfs.<architecture>.img (3)
}

1	指定您上传到HTTP/TFTP服务器的RHCOS文件的位置。`kernel`参数值是TFTP服务器上`kernel`文件的位置。`coreos.live.rootfs_url`参数值是`rootfs`文件的位置，`coreos.inst.ignition_url`参数值是HTTP服务器上引导Ignition配置文件的位置。
2	如果使用多个网卡，请在`ip`选项中指定单个接口。例如，要在名为`eno1`的网卡上使用DHCP，请设置`ip=eno1:dhcp`。
3	指定您上传到TFTP服务器的`initramfs`文件的位置。

监控机器控制台上RHCOS安装的进度。

在开始OpenShift Container Platform安装之前，请确保每个节点上的安装都成功。观察安装过程也可以帮助确定可能出现的RHCOS安装问题的根本原因。
RHCOS安装完成后，系统将重新启动。重新启动期间，系统将应用您指定的Ignition配置文件。

检查控制台输出以验证Ignition是否已运行。

示例命令

Ignition: ran on 2022/03/14 14:48:33 UTC (this boot)
Ignition: user-provided config was applied

继续为您的集群创建机器。

您必须在此处创建引导程序和控制平面机器。如果控制平面机器未设置为可调度状态，则在安装集群之前，还需创建至少两台计算机器。

如果网络、DNS和负载均衡器基础设施已就绪，则RHCOS节点重新启动后，OpenShift Container Platform引导过程将自动开始。

高级RHCOS安装配置

手动配置Red Hat Enterprise Linux CoreOS (RHCOS)节点以用于OpenShift Container Platform的一个主要优势在于能够进行默认OpenShift Container Platform安装方法无法提供的配置。本节介绍了一些您可以使用以下技术进行的配置：

将内核参数传递给实时安装程序
从实时系统手动运行coreos-installer
自定义实时ISO或PXE引导映像

本节中详细介绍的手动Red Hat Enterprise Linux CoreOS (RHCOS)安装的高级配置主题涉及磁盘分区、网络和以不同方式使用Ignition配置文件。

使用高级网络选项进行PXE和ISO安装

OpenShift Container Platform节点的网络默认情况下使用DHCP来收集所有必要的配置设置。要设置静态IP地址或配置特殊设置（例如bonding），您可以执行以下操作之一：

启动实时安装程序时传递特殊的内核参数。
使用机器配置将网络文件复制到已安装的系统。
从实时安装程序的shell提示符配置网络，然后将这些设置复制到已安装的系统，以便在已安装的系统第一次启动时生效。

要配置PXE或iPXE安装，请使用以下选项之一：

请参阅“高级RHCOS安装参考”表。
使用机器配置将网络文件复制到已安装的系统。

要配置ISO安装，请使用以下步骤。

步骤

启动ISO安装程序。
从实时系统shell提示符，使用可用的RHEL工具（例如nmcli或nmtui）配置实时系统的网络。
运行coreos-installer命令安装系统，并添加--copy-network选项以复制网络配置。例如：
```
$ sudo coreos-installer install --copy-network \
     --ignition-url=http://host/worker.ign /dev/disk/by-id/scsi-<serial_number>
```
--copy-network选项仅复制在/etc/NetworkManager/system-connections下找到的网络配置。特别是，它不会复制系统主机名。
重新启动到已安装的系统。

其他资源

请参阅RHEL 8文档中的nmcli入门和nmtui入门，以了解有关nmcli和nmtui工具的更多信息。

磁盘分区

在Red Hat Enterprise Linux CoreOS (RHCOS)安装期间，会在OpenShift Container Platform集群节点上创建磁盘分区。特定架构的每个RHCOS节点都使用相同的分区布局，除非您覆盖默认分区配置。在RHCOS安装期间，根文件系统的大小将增加，以使用目标设备上任何剩余的可用空间。

在您的节点上使用自定义分区方案可能会导致OpenShift Container Platform无法监控或警告某些节点分区。如果您覆盖默认分区，请参阅了解OpenShift文件系统监控（逐出条件），以了解有关OpenShift Container Platform如何监控您的主机文件系统的更多信息。

OpenShift Container Platform监控以下两个文件系统标识符：

nodefs，包含/var/lib/kubelet的文件系统
imagefs，包含/var/lib/containers的文件系统

对于默认分区方案，nodefs和imagefs监控相同的根文件系统/。

要在OpenShift Container Platform集群节点上安装RHCOS时覆盖默认分区，必须创建单独的分区。考虑一下您想要为容器和容器映像添加单独的存储分区的情况。例如，通过在单独的分区中挂载/var/lib/containers，kubelet 将单独监控/var/lib/containers作为imagefs目录，并将根文件系统作为nodefs目录。

如果您已调整磁盘大小以托管更大的文件系统，请考虑创建单独的/var/lib/containers分区。考虑调整具有xfs格式的磁盘大小，以减少由大量分配组引起的CPU时间问题。

创建单独的`/var`分区

通常，您应该使用RHCOS安装期间创建的默认磁盘分区。但是，在某些情况下，您可能想要为预计会增长的目录创建单独的分区。

OpenShift Container Platform支持添加单个分区以将存储附加到/var目录或/var的子目录。例如：

/var/lib/containers：保存与容器相关的內容，随着向系统添加更多映像和容器，该内容可能会增长。
/var/lib/etcd：保存您可能想要为了性能优化etcd存储等目的而单独保留的数据。
/var：保存您可能想要为了审核等目的而单独保留的数据。

对于大于 100GB 的磁盘，特别是大于 1TB 的磁盘，请创建单独的 /var 分区。

将 /var 目录的内容单独存储，可以更容易地根据需要扩展这些区域的存储空间，并在以后重新安装 OpenShift Container Platform 时保持数据完整。使用此方法，您无需再次拉取所有容器，也无需在更新系统时复制大量的日志文件。

为 /var 目录或 /var 的子目录使用单独的分区还可以防止分区目录中的数据增长填满根文件系统。

以下步骤通过添加一个机器配置清单来设置单独的 /var 分区，该清单在安装的准备阶段被包装到节点类型的 Ignition 配置文件中。

步骤

在您的安装主机上，切换到包含 OpenShift Container Platform 安装程序的目录，并为集群生成 Kubernetes 清单。
```
$ openshift-install create manifests --dir <installation_directory>
```

创建一个 Butane 配置文件来配置附加分区。例如，将文件命名为 $HOME/clusterconfig/98-var-partition.bu，将磁盘设备名称更改为 worker 系统上存储设备的名称，并根据需要设置存储大小。此示例将 /var 目录放在单独的分区上。

variant: openshift
version: 4.17.0
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: 98-var-partition
storage:
  disks:
  - device: /dev/disk/by-id/<device_name> (1)
    partitions:
    - label: var
      start_mib: <partition_start_offset> (2)
      size_mib: <partition_size> (3)
      number: 5
  filesystems:
    - device: /dev/disk/by-partlabel/var
      path: /var
      format: xfs
      mount_options: [defaults, prjquota] (4)
      with_mount_unit: true

1	您要分区的磁盘的存储设备名称。
2	将数据分区添加到启动磁盘时，建议最小偏移值为 25000 MiB。根文件系统将自动调整大小以填充直到指定偏移量的所有可用空间。如果未指定偏移值，或者指定的值小于建议的最小值，则生成的根文件系统将太小，并且以后重新安装 RHCOS 可能会覆盖数据分区的开头。
3	数据分区的大小（以 MiB 为单位）。
4	对于用于容器存储的文件系统，必须启用 `prjquota` 挂载选项。

创建单独的 /var 分区时，如果不同的实例类型没有相同的设备名称，则不能对计算节点使用不同的实例类型。

从 Butane 配置文件创建清单，并将其保存到 clusterconfig/openshift 目录。例如，运行以下命令：
```
$ butane $HOME/clusterconfig/98-var-partition.bu -o $HOME/clusterconfig/openshift/98-var-partition.yaml
```
创建 Ignition 配置文件
```
$ openshift-install create ignition-configs --dir <installation_directory> (1)
```
1 对于<installation_directory>，请指定相同的安装目录。

Ignition 配置文件是在安装目录中为引导程序、控制平面和计算节点创建的。
```
.
├── auth
│   ├── kubeadmin-password
│   └── kubeconfig
├── bootstrap.ign
├── master.ign
├── metadata.json
└── worker.ign
```
<installation_directory>/manifest 和 <installation_directory>/openshift 目录中的文件将被包装到 Ignition 配置文件中，包括包含 98-var-partition 自定义 MachineConfig 对象的文件。

后续步骤

您可以在 RHCOS 安装期间引用 Ignition 配置文件来应用自定义磁盘分区。

保留现有分区

对于 ISO 安装，您可以向 coreos-installer 命令添加选项，使安装程序能够维护一个或多个现有分区。对于 PXE 安装，您可以向 APPEND 参数添加 coreos.inst.* 选项来保留分区。

保存的分区可能是现有 OpenShift Container Platform 系统中的数据分区。您可以通过分区标签或编号来识别要保留的磁盘分区。

如果您保存现有分区，并且这些分区没有为 RHCOS 留下足够的空闲空间，则安装将失败，但不会损坏保存的分区。

在 ISO 安装期间保留现有分区

此示例保留分区标签以 data 开头（data*）的任何分区。

# coreos-installer install --ignition-url http://10.0.2.2:8080/user.ign \
        --save-partlabel 'data*' /dev/disk/by-id/scsi-<serial_number>

以下示例说明了以保留磁盘上的第六 (6) 个分区的方式运行 coreos-installer。

# coreos-installer install --ignition-url http://10.0.2.2:8080/user.ign \
        --save-partindex 6 /dev/disk/by-id/scsi-<serial_number>

此示例保留第 5 个及更高的分区。

# coreos-installer install --ignition-url http://10.0.2.2:8080/user.ign
        --save-partindex 5- /dev/disk/by-id/scsi-<serial_number>

在前面使用分区保存的示例中，coreos-installer 会立即重新创建分区。

在 PXE 安装期间保留现有分区

此 APPEND 选项保留分区标签以 'data' 开头 ('data*') 的任何分区。

coreos.inst.save_partlabel=data*

此 APPEND 选项保留第 5 个及更高的分区。

coreos.inst.save_partindex=5-

此 APPEND 选项保留第 6 个分区。

coreos.inst.save_partindex=6

识别 Ignition 配置文件

在进行 RHCOS 手动安装时，您可以提供两种类型的 Ignition 配置文件，提供每种配置文件的原因都不同。

永久安装 Ignition 配置文件：每次手动 RHCOS 安装都需要传递 openshift-installer 生成的 Ignition 配置文件之一（例如 bootstrap.ign、master.ign 和 worker.ign）来执行安装。

不建议直接修改这些 Ignition 配置文件。您可以更新包装到 Ignition 配置文件中的清单文件，如前面部分的示例中所述。

对于 PXE 安装，您可以使用 coreos.inst.ignition_url= 选项在 APPEND 行上传递 Ignition 配置文件。对于 ISO 安装，在 ISO 启动到 shell 提示符后，您可以使用 --ignition-url= 选项在 coreos-installer 命令行上标识 Ignition 配置文件。在这两种情况下，仅支持 HTTP 和 HTTPS 协议。
实时安装 Ignition 配置文件：可以使用 coreos-installer 的 customize 子命令及其各种选项创建此类型。使用此方法，Ignition 配置文件将传递到实时安装介质，在启动时立即运行，并在 RHCOS 系统安装到磁盘之前或之后执行设置任务。此方法应仅用于执行必须执行一次且以后不再应用的任务，例如使用无法使用机器配置执行的高级分区。

对于 PXE 或 ISO 启动，您可以创建 Ignition 配置文件并将 ignition.config.url= 选项添加到 APPEND，以标识 Ignition 配置文件的位置。您还需要附加 ignition.firstboot ignition.platform.id=metal，否则 ignition.config.url 选项将被忽略。

默认控制台配置

从 OpenShift Container Platform 4.17 启动映像安装的 Red Hat Enterprise Linux CoreOS (RHCOS) 节点使用默认控制台，该控制台旨在适应大多数虚拟化和裸机设置。不同的云和虚拟化平台可能会根据所选架构使用不同的默认设置。裸机安装使用内核默认设置，这通常意味着图形控制台是主控制台，而串行控制台被禁用。

默认控制台可能与您的特定硬件配置不匹配，或者您可能有需要调整默认控制台的特定需求。例如：

您想出于调试目的访问控制台上的紧急 shell。
您的云平台不提供对图形控制台的交互式访问，但提供串行控制台。
您想启用多个控制台。

控制台配置继承自启动映像。这意味着现有集群中的新节点不受对默认控制台的更改的影响。

您可以通过以下方式配置裸机安装的控制台：

在命令行上手动使用 coreos-installer。
使用 coreos-installer iso customize 或 coreos-installer pxe customize 子命令以及 --dest-console 选项来创建自动化此过程的自定义映像。

对于高级自定义，请使用 coreos-installer iso 或 coreos-installer pxe 子命令（而不是内核参数）执行控制台配置。

为 PXE 和 ISO 安装启用串行控制台

默认情况下，Red Hat Enterprise Linux CoreOS (RHCOS) 串行控制台被禁用，所有输出都写入图形控制台。您可以为 ISO 安装启用串行控制台并重新配置引导加载程序，以便将输出发送到串行控制台和图形控制台。

步骤

启动ISO安装程序。

运行coreos-installer命令安装系统，分别添加两次--console选项来指定图形控制台和串行控制台。

$ coreos-installer install \
  --console=tty0 \(1)
  --console=ttyS0,<options> \(2)
  --ignition-url=http://host/worker.ign /dev/disk/by-id/scsi-<serial_number>

1	所需的次要控制台。在本例中为图形控制台。省略此选项将禁用图形控制台。
2	所需的 primary 控制台。在本例中为串行控制台。`options`字段定义波特率和其他设置。此字段的常用值为`11520n8`。如果未提供选项，则使用默认内核值`9600n8`。有关此选项格式的更多信息，请参阅Linux 内核串行控制台文档。

重新启动到已安装的系统。

可以使用coreos-installer install --append-karg选项并使用console=指定控制台来获得类似的结果。但是，这只会设置内核的控制台，而不会设置引导加载程序的控制台。

要配置PXE安装，请确保省略coreos.inst.install_dev内核命令行选项，并使用shell提示符手动运行coreos-installer，使用上述ISO安装过程。

自定义实时RHCOS ISO或PXE安装

您可以使用实时ISO映像或PXE环境通过将Ignition配置文件直接注入映像来安装RHCOS。这将创建一个自定义映像，您可以使用它来配置您的系统。

对于ISO映像，执行此操作的机制是coreos-installer iso customize子命令，它使用您的配置修改.iso文件。类似地，PXE环境的机制是coreos-installer pxe customize子命令，它创建一个包含自定义内容的新initramfs文件。

customize子命令是一个通用工具，也可以嵌入其他类型的自定义内容。以下任务是一些更常见自定义的一些示例。

注入自定义CA证书，以满足公司安全策略的要求。
配置网络设置，无需内核参数。
嵌入任意预安装和后安装脚本或二进制文件。

自定义实时RHCOS ISO映像

您可以使用coreos-installer iso customize子命令直接自定义实时RHCOS ISO映像。启动ISO映像时，自定义内容会自动应用。

您可以使用此功能配置ISO映像以自动安装RHCOS。

步骤

从coreos-installer镜像页面下载coreos-installer二进制文件。

从RHCOS镜像页面检索RHCOS ISO映像和Ignition配置文件，然后运行以下命令将Ignition配置文件直接注入ISO映像。

$ coreos-installer iso customize rhcos-<version>-live.x86_64.iso \
    --dest-ignition bootstrap.ign \ (1)
    --dest-device /dev/disk/by-id/scsi-<serial_number> (2)

1	从`openshift-installer`安装程序生成的Ignition配置文件。
2	指定此选项时，ISO映像会自动运行安装程序。否则，映像仍然配置为安装，但除非您指定`coreos.inst.install_dev`内核参数，否则不会自动安装。

可选：要删除ISO映像自定义内容并将映像恢复到原始状态，请运行
```
$ coreos-installer iso reset rhcos-<version>-live.x86_64.iso
```
您现在可以重新自定义实时ISO映像或以其原始状态使用它。

应用您的自定义内容会影响RHCOS的后续每次启动。

修改实时安装ISO映像以启用串行控制台

在使用OpenShift Container Platform 4.12及更高版本的集群上，串行控制台默认情况下处于禁用状态，所有输出都写入图形控制台。您可以按照以下步骤启用串行控制台。

步骤

从coreos-installer镜像页面下载coreos-installer二进制文件。

从RHCOS镜像页面检索RHCOS ISO映像，并运行以下命令自定义ISO映像以启用串行控制台接收输出。

$ coreos-installer iso customize rhcos-<version>-live.x86_64.iso \
  --dest-ignition <path> \(1)
  --dest-console tty0 \(2)
  --dest-console ttyS0,<options> \(3)
  --dest-device /dev/disk/by-id/scsi-<serial_number> (4)

1	要安装的Ignition配置文件的位置。
2	所需的次要控制台。在本例中为图形控制台。省略此选项将禁用图形控制台。
3	所需的 primary 控制台。在本例中为串行控制台。`options`字段定义波特率和其他设置。此字段的常用值为`115200n8`。如果未提供选项，则使用默认内核值`9600n8`。有关此选项格式的更多信息，请参阅Linux 内核串行控制台文档。
4	指定要安装到的磁盘。如果您省略此选项，ISO映像将自动运行安装程序，除非您还指定`coreos.inst.install_dev`内核参数，否则安装程序将失败。

--dest-console选项会影响已安装的系统，而不是实时ISO系统。要修改实时ISO系统的控制台，请使用--live-karg-append选项并使用console=指定控制台。

您的自定义内容已应用，并将影响ISO映像的后续每次启动。

可选：要删除ISO映像自定义内容并将映像恢复到其原始状态，请运行以下命令
```
$ coreos-installer iso reset rhcos-<version>-live.x86_64.iso
```
您现在可以重新自定义实时ISO映像或以其原始状态使用它。

修改实时安装ISO映像以使用自定义证书颁发机构

您可以使用customize子命令的--ignition-ca标志向Ignition提供证书颁发机构(CA)证书。您可以在安装引导期间和配置已安装的系统时使用CA证书。

自定义CA证书会影响Ignition获取远程资源的方式，但不会影响安装到系统上的证书。

步骤

从coreos-installer镜像页面下载coreos-installer二进制文件。
从RHCOS镜像页面检索RHCOS ISO映像，并运行以下命令自定义ISO映像以与自定义CA一起使用。
```
$ coreos-installer iso customize rhcos-<version>-live.x86_64.iso --ignition-ca cert.pem
```

coreos.inst.ignition_url内核参数不适用于--ignition-ca标志。您必须使用--dest-ignition标志为每个集群创建自定义映像。

应用您的自定义CA证书会影响RHCOS的后续每次启动。

使用自定义网络设置修改实时安装ISO映像

您可以将NetworkManager密钥文件嵌入到实时ISO映像中，并使用customize子命令的--network-keyfile标志将其传递到已安装的系统。

创建连接配置文件时，文件名必须使用.nmconnection扩展名。如果不使用.nmconnection扩展名，集群会将连接配置文件应用于实时环境，但在集群首次启动节点时不会应用配置，导致设置无法正常工作。

步骤

从coreos-installer镜像页面下载coreos-installer二进制文件。

为绑定接口创建一个连接配置文件。例如，在本地目录中创建包含以下内容的bond0.nmconnection文件

[connection]
id=bond0
type=bond
interface-name=bond0
multi-connect=1

[bond]
miimon=100
mode=active-backup

[ipv4]
method=auto

[ipv6]
method=auto

创建一个连接配置文件，用于添加到绑定的辅助接口。例如，在本地目录中创建包含以下内容的bond0-proxy-em1.nmconnection文件
```
[connection]
id=em1
type=ethernet
interface-name=em1
master=bond0
multi-connect=1
slave-type=bond
```
创建一个连接配置文件，用于添加到绑定的辅助接口。例如，在本地目录中创建包含以下内容的bond0-proxy-em2.nmconnection文件
```
[connection]
id=em2
type=ethernet
interface-name=em2
master=bond0
multi-connect=1
slave-type=bond
```

从RHCOS镜像站点下载RHCOS ISO镜像，并运行以下命令使用您已配置的网络自定义ISO镜像

$ coreos-installer iso customize rhcos-<version>-live.x86_64.iso \
    --network-keyfile bond0.nmconnection \
    --network-keyfile bond0-proxy-em1.nmconnection \
    --network-keyfile bond0-proxy-em2.nmconnection

网络设置将应用于实时系统，并延续到目标系统。

为iSCSI启动设备自定义实时安装ISO镜像

您可以设置iSCSI目标和启动器值，以便使用自定义版本的实时RHCOS镜像进行自动挂载、启动和配置。

先决条件

您有一个要安装RHCOS的iSCSI目标。

步骤

从coreos-installer镜像页面下载coreos-installer二进制文件。

从RHCOS镜像站点下载RHCOS ISO镜像，并运行以下命令使用以下信息自定义ISO镜像

$ coreos-installer iso customize \
    --pre-install mount-iscsi.sh \ (1)
    --post-install unmount-iscsi.sh \ (2)
    --dest-device /dev/disk/by-path/<IP_address>:<port>-iscsi-<target_iqn>-lun-<lun> \ (3)
    --dest-ignition config.ign \ (4)
    --dest-karg-append rd.iscsi.initiator=<initiator_iqn> \ (5)
    --dest-karg-append netroot=<target_iqn> \ (6)
    -o custom.iso rhcos-<version>-live.x86_64.iso

1	安装前运行的脚本。它应包含用于挂载iSCSI目标的`iscsiadm`命令以及任何启用多路径的命令。
2	安装后运行的脚本。它应包含命令`iscsiadm --mode node --logout=all`。
3	目标系统的位置。您必须提供目标端口的IP地址、关联的端口号、IQN格式的目标iSCSI节点和iSCSI逻辑单元号(LUN)。
4	目标系统的Ignition配置。
5	iSCSI启动器（或客户端）的IQN格式名称。启动器形成一个会话以连接到iSCSI目标。
6	iSCSI目标（或服务器）的IQN格式名称。

有关dracut支持的iSCSI选项的更多信息，请参见dracut.cmdline手册页。

使用iBFT为iSCSI启动设备自定义实时安装ISO镜像

您可以设置iSCSI目标和启动器值，以便使用自定义版本的实时RHCOS镜像进行自动挂载、启动和配置。

先决条件

您有一个要安装RHCOS的iSCSI目标。
可选：您已为iSCSI目标配置多路径。

步骤

从coreos-installer镜像页面下载coreos-installer二进制文件。

从RHCOS镜像站点下载RHCOS ISO镜像，并运行以下命令使用以下信息自定义ISO镜像

$ coreos-installer iso customize \
    --pre-install mount-iscsi.sh \ (1)
    --post-install unmount-iscsi.sh \ (2)
    --dest-device /dev/mapper/mpatha \ (3)
    --dest-ignition config.ign \ (4)
    --dest-karg-append rd.iscsi.firmware=1 \ (5)
    --dest-karg-append rd.multipath=default \ (6)
    -o custom.iso rhcos-<version>-live.x86_64.iso

1	安装前运行的脚本。它应包含用于挂载iSCSI目标的`iscsiadm`命令以及任何启用多路径的命令。
2	安装后运行的脚本。它应包含命令`iscsiadm --mode node --logout=all`。
3	设备的路径。如果您使用多路径，则为多路径设备`/dev/mapper/mpatha`，如果连接了多个多路径设备，或者为了明确起见，您可以使用`/dev/disk/by-path`中可用的世界范围名称(WWN)符号链接。
4	目标系统的Ignition配置。
5	iSCSI参数从BIOS固件读取。
6	可选：如果您正在启用多路径，请包含此参数。

有关dracut支持的iSCSI选项的更多信息，请参见dracut.cmdline手册页。

自定义实时RHCOS PXE环境

您可以使用coreos-installer pxe customize子命令直接自定义实时RHCOS PXE环境。启动PXE环境时，自定义设置会自动应用。

您可以使用此功能配置PXE环境以自动安装RHCOS。

步骤

从coreos-installer镜像页面下载coreos-installer二进制文件。

从RHCOS镜像站点检索RHCOS的kernel、initramfs和rootfs文件以及Ignition配置文件，然后运行以下命令创建一个包含Ignition配置自定义内容的新initramfs文件

$ coreos-installer pxe customize rhcos-<version>-live-initramfs.x86_64.img \
    --dest-ignition bootstrap.ign \ (1)
    --dest-device /dev/disk/by-id/scsi-<serial_number> \ (2)
    -o rhcos-<version>-custom-initramfs.x86_64.img (3)

1	从`openshift-installer`生成的Ignition配置文件。
2	指定此选项时，PXE环境会自动运行安装程序。否则，映像将保持已配置为安装的状态，但除非您指定`coreos.inst.install_dev`内核参数，否则不会自动执行安装。
3	在您的PXE配置中使用自定义的`initramfs`文件。如果不存在，请添加`ignition.firstboot`和`ignition.platform.id=metal`内核参数。

应用您的自定义内容会影响RHCOS的后续每次启动。

修改实时安装PXE环境以启用串行控制台

步骤

从coreos-installer镜像页面下载coreos-installer二进制文件。

从RHCOS镜像站点检索RHCOS的kernel、initramfs和rootfs文件以及Ignition配置文件，然后运行以下命令创建一个新的自定义initramfs文件，以启用串行控制台接收输出

$ coreos-installer pxe customize rhcos-<version>-live-initramfs.x86_64.img \
  --dest-ignition <path> \(1)
  --dest-console tty0 \(2)
  --dest-console ttyS0,<options> \(3)
  --dest-device /dev/disk/by-id/scsi-<serial_number> \(4)
  -o rhcos-<version>-custom-initramfs.x86_64.img (5)

1	要安装的Ignition配置文件的位置。
2	所需的次要控制台。在本例中为图形控制台。省略此选项将禁用图形控制台。
3	所需的 primary 控制台。在本例中为串行控制台。`options`字段定义波特率和其他设置。此字段的常用值为`115200n8`。如果未提供选项，则使用默认内核值`9600n8`。有关此选项格式的更多信息，请参阅Linux 内核串行控制台文档。
4	指定的安装磁盘。如果您省略此选项，PXE环境会自动运行安装程序，除非您还指定了`coreos.inst.install_dev`内核参数，否则安装程序将失败。
5	在您的PXE配置中使用自定义的`initramfs`文件。如果不存在，请添加`ignition.firstboot`和`ignition.platform.id=metal`内核参数。

您的自定义设置已应用，并将影响PXE环境的每次后续启动。

修改实时安装PXE环境以使用自定义证书颁发机构

您可以使用customize子命令的--ignition-ca标志向Ignition提供证书颁发机构(CA)证书。您可以在安装引导期间和配置已安装的系统时使用CA证书。

自定义CA证书会影响Ignition获取远程资源的方式，但不会影响安装到系统上的证书。

步骤

从coreos-installer镜像页面下载coreos-installer二进制文件。

从RHCOS镜像站点检索RHCOS的kernel、initramfs和rootfs文件，然后运行以下命令创建一个新的自定义initramfs文件，用于与自定义CA一起使用

$ coreos-installer pxe customize rhcos-<version>-live-initramfs.x86_64.img \
    --ignition-ca cert.pem \
    -o rhcos-<version>-custom-initramfs.x86_64.img

在您的PXE配置中使用自定义的initramfs文件。如果不存在，请添加ignition.firstboot和ignition.platform.id=metal内核参数。

coreos.inst.ignition_url内核参数不适用于--ignition-ca标志。您必须使用--dest-ignition标志为每个集群创建自定义映像。

应用您的自定义CA证书会影响RHCOS的后续每次启动。

使用自定义网络设置修改实时安装PXE环境

您可以将NetworkManager密钥文件嵌入到实时PXE环境中，并使用customize子命令的--network-keyfile标志将其传递到已安装的系统。

步骤

从coreos-installer镜像页面下载coreos-installer二进制文件。

为绑定接口创建一个连接配置文件。例如，在本地目录中创建包含以下内容的bond0.nmconnection文件

[connection]
id=bond0
type=bond
interface-name=bond0
multi-connect=1

[bond]
miimon=100
mode=active-backup

[ipv4]
method=auto

[ipv6]
method=auto

创建一个连接配置文件，用于添加到绑定的辅助接口。例如，在本地目录中创建包含以下内容的bond0-proxy-em1.nmconnection文件
```
[connection]
id=em1
type=ethernet
interface-name=em1
master=bond0
multi-connect=1
slave-type=bond
```
创建一个连接配置文件，用于添加到绑定的辅助接口。例如，在本地目录中创建包含以下内容的bond0-proxy-em2.nmconnection文件
```
[connection]
id=em2
type=ethernet
interface-name=em2
master=bond0
multi-connect=1
slave-type=bond
```

从RHCOS镜像站点检索RHCOS的kernel、initramfs和rootfs文件，然后运行以下命令创建一个包含您已配置网络的新自定义initramfs文件

$ coreos-installer pxe customize rhcos-<version>-live-initramfs.x86_64.img \
    --network-keyfile bond0.nmconnection \
    --network-keyfile bond0-proxy-em1.nmconnection \
    --network-keyfile bond0-proxy-em2.nmconnection \
    -o rhcos-<version>-custom-initramfs.x86_64.img

在您的PXE配置中使用自定义的initramfs文件。如果不存在，请添加ignition.firstboot和ignition.platform.id=metal内核参数。

网络设置将应用于实时系统，并延续到目标系统。

为iSCSI启动设备自定义实时安装PXE环境

您可以设置iSCSI目标和启动器值，以便使用自定义版本的实时RHCOS镜像进行自动挂载、启动和配置。

先决条件

您有一个要安装RHCOS的iSCSI目标。

步骤

从coreos-installer镜像页面下载coreos-installer二进制文件。

从RHCOS镜像站点检索RHCOS的kernel、initramfs和rootfs文件，然后运行以下命令创建一个包含以下信息的新自定义initramfs文件

$ coreos-installer pxe customize \
    --pre-install mount-iscsi.sh \ (1)
    --post-install unmount-iscsi.sh \ (2)
    --dest-device /dev/disk/by-path/<IP_address>:<port>-iscsi-<target_iqn>-lun-<lun> \ (3)
    --dest-ignition config.ign \ (4)
    --dest-karg-append rd.iscsi.initiator=<initiator_iqn> \ (5)
    --dest-karg-append netroot=<target_iqn> \ (6)
    -o custom.img rhcos-<version>-live-initramfs.x86_64.img

1	安装前运行的脚本。它应包含用于挂载iSCSI目标的`iscsiadm`命令以及任何启用多路径的命令。
2	安装后运行的脚本。它应包含命令`iscsiadm --mode node --logout=all`。
3	目标系统的位置。您必须提供目标端口的IP地址、关联的端口号、IQN格式的目标iSCSI节点和iSCSI逻辑单元号(LUN)。
4	目标系统的Ignition配置。
5	iSCSI启动器（或客户端）的IQN格式名称。启动器形成一个会话以连接到iSCSI目标。
6	iSCSI目标（或服务器）的IQN格式名称。

有关dracut支持的iSCSI选项的更多信息，请参见dracut.cmdline手册页。

使用iBFT为iSCSI启动设备自定义实时安装PXE环境

您可以设置iSCSI目标和启动器值，以便使用自定义版本的实时RHCOS镜像进行自动挂载、启动和配置。

先决条件

您有一个要安装RHCOS的iSCSI目标。
可选：您已为iSCSI目标配置多路径。

步骤

从coreos-installer镜像页面下载coreos-installer二进制文件。

从RHCOS镜像站点检索RHCOS的kernel、initramfs和rootfs文件，然后运行以下命令创建一个包含以下信息的新自定义initramfs文件

$ coreos-installer pxe customize \
    --pre-install mount-iscsi.sh \ (1)
    --post-install unmount-iscsi.sh \ (2)
    --dest-device /dev/mapper/mpatha \ (3)
    --dest-ignition config.ign \ (4)
    --dest-karg-append rd.iscsi.firmware=1 \ (5)
    --dest-karg-append rd.multipath=default \ (6)
    -o custom.img rhcos-<version>-live-initramfs.x86_64.img

1	安装前运行的脚本。它应包含用于挂载iSCSI目标的`iscsiadm`命令。
2	安装后运行的脚本。它应包含命令`iscsiadm --mode node --logout=all`。
3	设备的路径。如果您使用多路径，则为多路径设备`/dev/mapper/mpatha`，如果连接了多个多路径设备，或者为了明确起见，您可以使用`/dev/disk/by-path`中可用的世界范围名称(WWN)符号链接。
4	目标系统的Ignition配置。
5	iSCSI参数从BIOS固件读取。
6	可选：如果您正在启用多路径，请包含此参数。

有关dracut支持的iSCSI选项的更多信息，请参见dracut.cmdline手册页。

高级RHCOS安装参考

本节说明网络配置和其他高级选项，这些选项允许您修改Red Hat Enterprise Linux CoreOS (RHCOS)手动安装过程。下表描述了您可以与RHCOS实时安装程序和coreos-installer命令一起使用的内核参数和命令行选项。

ISO安装的网络和绑定选项

如果从 ISO 镜像安装 RHCOS，您可以在引导镜像时手动添加内核参数来配置节点的网络。如果没有指定网络参数，则当 RHCOS 检测到需要网络来获取 Ignition 配置文件时，initramfs 中会激活 DHCP。

手动添加网络参数时，还必须添加rd.neednet=1内核参数才能在 initramfs 中启动网络。

以下信息提供了一些示例，用于为 ISO 安装的 RHCOS 节点配置网络和绑定。这些示例描述了如何使用ip=、nameserver=和bond=内核参数。

添加内核参数时，顺序很重要：ip=、nameserver=，然后是bond=。

网络选项在系统启动期间传递给dracut工具。有关dracut支持的网络选项的更多信息，请参阅dracut.cmdline 手册页。

以下示例是 ISO 安装的网络选项。

配置 DHCP 或静态 IP 地址

要配置 IP 地址，可以使用 DHCP（ip=dhcp）或设置单个静态 IP 地址（ip=<host_ip>）。如果设置静态 IP，则必须在每个节点上标识 DNS 服务器 IP 地址（nameserver=<dns_ip>）。以下示例设置：

节点的 IP 地址为10.10.10.2
网关地址为10.10.10.254
子网掩码为255.255.255.0
主机名为core0.example.com
DNS 服务器地址为4.4.4.41
自动配置值为none。静态配置 IP 网络时不需要自动配置。

ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp1s0:none
nameserver=4.4.4.41

当您使用 DHCP 为 RHCOS 机器配置 IP 地址时，这些机器也会通过 DHCP 获取 DNS 服务器信息。对于基于 DHCP 的部署，您可以通过 DHCP 服务器配置定义 RHCOS 节点使用的 DNS 服务器地址。

配置不带静态主机名的 IP 地址

您可以配置 IP 地址而不分配静态主机名。如果用户未设置静态主机名，它将被获取并通过反向 DNS 查找自动设置。要配置不带静态主机名的 IP 地址，请参考以下示例

节点的 IP 地址为10.10.10.2
网关地址为10.10.10.254
子网掩码为255.255.255.0
DNS 服务器地址为4.4.4.41
自动配置值为none。静态配置 IP 网络时不需要自动配置。

ip=10.10.10.2::10.10.10.254:255.255.255.0::enp1s0:none
nameserver=4.4.4.41

指定多个网络接口

您可以通过设置多个ip=条目来指定多个网络接口。

ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp1s0:none
ip=10.10.10.3::10.10.10.254:255.255.255.0:core0.example.com:enp2s0:none

配置默认网关和路由

可选：您可以通过设置rd.route=值来配置其他网络的路由。

当您配置一个或多个网络时，需要一个默认网关。如果附加网络网关与主网络网关不同，则默认网关必须是主网络网关。

运行以下命令配置默认网关
```
ip=::10.10.10.254::::
```
输入以下命令配置附加网络的路由
```
rd.route=20.20.20.0/24:20.20.20.254:enp2s0
```

禁用单个接口上的 DHCP

您可以禁用单个接口上的 DHCP，例如当有两个或多个网络接口并且只有一个接口正在使用时。在此示例中，enp1s0接口具有静态网络配置，并且禁用了enp2s0（未使用的）接口的 DHCP

ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp1s0:none
ip=::::core0.example.com:enp2s0:none

组合 DHCP 和静态 IP 配置

您可以在具有多个网络接口的系统上组合 DHCP 和静态 IP 配置，例如

ip=enp1s0:dhcp
ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp2s0:none

配置单个接口上的 VLAN

可选：您可以使用vlan=参数配置单个接口上的 VLAN。

要在网络接口上配置 VLAN 并使用静态 IP 地址，请运行以下命令

ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp2s0.100:none
vlan=enp2s0.100:enp2s0

要在网络接口上配置 VLAN 并使用 DHCP，请运行以下命令
```
ip=enp2s0.100:dhcp
vlan=enp2s0.100:enp2s0
```

提供多个 DNS 服务器

您可以通过为每个服务器添加nameserver=条目来提供多个 DNS 服务器，例如

nameserver=1.1.1.1
nameserver=8.8.8.8

将多个网络接口绑定到单个接口

可选：您可以使用bond=选项将多个网络接口绑定到单个接口。请参考以下示例

配置绑定接口的语法为：bond=<name>[:<network_interfaces>][:options]

<name>是绑定设备名称（bond0），<network_interfaces>表示物理（以太网）接口的逗号分隔列表（em1,em2），而options是绑定选项的逗号分隔列表。输入modinfo bonding查看可用选项。
当您使用bond=创建绑定接口时，必须指定 IP 地址的分配方式以及绑定接口的其他信息。
- 要将绑定接口配置为使用 DHCP，请将绑定的 IP 地址设置为dhcp。例如
  bond=bond0:em1,em2:mode=active-backup ip=bond0:dhcp
- 要将绑定接口配置为使用静态 IP 地址，请输入所需的特定 IP 地址和相关信息。例如
  bond=bond0:em1,em2:mode=active-backup ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:bond0:none

将多个 SR-IOV 网络接口绑定到双端口 NIC 接口

可选：您可以使用bond=选项将多个 SR-IOV 网络接口绑定到双端口 NIC 接口。

在每个节点上，您必须执行以下任务

按照管理 SR-IOV 设备中的指导创建 SR-IOV 虚拟功能 (VF)。请遵循“将 SR-IOV 网络设备附加到虚拟机”部分中的步骤。
按照配置网络绑定中的指导创建绑定，将所需的 VF 附加到绑定并设置绑定的链路状态。遵循所述的任何步骤来创建绑定。

以下示例说明了您必须使用的语法

配置绑定接口的语法为bond=<name>[:<network_interfaces>][:options]。

<name>是绑定设备名称（bond0），<network_interfaces>表示内核中已知的虚拟功能 (VF) 名称，并在ip link命令的输出中显示 (eno1f0、eno2f0)，而options是绑定选项的逗号分隔列表。输入modinfo bonding查看可用选项。
当您使用bond=创建绑定接口时，必须指定 IP 地址的分配方式以及绑定接口的其他信息。
- 要将绑定接口配置为使用 DHCP，请将绑定的 IP 地址设置为dhcp。例如
  bond=bond0:eno1f0,eno2f0:mode=active-backup ip=bond0:dhcp
- 要将绑定接口配置为使用静态 IP 地址，请输入所需的特定 IP 地址和相关信息。例如
  bond=bond0:eno1f0,eno2f0:mode=active-backup ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:bond0:none

使用网络团队

可选：您可以使用team=参数使用网络团队作为绑定的替代方案

配置团队接口的语法为：team=name[:network_interfaces]

name是团队设备名称（team0），而network_interfaces表示物理（以太网）接口的逗号分隔列表（em1, em2）。

当 RHCOS 切换到即将发布的 RHEL 版本时，团队功能计划被弃用。有关更多信息，请参阅此Red Hat 知识库文章。

使用以下示例配置网络团队

team=team0:em1,em2
ip=team0:dhcp

ISO 和 PXE 安装的`coreos-installer`选项

从 ISO 镜像引导进入 RHCOS 实时环境后，您可以在命令提示符下运行coreos-installer install <options> <device>来安装 RHCOS。

下表显示了您可以传递给coreos-installer命令的子命令、选项和参数。

coreos-installer install 子命令

子命令

描述

$ coreos-installer install <options> <device>

将 Ignition 配置嵌入 ISO 镜像中。

coreos-installer install 子命令选项

选项

描述

-u, --image-url <url>

手动指定镜像 URL。

-f, --image-file <path>

手动指定本地镜像文件。用于调试。

-i, --ignition-file <path>

从文件中嵌入 Ignition 配置。

-I, --ignition-url <URL>

从 URL 嵌入 Ignition 配置。

--ignition-hash <digest>

Ignition 配置的 `type-value`摘要。

-p, --platform <name>

覆盖已安装系统的 Ignition 平台 ID。

--console <spec>

设置已安装系统的内核和引导加载程序控制台。有关<spec> 格式的更多信息，请参阅Linux 内核串口控制台文档。

--append-karg <arg>…

向已安装系统追加默认内核参数。

--delete-karg <arg>…

从已安装系统删除默认内核参数。

-n, --copy-network

从安装环境复制网络配置。

--copy-network选项仅复制在/etc/NetworkManager/system-connections下找到的网络配置。特别是，它不会复制系统主机名。

--network-dir <path>

与-n一起使用。默认为/etc/NetworkManager/system-connections/。

--save-partlabel <lx>..

保存具有此标签通配符的分区。

--save-partindex <id>…

保存具有此编号或范围的分区。

--insecure

跳过 RHCOS 镜像签名验证。

--insecure-ignition

允许没有 HTTPS 或哈希值的 Ignition URL。

--architecture <name>

目标 CPU 架构。有效值为x86_64 和 aarch64。

--preserve-on-error

错误时不清除分区表。

-h, --help

打印帮助信息。

coreos-installer install 子命令参数

参数

描述

<device>

目标设备。

coreos-installer ISO 子命令

子命令

描述

$ coreos-installer iso customize <options> <ISO_image>

自定义 RHCOS 实时 ISO 镜像。

coreos-installer iso reset <options> <ISO_image>

将 RHCOS 实时 ISO 镜像恢复到默认设置。

coreos-installer iso ignition remove <options> <ISO_image>

从 ISO 镜像中删除嵌入的 Ignition 配置。

coreos-installer ISO customize 子命令选项

选项

描述

--dest-ignition <path>

将指定的 Ignition 配置文件合并到目标系统的新配置片段中。

--dest-console <spec>

指定目标系统的内核和引导加载程序控制台。

--dest-device <path>

安装并覆盖指定的目标设备。

--dest-karg-append <arg>

向目标系统的每次启动添加内核参数。

--dest-karg-delete <arg>

从目标系统的每次启动中删除内核参数。

--network-keyfile <path>

使用指定的 NetworkManager 密钥文件为实时和目标系统配置网络。

--ignition-ca <path>

指定 Ignition 需要信任的其他 TLS 证书颁发机构。

--pre-install <path>

在安装前运行指定的脚本。

--post-install <path>

在安装后运行指定的脚本。

--installer-config <path>

应用指定的安装程序配置文件。

--live-ignition <path>

将指定的 Ignition 配置文件合并到实时环境的新配置片段中。

--live-karg-append <arg>

向实时环境的每次启动添加内核参数。

--live-karg-delete <arg>

从实时环境的每次启动中删除内核参数。

--live-karg-replace <k=o=n>

替换实时环境每次启动中的内核参数，格式为key=old=new。

-f, --force

覆盖现有的 Ignition 配置。

-o, --output <path>

将 ISO 写入新的输出文件。

-h, --help

打印帮助信息。

coreos-installer PXE 子命令

子命令

描述

请注意，并非所有这些选项都被所有子命令接受。

coreos-installer pxe customize <options> <path>

自定义 RHCOS 实时 PXE 启动配置。

coreos-installer pxe ignition wrap <options>

将 Ignition 配置包装到镜像中。

coreos-installer pxe ignition unwrap <options> <image_name>

显示镜像中包装的 Ignition 配置。

coreos-installer PXE customize 子命令选项

选项

描述

请注意，并非所有这些选项都被所有子命令接受。

--dest-ignition <path>

将指定的 Ignition 配置文件合并到目标系统的新配置片段中。

--dest-console <spec>

指定目标系统的内核和引导加载程序控制台。

--dest-device <path>

安装并覆盖指定的目标设备。

--network-keyfile <path>

使用指定的 NetworkManager 密钥文件为实时和目标系统配置网络。

--ignition-ca <path>

指定 Ignition 需要信任的其他 TLS 证书颁发机构。

--pre-install <path>

在安装前运行指定的脚本。

post-install <path>

在安装后运行指定的脚本。

--installer-config <path>

应用指定的安装程序配置文件。

--live-ignition <path>

将指定的 Ignition 配置文件合并到实时环境的新配置片段中。

-o, --output <path>

将 initramfs 写入新的输出文件。

此选项对于 PXE 环境是必需的。

-h, --help

打印帮助信息。

ISO 或 PXE 安装的`coreos.inst` 引导选项

您可以通过将coreos.inst 引导参数传递给 RHCOS 实时安装程序，在启动时自动调用coreos-installer 选项。这些参数是除了标准引导参数之外提供的。

对于 ISO 安装，可以通过在引导加载程序菜单中中断自动引导来添加coreos.inst 选项。当 **RHEL CoreOS (Live)** 菜单选项高亮显示时，您可以按TAB键中断自动引导。
对于 PXE 或 iPXE 安装，必须在启动 RHCOS 实时安装程序之前将coreos.inst 选项添加到APPEND 行。

下表显示了 ISO 和 PXE 安装的 RHCOS 实时安装程序coreos.inst 引导选项。

表 10. `coreos.inst` 引导选项
参数	描述
`coreos.inst.install_dev`	必需。系统上要安装到的块设备。建议使用完整路径，例如`/dev/sda`，尽管允许使用`sda`。
`coreos.inst.ignition_url`	可选：要嵌入到已安装系统中的 Ignition 配置的 URL。如果未指定 URL，则不嵌入 Ignition 配置。仅支持 HTTP 和 HTTPS 协议。
`coreos.inst.save_partlabel`	可选：要在安装过程中保留的分区的逗号分隔标签。允许使用 glob 样式通配符。指定的分区不需要存在。
`coreos.inst.save_partindex`	可选：要在安装过程中保留的分区的逗号分隔索引。允许使用范围`m-n`，并且可以省略`m` 或`n`。指定的分区不需要存在。
`coreos.inst.insecure`	可选：允许`coreos.inst.image_url` 指定的操作系统镜像未签名。
`coreos.inst.image_url`	可选：下载并安装指定 RHCOS 镜像。此参数不应在生产环境中使用，仅用于调试目的。虽然此参数可用于安装与实时介质不匹配的 RHCOS 版本，但建议您改用与要安装的版本匹配的介质。如果您使用`coreos.inst.image_url`，则还必须使用`coreos.inst.insecure`。这是因为用于 OpenShift Container Platform 的裸机介质未进行 GPG 签名。仅支持 HTTP 和 HTTPS 协议。
`coreos.inst.skip_reboot`	可选：安装后系统不会重启。安装完成后，您将收到一个提示，允许您检查安装过程中发生的情况。此参数不应在生产环境中使用，仅用于调试目的。
`coreos.inst.platform_id`	可选：正在安装 RHCOS 镜像的平台的 Ignition 平台 ID。默认值为 `metal`。此选项决定是否向云提供商（例如 VMware）请求 Ignition 配置。例如：`coreos.inst.platform_id=vmware`。
`ignition.config.url`	可选：实时启动的 Ignition 配置的 URL。例如，这可以用来自定义 `coreos-installer` 的调用方式，或在安装之前或之后运行代码。这与 `coreos.inst.ignition_url` 不同，后者是已安装系统的 Ignition 配置。

在 RHCOS 上使用内核参数启用多路径

RHCOS 支持在主磁盘上启用多路径，从而增强对硬件故障的弹性，以实现更高的主机可用性。

您可以为在 OpenShift Container Platform 4.8 或更高版本中预配的节点在安装时启用多路径。虽然可以通过机器配置激活多路径来实现安装后的支持，但建议在安装期间启用多路径。

在任何对非优化路径的 I/O 都会导致 I/O 系统错误的设置中，必须在安装时启用多路径。

在 IBM Z® 和 IBM® LinuxONE 上，只有在安装期间为其配置了集群时，才能启用多路径。有关更多信息，请参阅《在 IBM Z® 和 IBM® LinuxONE 上使用 z/VM 安装集群》中的“安装 RHCOS 并启动 OpenShift Container Platform 引导程序”。

以下过程在安装时启用多路径并将内核参数添加到 coreos-installer install 命令中，以便已安装的系统本身从第一次启动开始使用多路径。

OpenShift Container Platform 不支持在已从 4.6 或更早版本升级的节点上将多路径启用作为第 2 天活动。

先决条件

您已为集群创建了 Ignition 配置文件。
您已查看《安装 RHCOS 并启动 OpenShift Container Platform 引导程序》。

步骤

要启用多路径并启动 multipathd 守护程序，请在安装主机上运行以下命令：
```
$ mpathconf --enable && systemctl start multipathd.service
```
- 可选：如果启动 PXE 或 ISO，则可以从内核命令行添加 rd.multipath=default 来启用多路径。
通过调用 coreos-installer 程序添加内核参数：
- 如果只有一台多路径设备连接到机器，则它应该在路径 /dev/mapper/mpatha 中可用。例如：
  $ coreos-installer install /dev/mapper/mpatha \(1) --ignition-url=http://host/worker.ign \ --append-karg rd.multipath=default \ --append-karg root=/dev/disk/by-label/dm-mpath-root \ --append-karg rw
  1 指示单个多路径设备的路径。
- 如果有多个多路径设备连接到机器，或者为了更明确起见，建议使用 /dev/disk/by-id 中可用的全球唯一名称 (WWN) 符号链接，而不是使用 /dev/mapper/mpatha。例如：
  $ coreos-installer install /dev/disk/by-id/wwn-<wwn_ID> \(1) --ignition-url=http://host/worker.ign \ --append-karg rd.multipath=default \ --append-karg root=/dev/disk/by-label/dm-mpath-root \ --append-karg rw
  1 指示目标多路径设备的 WWN ID。例如，0xx194e957fcedb4841。
  
  使用特殊的 coreos.inst.* 参数引导实时安装程序时，此符号链接也可以用作 coreos.inst.install_dev 内核参数。有关更多信息，请参阅“安装 RHCOS 并启动 OpenShift Container Platform 引导程序”。
重新启动到已安装的系统。

通过转到某个工作节点并列出内核命令行参数（主机上的 /proc/cmdline）来检查内核参数是否有效。

$ oc debug node/ip-10-0-141-105.ec2.internal

示例输出

Starting pod/ip-10-0-141-105ec2internal-debug ...
To use host binaries, run `chroot /host`

sh-4.2# cat /host/proc/cmdline
...
rd.multipath=default root=/dev/disk/by-label/dm-mpath-root
...

sh-4.2# exit

您应该会看到添加的内核参数。

启用辅助磁盘上的多路径

RHCOS 还支持在辅助磁盘上启用多路径。您不需要使用内核参数，而是使用 Ignition 在安装时为辅助磁盘启用多路径。

先决条件

您已阅读《磁盘分区》部分。
您已阅读《在 RHCOS 上使用内核参数启用多路径》部分。
您已安装 Butane 实用程序。

步骤

创建一个包含以下信息的 Butane 配置：

示例 multipath-config.bu

variant: openshift
version: 4.17.0
systemd:
  units:
    - name: mpath-configure.service
      enabled: true
      contents: |
        [Unit]
        Description=Configure Multipath on Secondary Disk
        ConditionFirstBoot=true
        ConditionPathExists=!/etc/multipath.conf
        Before=multipathd.service (1)
        DefaultDependencies=no

        [Service]
        Type=oneshot
        ExecStart=/usr/sbin/mpathconf --enable (2)

        [Install]
        WantedBy=multi-user.target
    - name: mpath-var-lib-container.service
      enabled: true
      contents: |
        [Unit]
        Description=Set Up Multipath On /var/lib/containers
        ConditionFirstBoot=true (3)
        Requires=dev-mapper-mpatha.device
        After=dev-mapper-mpatha.device
        After=ostree-remount.service
        Before=kubelet.service
        DefaultDependencies=no

        [Service] (4)
        Type=oneshot
        ExecStart=/usr/sbin/mkfs.xfs -L containers -m reflink=1 /dev/mapper/mpatha
        ExecStart=/usr/bin/mkdir -p /var/lib/containers

        [Install]
        WantedBy=multi-user.target
    - name: var-lib-containers.mount
      enabled: true
      contents: |
        [Unit]
        Description=Mount /var/lib/containers
        After=mpath-var-lib-containers.service
        Before=kubelet.service (5)

        [Mount] (6)
        What=/dev/disk/by-label/dm-mpath-containers
        Where=/var/lib/containers
        Type=xfs

        [Install]
        WantedBy=multi-user.target

1	必须在启动多路径守护程序之前设置配置。
2	启动 `mpathconf` 实用程序。
3	此字段必须设置为 `true`。
4	创建文件系统和目录 `/var/lib/containers`。
5	必须在启动任何节点之前挂载设备。
6	将设备挂载到 `/var/lib/containers` 挂载点。此位置不能是符号链接。

通过运行以下命令创建 Ignition 配置：

$ butane --pretty --strict multipath-config.bu > multipath-config.ign

继续进行其余的第一次启动 RHCOS 安装过程。

除非主磁盘也是多路径的，否则不要在安装期间在命令行上添加 rd.multipath 或 root 内核参数。

在 iSCSI 引导设备上手动安装 RHCOS

您可以在 iSCSI 目标上手动安装 RHCOS。

先决条件

您处于 RHCOS 实时环境中。
您有一个要安装 RHCOS 的 iSCSI 目标。

步骤

通过运行以下命令从实时环境挂载 iSCSI 目标：

$ iscsiadm \
    --mode discovery \
    --type sendtargets
    --portal <IP_address> \ (1)
    --login

1	目标门户的 IP 地址。

通过运行以下命令并将必要的内核参数安装到 iSCSI 目标上，例如：

$ coreos-installer install \
    /dev/disk/by-path/ip-<IP_address>:<port>-iscsi-<target_iqn>-lun-<lun> \ (1)
    --append-karg rd.iscsi.initiator=<initiator_iqn> \ (2)
    --append.karg netroot=<target_iqn> \ (3)
    --console ttyS0,115200n8
    --ignition-file <path_to_file>

1	您正在安装到的位置。您必须提供目标门户的 IP 地址、关联的端口号、IQN 格式的 iSCSI 目标节点和 iSCSI 逻辑单元号 (LUN)。
2	iSCSI启动器（或客户端）的IQN格式名称。启动器形成一个会话以连接到iSCSI目标。
3	iSCSI目标（或服务器）的IQN格式名称。

有关dracut支持的iSCSI选项的更多信息，请参见dracut.cmdline手册页。

使用以下命令卸载 iSCSI 磁盘：
```
$ iscsiadm --mode node --logoutall=all
```

此过程也可以使用 coreos-installer iso customize 或 coreos-installer pxe customize 子命令执行。

使用 iBFT 在 iSCSI 引导设备上安装 RHCOS

在完全无盘机器上，可以通过 iBFT 传递 iSCSI 目标和启动器值。也支持 iSCSI 多路径。

先决条件

您处于 RHCOS 实时环境中。
您有一个要安装RHCOS的iSCSI目标。
可选：您已为iSCSI目标配置多路径。

步骤

通过运行以下命令从实时环境挂载 iSCSI 目标：

$ iscsiadm \
    --mode discovery \
    --type sendtargets
    --portal <IP_address> \ (1)
    --login

1	目标门户的 IP 地址。

可选：使用以下命令启用多路径并启动守护程序：
```
$ mpathconf --enable && systemctl start multipathd.service
```

通过运行以下命令并将必要的内核参数安装到 iSCSI 目标上，例如：

$ coreos-installer install \
    /dev/mapper/mpatha \ (1)
    --append-karg rd.iscsi.firmware=1 \ (2)
    --append-karg rd.multipath=default \ (3)
    --console ttyS0 \
    --ignition-file <path_to_file>

1	单个多路径设备的路径。如果连接了多个多路径设备，或者为了更明确起见，您可以使用 `/dev/disk/by-path` 中可用的全球唯一名称 (WWN) 符号链接。
2	iSCSI参数从BIOS固件读取。
3	可选：如果您正在启用多路径，请包含此参数。

有关dracut支持的iSCSI选项的更多信息，请参见dracut.cmdline手册页。

卸载 iSCSI 磁盘
```
$ iscsiadm --mode node --logout=all
```

此过程也可以使用 coreos-installer iso customize 或 coreos-installer pxe customize 子命令执行。

等待引导过程完成

集群节点第一次启动到已安装到磁盘的持久性 RHCOS 环境后，OpenShift Container Platform 引导过程将开始。通过 Ignition 配置文件提供的配置信息用于初始化引导过程并在机器上安装 OpenShift Container Platform。您必须等待引导过程完成。

先决条件

您已为集群创建了 Ignition 配置文件。
您已配置合适的网络、DNS 和负载均衡基础架构。
您已获得安装程序并为您的集群生成了 Ignition 配置文件。
您已在集群机器上安装 RHCOS 并提供了 OpenShift Container Platform 安装程序生成的 Ignition 配置文件。

步骤

监控引导过程

$ ./openshift-install --dir <installation_directory> wait-for bootstrap-complete \ (1)
    --log-level=info (2)

1	对于`<installation_directory>`，请指定您存储安装文件的目录路径。
2	要查看不同的安装详细信息，请指定`warn`、`debug`或`error`，而不是`info`。

示例输出

INFO Waiting up to 30m0s for the Kubernetes API at https://api.test.example.com:6443...
INFO API v1.30.3 up
INFO Waiting up to 30m0s for bootstrapping to complete...
INFO It is now safe to remove the bootstrap resources

当 Kubernetes API 服务器发出信号表示它已在控制平面机器上引导时，命令即告成功。

引导过程完成后，请从负载均衡器中移除引导机器。

此时必须从负载均衡器中移除引导机器。您也可以移除或重新格式化引导机器本身。

其他资源

有关监视安装日志以及在出现安装问题时检索诊断数据的更多信息，请参阅监视安装进度。

使用 CLI 登录集群

您可以通过导出集群kubeconfig文件以默认系统用户身份登录到您的集群。kubeconfig文件包含集群信息，CLI 使用这些信息将客户端连接到正确的集群和 API 服务器。该文件特定于一个集群，并在 OpenShift Container Platform 安装期间创建。

先决条件

您已部署 OpenShift Container Platform 集群。
您已安装oc CLI。

步骤

导出kubeadmin凭据
```
$ export KUBECONFIG=<installation_directory>/auth/kubeconfig (1)
```
1 对于<installation_directory>，请指定您存储安装文件的目录路径。
验证您可以使用导出的配置成功运行oc命令
```
$ oc whoami
```
示例输出
```
system:admin
```

批准您机器的证书签名请求

将机器添加到集群时，会为每个添加的机器生成两个待处理的证书签名请求 (CSR)。您必须确认这些 CSR 已获批准，或者如有必要，自行批准它们。必须先批准客户端请求，然后才能批准服务器请求。

先决条件

您已将机器添加到集群。

步骤

确认集群已识别这些机器
```
$ oc get nodes
```
示例输出
```
NAME      STATUS    ROLES   AGE  VERSION
master-0  Ready     master  63m  v1.30.3
master-1  Ready     master  63m  v1.30.3
master-2  Ready     master  64m  v1.30.3
```
输出列出了您创建的所有机器。

在批准一些 CSR 之前，上述输出可能不包含计算节点（也称为工作节点）。

查看待处理的 CSR，并确保您看到为添加到集群的每台机器提供的具有Pending或Approved状态的客户端请求

$ oc get csr

示例输出

NAME        AGE     REQUESTOR                                                                   CONDITION
csr-8b2br   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
csr-8vnps   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
...

在此示例中，两台机器正在加入集群。您可能会在列表中看到更多已批准的 CSR。

如果未批准 CSR，则在您添加的所有机器的待处理 CSR 处于Pending状态后，请批准集群机器的 CSR

由于 CSR 会自动轮换，因此请在将机器添加到集群后一小时内批准您的 CSR。如果您在一小时内未批准它们，证书将轮换，并且每个节点将存在两个以上的证书。您必须批准所有这些证书。批准客户端 CSR 后，Kubelet 会为服务证书创建辅助 CSR，这需要手动批准。然后，如果 Kubelet 请求具有相同参数的新证书，则machine-approver会自动批准后续的服务证书续订请求。

对于在未启用机器 API 的平台（例如裸机和其他用户配置的基础架构）上运行的集群，您必须实现一种自动批准 kubelet 服务证书请求 (CSR) 的方法。如果未批准请求，则oc exec、oc rsh和oc logs命令将无法成功，因为 API 服务器连接到 kubelet 时需要服务证书。任何联系 Kubelet 端点的操作都需要此证书批准到位。该方法必须监视新的 CSR，确认 CSR 是由system:node或system:admin组中的node-bootstrapper服务帐户提交的，并确认节点的身份。

要单独批准它们，请对每个有效的 CSR 运行以下命令
```
$ oc adm certificate approve <csr_name> (1)
```
1 <csr_name>是当前 CSR 列表中 CSR 的名称。

要批准所有待处理的 CSR，请运行以下命令

$ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs --no-run-if-empty oc adm certificate approve

在批准一些 CSR 之前，某些 Operator 可能无法使用。

现在您的客户端请求已获批准，您必须查看为添加到集群的每台机器提供的服务器请求

$ oc get csr

示例输出

NAME        AGE     REQUESTOR                                                                   CONDITION
csr-bfd72   5m26s   system:node:ip-10-0-50-126.us-east-2.compute.internal                       Pending
csr-c57lv   5m26s   system:node:ip-10-0-95-157.us-east-2.compute.internal                       Pending
...

如果剩余的 CSR 未获批准且处于Pending状态，请批准集群机器的 CSR
- 要单独批准它们，请对每个有效的 CSR 运行以下命令
  $ oc adm certificate approve <csr_name> (1)
  1 <csr_name>是当前 CSR 列表中 CSR 的名称。
- 要批准所有待处理的 CSR，请运行以下命令
  $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve

批准所有客户端和服务器 CSR 后，机器将具有Ready状态。通过运行以下命令进行验证

$ oc get nodes

示例输出

NAME      STATUS    ROLES   AGE  VERSION
master-0  Ready     master  73m  v1.30.3
master-1  Ready     master  73m  v1.30.3
master-2  Ready     master  74m  v1.30.3
worker-0  Ready     worker  11m  v1.30.3
worker-1  Ready     worker  11m  v1.30.3

批准服务器 CSR 后，机器可能需要几分钟才能转换为Ready状态。

其他信息

证书签名请求

初始 Operator 配置

控制平面初始化后，您必须立即配置一些 Operator，以便它们全部可用。

先决条件

您的控制平面已初始化。

步骤

观察集群组件上线

$ watch -n5 oc get clusteroperators

示例输出

NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
authentication                             4.17.0    True        False         False      19m
baremetal                                  4.17.0    True        False         False      37m
cloud-credential                           4.17.0    True        False         False      40m
cluster-autoscaler                         4.17.0    True        False         False      37m
config-operator                            4.17.0    True        False         False      38m
console                                    4.17.0    True        False         False      26m
csi-snapshot-controller                    4.17.0    True        False         False      37m
dns                                        4.17.0    True        False         False      37m
etcd                                       4.17.0    True        False         False      36m
image-registry                             4.17.0    True        False         False      31m
ingress                                    4.17.0    True        False         False      30m
insights                                   4.17.0    True        False         False      31m
kube-apiserver                             4.17.0    True        False         False      26m
kube-controller-manager                    4.17.0    True        False         False      36m
kube-scheduler                             4.17.0    True        False         False      36m
kube-storage-version-migrator              4.17.0    True        False         False      37m
machine-api                                4.17.0    True        False         False      29m
machine-approver                           4.17.0    True        False         False      37m
machine-config                             4.17.0    True        False         False      36m
marketplace                                4.17.0    True        False         False      37m
monitoring                                 4.17.0    True        False         False      29m
network                                    4.17.0    True        False         False      38m
node-tuning                                4.17.0    True        False         False      37m
openshift-apiserver                        4.17.0    True        False         False      32m
openshift-controller-manager               4.17.0    True        False         False      30m
openshift-samples                          4.17.0    True        False         False      32m
operator-lifecycle-manager                 4.17.0    True        False         False      37m
operator-lifecycle-manager-catalog         4.17.0    True        False         False      37m
operator-lifecycle-manager-packageserver   4.17.0    True        False         False      32m
service-ca                                 4.17.0    True        False         False      38m
storage                                    4.17.0    True        False         False      37m

配置不可用的 Operator。

其他资源

有关在 OpenShift Container Platform 安装失败时收集数据的详细信息，请参阅从失败的安装中收集日志。
有关检查整个集群中的 Operator Pod 健康状况和收集 Operator 日志以进行诊断的步骤，请参阅排查 Operator 问题。

禁用默认 OperatorHub 目录源

在 OpenShift Container Platform 安装期间，默认情况下会为 OperatorHub 配置从 Red Hat 和社区项目提供的內容进行源代码的 Operator 目录。在受限网络环境中，您必须以集群管理员身份禁用默认目录。

步骤

通过将disableAllDefaultSources: true添加到OperatorHub对象来禁用默认目录的源。

$ oc patch OperatorHub cluster --type json \
    -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'

或者，您可以使用 Web 控制台来管理目录源。在**管理** → **集群设置** → **配置** → **OperatorHub**页面中，单击**源**选项卡，您可以在其中创建、更新、删除、禁用和启用各个源。

镜像注册表存储配置

对于不提供默认存储的平台，镜像注册表 Operator 最初不可用。安装后，您必须配置注册表以使用存储，以便使注册表 Operator 可用。

显示了配置持久卷的说明，这是生产集群所必需的。在适用情况下，将显示有关将空目录配置为存储位置的说明，这仅适用于非生产集群。

提供了其他说明，用于在升级期间使用Recreate滚动策略允许镜像注册表使用块存储类型。

更改镜像注册表的管理状态

要启动镜像注册表，必须将镜像注册表操作符配置的managementState从Removed更改为Managed。

步骤

将managementState镜像注册表操作符配置从Removed更改为Managed。例如

$ oc patch configs.imageregistry.operator.openshift.io cluster --type merge --patch '{"spec":{"managementState":"Managed"}}'

为裸机和其他手动安装配置注册表存储

作为集群管理员，安装后必须配置注册表以使用存储。

先决条件

您可以以具有cluster-admin角色的用户身份访问集群。
您有一个使用手动配置的 Red Hat Enterprise Linux CoreOS (RHCOS) 节点（例如裸机）的集群。

您已为集群配置了持久性存储，例如 Red Hat OpenShift Data Foundation。

当您只有一个副本时，OpenShift Container Platform 支持镜像注册表存储的ReadWriteOnce访问。ReadWriteOnce访问还需要注册表使用Recreate滚动策略。要部署支持高可用性的镜像注册表（具有两个或多个副本），则需要ReadWriteMany访问。

必须具有 100Gi 容量。

步骤

要配置注册表以使用存储，请更改configs.imageregistry/cluster资源中的spec.storage.pvc。

使用共享存储时，请查看安全设置以防止外部访问。

验证您是否没有注册表 pod

$ oc get pod -n openshift-image-registry -l docker-registry=default

示例输出

No resources found in openshift-image-registry namespace

如果您的输出中确实有注册表 pod，则无需继续执行此过程。

检查注册表配置
```
$ oc edit configs.imageregistry.operator.openshift.io
```
示例输出
```
storage:
  pvc:
    claim:
```
将claim字段留空以允许自动创建image-registry-storage PVC。

检查clusteroperator状态

$ oc get clusteroperator image-registry

示例输出

NAME             VERSION              AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
image-registry   4.17                 True        False         False      6h50m

确保您的注册表设置为已管理，以启用构建和推送镜像。
- 运行
  $ oc edit configs.imageregistry/cluster
  然后，更改行
  managementState: Removed
  到
  managementState: Managed

配置非生产集群中镜像注册表的存储

必须为镜像注册表操作符配置存储。对于非生产集群，您可以将镜像注册表设置为空目录。如果这样做，如果重新启动注册表，所有镜像都将丢失。

步骤

要将镜像注册表存储设置为空目录
```
$ oc patch configs.imageregistry.operator.openshift.io cluster --type merge --patch '{"spec":{"storage":{"emptyDir":{}}}}'
```
仅为非生产集群配置此选项。

如果在镜像注册表操作符初始化其组件之前运行此命令，则oc patch命令将失败，并显示以下错误
```
Error from server (NotFound): configs.imageregistry.operator.openshift.io "cluster" not found
```
等待几分钟，然后再次运行命令。

配置裸机的块注册表存储

要允许镜像注册表在升级期间使用块存储类型（作为集群管理员），可以使用Recreate滚动策略。

块存储卷或块持久卷受支持，但不建议在生产集群中与镜像注册表一起使用。在块存储上配置注册表的安装不是高可用的，因为注册表不能拥有多个副本。

如果选择将块存储卷与镜像注册表一起使用，则必须使用文件系统持久卷声明 (PVC)。

步骤

输入以下命令以将镜像注册表存储设置为块存储类型，修补注册表以使其使用Recreate滚动策略，并仅使用一个 (1) 副本运行
```
$ oc patch config.imageregistry.operator.openshift.io/cluster --type=merge -p '{"spec":{"rolloutStrategy":"Recreate","replicas":1}}'
```

为块存储设备配置 PV，并为该卷创建 PVC。请求的块卷使用 ReadWriteOnce (RWO) 访问模式。

创建包含以下内容的pvc.yaml文件以定义 VMware vSphere PersistentVolumeClaim对象

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: image-registry-storage (1)
  namespace: openshift-image-registry (2)
spec:
  accessModes:
  - ReadWriteOnce (3)
  resources:
    requests:
      storage: 100Gi (4)

1	表示`PersistentVolumeClaim`对象的唯一名称。
2	`PersistentVolumeClaim`对象的命名空间，即`openshift-image-registry`。
3	持久卷声明的访问模式。使用`ReadWriteOnce`，该卷可以被单个节点以读写权限挂载。
4	持久卷声明的大小。

输入以下命令以从文件创建PersistentVolumeClaim对象
```
$ oc create -f pvc.yaml -n openshift-image-registry
```

输入以下命令以编辑注册表配置，使其引用正确的 PVC
```
$ oc edit config.imageregistry.operator.openshift.io -o yaml
```
示例输出
```
storage:
  pvc:
    claim: (1)
```
1 通过创建自定义 PVC，您可以将claim字段留空，以便默认情况下自动创建image-registry-storage PVC。

完成用户配置基础设施上的安装

完成操作符配置后，您可以完成在您提供的基础设施上安装集群。

先决条件

您的控制平面已初始化。
您已完成初始操作符配置。

步骤

使用以下命令确认所有集群组件均在线

$ watch -n5 oc get clusteroperators

示例输出

NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
authentication                             4.17.0    True        False         False      19m
baremetal                                  4.17.0    True        False         False      37m
cloud-credential                           4.17.0    True        False         False      40m
cluster-autoscaler                         4.17.0    True        False         False      37m
config-operator                            4.17.0    True        False         False      38m
console                                    4.17.0    True        False         False      26m
csi-snapshot-controller                    4.17.0    True        False         False      37m
dns                                        4.17.0    True        False         False      37m
etcd                                       4.17.0    True        False         False      36m
image-registry                             4.17.0    True        False         False      31m
ingress                                    4.17.0    True        False         False      30m
insights                                   4.17.0    True        False         False      31m
kube-apiserver                             4.17.0    True        False         False      26m
kube-controller-manager                    4.17.0    True        False         False      36m
kube-scheduler                             4.17.0    True        False         False      36m
kube-storage-version-migrator              4.17.0    True        False         False      37m
machine-api                                4.17.0    True        False         False      29m
machine-approver                           4.17.0    True        False         False      37m
machine-config                             4.17.0    True        False         False      36m
marketplace                                4.17.0    True        False         False      37m
monitoring                                 4.17.0    True        False         False      29m
network                                    4.17.0    True        False         False      38m
node-tuning                                4.17.0    True        False         False      37m
openshift-apiserver                        4.17.0    True        False         False      32m
openshift-controller-manager               4.17.0    True        False         False      30m
openshift-samples                          4.17.0    True        False         False      32m
operator-lifecycle-manager                 4.17.0    True        False         False      37m
operator-lifecycle-manager-catalog         4.17.0    True        False         False      37m
operator-lifecycle-manager-packageserver   4.17.0    True        False         False      32m
service-ca                                 4.17.0    True        False         False      38m
storage                                    4.17.0    True        False         False      37m

或者，以下命令会在所有集群可用时通知您。它还会检索并显示凭据

$ ./openshift-install --dir <installation_directory> wait-for install-complete (1)

1	对于`<installation_directory>`，请指定您存储安装文件的目录路径。

示例输出

INFO Waiting up to 30m0s for the cluster to initialize...

当集群版本操作符完成从 Kubernetes API 服务器部署 OpenShift Container Platform 集群时，该命令将成功。

安装程序生成的 Ignition 配置文件包含 24 小时后过期的证书，然后会在那时续期。如果在续期证书之前关闭集群，并且稍后在 24 小时过去后重新启动集群，则集群会自动恢复已过期的证书。例外情况是，您必须手动批准挂起的node-bootstrapper证书签名请求 (CSR) 以恢复 kubelet 证书。有关更多信息，请参阅有关“从已过期控制平面证书恢复”的文档。
建议您在生成 Ignition 配置文件后 12 小时内使用它们，因为 24 小时证书会在集群安装后 16 到 22 小时之间轮换。在 12 小时内使用 Ignition 配置文件，可以避免在安装过程中运行证书更新时安装失败。

确认 Kubernetes API 服务器正在与 pod 通信。

要查看所有 pod 的列表，请使用以下命令

$ oc get pods --all-namespaces

示例输出

NAMESPACE                         NAME                                            READY   STATUS      RESTARTS   AGE
openshift-apiserver-operator      openshift-apiserver-operator-85cb746d55-zqhs8   1/1     Running     1          9m
openshift-apiserver               apiserver-67b9g                                 1/1     Running     0          3m
openshift-apiserver               apiserver-ljcmx                                 1/1     Running     0          1m
openshift-apiserver               apiserver-z25h4                                 1/1     Running     0          2m
openshift-authentication-operator authentication-operator-69d5d8bf84-vh2n8        1/1     Running     0          5m
...

使用以下命令查看先前命令输出中列出的 pod 的日志
```
$ oc logs <pod_name> -n <namespace> (1)
```
1 指定 pod 名称和命名空间，如先前命令的输出所示。

如果 pod 日志显示，则 Kubernetes API 服务器可以与集群机器通信。

对于使用光纤通道协议 (FCP) 的安装，需要其他步骤才能启用多路径。请勿在安装期间启用多路径。

有关更多信息，请参阅《安装后机器配置任务》文档中的“在 RHCOS 上使用内核参数启用多路径”。
在集群注册页面上注册您的集群。

OpenShift Container Platform 的遥测访问

在 OpenShift Container Platform 4.17 中，默认情况下运行的遥测服务（用于提供有关集群运行状况和更新成功的指标）需要互联网访问。如果您的集群连接到互联网，则遥测会自动运行，并且您的集群会注册到OpenShift 集群管理器。

确认您的OpenShift 集群管理器清单正确无误后（由遥测自动维护或使用 OpenShift 集群管理器手动维护），使用订阅监控来跟踪帐户或多集群级别的 OpenShift Container Platform 订阅。

其他资源

有关遥测服务的更多信息，请参阅关于远程运行状况监控

后续步骤

验证安装.
自定义您的集群.
为集群示例操作符和must-gather工具配置镜像流。
了解如何在断开连接的环境中使用操作符生命周期管理器。
如果您用于安装集群的镜像仓库拥有受信任的 CA 证书，请通过配置额外的信任存储将其添加到集群。
如有必要，您可以选择退出远程健康报告。
如有必要，请参阅注册您的离线集群

1	提供 Kubernetes 内部 API 的记录名称。
2	提供 Kubernetes API 的记录名称。

先决条件

关于受限网络中的安装

其他限制

OpenShift Container Platform 的互联网访问

具有用户预配基础设施的集群的要求

集群安装所需的机器

集群安装的最低资源要求

证书签名请求管理

用户配置基础设施的网络要求

通过 DHCP 设置集群节点主机名

网络连接要求

用户配置基础设施的 NTP 配置

用户配置的 DNS 需求

用户配置集群的 DNS 配置示例

用户配置的基础设施的负载均衡需求

用户配置集群的负载均衡器配置示例

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

将每个机器集扩展到计算节点

准备用户预配的基础设施

验证用户预配基础设施的DNS解析

生成用于集群节点 SSH 访问的密钥对

手动创建安装配置文件

裸机安装的install-config.yaml文件示例

在安装期间配置集群范围的代理

配置三节点集群

创建 Kubernetes 清单和 Ignition 配置文件

配置 chrony 时间服务

安装 RHCOS 并启动 OpenShift Container Platform 引导过程

使用 ISO 镜像安装 RHCOS

使用PXE或iPXE启动安装RHCOS

高级RHCOS安装配置

使用高级网络选项进行PXE和ISO安装

磁盘分区

创建单独的/var分区

保留现有分区

识别 Ignition 配置文件

默认控制台配置

为 PXE 和 ISO 安装启用串行控制台

自定义实时RHCOS ISO或PXE安装

自定义实时RHCOS ISO映像

修改实时安装ISO映像以启用串行控制台

修改实时安装ISO映像以使用自定义证书颁发机构

使用自定义网络设置修改实时安装ISO映像

为iSCSI启动设备自定义实时安装ISO镜像

使用iBFT为iSCSI启动设备自定义实时安装ISO镜像

自定义实时RHCOS PXE环境

修改实时安装PXE环境以启用串行控制台

修改实时安装PXE环境以使用自定义证书颁发机构

使用自定义网络设置修改实时安装PXE环境

为iSCSI启动设备自定义实时安装PXE环境

使用iBFT为iSCSI启动设备自定义实时安装PXE环境

高级RHCOS安装参考

ISO安装的网络和绑定选项

配置 DHCP 或静态 IP 地址

配置不带静态主机名的 IP 地址

指定多个网络接口

配置默认网关和路由

禁用单个接口上的 DHCP

组合 DHCP 和静态 IP 配置

配置单个接口上的 VLAN

提供多个 DNS 服务器

将多个网络接口绑定到单个接口

将多个 SR-IOV 网络接口绑定到双端口 NIC 接口

使用网络团队

ISO 和 PXE 安装的coreos-installer选项

ISO 或 PXE 安装的coreos.inst 引导选项

在 RHCOS 上使用内核参数启用多路径

启用辅助磁盘上的多路径

在 iSCSI 引导设备上手动安装 RHCOS

使用 iBFT 在 iSCSI 引导设备上安装 RHCOS

等待引导过程完成

使用 CLI 登录集群

批准您机器的证书签名请求

初始 Operator 配置

禁用默认 OperatorHub 目录源

镜像注册表存储配置

更改镜像注册表的管理状态

为裸机和其他手动安装配置注册表存储

配置非生产集群中镜像注册表的存储

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

裸机安装的`install-config.yaml`文件示例

创建单独的`/var`分区

ISO 和 PXE 安装的`coreos-installer`选项

ISO 或 PXE 安装的`coreos.inst` 引导选项