在任何平台上安装集群

先决条件
OpenShift Container Platform 的互联网访问
使用用户配置的基础架构的集群的要求
准备用户配置的基础架构
验证用户配置的基础架构的 DNS 解析
为集群节点 SSH 访问生成密钥对
获取安装程序
安装 OpenShift CLI
手动创建安装配置文件
创建 Kubernetes 清单和 Ignition 配置文件
安装 RHCOS 并启动 OpenShift Container Platform 引导过程
等待引导过程完成
使用 CLI 登录到集群
批准机器的证书签名请求
初始 Operator 配置
完成用户配置的基础架构上的安装
OpenShift Container Platform 的遥测访问
后续步骤

在 OpenShift Container Platform 4.17 版本中，您可以在您配置的任何基础架构上安装集群，包括虚拟化和云环境。

在尝试在虚拟化或云环境中安装 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. 最低资源要求
机器	操作系统	vCPU ^[1]	虚拟内存	存储	每秒输入/输出次数 (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) 或超线程时，一个 vCPU 等效于一个物理核心。启用时，请使用以下公式计算相应的比率：(每个核心的线程数 × 核心数) × 插槽数 = vCPU。
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 服务证书请求的有效性并批准它们的方法。

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

所有 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 记录，并且必须在安装前到位。在每个记录中，`` 是集群名称，`` 是您在 `install-config.yaml` 文件中指定的基域。完整的 DNS 记录形式为：`..`.

组件记录描述

Kubernetes API

api...

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

api-int...

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

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

路由

*.apps...

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

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

引导程序机器

bootstrap...

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

控制平面机器

...

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

计算机器

...

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 记录。

用户自备基础设施的负载均衡需求

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

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

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

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

仅限 4 层负载均衡。这可以称为原始 TCP 或 SSL 直通模式。
无状态负载均衡算法。选项根据负载均衡器实现而有所不同。

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

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

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

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

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

配置以下条件

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

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

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

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

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

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

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

如果使用 HAProxy 作为负载均衡器并且 SELinux 设置为enforcing，则必须确保 HAProxy 服务可以绑定到已配置的 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。

准备用户自备基础设施

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

本节提供有关为准备 OpenShift Container Platform 安装而设置集群基础设施所需的高级步骤的详细信息。这包括为集群节点配置 IP 网络和网络连接、通过防火墙启用所需端口以及设置所需的 DNS 和负载均衡基础设施。

准备就绪后，集群基础设施必须满足“用户自备基础设施集群的要求”一节中概述的要求。

先决条件

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

步骤

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

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

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

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

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

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

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

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

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

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

设置集群所需的 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 将 `` 替换为名称服务器的 IP 地址，将 `` 替换为您的集群名称，并将 `` 替换为您的基本域名。
示例输出
```
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 身份验证，或者如果您想使用 ./openshift-install gather 命令，都需要 SSH 代理管理密钥。

在某些发行版中，默认的 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 Hybrid Cloud Console 上的集群类型页面。如果您有 Red Hat 帐户，请使用您的凭据登录。如果没有，请创建一个帐户。
从页面自行运行部分选择您的基础架构提供商。
从OpenShift 安装程序下的下拉菜单中选择您的主机操作系统和架构，然后单击下载安装程序。

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

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

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

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

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

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

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

先决条件

您有一个现有的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`的配置映射，该映射位于`openshift-config`命名空间中，其中包含一个或多个用于代理 HTTPS 连接的附加 CA 证书。然后，集群网络操作员创建一个`trusted-ca-bundle`配置映射，将这些内容与 Red Hat Enterprise Linux CoreOS (RHCOS) 信任捆绑包合并，并且此配置映射在`Proxy`对象的`trustedCA`字段中引用。除非代理的身份证书由 RHCOS 信任捆绑包中的授权机构签名，否则需要`additionalTrustBundle`字段。
5	可选：确定`Proxy`对象的配置以在`trustedCA`字段中引用`user-ca-bundle`配置映射的策略。允许的值为`Proxyonly`和`Always`。使用`Proxyonly`仅在配置`http/https`代理时引用`user-ca-bundle`配置映射。使用`Always`始终引用`user-ca-bundle`配置映射。默认值为`Proxyonly`。

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

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

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

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

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

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

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

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

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

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

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

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

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

使用 ISO 镜像安装 RHCOS

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

先决条件

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

步骤

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

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

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

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

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

示例输出

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

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

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

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

示例输出

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

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

ISO 文件名类似于以下示例：

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

使用 ISO 启动 RHCOS 安装。使用以下安装选项之一：
- 将 ISO 镜像刻录到磁盘并直接引导它。
- 使用无盘管理 (LOM) 接口使用 ISO 重定向。

引导 RHCOS ISO 镜像，无需指定任何选项或中断实时引导序列。等待安装程序引导到 RHCOS 实时环境中的 shell 提示符。

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

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

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

1	您必须使用 `sudo` 运行 `coreos-installer` 命令，因为 `core` 用户没有执行安装所需的 root 权限。
2	`--ignition-hash` 选项在通过 HTTP URL 获取 Ignition 配置文件时是必需的，用于验证集群节点上 Ignition 配置文件的真实性。`` 是在前面步骤中获得的 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 私钥访问权限的用户运行ssh core@<node>.<cluster_name>.<base_domain>来访问节点，该私钥与您在install_config.yaml文件中指定的公钥配对。运行 RHCOS 的 OpenShift Container Platform 4 集群节点是不可变的，并依赖于 Operators 来应用集群更改。不建议使用 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	如果您使用多个网卡，请在`ip`选项中指定单个接口。例如，要在名为`eno1`的网卡上使用 DHCP，请设置`ip=eno1:dhcp`。
3	指定您上传到 HTTP 服务器的 RHCOS 文件的位置。`initrd`参数值是`initramfs`文件的位置，`coreos.live.rootfs_url`参数值是`rootfs`文件的位置，`coreos.inst.ignition_url`参数值是引导 Ignition 配置文件的位置。您还可以向`APPEND`行添加更多内核参数来配置网络或其他引导选项。

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

对于 iPXE (x86_64 + aarch64)

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

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

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

要在aarch64架构上网络引导 CoreOS kernel，您需要使用启用了IMAGE_GZIP选项的 iPXE 版本构建。请参阅iPXE 中的IMAGE_GZIP选项。

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

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

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

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

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

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

示例命令

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

继续创建集群的机器。

此时必须创建引导节点和控制平面机器。如果控制平面机器不可调度，则在安装集群之前，还需创建至少两台计算机器。

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

高级 RHCOS 安装配置

手动配置用于 OpenShift Container Platform 的 Red Hat Enterprise Linux CoreOS (RHCOS) 节点的一个主要好处是可以进行默认 OpenShift Container Platform 安装方法中不可用的配置。本节描述了一些可以使用以下技术进行的配置：

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

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

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

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

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

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

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

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

步骤

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

其他资源

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

磁盘分区

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

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

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

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

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

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

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

创建单独的`/var`分区

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

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

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

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

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

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

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

步骤

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

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

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

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

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

从Butane配置创建清单并将其保存到clusterconfig/openshift目录。例如，运行以下命令：

$ butane $HOME/clusterconfig/98-var-partition.bu -o $HOME/clusterconfig/openshift/98-var-partition.yaml

创建Ignition配置文件
```
$ openshift-install create ignition-configs --dir <installation_directory> (1)
```
1 对于<installation_directory>，请指定相同的安装目录。

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

后续步骤

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

保留现有分区

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

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

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

在 ISO 安装过程中保留现有分区

此示例保留分区标签以data开头的任何分区 (data*)

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

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

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

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

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

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

在 PXE 安装过程中保留现有分区

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

coreos.inst.save_partlabel=data*

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

coreos.inst.save_partindex=5-

此APPEND选项保留第 6 个分区

coreos.inst.save_partindex=6

识别 Ignition 配置文件

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

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

不建议直接修改这些 Ignition 配置文件。您可以更新封装在 Ignition 配置文件中的清单文件，如前面章节中的示例所示。

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

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

高级 RHCOS 安装参考

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

ISO 安装的网络和绑定选项

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

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

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

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

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

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

配置 DHCP 或静态 IP 地址

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

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

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

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

配置无静态主机名的 IP 地址

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

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

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

指定多个网络接口

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

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

配置默认网关和路由

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

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

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

禁用单个接口上的 DHCP

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

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

组合 DHCP 和静态 IP 配置

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

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

在单个接口上配置 VLAN

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

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

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

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

提供多个 DNS 服务器

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

nameserver=1.1.1.1
nameserver=8.8.8.8

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

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

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

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

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

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

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

按照管理SR-IOV设备中的指导创建SR-IOV虚拟函数 (VF)。请按照“将SR-IOV网络设备连接到虚拟机”部分中的步骤操作。
按照配置网络绑定中的指导创建绑定，将所需的VF连接到绑定并设置绑定链路状态为up。请按照所述的任何步骤创建绑定。

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

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

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

使用网络组队

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

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

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

当RHCOS切换到即将推出的RHEL版本时，计划弃用组队。更多信息，请参见此Red Hat知识库文章。

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

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

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

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

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

coreos-installer install 子命令

子命令

描述

$ coreos-installer install <options> <device>

将Ignition配置嵌入ISO映像。

coreos-installer install 子命令选项

选项

描述

-u, --image-url <url>

手动指定映像URL。

-f, --image-file <path>

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

-i, --ignition-file <path>

从文件嵌入Ignition配置。

-I, --ignition-url <URL>

从URL嵌入Ignition配置。

--ignition-hash <digest>

Ignition配置的摘要type-value。

-p, --platform <name>

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

--console <spec>

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

--append-karg <arg>…

将默认内核参数追加到已安装的系统。

--delete-karg <arg>…

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

-n, --copy-network

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

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

--network-dir <path>

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

--save-partlabel <lx>..

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

--save-partindex <id>…

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

--insecure

跳过RHCOS映像签名验证。

--insecure-ignition

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

--architecture <name>

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

--preserve-on-error

错误时不清除分区表。

-h, --help

打印帮助信息。

coreos-installer install 子命令参数

参数

描述

<device>

目标设备。

coreos-installer ISO 子命令

子命令

描述

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

自定义RHCOS实时ISO映像。

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

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

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

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

coreos-installer ISO customize 子命令选项

选项

描述

--dest-ignition <path>

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

--dest-console <spec>

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

--dest-device <path>

安装并覆盖指定的设备。

--dest-karg-append <arg>

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

--dest-karg-delete <arg>

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

--network-keyfile <path>

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

--ignition-ca <path>

指定Ignition信任的附加TLS证书颁发机构。

--pre-install <path>

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

--post-install <path>

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

--installer-config <path>

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

--live-ignition <path>

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

--live-karg-append <arg>

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

--live-karg-delete <arg>

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

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

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

-f, --force

覆盖现有的Ignition配置。

-o, --output <path>

将ISO写入新的输出文件。

-h, --help

打印帮助信息。

coreos-installer PXE 子命令

子命令

描述

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

coreos-installer pxe customize <选项> <路径>

自定义 RHCOS 实时 PXE 引导配置。

coreos-installer pxe ignition wrap <选项>

将 Ignition 配置打包到镜像中。

coreos-installer pxe ignition unwrap <选项> <镜像名称>

显示镜像中打包的 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 <路径>

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

--installer-config <path>

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

--live-ignition <path>

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

-o, --output <路径>

将 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` 指定的 OS 镜像未签名。
`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 环境后，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	对于 `<安装目录>`，请指定您存储安装文件的目录的路径。
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 对于 <安装目录>，请指定您存储安装文件的目录的路径。
验证您可以使用导出的配置成功运行 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都处于Pending状态后，请批准集群机器的CSR。

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

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

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

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

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

某些Operator可能需要等到一些CSR获批准后才能可用。

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

$ oc get csr

示例输出

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

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

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

$ oc get nodes

示例输出

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

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

附加信息

证书签名请求

初始Operator配置

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

先决条件

您的控制平面已初始化。

步骤

观察集群组件上线

$ watch -n5 oc get clusteroperators

示例输出

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

配置不可用的Operator。

禁用默认OperatorHub目录源

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

步骤

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

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

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

安装期间删除镜像注册表

在不提供可共享对象存储的平台上，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访问。

必须具有100Gi容量。

步骤

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

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

验证您没有注册表pod。

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

示例输出

No resources found in openshift-image-registry namespace

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

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

检查clusteroperator状态

$ oc get clusteroperator image-registry

示例输出

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

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

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

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

步骤

要将镜像注册表存储设置为空目录
```
$ 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	对于 `<安装目录>`，请指定您存储安装文件的目录的路径。

示例输出

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 的互联网访问

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

集群安装所需的机器

集群安装的最低资源要求

证书签名请求管理

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

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

网络连接需求

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

用户预配 DNS 需求

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

用户自备基础设施的负载均衡需求

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

准备用户自备基础设施

验证用户配置基础设施的 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 配置文件

高级 RHCOS 安装参考

ISO 安装的网络和绑定选项

配置 DHCP 或静态 IP 地址

配置无静态主机名的 IP 地址

指定多个网络接口

配置默认网关和路由

禁用单个接口上的 DHCP

组合 DHCP 和静态 IP 配置

在单个接口上配置 VLAN

提供多个 DNS 服务器

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

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

使用网络组队

ISO和PXE安装的coreos-installer选项

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

等待引导过程完成

使用 CLI 登录集群

批准机器的证书签名请求

初始Operator配置

禁用默认OperatorHub目录源

安装期间删除镜像注册表

镜像注册表存储配置

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

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

为裸机配置块存储注册表

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

OpenShift Container Platform 的遥测访问

后续步骤

创建单独的`/var`分区

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

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