在裸机上安装用户预配集群

先决条件
OpenShift Container Platform 的互联网访问
使用用户预配基础设施的集群的要求
准备用户预配的基础设施
验证用户预配基础设施的 DNS 解析
生成用于集群节点 SSH 访问的密钥对
获取安装程序
安装 OpenShift CLI
手动创建安装配置文件
创建 Kubernetes 清单和 Ignition 配置文件
安装 RHCOS 并启动 OpenShift Container Platform 引导过程
等待引导过程完成
使用 CLI 登录集群
批准机器的证书签名请求
初始操作符配置
- 安装期间删除的镜像注册表
- 镜像注册表存储配置
完成用户预配基础设施上的安装
OpenShift Container Platform 的遥测访问
后续步骤

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

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

前提条件

您回顾了有关OpenShift Container Platform 安装和更新过程的详细信息。
您阅读了有关选择集群安装方法并为用户准备集群的文档。
如果您使用防火墙，则已将其配置为允许集群需要访问的站点。

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

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 计算机器，则您需要负责所有操作系统生命周期管理和维护，包括执行系统更新、应用补丁和完成所有其他所需的任务。在 OpenShift Container Platform 4.10 及更高版本中，已弃用并删除了 RHEL 7 计算机的使用。

从 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 服务证书请求的有效性并批准它们的方法。

其他资源

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

vSphere 上裸机集群的要求

确保您在集群中的所有虚拟机上启用disk.EnableUUID参数。

其他资源

有关将disk.EnableUUID参数的值设置为VMware vSphere 上用户配置基础架构的TRUE的详细信息，请参见安装 RHCOS 并启动 OpenShift Container Platform 引导过程。

用户配置基础架构的网络要求

所有 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 集群组件进行通信。每台机器都必须能够解析集群中所有其他机器的主机名。

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

在已连接的 OpenShift Container Platform 环境中，所有节点都需要访问互联网才能提取平台容器的镜像并向 Red Hat 提供遥测数据。

表 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 秒探测一次，两次成功请求才能恢复正常，三次才能变为不正常，这些都是经过良好测试的值。

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

配置以下条件

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

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

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

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

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

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

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

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

示例 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，其中定义了裸机的信息，例如主机名、凭据等等。

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

先决条件

您创建了一个包含自定义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 服务。

将节点的持久 IP 地址添加到您的 DHCP 服务器配置中。在您的配置中，将相关网络接口的 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公钥。如果您在您自己配置的基础架构上安装集群，则必须向安装程序提供密钥。

其他资源

验证节点健康状况

获取安装程序

在安装OpenShift Container Platform之前，请在您用于安装的主机上下载安装文件。

先决条件

您需要一台运行Linux或macOS的计算机，具有500 MB的本地磁盘空间。

步骤

访问Red Hat混合云控制台上的集群类型页面。如果您有Red Hat帐户，请使用您的凭据登录。如果没有，请创建一个帐户。
从页面自己运行部分选择您的基础架构提供商。
从OpenShift安装程序下的下拉菜单中选择您的主机操作系统和架构，然后单击下载安装程序。

将下载的文件放在您要存储安装配置文件的目录中。

安装程序会在您用于安装集群的计算机上创建多个文件。您必须保留安装程序和安装程序在您完成集群安装后创建的文件。这两个文件都是删除集群所必需的。
即使集群在安装过程中失败，删除安装程序创建的文件也不会删除您的集群。要删除集群，请完成针对您的特定云提供商的OpenShift Container Platform卸载过程。

解压缩安装程序。例如，在使用Linux操作系统的计算机上，运行以下命令
```
$ tar -xvf openshift-install-linux.tar.gz
```
从Red Hat OpenShift集群管理器下载您的安装拉取密钥。此拉取密钥允许您对包含的授权机构（包括提供OpenShift Container Platform组件容器镜像的Quay.io）提供的服务进行身份验证。

或者，您可以从Red Hat客户门户检索安装程序，您可以在其中指定要下载的安装程序版本。但是，您必须拥有有效的订阅才能访问此页面。

安装OpenShift CLI

您可以安装OpenShift CLI (oc) 以通过命令行界面与OpenShift Container Platform进行交互。您可以在Linux、Windows或macOS上安装oc。

如果您安装了较早版本的oc，则无法使用它来完成OpenShift Container Platform 4.17中的所有命令。请下载并安装新版本的oc。

在Linux上安装OpenShift CLI

您可以使用以下步骤在Linux上安装OpenShift CLI (oc) 二进制文件。

步骤

导航到Red Hat客户门户上的OpenShift Container Platform下载页面。
从产品变体下拉列表中选择体系结构。
从版本下拉列表中选择相应的版本。
单击OpenShift v4.17 Linux客户端条目旁边的立即下载并保存文件。
解压存档
```
$ tar xvf <file>
```
将oc二进制文件放在PATH上的目录中。

要检查您的PATH，请执行以下命令
```
$ echo $PATH
```

验证

安装OpenShift CLI后，可以使用oc命令。
```
$ oc <command>
```

在Windows上安装OpenShift CLI

您可以使用以下步骤在Windows上安装OpenShift CLI (oc) 二进制文件。

步骤

导航到Red Hat客户门户上的OpenShift Container Platform下载页面。
从版本下拉列表中选择相应的版本。
单击OpenShift v4.17 Windows客户端条目旁边的立即下载并保存文件。
使用ZIP程序解压缩存档。
将oc二进制文件移动到PATH上的目录。

要检查您的PATH，请打开命令提示符并执行以下命令
```
C:\> path
```

验证

安装OpenShift CLI后，可以使用oc命令。
```
C:\> oc <command>
```

在macOS上安装OpenShift CLI

您可以通过以下步骤在 macOS 上安装 OpenShift CLI（oc）二进制文件。

步骤

导航到Red Hat客户门户上的OpenShift Container Platform下载页面。
从版本下拉列表中选择相应的版本。
点击OpenShift v4.17 macOS客户端条目旁边的立即下载，并保存文件。

对于 macOS arm64，请选择OpenShift v4.17 macOS arm64客户端条目。
解压归档文件。
将oc二进制文件移动到您的 PATH 环境变量中的某个目录。

要检查您的PATH，请打开终端并执行以下命令
```
$ echo $PATH
```

验证

使用oc命令验证您的安装
```
$ oc <command>
```

手动创建安装配置文件

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

先决条件

您需要在本地机器上有一个 SSH 公钥，提供给安装程序。此密钥将用于 SSH 身份验证，用于连接到您的集群节点进行调试和灾难恢复。
您已获得 OpenShift Container Platform 安装程序和集群的 pull 密钥。

步骤

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

$ mkdir <installation_directory>

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

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

您必须将此配置文件命名为install-config.yaml。
备份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": ...}' (13)
sshKey: 'ssh-ed25519 AAAA...' (14)

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

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

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

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

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

在用户提供的基础架构上安装 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 来自 Red Hat OpenShift 集群管理器的 pull 密钥。此 pull 密钥允许您向包含的授权机构（包括提供 OpenShift Container Platform 组件容器映像的 Quay.io）提供的服务进行身份验证。

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

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

其他资源

有关 API 和应用程序入口负载均衡要求的更多信息，请参阅用户预配基础设施的负载均衡要求。
有关启用安装前已禁用的集群功能的更多信息，请参阅集群功能。
有关每个功能提供的功能的更多信息，请参阅OpenShift Container Platform 4.17 中可选的集群功能。

在安装过程中配置集群范围的代理

生产环境可能会拒绝直接访问互联网，而是提供 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 证书的更多信息，请参阅恢复已过期控制平面证书。

安装 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使用，并在安装系统的第一次启动时应用。请勿直接向实时 ISO 提供标准的控制平面和计算节点 Ignition 配置文件。
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镜像站点获取安装操作系统实例所需的首选方法的 RHCOS kernel、initramfs和rootfs文件，但推荐的方法是从openshift-install命令的输出中获取正确版本的 RHCOS文件。

$ 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	如果您使用多个 NIC，请在`ip`选项中指定单个接口。例如，要在名为`eno1`的 NIC 上使用 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	如果您使用多个 NIC，请在`ip`选项中指定单个接口。例如，要在名为`eno1`的 NIC 上使用 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	如果您使用多个 NIC，请在`ip`选项中指定单个接口。例如，要在名为`eno1`的 NIC 上使用 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 地址或配置特殊设置（例如绑定），您可以执行以下操作之一

在引导实时安装程序时传递特殊的内核参数。
使用机器配置将网络文件复制到已安装的系统。
从实时安装程序 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 MB。根文件系统会自动调整大小以填充所有可用空间，直到指定的偏移量。如果未指定偏移值，或者指定的偏移值小于建议的最小值，则生成的根文件系统将太小，并且以后重新安装 RHCOS 可能会覆盖数据分区的开头。
3	数据分区的大小（以 MB 为单位）。
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
```
<安装目录>/manifest和<安装目录>/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配置文件，并将APPEND参数ignition.config.url=添加到选项中以标识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	所需的主控制台。在本例中为串行控制台。`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	所需的主控制台。在本例中为串行控制台。`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

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

自定义实时安装ISO映像以用于iSCSI引导设备

您可以设置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自定义实时安装ISO映像以用于iSCSI引导设备

您可以设置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	所需的主控制台。在本例中为串行控制台。`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文件，并运行以下命令以创建一个用于自定义CA的新自定义initramfs文件

$ 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=`）。如果设置静态IP，则必须在每个节点上标识DNS服务器IP地址（`nameserver=`）。以下示例设置：

节点的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=[:][:options]`

``是绑定设备名称（`bond0`），``表示物理（以太网）接口的逗号分隔列表（`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=[:][:options]`。

``是绑定设备名称（`bond0`），``表示内核中已知的虚拟函数（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` 引导选项

通过向 RHCOS 实时安装程序传递 coreos.inst 引导参数，您可以在启动时自动调用 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地址。

通过运行以下命令并将必要的内核参数用于安装RHCOS到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

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

先决条件

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

步骤

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

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

1	目标门户的IP地址。

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

通过运行以下命令并将必要的内核参数用于安装RHCOS到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子命令执行。

其他资源

有关使用特殊的coreos.inst.*参数来指导实时安装程序的更多信息，请参阅安装RHCOS并启动OpenShift Container Platform引导过程。

等待引导过程完成

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

先决条件

您已为集群创建 Ignition 配置文件。
您已配置合适的网络、DNS 和负载均衡基础架构。
您已获得安装程序并为您的集群生成了Ignition配置文件。
您已在集群机器上安装RHCOS，并提供了OpenShift Container Platform安装程序生成的Ignition配置文件。
您的机器具有直接的互联网访问权限或可以使用HTTP或HTTPS代理。

步骤

监控引导过程

$ ./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，并确保您看到为添加到集群的每台机器的客户端请求显示“待处理”或“已批准”状态。

$ 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 都处于“待处理”状态后，请批准集群机器的 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 未获批准且处于“待处理”状态，请批准集群机器的 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 后，机器将具有“就绪”状态。通过运行以下命令验证此状态

$ 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 后，机器可能需要几分钟才能过渡到“就绪”状态。

附加信息

证书签名请求

初始 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 问题。

安装过程中移除镜像注册表

在不提供可共享对象存储的平台上，OpenShift Image Registry Operator 将自身引导为Removed。这允许openshift-installer在这些平台类型上完成安装。

安装后，您必须编辑 Image Registry Operator 配置以将managementState从Removed切换到Managed。完成后，您必须配置存储。

镜像注册表存储配置

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

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

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

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

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

先决条件

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

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

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

必须具有 100 Gi 容量。

步骤

要配置注册表以使用存储，请更改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 订阅。

其他资源

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

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

前提条件

OpenShift Container Platform 的互联网访问

用户配置基础架构集群的要求

集群安装所需的机器

集群安装的最低资源要求

证书签名请求管理

vSphere 上裸机集群的要求

用户配置基础架构的网络要求

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

网络连接要求

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

用户自备 DNS 要求

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

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

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

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

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

准备用户提供的基础设施

用户自备基础架构的 DNS 解析验证

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

获取安装程序

安装OpenShift CLI

在Linux上安装OpenShift CLI

在Windows上安装OpenShift CLI

在macOS上安装OpenShift CLI

手动创建安装配置文件

裸机环境的示例 install-config.yaml 文件

在安装过程中配置集群范围的代理

配置三节点集群

创建 Kubernetes 清单文件和 Ignition 配置文件

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

使用 ISO 映像安装 RHCOS

使用 PXE 或 iPXE 引导安装 RHCOS

高级 RHCOS 安装配置

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

磁盘分区

创建单独的 /var 分区

保留现有分区

识别 Ignition 配置文件

默认控制台配置

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

自定义实时RHCOS ISO或PXE安装

自定义实时RHCOS ISO映像

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

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

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

自定义实时安装ISO映像以用于iSCSI引导设备

使用iBFT自定义实时安装ISO映像以用于iSCSI引导设备

自定义实时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 配置

安装过程中移除镜像注册表

镜像注册表存储配置

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

创建单独的 `/var` 分区

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

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