×

先决条件

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® 实例上,设置:

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

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

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

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® 实例上,设置:

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

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

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

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 配置文件。

在初始启动期间,机器需要通过 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 服务器同步时钟。

用户自建 DNS 要求

在 OpenShift Container Platform 部署中,DNS 名称解析对于以下组件是必需的:

  • Kubernetes API

  • OpenShift Container Platform 应用通配符

  • 引导程序、控制平面和计算机器

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

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

建议使用 DHCP 服务器为每个集群节点提供主机名。有关更多信息,请参见《用户自建基础设施的 DHCP 建议》一节。

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

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

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

引导程序机器

bootstrap.<cluster_name>.<base_domain>.

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

控制平面机器

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

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

计算机器

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

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

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

您可以使用dig命令验证名称和反向名称解析。有关详细的验证步骤,请参见《验证用户自建基础设施的 DNS 解析》一节。

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

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

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

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

以下示例是一个 BIND 区域文件,它显示了用户自建集群中名称解析的样本 A 记录。

示例 DNS 区域数据库
$TTL 1W
@	IN	SOA	ns1.example.com.	root (
			2019070700	; serial
			3H		; refresh (3 hours)
			30M		; retry (30 minutes)
			2W		; expiry (2 weeks)
			1W )		; minimum (1 week)
	IN	NS	ns1.example.com.
	IN	MX 10	smtp.example.com.
;
;
ns1.example.com.		IN	A	192.168.1.5
smtp.example.com.		IN	A	192.168.1.5
;
helper.example.com.		IN	A	192.168.1.5
helper.ocp4.example.com.	IN	A	192.168.1.5
;
api.ocp4.example.com.		IN	A	192.168.1.5 (1)
api-int.ocp4.example.com.	IN	A	192.168.1.5 (2)
;
*.apps.ocp4.example.com.	IN	A	192.168.1.5 (3)
;
bootstrap.ocp4.example.com.	IN	A	192.168.1.96 (4)
;
control-plane0.ocp4.example.com.	IN	A	192.168.1.97 (5)
control-plane1.ocp4.example.com.	IN	A	192.168.1.98 (5)
control-plane2.ocp4.example.com.	IN	A	192.168.1.99 (5)
;
compute0.ocp4.example.com.	IN	A	192.168.1.11 (6)
compute1.ocp4.example.com.	IN	A	192.168.1.7 (6)
;
;EOF
1 提供 Kubernetes API 的名称解析。该记录指向 API 负载均衡器的 IP 地址。
2 提供 Kubernetes API 的名称解析。该记录指向 API 负载均衡器的 IP 地址,并用于集群内部通信。
3 提供通配符路由的名称解析。该记录指向应用程序 Ingress 负载均衡器的 IP 地址。应用程序 Ingress 负载均衡器指向运行 Ingress Controller Pod 的机器。默认情况下,Ingress Controller Pod 运行在计算机器上。

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

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 和应用程序 Ingress 负载均衡基础设施。在生产环境中,您可以分别部署 API 和应用程序 Ingress 负载均衡器,以便您可以独立地扩展每个负载均衡器的基础设施。

如果您想使用 Red Hat Enterprise Linux (RHEL) 实例部署 API 和应用程序 Ingress 负载均衡器,则必须单独购买 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. 应用程序 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配置。本示例并非旨在就选择一种负载均衡解决方案而不是另一种解决方案提供建议。

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

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

示例 API 和应用程序 Ingress 负载均衡器配置
global
  log         127.0.0.1 local2
  pidfile     /var/run/haproxy.pid
  maxconn     4000
  daemon
defaults
  mode                    http
  log                     global
  option                  dontlognull
  option http-server-close
  option                  redispatch
  retries                 3
  timeout http-request    10s
  timeout queue           1m
  timeout connect         10s
  timeout client          1m
  timeout server          1m
  timeout http-keep-alive 10s
  timeout check           10s
  maxconn                 3000
listen api-server-6443 (1)
  bind *:6443
  mode tcp
  option  httpchk GET /readyz HTTP/1.0
  option  log-health-checks
  balance roundrobin
  server bootstrap bootstrap.ocp4.example.com:6443 verify none check check-ssl inter 10s fall 2 rise 3 backup (2)
  server master0 master0.ocp4.example.com:6443 weight 1 verify none check check-ssl inter 10s fall 2 rise 3
  server master1 master1.ocp4.example.com:6443 weight 1 verify none check check-ssl inter 10s fall 2 rise 3
  server master2 master2.ocp4.example.com:6443 weight 1 verify none check check-ssl inter 10s fall 2 rise 3
listen machine-config-server-22623 (3)
  bind *:22623
  mode tcp
  server bootstrap bootstrap.ocp4.example.com:22623 check inter 1s backup (2)
  server master0 master0.ocp4.example.com:22623 check inter 1s
  server master1 master1.ocp4.example.com:22623 check inter 1s
  server master2 master2.ocp4.example.com:22623 check inter 1s
listen ingress-router-443 (4)
  bind *:443
  mode tcp
  balance source
  server compute0 compute0.ocp4.example.com:443 check inter 1s
  server compute1 compute1.ocp4.example.com:443 check inter 1s
listen ingress-router-80 (5)
  bind *:80
  mode tcp
  balance source
  server compute0 compute0.ocp4.example.com:80 check inter 1s
  server compute1 compute1.ocp4.example.com:80 check inter 1s
1 端口6443处理 Kubernetes API 流量并指向控制平面机器。
2 OpenShift Container Platform 集群安装之前必须存在引导条目,并且在引导过程完成后必须将其删除。
3 端口22623处理机器配置服务器流量并指向控制平面机器。
4 端口443处理 HTTPS 流量并指向运行 Ingress Controller Pod 的机器。默认情况下,Ingress Controller Pod 运行在计算机器上。
5 端口80处理 HTTP 流量并指向运行 Ingress Controller Pod 的机器。默认情况下,Ingress Controller Pod 运行在计算机器上。

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

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

准备用户自建基础设施

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

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

准备工作完成后,您的集群基础设施必须满足《用户自备基础设施集群要求》一节中列出的要求。

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

    1. 为节点添加持久 IP 地址到您的 DHCP 服务器配置中。在您的配置中,将相关网络接口的 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 控制器相关的统计信息和指标。

  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` 目录中。

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

  2. 查看 SSH 公钥

    $ cat <path>/<file_name>.pub

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

    $ cat ~/.ssh/id_ed25519.pub
  3. 如果尚未添加,请将 SSH 私钥身份添加到本地用户的 SSH 代理。SSH 代理管理密钥是无需密码的 SSH 身份验证到集群节点所必需的,或者如果您想使用 `./openshift-install gather` 命令。

    在某些发行版中,默认的 SSH 私钥身份(例如 `~/.ssh/id_rsa` 和 `~/.ssh/id_dsa`)会自动管理。

    1. 如果本地用户的 `ssh-agent` 进程尚未运行,请将其作为后台任务启动:

      $ eval "$(ssh-agent -s)"
      示例输出
      Agent pid 31874

      如果您的集群处于 FIPS 模式,则只能使用符合 FIPS 的算法生成 SSH 密钥。密钥必须是 RSA 或 ECDSA。

  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 公钥。

获取安装程序

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

先决条件
  • 您需要一台运行 Linux 或 macOS 的计算机,并具有 500 MB 的本地磁盘空间。

步骤
  1. 访问 Red Hat Hybrid Cloud Console 上的 集群类型 页面。如果您有 Red Hat 帐户,请使用您的凭据登录。如果没有,请创建一个帐户。

  2. 从页面中的“自行运行”部分选择您的基础设施提供商。

  3. 从“OpenShift 安装程序”下的下拉菜单中选择您的主机操作系统和架构,然后单击“下载安装程序”。

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

    • 安装程序会在您用于安装集群的计算机上创建多个文件。您必须保留安装程序以及安装程序在您完成集群安装后创建的文件。这两个文件都是删除集群所必需的。

    • 即使集群在安装过程中失败,删除安装程序创建的文件也不会删除您的集群。要删除您的集群,请完成针对您的特定云提供商的 OpenShift Container Platform 卸载过程。

  5. 解压安装程序。例如,在使用 Linux 操作系统的计算机上,运行以下命令:

    $ tar -xvf openshift-install-linux.tar.gz
  6. 从 Red Hat OpenShift 集群管理器下载您的安装 pull secret。此 pull secret 允许您使用包含的授权机构(包括 Quay.io,它提供 OpenShift Container Platform 组件的容器镜像)提供的服务进行身份验证。

或者,您可以从 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`)二进制文件。

步骤
  1. 导航到 Red Hat 客户门户上的 OpenShift Container Platform 下载页面

  2. 从“产品变体”下拉列表中选择架构。

  3. 从“版本”下拉列表中选择相应的版本。

  4. 单击“OpenShift v4.17 Linux 客户机”条目旁边的“立即下载”并保存文件。

  5. 解压归档文件

    $ tar xvf <file>
  6. 将 `oc` 二进制文件放在 `PATH` 上的目录中。

    要检查您的 `PATH`,请执行以下命令:

    $ echo $PATH
验证
  • 安装 OpenShift CLI 后,可以使用 `oc` 命令。

    $ oc <command>

在 Windows 上安装 OpenShift CLI

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

步骤
  1. 导航到 Red Hat 客户门户上的 OpenShift Container Platform 下载页面

  2. 从“版本”下拉列表中选择相应的版本。

  3. 单击“OpenShift v4.17 Windows 客户机”条目旁边的“立即下载”并保存文件。

  4. 使用 ZIP 程序解压缩归档文件。

  5. 将 `oc` 二进制文件移动到 `PATH` 上的目录中。

    要检查您的 `PATH`,请打开命令提示符并执行以下命令:

    C:\> path
验证
  • 安装 OpenShift CLI 后,可以使用 `oc` 命令。

    C:\> oc <command>

在 macOS 上安装 OpenShift CLI

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

步骤
  1. 导航到 Red Hat 客户门户上的 OpenShift Container Platform 下载页面

  2. 从“版本”下拉列表中选择相应的版本。

  3. 单击“OpenShift v4.17 macOS 客户机”条目旁边的“立即下载”并保存文件。

    对于 macOS arm64,请选择“OpenShift v4.17 macOS arm64 客户机”条目。

  4. 解压归档文件。

  5. 将 `oc` 二进制文件移动到 PATH 上的目录中。

    要检查您的 `PATH`,请打开终端并执行以下命令:

    $ echo $PATH
验证
  • 使用 `oc` 命令验证您的安装

    $ oc <command>

手动创建安装配置文件

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

先决条件
  • 您在本地机器上有一个 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": ...}' (13)
sshKey: 'ssh-ed25519 AAAA...' (14)
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 来自 Red Hat OpenShift 集群管理器 的pull 密钥。此 pull 密钥允许您对包含的授权机构(包括提供 OpenShift Container Platform 组件容器映像的 Quay.io)提供的服务进行身份验证。
14 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[].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证书。集群网络操作符(Cluster Network Operator)随后会创建一个trusted-ca-bundle config map,将这些内容与Red Hat Enterprise Linux CoreOS (RHCOS)信任捆绑包合并,并且此config map在Proxy对象的trustedCA字段中引用。除非代理的身份证书由RHCOS信任捆绑包中的机构签名,否则需要additionalTrustBundle字段。
    5 可选:确定Proxy对象的配置以在trustedCA字段中引用user-ca-bundle config map 的策略。允许的值为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 对象
字段 类型 描述

type

字符串

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

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服务器。用syslog服务器的主机和端口替换<host>:<port>

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 小时内使用它们,因为在集群安装后 16 到 22 小时之间会进行 24 小时证书轮换。在 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@..` 来访问这些节点,前提是您拥有与您在 `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=`)。如果设置静态 IP,则必须在每个节点上标识 DNS 服务器 IP 地址(`nameserver=`)。以下示例设置

  • 节点的 IP 地址为 `10.10.10.2`

  • 网关地址为 `10.10.10.254`

  • 子网掩码为 `255.255.255.0`

  • 主机名为 `core0.example.com`

  • DNS 服务器地址为 `4.4.4.41`

  • 自动配置值为 `none`。静态配置 IP 网络时不需要自动配置。

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

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

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

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

  • 节点的 IP 地址为 `10.10.10.2`

  • 网关地址为 `10.10.10.254`

  • 子网掩码为 `255.255.255.0`

  • DNS 服务器地址为 `4.4.4.41`

  • 自动配置值为 `none`。静态配置 IP 网络时不需要自动配置。

ip=10.10.10.2::10.10.10.254:255.255.255.0::enp1s0:none
nameserver=4.4.4.41
指定多个网络接口

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

ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp1s0:none
ip=10.10.10.3::10.10.10.254:255.255.255.0:core0.example.com:enp2s0:none
配置默认网关和路由

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

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

  • 运行以下命令配置默认网关

    ip=::10.10.10.254::::
  • 输入以下命令配置附加网络的路由

    rd.route=20.20.20.0/24:20.20.20.254:enp2s0
禁用单个接口上的 DHCP

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

ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp1s0:none
ip=::::core0.example.com:enp2s0:none
组合 DHCP 和静态 IP 配置

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

ip=enp1s0:dhcp
ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp2s0:none
在单个接口上配置 VLAN

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

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

    ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp2s0.100:none
    vlan=enp2s0.100:enp2s0
  • 要在网络接口上配置 VLAN 并使用 DHCP,请运行以下命令

    ip=enp2s0.100:dhcp
    vlan=enp2s0.100:enp2s0
提供多个 DNS 服务器

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

nameserver=1.1.1.1
nameserver=8.8.8.8
将多个网络接口绑定到单个接口

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

  • 配置绑定接口的语法为:`bond=[:][:options]`

    `` 是绑定设备名称(`bond0`),`` 表示物理(以太网)接口的逗号分隔列表(`em1,em2`),而 *options* 是绑定选项的逗号分隔列表。输入 `modinfo bonding` 以查看可用的选项。

  • 使用 `bond=` 创建绑定接口时,必须指定如何分配 IP 地址以及绑定接口的其他信息。

    • 要将绑定接口配置为使用 DHCP,请将绑定的 IP 地址设置为 `dhcp`。例如

      bond=bond0:em1,em2:mode=active-backup
      ip=bond0:dhcp
    • 要将绑定接口配置为使用静态 IP 地址,请输入所需的特定 IP 地址和相关信息。例如

      bond=bond0:em1,em2:mode=active-backup
      ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:bond0:none
将多个 SR-IOV 网络接口绑定到双端口 NIC 接口

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

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

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

  2. 按照 配置网络绑定 中的指导创建绑定,将所需的 VF 附加到绑定并设置绑定链路状态。

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

  • 配置绑定接口的语法为 `bond=[:][: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

使用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镜像站点获取安装操作系统实例所需的首选方法所需的RHCOS kernelinitramfsrootfs文件,但推荐的方式是从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版本的最高版本镜像。此过程中,仅使用下面描述的适当kernelinitramfsrootfs构件。此安装类型不支持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

  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@..` 来访问这些节点,前提是您拥有与您在 `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配置文件。

  • 您的机器具有直接的互联网访问权限或可以使用HTTP或HTTPS代理。

步骤
  1. 监控引导过程

    $ ./openshift-install --dir <installation_directory> wait-for bootstrap-complete \ (1)
        --log-level=info (2)
    
    1 对于<安装目录>,请指定您存储安装文件的目录路径。
    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 对于<安装目录>,请指定您存储安装文件的目录路径。
  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,并确保您看到为添加到集群的每台机器的客户端请求的PendingApproved状态。

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

镜像注册表存储配置

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

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

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

为 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

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

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

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

    $ 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

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

完成用户自备基础设施上的安装

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

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

  • 您已完成初始操作符配置。

步骤
  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 对于<安装目录>,请指定您存储安装文件的目录路径。
    示例输出
    INFO Waiting up to 30m0s for the cluster to initialize...

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

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

    • 建议您在生成 Ignition 配置文件后 12 小时内使用它们,因为在集群安装后 16 到 22 小时之间会进行 24 小时证书轮换。在 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 上使用内核参数启用多路径”。

OpenShift Container Platform 的遥测访问

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

确认您的OpenShift 集群管理器清单正确后(由遥测自动维护或使用 OpenShift 集群管理器手动维护),使用订阅监控跟踪您在帐户或多集群级别的 OpenShift Container Platform 订阅。

其他资源