×

在 OpenShift Container Platform 4.17 版本中,您可以在您在受限网络中预配的 IBM Power® 基础设施上安装集群。

非裸机平台存在其他注意事项。在安装 OpenShift Container Platform 集群之前,请查看在未经测试的平台上部署 OpenShift Container Platform 的指南中的信息。

先决条件

关于受限网络中的安装

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

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

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

其他限制

受限网络中的集群具有以下其他限制:

  • ClusterVersion状态包含无法检索可用更新错误。

  • 默认情况下,您无法使用开发者目录的内容,因为您无法访问所需的镜像流标签。

OpenShift Container Platform 的互联网访问

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

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

  • 访问OpenShift 集群管理器以下载安装程序并执行订阅管理。如果集群具有互联网访问权限并且您没有禁用遥测,则该服务会自动授权您的集群。

  • 访问Quay.io以获取安装集群所需的软件包。

  • 获取执行集群更新所需的软件包。

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

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

本节描述在用户配置的基础设施上部署 OpenShift Container Platform 的要求。

集群安装所需的机器

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

表 1. 最低所需主机
主机 描述

一台临时引导机器

集群需要引导机器才能在三台控制平面机器上部署 OpenShift Container Platform 集群。安装集群后,您可以删除引导机器。

三台控制平面机器

控制平面机器运行构成控制平面的 Kubernetes 和 OpenShift Container Platform 服务。

至少两台计算机器,也称为工作机器。

OpenShift Container Platform 用户请求的工作负载在计算机器上运行。

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

引导程序、控制平面和计算机器必须使用 Red Hat Enterprise Linux CoreOS (RHCOS) 作为操作系统。

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

集群安装的最低资源要求

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

表 2. 最低资源要求
机器 操作系统 vCPU [1] 虚拟内存 存储 每秒输入/输出次数 (IOPS)[2]

引导程序

RHCOS

2

16 GB

100 GB

300

控制平面

RHCOS

2

16 GB

100 GB

300

计算

RHCOS

2

8 GB

100 GB

300

  1. 当未启用同时多线程 (SMT) 或超线程时,一个 vCPU 等于一个物理核心。启用时,请使用以下公式计算相应的比率:(每个核心的线程数 × 核心数)× 插槽数 = vCPU 数。

  2. OpenShift Container Platform 和 Kubernetes 对磁盘性能敏感,建议使用更快的存储,特别是对于控制平面节点上的 etcd。请注意,在许多云平台上,存储大小和 IOPS 成正比,因此您可能需要过度分配存储卷才能获得足够的性能。

从 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 中使用。

其他资源

最低 IBM Power 要求

您可以在以下 IBM® 硬件上安装 OpenShift Container Platform 4.17 版本

  • 基于 IBM Power®9 或 IBM Power®10 处理器的系统

在 OpenShift Container Platform 4.17 中,已弃用对所有 IBM Power®8 型号、IBM Power® AC922、IBM Power® IC922 和 IBM Power® LC922 的 RHCOS 功能的支持。Red Hat 建议您使用较新的硬件型号。

硬件要求

  • 跨多个 PowerVM 服务器的六个逻辑分区 (LPAR)

操作系统要求

  • 基于 IBM Power®9 或 Power10 处理器的一个系统实例

在您的 IBM Power® 实例上,设置:

  • 三个 LPAR 用于 OpenShift Container Platform 控制平面机器

  • 两个 LPAR 用于 OpenShift Container Platform 计算机器

  • 一个 LPAR 用于临时 OpenShift Container Platform 引导机器

IBM Power 客户机虚拟机的磁盘存储

  • 本地存储,或由虚拟 I/O 服务器使用 vSCSI、NPIV(N 端口 ID 虚拟化)、光纤通道或 SSP(共享存储池)提供的存储

PowerVM 客户机虚拟机的网络

  • 专用物理适配器或 SR-IOV 虚拟功能

  • 由虚拟 I/O 服务器使用共享以太网适配器提供

  • 由虚拟 I/O 服务器使用 IBM® vNIC 虚拟化

存储/主内存

  • OpenShift Container Platform 控制平面机器:100 GB / 16 GB

  • OpenShift Container Platform 计算机器:100 GB / 8 GB

  • 临时 OpenShift Container Platform 引导机器:100 GB / 16 GB

硬件要求

  • 跨多个 PowerVM 服务器的六个 LPAR

操作系统要求

  • 基于 IBM Power®9 或 IBM Power®10 处理器的一个系统实例

在您的 IBM Power® 实例上,设置:

  • 三个 LPAR 用于 OpenShift Container Platform 控制平面机器

  • 两个 LPAR 用于 OpenShift Container Platform 计算机器

  • 一个 LPAR 用于临时 OpenShift Container Platform 引导机器

IBM Power 客户机虚拟机的磁盘存储

  • 本地存储,或由虚拟 I/O 服务器使用 vSCSI、NPIV(N 端口 ID 虚拟化)或 SSP(共享存储池)提供的存储

PowerVM 客户机虚拟机的网络

  • 专用物理适配器或 SR-IOV 虚拟功能

  • 由虚拟 I/O 服务器使用共享以太网适配器虚拟化

  • 由虚拟 I/O 服务器使用 IBM® vNIC 虚拟化

存储/主内存

  • OpenShift Container Platform 控制平面机器:120 GB / 32 GB

  • OpenShift Container Platform 计算机器:120 GB / 32 GB

  • 临时 OpenShift Container Platform 引导机器:120 GB / 16 GB

证书签名请求管理

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

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

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

在初始启动期间,机器需要一个IP地址配置,该配置可以通过DHCP服务器设置,也可以通过提供所需的启动选项静态设置。建立网络连接后,机器会从HTTP或HTTPS服务器下载其Ignition配置文件。然后,Ignition配置文件用于设置每台机器的精确状态。安装后,机器配置操作员会对机器进行更多更改,例如应用新的证书或密钥。

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

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

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

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

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

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

网络连接要求

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

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

表3. 所有机器到所有机器通信使用的端口
协议 端口 描述

ICMP

N/A

网络可达性测试

TCP

1936

指标

9000-9999

主机级服务,包括端口`9100`-`9101`上的节点导出器和端口`9099`上的集群版本操作员。

10250-10259

Kubernetes保留的默认端口

UDP

4789

VXLAN

6081

Geneve

9000-9999

主机级服务,包括端口`9100`-`9101`上的节点导出器。

500

IPsec IKE数据包

4500

IPsec NAT-T数据包

123

UDP端口`123`上的网络时间协议(NTP)

如果配置了外部NTP时间服务器,则必须打开UDP端口`123`。

TCP/UDP

30000-32767

Kubernetes节点端口

ESP

N/A

IPsec封装安全负载(ESP)

表4. 所有机器到控制平面通信使用的端口
协议 端口 描述

TCP

6443

Kubernetes API

表5. 控制平面机器到控制平面机器通信使用的端口
协议 端口 描述

TCP

2379-2380

etcd服务器和对等端口

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

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

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

用户预配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记录格式为:`...`。

表6. 必需的DNS记录
组件 记录 描述

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记录。应用程序入口负载均衡器将目标指向运行入口控制器Pod的机器。入口控制器Pod默认运行在计算机器上。集群外部的客户端和集群内的所有节点都必须能够解析这些记录。

例如,`console-openshift-console.apps..`用作指向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
1 提供 Kubernetes API 的名称解析。该记录引用 API 负载均衡器的 IP 地址。
2 提供 Kubernetes API 的名称解析。该记录引用 API 负载均衡器的 IP 地址,并用于内部集群通信。
3 提供通配符路由的名称解析。该记录引用应用程序入口负载均衡器的 IP 地址。应用程序入口负载均衡器以计算机器上的 Ingress Controller Pod 为目标。默认情况下,Ingress Controller Pod 在计算机器上运行。

在此示例中,同一个负载均衡器用于 Kubernetes API 和应用程序入口流量。在生产环境中,您可以分别部署 API 和应用程序入口负载均衡器,以便您可以隔离地扩展每个负载均衡器基础架构。

4 提供引导机器的名称解析。
5 提供控制平面机器的名称解析。
6 提供计算机器的名称解析。
用户自备集群的 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 和应用程序入口负载均衡基础架构。在生产环境中,您可以分别部署 API 和应用程序入口负载均衡器,以便您可以隔离地扩展每个负载均衡器基础架构。

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

负载均衡基础架构必须满足以下要求

  1. **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 秒探测一次,两次成功的请求变为健康,三次变为不健康。

  2. **应用程序入口负载均衡器**: 为从集群外部流入的应用程序流量提供入口点。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` 配置。本示例并非旨在提供有关选择一种负载均衡解决方案而非另一种解决方案的建议。

在此示例中,同一个负载均衡器用于 Kubernetes API 和应用程序入口流量。在生产环境中,您可以分别部署 API 和应用程序入口负载均衡器,以便您可以隔离地扩展每个负载均衡器基础架构。

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

API 和应用程序入口负载均衡器配置示例
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 在计算机器上运行。
5 80 端口处理 HTTP 流量,并指向运行 Ingress Controller Pod 的机器。Ingress Controller Pod 默认运行在计算机器上。

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

如果您使用 HAProxy 作为负载均衡器,可以通过在 HAProxy 节点上运行 netstat -nltupe 命令来检查 haproxy 进程是否正在监听 64432262344380 端口。

准备用户自备的基础设施

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

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

准备完毕后,您的集群基础设施必须满足用户自备基础设施集群的要求部分中概述的要求。

先决条件
步骤
  1. 如果您使用 DHCP 为集群节点提供 IP 网络配置,请配置您的 DHCP 服务。

    1. 为节点的 DHCP 服务器配置中添加持久性 IP 地址。在您的配置中,将相关网络接口的 MAC 地址与每个节点的目标 IP 地址匹配。

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

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

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

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

  2. 确保您的网络基础设施在集群组件之间提供所需的网络连接。有关要求的详细信息,请参阅用户自备基础设施的网络要求部分。

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

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

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

  4. 设置集群所需的 DNS 基础设施。

    1. 为 Kubernetes API、应用程序通配符、引导机器、控制平面机器和计算机器配置 DNS 名称解析。

    2. 为 Kubernetes API、引导机器、控制平面机器和计算机器配置反向 DNS 解析。

      有关 OpenShift Container Platform DNS 要求的更多信息,请参阅用户自备 DNS 要求部分。

  5. 验证您的 DNS 配置。

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

    2. 从您的安装节点运行针对负载均衡器和集群节点 IP 地址的反向 DNS 查询。验证响应中的记录名称是否与正确的组件相对应。

      有关详细的 DNS 验证步骤,请参阅用户自备基础设施的 DNS 验证部分。

  6. 配置所需的 API 和应用程序入口负载均衡基础设施。有关要求的更多信息,请参阅用户自备基础设施的负载均衡要求部分。

一些负载均衡解决方案要求在初始化负载均衡之前先配置集群节点的 DNS 名称解析。

验证用户自备基础设施的 DNS 解析

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

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

先决条件
  • 您已为用户自备的基础设施配置了所需的 DNS 记录。

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

    1. 对 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
    2. 对 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
    3. 测试示例 *.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
    4. 对引导 DNS 记录名称运行查询。检查结果是否指向引导节点的 IP 地址。

      $ dig +noall +answer @<nameserver_ip> bootstrap.<cluster_name>.<base_domain>
      示例输出
      bootstrap.ocp4.example.com.		604800	IN	A	192.168.1.96
    5. 使用此方法对控制平面节点和计算节点的 DNS 记录名称执行查询。检查结果是否与每个节点的 IP 地址相对应。

  2. 从您的安装节点运行针对负载均衡器和集群节点 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密钥对)配置的密钥。

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

    $ ssh-keygen -t ed25519 -N '' -f <path>/<file_name> (1)
    1 指定新SSH密钥的路径和文件名,例如~/.ssh/id_ed25519。如果您有现有的密钥对,请确保您的公钥位于~/.ssh目录中。

    如果您计划安装一个OpenShift Container Platform集群,该集群仅在x86_64ppc64les390x架构上使用已提交给NIST进行FIPS 140-2/140-3验证的RHEL加密库,请不要创建使用ed25519算法的密钥。请改用rsaecdsa算法创建密钥。

  2. 查看SSH公钥

    $ cat <path>/<file_name>.pub

    例如,运行以下命令查看~/.ssh/id_ed25519.pub公钥:

    $ cat ~/.ssh/id_ed25519.pub
  3. 如果尚未添加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。

  4. 将您的SSH私钥添加到ssh-agent

    $ ssh-add <path>/<file_name> (1)
    1 指定SSH私钥的路径和文件名,例如~/.ssh/id_ed25519
    示例输出
    Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
后续步骤
  • 安装OpenShift Container Platform时,请向安装程序提供SSH公钥。

手动创建安装配置文件

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

先决条件
  • 您在本地机器上有一个SSH公钥,可以提供给安装程序。该密钥将用于对集群节点进行SSH身份验证,以进行调试和灾难恢复。

  • 您已获得OpenShift Container Platform安装程序和集群的pull secret。

步骤
  1. 创建一个安装目录来存储所需的安装资源:

    $ mkdir <installation_directory>

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

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

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

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

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

IBM Power的示例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)
  architecture: ppc64le
controlPlane: (2)
  hyperthreading: Enabled (3)
  name: master
  replicas: 3 (5)
  architecture: ppc64le
metadata:
  name: test (6)
networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14 (7)
    hostPrefix: 23 (8)
  networkType: OVNKubernetes (9)
  serviceNetwork: (10)
  - 172.30.0.0/16
platform:
  none: {} (11)
fips: false (12)
pullSecret: '{"auths":{"<local_registry>": {"auth": "<credentials>","email": "[email protected]"}}}' (13)
sshKey: 'ssh-ed25519 AAAA...' (14)
additionalTrustBundle: | (15)
  -----BEGIN CERTIFICATE-----
  ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
  -----END CERTIFICATE-----
imageContentSources: (16)
- mirrors:
  - <local_registry>/<local_repository_name>/release
  source: quay.io/openshift-release-dev/ocp-release
- mirrors:
  - <local_registry>/<local_repository_name>/release
  source: quay.io/openshift-release-dev/ocp-v4.0-art-dev
1 集群的基本域名。所有DNS记录都必须是此基本域的子域,并且包含集群名称。
2 controlPlane部分是一个单映射,但compute部分是一系列映射。为了满足不同数据结构的要求,compute部分的第一行必须以连字符-开头,而controlPlane部分的第一行则不能。只使用一个控制平面池。
3 不支持同时多线程 (SMT)。
4 在用户预配的基础架构上安装OpenShift Container Platform时,必须将此值设置为0。在安装程序预配的安装中,此参数控制集群为您创建和管理的计算机的数量。在用户预配的安装中,您必须在完成集群安装之前手动部署计算机构。

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

5 添加到集群的控制平面机器的数量。由于集群使用这些值作为集群中etcd端点的数量,因此该值必须与您部署的控制平面机器的数量相匹配。
6 您在DNS记录中指定的集群名称。
7 分配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 地址池。此块不得与现有物理网络重叠。如果您需要从外部网络访问服务,请配置负载均衡器和路由器来管理流量。
11 您必须将平台设置为none。您不能为 IBM Power® 基础架构提供其他平台配置变量。

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

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

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

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

13 对于<local_registry>,请指定您的镜像注册表用于提供内容的注册表域名,以及可选的端口。例如,registry.example.comregistry.example.com:5000。对于<credentials>,请指定您的镜像注册表的 base64 编码用户名和密码。
14 Red Hat Enterprise Linux CoreOS (RHCOS) 中core用户的 SSH 公钥。

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

15 提供您用于镜像注册表的证书文件的内容。
16 根据您用于镜像存储库的命令的输出提供imageContentSources部分。
  • 使用oc adm release mirror命令时,请使用imageContentSources部分的输出。

  • 使用oc mirror命令时,请使用运行该命令生成的ImageContentSourcePolicy文件的repositoryDigestMirrors部分。

  • ImageContentSourcePolicy已弃用。更多信息请参见《配置镜像注册表存储库镜像》。

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

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

先决条件
  • 您已有一个现有的install-config.yaml文件。

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

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

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

步骤
  1. 编辑您的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) 信任捆绑包合并,并在Proxy对象的trustedCA字段中引用此 config map。除非代理的身份证书由 RHCOS 信任捆绑包中的机构签名,否则需要additionalTrustBundle字段。
    5 可选:确定Proxy对象的配置策略,以便在trustedCA字段中引用user-ca-bundle config map。允许的值为ProxyonlyAlways。使用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
  2. 保存文件并在安装 OpenShift Container Platform 时引用它。

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

仅支持名为clusterProxy对象,无法创建其他代理。

配置三节点集群

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

在三节点 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) 虚拟机时,请勿部署任何计算节点。

集群网络操作员配置

集群网络的配置指定为集群网络操作员 (CNO) 配置的一部分,并存储在一个名为cluster的自定义资源 (CR) 对象中。CR 指定operator.openshift.io API 组中Network API 的字段。

在集群安装期间,CNO 配置从Network.config.openshift.io API 组中的Network API 继承以下字段

clusterNetwork

分配 Pod IP 地址的 IP 地址池。

serviceNetwork

服务的 IP 地址池。

defaultNetwork.type

集群网络插件。安装期间,唯一支持的插件是OVNKubernetes

您可以通过设置名为cluster的 CNO 对象中defaultNetwork对象的字段来指定集群的集群网络插件配置。

集群网络操作员配置对象

集群网络操作员 (CNO) 的字段在以下表格中描述

表 9. 集群网络操作员配置对象
字段 类型 描述

metadata.name

字符串

CNO 对象的名称。此名称始终为cluster

spec.clusterNetwork

数组

一个列表,指定分配 Pod IP 地址的 IP 地址块以及分配给集群中每个节点的子网前缀长度。例如

spec:
  clusterNetwork:
  - cidr: 10.128.0.0/19
    hostPrefix: 23
  - cidr: 10.128.32.0/19
    hostPrefix: 23

spec.serviceNetwork

数组

服务的 IP 地址块。OVN-Kubernetes 网络插件仅支持服务网络的单个 IP 地址块。例如

spec:
  serviceNetwork:
  - 172.30.0.0/14

您只能在创建清单之前在install-config.yaml文件中自定义此字段。该值在清单文件中是只读的。

spec.defaultNetwork

对象

配置集群网络的网络插件。

spec.kubeProxyConfig

对象

此对象的字段指定 kube-proxy 配置。如果您使用的是 OVN-Kubernetes 集群网络插件,则 kube-proxy 配置无效。

对于需要跨多个网络部署对象的集群,请确保为install-config.yaml文件中定义的每种网络类型指定相同的值clusterNetwork.hostPrefix参数。为每个clusterNetwork.hostPrefix参数设置不同的值会影响 OVN-Kubernetes 网络插件,插件无法有效地在不同节点之间路由对象流量。

defaultNetwork 对象配置

defaultNetwork 对象的值在以下表格中定义

表 10. defaultNetwork 对象
字段 类型 描述

类型

字符串

OVNKubernetes。安装过程中选择 Red Hat OpenShift 网络网络插件。此值在集群安装后无法更改。

OpenShift Container Platform 默认使用 OVN-Kubernetes 网络插件。OpenShift SDN 不再作为新集群的安装选项可用。

ovnKubernetesConfig

对象

此对象仅对 OVN-Kubernetes 网络插件有效。

OVN-Kubernetes 网络插件的配置

下表描述了 OVN-Kubernetes 网络插件的配置字段

表 11. ovnKubernetesConfig 对象
字段 类型 描述

mtu

整数

Geneve(通用网络虚拟化封装)覆盖网络的最大传输单元 (MTU)。这将根据主网络接口的 MTU 自动检测。您通常不需要覆盖检测到的 MTU。

如果自动检测到的值与您的预期不符,请确认节点上主网络接口上的 MTU 正确。您不能使用此选项更改节点上主网络接口的 MTU 值。

如果您的集群需要为不同的节点使用不同的 MTU 值,则必须将此值设置为集群中最低 MTU 值的100。例如,如果集群中某些节点的 MTU 为9001,而某些节点的 MTU 为1500,则必须将此值设置为1400

genevePort

整数

用于所有 Geneve 数据包的端口。默认值为6081。此值在集群安装后无法更改。

ipsecConfig

对象

指定一个配置对象来自定义 IPsec 配置。

ipv4

对象

指定 IPv4 设置的配置对象。

ipv6

对象

指定 IPv6 设置的配置对象。

policyAuditConfig

对象

指定一个配置对象来自定义网络策略审计日志记录。如果未设置,则使用默认审计日志设置。

gatewayConfig

对象

可选:指定一个配置对象来自定义如何将出站流量发送到节点网关。

迁移出站流量时,在集群网络操作员 (CNO) 成功推出更改之前,您可能会遇到工作负载和服务流量的一些中断。

表 12. ovnKubernetesConfig.ipv4 对象
字段 类型 描述

internalTransitSwitchSubnet

字符串

如果您的现有网络基础设施与100.88.0.0/16 IPv4 子网重叠,您可以为 OVN-Kubernetes 指定不同的内部使用 IP 地址范围。启用东西向流量的分布式转接交换机的子网。此子网不能与 OVN-Kubernetes 或主机本身使用的任何其他子网重叠。它必须足够大,可以容纳集群中每个节点的一个 IP 地址。

默认值为100.88.0.0/16

internalJoinSubnet

字符串

如果您的现有网络基础设施与100.64.0.0/16 IPv4 子网重叠,您可以为 OVN-Kubernetes 指定不同的内部使用 IP 地址范围。您必须确保 IP 地址范围不与 OpenShift Container Platform 安装使用的任何其他子网重叠。IP 地址范围必须大于可以添加到集群中的最大节点数。例如,如果clusterNetwork.cidr值为10.128.0.0/14,并且clusterNetwork.hostPrefix值为/23,则最大节点数为2^(23-14)=512

默认值为100.64.0.0/16

表 13. ovnKubernetesConfig.ipv6 对象
字段 类型 描述

internalTransitSwitchSubnet

字符串

如果您的现有网络基础设施与fd97::/64 IPv6 子网重叠,您可以为 OVN-Kubernetes 指定不同的内部使用 IP 地址范围。启用东西向流量的分布式转接交换机的子网。此子网不能与 OVN-Kubernetes 或主机本身使用的任何其他子网重叠。它必须足够大,可以容纳集群中每个节点的一个 IP 地址。

默认值为fd97::/64

internalJoinSubnet

字符串

如果您的现有网络基础设施与fd98::/64 IPv6 子网重叠,您可以为 OVN-Kubernetes 指定不同的内部使用 IP 地址范围。您必须确保 IP 地址范围不与 OpenShift Container Platform 安装使用的任何其他子网重叠。IP 地址范围必须大于可以添加到集群中的最大节点数。

默认值为fd98::/64

表 14. policyAuditConfig 对象
字段 类型 描述

rateLimit

整数

每个节点每秒生成的最多消息数。默认值为每秒20条消息。

maxFileSize

整数

审计日志的最大大小(字节)。默认值为50000000或 50 MB。

maxLogFiles

整数

保留的最大日志文件数。

destination

字符串

以下附加审计日志目标之一

libc

主机上 journald 进程的 libc syslog() 函数。

udp:<host>:<port>

一个 syslog 服务器。将<host>:<port>替换为 syslog 服务器的主机和端口。

unix:<file>

<file>指定的 Unix 域套接字文件。

null

不将审计日志发送到任何其他目标。

syslogFacility

字符串

syslog 设施,例如kern,如 RFC5424 中所定义。默认值为local0

表 15. gatewayConfig 对象
字段 类型 描述

routingViaHost

布尔值

将此字段设置为true可将 Pod 的出站流量发送到主机网络堆栈。对于依赖于内核路由表中手动配置的路由的高度专业化的安装和应用程序,您可能希望将出站流量路由到主机网络堆栈。默认情况下,出站流量在 OVN 中处理以退出集群,并且不受内核路由表中专用路由的影响。默认值为false

此字段与 Open vSwitch 硬件卸载功能存在交互。如果将此字段设置为true,则您将无法获得卸载的性能优势,因为出站流量由主机网络堆栈处理。

ipForwarding

对象

您可以使用Network资源中的ipForwarding规范来控制OVN-Kubernetes管理接口上所有流量的IP转发。指定Restricted仅允许针对Kubernetes相关流量的IP转发。指定Global允许转发所有IP流量。对于新安装,默认为Restricted。对于 OpenShift Container Platform 4.14 或更高版本的更新,默认为Global

ipv4

对象

可选:指定一个对象来配置用于主机到服务流量(IPv4 地址)的内部 OVN-Kubernetes 伪装地址。

ipv6

对象

可选:指定一个对象来配置用于主机到服务流量(IPv6 地址)的内部 OVN-Kubernetes 伪装地址。

表 16. gatewayConfig.ipv4 对象
字段 类型 描述

internalMasqueradeSubnet

字符串

在内部用于启用主机到服务流量的伪装 IPv4 地址。主机也配置了这些 IP 地址以及共享网关桥接口。默认值为169.254.169.0/29

对于 OpenShift Container Platform 4.17 和更高版本,集群使用169.254.0.0/17作为默认伪装子网。对于升级的集群,默认伪装子网不会更改。

表 17. gatewayConfig.ipv6 对象
字段 类型 描述

internalMasqueradeSubnet

字符串

在内部用于启用主机到服务流量的伪装 IPv6 地址。主机也配置了这些 IP 地址以及共享网关桥接口。默认值为fd69::/125

对于 OpenShift Container Platform 4.17 和更高版本,集群使用fd69::/112作为默认伪装子网。对于升级的集群,默认伪装子网不会更改。

表 18. ipsecConfig 对象
字段 类型 描述

mode

字符串

指定 IPsec 实现的行为。必须是以下值之一

  • Disabled:在集群节点上未启用 IPsec。

  • External:已为与外部主机的网络流量启用 IPsec。

  • Full:已为 Pod 流量和与外部主机的网络流量启用 IPsec。

启用 IPSec 的示例 OVN-Kubernetes 配置
defaultNetwork:
  type: OVNKubernetes
  ovnKubernetesConfig:
    mtu: 1400
    genevePort: 6081
      ipsecConfig:
        mode: Full

创建 Kubernetes 清单和 Ignition 配置文件

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

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

  • OpenShift Container Platform 安装程序生成的 Ignition 配置文件包含在 24 小时后过期的证书,然后在该时间续订。如果集群在续订证书之前关闭,并且集群在 24 小时后重新启动,则集群会自动恢复已过期的证书。例外情况是,您必须手动批准挂起的node-bootstrapper证书签名请求 (CSR) 以恢复 kubelet 证书。有关详细信息,请参阅从已过期的控制平面证书中恢复的文档。

  • 建议您在生成 Ignition 配置文件后 12 小时内使用它们,因为 24 小时证书会在集群安装后 16 到 22 小时之间轮换。通过在 12 小时内使用 Ignition 配置文件,您可以避免在安装期间运行证书更新时安装失败。

生成清单和 Ignition 文件的安装程序是特定于体系结构的,可以从客户端镜像镜像获取。安装程序的 Linux 版本(没有体系结构后缀)仅在 ppc64le 上运行。此安装程序也提供 Mac OS 版本。

先决条件
  • 您已获得 OpenShift Container Platform 安装程序。对于受限网络安装,这些文件位于您的镜像主机上。

  • 您已创建install-config.yaml安装配置文件。

步骤
  1. 更改到包含 OpenShift Container Platform 安装程序的目录,并为集群生成 Kubernetes 清单

    $ ./openshift-install create manifests --dir <installation_directory> (1)
    1 对于<installation_directory>,请指定包含您创建的install-config.yaml文件的安装目录。

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

    当您将控制平面节点从默认的不可调度配置为可调度时,需要额外的订阅。这是因为控制平面节点随后成为计算节点。

  2. 检查<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. 保存并退出文件。

  3. 要创建 Ignition 配置文件,请从包含安装程序的目录运行以下命令

    $ ./openshift-install create ignition-configs --dir <installation_directory> (1)
    1 对于<installation_directory>,请指定相同的安装目录。

    安装目录下会为引导程序、控制平面和计算节点创建 Ignition 配置文件。kubeadmin-passwordkubeconfig 文件创建在 ./<installation_directory>/auth 目录下。

    .
    ├── auth
    │   ├── kubeadmin-password
    │   └── kubeconfig
    ├── bootstrap.ign
    ├── master.ign
    ├── metadata.json
    └── worker.ign

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

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

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

使用 ISO 镜像安装 RHCOS

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

先决条件
  • 您已为集群创建了 Ignition 配置文件。

  • 您已配置合适的网络、DNS 和负载均衡基础架构。

  • 您有一个可以从您的计算机和您创建的机器访问的 HTTP 服务器。

  • 您已查看“高级 RHCOS 安装配置”部分,了解配置网络和磁盘分区等功能的不同方法。

步骤
  1. 获取每个 Ignition 配置文件的 SHA512 哈希值。例如,您可以在运行 Linux 的系统上使用以下命令获取 bootstrap.ign Ignition 配置文件的 SHA512 哈希值:

    $ sha512sum <installation_directory>/bootstrap.ign

    在后面的步骤中,会将哈希值提供给 coreos-installer,以验证集群节点上 Ignition 配置文件的真实性。

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

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

  3. 从安装主机验证 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.ignworker.ign,以验证控制平面和计算节点的 Ignition 配置文件是否也可用。

  4. 虽然可以从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

  5. 使用 ISO 启动 RHCOS 安装。使用以下安装选项之一:

    • 将 ISO 镜像刻录到磁盘并直接启动它。

    • 使用免维护管理 (LOM) 接口进行 ISO 重定向。

  6. 启动 RHCOS ISO 镜像,无需指定任何选项或中断实时启动序列。等待安装程序在 RHCOS 实时环境中启动到 shell 提示符。

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

  7. 运行 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
  8. 监控机器控制台上 RHCOS 安装的进度。

    请确保在开始 OpenShift Container Platform 安装之前,每个节点上的安装都成功。观察安装过程还可以帮助确定可能出现的 RHCOS 安装问题的原因。

  9. RHCOS 安装完成后,必须重新启动系统。系统重新启动期间,它将应用您指定的 Ignition 配置文件。

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

    示例命令
    Ignition: ran on 2022/03/14 14:48:33 UTC (this boot)
    Ignition: user-provided config was applied
  11. 继续为您的集群创建其他机器。

    您必须在此时间创建引导程序和控制平面机器。如果控制平面机器不可调度,则在安装 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 集群节点是不可变的,并依赖于 Operators 来应用集群更改。不建议使用 SSH 访问集群节点。但是,在调查安装问题时,如果 OpenShift Container Platform API 不可用,或者 kubelet 在目标节点上运行不正常,则可能需要 SSH 访问权限进行调试或灾难恢复。

高级 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接口。

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

  1. 按照管理SR-IOV设备中的指导创建SR-IOV虚拟函数(VF)。请遵循“将SR-IOV网络设备附加到虚拟机”部分中的步骤。

  2. 按照配置网络绑定中的指导创建绑定,将所需的VF附加到绑定并设置绑定链路状态为up。请遵循所描述的任何步骤来创建绑定。

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

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

    <name>是绑定设备名称(bond0),<network_interfaces>表示内核中已知的虚拟函数(VF),并在ip link命令的输出中显示(eno1f0eno2f0),而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

使用PXE引导安装RHCOS

您可以使用PXE引导在机器上安装RHCOS。

先决条件
  • 您已为集群创建了 Ignition 配置文件。

  • 您已配置合适的网络、DNS 和负载均衡基础架构。

  • 您已配置合适的PXE基础结构。

  • 您有一个可以从您的计算机和您创建的机器访问的 HTTP 服务器。

  • 您已查看“高级 RHCOS 安装配置”部分,了解配置网络和磁盘分区等功能的不同方法。

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

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

  2. 从安装主机验证 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.ignworker.ign,以验证控制平面和计算节点的 Ignition 配置文件是否也可用。

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

    $ openshift-install coreos print-stream-json | grep -Eo '"https.*(kernel-|initramfs.|rootfs.)\w+(\.img)?"'
    示例输出
    "<url>/art/storage/releases/rhcos-4.17-aarch64/<release>/aarch64/rhcos-<release>-live-kernel-aarch64"
    "<url>/art/storage/releases/rhcos-4.17-aarch64/<release>/aarch64/rhcos-<release>-live-initramfs.aarch64.img"
    "<url>/art/storage/releases/rhcos-4.17-aarch64/<release>/aarch64/rhcos-<release>-live-rootfs.aarch64.img"
    "<url>/art/storage/releases/rhcos-4.17-ppc64le/49.84.202110081256-0/ppc64le/rhcos-<release>-live-kernel-ppc64le"
    "<url>/art/storage/releases/rhcos-4.17-ppc64le/<release>/ppc64le/rhcos-<release>-live-initramfs.ppc64le.img"
    "<url>/art/storage/releases/rhcos-4.17-ppc64le/<release>/ppc64le/rhcos-<release>-live-rootfs.ppc64le.img"
    "<url>/art/storage/releases/rhcos-4.17-s390x/<release>/s390x/rhcos-<release>-live-kernel-s390x"
    "<url>/art/storage/releases/rhcos-4.17-s390x/<release>/s390x/rhcos-<release>-live-initramfs.s390x.img"
    "<url>/art/storage/releases/rhcos-4.17-s390x/<release>/s390x/rhcos-<release>-live-rootfs.s390x.img"
    "<url>/art/storage/releases/rhcos-4.17/<release>/x86_64/rhcos-<release>-live-kernel-x86_64"
    "<url>/art/storage/releases/rhcos-4.17/<release>/x86_64/rhcos-<release>-live-initramfs.x86_64.img"
    "<url>/art/storage/releases/rhcos-4.17/<release>/x86_64/rhcos-<release>-live-rootfs.x86_64.img"

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

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

    • kernelrhcos-<version>-live-kernel-<architecture>

    • initramfsrhcos-<version>-live-initramfs.<architecture>.img

    • rootfsrhcos-<version>-live-rootfs.<architecture>.img

  4. rootfskernelinitramfs文件上传到您的HTTP服务器。

    如果您计划在安装完成后向集群添加更多计算机器,请不要删除这些文件。

  5. 配置网络启动基础结构,以便在RHCOS安装到机器上后,机器从本地磁盘启动。

  6. 为RHCOS镜像配置PXE安装并开始安装。

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

    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 安装启用串行控制台”。

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

    请确保在开始 OpenShift Container Platform 安装之前,每个节点上的安装都成功。观察安装过程还可以帮助确定可能出现的 RHCOS 安装问题的原因。

  8. RHCOS 安装完成后,系统将重新启动。重新启动期间,系统将应用您指定的 Ignition 配置文件。

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

    示例命令
    Ignition: ran on 2022/03/14 14:48:33 UTC (this boot)
    Ignition: user-provided config was applied
  10. 继续为您的集群创建机器。

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

    如果所需的网络、DNS 和负载均衡器基础架构已到位,则 RHCOS 节点重新启动后,OpenShift Container Platform 引导程序进程将自动开始。

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

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

在 OpenShift Container Platform 4.17 版本中,在安装过程中,您可以为已配置的节点启用多路径。RHCOS 支持在主磁盘上启用多路径。多路径提供了更强的硬件故障恢复能力,从而实现更高的主机可用性。

在初始集群创建过程中,您可能需要向所有主节点或工作节点添加内核参数。要向主节点或工作节点添加内核参数,您可以创建一个MachineConfig对象,并将该对象注入到集群设置过程中 Ignition 使用的清单文件集中。

步骤
  1. 切换到包含安装程序的目录,并为集群生成 Kubernetes 清单文件。

    $ ./openshift-install create manifests --dir <installation_directory>
  2. 确定是否要向工作节点或控制平面节点添加内核参数。

    • 创建一个机器配置文 件。例如,创建一个99-master-kargs-mpath.yaml文件,指示集群添加master标签并识别多路径内核参数。

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfig
      metadata:
        labels:
          machineconfiguration.openshift.io/role: "master"
        name: 99-master-kargs-mpath
      spec:
        kernelArguments:
          - 'rd.multipath=default'
          - 'root=/dev/disk/by-label/dm-mpath-root'
  3. 要在工作节点上启用多路径:

    • 创建一个机器配置文 件。例如,创建一个99-worker-kargs-mpath.yaml文件,指示集群添加worker标签并识别多路径内核参数。

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfig
      metadata:
        labels:
          machineconfiguration.openshift.io/role: "worker"
        name: 99-worker-kargs-mpath
      spec:
        kernelArguments:
          - 'rd.multipath=default'
          - 'root=/dev/disk/by-label/dm-mpath-root'

      您现在可以继续创建集群。

要完全启用多路径,需要执行其他安装后步骤。有关更多信息,请参阅《安装后机器配置任务》中的“在 RHCOS 上使用内核参数启用多路径”。

如果 MPIO 失败,请使用 bootlist 命令使用备用逻辑设备名称更新引导设备列表。该命令将显示引导列表,并指定系统在正常模式下引导时的可能引导设备。

  1. 要显示引导列表并指定系统在正常模式下引导时的可能引导设备,请输入以下命令:

    $ bootlist -m normal -o
    sda
  2. 要更新正常模式的引导列表并添加备用设备名称,请输入以下命令:

    $ bootlist -m normal -o /dev/sdc /dev/sdd /dev/sde
    sdc
    sdd
    sde

    如果原始引导磁盘路径不可用,则节点将从正常引导设备列表中注册的备用设备重新引导。

等待引导过程完成

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

先决条件
  • 您已为集群创建了 Ignition 配置文件。

  • 您已配置合适的网络、DNS 和负载均衡基础架构。

  • 您已获取安装程序并为您的集群生成了 Ignition 配置文件。

  • 您已在集群机器上安装 RHCOS,并提供了 OpenShift Container Platform 安装程序生成的 Ignition 配置文件。

步骤
  1. 监控引导过程

    $ ./openshift-install --dir <installation_directory> wait-for bootstrap-complete \ (1)
        --log-level=info (2)
    
    1 对于<installation_directory>,请指定您存储安装文件的目录的路径。
    2 要查看不同的安装详细信息,请指定warndebugerror代替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 服务器发出信号表明它已在控制平面机器上引导时,命令将成功。

  2. 引导过程完成后,从负载均衡器中移除引导程序机器。

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

使用 CLI 登录集群

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

先决条件
  • 您已部署了一个 OpenShift Container Platform 集群。

  • 您已安装了oc CLI。

步骤
  1. 导出kubeadmin凭据

    $ export KUBECONFIG=<installation_directory>/auth/kubeconfig (1)
    1 对于<installation_directory>,请指定您存储安装文件的目录的路径。
  2. 验证您可以使用导出的配置成功运行oc命令

    $ oc whoami
    示例输出
    system:admin

批准机器的证书签名请求

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

先决条件
  • 您已向集群添加机器。

步骤
  1. 确认集群已识别这些机器

    $ 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 之前,上述输出可能不包含计算节点(也称为工作节点)。

  2. 查看待处理的 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。

  3. 如果 CSR 未获批准,在您添加的所有机器的待处理 CSR 都处于Pending状态后,请批准集群机器的 CSR。

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

    对于在未启用机器 API 的平台(例如裸机和其他用户提供的基础设施)上运行的集群,您必须实现一种自动批准 kubelet 服务证书请求 (CSR) 的方法。如果请求未获批准,则oc execoc rshoc logs命令将无法成功,因为API服务器连接到 kubelet 时需要服务证书。任何联系 Kubelet 端点的操作都需要此证书批准到位。该方法必须监视新的 CSR,确认 CSR 是由system:nodesystem: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 可能无法使用。

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

    $ 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
    ...
  5. 如果剩余的 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
  6. 批准所有客户端和服务器 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,以便它们全部可用。

先决条件
  • 您的控制平面已初始化。

步骤
  1. 观察集群组件上线

    $ 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
  2. 配置不可用的 Operator。

禁用默认 OperatorHub 目录源

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

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

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

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

镜像注册表存储配置

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

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

提供了其他说明,说明如何在升级期间使用Recreate部署策略允许镜像注册表使用块存储类型。

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

要启动镜像注册表,您必须将镜像注册表 Operator 配置的managementStateRemoved更改为Managed

步骤
  • managementState镜像注册表 Operator 配置从Removed更改为Managed。例如:

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

为 IBM Power 配置注册表存储

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

先决条件
  • 您可以作为具有cluster-admin角色的用户访问集群。

  • 您在 IBM Power® 上有一个集群。

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

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

  • 必须具有 100Gi 容量。

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

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

  2. 验证您没有注册表 pod。

    $ oc get pod -n openshift-image-registry -l docker-registry=default
    示例输出
    No resources found in openshift-image-registry namespace

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

  3. 检查注册表配置

    $ oc edit configs.imageregistry.operator.openshift.io
    示例输出
    storage:
      pvc:
        claim:

    claim字段留空以允许自动创建image-registry-storage PVC。

  4. 检查clusteroperator状态

    $ oc get clusteroperator image-registry
    示例输出
    NAME             VERSION              AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
    image-registry   4.17                 True        False         False      6h50m
  5. 确保您的注册表设置为已管理,以启用镜像的构建和推送。

    • 运行

      $ oc edit configs.imageregistry/cluster

      然后,更改这一行:

      managementState: Removed

      为:

      managementState: Managed

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

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

步骤
  • 要将镜像注册表存储设置为空目录:

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

    仅为非生产集群配置此选项。

    如果您在镜像注册表 Operator 初始化其组件之前运行此命令,则oc patch命令将失败并出现以下错误:

    Error from server (NotFound): configs.imageregistry.operator.openshift.io "cluster" not found

    等待几分钟,然后再次运行该命令。

完成在用户提供的基础设施上的安装

完成 Operator 配置后,您可以完成在您提供基础设施上的集群安装。

先决条件
  • 您的控制平面已初始化。

  • 您已完成初始 Operator 配置。

步骤
  1. 使用以下命令确认所有集群组件都已上线:

    $ 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...

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

    • 安装程序生成的 Ignition 配置文件包含会在 24 小时后过期的证书,届时会自动续期。如果集群在证书续期前关闭,并在 24 小时后重新启动,集群会自动恢复已过期的证书。例外情况是,您必须手动批准待处理的 node-bootstrapper 证书签名请求 (CSR) 以恢复 kubelet 证书。有关更多信息,请参阅已过期控制平面证书的恢复文档。

    • 建议您在生成 Ignition 配置文件后 12 小时内使用它们,因为 24 小时证书会在集群安装后 16 到 22 小时之间轮换。通过在 12 小时内使用 Ignition 配置文件,您可以避免在安装期间运行证书更新时安装失败。

  2. 确认 Kubernetes API 服务器能够与 Pod 通信。

    1. 要查看所有 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
      ...
    2. 使用以下命令查看先前命令输出中列出的 Pod 的日志

      $ oc logs <pod_name> -n <namespace> (1)
      1 指定 Pod 名称和命名空间,如先前命令的输出所示。

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

  3. 启用多路径需要执行其他步骤。安装过程中请勿启用多路径。

    有关更多信息,请参阅安装后机器配置任务文档中的“在 RHCOS 上使用内核参数启用多路径”。

  4. 集群注册 页面上注册您的集群。

后续步骤