在裸机上安装


OpenShift Container Platform 4.19

在裸机上安装 OpenShift Container Platform

Red Hat OpenShift Documentation Team

摘要

本文档论述了如何在裸机上安装 OpenShift Container Platform。

第 1 章 准备裸机集群安装

1.1. 先决条件

1.2. 为 OpenShift Virtualization 规划裸机集群

如果使用 OpenShift Virtualization,必须在安装裸机集群前了解一些要求。

  • 如果要使用实时迁移功能,在集群安装时需要有多个 worker 节点。这是因为实时迁移需要集群级别的高可用性 (HA) 标记设置为 true。当安装集群时,会设置 HA 标志,之后无法更改。如果在安装集群时定义少于两个 worker 节点,则集群生命周期中的 HA 标记被设置为 false。

    注意

    您可以在单节点集群中安装 OpenShift Virtualization,但单节点 OpenShift 不支持高可用性。

  • 实时迁移需要共享存储。OpenShift Virtualization 的存储必须支持并使用 ReadWriteMany (RWX) 访问模式。
  • 如果您计划使用单根 I/O 虚拟化 (SR-IOV),请确保 OpenShift Container Platform 支持网络接口控制器 (NIC)。

1.3. SR-IOV 设备的 NIC 分区

OpenShift Container Platform 可以部署到具有双端口网络接口卡(NIC)的服务器上。您可以将单个、高速的双端口 NIC 分区到多个虚拟功能 (VF) 并启用 SR-IOV。

此功能支持使用绑定来实现链路聚合控制协议 (LACP) 的高可用性。

注意

物理 NIC 只能声明一个 LACP。

OpenShift Container Platform 集群可以使用以下方法之一部署到 2 个物理功能 (PF)上带有 2 个 VF 的绑定接口中:

  • 基于代理的安装程序

    注意

    nmstate 的最低所需版本是:

    • 1.4.2-4 对于 RHEL 8 版本
    • 2.2.7 对于 RHEL 9 版本
  • 安装程序置备的基础架构安装
  • 用户置备的基础架构安装

OpenShift Container Platform 安装程序提供四个部署集群的方法:

  • 交互式 :您可以使用基于 Web 的 辅助安装程序(Assisted Installer)部署集群。这是使用连接到互联网的网络的集群推荐的方法。Assisted Installer 是安装 OpenShift Container Platform 的最简单方法,它提供智能默认值,并在安装集群前执行预动态验证。它还提供了一个 RESTful API 用于自动化和高级配置场景。
  • 本地基于代理的: 您可以使用 基于代理的安装程序为 air- gapped 或受限网络在本地部署集群。它提供了 Assisted Installer 的许多优点,但您必须首先下载并配置基于代理的安装程序。使用命令行界面完成配置。这个方法对于 air-gapped 或受限网络是一个理想的方法。
  • 自动 :您可以在安装程序置备的基础架构中部署集群及其维护的集群。安装程序使用每个集群主机的基板管理控制器 (BMC) 进行置备。您可以使用连接的网络或 air-gapped 网络或受限网络部署集群。
  • 完全控制:您可以在自己准备和维护的基础架构上部署集群,这种方法提供了最大的定制性。您可以使用连接的网络或 air-gapped 网络或受限网络部署集群。

集群有以下特征:

  • 默认提供无单点故障的高可用性基础架构。
  • 管理员可以控制要应用的更新内容和时间。

如需有关安装程序置备和用户置备的安装过程的更多信息,请参阅 安装过程。

1.4.1. 在安装程序置备的基础架构上安装集群

您可以使用以下方法在 OpenShift Container Platform 安装程序置备的裸机基础架构上安装集群:

在裸机上安装安装程序置备的集群
您可以使用安装程序置备在裸机上安装 OpenShift Container Platform。

1.4.2. 在用户置备的基础架构上安装集群

您可以使用以下方法之一在您置备的裸机基础架构上安装集群:

在裸机上安装用户置备的集群
您可以在您置备的裸机基础架构上安装 OpenShift Container Platform。对于包含用户置备的基础架构的集群,您必须部署所有所需的机器。
使用自定义网络安装用户置备的裸机集群
您可以使用网络自定义在用户置备的基础架构上安装裸机集群。通过自定义网络配置,您的集群可以与环境中现有的 IP 地址分配共存,并与现有的 MTU 和 VXLAN 配置集成。大多数网络自定义必须在安装阶段应用。
在受限网络中安装用户置备的裸机集群
您可以使用镜像 registry 在受限或断开连接的网络中安装用户置备的裸机集群。您还可以使用此安装方法来确保集群只使用满足您组织对外部内容控制的容器镜像。

第 2 章 用户置备的基础架构

2.1. 在裸机上安装用户置备的集群

在 OpenShift Container Platform 4.19 中,您可以在您置备的裸机基础架构上安装集群。

重要

虽然您可能能够按照以下步骤在虚拟化或云环境中部署集群,但您必须了解非裸机平台的其他注意事项。在尝试在此类环境中安装 OpenShift Container Platform 集群前,请参阅有关在未经测试的平台上部署 OpenShift Container Platform 的指南 中的信息。

2.1.1. 先决条件

2.1.2. OpenShift Container Platform 互联网访问

在 OpenShift Container Platform 4.19 中,您需要访问互联网来安装集群。

您需要连接到互联网才能执行以下操作:

  • 访问 OpenShift Cluster Manager 以下载安装程序并执行订阅管理。如果集群可以访问互联网,并且没有禁用 Telemetry,该服务会自动授权您的集群。
  • 访问 Quay.io,以获取安装集群所需的软件包。
  • 获取执行集群更新所需的软件包。
重要

如果您的集群无法直接访问互联网,则可以在置备的某些类型的基础架构上执行受限网络安装。在此过程中,您可以下载所需的内容,并使用它为镜像 registry 填充安装软件包。对于某些安装类型,集群要安装到的环境不需要访问互联网。在更新集群前,您要更新镜像 registry 的内容。

2.1.3. 具有用户置备基础架构的集群的要求

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

本节论述了在用户置备的基础架构上部署 OpenShift Container Platform 的要求。

2.1.3.1. 集群安装所需的机器

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

Expand
表 2.1. 最低所需的主机
主机描述

一个临时 bootstrap 机器

集群需要 bootstrap 机器在三台 control plane 机器上部署 OpenShift Container Platform 集群。您可在安装集群后删除 bootstrap 机器。

三台 control plane 机器

control plane 机器运行组成 control plane 的 Kubernetes 和 OpenShift Container Platform 服务。

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

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

注意

作为例外,您可以在裸机集群中运行零台计算机器,它们仅由三台 control plane 机器组成。这为集群管理员和开发人员提供了更小、效率更高的集群,用于测试、开发和生产。不支持运行一台计算机器。

重要

要保持集群的高可用性,请将独立的物理主机用于这些集群机器。

bootstrap 和 control plane 机器必须使用 Red Hat Enterprise Linux CoreOS(RHCOS)作为操作系统。但是,计算机器可以在 Red Hat Enterprise Linux CoreOS(RHCOS)、Red Hat Enterprise Linux(RHEL) 8.6 和更高的版本。

请注意,RHCOS 基于 Red Hat Enterprise Linux(RHEL) 9.2,并继承其所有硬件认证和要求。查看 红帽企业 Linux 技术功能和限制

2.1.3.2. 集群安装的最低资源要求

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

Expand
表 2.2. 最低资源要求
机器操作系统CPU [1]RAMStorage每秒输入/输出 (IOPS) [2]

bootstrap

RHCOS

4

16 GB

100 GB

300

Control plane(控制平面)

RHCOS

4

16 GB

100 GB

300

Compute

RHCOS、RHEL 8.6 及更新版本 [3]

2

8 GB

100 GB

300

  1. 当未启用并发多线程 (SMT) 或超线程时,一个 CPU 相当于一个物理内核。启用后,使用以下公式来计算对应的比例:(每个内核数的线程)× sockets = CPU。
  2. OpenShift Container Platform 和 Kubernetes 对磁盘性能非常敏感,建议使用更快的存储速度,特别是 control plane 节点上需要 10 ms p99 fsync 持续时间的 etcd。请注意,在许多云平台上,存储大小和 IOPS 可一起扩展,因此您可能需要过度分配存储卷来获取足够的性能。
  3. 与所有用户置备的安装一样,如果您选择在集群中使用 RHEL 计算机器,则负责所有操作系统生命周期管理和维护,包括执行系统更新、应用补丁和完成所有其他必要的任务。RHEL 7 计算机器的使用已弃用,并已在 OpenShift Container Platform 4.10 及更新的版本中删除。
注意

对于 OpenShift Container Platform 版本 4.19,RHCOS 基于 RHEL 版本 9.6,它会更新微架构要求。以下列表包含每个架构需要的最小指令集架构 (ISA):

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

如需更多信息,请参阅 架构 (RHEL 文档)。

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

2.1.3.3. 证书签名请求管理

在使用您置备的基础架构时,集群只能有限地访问自动机器管理,因此您必须提供一种在安装后批准集群证书签名请求 (CSR) 的机制。kube-controller-manager 只能批准 kubelet 客户端 CSR。machine-approver 无法保证使用 kubelet 凭证请求的提供证书的有效性,因为它不能确认是正确的机器发出了该请求。您必须决定并实施一种方法,以验证 kubelet 提供证书请求的有效性并进行批准。

2.1.3.4. vSphere 上裸机集群的要求

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

2.1.3.5. 用户置备的基础架构对网络的要求

所有 Red Hat Enterprise Linux CoreOS(RHCOS)机器都需要在启动时在 initramfs 中配置联网,以获取它们的 Ignition 配置文件。

在初次启动过程中,机器需要 IP 地址配置,该配置通过 DHCP 服务器或静态设置,提供所需的引导选项。建立网络连接后,机器会从 HTTP 或 HTTPS 服务器下载 Ignition 配置文件。然后,Ignition 配置文件用于设置每台机器的确切状态。Machine Config Operator 在安装后完成对机器的更多更改,如应用新证书或密钥。

注意
  • 建议使用 DHCP 服务器对集群机器进行长期管理。确保 DHCP 服务器已配置为向集群机器提供持久的 IP 地址、DNS 服务器信息和主机名。
  • 如果用户置备的基础架构没有 DHCP 服务,您可以在 RHCOS 安装时向节点提供 IP 网络配置和 DNS 服务器地址。如果要从 ISO 镜像安装,这些参数可作为引导参数传递。如需有关静态 IP 置备和高级网络选项的更多信息,请参阅 安装 RHCOS 并启动 OpenShift Container Platform bootstrap 过程 部分。

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

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

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

另外,通过 DHCP 设置主机名可以绕过实施 DNS split-horizon 的环境中的手动 DNS 记录名称配置错误。

2.1.3.5.2. 网络连接要求

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

本节详细介绍了所需的端口。

重要

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

Expand
表 2.3. 用于全机器到所有机器通信的端口
协议port描述

ICMP

N/A

网络可访问性测试

TCP

1936

指标

9000-9999

主机级别的服务,包括端口 9 100-9101 上的节点导出器,以及端口 9099 上的 Cluster Version Operator。

10250-10259

Kubernetes 保留的默认端口

22623

端口处理来自 Machine Config 服务器的流量,并将流量定向到 control plane 机器。

UDP

4789

VXLAN

6081

Geneve

9000-9999

主机级别的服务,包括端口 91009101 上的节点导出器。

500

IPsec IKE 数据包

4500

IPsec NAT-T 数据包

123

UDP 端口 123 上的网络时间协议 (NTP)如果配置了外部 NTP 时间服务器,需要打开 UDP 端口 123

TCP/UDP

30000-32767

Kubernetes 节点端口

ESP

N/A

IPsec Encapsulating Security Payload(ESP)

Expand
表 2.4. 用于所有机器控制平面通信的端口
协议port描述

TCP

6443

Kubernetes API

Expand
表 2.5. control plane 机器用于 control plane 机器通信的端口
协议port描述

TCP

2379-2380

etcd 服务器和对等端口

2.1.3.5.3. 用户置备的基础架构的 NTP 配置

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

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

2.1.3.6. 用户置备的 DNS 要求

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

  • The Kubernetes API
  • OpenShift Container Platform 应用程序通配符
  • bootstrap、control plane 和计算机器

Kubernetes API、bootstrap 机器、control plane 机器和计算机器也需要反向 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>.

Expand
表 2.6. 所需的 DNS 记录
组件记录描述

Kubernetes API

api.<cluster_name>.<base_domain>.

DNS A/AAAA 或 CNAME 记录,以及用于标识 API 负载均衡器的 DNS PTR 记录。这些记录必须由集群外的客户端和集群中的所有节点解析。

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

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

重要

API 服务器必须能够根据 Kubernetes 中记录的主机名解析 worker 节点。如果 API 服务器无法解析节点名称,则代理的 API 调用会失败,且您无法从 pod 检索日志。

Routes

*.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 机器

bootstrap.<cluster_name>.<base_domain>.

DNS A/AAAA 或 CNAME 记录,以及用于标识 bootstrap 机器的 DNS PTR 记录。这些记录必须由集群中的节点解析。

control plane 机器

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

DNS A/AAAA 或 CNAME 记录,以识别 control plane 节点的每台机器。这些记录必须由集群中的节点解析。

计算机器

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

DNS A/AAAA 或 CNAME 记录,用于识别 worker 节点的每台机器。这些记录必须由集群中的节点解析。

注意

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

提示

您可以使用 dig 命令验证名称和反向名称解析。如需了解详细的 验证步骤,请参阅为用户置备的基础架构验证 DNS 解析 一节。

2.1.3.6.1. 用户置备的集群的 DNS 配置示例

本节提供 A 和 PTR 记录配置示例,它们满足了在用户置备的基础架构上部署 OpenShift Container Platform 的 DNS 要求。样本不是为选择一个 DNS 解决方案提供建议。

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

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

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

例 2.1. 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 
6

control-plane2.ocp4.example.com.	IN	A	192.168.1.99 
7

;
compute0.ocp4.example.com.	IN	A	192.168.1.11 
8

compute1.ocp4.example.com.	IN	A	192.168.1.7 
9

;
;EOF
Copy to Clipboard Toggle word wrap
1
为 Kubernetes API 提供名称解析。记录引用 API 负载均衡器的 IP 地址。
2
为 Kubernetes API 提供名称解析。记录引用 API 负载均衡器的 IP 地址,用于内部集群通信。
3
为通配符路由提供名称解析。记录引用应用程序入口负载均衡器的 IP 地址。应用程序入口负载均衡器以运行 Ingress Controller Pod 的机器为目标。默认情况下,Ingress Controller Pod 在计算机器上运行。
注意

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

4
为 bootstrap 机器提供名称解析。
5 6 7
为 control plane 机器提供名称解析。
8 9
为计算机器提供名称解析。

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

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

例 2.2. 反向记录的 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. 
5

99.1.168.192.in-addr.arpa.	IN	PTR	control-plane2.ocp4.example.com. 
6

;
11.1.168.192.in-addr.arpa.	IN	PTR	compute0.ocp4.example.com. 
7

7.1.168.192.in-addr.arpa.	IN	PTR	compute1.ocp4.example.com. 
8

;
;EOF
Copy to Clipboard Toggle word wrap
1
为 Kubernetes API 提供反向 DNS 解析。PTR 记录引用 API 负载均衡器的记录名称。
2
为 Kubernetes API 提供反向 DNS 解析。PTR 记录引用 API 负载均衡器的记录名称,用于内部集群通信。
3
为 bootstrap 机器提供反向 DNS 解析。
4 5 6
为 control plane 机器提供反向 DNS 解析。
7 8
为计算机器提供反向 DNS 解析。
注意

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

2.1.3.7. 用户置备的基础架构的负载均衡要求

在安装 OpenShift Container Platform 前,您必须置备 API 和应用程序入口负载均衡基础架构。在生产环境中,您可以单独部署 API 和应用程序入口负载均衡器,以便可以隔离扩展每个负载均衡器基础架构。

注意

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

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

  1. API 负载均衡器 :提供一个通用端点,供用户(包括人工和机器)与平台交互和配置。配置以下条件:

    • 仅第 4 层负载均衡.这可被称为 Raw TCP 或 SSL Passthrough 模式。
    • 无状态负载平衡算法。这些选项根据负载均衡器的实施而有所不同。
    重要

    不要为 API 负载均衡器配置会话持久性。为 Kubernetes API 服务器配置会话持久性可能会导致出现过量 OpenShift Container Platform 集群应用程序流量,以及过量的在集群中运行的 Kubernetes API。

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

    Expand
    表 2.7. API 负载均衡器
    port后端机器(池成员)internal外部描述

    6443

    Bootstrap 和 control plane.bootstrap 机器初始化集群 control plane 后,您要从负载均衡器中删除 bootstrap 机器。您必须为 API 服务器健康检查探测配置 /readyz 端点。

    X

    X

    Kubernetes API 服务器

    22623

    Bootstrap 和 control plane.bootstrap 机器初始化集群 control plane 后,您要从负载均衡器中删除 bootstrap 机器。

    X

     

    机器配置服务器

    注意

    负载均衡器必须配置为,从 API 服务器关闭 /readyz 端点到从池中移除 API 服务器实例时最多需要 30 秒。在 /readyz 返回错误或健康后的时间范围内,端点必须被删除或添加。每 5 秒或 10 秒探测一次,有两个成功请求处于健康状态,三个成为不健康的请求是经过良好测试的值。

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

    配置以下条件:

    • 仅第 4 层负载均衡.这可被称为 Raw TCP 或 SSL Passthrough 模式。
    • 建议根据可用选项以及平台上托管的应用程序类型,使用基于连接的或基于会话的持久性。
    提示

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

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

    Expand
    表 2.8. 应用程序入口负载均衡器
    port后端机器(池成员)internal外部描述

    443

    默认情况下,运行 Ingress Controller Pod、计算或 worker 的机器。

    X

    X

    HTTPS 流量

    80

    默认情况下,运行 Ingress Controller Pod、计算或 worker 的机器。

    X

    X

    HTTP 流量

    注意

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

本节提供了一个满足用户置备集群的负载均衡要求的 API 和应用程序入口负载均衡器配置示例。示例是 HAProxy 负载均衡器的 /etc/haproxy/haproxy.cfg 配置。这个示例不是为选择一个负载平衡解决方案提供建议。

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

注意

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

例 2.3. 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 
4

  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 
5

  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 
6

  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
Copy to Clipboard Toggle word wrap
1
端口 6443 处理 Kubernetes API 流量并指向 control plane 机器。
2 4
bootstrap 条目必须在 OpenShift Container Platform 集群安装前就位,且必须在 bootstrap 过程完成后删除它们。
3
端口 22623 处理机器配置服务器流量并指向 control plane 机器。
5
端口 443 处理 HTTPS 流量,并指向运行 Ingress Controller pod 的机器。默认情况下,Ingress Controller Pod 在计算机器上运行。
6
端口 80 处理 HTTP 流量,并指向运行 Ingress Controller pod 的机器。默认情况下,Ingress Controller Pod 在计算机器上运行。
注意

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

提示

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

除了使用 configure-ovs.sh shell 脚本在裸机平台上设置 br-ex 网桥的替代选择,您可以创建一个包括 NMState 配置文件的 MachineConfig 对象。主机 nmstate-configuration.servicenmstate.service 将 NMState 配置文件应用到集群中运行的每个节点。

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

  • 您需要对网桥进行安装后更改,如更改 Open vSwitch (OVS) 或 OVN-Kubernetes br-ex 网桥网络。configure-ovs.sh shell 脚本不支持对网桥进行安装后更改。
  • 您希望将网桥部署到与主机或服务器 IP 地址上可用的接口不同的接口上。
  • 您希望通过 configure-ovs.sh shell 脚本对网桥进行高级配置。对这些配置使用脚本可能会导致网桥无法连接多个网络接口,并无法正确处理接口之间的数据转发。
注意

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

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

警告

以下接口名称列表被保留,您不能使用带有 NMstate 配置的名称:

  • br-ext
  • br-int
  • br-local
  • br-nexthop
  • br0
  • ext-vxlan
  • ext
  • genev_sys_*
  • int
  • k8s-*
  • ovn-k8s-*
  • patch-br-*
  • tun0
  • vxlan_sys_*

先决条件

  • 可选: 已安装 nmstate API,以便您可以验证 NMState 配置。

流程

  1. 为您的自定义 br-ex 网桥网络创建一个使用 base64 信息的 NMState 配置文件:

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

    interfaces:
    - name: enp2s0 
    1
    
      type: ethernet 
    2
    
      state: up 
    3
    
      ipv4:
        enabled: false 
    4
    
      ipv6:
        enabled: false
    - name: br-ex
      type: ovs-bridge
      state: up
      ipv4:
        enabled: false
        dhcp: false
      ipv6:
        enabled: false
        dhcp: false
      bridge:
        options:
          mcast-snooping-enable: true
        port:
        - name: enp2s0 
    5
    
        - name: br-ex
    - name: br-ex
      type: ovs-interface
      state: up
      copy-mac-from: enp2s0
      ipv4:
        enabled: true
        dhcp: true
        auto-route-metric: 48 
    6
    
      ipv6:
        enabled: true
        dhcp: true
        auto-route-metric: 48
    # ...
    Copy to Clipboard Toggle word wrap

    1
    接口的名称。
    2
    以太网的类型。
    3
    创建后接口的请求状态。
    4
    在这个示例中禁用 IPv4 和 IPv6。
    5
    网桥附加到的节点 NIC。
    6
    将参数设置为 48,以确保 br-ex 默认路由始终具有最高的优先级(最低指标)。此配置可防止与 NetworkManager 服务自动配置的任何其他接口冲突。
  2. 使用 cat 命令对 NMState 配置的内容进行 base64 编码:

    $ cat <nmstate_configuration>.yaml | base64 
    1
    Copy to Clipboard Toggle word wrap
    1
    <nmstate_configuration> 替换为 NMState 资源 YAML 文件的名称。
  3. 创建 MachineConfig 清单文件,并定义一个自定义 br-ex 网桥网络配置,如下例所示:

    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: worker
      name: 10-br-ex-worker 
    1
    
    spec:
      config:
        ignition:
          version: 3.2.0
        storage:
          files:
          - contents:
              source: data:text/plain;charset=utf-8;base64,<base64_encoded_nmstate_configuration> 
    2
    
            mode: 0644
            overwrite: true
            path: /etc/nmstate/openshift/worker-0.yml 
    3
    
          - contents:
              source: data:text/plain;charset=utf-8;base64,<base64_encoded_nmstate_configuration>
            mode: 0644
            overwrite: true
            path: /etc/nmstate/openshift/worker-1.yml 
    4
    
    # ...
    Copy to Clipboard Toggle word wrap
    1
    策略的名称。
    2
    将编码的 base64 信息写入指定路径。
    3 4
    对于集群中的每个节点,指定节点的主机名路径以及机器类型的 base-64 编码 Ignition 配置文件数据。worker 角色是集群中节点的默认角色。如果为每个节点或 MachineConfig 清单文件中的所有节点设置了短主机名、 hostname -s、路径,.yaml 扩展将无法工作。

    如果您在要应用到集群中的所有节点的 /etc/nmstate/openshift/cluster.yml 配置文件中指定了单个全局配置,则不需要为每个节点指定短主机名路径,如 /etc/nmstate/openshift/<node_hostname>.yml。例如:

    # ...
          - contents:
              source: data:text/plain;charset=utf-8;base64,<base64_encoded_nmstate_configuration>
            mode: 0644
            overwrite: true
            path: /etc/nmstate/openshift/cluster.yml
    # ...
    Copy to Clipboard Toggle word wrap

后续步骤

  • 扩展计算节点,以将包含自定义 br-ex 网桥的 manifest 对象应用到集群中存在的每个计算节点。如需更多信息,请参阅附加资源部分中的"扩展集群"。
2.1.4.1. 将每个机器集扩展到计算节点

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

配置这些资源后,您必须扩展机器集,以便机器集可以将资源配置应用到每个计算节点并重新引导节点。

先决条件

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

流程

  1. 输入以下命令编辑 MachineConfig CR:

    $ oc edit mc <machineconfig_custom_resource_name>
    Copy to Clipboard Toggle word wrap
  2. 将每个计算节点配置添加到 CR,以便 CR 可以管理集群中每个定义的计算节点的角色。
  3. 创建名为 extraworker-secretSecret 对象,该对象具有最小的静态 IP 配置。
  4. 输入以下命令将 extraworker-secret secret 应用到集群中的每个节点。此步骤提供每个计算节点对 Ignition 配置文件的访问权限。

    $ oc apply -f ./extraworker-secret.yaml
    Copy to Clipboard Toggle word wrap
  5. 创建 BareMetalHost 资源并在 preprovisioningNetworkDataName 参数中指定网络 secret:

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

    apiVersion: metal3.io/v1alpha1
    kind: BareMetalHost
    spec:
    # ...
      preprovisioningNetworkDataName: ostest-extraworker-0-network-config-secret
    # ...
    Copy to Clipboard Toggle word wrap

  6. 要在集群的 openshift-machine-api 命名空间中管理 BareMetalHost 对象,请输入以下命令来更改命名空间:

    $ oc project openshift-machine-api
    Copy to Clipboard Toggle word wrap
  7. 获取机器集:

    $ oc get machinesets
    Copy to Clipboard Toggle word wrap
  8. 输入以下命令扩展每个机器集。您必须为每个机器集运行这个命令。

    $ oc scale machineset <machineset_name> --replicas=<n> 
    1
    Copy to Clipboard Toggle word wrap
    1
    其中 <machineset_name> 是机器集的名称,<n> 是计算节点的数量。

2.1.5. 为集群启用 OVS balance-slb 模式

您可以启用 Open vSwitch (OVS) balance-slb 模式,以便两个或多个物理接口共享其网络流量。balance-slb 模式接口可以为运行虚拟化工作负载的集群提供源负载均衡(SLB)功能,而无需与网络交换机协商。

目前,源负载均衡在绑定接口上运行,该接口连接到辅助网桥,如 br-phy。源负载均衡仅在不同的 Media Access Control (MAC)地址和虚拟局域网(VLAN)组合之间平衡。请注意,所有 OVN-Kubernetes pod 流量都使用相同的 MAC 地址和 VLAN,因此此流量无法在多个物理接口负载平衡。

下图显示了简单集群基础架构布局上的 balance-slb 模式。虚拟机(VM)连接到特定的 localnet NetworkAttachmentDefinition (NAD)自定义资源定义(CRD)、NAD 0NAD 1。每个 NAD 均为虚拟机提供对底层物理网络的访问,支持 VLAN 标记或未标记的流量。br-ex OVS 网桥从虚拟机接收流量,并将流量传递到下一个 OVS 网桥 br-phybr-phy 网桥作为 SLB 绑定的控制器。SLB 绑定通过物理接口链接(如 eno0eno1)平衡来自不同虚拟机端口的流量。此外,来自一个物理接口的入口流量可以通过一组 OVS 网桥来访问虚拟机。

图 2.1. OVS balance-slb 模式在带有两个 NAD 的 localnet 上运行

您可以使用 OVS 绑定将 balance-slb 模式接口集成到主或二级网络类型中。注意关于 OVS 绑定的以下点:

  • 支持 OVN-Kubernetes CNI 插件,并轻松与插件集成。
  • 原生支持 balance-slb 模式。

先决条件

  • 将多个物理接口附加到主网络,并在 MachineConfig 文件中定义接口。
  • 您创建了清单对象,并在对象配置文件中定义了自定义 br-ex 网桥。
  • 您附加了多个物理接口,并在 NAD CRD 文件中定义接口。

流程

  1. 对于集群中的每个裸机主机,在 install-config.yaml 文件中为集群定义一个 networkConfig 部分,如下例所示:

    # ...
    networkConfig:
      interfaces:
        - name: enp1s0 
    1
    
          type: ethernet
          state: up
          ipv4:
            dhcp: true
            enabled: true
          ipv6:
            enabled: false
        - name: enp2s0 
    2
    
          type: ethernet
          state: up
          mtu: 1500 
    3
    
          ipv4:
            dhcp: true
            enabled: true
          ipv6:
            dhcp: true
            enabled: true
        - name: enp3s0 
    4
    
          type: ethernet
          state: up
          mtu: 1500
          ipv4:
            enabled: false
          ipv6:
            enabled: false
    # ...
    Copy to Clipboard Toggle word wrap
    1
    置备的网络接口控制器(NIC)的接口。
    2
    在绑定接口的 Ignition 配置文件中拉取的第一个绑定接口。
    3
    在绑定端口上手动设置 br-ex 最大传输单元(MTU)。
    4
    第二个绑定接口是在集群安装过程中拉取 ignition 的最小配置的一部分。
  2. 在 NMState 配置文件中定义每个网络接口:

    定义许多网络接口的 NMState 配置文件示例

    ovn:
      bridge-mappings:
        - localnet: localnet-network
          bridge: br-ex
          state: present
    interfaces:
      - name: br-ex
        type: ovs-bridge
        state: up
        bridge:
          allow-extra-patch-ports: true
          port:
            - name: br-ex
            - name: patch-ex-to-phy
        ovs-db:
          external_ids:
            bridge-uplink: "patch-ex-to-phy"
      - name: br-ex
        type: ovs-interface
        state: up
        mtu: 1500 
    1
    
        ipv4:
          enabled: true
          dhcp: true
          auto-route-metric: 48
        ipv6:
          enabled: false
          dhcp: false
          auto-route-metric: 48
      - name: br-phy
        type: ovs-bridge
        state: up
        bridge:
          allow-extra-patch-ports: true
          port:
            - name: patch-phy-to-ex
            - name: ovs-bond
              link-aggregation:
                mode: balance-slb
                port:
                  - name: enp2s0
                  - name: enp3s0
      - name: patch-ex-to-phy
        type: ovs-interface
        state: up
        patch:
          peer: patch-phy-to-ex
      - name: patch-phy-to-ex
        type: ovs-interface
        state: up
        patch:
          peer: patch-ex-to-phy
      - name: enp1s0
        type: ethernet
        state: up
        ipv4:
          dhcp: true
          enabled: true
        ipv6:
          enabled: false
      - name: enp2s0
        type: ethernet
        state: up
        mtu: 1500
        ipv4:
          enabled: false
        ipv6:
          enabled: false
      - name: enp3s0
        type: ethernet
        state: up
        mtu: 1500
        ipv4:
          enabled: false
        ipv6:
          enabled: false
    # ...
    Copy to Clipboard Toggle word wrap

    1
    在绑定端口上手动设置 br-ex MTU。
  3. 使用 base64 命令对 NMState 配置文件的接口内容进行编码:

    $ base64 -w0  <nmstate_configuration>.yml 
    1
    Copy to Clipboard Toggle word wrap
    1
    其中 -w0 选项可防止在 base64 编码操作中换行。
  4. master 角色和 worker 角色创建 MachineConfig 清单文件。确保将之前命令中的 base64 编码的字符串嵌入到每个 MachineConfig 清单文件中。以下示例清单文件为集群中存在的所有节点配置 master 角色。您还可以为特定于节点的 masterworker 角色创建清单文件。

    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: master
      name: 10-br-ex-master 
    1
    
    spec:
      config:
        ignition:
          version: 3.2.0
        storage:
          files:
          - contents:
              source: data:text/plain;charset=utf-8;base64,<base64_encoded_nmstate_configuration> 
    2
    
            mode: 0644
            overwrite: true
            path: /etc/nmstate/openshift/cluster.yml 
    3
    Copy to Clipboard Toggle word wrap
    1
    策略的名称。
    2
    将编码的 base64 信息写入指定路径。
    3
    指定 cluster.yml 文件的路径。对于集群中的每个节点,您可以指定节点的短主机名路径,如 <node_short_hostname>.yml。
  5. 将每个 MachineConfig 清单文件保存到 ./& lt;installation_directory>/manifests 目录,其中 &lt ;installation_directory > 是安装程序在其中创建文件的目录。

    Machine Config Operator (MCO)从每个清单文件中获取内容,并在滚动更新期间持续将内容应用到所有所选节点。

2.1.6. 准备用户置备的基础架构

在用户置备的基础架构上安装 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 bootstrap 过程 部分。

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

      注意

      如果没有使用 DHCP 服务,集群节点可以通过反向 DNS 查找来获取其主机名。

  2. 确保您的网络基础架构提供集群组件之间所需的网络连接。有关 要求的详情,请参阅用户置备的基础架构 的网络要求部分。
  3. 将防火墙配置为启用 OpenShift Container Platform 集群组件进行通信所需的端口。如需有关所需端口的详细信息,请参阅用户置备的基础架构 部分的网络要求。

    重要

    默认情况下,OpenShift Container Platform 集群可以访问端口 1936,因为每个 control plane 节点都需要访问此端口。

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

  4. 为集群设置所需的 DNS 基础架构。

    1. 为 Kubernetes API、应用程序通配符、bootstrap 机器、control plane 机器和计算机器配置 DNS 名称解析。
    2. 为 Kubernetes API、bootstrap 机器、control plane 机器和计算机器配置反向 DNS 解析。

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

  5. 验证您的 DNS 配置。

    1. 从安装节点,针对 Kubernetes API 的记录名称、通配符路由和集群节点运行 DNS 查找。验证响应中的 IP 地址是否与正确的组件对应。
    2. 从安装节点,针对负载均衡器和集群节点的 IP 地址运行反向 DNS 查找。验证响应中的记录名称是否与正确的组件对应。

      有关详细的 DNS 验证步骤,请参阅用户置备的基础架构 验证 DNS 解析部分。

  6. 置备所需的 API 和应用程序入口负载平衡基础架构。有关 要求的更多信息,请参阅用户置备的基础架构的负载平衡 要求部分。
注意

某些负载平衡解决方案要求在初始化负载平衡之前,对群集节点进行 DNS 名称解析。

2.1.7. 验证用户置备的基础架构的 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
      Copy to Clipboard Toggle word wrap
      1
      <nameserver_ip> 替换为 nameserver 的 IP 地址,<cluster_name> 替换为您的集群名称,<base_domain> 替换为您的基本域名。

      输出示例

      api.ocp4.example.com.		604800	IN	A	192.168.1.5
      Copy to Clipboard Toggle word wrap

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

      $ dig +noall +answer @<nameserver_ip> api-int.<cluster_name>.<base_domain>
      Copy to Clipboard Toggle word wrap

      输出示例

      api-int.ocp4.example.com.		604800	IN	A	192.168.1.5
      Copy to Clipboard Toggle word wrap

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

      $ dig +noall +answer @<nameserver_ip> random.apps.<cluster_name>.<base_domain>
      Copy to Clipboard Toggle word wrap

      输出示例

      random.apps.ocp4.example.com.		604800	IN	A	192.168.1.5
      Copy to Clipboard Toggle word wrap

      注意

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

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

      $ dig +noall +answer @<nameserver_ip> console-openshift-console.apps.<cluster_name>.<base_domain>
      Copy to Clipboard Toggle word wrap

      输出示例

      console-openshift-console.apps.ocp4.example.com. 604800 IN	A 192.168.1.5
      Copy to Clipboard Toggle word wrap

    4. 针对 bootstrap DNS 记录名称运行查询。检查结果是否指向 bootstrap 节点的 IP 地址:

      $ dig +noall +answer @<nameserver_ip> bootstrap.<cluster_name>.<base_domain>
      Copy to Clipboard Toggle word wrap

      输出示例

      bootstrap.ocp4.example.com.		604800	IN	A	192.168.1.96
      Copy to Clipboard Toggle word wrap

    5. 使用此方法对 control plane 和计算节点的 DNS 记录名称执行查找。检查结果是否与每个节点的 IP 地址对应。
  2. 从安装节点,针对负载均衡器和集群节点的 IP 地址运行反向 DNS 查找。验证响应中包含的记录名称是否与正确的组件对应。

    1. 对 API 负载均衡器的 IP 地址执行反向查找。检查响应是否包含 Kubernetes API 和 Kubernetes 内部 API 的记录名称:

      $ dig +noall +answer @<nameserver_ip> -x 192.168.1.5
      Copy to Clipboard Toggle word wrap

      输出示例

      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
      Copy to Clipboard Toggle word wrap

      1
      为 Kubernetes 内部 API 提供记录名称。
      2
      为 Kubernetes API 提供记录名称。
      注意

      OpenShift Container Platform 应用程序通配符不需要 PTR 记录。针对应用程序入口负载均衡器的 IP 地址解析反向 DNS 解析不需要验证步骤。

    2. 对 bootstrap 节点的 IP 地址执行反向查找。检查结果是否指向 bootstrap 节点的 DNS 记录名称:

      $ dig +noall +answer @<nameserver_ip> -x 192.168.1.96
      Copy to Clipboard Toggle word wrap

      输出示例

      96.1.168.192.in-addr.arpa. 604800	IN	PTR	bootstrap.ocp4.example.com.
      Copy to Clipboard Toggle word wrap

    3. 使用此方法对 control plane 和计算节点的 IP 地址执行反向查找。检查结果是否与每个节点的 DNS 记录名称对应。

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

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

将密钥传递给节点后,您可以使用密钥对作为用户 核心 通过 SSH 连接到 RHCOS 节点。若要通过 SSH 访问节点,必须由 SSH 为您的本地用户管理私钥身份。

如果要通过 SSH 连接到集群节点来执行安装调试或灾难恢复,则必须在安装过程中提供 SSH 公钥。./openshift-install gather 命令还需要在集群节点上设置 SSH 公钥。

重要

不要在生产环境中跳过这个过程,在生产环境中需要灾难恢复和调试。

注意

您必须使用本地密钥,而不是使用特定平台方法配置的密钥。

流程

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

    $ ssh-keygen -t ed25519 -N '' -f <path>/<file_name> 
    1
    Copy to Clipboard Toggle word wrap
    1
    指定新 SSH 密钥的路径和文件名,如 ~/.ssh/id_ed25519。如果您已有密钥对,请确保您的公钥位于 ~/.ssh 目录中。
    注意

    如果您计划在 x86_64ppc64les390x 架构上安装使用 RHEL 加密库(这些加密库已提交给 NIST 用于 FIPS 140-2/140-3 验证)的 OpenShift Container Platform 集群,则不要创建使用 ed25519 算法的密钥。相反,创建一个使用 rsaecdsa 算法的密钥。

  2. 查看公共 SSH 密钥:

    $ cat <path>/<file_name>.pub
    Copy to Clipboard Toggle word wrap

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

    $ cat ~/.ssh/id_ed25519.pub
    Copy to Clipboard Toggle word wrap
  3. 将 SSH 私钥身份添加到本地用户的 SSH 代理(如果尚未添加)。在集群节点上,或者要使用 ./openshift-install gather 命令,需要对该密钥进行 SSH 代理管理,才能在集群节点上进行免密码 SSH 身份验证。

    注意

    在某些发行版中,自动管理默认 SSH 私钥身份,如 ~/.ssh/id_rsa~/.ssh/id_dsa

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

      $ eval "$(ssh-agent -s)"
      Copy to Clipboard Toggle word wrap

      输出示例

      Agent pid 31874
      Copy to Clipboard Toggle word wrap

      注意

      如果集群处于 FIPS 模式,则只使用 FIPS 兼容算法来生成 SSH 密钥。密钥必须是 RSA 或 ECDSA。

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

    $ ssh-add <path>/<file_name> 
    1
    Copy to Clipboard Toggle word wrap
    1
    指定 SSH 私钥的路径和文件名,如 ~/.ssh/id_ed25519.pub

    输出示例

    Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
    Copy to Clipboard Toggle word wrap

后续步骤

  • 安装 OpenShift Container Platform 时,为安装程序提供 SSH 公钥。如果在您置备的基础架构上安装集群,则必须为安装程序提供密钥。

2.1.9. 获取安装程序

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

先决条件

  • 您有一台运行 Linux 或 macOS 的计算机,本地磁盘空间为 500 MB。

流程

  1. 进入 Red Hat Hybrid Cloud Console 上的 Cluster Type 页。如果您有红帽帐户,请使用您的凭证登录。如果没有,请创建一个帐户。

    提示
  2. 在页的 Run it yourself 部分中选择您的基础架构供应商。
  3. OpenShift 安装程序下的下拉菜单中选择您的主机操作系统和架构,然后点下载安装程序
  4. 将下载的文件保存在要存储安装配置文件的目录中。

    重要
    • 安装程序会在用来安装集群的计算机上创建几个文件。在完成集群安装后,您必须保留安装程序和安装程序所创建的文件。删除集群需要这两个文件。
    • 删除安装程序创建的文件不会删除您的集群,即使集群在安装过程中失败也是如此。要删除集群,请为特定云供应商完成 OpenShift Container Platform 卸载流程。
  5. 提取安装程序。例如,在使用 Linux 操作系统的计算机上运行以下命令:

    $ tar -xvf openshift-install-linux.tar.gz
    Copy to Clipboard Toggle word wrap
  6. 从 Red Hat OpenShift Cluster Manager 下载安装 pull secret。此 pull secret 允许您与所含授权机构提供的服务进行身份验证,这些服务包括为 OpenShift Container Platform 组件提供容器镜像的 Quay.io。
提示

另外,您还可以从红帽客户门户网站检索安装程序,您可以在其中指定要下载的安装程序版本。但是,您需要有一个有效的订阅才能访问此页。

2.1.10. 安装 OpenShift CLI

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

重要

如果安装了旧版本的 oc,则可能无法使用 OpenShift Container Platform 中的所有命令。

下载并安装新版本的 oc

2.1.10.1. 在 Linux 上安装 OpenShift CLI

您可以按照以下流程在 Linux 上安装 OpenShift CLI(oc)二进制文件。

流程

  1. 进入到红帽客户门户网站上的 Download OpenShift Container Platform 页。
  2. Product Variant 列表中选择构架。
  3. Version 列表中选择适当的版本。
  4. OpenShift v4.19 Linux Clients 条目旁的 Download Now 来保存文件。
  5. 解包存档:

    $ tar xvf <file>
    Copy to Clipboard Toggle word wrap
  6. oc 二进制文件放到 PATH 中的目录中

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

    $ echo $PATH
    Copy to Clipboard Toggle word wrap

验证

  • 安装 OpenShift CLI 后,可以使用 oc 命令:

    $ oc <command>
    Copy to Clipboard Toggle word wrap
2.1.10.2. 在 Windows 上安装 OpenShift CLI

您可以按照以下流程在 Windows 上安装 OpenShift CLI(oc)二进制文件。

流程

  1. 进入到红帽客户门户网站上的 Download OpenShift Container Platform 页。
  2. Version 列表中选择适当的版本。
  3. OpenShift v4.19 Windows Client 条目旁的 Download Now 来保存文件。
  4. 使用 ZIP 程序解压存档。
  5. oc 二进制文件移到 PATH 中的目录中

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

    C:\> path
    Copy to Clipboard Toggle word wrap

验证

  • 安装 OpenShift CLI 后,可以使用 oc 命令:

    C:\> oc <command>
    Copy to Clipboard Toggle word wrap
2.1.10.3. 在 macOS 上安装 OpenShift CLI

您可以按照以下流程在 macOS 上安装 OpenShift CLI(oc)二进制文件。

流程

  1. 进入到红帽客户门户网站上的 Download OpenShift Container Platform 页。
  2. 版本 下拉列表中选择适当的版本。
  3. OpenShift v4.19 macOS Clients 条目旁的 Download Now 来保存文件。

    注意

    对于 macOS arm64,请选择 OpenShift v4.19 macOS arm64 Client 条目。

  4. 解包和解压存档。
  5. oc 二进制文件移到 PATH 的目录中。

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

    $ echo $PATH
    Copy to Clipboard Toggle word wrap

验证

  • 使用 oc 命令验证安装:

    $ oc <command>
    Copy to Clipboard Toggle word wrap

2.1.11. 手动创建安装配置文件

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

先决条件

  • 在本地机器上有一个 SSH 公钥用于安装程序。您可以使用密钥在集群节点上进行 SSH 身份验证,以进行调试和灾难恢复。
  • 已获取 OpenShift Container Platform 安装程序和集群的 pull secret。

流程

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

    $ mkdir <installation_directory>
    Copy to Clipboard Toggle word wrap
    重要

    您必须创建一个目录。有些安装资产,如 bootstrap X.509 证书的过期间隔较短,因此不得重复使用安装目录。如果要重复使用另一个集群安装中的单个文件,您可以将它们复制到您的目录中。但是,安装资产的文件名可能会在发行版本间有所变化。从以前的 OpenShift Container Platform 版本中复制安装文件时请小心。

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

    注意

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

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

    重要

    现在备份 install-config.yaml 文件,因为安装过程会在下一步中消耗该文件。

2.1.11.1. 裸机 install-config.yaml 文件示例

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

apiVersion: v1
baseDomain: example.com 
1

compute: 
2

- hyperthreading: Enabled 
3

  name: worker
  replicas: 0 
4

controlPlane: 
5

  hyperthreading: Enabled 
6

  name: master
  replicas: 3 
7

metadata:
  name: test 
8

networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14 
9

    hostPrefix: 23 
10

  networkType: OVNKubernetes 
11

  serviceNetwork: 
12

  - 172.30.0.0/16
platform:
  none: {} 
13

fips: false 
14

pullSecret: '{"auths": ...}' 
15

sshKey: 'ssh-ed25519 AAAA...' 
16
Copy to Clipboard Toggle word wrap
1
集群的基域。所有 DNS 记录都必须是这个基域的子域,并包含集群名称。
2 5
controlPlane 部分是一个单个映射,但 compute 部分是一系列映射。为满足不同数据结构的要求,compute 部分的第一行必须以连字符 - 开头,controlPlane 部分 的第一行则不以连字符开头。仅使用一个 control plane 池。
3 6
指定要启用或禁用并发多线程(SMT)还是超线程。默认情况下,启用 SMT 可提高机器中内核的性能。您可以通过将 参数值设置为 Disabled 来禁用它。如果禁用 SMT,则必须在所有集群机器中禁用它;这包括 control plane 和计算机器。
注意

默认启用并发多线程(SMT)。如果您的 BIOS 设置中没有启用 SMT,超线程 参数无效。

重要

如果您禁用 超线程,无论是在 BIOS 中,还是在 install-config.yaml 文件中,请确保您的容量规划考虑机器性能显著降低的情况。

4
在用户置备的基础架构上安装 OpenShift Container Platform 时,必须将这个值设置为 0。在安装程序置备的安装中,参数控制集群为您创建和管理的计算机器数量。在用户置备的安装中,您必须在完成集群安装前手动部署计算机器。
注意

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

7
您添加到集群的 control plane 机器数量。由于集群使用这些值作为集群中的 etcd 端点数量,所以该值必须与您部署的 control plane 机器数量匹配。
8
您在 DNS 记录中指定的集群名称。
9
从中分配 Pod IP 地址的 IP 地址块。此块不得与现有物理网络重叠。这些 IP 地址用于 pod 网络。如果需要从外部网络访问 pod,您必须配置负载均衡器和路由器来管理流量。
注意

类 E CIDR 范围被保留以供以后使用。要使用 Class E CIDR 范围,您必须确保您的网络环境接受 Class E CIDR 范围内的 IP 地址。

10
分配给每个节点的子网前缀长度。例如,如果 hostPrefix 设为 23,则每个节点从 given cidr 中分配 a /23 子网,这样就能有 510(2^(32 - 23)- 2)个 pod IP 地址。如果需要从外部网络访问节点,请配置负载均衡器和路由器来管理流量。
11
要安装的集群网络插件。默认值 OVNKubernetes 是唯一支持的值。
12
用于服务 IP 地址的 IP 地址池。您只能输入一个 IP 地址池。此块不得与现有物理网络重叠。如果您需要从外部网络访问服务,请配置负载均衡器和路由器来管理流量。
13
您必须将平台设置为 none。您无法为您的平台提供额外的平台配置变量。
重要

使用平台类型 none 安装的集群无法使用一些功能,如使用 Machine API 管理计算机器。即使附加到集群的计算机器安装在通常支持该功能的平台上,也会应用这个限制。在安装后无法更改此参数。

14
是否启用或禁用 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 核心组件使用 RHEL 加密库,只有在 x86_64, ppc64le, 和 s390x 架构上的库被提交到 NIST 进行 FIPS 140-2/140-3 Validation。

15
Red Hat OpenShift Cluster Manager 的 pull secret。此 pull secret 允许您与所含授权机构提供的服务进行身份验证,这些服务包括为 OpenShift Container Platform 组件提供容器镜像的 Quay.io。
16
Red Hat Enterprise Linux CoreOS(RHCOS)中 core 用户的 SSH 公钥。
注意

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

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

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

注意

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

先决条件

  • 您有一个现有的 install-config.yaml 文件。
  • 您检查了集群需要访问的站点,并确定它们中的任何站点是否需要绕过代理。默认情况下,所有集群出口流量都经过代理,包括对托管云供应商 API 的调用。如果需要,您将在 Proxy 对象的 spec.noProxy 字段中添加站点来绕过代理。

    注意

    Proxy 对象 status.noProxy 字段使用安装配置中的 networking.machineNetwork[].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
    Copy to Clipboard Toggle word wrap
    1
    用于创建集群外 HTTP 连接的代理 URL。URL 方案必须是 http
    2
    用于创建集群外 HTTPS 连接的代理 URL。
    3
    要从代理中排除的目标域名、IP 地址或其他网络 CIDR 的逗号分隔列表。在域前面加上 . 以仅匹配子域。例如,.y.com 匹配 x.y.com,但不匹配 y.com。使用 * 绕过所有目的地的代理。
    4
    如果提供,安装程序会在 openshift-config 命名空间中生成名为 user-ca-bundle 的配置映射,其包含代理 HTTPS 连接所需的一个或多个额外 CA 证书。然后,Cluster Network Operator 会创建一个 trusted-ca-bundle 配置映射,将这些内容与 Red Hat Enterprise Linux CoreOS (RHCOS)信任捆绑包合并,Proxy 对象的 trustedCA 字段中也会引用此配置映射。additionalTrustBundle 字段是必需的,除非代理的身份证书由来自 RHCOS 信任捆绑包的颁发机构签名。
    5
    可选:决定 Proxy 对象的配置以引用 trustedCA 字段中 user-ca-bundle 配置映射的策略。允许的值是 ProxyonlyAlways。仅在配置了 http/https 代理时,使用 Proxyonly 引用 user-ca-bundle 配置映射。使用 Always 始终引用 user-ca-bundle 配置映射。默认值为 Proxyonly
    注意

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

    注意

    如果安装程序超时,重启并使用安装程序的 wait-for 命令完成部署。例如:

    $ ./openshift-install wait-for install-complete --log-level debug
    Copy to Clipboard Toggle word wrap
  2. 保存该文件并在安装 OpenShift Container Platform 时引用。

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

注意

只支持名为 clusterProxy 对象,且无法创建额外的代理。

2.1.11.3. 配置三节点集群

另外,您可以在只由三台 control plane 机器组成的裸机集群中部署零台计算机器。这为集群管理员和开发人员提供了更小、效率更高的集群,用于测试、开发和生产。

在三节点 OpenShift Container Platform 环境中,三台 control plane 机器可以调度,这意味着应用程序工作负载被调度到它们上运行。

先决条件

  • 您有一个现有的 install-config.yaml 文件。

流程

  • 确保 install-config.yaml 文件中的计算副本数量设置为 0,如以下 计算 小节所示:

    compute:
    - name: worker
      platform: {}
      replicas: 0
    Copy to Clipboard Toggle word wrap
    注意

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

对于三节点集群安装,请按照以下步骤执行:

  • 如果要部署一个带有零计算节点的三节点集群,Ingress Controller Pod 在 control plane 节点上运行。在三节点集群部署中,您必须配置应用程序入口负载均衡器,将 HTTP 和 HTTPS 流量路由到 control plane 节点。如需更多信息,请参阅用户置备的基础架构的负载平衡要求 部分。
  • 在以下步骤中创建 Kubernetes 清单文件时,请确保 <installation_directory>/manifests/cluster-scheduler-02-config.yml 文件中的 mastersSchedulable 参数被设置为 true。这可让应用程序工作负载在 control plane 节点上运行。
  • 在创建 Red Hat Enterprise Linux CoreOS(RHCOS)机器时,不要部署任何计算节点。

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

由于您必须修改一些集群定义文件并手动启动集群机器,因此您必须生成 Kubernetes 清单和 Ignition 配置文件来配置机器。

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

重要
  • OpenShift Container Platform 安装程序生成的 Ignition 配置文件包含 24 小时后过期的证书,然后在该时进行续订。如果在更新证书前关闭集群,且集群在 24 小时后重启,集群会自动恢复过期的证书。一个例外是,您必须手动批准待处理的 node-bootstrapper 证书签名请求(CSR)来恢复 kubelet 证书。如需更多信息,请参阅从过期的 control plane 证书 中恢复的文档。
  • 建议您在 Ignition 配置文件生成后的 12 小时内使用它们,因为 24 小时的证书会在集群安装后的 16 小时到 22 小时间进行轮转。通过在 12 小时内使用 Ignition 配置文件,您可以避免在安装过程中因为执行了证书更新而导致安装失败的问题。

先决条件

  • 已获得 OpenShift Container Platform 安装程序。
  • 已创建 install-config.yaml 安装配置文件。

流程

  1. 进入包含 OpenShift Container Platform 安装程序的目录,并为集群生成 Kubernetes 清单:

    $ ./openshift-install create manifests --dir <installation_directory> 
    1
    Copy to Clipboard Toggle word wrap
    1
    对于 <installation_directory>,请指定包含您创建的 install-config.yaml 文件的安装目录。
    警告

    如果您要安装一个三节点集群,请跳过以下步骤,以便可以调度 control plane 节点。

    重要

    当您将 control plane 节点从默认的不可调度配置为可以调度时,需要额外的订阅。这是因为 control plane 节点变为计算节点。

  2. 检查 <installation_directory>/manifests/cluster-scheduler-02-config.yml Kubernetes 清单文件中的 mastersSchedulable 参数是否已设置为 false。此设置可防止在 control plane 机器上调度 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
    Copy to Clipboard Toggle word wrap
    1
    对于 <installation_directory>,请指定相同的安装目录。

    为安装目录中的 bootstrap、control plane 和计算节点创建 Ignition 配置文件。kubeadmin-passwordkubeconfig 文件在 ./<installation_directory>/auth 目录中创建:

    .
    ├── auth
    │   ├── kubeadmin-password
    │   └── kubeconfig
    ├── bootstrap.ign
    ├── master.ign
    ├── metadata.json
    └── worker.ign
    Copy to Clipboard Toggle word wrap

要在您置备的裸机基础架构上安装 OpenShift Container Platform,您必须在机器上安装 Red Hat Enterprise Linux CoreOS(RHCOS)。安装 RHCOS 时,您必须为您要安装的机器类型提供 OpenShift Container Platform 安装程序生成的 Ignition 配置文件。如果您配置了适当的网络、DNS 和负载均衡基础架构,OpenShift Container Platform bootstrap 过程会在 RHCOS 机器重启后自动启动。

要在机器上安装 RHCOS,请按照以下步骤使用 ISO 镜像或网络 PXE 引导。

注意

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

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

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

    注意

    0.17.0-3 起,coreos-installer 需要 RHEL 9 或更高版本来运行该程序。您仍然可以使用旧版本的 coreos-installer 自定义较新的 OpenShift Container Platform 版本的 RHCOS 工件,并将构建器镜像安装到磁盘。您可以从 coreos-installer image mirror 页下载旧版本的 coreos-installer 二进制文件。

使用 ISO 安装还是 PXE 安装取决于您的情况。PXE 安装需要可用的 DHCP 服务并进行更多准备,但可以使安装过程更加自动化。ISO 安装是一个更手动的过程,如果您设置的机器数超过几台,则可能不方便。

2.1.13.1. 使用 ISO 镜像安装 RHCOS

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

先决条件

  • 已为集群创建 Ignition 配置文件。
  • 您已配置了适当的网络、DNS 和负载平衡基础架构。
  • 您有一个可以从计算机以及您创建的机器访问的 HTTP 服务器。
  • 您已参阅 Advanced RHCOS 安装配置 部分来了解配置功能的不同方法,如网络和磁盘分区。

流程

  1. 获取每个 Ignition 配置文件的 SHA512 摘要。例如,您可以在运行 Linux 的系统上使用以下内容来获取 bootstrap.ign Ignition 配置文件的 SHA512 摘要:

    $ sha512sum <installation_directory>/bootstrap.ign
    Copy to Clipboard Toggle word wrap

    后续步骤中会向 coreos-installer 提供摘要,以验证集群节点上 Ignition 配置文件的真实性。

  2. 将安装程序创建的 bootstrap、control plane 和计算节点 Ignition 配置文件上传到 HTTP 服务器。注意这些文件的 URL。

    重要

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

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

    $ curl -k http://<HTTP_server>/bootstrap.ign 
    1
    Copy to Clipboard Toggle word wrap

    输出示例

      % 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...
    Copy to Clipboard Toggle word wrap

    在命令中将 bootstrap.ign 替换为 master.ignworker.ign,以验证 control plane 和计算节点的 Ignition 配置文件是否可用。

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

    $ openshift-install coreos print-stream-json | grep '\.iso[^.]'
    Copy to Clipboard Toggle word wrap

    输出示例

    "location": "<url>/art/storage/releases/rhcos-4.19-aarch64/<release>/aarch64/rhcos-<release>-live.aarch64.iso",
    "location": "<url>/art/storage/releases/rhcos-4.19-ppc64le/<release>/ppc64le/rhcos-<release>-live.ppc64le.iso",
    "location": "<url>/art/storage/releases/rhcos-4.19-s390x/<release>/s390x/rhcos-<release>-live.s390x.iso",
    "location": "<url>/art/storage/releases/rhcos-4.19/<release>/x86_64/rhcos-<release>-live.x86_64.iso",
    Copy to Clipboard Toggle word wrap

    重要

    RHCOS 镜像可能不会随着 OpenShift Container Platform 的每个发行版本而改变。您必须下载最高版本的镜像,其版本号应小于或等于您安装的 OpenShift Container Platform 版本。如果可用,请使用与 OpenShift Container Platform 版本匹配的镜像版本。这个过程只使用 ISO 镜像。此安装类型不支持 RHCOS qcow2 镜像。

    ISO 文件名类似以下示例:

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

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

    • 将 ISO 映像刻录到磁盘并直接启动。
    • 使用 light-out 管理(LOM)接口使用 ISO 重定向。
  6. 在不指定任何选项或中断实时引导序列的情况下引导 RHCOS ISO 镜像。等待安装程序在 RHCOS live 环境中引导进入 shell 提示符。

    注意

    可以中断 RHCOS 安装引导过程来添加内核参数。但是,在这个 ISO 过程中,您应该使用以下步骤中所述的 coreos-installer 命令,而不是添加内核参数。

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

    $ sudo coreos-installer install --ignition-url=http://<HTTP_server>/<node_type>.ign <device> \ 
    1
    
    --ignition-hash=sha512-<digest> 
    2
    Copy to Clipboard Toggle word wrap
    1 1
    您必须使用 sudo 运行 coreos-installer 命令,因为 core 用户没有执行安装所需的 root 权限。
    2
    当 Ignition 配置文件通过 HTTP URL 获取时,需要 --ignition-hash 选项来验证集群节点上 Ignition 配置文件的真实性。<digest> 是上一步中获取的 Ignition 配置文件 SHA512 摘要。
    注意

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

    以下示例将引导节点安装初始化到 /dev/sda 设备。bootstrap 节点的 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
    Copy to Clipboard Toggle word wrap
  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
    Copy to Clipboard Toggle word wrap

  11. 继续为集群创建其他机器。

    重要

    此时您必须创建 bootstrap 和 control plane 机器。如果 control plane 机器不可调度,请在安装 OpenShift Container Platform 前至少创建两台计算机器。

    如果存在所需的网络、DNS 和负载均衡器基础架构,OpenShift Container Platform bootstrap 过程会在 RHCOS 节点重启后自动启动。

    注意

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

2.1.13.2. 使用 PXE 或 iPXE 启动安装 RHCOS

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

先决条件

  • 已为集群创建 Ignition 配置文件。
  • 您已配置了适当的网络、DNS 和负载平衡基础架构。
  • 您已配置了合适的 PXE 或 iPXE 基础架构。
  • 您有一个可以从计算机以及您创建的机器访问的 HTTP 服务器。
  • 您已参阅 Advanced RHCOS 安装配置 部分来了解配置功能的不同方法,如网络和磁盘分区。

流程

  1. 将安装程序创建的 bootstrap、control plane 和计算节点 Ignition 配置文件上传到 HTTP 服务器。注意这些文件的 URL。

    重要

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

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

    $ curl -k http://<HTTP_server>/bootstrap.ign 
    1
    Copy to Clipboard Toggle word wrap

    输出示例

      % 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...
    Copy to Clipboard Toggle word wrap

    在命令中将 bootstrap.ign 替换为 master.ignworker.ign,以验证 control plane 和计算节点的 Ignition 配置文件是否可用。

  3. 虽然可以从 RHCOS image mirror 页面获取您选择的操作系统实例所需的 RHCOS kernelinitramfsrootfs 文件,但推荐的方法是从 openshift-install 命令的输出中获取 RHCOS 文件的正确版本:

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

    输出示例

    "<url>/art/storage/releases/rhcos-4.19-aarch64/<release>/aarch64/rhcos-<release>-live-kernel-aarch64"
    "<url>/art/storage/releases/rhcos-4.19-aarch64/<release>/aarch64/rhcos-<release>-live-initramfs.aarch64.img"
    "<url>/art/storage/releases/rhcos-4.19-aarch64/<release>/aarch64/rhcos-<release>-live-rootfs.aarch64.img"
    "<url>/art/storage/releases/rhcos-4.19-ppc64le/49.84.202110081256-0/ppc64le/rhcos-<release>-live-kernel-ppc64le"
    "<url>/art/storage/releases/rhcos-4.19-ppc64le/<release>/ppc64le/rhcos-<release>-live-initramfs.ppc64le.img"
    "<url>/art/storage/releases/rhcos-4.19-ppc64le/<release>/ppc64le/rhcos-<release>-live-rootfs.ppc64le.img"
    "<url>/art/storage/releases/rhcos-4.19-s390x/<release>/s390x/rhcos-<release>-live-kernel-s390x"
    "<url>/art/storage/releases/rhcos-4.19-s390x/<release>/s390x/rhcos-<release>-live-initramfs.s390x.img"
    "<url>/art/storage/releases/rhcos-4.19-s390x/<release>/s390x/rhcos-<release>-live-rootfs.s390x.img"
    "<url>/art/storage/releases/rhcos-4.19/<release>/x86_64/rhcos-<release>-live-kernel-x86_64"
    "<url>/art/storage/releases/rhcos-4.19/<release>/x86_64/rhcos-<release>-live-initramfs.x86_64.img"
    "<url>/art/storage/releases/rhcos-4.19/<release>/x86_64/rhcos-<release>-live-rootfs.x86_64.img"
    Copy to Clipboard Toggle word wrap

    重要

    RHCOS 工件可能不会随着 OpenShift Container Platform 的每个发行版本而改变。您必须下载最高版本的镜像,其版本号应小于或等于您安装的 OpenShift Container Platform 版本。这个过程只使用下面描述的适当 kernelinitram fs 和 rootfs 工件。此安装类型不支持 RHCOS QCOW2 镜像。

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

    • kernel:rhcos-<version>-live-kernel-<architecture>
    • initramfs: rhcos-<version>-live-initramfs.<architecture>.img
    • rootfs: rhcos-<version>-live-rootfs.<architecture>.img
  4. rootfskernelinitramfs 文件上传到 HTTP 服务器。

    重要

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

  5. 配置网络引导基础架构,以便在安装 RHCOS 后机器从本地磁盘启动。
  6. 为 RHCOS 镜像配置 PXE 或 iPXE 安装并开始安装。

    为环境修改以下示例菜单条目之一,并验证能否正确访问镜像和 Ignition 文件:

    • 对于 PXE(x86_64)

      DEFAULT pxeboot
      TIMEOUT 20
      PROMPT 0
      LABEL pxeboot
          KERNEL http://<HTTP_server>/rhcos-<version>-live-kernel-<architecture> 
      1
      
          APPEND initrd=http://<HTTP_server>/rhcos-<version>-live-initramfs.<architecture>.img coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/bootstrap.ign 
      2
       
      3
      Copy to Clipboard Toggle word wrap
      1 1
      指定上传到 HTTP 服务器的 live kernel 文件位置。URL 必须是 HTTP、TFTP 或 FTP;不支持 HTTPS 和 NFS。
      2
      如果您使用多个 NIC,请在 ip 选项中指定一个接口。例如,要在名为 eno1 的 NIC 上使用 DHCP,请设置 ip=eno1:dhcp
      3
      指定上传到 HTTP 服务器的 RHCOS 文件的位置。initrd 参数值是 initramfs 文件的位置,coreos.live.rootfs_url 参数值是 rootfs 文件的位置,coreos.inst.ignition_url 参数值则是 bootstrap Ignition 配置文件的位置。您还可以在 APPEND 行中添加更多内核参数来配置联网或其他引导选项。
      注意

      此配置不会在图形控制台的机器上启用串行控制台访问。要配置不同的控制台,请在 APPEND 行中添加一个或多个 console= 参数。例如,添加 console=tty0 console=ttyS0 以将第一个 PC 串口设置为主控制台,并将图形控制台设置为二级控制台。如需更多信息,请参阅如何在 Red Hat Enterprise Linux 中设置串行终端和/或控制台? 和"启用 PXE 和 ISO 安装的串行控制台"部分。

    • 对于 iPXE (x86_64 + aarch64 ):

      kernel http://<HTTP_server>/rhcos-<version>-live-kernel-<architecture> initrd=main coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/bootstrap.ign 
      1
       
      2
      
      initrd --name main http://<HTTP_server>/rhcos-<version>-live-initramfs.<architecture>.img 
      3
      
      boot
      Copy to Clipboard Toggle word wrap
      1
      指定上传到 HTTP 服务器的 RHCOS 文件的位置。kernel 参数值是 kernel 文件的位置,init rd=main 参数用于在 UEFI 系统中引导,coreos.live.rootfs_url 参数值是 rootfs 文件的位置,coreos.inst.ignition_url 参数值则是 bootstrap Ignition 配置文件的位置。
      2
      如果您使用多个 NIC,请在 ip 选项中指定一个接口。例如,要在名为 eno1 的 NIC 上使用 DHCP,请设置 ip=eno1:dhcp
      3
      指定上传到 HTTP 服务器的 initramfs 文件的位置。
      注意

      此配置不会在图形控制台的机器上启用串行控制台访问。要配置不同的控制台,请在 内核参数 中添加一个或多个 console= 参数。例如,添加 console=tty0 console=ttyS0 以将第一个 PC 串口设置为主控制台,并将图形控制台设置为二级控制台。如需更多信息,请参阅如何在 Red Hat Enterprise Linux 中设置串行终端和/或控制台? 和"启用 PXE 和 ISO 安装的串行控制台"部分。

      注意

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

    • 对于 aarch64 中的 PXE(使用 UEFI 和 Grub 作为第二阶段):

      menuentry 'Install CoreOS' {
          linux rhcos-<version>-live-kernel-<architecture>  coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/bootstrap.ign 
      1
       
      2
      
          initrd rhcos-<version>-live-initramfs.<architecture>.img 
      3
      
      }
      Copy to Clipboard Toggle word wrap
      1
      指定上传到 HTTP/TFTP 服务器的 RHCOS 文件的位置。kernel 参数值是 TFTP 服务器中的 kernel 文件的位置。coreos.live.rootfs_url 参数值是 rootfs 文件的位置,coreos.inst.ignition_url 参数值是 HTTP 服务器上的 bootstrap Ignition 配置文件的位置。
      2
      如果您使用多个 NIC,请在 ip 选项中指定一个接口。例如,要在名为 eno1 的 NIC 上使用 DHCP,请设置 ip=eno1:dhcp
      3
      指定上传到 TFTP 服务器的 initramfs 文件的位置。
  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
    Copy to Clipboard Toggle word wrap

  10. 继续为集群创建机器。

    重要

    此时您必须创建 bootstrap 和 control plane 机器。如果 control plane 机器不可调度,请在安装集群前至少创建两台计算机器。

    如果存在所需的网络、DNS 和负载均衡器基础架构,OpenShift Container Platform bootstrap 过程会在 RHCOS 节点重启后自动启动。

    注意

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

2.1.13.3. 高级 RHCOS 安装配置

为 OpenShift Container Platform 手动置备 Red Hat Enterprise Linux CoreOS(RHCOS)节点的一个关键优点是能够进行通过默认的 OpenShift Container Platform 安装方法无法进行的配置。本节介绍了您可以使用的一些技术进行配置,其中包括:

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

本节详述了与 Red Hat Enterprise Linux CoreOS(RHCOS)手动安装的高级配置相关的内容,如磁盘分区、网络以及使用 Ignition 配置的不同方式相关。

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

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

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

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

要配置 ISO 安装,请使用以下步骤:

流程

  1. 引导 ISO 安装程序.
  2. 在 live 系统 shell 提示符下,使用可用的 RHEL 工具(如 nmclinmtui )为 live 系统配置网络。
  3. 运行 coreos-installer 命令以安装系统,添加 --copy-network 选项来复制网络配置。例如:

    $ sudo coreos-installer install --copy-network \
         --ignition-url=http://host/worker.ign /dev/disk/by-id/scsi-<serial_number>
    Copy to Clipboard Toggle word wrap
    重要

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

  4. 重启安装的系统。
2.1.13.3.2. 磁盘分区

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

重要

在节点上使用自定义分区方案可能会导致 OpenShift Container Platform 在某些节点分区上监控或警报。如果要覆盖默认分区,请参阅 了解 OpenShift 文件系统监控(驱除条件) 以了解有关 OpenShift Container Platform 如何监控主机文件系统的更多信息。

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

  • nodefs,这是包含 /var/lib/kubelet 的文件系统
  • imagefs,这是包含 /var/lib/containers 的文件系统

对于默认分区方案,nodefsimagefs 监控相同的根文件系统 /

要在 OpenShift Container Platform 集群节点上安装 RHCOS 时覆盖默认分区,您必须创建单独的分区。您可能想要为容器和容器镜像添加单独的存储分区。例如,通过在独立分区中挂载 /var/lib/containers,kubelet 会单独监控 /var/lib/containers 作为 imagefs 目录,以及 root 文件系统作为 nodefs 目录。

重要

如果您已将磁盘大小调整为托管更大的文件系统,请考虑创建单独的 /var/lib/containers 分区。考虑重新定义具有 xfs 格式的磁盘大小,以减少大量分配组导致的 CPU 时间问题。

2.1.13.3.2.1. 创建独立 /var 分区

通常,您应该使用在 RHCOS 安装过程中创建的默认磁盘分区。然而,在有些情况下您可能需要为预期增长的目录创建独立分区。

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

  • /var/lib/containers :保存随着系统中添加更多镜像和容器而增长的容器相关内容。
  • /var/lib/etcd :保存您可能希望独立保留的数据,比如 etcd 存储的性能优化。
  • /var :保存您可能希望独立保留的数据,以满足审计等目的。

    重要

    对于大于 100GB 的磁盘大小,特别是磁盘大小大于 1TB,请创建一个独立的 /var 分区。

通过单独存储 /var 目录的内容,可以更轻松地根据需要为区域扩展存储,并在以后重新安装 OpenShift Container Platform,并保持该数据的完整性。使用这个方法,您不必再次拉取所有容器,在更新系统时也不必复制大量日志文件。

将独立分区用于 /var 目录或 /var 的子目录也会防止分区目录中的数据增加填充根文件系统。

以下流程通过添加机器配置清单来设置独立的 /var 分区,该清单会在安装准备阶段封装到节点类型的 Ignition 配置文件中。

流程

  1. 在安装主机上,切换到包含 OpenShift Container Platform 安装程序的目录,并为集群生成 Kubernetes 清单:

    $ openshift-install create manifests --dir <installation_directory>
    Copy to Clipboard Toggle word wrap
  2. 创建用于配置额外分区的 Butane 配置。例如,将文件命名为 $HOME/clusterconfig/98-var-partition.bu,将磁盘设备名称改为 worker 系统上存储设备的名称,并根据情况设置存储大小。这个示例将 /var 目录放在一个单独的分区中:

    variant: openshift
    version: 4.19.0
    metadata:
      labels:
        machineconfiguration.openshift.io/role: worker
      name: 98-var-partition
    storage:
      disks:
      - device: /dev/disk/by-id/<device_name> 
    1
    
        partitions:
        - label: var
          start_mib: <partition_start_offset> 
    2
    
          size_mib: <partition_size> 
    3
    
          number: 5
      filesystems:
        - device: /dev/disk/by-partlabel/var
          path: /var
          format: xfs
          mount_options: [defaults, prjquota] 
    4
    
          with_mount_unit: true
    Copy to Clipboard Toggle word wrap
    1
    要分区的磁盘的存储设备名称。
    2
    当在引导磁盘中添加数据分区时,推荐最少使用偏移值 25000 兆字节。root 文件系统会自动调整大小以填充所有可用空间(最多到指定的偏移值)。如果没有指定偏移值,或者指定的值小于推荐的最小值,则生成的 root 文件系统会太小,而在以后进行的 RHCOS 重新安装可能会覆盖数据分区的开始部分。
    3
    以兆字节为单位的数据分区大小。
    4
    对于用于容器存储的文件系统,必须启用 prjquota 挂载选项。
    注意

    在创建单独的 /var 分区时,如果不同的实例类型没有相同的设备名称,则无法将不同的实例类型用于计算节点。

  3. 从 Butane 配置创建一个清单,并将它保存到 clusterconfig/openshift 目录中。例如,运行以下命令:

    $ butane $HOME/clusterconfig/98-var-partition.bu -o $HOME/clusterconfig/openshift/98-var-partition.yaml
    Copy to Clipboard Toggle word wrap
  4. 创建 Ignition 配置文件:

    $ openshift-install create ignition-configs --dir <installation_directory> 
    1
    Copy to Clipboard Toggle word wrap
    1
    对于 <installation_directory>,请指定相同的安装目录。

    为安装目录中的 bootstrap、control plane 和计算节点创建 Ignition 配置文件:

    .
    ├── auth
    │   ├── kubeadmin-password
    │   └── kubeconfig
    ├── bootstrap.ign
    ├── master.ign
    ├── metadata.json
    └── worker.ign
    Copy to Clipboard Toggle word wrap

    <installation_directory>/manifest<installation_directory>/openshift 目录中的文件被嵌套到 Ignition 配置文件中,包括包含 98-var-partition 自定义 MachineConfig 对象的文件。

后续步骤

  • 您可以通过在 RHCOS 安装过程中引用 Ignition 配置文件来应用自定义磁盘分区。
2.1.13.3.2.2. 保留现有分区

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

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

注意

如果您保存了现有分区,且这些分区没有为 RHCOS 留下足够空间,则安装将失败,而不影响保存的分区。

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

这个示例保留分区标签以 数据开头的任何分区(data *):

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

以下示例演示了在运行 coreos-installer 时要保留磁盘上的第 6 个分区:

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

这个示例保留分区 5 及更高分区:

# coreos-installer install --ignition-url http://10.0.2.2:8080/user.ign \
--save-partindex 5- /dev/disk/by-id/scsi-<serial_number>
Copy to Clipboard Toggle word wrap

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

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

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

coreos.inst.save_partlabel=data*
Copy to Clipboard Toggle word wrap

这个 APPEND 选项保留分区 5 及更高分区:

coreos.inst.save_partindex=5-
Copy to Clipboard Toggle word wrap

这个 APPEND 选项保留分区 6:

coreos.inst.save_partindex=6
Copy to Clipboard Toggle word wrap
2.1.13.3.3. 识别 Ignition 配置

在进行 RHCOS 手动安装时,您可以提供两种 Ignition 配置类型,它们有不同的原因:

  • 永久安装 Ignition 配置 :每个手动 RHCOS 安装都需要传递 openshift-installer 生成的 Ignition 配置文件之一,如 bootstrap.ignmaster.ignworker.ign,才能进行安装。

    重要

    不建议直接修改这些 Ignition 配置文件。您可以更新嵌套到 Ignition 配置文件中的清单文件,如上一节示例中所述。

    对于 PXE 安装,您可以使用 coreos.inst.ignition_url= 选项在 APPEND 行上传递 Ignition 配置。对于 ISO 安装,在 ISO 引导至 shell 提示符后,您可以使用带有 --ignition-url= 选项的 coreos-installer 命令行。在这两种情况下,只支持 HTTP 和 HTTPS 协议。

  • 实时安装 Ignition 配置 :可使用 coreos-installer customize 子命令及其各种选项来创建此类型。使用此方法,Ignition 配置会传递到 live 安装介质,在引导时立即运行,并在 RHCOS 系统安装到磁盘之前或之后执行设置任务。这个方法只用于必须执行一次且之后不能再次应用的任务,比如不能使用机器配置进行的高级分区。

    对于 PXE 或 ISO 引导,您可以创建 Ignition 配置,APP END ignition.config.url= 选项来标识 Ignition 配置的位置。您还需要附加 ignition.firstboot ignition.platform.id=metalignition.config.url 选项。

2.1.13.3.4. 默认控制台配置

从 OpenShift Container Platform 4.19 引导镜像安装的 Red Hat Enterprise Linux CoreOS (RHCOS) 节点使用默认控制台,旨在识别大多数虚拟化和裸机设置。不同的云和虚拟化平台可能会根据所选的架构使用不同的默认设置。裸机安装使用内核默认设置,这通常意味着图形控制台是主控制台,并且禁用串行控制台。

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

  • 您希望访问控制台上的紧急 shell 进行调试。
  • 您的云平台没有提供到图形控制台的互动访问,但提供了一个串行控制台。
  • 您需要启用多个控制台。

控制台配置继承自引导镜像。这意味着现有集群中的新节点不受默认控制台的影响。

您可以使用以下方法为裸机安装配置控制台:

  • 在命令行中手动使用 coreos-installer
  • 使用带有 --dest-console 选项的 coreos-installer iso customizecoreos-installer pxe customize 子命令,以创建可自动执行进程的自定义镜像。
注意

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

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

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

流程

  1. 引导 ISO 安装程序.
  2. 运行 coreos-installer 命令来安装系统,添加 --console 选项一次来指定图形控制台,然后第二次指定串行控制台:

    $ coreos-installer install \
    --console=tty0 \
    1
    
    --console=ttyS0,<options> \
    2
    
    --ignition-url=http://host/worker.ign /dev/disk/by-id/scsi-<serial_number>
    Copy to Clipboard Toggle word wrap
    1
    所需的二级控制台。在这种情况下,是图形控制台。省略这个选项将禁用图形控制台。
    2
    所需的主控制台。在这种情况下,是串行控制台。options 字段定义 baud 速率和其他设置。此字段的一个常见值为 115200n8。如果没有提供选项,则使用默认内核值 9600n8。有关这个选项格式的更多信息,请参阅 Linux 内核串口控制台 文档。
  3. 重启安装的系统。

    注意

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

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

2.1.13.3.6. 自定义 live RHCOS ISO 或 PXE 安装

您可以通过将 Ignition 配置文件直接注入镜像中来使用 live ISO 镜像或 PXE 环境来安装 RHCOS。这会创建一个自定义镜像,供您用来置备系统。

对于 ISO 镜像,此操作的机制是 coreos-installer iso custom 子命令,它使用您的配置修改 .iso 文件。同样,PXE 环境的机制是 coreos-installer pxe customize 子命令,它会创建一个包含自定义的新 initramfs 文件。

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

  • 当公司安全策略需要使用时,注入自定义的 CA 证书。
  • 在不需要内核参数的情况下配置网络设置。
  • 嵌入任意预安装和安装后脚本或二进制文件。
2.1.13.3.7. 自定义 live RHCOS ISO 镜像

您可以使用 coreos-installer iso custom 子命令直接自定义 live RHCOS ISO 镜像。当您引导 ISO 镜像时,会自动应用自定义。

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

流程

  1. coreos-installer 镜像镜像页面下载 coreos-installer 二进制文件。
  2. 从 RHCOS 镜像镜像页面和 Ignition 配置文件检索 RHCOS ISO 镜像,然后运行以下命令来直接将 Ignition 配置注入 ISO 镜像:

    $ coreos-installer iso customize rhcos-<version>-live.x86_64.iso \
        --dest-ignition bootstrap.ign \ 
    1
    
        --dest-device /dev/disk/by-id/scsi-<serial_number> 
    2
    Copy to Clipboard Toggle word wrap
    1
    openshift-installer 安装程序生成的 Ignition 配置文件。
    2
    当您指定这个选项时,ISO 镜像会自动运行安装。否则,镜像为安装配置,但不会自动安装,除非您指定了 coreos.inst.install_dev 内核参数。
  3. 可选: 要删除 ISO 镜像自定义并将镜像返回到其 pristine 状态,请运行:

    $ coreos-installer iso reset rhcos-<version>-live.x86_64.iso
    Copy to Clipboard Toggle word wrap

    现在,您可以重新自定义 live ISO 镜像,或者在其 pristine 状态中使用它。

应用您的自定义会影响每个后续 RHCOS 引导。

在使用 OpenShift Container Platform 4.12 及更高版本安装的集群中,串行控制台默认被禁用,所有输出都会写入图形控制台。您可以按照以下流程启用串行控制台。

流程

  1. coreos-installer 镜像镜像页面下载 coreos-installer 二进制文件。
  2. RHCOS image mirror 页中获取 RHCOS ISO 镜像,并运行以下命令来自定义 ISO 镜像,使串行控制台能够接收输出:

    $ coreos-installer iso customize rhcos-<version>-live.x86_64.iso \
      --dest-ignition <path> \
    1
    
      --dest-console tty0 \
    2
    
      --dest-console ttyS0,<options> \
    3
    
      --dest-device /dev/disk/by-id/scsi-<serial_number> 
    4
    Copy to Clipboard Toggle word wrap
    1
    要安装 Ignition 配置的位置。
    2
    所需的二级控制台。在这种情况下,是图形控制台。省略这个选项将禁用图形控制台。
    3
    所需的主控制台。在这种情况下,是串行控制台。options 字段定义 baud 速率和其他设置。此字段的一个常见值为 115200n8。如果没有提供选项,则使用默认内核值 9600n8。有关这个选项格式的更多信息,请参阅 Linux 内核串口控制台文档。
    4
    要安装到的指定磁盘。如果省略这个选项,ISO 镜像会自动运行安装程序,除非还指定了 coreos.inst.install_dev 内核参数。
    注意

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

    自定义会被应用,并影响每个后续 ISO 镜像引导。

  3. 可选: 要删除 ISO 镜像自定义并将镜像返回到其原始状态,请运行以下命令:

    $ coreos-installer iso reset rhcos-<version>-live.x86_64.iso
    Copy to Clipboard Toggle word wrap

    现在,您可以重新自定义 live ISO 镜像,或者在其原始状态中使用它。

您可以使用 custom 子命令的 --ignition-ca 标志向 Ignition 提供证书颁发机构(CA)证书。您可以在安装过程中使用 CA 证书,并在置备安装的系统时使用 CA 证书。

注意

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

流程

  1. coreos-installer 镜像镜像页面下载 coreos-installer 二进制文件。
  2. 从 RHCOS 镜像镜像页面检索 RHCOS ISO 镜像,并运行以下命令来自定义 ISO 镜像以用于自定义 CA:

    $ coreos-installer iso customize rhcos-<version>-live.x86_64.iso --ignition-ca cert.pem
    Copy to Clipboard Toggle word wrap
重要

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

应用自定义 CA 证书会影响每个后续 RHCOS 引导。

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

警告

在创建连接配置文件时,您必须在连接配置文件的文件名中使用 .nmconnection 文件名扩展名。如果不使用 .nmconnection 文件名扩展,集群会将连接配置集应用到 live 环境,但它不会在集群首次启动节点时应用配置,从而导致无法正常工作的设置。

流程

  1. coreos-installer 镜像镜像页面下载 coreos-installer 二进制文件。
  2. 为绑定接口创建连接配置集。例如,在本地目录中创建 bond0.nmconnection 文件,其内容如下:

    [connection]
    id=bond0
    type=bond
    interface-name=bond0
    multi-connect=1
    
    [bond]
    miimon=100
    mode=active-backup
    
    [ipv4]
    method=auto
    
    [ipv6]
    method=auto
    Copy to Clipboard Toggle word wrap
  3. 为二级接口创建连接配置集,以添加到绑定中。例如,在本地目录中创建 bond0-proxy-em1.nmconnection 文件,其内容如下:

    [connection]
    id=em1
    type=ethernet
    interface-name=em1
    master=bond0
    multi-connect=1
    slave-type=bond
    Copy to Clipboard Toggle word wrap
  4. 为二级接口创建连接配置集,以添加到绑定中。例如,在本地目录中创建 bond0-proxy-em2.nmconnection 文件,其内容如下:

    [connection]
    id=em2
    type=ethernet
    interface-name=em2
    master=bond0
    multi-connect=1
    slave-type=bond
    Copy to Clipboard Toggle word wrap
  5. RHCOS 镜像镜像页面检索 RHCOS ISO 镜像,并运行以下命令来使用您配置网络自定义 ISO 镜像:

    $ coreos-installer iso customize rhcos-<version>-live.x86_64.iso \
        --network-keyfile bond0.nmconnection \
        --network-keyfile bond0-proxy-em1.nmconnection \
        --network-keyfile bond0-proxy-em2.nmconnection
    Copy to Clipboard Toggle word wrap

    网络设置应用于实时系统,并传输到目标系统。

您可以设置 iSCSI 目标和 initiator 值,以便使用自定义的 live RHCOS 镜像版本自动挂载、引导和配置。

先决条件

  1. 您有一个 iSCSI 目标,您要在其中安装 RHCOS。

流程

  1. coreos-installer 镜像镜像页面下载 coreos-installer 二进制文件。
  2. RHCOS 镜像镜像页面检索 RHCOS ISO 镜像,并运行以下命令使用以下信息自定义 ISO 镜像:

    $ coreos-installer iso customize \
        --pre-install mount-iscsi.sh \ 
    1
    
        --post-install unmount-iscsi.sh \ 
    2
    
        --dest-device /dev/disk/by-path/<IP_address>:<port>-iscsi-<target_iqn>-lun-<lun> \ 
    3
    
        --dest-ignition config.ign \ 
    4
    
        --dest-karg-append rd.iscsi.initiator=<initiator_iqn> \ 
    5
    
        --dest-karg-append netroot=<target_iqn> \ 
    6
    
        -o custom.iso rhcos-<version>-live.x86_64.iso
    Copy to Clipboard Toggle word wrap
    1
    安装之前运行的脚本。它应包含用于挂载 iSCSI 目标以及启用多路径的任何命令的 iscsiadm 命令。
    2
    安装后运行的脚本。它应包含命令 iscsiadm --mode node --logout=all
    3
    目标系统的位置。您必须提供目标门户的 IP 地址、关联的端口号、目标 iSCSI 节点采用 IQN 格式,以及 iSCSI 逻辑单元号(LUN)。
    4
    目标系统的 Ignition 配置。
    5
    iSCSI 启动器或客户端,以 IQN 格式的名称。启动器构成连接到 iSCSI 目标的一个会话。
    6
    iSCSI 目标或服务器的名称(IQN 格式)。

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

您可以设置 iSCSI 目标和 initiator 值,以便使用自定义的 live RHCOS 镜像版本自动挂载、引导和配置。

先决条件

  1. 您有一个 iSCSI 目标,您要在其中安装 RHCOS。
  2. 可选:有多路径 iSCSI 目标。

流程

  1. coreos-installer 镜像镜像页面下载 coreos-installer 二进制文件。
  2. RHCOS 镜像镜像页面检索 RHCOS ISO 镜像,并运行以下命令使用以下信息自定义 ISO 镜像:

    $ coreos-installer iso customize \
        --pre-install mount-iscsi.sh \ 
    1
    
        --post-install unmount-iscsi.sh \ 
    2
    
        --dest-device /dev/mapper/mpatha \ 
    3
    
        --dest-ignition config.ign \ 
    4
    
        --dest-karg-append rd.iscsi.firmware=1 \ 
    5
    
        --dest-karg-append rd.multipath=default \ 
    6
    
        -o custom.iso rhcos-<version>-live.x86_64.iso
    Copy to Clipboard Toggle word wrap
    1
    安装之前运行的脚本。它应包含用于挂载 iSCSI 目标以及启用多路径的任何命令的 iscsiadm 命令。
    2
    安装后运行的脚本。它应包含命令 iscsiadm --mode node --logout=all
    3
    设备的路径。如果连接了多个多路径设备,或者需要明确指定,您使用多路径(/dev/mapper/mpatha),您可以使用 /dev/disk/by-path 中可用的 World Wide Name (WWN) 符号链接。
    4
    目标系统的 Ignition 配置。
    5
    iSCSI 参数从 BIOS 固件读取。
    6
    可选:如果您要启用多路径,请包含此参数。

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

2.1.13.3.8. 自定义 live RHCOS PXE 环境

您可以使用 coreos-installer pxe customize 子命令直接自定义 live RHCOS PXE 环境。当您引导 PXE 环境时,会自动应用自定义。

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

流程

  1. coreos-installer 镜像镜像页面下载 coreos-installer 二进制文件。
  2. RHCOS 镜像镜像页面和 Ignition 配置文件获取 RHCOS kernel, initramfsrootfs 文件,然后运行以下命令创建一个包含 Ignition 配置中的自定义的新 initramfs 文件:

    $ coreos-installer pxe customize rhcos-<version>-live-initramfs.x86_64.img \
        --dest-ignition bootstrap.ign \ 
    1
    
        --dest-device /dev/disk/by-id/scsi-<serial_number> \ 
    2
    
        -o rhcos-<version>-custom-initramfs.x86_64.img 
    3
    Copy to Clipboard Toggle word wrap
    1
    openshift-installer 生成的 Ignition 配置文件。
    2
    当您指定这个选项时,PXE 环境会自动运行安装。否则,为安装配置了镜像,除非指定了 coreos.inst.install_dev 内核参数,否则不会自动这样做。
    3
    在 PXE 配置中使用自定义 initramfs 文件。添加 ignition.firstbootignition.platform.id=metal 内核参数(如果它们尚不存在)。

应用您的自定义会影响每个后续 RHCOS 引导。

在使用 OpenShift Container Platform 4.12 及更高版本安装的集群中,串行控制台默认被禁用,所有输出都会写入图形控制台。您可以按照以下流程启用串行控制台。

流程

  1. coreos-installer 镜像镜像页面下载 coreos-installer 二进制文件。
  2. RHCOS image mirror 页面获取 kernel, initramfsrootfs 文件,然后运行以下命令来创建新的自定义 initramfs 文件,以便串行控制台接收输出:

    $ coreos-installer pxe customize rhcos-<version>-live-initramfs.x86_64.img \
      --dest-ignition <path> \
    1
    
      --dest-console tty0 \
    2
    
      --dest-console ttyS0,<options> \
    3
    
      --dest-device /dev/disk/by-id/scsi-<serial_number> \
    4
    
      -o rhcos-<version>-custom-initramfs.x86_64.img 
    5
    Copy to Clipboard Toggle word wrap
    1
    要安装 Ignition 配置的位置。
    2
    所需的二级控制台。在这种情况下,是图形控制台。省略这个选项将禁用图形控制台。
    3
    所需的主控制台。在这种情况下,是串行控制台。options 字段定义 baud 速率和其他设置。此字段的一个常见值为 115200n8。如果没有提供选项,则使用默认内核值 9600n8。有关这个选项格式的更多信息,请参阅 Linux 内核串口控制台文档。
    4
    要安装到的指定磁盘。如果省略这个选项,PXE 环境会自动运行安装程序,除非还指定了 coreos.inst.install_dev 内核参数。
    5
    在 PXE 配置中使用自定义 initramfs 文件。添加 ignition.firstbootignition.platform.id=metal 内核参数(如果它们尚不存在)。

    自定义会被应用,并影响 PXE 环境的每个后续引导。

您可以使用 custom 子命令的 --ignition-ca 标志向 Ignition 提供证书颁发机构(CA)证书。您可以在安装过程中使用 CA 证书,并在置备安装的系统时使用 CA 证书。

注意

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

流程

  1. coreos-installer 镜像镜像页面下载 coreos-installer 二进制文件。
  2. RHCOS 镜像镜像页面获取 RHCOS kernelinitramfsrootfs 文件,并运行以下命令来创建一个新的自定义 initramfs 文件以用于自定义 CA:

    $ coreos-installer pxe customize rhcos-<version>-live-initramfs.x86_64.img \
        --ignition-ca cert.pem \
        -o rhcos-<version>-custom-initramfs.x86_64.img
    Copy to Clipboard Toggle word wrap
  3. 在 PXE 配置中使用自定义 initramfs 文件。添加 ignition.firstbootignition.platform.id=metal 内核参数(如果它们尚不存在)。
重要

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

应用自定义 CA 证书会影响每个后续 RHCOS 引导。

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

警告

在创建连接配置文件时,您必须在连接配置文件的文件名中使用 .nmconnection 文件名扩展名。如果不使用 .nmconnection 文件名扩展,集群会将连接配置集应用到 live 环境,但它不会在集群首次启动节点时应用配置,从而导致无法正常工作的设置。

流程

  1. coreos-installer 镜像镜像页面下载 coreos-installer 二进制文件。
  2. 为绑定接口创建连接配置集。例如,在本地目录中创建 bond0.nmconnection 文件,其内容如下:

    [connection]
    id=bond0
    type=bond
    interface-name=bond0
    multi-connect=1
    
    [bond]
    miimon=100
    mode=active-backup
    
    [ipv4]
    method=auto
    
    [ipv6]
    method=auto
    Copy to Clipboard Toggle word wrap
  3. 为二级接口创建连接配置集,以添加到绑定中。例如,在本地目录中创建 bond0-proxy-em1.nmconnection 文件,其内容如下:

    [connection]
    id=em1
    type=ethernet
    interface-name=em1
    master=bond0
    multi-connect=1
    slave-type=bond
    Copy to Clipboard Toggle word wrap
  4. 为二级接口创建连接配置集,以添加到绑定中。例如,在本地目录中创建 bond0-proxy-em2.nmconnection 文件,其内容如下:

    [connection]
    id=em2
    type=ethernet
    interface-name=em2
    master=bond0
    multi-connect=1
    slave-type=bond
    Copy to Clipboard Toggle word wrap
  5. RHCOS 镜像镜像页面获取 RHCOS kernelinitramfsrootfs 文件,并运行以下命令来创建一个新的自定义 initramfs 文件,它包括您的配置网络:

    $ coreos-installer pxe customize rhcos-<version>-live-initramfs.x86_64.img \
        --network-keyfile bond0.nmconnection \
        --network-keyfile bond0-proxy-em1.nmconnection \
        --network-keyfile bond0-proxy-em2.nmconnection \
        -o rhcos-<version>-custom-initramfs.x86_64.img
    Copy to Clipboard Toggle word wrap
  6. 在 PXE 配置中使用自定义 initramfs 文件。添加 ignition.firstbootignition.platform.id=metal 内核参数(如果它们尚不存在)。

    网络设置应用于实时系统,并传输到目标系统。

您可以设置 iSCSI 目标和 initiator 值,以便使用自定义的 live RHCOS 镜像版本自动挂载、引导和配置。

先决条件

  1. 您有一个 iSCSI 目标,您要在其中安装 RHCOS。

流程

  1. coreos-installer 镜像镜像页面下载 coreos-installer 二进制文件。
  2. RHCOS image mirror 页获取 RHCOS kernelinitramfsrootfs 文件,并运行以下命令来使用以下信息创建新的自定义 initramfs 文件:

    $ coreos-installer pxe customize \
        --pre-install mount-iscsi.sh \ 
    1
    
        --post-install unmount-iscsi.sh \ 
    2
    
        --dest-device /dev/disk/by-path/<IP_address>:<port>-iscsi-<target_iqn>-lun-<lun> \ 
    3
    
        --dest-ignition config.ign \ 
    4
    
        --dest-karg-append rd.iscsi.initiator=<initiator_iqn> \ 
    5
    
        --dest-karg-append netroot=<target_iqn> \ 
    6
    
        -o custom.img rhcos-<version>-live-initramfs.x86_64.img
    Copy to Clipboard Toggle word wrap
    1
    安装之前运行的脚本。它应包含用于挂载 iSCSI 目标以及启用多路径的任何命令的 iscsiadm 命令。
    2
    安装后运行的脚本。它应包含命令 iscsiadm --mode node --logout=all
    3
    目标系统的位置。您必须提供目标门户的 IP 地址、关联的端口号、目标 iSCSI 节点采用 IQN 格式,以及 iSCSI 逻辑单元号(LUN)。
    4
    目标系统的 Ignition 配置。
    5
    iSCSI 启动器或客户端,以 IQN 格式的名称。启动器构成连接到 iSCSI 目标的一个会话。
    6
    iSCSI 目标或服务器的名称(IQN 格式)。

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

您可以设置 iSCSI 目标和 initiator 值,以便使用自定义的 live RHCOS 镜像版本自动挂载、引导和配置。

先决条件

  1. 您有一个 iSCSI 目标,您要在其中安装 RHCOS。
  2. 可选:有多路径 iSCSI 目标。

流程

  1. coreos-installer 镜像镜像页面下载 coreos-installer 二进制文件。
  2. RHCOS image mirror 页获取 RHCOS kernelinitramfsrootfs 文件,并运行以下命令来使用以下信息创建新的自定义 initramfs 文件:

    $ coreos-installer pxe customize \
        --pre-install mount-iscsi.sh \ 
    1
    
        --post-install unmount-iscsi.sh \ 
    2
    
        --dest-device /dev/mapper/mpatha \ 
    3
    
        --dest-ignition config.ign \ 
    4
    
        --dest-karg-append rd.iscsi.firmware=1 \ 
    5
    
        --dest-karg-append rd.multipath=default \ 
    6
    
        -o custom.img rhcos-<version>-live-initramfs.x86_64.img
    Copy to Clipboard Toggle word wrap
    1
    安装之前运行的脚本。它应包含用于挂载 iSCSI 目标的 iscsiadm 命令。
    2
    安装后运行的脚本。它应包含命令 iscsiadm --mode node --logout=all
    3
    设备的路径。如果连接了多个多路径设备,或者需要明确指定,您使用多路径(/dev/mapper/mpatha),您可以使用 /dev/disk/by-path 中可用的 World Wide Name (WWN) 符号链接。
    4
    目标系统的 Ignition 配置。
    5
    iSCSI 参数从 BIOS 固件读取。
    6
    可选:如果您要启用多路径,请包含此参数。

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

2.1.13.3.9. 高级 RHCOS 安装参考

本节演示了网络配置和其他高级选项,允许您修改 Red Hat Enterprise Linux CoreOS(RHCOS)手动安装过程。下表描述了您可以用于 RHCOS live 安装程序和 coreos-installer 命令的内核参数和命令行选项。

2.1.13.3.9.1. ISO 安装的网络和绑定选项

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

重要

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

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

注意

添加内核参数时顺序非常重要: ip=、name server=,然后 bond=

网络选项在系统引导过程中传递给 dracut 工具。有关 dracut 支持的网络选项的更多信息,请参阅 dracut.cmdline 手册页

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

2.1.13.3.9.1.1. 配置 DHCP 或静态 IP 地址

要配置 IP 地址,可使用 DHCP(ip=dhcp)或设置单独的静态 IP 地址(ip=<host_ip>)。如果设置静态 IP,则必须在每个节点上识别 DNS 服务器 IP 地址(名称服务器=<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
Copy to Clipboard Toggle word wrap
注意

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

2.1.13.3.9.1.2. 配置没有静态主机名的 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
Copy to Clipboard Toggle word wrap
2.1.13.3.9.1.3. 指定多个网络接口

您可以通过设置多个 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
Copy to Clipboard Toggle word wrap
2.1.13.3.9.1.4. 配置默认网关和路由

可选:您可以通过设置 a rd.route= 值来配置到额外网络的路由。

注意

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

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

    ip=::10.10.10.254::::
    Copy to Clipboard Toggle word wrap
  • 输入以下命令为额外网络配置路由:

    rd.route=20.20.20.0/24:20.20.20.254:enp2s0
    Copy to Clipboard Toggle word wrap
2.1.13.3.9.1.5. 在单个接口中禁用 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
Copy to Clipboard Toggle word wrap
2.1.13.3.9.1.6. 合并 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
Copy to Clipboard Toggle word wrap
2.1.13.3.9.1.7. 在独立接口上配置 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
    Copy to Clipboard Toggle word wrap
  • 要在网络接口中配置 VLAN 并使用 DHCP,请运行以下命令:

    ip=enp2s0.100:dhcp
    vlan=enp2s0.100:enp2s0
    Copy to Clipboard Toggle word wrap
2.1.13.3.9.1.8. 提供多个 DNS 服务器

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

nameserver=1.1.1.1
nameserver=8.8.8.8
Copy to Clipboard Toggle word wrap
2.1.13.3.9.1.9. 将多个网络接口绑定到一个接口

可选: 您可以使用 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
      Copy to Clipboard Toggle word wrap
    • 要将绑定接口配置为使用静态 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
      Copy to Clipboard Toggle word wrap

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

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

  1. 按照管理 SR-IOV 设备中的指导创建 SR-IOV 虚拟功能(VF)。按照"将 SR-IOV 网络设备附加到虚拟机"部分中的步骤操作。
  2. 创建绑定,将所需的 VF 附加到绑定,并根据配置网络绑定的指导设置绑定链接状态。按照任何描述的步骤创建绑定。

以下示例演示了您必须使用的语法:

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

    <name> 是绑定设备名称 (bond0)、<network_interfaces> 由内核中已知的名称来代表虚拟功能(VF),并显示在 ip link 命令的输出中 (eno1f0,eno2f0),options 是以逗号分隔的绑定选项列表。输入 modinfo bonding 查看可用选项。

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

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

      bond=bond0:eno1f0,eno2f0:mode=active-backup
      ip=bond0:dhcp
      Copy to Clipboard Toggle word wrap
    • 要将绑定接口配置为使用静态 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
      Copy to Clipboard Toggle word wrap
2.1.13.3.9.1.11. 使用网络团队

可选: 您可以使用 team= 参数来将网络团队用作绑定的替代选择:

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

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

注意

当 RHCOS 切换到即将推出的 RHEL 版本时,团队(team)功能被计划弃用。如需更多信息,请参阅红帽知识库文章

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

team=team0:em1,em2
ip=team0:dhcp
Copy to Clipboard Toggle word wrap
2.1.13.3.9.2. ISO 和 PXE 安装的 coreos-installer 选项

从 ISO 镜像引导 RHCOS live 环境后,您可以通过 在命令提示符下运行 coreos-installer install <options> <device > 来安装 RHCOS。

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

Expand
表 2.9. coreos-installer 子命令、命令行选项和参数

coreos-installer install 子命令

子命令

描述

$ coreos-installer install <options> <device>

在 ISO 镜像中嵌入 Ignition 配置。

coreos-installer install 子命令选项

选项

描述

-u, --image-url <url>

手动指定镜像 URL。

-f,--image-file <path>

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

-i, --ignition-file <path>

从文件中嵌入 Ignition 配置。

-i,--ignition-url <URL>

从 URL 嵌入 Ignition 配置。

--ignition-hash <digest>

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

-p, --platform <name>

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

--console <spec>

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

--append-karg <arg>…​

将默认内核参数附加到安装的系统中。

--delete-karg <arg>…​

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

-n, --copy-network

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

重要

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

--network-dir <path>

用于 -n。默认为 /etc/NetworkManager/system-connections/

--save-partlabel <lx>..

使用这个标签 glob 保存分区。

--save-partindex <id>…​

使用这个数值或范围保存分区。

--insecure

跳过 RHCOS 镜像签名验证。

--insecure-ignition

允许没有 HTTPS 或 hash 的 Ignition URL。

--architecture <name>

目标 CPU 架构.有效值为 x86_64aarch64

--preserve-on-error

出错时不要清除分区表。

-h,--help

打印帮助信息.

coreos-installer install 子命令参数

参数

描述

<device>

目标设备.

coreos-installer ISO 子命令

子命令

描述

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

自定义 RHCOS live ISO 镜像。

coreos-installer iso reset <options> <ISO_image>

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

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

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

coreos-installer ISO customize 子命令选项

选项

描述

--dest-ignition <path>

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

--dest-console <spec>

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

--dest-device <path>

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

--dest-karg-append <arg>

为每个目标系统引导添加一个内核参数。

--dest-karg-delete <arg>

从目标系统的每个引导中删除内核参数。

--network-keyfile <path>

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

--ignition-ca <path>

指定要被 Ignition 信任的额外 TLS 证书颁发机构。

--pre-install <path>

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

--post-install <path>

安装后运行指定的脚本。

--installer-config <path>

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

--live-ignition <path>

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

--live-karg-append <arg>

为每个实时环境引导添加一个内核参数。

--live-karg-delete <arg>

从实时环境每次引导时删除内核参数。

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

在每次启动 live 环境时替换内核参数,格式为 key=old=new

-f,--force

覆盖现有的 Ignition 配置。

-o,--output <path>

将 ISO 写入到新的输出文件。

-h,--help

打印帮助信息.

coreos-installer PXE 子命令

子命令

描述

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

coreos-installer pxe customize <options> <path>

自定义 RHCOS live PXE 引导配置。

coreos-installer pxe ignition wrap <options>

在镜像中嵌套 Ignition 配置。

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

在镜像中显示嵌套的 Ignition 配置。

coreos-installer PXE customize 子命令选项

选项

描述

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

--dest-ignition <path>

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

--dest-console <spec>

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

--dest-device <path>

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

--network-keyfile <path>

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

--ignition-ca <path>

指定要被 Ignition 信任的额外 TLS 证书颁发机构。

--pre-install <path>

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

post-install <path>

安装后运行指定的脚本。

--installer-config <path>

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

--live-ignition <path>

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

-o, --output <path>

将 initramfs 写入一个新输出文件。

注意

PXE 环境需要这个选项。

-h,--help

打印帮助信息.

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

  • 对于 ISO 安装,可以通过在启动加载器菜单中中断自动引导来添加 coreos.inst 选项。您可以在突出显示 RHEL CoreOS(Live) 菜单选项时按 TAB 来中断自动引导。
  • 对于 PXE 或 iPXE 安装,在引导 RHCOS live 安装程序前,coreos.inst 选项必须添加到 APPEND 行。

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

Expand
表 2.10. coreos.inst 引导选项
参数描述

coreos.inst.install_dev

必需。要安装到的系统中的块设备。

注意

建议您使用完整路径,如 /dev/sda,但 允许使用

coreos.inst.ignition_url

可选:嵌入到安装的系统中的 Ignition 配置的 URL。如果没有指定 URL,则不会嵌入 Ignition 配置。仅支持 HTTP 和 HTTPS 协议。

coreos.inst.save_partlabel

可选:在安装过程中要保留的分区分离标签。允许使用 glob 风格的通配符。指定分区不需要存在。

coreos.inst.save_partindex

可选:在安装过程中压缩要保留的分区索引。允许 m-n 范围,mn 可以被省略。指定分区不需要存在。

coreos.inst.insecure

可选:将 coreos.inst.image_url 指定的 OS 镜像提交取消签名。

coreos.inst.image_url

可选:下载并安装指定的 RHCOS 镜像。

  • 这个参数不应该在生产环境中使用,而是只用于调试目的。
  • 虽然此参数可用于安装与 live 介质不匹配的 RHCOS 版本,但建议您使用与您要安装版本匹配的介质。
  • 如果您使用 coreos.inst.image_url,还必须使用 coreos.inst.insecure。这是因为,裸机介质没有为 OpenShift Container Platform 进行 GPG 签名。
  • 仅支持 HTTP 和 HTTPS 协议。

coreos.inst.skip_reboot

可选:安装后系统不会重启。安装完成后,您将收到提示,提示您检查在安装过程中发生的情况。这个参数不应该在生产环境中使用,而是只用于调试目的。

coreos.inst.platform_id

可选:安装 RHCOS 镜像的平台的 Ignition 平台 ID。默认为 metal。这个选项决定是否从云供应商(如 VMware)请求 Ignition 配置。例如: coreos.inst.platform_id=vmware

ignition.config.url

可选:用于实时引导的 Ignition 配置的 URL。例如,这可用于自定义调用 coreos-installer 的方式,或者用于在安装前或安装后运行代码。这与 coreos.inst.ignition_url (这是已安装系统的 Ignition 配置)不同。

2.1.13.4. 在 RHCOS 上启用带有内核参数的多路径

RHCOS 支持主磁盘上的多路径,支持更强大的硬件故障弹性,以获得更高的主机可用性。

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

在任何 I/O 到未优化路径会导致 I/O 系统错误的设置中,您必须在安装时启用多路径。

重要

在 IBM Z® 和 IBM® LinuxONE 中,您只能在在安装过程中为它配置集群时启用多路径。如需更多信息,请参阅在 IBM Z® 和 IBM® LinuxONE 上安装使用 z/VM 的集群"安装 RHCOS 并启动 OpenShift Container Platform bootstrap 过程"。

以下流程在安装时启用多路径,并在 coreos-installer install 命令中附加内核参数,以便安装的系统本身将使用从第一次引导开始的多路径。

注意

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

先决条件

  • 已为集群创建 Ignition 配置文件。
  • 您已参阅 安装 RHCOS 并启动 OpenShift Container Platform bootstrap 过程

流程

  1. 要启用多路径并启动 multipathd 守护进程,请在安装主机上运行以下命令:

    $ mpathconf --enable && systemctl start multipathd.service
    Copy to Clipboard Toggle word wrap
    • 可选:如果引导 PXE 或 ISO,则可以通过从内核命令行添加 rd.multipath=default 来启用多路径。
  2. 通过调用 coreos-installer 程序附加内核参数:

    • 如果只有一个多路径设备连接到计算机,则应在路径 /dev/mapper/mpatha 上可用。例如:

      $ coreos-installer install /dev/mapper/mpatha \
      1
      
      --ignition-url=http://host/worker.ign \
      --append-karg rd.multipath=default \
      --append-karg root=/dev/disk/by-label/dm-mpath-root \
      --append-karg rw
      Copy to Clipboard Toggle word wrap
      1
      表示单一多路径设备的路径。
    • 如果有多个多路径设备连接到计算机,或者更为明确,而不是使用 /dev/mapper/mpatha,则建议使用 /dev/disk/by-id 中可用的 World Wide Name(WWN)符号链接。例如:

      $ coreos-installer install /dev/disk/by-id/wwn-<wwn_ID> \
      1
      
      --ignition-url=http://host/worker.ign \
      --append-karg rd.multipath=default \
      --append-karg root=/dev/disk/by-label/dm-mpath-root \
      --append-karg rw
      Copy to Clipboard Toggle word wrap
      1
      表示目标多路径设备的 WWN ID。例如: 0xx194e957fcedb4841

      当使用特殊 coreos.inst.* 参数指示 live 安装程序时,这个符号链接也可以用作 coreos.inst.install_dev 内核参数。如需更多信息,请参阅"安装 RHCOS 和启动 OpenShift Container Platform bootstrap 过程"。

  3. 重启安装的系统。
  4. 前往其中一个 worker 节点并列出内核命令行参数(主机上的 /proc/cmdline 中),以检查内核参数是否正常工作:

    $ oc debug node/ip-10-0-141-105.ec2.internal
    Copy to Clipboard Toggle word wrap

    输出示例

    Starting pod/ip-10-0-141-105ec2internal-debug ...
    To use host binaries, run `chroot /host`
    
    sh-4.2# cat /host/proc/cmdline
    ...
    rd.multipath=default root=/dev/disk/by-label/dm-mpath-root
    ...
    
    sh-4.2# exit
    Copy to Clipboard Toggle word wrap

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

2.1.13.4.1. 在辅助磁盘中启用多路径

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

先决条件

  • 您已阅读了磁盘分区一节。
  • 您已在 RHCOS 中使用内核参数读取启用多路径
  • 已安装 Butane 工具。

流程

  1. 使用类似如下的信息创建一个 Butane 配置:

    multipath-config.bu 示例

    variant: openshift
    version: 4.19.0
    systemd:
      units:
        - name: mpath-configure.service
          enabled: true
          contents: |
            [Unit]
            Description=Configure Multipath on Secondary Disk
            ConditionFirstBoot=true
            ConditionPathExists=!/etc/multipath.conf
            Before=multipathd.service 
    1
    
            DefaultDependencies=no
    
            [Service]
            Type=oneshot
            ExecStart=/usr/sbin/mpathconf --enable 
    2
    
    
            [Install]
            WantedBy=multi-user.target
        - name: mpath-var-lib-container.service
          enabled: true
          contents: |
            [Unit]
            Description=Set Up Multipath On /var/lib/containers
            ConditionFirstBoot=true 
    3
    
            Requires=dev-mapper-mpatha.device
            After=dev-mapper-mpatha.device
            After=ostree-remount.service
            Before=kubelet.service
            DefaultDependencies=no
    
            [Service] 
    4
    
            Type=oneshot
            ExecStart=/usr/sbin/mkfs.xfs -L containers -m reflink=1 /dev/mapper/mpatha
            ExecStart=/usr/bin/mkdir -p /var/lib/containers
    
            [Install]
            WantedBy=multi-user.target
        - name: var-lib-containers.mount
          enabled: true
          contents: |
            [Unit]
            Description=Mount /var/lib/containers
            After=mpath-var-lib-containers.service
            Before=kubelet.service 
    5
    
    
            [Mount] 
    6
    
            What=/dev/disk/by-label/dm-mpath-containers
            Where=/var/lib/containers
            Type=xfs
    
            [Install]
            WantedBy=multi-user.target
    Copy to Clipboard Toggle word wrap

    1
    在启动 multipath 守护进程前,必须设置配置。
    2
    启动 mpathconf 实用程序。
    3
    此字段必须设置为 true
    4
    创建文件系统和目录 /var/lib/containers
    5
    在启动任何节点前必须挂载该设备。
    6
    将设备挂载到 /var/lib/containers 挂载点。此位置不能是符号链接。
  2. 运行以下命令来创建 Ignition 配置:

    $ butane --pretty --strict multipath-config.bu > multipath-config.ign
    Copy to Clipboard Toggle word wrap
  3. 继续第一个引导 RHCOS 安装过程的其余部分。

    重要

    不要在安装过程中在命令行上添加 rd.multipathroot 内核参数,除非主磁盘也是多路径的。

2.1.13.5. 在 iSCSI 引导设备中手动安装 RHCOS

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

先决条件

  1. 您在 RHCOS live 环境中。
  2. 您有一个要在其上安装 RHCOS 的 iSCSI 目标。

流程

  1. 运行以下命令,从 live 环境中挂载 iSCSI 目标:

    $ iscsiadm \
        --mode discovery \
        --type sendtargets
        --portal <IP_address> \ 
    1
    
        --login
    Copy to Clipboard Toggle word wrap
    1
    目标门户的 IP 地址。
  2. 运行以下命令并使用必要的内核参数将 RHCOS 安装到 iSCSI 目标上,例如:

    $ coreos-installer install \
    /dev/disk/by-path/ip-<IP_address>:<port>-iscsi-<target_iqn>-lun-<lun> \ 
    1
    
    --append-karg rd.iscsi.initiator=<initiator_iqn> \ 
    2
    
    --append.karg netroot=<target_iqn> \ 
    3
    
    --console ttyS0,115200n8
    --ignition-file <path_to_file>
    Copy to Clipboard Toggle word wrap
    1
    您要安装到的位置。您必须提供目标门户的 IP 地址、关联的端口号、目标 iSCSI 节点采用 IQN 格式,以及 iSCSI 逻辑单元号(LUN)。
    2
    iSCSI 启动器或客户端,以 IQN 格式的名称。启动器构成连接到 iSCSI 目标的一个会话。
    3
    iSCSI 目标或服务器的名称(IQN 格式)。

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

  3. 使用以下命令卸载 iSCSI 磁盘:

    $ iscsiadm --mode node --logoutall=all
    Copy to Clipboard Toggle word wrap

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

2.1.13.6. 使用 iBFT 在 iSCSI 引导设备中安装 RHCOS

在一个完全无盘机器上,也可以通过 iBFT. iSCSI 多路径传递 iSCSI 目标和启动器值。

先决条件

  1. 您在 RHCOS live 环境中。
  2. 您有一个 iSCSI 目标,您要在其中安装 RHCOS。
  3. 可选:有多路径 iSCSI 目标。

流程

  1. 运行以下命令,从 live 环境中挂载 iSCSI 目标:

    $ iscsiadm \
        --mode discovery \
        --type sendtargets
        --portal <IP_address> \ 
    1
    
        --login
    Copy to Clipboard Toggle word wrap
    1
    目标门户的 IP 地址。
  2. 可选:使用以下命令启用多路径并启动守护进程:

    $ mpathconf --enable && systemctl start multipathd.service
    Copy to Clipboard Toggle word wrap
  3. 运行以下命令并使用必要的内核参数将 RHCOS 安装到 iSCSI 目标上,例如:

    $ coreos-installer install \
        /dev/mapper/mpatha \ 
    1
    
        --append-karg rd.iscsi.firmware=1 \ 
    2
    
        --append-karg rd.multipath=default \ 
    3
    
        --console ttyS0 \
        --ignition-file <path_to_file>
    Copy to Clipboard Toggle word wrap
    1
    单一多路径设备的路径。如果连接了多个多路径设备,或者需要明确指定,您可以使用 /dev/disk/by-path 中可用的 World Wide Name (WWN) 符号链接。
    2
    iSCSI 参数从 BIOS 固件读取。
    3
    可选:如果您要启用多路径,请包含此参数。

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

  4. 卸载 iSCSI 磁盘:

    $ iscsiadm --mode node --logout=all
    Copy to Clipboard Toggle word wrap

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

2.1.14. 等待 bootstrap 过程完成

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

先决条件

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

流程

  1. 监控 bootstrap 过程:

    $ ./openshift-install --dir <installation_directory> wait-for bootstrap-complete \ 
    1
    
        --log-level=info 
    2
    Copy to Clipboard Toggle word wrap
    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.32.3 up
    INFO Waiting up to 30m0s for bootstrapping to complete...
    INFO It is now safe to remove the bootstrap resources
    Copy to Clipboard Toggle word wrap

    当 Kubernetes API 服务器提示已在 control plane 机器上引导它时,该命令会成功。

  2. bootstrap 过程完成后,从负载均衡器中删除 bootstrap 机器。

    重要

    此时您必须从负载均衡器中删除 bootstrap 机器。您还可以删除或重新格式化 bootstrap 机器本身。

2.1.15. 使用 CLI 登录集群

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

先决条件

  • 已部署 OpenShift Container Platform 集群。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 运行以下命令来导出 kubeadmin 凭证:

    $ export KUBECONFIG=<installation_directory>/auth/kubeconfig 
    1
    Copy to Clipboard Toggle word wrap
    1
    对于 <installation_directory>,请指定安装文件保存到的目录的路径。
  2. 运行以下命令,使用导出的配置成功运行 oc 命令:

    $ oc whoami
    Copy to Clipboard Toggle word wrap

    输出示例

    system:admin
    Copy to Clipboard Toggle word wrap

2.1.16. 批准机器的证书签名请求

当您将机器添加到集群时,会为您添加的每台机器生成两个待处理证书签名请求(CSR)。您必须确认这些 CSR 已获得批准,或根据需要自行批准。必须首先批准客户端请求,然后批准服务器请求。

先决条件

  • 您已将机器添加到集群中。

流程

  1. 确认集群可以识别这些机器:

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME      STATUS    ROLES   AGE  VERSION
    master-0  Ready     master  63m  v1.32.3
    master-1  Ready     master  63m  v1.32.3
    master-2  Ready     master  64m  v1.32.3
    Copy to Clipboard Toggle word wrap

    输出中列出了您创建的所有机器。

    注意

    在有些 CSR 被批准前,前面的输出可能不包括计算节点(也称为 worker 节点)。

  2. 检查待处理的 CSR,并确保添加到集群中的每台机器都有 PendingApproved 状态的客户端请求:

    $ oc get csr
    Copy to Clipboard Toggle word wrap

    输出示例

    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
    ...
    Copy to Clipboard Toggle word wrap

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

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

    注意

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

    注意

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

    • 要单独批准,请对每个有效的 CSR 运行以下命令:

      $ oc adm certificate approve <csr_name> 
      1
      Copy to Clipboard Toggle word wrap
      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
      Copy to Clipboard Toggle word wrap
      注意

      在有些 CSR 被批准前,一些 Operator 可能无法使用。

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

    $ oc get csr
    Copy to Clipboard Toggle word wrap

    输出示例

    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
    ...
    Copy to Clipboard Toggle word wrap

  5. 如果剩余的 CSR 没有被批准,且处于 Pending 状态,请批准集群机器的 CSR:

    • 要单独批准,请对每个有效的 CSR 运行以下命令:

      $ oc adm certificate approve <csr_name> 
      1
      Copy to Clipboard Toggle word wrap
      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
      Copy to Clipboard Toggle word wrap
  6. 批准所有客户端和服务器 CSR 后,机器将 处于 Ready 状态。运行以下命令验证:

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME      STATUS    ROLES   AGE  VERSION
    master-0  Ready     master  73m  v1.32.3
    master-1  Ready     master  73m  v1.32.3
    master-2  Ready     master  74m  v1.32.3
    worker-0  Ready     worker  11m  v1.32.3
    worker-1  Ready     worker  11m  v1.32.3
    Copy to Clipboard Toggle word wrap

    注意

    批准服务器 CSR 后可能需要几分钟时间让机器过渡到 Ready 状态

其他信息

2.1.17. 初始 Operator 配置

在 control plane 初始化后,您必须立即配置一些 Operator,以便它们都可用。

先决条件

  • 您的 control plane 已初始化。

流程

  1. 观察集群组件上线:

    $ watch -n5 oc get clusteroperators
    Copy to Clipboard Toggle word wrap

    输出示例

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

  2. 配置不可用的 Operator。
2.1.17.1. 安装过程中删除的镜像 registry

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

安装后,您必须编辑 Image Registry Operator 配置,将 managementStateRemoved 切换到 Managed。完成此操作后,您必须配置存储。

2.1.17.2. 镜像 registry 存储配置

对于不提供默认存储的平台,Image Registry Operator 最初不可用。安装后,您必须将 registry 配置为使用存储,以便 Registry Operator 可用。

显示配置生产集群所需的持久性卷的说明。如果适用,显示有关将空目录配置为存储位置的说明,这仅适用于非生产集群。

提供了在升级过程中使用 Recreate rollout 策略来允许镜像 registry 使用块存储类型的说明。

作为集群管理员,在安装后需要配置 registry 来使用存储。

先决条件

  • 您可以使用具有 cluster-admin 角色的用户访问集群。
  • 您有一个使用手动置备的 Red Hat Enterprise Linux CoreOS(RHCOS)节点(如裸机)的集群。
  • 您已为集群置备持久性存储,如 Red Hat OpenShift Data Foundation。

    重要

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

  • 必须具有 100Gi 容量。

流程

  1. 要将 registry 配置为使用存储,修改 configs.imageregistry/cluster 资源中的 spec.storage.pvc

    注意

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

  2. 验证您没有 registry pod:

    $ oc get pod -n openshift-image-registry -l docker-registry=default
    Copy to Clipboard Toggle word wrap

    输出示例

    No resources found in openshift-image-registry namespace
    Copy to Clipboard Toggle word wrap

    注意

    如果您的输出中有一个 registry pod,则不需要继续这个过程。

  3. 检查 registry 配置:

    $ oc edit configs.imageregistry.operator.openshift.io
    Copy to Clipboard Toggle word wrap

    输出示例

    storage:
      pvc:
        claim:
    Copy to Clipboard Toggle word wrap

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

  4. 检查 clusteroperator 状态:

    $ oc get clusteroperator image-registry
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME             VERSION              AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
    image-registry   4.19                 True        False         False      6h50m
    Copy to Clipboard Toggle word wrap

  5. 确保 registry 设置为 managed,以启用镜像的构建和推送。

    • 运行:

      $ oc edit configs.imageregistry/cluster
      Copy to Clipboard Toggle word wrap

      然后,更改行

      managementState: Removed
      Copy to Clipboard Toggle word wrap

      managementState: Managed
      Copy to Clipboard Toggle word wrap

您必须为 Image Registry Operator 配置存储。对于非生产集群,您可以将镜像 registry 设置为空目录。如果您这样做,重启 registry 时会丢失所有镜像。

流程

  • 将镜像 registry 存储设置为空目录:

    $ oc patch configs.imageregistry.operator.openshift.io cluster --type merge --patch '{"spec":{"storage":{"emptyDir":{}}}}'
    Copy to Clipboard Toggle word wrap
    警告

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

    如果在 Image Registry Operator 初始化其组件前运行这个命令,oc patch 命令会失败并显示以下错误:

    Error from server (NotFound): configs.imageregistry.operator.openshift.io "cluster" not found
    Copy to Clipboard Toggle word wrap

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

2.1.17.2.3. 为裸机配置块 registry 存储

要允许镜像 registry 在作为集群管理员升级过程中使用块存储类型,您可以使用 Recreate rollout 策略

重要

支持块存储卷或块持久性卷,但不建议在生产环境中使用镜像 registry。在块存储上配置 registry 的安装不具有高可用性,因为 registry 无法具有多个副本。

如果您选择将块存储卷与镜像 registry 搭配使用,则必须使用文件系统持久性卷声明(PVC)。

流程

  1. 输入以下命令将镜像 registry 存储设置为块存储类型,对 registry 进行补丁,使其使用 Recreate rollout 策略,并只使用一个副本运行:1

    $ oc patch config.imageregistry.operator.openshift.io/cluster --type=merge -p '{"spec":{"rolloutStrategy":"Recreate","replicas":1}}'
    Copy to Clipboard Toggle word wrap
  2. 为块存储设备置备 PV,并为该卷创建 PVC。请求的块卷使用 ReadWriteOnce(RWO)访问模式。

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

      kind: PersistentVolumeClaim
      apiVersion: v1
      metadata:
        name: image-registry-storage 
      1
      
        namespace: openshift-image-registry 
      2
      
      spec:
        accessModes:
        - ReadWriteOnce 
      3
      
        resources:
          requests:
            storage: 100Gi 
      4
      Copy to Clipboard Toggle word wrap
      1
      代表 PersistentVolumeClaim 对象的唯一名称。
      2
      PersistentVolumeClaim 对象的命名空间,即 openshift-image-registry
      3
      持久性卷声明的访问模式。使用 ReadWriteOnce 时,单个节点可以通过读写权限挂载该卷。
      4
      持久性卷声明的大小。
    2. 输入以下命令从文件创建 PersistentVolumeClaim 对象:

      $ oc create -f pvc.yaml -n openshift-image-registry
      Copy to Clipboard Toggle word wrap
  3. 输入以下命令编辑 registry 配置,使其引用正确的 PVC:

    $ oc edit config.imageregistry.operator.openshift.io -o yaml
    Copy to Clipboard Toggle word wrap

    输出示例

    storage:
      pvc:
        claim: 
    1
    Copy to Clipboard Toggle word wrap

    1
    通过创建自定义 PVC,您可以将 claim 字段留空,以便默认自动创建 image-registry-storage PVC。

2.1.18. 在用户置备的基础架构上完成安装

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

先决条件

  • 您的 control plane 已初始化。
  • 已完成初始 Operator 配置。

流程

  1. 使用以下命令确认所有集群组件都在线:

    $ watch -n5 oc get clusteroperators
    Copy to Clipboard Toggle word wrap

    输出示例

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

    另外,当所有集群都可用时,以下命令会通知您。它还检索并显示凭证:

    $ ./openshift-install --dir <installation_directory> wait-for install-complete 
    1
    Copy to Clipboard Toggle word wrap
    1
    对于 <installation_directory>,请指定安装文件保存到的目录的路径。

    输出示例

    INFO Waiting up to 30m0s for the cluster to initialize...
    Copy to Clipboard Toggle word wrap

    Cluster Version Operator 完成从 Kubernetes API 服务器部署 OpenShift Container Platform 集群时,该命令会成功。

    重要
    • 安装程序生成的 Ignition 配置文件包含 24 小时后过期的证书,然后在该时进行续订。如果在更新证书前关闭集群,且集群在 24 小时后重启,集群会自动恢复过期的证书。一个例外是,您必须手动批准待处理的 node-bootstrapper 证书签名请求(CSR)来恢复 kubelet 证书。如需更多信息,请参阅从过期的 control plane 证书 中恢复的文档。
    • 建议您在 Ignition 配置文件生成后的 12 小时内使用它们,因为 24 小时的证书会在集群安装后的 16 小时到 22 小时间进行轮转。通过在 12 小时内使用 Ignition 配置文件,您可以避免在安装过程中因为执行了证书更新而导致安装失败的问题。
  2. 确认 Kubernetes API 服务器正在与 pod 通信。

    1. 要查看所有 pod 的列表,请使用以下命令:

      $ oc get pods --all-namespaces
      Copy to Clipboard Toggle word wrap

      输出示例

      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
      ...
      Copy to Clipboard Toggle word wrap

    2. 使用以下命令,查看上一命令的输出中所列 pod 的日志:

      $ oc logs <pod_name> -n <namespace> 
      1
      Copy to Clipboard Toggle word wrap
      1
      指定 pod 名称和命名空间,如上一命令的输出中所示。

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

  3. 对于使用光纤通道协议(FCP)的安装,还需要额外的步骤才能启用多路径。不要在安装过程中启用多路径。

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

2.1.19. OpenShift Container Platform 的 Telemetry 访问

在 OpenShift Container Platform 4.19 中,默认运行的 Telemetry 服务提供有关集群健康状况和成功更新的指标,需要访问互联网。如果您的集群连接到互联网,Telemetry 会自动运行,而且集群会注册到 OpenShift Cluster Manager

确认 OpenShift Cluster Manager 清单正确后,可以由 Telemetry 自动维护,也可以使用 OpenShift Cluster Manager 手动维护,使用订阅监控来跟踪帐户或多集群级别的 OpenShift Container Platform 订阅。

2.1.20. 后续步骤

2.2. 使用自定义网络安装用户置备的裸机集群

在 OpenShift Container Platform 4.19 中,您可以使用自定义的网络配置选项在裸机环境中安装集群。通过自定义网络配置,您的集群可以与环境中现有的 IP 地址分配共存,并与现有的 MTU 和 VXLAN 配置集成。

自定义 OpenShift Container Platform 网络时,必须在安装过程中设置大多数网络配置参数。您只能在正在运行的集群中修改 kubeProxy 网络配置参数。

2.2.1. 先决条件

2.2.2. OpenShift Container Platform 互联网访问

在 OpenShift Container Platform 4.19 中,您需要访问互联网来安装集群。

您需要连接到互联网才能执行以下操作:

  • 访问 OpenShift Cluster Manager 以下载安装程序并执行订阅管理。如果集群可以访问互联网,并且没有禁用 Telemetry,该服务会自动授权您的集群。
  • 访问 Quay.io,以获取安装集群所需的软件包。
  • 获取执行集群更新所需的软件包。
重要

如果您的集群无法直接访问互联网,则可以在置备的某些类型的基础架构上执行受限网络安装。在此过程中,您可以下载所需的内容,并使用它为镜像 registry 填充安装软件包。对于某些安装类型,集群要安装到的环境不需要访问互联网。在更新集群前,您要更新镜像 registry 的内容。

2.2.3. 具有用户置备基础架构的集群的要求

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

本节论述了在用户置备的基础架构上部署 OpenShift Container Platform 的要求。

2.2.3.1. 集群安装所需的机器

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

Expand
表 2.11. 最低所需的主机
主机描述

一个临时 bootstrap 机器

集群需要 bootstrap 机器在三台 control plane 机器上部署 OpenShift Container Platform 集群。您可在安装集群后删除 bootstrap 机器。

三台 control plane 机器

control plane 机器运行组成 control plane 的 Kubernetes 和 OpenShift Container Platform 服务。

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

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

注意

作为例外,您可以在裸机集群中运行零台计算机器,它们仅由三台 control plane 机器组成。这为集群管理员和开发人员提供了更小、效率更高的集群,用于测试、开发和生产。不支持运行一台计算机器。

重要

要保持集群的高可用性,请将独立的物理主机用于这些集群机器。

bootstrap 和 control plane 机器必须使用 Red Hat Enterprise Linux CoreOS(RHCOS)作为操作系统。但是,计算机器可以在 Red Hat Enterprise Linux CoreOS(RHCOS)、Red Hat Enterprise Linux(RHEL) 8.6 和更高的版本。

请注意,RHCOS 基于 Red Hat Enterprise Linux(RHEL) 9.2,并继承其所有硬件认证和要求。查看 红帽企业 Linux 技术功能和限制

2.2.3.2. 集群安装的最低资源要求

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

Expand
表 2.12. 最低资源要求
机器操作系统CPU [1]RAMStorage每秒输入/输出 (IOPS) [2]

bootstrap

RHCOS

4

16 GB

100 GB

300

Control plane(控制平面)

RHCOS

4

16 GB

100 GB

300

Compute

RHCOS、RHEL 8.6 及更新版本 [3]

2

8 GB

100 GB

300

  1. 当未启用并发多线程 (SMT) 或超线程时,一个 CPU 相当于一个物理内核。启用后,使用以下公式来计算对应的比例:(每个内核数的线程)× sockets = CPU。
  2. OpenShift Container Platform 和 Kubernetes 对磁盘性能非常敏感,建议使用更快的存储速度,特别是 control plane 节点上需要 10 ms p99 fsync 持续时间的 etcd。请注意,在许多云平台上,存储大小和 IOPS 可一起扩展,因此您可能需要过度分配存储卷来获取足够的性能。
  3. 与所有用户置备的安装一样,如果您选择在集群中使用 RHEL 计算机器,则负责所有操作系统生命周期管理和维护,包括执行系统更新、应用补丁和完成所有其他必要的任务。RHEL 7 计算机器的使用已弃用,并已在 OpenShift Container Platform 4.10 及更新的版本中删除。
注意

对于 OpenShift Container Platform 版本 4.19,RHCOS 基于 RHEL 版本 9.6,它会更新微架构要求。以下列表包含每个架构需要的最小指令集架构 (ISA):

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

如需更多信息,请参阅 架构 (RHEL 文档)。

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

2.2.3.3. 证书签名请求管理

在使用您置备的基础架构时,集群只能有限地访问自动机器管理,因此您必须提供一种在安装后批准集群证书签名请求 (CSR) 的机制。kube-controller-manager 只能批准 kubelet 客户端 CSR。machine-approver 无法保证使用 kubelet 凭证请求的提供证书的有效性,因为它不能确认是正确的机器发出了该请求。您必须决定并实施一种方法,以验证 kubelet 提供证书请求的有效性并进行批准。

2.2.3.4. 用户置备的基础架构对网络的要求

所有 Red Hat Enterprise Linux CoreOS(RHCOS)机器都需要在启动时在 initramfs 中配置联网,以获取它们的 Ignition 配置文件。

在初次启动过程中,机器需要 IP 地址配置,该配置通过 DHCP 服务器或静态设置,提供所需的引导选项。建立网络连接后,机器会从 HTTP 或 HTTPS 服务器下载 Ignition 配置文件。然后,Ignition 配置文件用于设置每台机器的确切状态。Machine Config Operator 在安装后完成对机器的更多更改,如应用新证书或密钥。

注意
  • 建议使用 DHCP 服务器对集群机器进行长期管理。确保 DHCP 服务器已配置为向集群机器提供持久的 IP 地址、DNS 服务器信息和主机名。
  • 如果用户置备的基础架构没有 DHCP 服务,您可以在 RHCOS 安装时向节点提供 IP 网络配置和 DNS 服务器地址。如果要从 ISO 镜像安装,这些参数可作为引导参数传递。如需有关静态 IP 置备和高级网络选项的更多信息,请参阅 安装 RHCOS 并启动 OpenShift Container Platform bootstrap 过程 部分。

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

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

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

另外,通过 DHCP 设置主机名可以绕过实施 DNS split-horizon 的环境中的手动 DNS 记录名称配置错误。

2.2.3.4.2. 网络连接要求

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

本节详细介绍了所需的端口。

重要

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

Expand
表 2.13. 用于全机器到所有机器通信的端口
协议port描述

ICMP

N/A

网络可访问性测试

TCP

1936

指标

9000-9999

主机级别的服务,包括端口 9 100-9101 上的节点导出器,以及端口 9099 上的 Cluster Version Operator。

10250-10259

Kubernetes 保留的默认端口

22623

端口处理来自 Machine Config 服务器的流量,并将流量定向到 control plane 机器。

UDP

4789

VXLAN

6081

Geneve

9000-9999

主机级别的服务,包括端口 91009101 上的节点导出器。

500

IPsec IKE 数据包

4500

IPsec NAT-T 数据包

123

UDP 端口 123 上的网络时间协议 (NTP)如果配置了外部 NTP 时间服务器,需要打开 UDP 端口 123

TCP/UDP

30000-32767

Kubernetes 节点端口

ESP

N/A

IPsec Encapsulating Security Payload(ESP)

Expand
表 2.14. 用于所有机器控制平面通信的端口
协议port描述

TCP

6443

Kubernetes API

Expand
表 2.15. control plane 机器用于 control plane 机器通信的端口
协议port描述

TCP

2379-2380

etcd 服务器和对等端口

2.2.3.4.3. 用户置备的基础架构的 NTP 配置

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

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

2.2.3.5. 用户置备的 DNS 要求

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

  • The Kubernetes API
  • OpenShift Container Platform 应用程序通配符
  • bootstrap、control plane 和计算机器

Kubernetes API、bootstrap 机器、control plane 机器和计算机器也需要反向 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>.

Expand
表 2.16. 所需的 DNS 记录
组件记录描述

Kubernetes API

api.<cluster_name>.<base_domain>.

DNS A/AAAA 或 CNAME 记录,以及用于标识 API 负载均衡器的 DNS PTR 记录。这些记录必须由集群外的客户端和集群中的所有节点解析。

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

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

重要

API 服务器必须能够根据 Kubernetes 中记录的主机名解析 worker 节点。如果 API 服务器无法解析节点名称,则代理的 API 调用会失败,且您无法从 pod 检索日志。

Routes

*.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 机器

bootstrap.<cluster_name>.<base_domain>.

DNS A/AAAA 或 CNAME 记录,以及用于标识 bootstrap 机器的 DNS PTR 记录。这些记录必须由集群中的节点解析。

control plane 机器

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

DNS A/AAAA 或 CNAME 记录,以识别 control plane 节点的每台机器。这些记录必须由集群中的节点解析。

计算机器

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

DNS A/AAAA 或 CNAME 记录,用于识别 worker 节点的每台机器。这些记录必须由集群中的节点解析。

注意

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

提示

您可以使用 dig 命令验证名称和反向名称解析。如需了解详细的 验证步骤,请参阅为用户置备的基础架构验证 DNS 解析 一节。

2.2.3.5.1. 用户置备的集群的 DNS 配置示例

本节提供 A 和 PTR 记录配置示例,它们满足了在用户置备的基础架构上部署 OpenShift Container Platform 的 DNS 要求。样本不是为选择一个 DNS 解决方案提供建议。

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

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

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

例 2.4. 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 
6

control-plane2.ocp4.example.com.	IN	A	192.168.1.99 
7

;
compute0.ocp4.example.com.	IN	A	192.168.1.11 
8

compute1.ocp4.example.com.	IN	A	192.168.1.7 
9

;
;EOF
Copy to Clipboard Toggle word wrap
1
为 Kubernetes API 提供名称解析。记录引用 API 负载均衡器的 IP 地址。
2
为 Kubernetes API 提供名称解析。记录引用 API 负载均衡器的 IP 地址,用于内部集群通信。
3
为通配符路由提供名称解析。记录引用应用程序入口负载均衡器的 IP 地址。应用程序入口负载均衡器以运行 Ingress Controller Pod 的机器为目标。默认情况下,Ingress Controller Pod 在计算机器上运行。
注意

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

4
为 bootstrap 机器提供名称解析。
5 6 7
为 control plane 机器提供名称解析。
8 9
为计算机器提供名称解析。

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

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

例 2.5. 反向记录的 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. 
5

99.1.168.192.in-addr.arpa.	IN	PTR	control-plane2.ocp4.example.com. 
6

;
11.1.168.192.in-addr.arpa.	IN	PTR	compute0.ocp4.example.com. 
7

7.1.168.192.in-addr.arpa.	IN	PTR	compute1.ocp4.example.com. 
8

;
;EOF
Copy to Clipboard Toggle word wrap
1
为 Kubernetes API 提供反向 DNS 解析。PTR 记录引用 API 负载均衡器的记录名称。
2
为 Kubernetes API 提供反向 DNS 解析。PTR 记录引用 API 负载均衡器的记录名称,用于内部集群通信。
3
为 bootstrap 机器提供反向 DNS 解析。
4 5 6
为 control plane 机器提供反向 DNS 解析。
7 8
为计算机器提供反向 DNS 解析。
注意

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

2.2.3.6. 用户置备的基础架构的负载均衡要求

在安装 OpenShift Container Platform 前,您必须置备 API 和应用程序入口负载均衡基础架构。在生产环境中,您可以单独部署 API 和应用程序入口负载均衡器,以便可以隔离扩展每个负载均衡器基础架构。

注意

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

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

  1. API 负载均衡器 :提供一个通用端点,供用户(包括人工和机器)与平台交互和配置。配置以下条件:

    • 仅第 4 层负载均衡.这可被称为 Raw TCP 或 SSL Passthrough 模式。
    • 无状态负载平衡算法。这些选项根据负载均衡器的实施而有所不同。
    重要

    不要为 API 负载均衡器配置会话持久性。为 Kubernetes API 服务器配置会话持久性可能会导致出现过量 OpenShift Container Platform 集群应用程序流量,以及过量的在集群中运行的 Kubernetes API。

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

    Expand
    表 2.17. API 负载均衡器
    port后端机器(池成员)internal外部描述

    6443

    Bootstrap 和 control plane.bootstrap 机器初始化集群 control plane 后,您要从负载均衡器中删除 bootstrap 机器。您必须为 API 服务器健康检查探测配置 /readyz 端点。

    X

    X

    Kubernetes API 服务器

    22623

    Bootstrap 和 control plane.bootstrap 机器初始化集群 control plane 后,您要从负载均衡器中删除 bootstrap 机器。

    X

     

    机器配置服务器

    注意

    负载均衡器必须配置为,从 API 服务器关闭 /readyz 端点到从池中移除 API 服务器实例时最多需要 30 秒。在 /readyz 返回错误或健康后的时间范围内,端点必须被删除或添加。每 5 秒或 10 秒探测一次,有两个成功请求处于健康状态,三个成为不健康的请求是经过良好测试的值。

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

    配置以下条件:

    • 仅第 4 层负载均衡.这可被称为 Raw TCP 或 SSL Passthrough 模式。
    • 建议根据可用选项以及平台上托管的应用程序类型,使用基于连接的或基于会话的持久性。
    提示

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

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

    Expand
    表 2.18. 应用程序入口负载均衡器
    port后端机器(池成员)internal外部描述

    443

    默认情况下,运行 Ingress Controller Pod、计算或 worker 的机器。

    X

    X

    HTTPS 流量

    80

    默认情况下,运行 Ingress Controller Pod、计算或 worker 的机器。

    X

    X

    HTTP 流量

    注意

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

本节提供了一个满足用户置备集群的负载均衡要求的 API 和应用程序入口负载均衡器配置示例。示例是 HAProxy 负载均衡器的 /etc/haproxy/haproxy.cfg 配置。这个示例不是为选择一个负载平衡解决方案提供建议。

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

注意

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

例 2.6. 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 
4

  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 
5

  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 
6

  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
Copy to Clipboard Toggle word wrap
1
端口 6443 处理 Kubernetes API 流量并指向 control plane 机器。
2 4
bootstrap 条目必须在 OpenShift Container Platform 集群安装前就位,且必须在 bootstrap 过程完成后删除它们。
3
端口 22623 处理机器配置服务器流量并指向 control plane 机器。
5
端口 443 处理 HTTPS 流量,并指向运行 Ingress Controller pod 的机器。默认情况下,Ingress Controller Pod 在计算机器上运行。
6
端口 80 处理 HTTP 流量,并指向运行 Ingress Controller pod 的机器。默认情况下,Ingress Controller Pod 在计算机器上运行。
注意

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

提示

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

除了使用 configure-ovs.sh shell 脚本在裸机平台上设置 br-ex 网桥的替代选择,您可以创建一个包括 NMState 配置文件的 MachineConfig 对象。主机 nmstate-configuration.servicenmstate.service 将 NMState 配置文件应用到集群中运行的每个节点。

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

  • 您需要对网桥进行安装后更改,如更改 Open vSwitch (OVS) 或 OVN-Kubernetes br-ex 网桥网络。configure-ovs.sh shell 脚本不支持对网桥进行安装后更改。
  • 您希望将网桥部署到与主机或服务器 IP 地址上可用的接口不同的接口上。
  • 您希望通过 configure-ovs.sh shell 脚本对网桥进行高级配置。对这些配置使用脚本可能会导致网桥无法连接多个网络接口,并无法正确处理接口之间的数据转发。
注意

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

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

警告

以下接口名称列表被保留,您不能使用带有 NMstate 配置的名称:

  • br-ext
  • br-int
  • br-local
  • br-nexthop
  • br0
  • ext-vxlan
  • ext
  • genev_sys_*
  • int
  • k8s-*
  • ovn-k8s-*
  • patch-br-*
  • tun0
  • vxlan_sys_*

先决条件

  • 可选: 已安装 nmstate API,以便您可以验证 NMState 配置。

流程

  1. 为您的自定义 br-ex 网桥网络创建一个使用 base64 信息的 NMState 配置文件:

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

    interfaces:
    - name: enp2s0 
    1
    
      type: ethernet 
    2
    
      state: up 
    3
    
      ipv4:
        enabled: false 
    4
    
      ipv6:
        enabled: false
    - name: br-ex
      type: ovs-bridge
      state: up
      ipv4:
        enabled: false
        dhcp: false
      ipv6:
        enabled: false
        dhcp: false
      bridge:
        options:
          mcast-snooping-enable: true
        port:
        - name: enp2s0 
    5
    
        - name: br-ex
    - name: br-ex
      type: ovs-interface
      state: up
      copy-mac-from: enp2s0
      ipv4:
        enabled: true
        dhcp: true
        auto-route-metric: 48 
    6
    
      ipv6:
        enabled: true
        dhcp: true
        auto-route-metric: 48
    # ...
    Copy to Clipboard Toggle word wrap

    1
    接口的名称。
    2
    以太网的类型。
    3
    创建后接口的请求状态。
    4
    在这个示例中禁用 IPv4 和 IPv6。
    5
    网桥附加到的节点 NIC。
    6
    将参数设置为 48,以确保 br-ex 默认路由始终具有最高的优先级(最低指标)。此配置可防止与 NetworkManager 服务自动配置的任何其他接口冲突。
  2. 使用 cat 命令对 NMState 配置的内容进行 base64 编码:

    $ cat <nmstate_configuration>.yaml | base64 
    1
    Copy to Clipboard Toggle word wrap
    1
    <nmstate_configuration> 替换为 NMState 资源 YAML 文件的名称。
  3. 创建 MachineConfig 清单文件,并定义一个自定义 br-ex 网桥网络配置,如下例所示:

    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: worker
      name: 10-br-ex-worker 
    1
    
    spec:
      config:
        ignition:
          version: 3.2.0
        storage:
          files:
          - contents:
              source: data:text/plain;charset=utf-8;base64,<base64_encoded_nmstate_configuration> 
    2
    
            mode: 0644
            overwrite: true
            path: /etc/nmstate/openshift/worker-0.yml 
    3
    
          - contents:
              source: data:text/plain;charset=utf-8;base64,<base64_encoded_nmstate_configuration>
            mode: 0644
            overwrite: true
            path: /etc/nmstate/openshift/worker-1.yml 
    4
    
    # ...
    Copy to Clipboard Toggle word wrap
    1
    策略的名称。
    2
    将编码的 base64 信息写入指定路径。
    3 4
    对于集群中的每个节点,指定节点的主机名路径以及机器类型的 base-64 编码 Ignition 配置文件数据。worker 角色是集群中节点的默认角色。如果为每个节点或 MachineConfig 清单文件中的所有节点设置了短主机名、 hostname -s、路径,.yaml 扩展将无法工作。

    如果您在要应用到集群中的所有节点的 /etc/nmstate/openshift/cluster.yml 配置文件中指定了单个全局配置,则不需要为每个节点指定短主机名路径,如 /etc/nmstate/openshift/<node_hostname>.yml。例如:

    # ...
          - contents:
              source: data:text/plain;charset=utf-8;base64,<base64_encoded_nmstate_configuration>
            mode: 0644
            overwrite: true
            path: /etc/nmstate/openshift/cluster.yml
    # ...
    Copy to Clipboard Toggle word wrap

后续步骤

  • 扩展计算节点,以将包含自定义 br-ex 网桥的 manifest 对象应用到集群中存在的每个计算节点。如需更多信息,请参阅附加资源部分中的"扩展集群"。
2.2.4.1. 将每个机器集扩展到计算节点

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

配置这些资源后,您必须扩展机器集,以便机器集可以将资源配置应用到每个计算节点并重新引导节点。

先决条件

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

流程

  1. 输入以下命令编辑 MachineConfig CR:

    $ oc edit mc <machineconfig_custom_resource_name>
    Copy to Clipboard Toggle word wrap
  2. 将每个计算节点配置添加到 CR,以便 CR 可以管理集群中每个定义的计算节点的角色。
  3. 创建名为 extraworker-secretSecret 对象,该对象具有最小的静态 IP 配置。
  4. 输入以下命令将 extraworker-secret secret 应用到集群中的每个节点。此步骤提供每个计算节点对 Ignition 配置文件的访问权限。

    $ oc apply -f ./extraworker-secret.yaml
    Copy to Clipboard Toggle word wrap
  5. 创建 BareMetalHost 资源并在 preprovisioningNetworkDataName 参数中指定网络 secret:

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

    apiVersion: metal3.io/v1alpha1
    kind: BareMetalHost
    spec:
    # ...
      preprovisioningNetworkDataName: ostest-extraworker-0-network-config-secret
    # ...
    Copy to Clipboard Toggle word wrap

  6. 要在集群的 openshift-machine-api 命名空间中管理 BareMetalHost 对象,请输入以下命令来更改命名空间:

    $ oc project openshift-machine-api
    Copy to Clipboard Toggle word wrap
  7. 获取机器集:

    $ oc get machinesets
    Copy to Clipboard Toggle word wrap
  8. 输入以下命令扩展每个机器集。您必须为每个机器集运行这个命令。

    $ oc scale machineset <machineset_name> --replicas=<n> 
    1
    Copy to Clipboard Toggle word wrap
    1
    其中 <machineset_name> 是机器集的名称,<n> 是计算节点的数量。

2.2.5. 为集群启用 OVS balance-slb 模式

您可以启用 Open vSwitch (OVS) balance-slb 模式,以便两个或多个物理接口共享其网络流量。balance-slb 模式接口可以为运行虚拟化工作负载的集群提供源负载均衡(SLB)功能,而无需与网络交换机协商。

目前,源负载均衡在绑定接口上运行,该接口连接到辅助网桥,如 br-phy。源负载均衡仅在不同的 Media Access Control (MAC)地址和虚拟局域网(VLAN)组合之间平衡。请注意,所有 OVN-Kubernetes pod 流量都使用相同的 MAC 地址和 VLAN,因此此流量无法在多个物理接口负载平衡。

下图显示了简单集群基础架构布局上的 balance-slb 模式。虚拟机(VM)连接到特定的 localnet NetworkAttachmentDefinition (NAD)自定义资源定义(CRD)、NAD 0NAD 1。每个 NAD 均为虚拟机提供对底层物理网络的访问,支持 VLAN 标记或未标记的流量。br-ex OVS 网桥从虚拟机接收流量,并将流量传递到下一个 OVS 网桥 br-phybr-phy 网桥作为 SLB 绑定的控制器。SLB 绑定通过物理接口链接(如 eno0eno1)平衡来自不同虚拟机端口的流量。此外,来自一个物理接口的入口流量可以通过一组 OVS 网桥来访问虚拟机。

图 2.2. OVS balance-slb 模式在带有两个 NAD 的 localnet 上运行

您可以使用 OVS 绑定将 balance-slb 模式接口集成到主或二级网络类型中。注意关于 OVS 绑定的以下点:

  • 支持 OVN-Kubernetes CNI 插件,并轻松与插件集成。
  • 原生支持 balance-slb 模式。

先决条件

  • 将多个物理接口附加到主网络,并在 MachineConfig 文件中定义接口。
  • 您创建了清单对象,并在对象配置文件中定义了自定义 br-ex 网桥。
  • 您附加了多个物理接口,并在 NAD CRD 文件中定义接口。

流程

  1. 对于集群中的每个裸机主机,在 install-config.yaml 文件中为集群定义一个 networkConfig 部分,如下例所示:

    # ...
    networkConfig:
      interfaces:
        - name: enp1s0 
    1
    
          type: ethernet
          state: up
          ipv4:
            dhcp: true
            enabled: true
          ipv6:
            enabled: false
        - name: enp2s0 
    2
    
          type: ethernet
          state: up
          mtu: 1500 
    3
    
          ipv4:
            dhcp: true
            enabled: true
          ipv6:
            dhcp: true
            enabled: true
        - name: enp3s0 
    4
    
          type: ethernet
          state: up
          mtu: 1500
          ipv4:
            enabled: false
          ipv6:
            enabled: false
    # ...
    Copy to Clipboard Toggle word wrap
    1
    置备的网络接口控制器(NIC)的接口。
    2
    在绑定接口的 Ignition 配置文件中拉取的第一个绑定接口。
    3
    在绑定端口上手动设置 br-ex 最大传输单元(MTU)。
    4
    第二个绑定接口是在集群安装过程中拉取 ignition 的最小配置的一部分。
  2. 在 NMState 配置文件中定义每个网络接口:

    定义许多网络接口的 NMState 配置文件示例

    ovn:
      bridge-mappings:
        - localnet: localnet-network
          bridge: br-ex
          state: present
    interfaces:
      - name: br-ex
        type: ovs-bridge
        state: up
        bridge:
          allow-extra-patch-ports: true
          port:
            - name: br-ex
            - name: patch-ex-to-phy
        ovs-db:
          external_ids:
            bridge-uplink: "patch-ex-to-phy"
      - name: br-ex
        type: ovs-interface
        state: up
        mtu: 1500 
    1
    
        ipv4:
          enabled: true
          dhcp: true
          auto-route-metric: 48
        ipv6:
          enabled: false
          dhcp: false
          auto-route-metric: 48
      - name: br-phy
        type: ovs-bridge
        state: up
        bridge:
          allow-extra-patch-ports: true
          port:
            - name: patch-phy-to-ex
            - name: ovs-bond
              link-aggregation:
                mode: balance-slb
                port:
                  - name: enp2s0
                  - name: enp3s0
      - name: patch-ex-to-phy
        type: ovs-interface
        state: up
        patch:
          peer: patch-phy-to-ex
      - name: patch-phy-to-ex
        type: ovs-interface
        state: up
        patch:
          peer: patch-ex-to-phy
      - name: enp1s0
        type: ethernet
        state: up
        ipv4:
          dhcp: true
          enabled: true
        ipv6:
          enabled: false
      - name: enp2s0
        type: ethernet
        state: up
        mtu: 1500
        ipv4:
          enabled: false
        ipv6:
          enabled: false
      - name: enp3s0
        type: ethernet
        state: up
        mtu: 1500
        ipv4:
          enabled: false
        ipv6:
          enabled: false
    # ...
    Copy to Clipboard Toggle word wrap

    1
    在绑定端口上手动设置 br-ex MTU。
  3. 使用 base64 命令对 NMState 配置文件的接口内容进行编码:

    $ base64 -w0  <nmstate_configuration>.yml 
    1
    Copy to Clipboard Toggle word wrap
    1
    其中 -w0 选项可防止在 base64 编码操作中换行。
  4. master 角色和 worker 角色创建 MachineConfig 清单文件。确保将之前命令中的 base64 编码的字符串嵌入到每个 MachineConfig 清单文件中。以下示例清单文件为集群中存在的所有节点配置 master 角色。您还可以为特定于节点的 masterworker 角色创建清单文件。

    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: master
      name: 10-br-ex-master 
    1
    
    spec:
      config:
        ignition:
          version: 3.2.0
        storage:
          files:
          - contents:
              source: data:text/plain;charset=utf-8;base64,<base64_encoded_nmstate_configuration> 
    2
    
            mode: 0644
            overwrite: true
            path: /etc/nmstate/openshift/cluster.yml 
    3
    Copy to Clipboard Toggle word wrap
    1
    策略的名称。
    2
    将编码的 base64 信息写入指定路径。
    3
    指定 cluster.yml 文件的路径。对于集群中的每个节点,您可以指定节点的短主机名路径,如 <node_short_hostname>.yml。
  5. 将每个 MachineConfig 清单文件保存到 ./& lt;installation_directory>/manifests 目录,其中 &lt ;installation_directory > 是安装程序在其中创建文件的目录。

    Machine Config Operator (MCO)从每个清单文件中获取内容,并在滚动更新期间持续将内容应用到所有所选节点。

2.2.6. 准备用户置备的基础架构

在用户置备的基础架构上安装 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 bootstrap 过程 部分。

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

      注意

      如果没有使用 DHCP 服务,集群节点可以通过反向 DNS 查找来获取其主机名。

  2. 确保您的网络基础架构提供集群组件之间所需的网络连接。有关 要求的详情,请参阅用户置备的基础架构 的网络要求部分。
  3. 将防火墙配置为启用 OpenShift Container Platform 集群组件进行通信所需的端口。如需有关所需端口的详细信息,请参阅用户置备的基础架构 部分的网络要求。

    重要

    默认情况下,OpenShift Container Platform 集群可以访问端口 1936,因为每个 control plane 节点都需要访问此端口。

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

  4. 为集群设置所需的 DNS 基础架构。

    1. 为 Kubernetes API、应用程序通配符、bootstrap 机器、control plane 机器和计算机器配置 DNS 名称解析。
    2. 为 Kubernetes API、bootstrap 机器、control plane 机器和计算机器配置反向 DNS 解析。

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

  5. 验证您的 DNS 配置。

    1. 从安装节点,针对 Kubernetes API 的记录名称、通配符路由和集群节点运行 DNS 查找。验证响应中的 IP 地址是否与正确的组件对应。
    2. 从安装节点,针对负载均衡器和集群节点的 IP 地址运行反向 DNS 查找。验证响应中的记录名称是否与正确的组件对应。

      有关详细的 DNS 验证步骤,请参阅用户置备的基础架构 验证 DNS 解析部分。

  6. 置备所需的 API 和应用程序入口负载平衡基础架构。有关 要求的更多信息,请参阅用户置备的基础架构的负载平衡 要求部分。
注意

某些负载平衡解决方案要求在初始化负载平衡之前,对群集节点进行 DNS 名称解析。

2.2.7. 验证用户置备的基础架构的 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
      Copy to Clipboard Toggle word wrap
      1
      <nameserver_ip> 替换为 nameserver 的 IP 地址,<cluster_name> 替换为您的集群名称,<base_domain> 替换为您的基本域名。

      输出示例

      api.ocp4.example.com.		604800	IN	A	192.168.1.5
      Copy to Clipboard Toggle word wrap

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

      $ dig +noall +answer @<nameserver_ip> api-int.<cluster_name>.<base_domain>
      Copy to Clipboard Toggle word wrap

      输出示例

      api-int.ocp4.example.com.		604800	IN	A	192.168.1.5
      Copy to Clipboard Toggle word wrap

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

      $ dig +noall +answer @<nameserver_ip> random.apps.<cluster_name>.<base_domain>
      Copy to Clipboard Toggle word wrap

      输出示例

      random.apps.ocp4.example.com.		604800	IN	A	192.168.1.5
      Copy to Clipboard Toggle word wrap

      注意

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

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

      $ dig +noall +answer @<nameserver_ip> console-openshift-console.apps.<cluster_name>.<base_domain>
      Copy to Clipboard Toggle word wrap

      输出示例

      console-openshift-console.apps.ocp4.example.com. 604800 IN	A 192.168.1.5
      Copy to Clipboard Toggle word wrap

    4. 针对 bootstrap DNS 记录名称运行查询。检查结果是否指向 bootstrap 节点的 IP 地址:

      $ dig +noall +answer @<nameserver_ip> bootstrap.<cluster_name>.<base_domain>
      Copy to Clipboard Toggle word wrap

      输出示例

      bootstrap.ocp4.example.com.		604800	IN	A	192.168.1.96
      Copy to Clipboard Toggle word wrap

    5. 使用此方法对 control plane 和计算节点的 DNS 记录名称执行查找。检查结果是否与每个节点的 IP 地址对应。
  2. 从安装节点,针对负载均衡器和集群节点的 IP 地址运行反向 DNS 查找。验证响应中包含的记录名称是否与正确的组件对应。

    1. 对 API 负载均衡器的 IP 地址执行反向查找。检查响应是否包含 Kubernetes API 和 Kubernetes 内部 API 的记录名称:

      $ dig +noall +answer @<nameserver_ip> -x 192.168.1.5
      Copy to Clipboard Toggle word wrap

      输出示例

      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
      Copy to Clipboard Toggle word wrap

      1
      为 Kubernetes 内部 API 提供记录名称。
      2
      为 Kubernetes API 提供记录名称。
      注意

      OpenShift Container Platform 应用程序通配符不需要 PTR 记录。针对应用程序入口负载均衡器的 IP 地址解析反向 DNS 解析不需要验证步骤。

    2. 对 bootstrap 节点的 IP 地址执行反向查找。检查结果是否指向 bootstrap 节点的 DNS 记录名称:

      $ dig +noall +answer @<nameserver_ip> -x 192.168.1.96
      Copy to Clipboard Toggle word wrap

      输出示例

      96.1.168.192.in-addr.arpa. 604800	IN	PTR	bootstrap.ocp4.example.com.
      Copy to Clipboard Toggle word wrap

    3. 使用此方法对 control plane 和计算节点的 IP 地址执行反向查找。检查结果是否与每个节点的 DNS 记录名称对应。

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

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

将密钥传递给节点后,您可以使用密钥对作为用户 核心 通过 SSH 连接到 RHCOS 节点。若要通过 SSH 访问节点,必须由 SSH 为您的本地用户管理私钥身份。

如果要通过 SSH 连接到集群节点来执行安装调试或灾难恢复,则必须在安装过程中提供 SSH 公钥。./openshift-install gather 命令还需要在集群节点上设置 SSH 公钥。

重要

不要在生产环境中跳过这个过程,在生产环境中需要灾难恢复和调试。

注意

您必须使用本地密钥,而不是使用特定平台方法配置的密钥。

流程

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

    $ ssh-keygen -t ed25519 -N '' -f <path>/<file_name> 
    1
    Copy to Clipboard Toggle word wrap
    1
    指定新 SSH 密钥的路径和文件名,如 ~/.ssh/id_ed25519。如果您已有密钥对,请确保您的公钥位于 ~/.ssh 目录中。
    注意

    如果您计划在 x86_64ppc64les390x 架构上安装使用 RHEL 加密库(这些加密库已提交给 NIST 用于 FIPS 140-2/140-3 验证)的 OpenShift Container Platform 集群,则不要创建使用 ed25519 算法的密钥。相反,创建一个使用 rsaecdsa 算法的密钥。

  2. 查看公共 SSH 密钥:

    $ cat <path>/<file_name>.pub
    Copy to Clipboard Toggle word wrap

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

    $ cat ~/.ssh/id_ed25519.pub
    Copy to Clipboard Toggle word wrap
  3. 将 SSH 私钥身份添加到本地用户的 SSH 代理(如果尚未添加)。在集群节点上,或者要使用 ./openshift-install gather 命令,需要对该密钥进行 SSH 代理管理,才能在集群节点上进行免密码 SSH 身份验证。

    注意

    在某些发行版中,自动管理默认 SSH 私钥身份,如 ~/.ssh/id_rsa~/.ssh/id_dsa

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

      $ eval "$(ssh-agent -s)"
      Copy to Clipboard Toggle word wrap

      输出示例

      Agent pid 31874
      Copy to Clipboard Toggle word wrap

      注意

      如果集群处于 FIPS 模式,则只使用 FIPS 兼容算法来生成 SSH 密钥。密钥必须是 RSA 或 ECDSA。

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

    $ ssh-add <path>/<file_name> 
    1
    Copy to Clipboard Toggle word wrap
    1
    指定 SSH 私钥的路径和文件名,如 ~/.ssh/id_ed25519.pub

    输出示例

    Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
    Copy to Clipboard Toggle word wrap

后续步骤

  • 安装 OpenShift Container Platform 时,为安装程序提供 SSH 公钥。

2.2.9. 获取安装程序

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

先决条件

  • 您有一台运行 Linux 或 macOS 的计算机,本地磁盘空间为 500 MB。

流程

  1. 进入 Red Hat Hybrid Cloud Console 上的 Cluster Type 页。如果您有红帽帐户,请使用您的凭证登录。如果没有,请创建一个帐户。

    提示
  2. 在页的 Run it yourself 部分中选择您的基础架构供应商。
  3. OpenShift 安装程序下的下拉菜单中选择您的主机操作系统和架构,然后点下载安装程序
  4. 将下载的文件保存在要存储安装配置文件的目录中。

    重要
    • 安装程序会在用来安装集群的计算机上创建几个文件。在完成集群安装后,您必须保留安装程序和安装程序所创建的文件。删除集群需要这两个文件。
    • 删除安装程序创建的文件不会删除您的集群,即使集群在安装过程中失败也是如此。要删除集群,请为特定云供应商完成 OpenShift Container Platform 卸载流程。
  5. 提取安装程序。例如,在使用 Linux 操作系统的计算机上运行以下命令:

    $ tar -xvf openshift-install-linux.tar.gz
    Copy to Clipboard Toggle word wrap
  6. 从 Red Hat OpenShift Cluster Manager 下载安装 pull secret。此 pull secret 允许您与所含授权机构提供的服务进行身份验证,这些服务包括为 OpenShift Container Platform 组件提供容器镜像的 Quay.io。
提示

另外,您还可以从红帽客户门户网站检索安装程序,您可以在其中指定要下载的安装程序版本。但是,您需要有一个有效的订阅才能访问此页。

2.2.10. 安装 OpenShift CLI

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

重要

如果安装了旧版本的 oc,则可能无法使用 OpenShift Container Platform 中的所有命令。

下载并安装新版本的 oc

2.2.10.1. 在 Linux 上安装 OpenShift CLI

您可以按照以下流程在 Linux 上安装 OpenShift CLI(oc)二进制文件。

流程

  1. 进入到红帽客户门户网站上的 Download OpenShift Container Platform 页。
  2. Product Variant 列表中选择构架。
  3. Version 列表中选择适当的版本。
  4. OpenShift v4.19 Linux Clients 条目旁的 Download Now 来保存文件。
  5. 解包存档:

    $ tar xvf <file>
    Copy to Clipboard Toggle word wrap
  6. oc 二进制文件放到 PATH 中的目录中

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

    $ echo $PATH
    Copy to Clipboard Toggle word wrap

验证

  • 安装 OpenShift CLI 后,可以使用 oc 命令:

    $ oc <command>
    Copy to Clipboard Toggle word wrap
2.2.10.2. 在 Windows 上安装 OpenShift CLI

您可以按照以下流程在 Windows 上安装 OpenShift CLI(oc)二进制文件。

流程

  1. 进入到红帽客户门户网站上的 Download OpenShift Container Platform 页。
  2. Version 列表中选择适当的版本。
  3. OpenShift v4.19 Windows Client 条目旁的 Download Now 来保存文件。
  4. 使用 ZIP 程序解压存档。
  5. oc 二进制文件移到 PATH 中的目录中

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

    C:\> path
    Copy to Clipboard Toggle word wrap

验证

  • 安装 OpenShift CLI 后,可以使用 oc 命令:

    C:\> oc <command>
    Copy to Clipboard Toggle word wrap
2.2.10.3. 在 macOS 上安装 OpenShift CLI

您可以按照以下流程在 macOS 上安装 OpenShift CLI(oc)二进制文件。

流程

  1. 进入到红帽客户门户网站上的 Download OpenShift Container Platform 页。
  2. 版本 下拉列表中选择适当的版本。
  3. OpenShift v4.19 macOS Clients 条目旁的 Download Now 来保存文件。

    注意

    对于 macOS arm64,请选择 OpenShift v4.19 macOS arm64 Client 条目。

  4. 解包和解压存档。
  5. oc 二进制文件移到 PATH 的目录中。

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

    $ echo $PATH
    Copy to Clipboard Toggle word wrap

验证

  • 使用 oc 命令验证安装:

    $ oc <command>
    Copy to Clipboard Toggle word wrap

2.2.11. 手动创建安装配置文件

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

先决条件

  • 在本地机器上有一个 SSH 公钥用于安装程序。您可以使用密钥在集群节点上进行 SSH 身份验证,以进行调试和灾难恢复。
  • 已获取 OpenShift Container Platform 安装程序和集群的 pull secret。

流程

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

    $ mkdir <installation_directory>
    Copy to Clipboard Toggle word wrap
    重要

    您必须创建一个目录。有些安装资产,如 bootstrap X.509 证书的过期间隔较短,因此不得重复使用安装目录。如果要重复使用另一个集群安装中的单个文件,您可以将它们复制到您的目录中。但是,安装资产的文件名可能会在发行版本间有所变化。从以前的 OpenShift Container Platform 版本中复制安装文件时请小心。

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

    注意

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

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

    重要

    现在备份 install-config.yaml 文件,因为安装过程会在下一步中消耗该文件。

2.2.11.1. 裸机 install-config.yaml 文件示例

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

apiVersion: v1
baseDomain: example.com 
1

compute: 
2

- hyperthreading: Enabled 
3

  name: worker
  replicas: 0 
4

controlPlane: 
5

  hyperthreading: Enabled 
6

  name: master
  replicas: 3 
7

metadata:
  name: test 
8

networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14 
9

    hostPrefix: 23 
10

  networkType: OVNKubernetes 
11

  serviceNetwork: 
12

  - 172.30.0.0/16
platform:
  none: {} 
13

fips: false 
14

pullSecret: '{"auths": ...}' 
15

sshKey: 'ssh-ed25519 AAAA...' 
16
Copy to Clipboard Toggle word wrap
1
集群的基域。所有 DNS 记录都必须是这个基域的子域,并包含集群名称。
2 5
controlPlane 部分是一个单个映射,但 compute 部分是一系列映射。为满足不同数据结构的要求,compute 部分的第一行必须以连字符 - 开头,controlPlane 部分 的第一行则不以连字符开头。仅使用一个 control plane 池。
3 6
指定要启用或禁用并发多线程(SMT)还是超线程。默认情况下,启用 SMT 可提高机器中内核的性能。您可以通过将 参数值设置为 Disabled 来禁用它。如果禁用 SMT,则必须在所有集群机器中禁用它;这包括 control plane 和计算机器。
注意

默认启用并发多线程(SMT)。如果您的 BIOS 设置中没有启用 SMT,超线程 参数无效。

重要

如果您禁用 超线程,无论是在 BIOS 中,还是在 install-config.yaml 文件中,请确保您的容量规划考虑机器性能显著降低的情况。

4
在用户置备的基础架构上安装 OpenShift Container Platform 时,必须将这个值设置为 0。在安装程序置备的安装中,参数控制集群为您创建和管理的计算机器数量。在用户置备的安装中,您必须在完成集群安装前手动部署计算机器。
注意

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

7
您添加到集群的 control plane 机器数量。由于集群使用这些值作为集群中的 etcd 端点数量,所以该值必须与您部署的 control plane 机器数量匹配。
8
您在 DNS 记录中指定的集群名称。
9
从中分配 Pod IP 地址的 IP 地址块。此块不得与现有物理网络重叠。这些 IP 地址用于 pod 网络。如果需要从外部网络访问 pod,您必须配置负载均衡器和路由器来管理流量。
注意

类 E CIDR 范围被保留以供以后使用。要使用 Class E CIDR 范围,您必须确保您的网络环境接受 Class E CIDR 范围内的 IP 地址。

10
分配给每个节点的子网前缀长度。例如,如果 hostPrefix 设为 23,则每个节点从 given cidr 中分配 a /23 子网,这样就能有 510(2^(32 - 23)- 2)个 pod IP 地址。如果需要从外部网络访问节点,请配置负载均衡器和路由器来管理流量。
11
要安装的集群网络插件。默认值 OVNKubernetes 是唯一支持的值。
12
用于服务 IP 地址的 IP 地址池。您只能输入一个 IP 地址池。此块不得与现有物理网络重叠。如果您需要从外部网络访问服务,请配置负载均衡器和路由器来管理流量。
13
您必须将平台设置为 none。您无法为您的平台提供额外的平台配置变量。
重要

使用平台类型 none 安装的集群无法使用一些功能,如使用 Machine API 管理计算机器。即使附加到集群的计算机器安装在通常支持该功能的平台上,也会应用这个限制。在安装后无法更改此参数。

14
是否启用或禁用 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 核心组件使用 RHEL 加密库,只有在 x86_64, ppc64le, 和 s390x 架构上的库被提交到 NIST 进行 FIPS 140-2/140-3 Validation。

15
Red Hat OpenShift Cluster Manager 的 pull secret。此 pull secret 允许您与所含授权机构提供的服务进行身份验证,这些服务包括为 OpenShift Container Platform 组件提供容器镜像的 Quay.io。
16
Red Hat Enterprise Linux CoreOS(RHCOS)中 core 用户的 SSH 公钥。
注意

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

2.2.12. 网络配置阶段

OpenShift Container Platform 安装前有两个阶段,您可以在其中自定义网络配置。

第 1 阶段

在创建清单文件前,您可以自定义 install-config.yaml 文件中的以下与网络相关的字段:

  • networking.networkType
  • networking.clusterNetwork
  • networking.serviceNetwork
  • networking.machineNetwork
  • nodeNetworking

    如需更多信息,请参阅"安装配置参数"。

    注意

    networking.machineNetwork 设置为与首选子网所在的无类别域间路由 (CIDR) 匹配。

    重要

    CIDR 范围 172.17.0.0/16libVirt 保留。对于集群中的网络,您无法使用与 172.17.0.0/16 CIDR 范围重叠的任何其他 CIDR 范围。

第 2 阶段
运行 openshift-install create 清单创建 清单文件后,您可以只使用您要修改的字段定义自定义 Cluster Network Operator 清单。您可以使用清单指定高级网络配置。

在阶段 2 中,您无法覆盖 install-config.yaml 文件中在第 1 阶段指定的值。但是,您可以在第 2 阶段自定义网络插件。

2.2.13. 指定高级网络配置

您可以使用网络插件的高级网络配置将集群集成到现有网络环境中。

您只能在安装集群前指定高级网络配置。

重要

不支持通过修改安装程序创建的 OpenShift Container Platform 清单文件来自定义网络配置。支持应用您创建的清单文件,如以下流程中所示。

先决条件

  • 您已创建 install-config.yaml 文件并完成对其所做的任何修改。

流程

  1. 进入包含安装程序的目录并创建清单:

    $ ./openshift-install create manifests --dir <installation_directory> 
    1
    Copy to Clipboard Toggle word wrap
    1
    <installation_directory> 指定包含集群的 install-config.yaml 文件的目录名称。
  2. <installation_directory>/manifests/ 目录中 为高级网络配置创建一个名为 cluster-network-03-config.yml 的 stub 清单文件:

    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
    Copy to Clipboard Toggle word wrap
  3. cluster-network-03-config.yml 文件中指定集群的高级网络配置,如下例所示:

    为 OVN-Kubernetes 网络供应商启用 IPsec

    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
      defaultNetwork:
        ovnKubernetesConfig:
          ipsecConfig:
            mode: Full
    Copy to Clipboard Toggle word wrap

  4. 可选:备份 manifests/cluster-network-03-config.yml 文件。创建 Ignition 配置文件时,安装程序会使用 manifests/ 目录。
  5. 删除定义 control plane 机器的 Kubernetes 清单文件和计算 MachineSets

    $ rm -f openshift/99_openshift-cluster-api_master-machines-*.yaml openshift/99_openshift-cluster-api_worker-machineset-*.yaml
    Copy to Clipboard Toggle word wrap

    由于您要自行创建和管理这些资源,因此不必初始化这些资源。

    • 您可以使用机器 API 保留 MachineSet 文件以创建计算机器,但您必须更新对它们的引用以匹配您的环境。

2.2.14. Cluster Network Operator 配置

集群网络的配置作为 Cluster Network Operator(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 对象的字段来为集群指定集群网络插件配置。

2.2.14.1. Cluster Network Operator 配置对象

下表中描述了 Cluster Network Operator(CNO)的字段:

Expand
表 2.19. Cluster Network Operator 配置对象
字段类型描述

metadata.name

字符串

CNO 对象的名称。这个名称始终是 集群

spec.clusterNetwork

array

用于指定从哪些 IP 地址块分配 Pod IP 地址以及集群中每个节点的子网前缀长度的列表。例如:

spec:
  clusterNetwork:
  - cidr: 10.128.0.0/19
    hostPrefix: 23
  - cidr: 10.128.32.0/19
    hostPrefix: 23
Copy to Clipboard Toggle word wrap

spec.serviceNetwork

array

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

spec:
  serviceNetwork:
  - 172.30.0.0/14
Copy to Clipboard Toggle word wrap

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

spec.defaultNetwork

object

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

spec.additionalRoutingCapabilities.providers

array

此设置启用动态路由供应商。路由公告功能功能需要 FRR 路由功能供应商。唯一支持的值是 FRR

  • frr : FRR 路由供应商
spec:
  additionalRoutingCapabilities:
    providers:
    - FRR
Copy to Clipboard Toggle word wrap

spec.kubeProxyConfig

object

此对象的字段指定 kube-proxy 配置。如果使用 OVN-Kubernetes 集群网络供应商,则 kube-proxy 配置不会起作用。

重要

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

2.2.14.1.1. defaultNetwork 对象配置

下表列出了 defaultNetwork 对象的值:

Expand
表 2.20. defaultNetwork 对象
字段类型描述

type

字符串

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

注意

OpenShift Container Platform 默认使用 OVN-Kubernetes 网络插件。

ovnKubernetesConfig

object

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

2.2.14.1.1.1. 配置 OVN-Kubernetes 网络插件

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

Expand
表 2.21. ovnKubernetesConfig object
字段类型描述

mtu

integer

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

如果自动探测的值不是您期望的值,请确认节点上主网络接口上的 MTU 是否正确。您不能使用这个选项更改节点上主网络接口的 MTU 值。

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

genevePort

integer

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

ipsecConfig

object

指定用于自定义 IPsec 配置的配置对象。

ipv4

object

为 IPv4 设置指定配置对象。

ipv6

object

为 IPv6 设置指定配置对象。

policyAuditConfig

object

指定用于自定义网络策略审计日志的配置对象。如果未设置,则使用默认的审计日志设置。

routeAdvertisements

字符串

指定是否公告集群网络路由。默认值为 Disabled

  • 启用 :导入到集群网络的路由,并公告集群网络路由,如 RouteAdvertisements 对象中配置的。
  • disabled :不要导入到集群网络的路由,或公告集群网络路由。

gatewayConfig

object

可选:指定一个配置对象来自定义如何将出口流量发送到节点网关。有效值为 SharedLocal。默认值为 Shared。在默认设置中,Open vSwitch (OVS) 将流量直接输出到节点 IP 接口。在 Local 设置中,它会遍历主机网络;因此,它会应用到主机的路由表。

注意

在迁移出口流量时,工作负载和服务流量会受到一定影响,直到 Cluster Network Operator (CNO) 成功推出更改。

Expand
表 2.22. ovnKubernetesConfig.ipv4 object
字段类型描述

internalTransitSwitchSubnet

字符串

如果您的现有网络基础架构与 100.88.0.0/16 IPv4 子网重叠,您可以指定不同的 IP 地址范围供 OVN-Kubernetes 使用。启用东西流量的分布式传输交换机的子网。此子网不能与 OVN-Kubernetes 或主机本身使用的任何其他子网重叠。必须足够大,以适应集群中的每个节点一个 IP 地址。

默认值为 100.88.0.0/16

internalJoinSubnet

字符串

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

默认值为 100.64.0.0/16

Expand
表 2.23. ovnKubernetesConfig.ipv6 object
字段类型描述

internalTransitSwitchSubnet

字符串

如果您的现有网络基础架构与 fd97::/64 IPv6 子网重叠,您可以指定不同的 IP 地址范围供 OVN-Kubernetes 使用。启用东西流量的分布式传输交换机的子网。此子网不能与 OVN-Kubernetes 或主机本身使用的任何其他子网重叠。必须足够大,以适应集群中的每个节点一个 IP 地址。

默认值为 fd97::/64

internalJoinSubnet

字符串

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

默认值为 fd98::/64

Expand
表 2.24. policyAuditConfig object
字段类型描述

rateLimit

整数

每个节点每秒生成一次的消息数量上限。默认值为每秒 20 条消息。

maxFileSize

整数

审计日志的最大大小,以字节为单位。默认值为 50000000 或 50 MB。

maxLogFiles

整数

保留的日志文件的最大数量。

目的地

字符串

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

libc
主机上的 journald 进程的 libc syslog() 函数。
UDP:<host>:<port>
一个 syslog 服务器。将 <host>:<port> 替换为 syslog 服务器的主机 和端口。
Unix:<file>
<file> 指定的 Unix 域套接字文件。
null
不要将审计日志发送到任何其他目标。

syslogFacility

字符串

syslog 工具,如 as kern,如 RFC5424 定义。默认值为 local0。

Expand
表 2.25. gatewayConfig object
字段类型描述

routingViaHost

布尔值

将此字段设置为 true,将来自 pod 的出口流量发送到主机网络堆栈。对于依赖于在内核路由表中手动配置路由的高级别安装和应用程序,您可能需要将出口流量路由到主机网络堆栈。默认情况下,出口流量在 OVN 中进行处理以退出集群,不受内核路由表中的特殊路由的影响。默认值为 false

此字段与 Open vSwitch 硬件卸载功能有交互。如果将此字段设置为 true,则不会获得卸载的性能优势,因为主机网络堆栈会处理出口流量。

ipForwarding

object

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

注意

Restricted 的默认值将 IP 转发设置为 drop。

ipv4

object

可选:指定一个对象来为主机配置内部 OVN-Kubernetes 伪装地址,以服务 IPv4 地址的流量。

ipv6

object

可选:指定一个对象来为主机配置内部 OVN-Kubernetes 伪装地址,以服务 IPv6 地址的流量。

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

internalMasqueradeSubnet

字符串

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

重要

对于 OpenShift Container Platform 4.17 及更新的版本,集群使用 169.254.0.0/17 作为默认的 masquerade 子网。对于升级的集群,默认 masquerade 子网没有变化。

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

internalMasqueradeSubnet

字符串

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

重要

对于 OpenShift Container Platform 4.17 及更新的版本,集群使用 fd69::/112 作为默认的 masquerade 子网。对于升级的集群,默认 masquerade 子网没有变化。

Expand
表 2.28. ipsecConfig 对象
字段类型描述

模式

字符串

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

  • Disabled: 在集群节点上不启用 IPsec。
  • External :对于带有外部主机的网络流量,启用 IPsec。
  • Full: IPsec 为带有外部主机的 pod 流量和网络流量启用 IPsec。

启用 IPSec 的 OVN-Kubernetes 配置示例

defaultNetwork:
  type: OVNKubernetes
  ovnKubernetesConfig:
    mtu: 1400
    genevePort: 6081
    ipsecConfig:
      mode: Full
Copy to Clipboard Toggle word wrap

2.2.15. 创建 Ignition 配置文件

由于您必须手动启动集群机器,因此您必须生成 Ignition 配置文件,集群需要这些配置文件来创建其机器。

重要
  • 安装程序生成的 Ignition 配置文件包含 24 小时后过期的证书,然后在该时进行续订。如果在更新证书前关闭集群,且集群在 24 小时后重启,集群会自动恢复过期的证书。一个例外是,您必须手动批准待处理的 node-bootstrapper 证书签名请求(CSR)来恢复 kubelet 证书。如需更多信息,请参阅从过期的 control plane 证书 中恢复的文档。
  • 建议您在 Ignition 配置文件生成后的 12 小时内使用它们,因为 24 小时的证书会在集群安装后的 16 小时到 22 小时间进行轮转。通过在 12 小时内使用 Ignition 配置文件,您可以避免在安装过程中因为执行了证书更新而导致安装失败的问题。

先决条件

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

流程

  • 获取 Ignition 配置文件:

    $ ./openshift-install create ignition-configs --dir <installation_directory> 
    1
    Copy to Clipboard Toggle word wrap
    1
    对于 <installation_directory>,请指定要存储安装程序创建的文件的目录名称。
    重要

    如果创建了 install-config.yaml 文件,请指定包含该文件的目录。否则,指定一个空目录。有些安装资产,如 bootstrap X.509 证书的过期间隔较短,因此不得重复使用安装目录。如果要重复使用另一个集群安装中的单个文件,您可以将它们复制到您的目录中。但是,安装资产的文件名可能会在发行版本间有所变化。从以前的 OpenShift Container Platform 版本中复制安装文件时请小心。

    该目录中会生成以下文件:

    .
    ├── auth
    │   ├── kubeadmin-password
    │   └── kubeconfig
    ├── bootstrap.ign
    ├── master.ign
    ├── metadata.json
    └── worker.ign
    Copy to Clipboard Toggle word wrap

要在您置备的裸机基础架构上安装 OpenShift Container Platform,您必须在机器上安装 Red Hat Enterprise Linux CoreOS(RHCOS)。安装 RHCOS 时,您必须为您要安装的机器类型提供 OpenShift Container Platform 安装程序生成的 Ignition 配置文件。如果您配置了适当的网络、DNS 和负载均衡基础架构,OpenShift Container Platform bootstrap 过程会在 RHCOS 机器重启后自动启动。

要在机器上安装 RHCOS,请按照以下步骤使用 ISO 镜像或网络 PXE 引导。

注意

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

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

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

    注意

    0.17.0-3 起,coreos-installer 需要 RHEL 9 或更高版本来运行该程序。您仍然可以使用旧版本的 coreos-installer 自定义较新的 OpenShift Container Platform 版本的 RHCOS 工件,并将构建器镜像安装到磁盘。您可以从 coreos-installer image mirror 页下载旧版本的 coreos-installer 二进制文件。

使用 ISO 安装还是 PXE 安装取决于您的情况。PXE 安装需要可用的 DHCP 服务并进行更多准备,但可以使安装过程更加自动化。ISO 安装是一个更手动的过程,如果您设置的机器数超过几台,则可能不方便。

2.2.16.1. 使用 ISO 镜像安装 RHCOS

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

先决条件

  • 已为集群创建 Ignition 配置文件。
  • 您已配置了适当的网络、DNS 和负载平衡基础架构。
  • 您有一个可以从计算机以及您创建的机器访问的 HTTP 服务器。
  • 您已参阅 Advanced RHCOS 安装配置 部分来了解配置功能的不同方法,如网络和磁盘分区。

流程

  1. 获取每个 Ignition 配置文件的 SHA512 摘要。例如,您可以在运行 Linux 的系统上使用以下内容来获取 bootstrap.ign Ignition 配置文件的 SHA512 摘要:

    $ sha512sum <installation_directory>/bootstrap.ign
    Copy to Clipboard Toggle word wrap

    后续步骤中会向 coreos-installer 提供摘要,以验证集群节点上 Ignition 配置文件的真实性。

  2. 将安装程序创建的 bootstrap、control plane 和计算节点 Ignition 配置文件上传到 HTTP 服务器。注意这些文件的 URL。

    重要

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

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

    $ curl -k http://<HTTP_server>/bootstrap.ign 
    1
    Copy to Clipboard Toggle word wrap

    输出示例

      % 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...
    Copy to Clipboard Toggle word wrap

    在命令中将 bootstrap.ign 替换为 master.ignworker.ign,以验证 control plane 和计算节点的 Ignition 配置文件是否可用。

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

    $ openshift-install coreos print-stream-json | grep '\.iso[^.]'
    Copy to Clipboard Toggle word wrap

    输出示例

    "location": "<url>/art/storage/releases/rhcos-4.19-aarch64/<release>/aarch64/rhcos-<release>-live.aarch64.iso",
    "location": "<url>/art/storage/releases/rhcos-4.19-ppc64le/<release>/ppc64le/rhcos-<release>-live.ppc64le.iso",
    "location": "<url>/art/storage/releases/rhcos-4.19-s390x/<release>/s390x/rhcos-<release>-live.s390x.iso",
    "location": "<url>/art/storage/releases/rhcos-4.19/<release>/x86_64/rhcos-<release>-live.x86_64.iso",
    Copy to Clipboard Toggle word wrap

    重要

    RHCOS 镜像可能不会随着 OpenShift Container Platform 的每个发行版本而改变。您必须下载最高版本的镜像,其版本号应小于或等于您安装的 OpenShift Container Platform 版本。如果可用,请使用与 OpenShift Container Platform 版本匹配的镜像版本。这个过程只使用 ISO 镜像。此安装类型不支持 RHCOS qcow2 镜像。

    ISO 文件名类似以下示例:

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

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

    • 将 ISO 映像刻录到磁盘并直接启动。
    • 使用 light-out 管理(LOM)接口使用 ISO 重定向。
  6. 在不指定任何选项或中断实时引导序列的情况下引导 RHCOS ISO 镜像。等待安装程序在 RHCOS live 环境中引导进入 shell 提示符。

    注意

    可以中断 RHCOS 安装引导过程来添加内核参数。但是,在这个 ISO 过程中,您应该使用以下步骤中所述的 coreos-installer 命令,而不是添加内核参数。

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

    $ sudo coreos-installer install --ignition-url=http://<HTTP_server>/<node_type>.ign <device> \ 
    1
    
    --ignition-hash=sha512-<digest> 
    2
    Copy to Clipboard Toggle word wrap
    1 1
    您必须使用 sudo 运行 coreos-installer 命令,因为 core 用户没有执行安装所需的 root 权限。
    2
    当 Ignition 配置文件通过 HTTP URL 获取时,需要 --ignition-hash 选项来验证集群节点上 Ignition 配置文件的真实性。<digest> 是上一步中获取的 Ignition 配置文件 SHA512 摘要。
    注意

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

    以下示例将引导节点安装初始化到 /dev/sda 设备。bootstrap 节点的 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
    Copy to Clipboard Toggle word wrap
  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
    Copy to Clipboard Toggle word wrap

  11. 继续为集群创建其他机器。

    重要

    此时您必须创建 bootstrap 和 control plane 机器。如果 control plane 机器不可调度,请在安装 OpenShift Container Platform 前至少创建两台计算机器。

    如果存在所需的网络、DNS 和负载均衡器基础架构,OpenShift Container Platform bootstrap 过程会在 RHCOS 节点重启后自动启动。

    注意

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

2.2.16.2. 使用 PXE 或 iPXE 启动安装 RHCOS

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

先决条件

  • 已为集群创建 Ignition 配置文件。
  • 您已配置了适当的网络、DNS 和负载平衡基础架构。
  • 您已配置了合适的 PXE 或 iPXE 基础架构。
  • 您有一个可以从计算机以及您创建的机器访问的 HTTP 服务器。
  • 您已参阅 Advanced RHCOS 安装配置 部分来了解配置功能的不同方法,如网络和磁盘分区。

流程

  1. 将安装程序创建的 bootstrap、control plane 和计算节点 Ignition 配置文件上传到 HTTP 服务器。注意这些文件的 URL。

    重要

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

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

    $ curl -k http://<HTTP_server>/bootstrap.ign 
    1
    Copy to Clipboard Toggle word wrap

    输出示例

      % 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...
    Copy to Clipboard Toggle word wrap

    在命令中将 bootstrap.ign 替换为 master.ignworker.ign,以验证 control plane 和计算节点的 Ignition 配置文件是否可用。

  3. 虽然可以从 RHCOS image mirror 页面获取您选择的操作系统实例所需的 RHCOS kernelinitramfsrootfs 文件,但推荐的方法是从 openshift-install 命令的输出中获取 RHCOS 文件的正确版本:

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

    输出示例

    "<url>/art/storage/releases/rhcos-4.19-aarch64/<release>/aarch64/rhcos-<release>-live-kernel-aarch64"
    "<url>/art/storage/releases/rhcos-4.19-aarch64/<release>/aarch64/rhcos-<release>-live-initramfs.aarch64.img"
    "<url>/art/storage/releases/rhcos-4.19-aarch64/<release>/aarch64/rhcos-<release>-live-rootfs.aarch64.img"
    "<url>/art/storage/releases/rhcos-4.19-ppc64le/49.84.202110081256-0/ppc64le/rhcos-<release>-live-kernel-ppc64le"
    "<url>/art/storage/releases/rhcos-4.19-ppc64le/<release>/ppc64le/rhcos-<release>-live-initramfs.ppc64le.img"
    "<url>/art/storage/releases/rhcos-4.19-ppc64le/<release>/ppc64le/rhcos-<release>-live-rootfs.ppc64le.img"
    "<url>/art/storage/releases/rhcos-4.19-s390x/<release>/s390x/rhcos-<release>-live-kernel-s390x"
    "<url>/art/storage/releases/rhcos-4.19-s390x/<release>/s390x/rhcos-<release>-live-initramfs.s390x.img"
    "<url>/art/storage/releases/rhcos-4.19-s390x/<release>/s390x/rhcos-<release>-live-rootfs.s390x.img"
    "<url>/art/storage/releases/rhcos-4.19/<release>/x86_64/rhcos-<release>-live-kernel-x86_64"
    "<url>/art/storage/releases/rhcos-4.19/<release>/x86_64/rhcos-<release>-live-initramfs.x86_64.img"
    "<url>/art/storage/releases/rhcos-4.19/<release>/x86_64/rhcos-<release>-live-rootfs.x86_64.img"
    Copy to Clipboard Toggle word wrap

    重要

    RHCOS 工件可能不会随着 OpenShift Container Platform 的每个发行版本而改变。您必须下载最高版本的镜像,其版本号应小于或等于您安装的 OpenShift Container Platform 版本。这个过程只使用下面描述的适当 kernelinitram fs 和 rootfs 工件。此安装类型不支持 RHCOS QCOW2 镜像。

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

    • kernel:rhcos-<version>-live-kernel-<architecture>
    • initramfs: rhcos-<version>-live-initramfs.<architecture>.img
    • rootfs: rhcos-<version>-live-rootfs.<architecture>.img
  4. rootfskernelinitramfs 文件上传到 HTTP 服务器。

    重要

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

  5. 配置网络引导基础架构,以便在安装 RHCOS 后机器从本地磁盘启动。
  6. 为 RHCOS 镜像配置 PXE 或 iPXE 安装并开始安装。

    为环境修改以下示例菜单条目之一,并验证能否正确访问镜像和 Ignition 文件:

    • 对于 PXE(x86_64)

      DEFAULT pxeboot
      TIMEOUT 20
      PROMPT 0
      LABEL pxeboot
          KERNEL http://<HTTP_server>/rhcos-<version>-live-kernel-<architecture> 
      1
      
          APPEND initrd=http://<HTTP_server>/rhcos-<version>-live-initramfs.<architecture>.img coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/bootstrap.ign 
      2
       
      3
      Copy to Clipboard Toggle word wrap
      1 1
      指定上传到 HTTP 服务器的 live kernel 文件位置。URL 必须是 HTTP、TFTP 或 FTP;不支持 HTTPS 和 NFS。
      2
      如果您使用多个 NIC,请在 ip 选项中指定一个接口。例如,要在名为 eno1 的 NIC 上使用 DHCP,请设置 ip=eno1:dhcp
      3
      指定上传到 HTTP 服务器的 RHCOS 文件的位置。initrd 参数值是 initramfs 文件的位置,coreos.live.rootfs_url 参数值是 rootfs 文件的位置,coreos.inst.ignition_url 参数值则是 bootstrap Ignition 配置文件的位置。您还可以在 APPEND 行中添加更多内核参数来配置联网或其他引导选项。
      注意

      此配置不会在图形控制台的机器上启用串行控制台访问。要配置不同的控制台,请在 APPEND 行中添加一个或多个 console= 参数。例如,添加 console=tty0 console=ttyS0 以将第一个 PC 串口设置为主控制台,并将图形控制台设置为二级控制台。如需更多信息,请参阅如何在 Red Hat Enterprise Linux 中设置串行终端和/或控制台? 和"启用 PXE 和 ISO 安装的串行控制台"部分。

    • 对于 iPXE (x86_64 + aarch64 ):

      kernel http://<HTTP_server>/rhcos-<version>-live-kernel-<architecture> initrd=main coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/bootstrap.ign 
      1
       
      2
      
      initrd --name main http://<HTTP_server>/rhcos-<version>-live-initramfs.<architecture>.img 
      3
      
      boot
      Copy to Clipboard Toggle word wrap
      1
      指定上传到 HTTP 服务器的 RHCOS 文件的位置。kernel 参数值是 kernel 文件的位置,init rd=main 参数用于在 UEFI 系统中引导,coreos.live.rootfs_url 参数值是 rootfs 文件的位置,coreos.inst.ignition_url 参数值则是 bootstrap Ignition 配置文件的位置。
      2
      如果您使用多个 NIC,请在 ip 选项中指定一个接口。例如,要在名为 eno1 的 NIC 上使用 DHCP,请设置 ip=eno1:dhcp
      3
      指定上传到 HTTP 服务器的 initramfs 文件的位置。
      注意

      此配置不会在图形控制台的机器上启用串行控制台访问。要配置不同的控制台,请在 内核参数 中添加一个或多个 console= 参数。例如,添加 console=tty0 console=ttyS0 以将第一个 PC 串口设置为主控制台,并将图形控制台设置为二级控制台。如需更多信息,请参阅如何在 Red Hat Enterprise Linux 中设置串行终端和/或控制台? 和"启用 PXE 和 ISO 安装的串行控制台"部分。

      注意

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

    • 对于 aarch64 中的 PXE(使用 UEFI 和 Grub 作为第二阶段):

      menuentry 'Install CoreOS' {
          linux rhcos-<version>-live-kernel-<architecture>  coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/bootstrap.ign 
      1
       
      2
      
          initrd rhcos-<version>-live-initramfs.<architecture>.img 
      3
      
      }
      Copy to Clipboard Toggle word wrap
      1
      指定上传到 HTTP/TFTP 服务器的 RHCOS 文件的位置。kernel 参数值是 TFTP 服务器中的 kernel 文件的位置。coreos.live.rootfs_url 参数值是 rootfs 文件的位置,coreos.inst.ignition_url 参数值是 HTTP 服务器上的 bootstrap Ignition 配置文件的位置。
      2
      如果您使用多个 NIC,请在 ip 选项中指定一个接口。例如,要在名为 eno1 的 NIC 上使用 DHCP,请设置 ip=eno1:dhcp
      3
      指定上传到 TFTP 服务器的 initramfs 文件的位置。
  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
    Copy to Clipboard Toggle word wrap

  10. 继续为集群创建机器。

    重要

    此时您必须创建 bootstrap 和 control plane 机器。如果 control plane 机器不可调度,请在安装集群前至少创建两台计算机器。

    如果存在所需的网络、DNS 和负载均衡器基础架构,OpenShift Container Platform bootstrap 过程会在 RHCOS 节点重启后自动启动。

    注意

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

2.2.16.3. 高级 RHCOS 安装配置

为 OpenShift Container Platform 手动置备 Red Hat Enterprise Linux CoreOS(RHCOS)节点的一个关键优点是能够进行通过默认的 OpenShift Container Platform 安装方法无法进行的配置。本节介绍了您可以使用的一些技术进行配置,其中包括:

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

本节详述了与 Red Hat Enterprise Linux CoreOS(RHCOS)手动安装的高级配置相关的内容,如磁盘分区、网络以及使用 Ignition 配置的不同方式相关。

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

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

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

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

要配置 ISO 安装,请使用以下步骤:

流程

  1. 引导 ISO 安装程序.
  2. 在 live 系统 shell 提示符下,使用可用的 RHEL 工具(如 nmclinmtui )为 live 系统配置网络。
  3. 运行 coreos-installer 命令以安装系统,添加 --copy-network 选项来复制网络配置。例如:

    $ sudo coreos-installer install --copy-network \
         --ignition-url=http://host/worker.ign /dev/disk/by-id/scsi-<serial_number>
    Copy to Clipboard Toggle word wrap
    重要

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

  4. 重启安装的系统。
2.2.16.3.2. 磁盘分区

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

重要

在节点上使用自定义分区方案可能会导致 OpenShift Container Platform 在某些节点分区上监控或警报。如果要覆盖默认分区,请参阅 了解 OpenShift 文件系统监控(驱除条件) 以了解有关 OpenShift Container Platform 如何监控主机文件系统的更多信息。

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

  • nodefs,这是包含 /var/lib/kubelet 的文件系统
  • imagefs,这是包含 /var/lib/containers 的文件系统

对于默认分区方案,nodefsimagefs 监控相同的根文件系统 /

要在 OpenShift Container Platform 集群节点上安装 RHCOS 时覆盖默认分区,您必须创建单独的分区。您可能想要为容器和容器镜像添加单独的存储分区。例如,通过在独立分区中挂载 /var/lib/containers,kubelet 会单独监控 /var/lib/containers 作为 imagefs 目录,以及 root 文件系统作为 nodefs 目录。

重要

如果您已将磁盘大小调整为托管更大的文件系统,请考虑创建单独的 /var/lib/containers 分区。考虑重新定义具有 xfs 格式的磁盘大小,以减少大量分配组导致的 CPU 时间问题。

2.2.16.3.2.1. 创建独立 /var 分区

通常,您应该使用在 RHCOS 安装过程中创建的默认磁盘分区。然而,在有些情况下您可能需要为预期增长的目录创建独立分区。

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

  • /var/lib/containers :保存随着系统中添加更多镜像和容器而增长的容器相关内容。
  • /var/lib/etcd :保存您可能希望独立保留的数据,比如 etcd 存储的性能优化。
  • /var :保存您可能希望独立保留的数据,以满足审计等目的。

    重要

    对于大于 100GB 的磁盘大小,特别是磁盘大小大于 1TB,请创建一个独立的 /var 分区。

通过单独存储 /var 目录的内容,可以更轻松地根据需要为区域扩展存储,并在以后重新安装 OpenShift Container Platform,并保持该数据的完整性。使用这个方法,您不必再次拉取所有容器,在更新系统时也不必复制大量日志文件。

将独立分区用于 /var 目录或 /var 的子目录也会防止分区目录中的数据增加填充根文件系统。

以下流程通过添加机器配置清单来设置独立的 /var 分区,该清单会在安装准备阶段封装到节点类型的 Ignition 配置文件中。

流程

  1. 在安装主机上,切换到包含 OpenShift Container Platform 安装程序的目录,并为集群生成 Kubernetes 清单:

    $ openshift-install create manifests --dir <installation_directory>
    Copy to Clipboard Toggle word wrap
  2. 创建用于配置额外分区的 Butane 配置。例如,将文件命名为 $HOME/clusterconfig/98-var-partition.bu,将磁盘设备名称改为 worker 系统上存储设备的名称,并根据情况设置存储大小。这个示例将 /var 目录放在一个单独的分区中:

    variant: openshift
    version: 4.19.0
    metadata:
      labels:
        machineconfiguration.openshift.io/role: worker
      name: 98-var-partition
    storage:
      disks:
      - device: /dev/disk/by-id/<device_name> 
    1
    
        partitions:
        - label: var
          start_mib: <partition_start_offset> 
    2
    
          size_mib: <partition_size> 
    3
    
          number: 5
      filesystems:
        - device: /dev/disk/by-partlabel/var
          path: /var
          format: xfs
          mount_options: [defaults, prjquota] 
    4
    
          with_mount_unit: true
    Copy to Clipboard Toggle word wrap
    1
    要分区的磁盘的存储设备名称。
    2
    当在引导磁盘中添加数据分区时,推荐最少使用偏移值 25000 兆字节。root 文件系统会自动调整大小以填充所有可用空间(最多到指定的偏移值)。如果没有指定偏移值,或者指定的值小于推荐的最小值,则生成的 root 文件系统会太小,而在以后进行的 RHCOS 重新安装可能会覆盖数据分区的开始部分。
    3
    以兆字节为单位的数据分区大小。
    4
    对于用于容器存储的文件系统,必须启用 prjquota 挂载选项。
    注意

    在创建单独的 /var 分区时,如果不同的实例类型没有相同的设备名称,则无法将不同的实例类型用于计算节点。

  3. 从 Butane 配置创建一个清单,并将它保存到 clusterconfig/openshift 目录中。例如,运行以下命令:

    $ butane $HOME/clusterconfig/98-var-partition.bu -o $HOME/clusterconfig/openshift/98-var-partition.yaml
    Copy to Clipboard Toggle word wrap
  4. 创建 Ignition 配置文件:

    $ openshift-install create ignition-configs --dir <installation_directory> 
    1
    Copy to Clipboard Toggle word wrap
    1
    对于 <installation_directory>,请指定相同的安装目录。

    为安装目录中的 bootstrap、control plane 和计算节点创建 Ignition 配置文件:

    .
    ├── auth
    │   ├── kubeadmin-password
    │   └── kubeconfig
    ├── bootstrap.ign
    ├── master.ign
    ├── metadata.json
    └── worker.ign
    Copy to Clipboard Toggle word wrap

    <installation_directory>/manifest<installation_directory>/openshift 目录中的文件被嵌套到 Ignition 配置文件中,包括包含 98-var-partition 自定义 MachineConfig 对象的文件。

后续步骤

  • 您可以通过在 RHCOS 安装过程中引用 Ignition 配置文件来应用自定义磁盘分区。
2.2.16.3.2.2. 保留现有分区

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

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

注意

如果您保存了现有分区,且这些分区没有为 RHCOS 留下足够空间,则安装将失败,而不影响保存的分区。

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

这个示例保留分区标签以 数据开头的任何分区(data *):

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

以下示例演示了在运行 coreos-installer 时要保留磁盘上的第 6 个分区:

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

这个示例保留分区 5 及更高分区:

# coreos-installer install --ignition-url http://10.0.2.2:8080/user.ign \
--save-partindex 5- /dev/disk/by-id/scsi-<serial_number>
Copy to Clipboard Toggle word wrap

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

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

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

coreos.inst.save_partlabel=data*
Copy to Clipboard Toggle word wrap

这个 APPEND 选项保留分区 5 及更高分区:

coreos.inst.save_partindex=5-
Copy to Clipboard Toggle word wrap

这个 APPEND 选项保留分区 6:

coreos.inst.save_partindex=6
Copy to Clipboard Toggle word wrap
2.2.16.3.3. 识别 Ignition 配置

在进行 RHCOS 手动安装时,您可以提供两种 Ignition 配置类型,它们有不同的原因:

  • 永久安装 Ignition 配置 :每个手动 RHCOS 安装都需要传递 openshift-installer 生成的 Ignition 配置文件之一,如 bootstrap.ignmaster.ignworker.ign,才能进行安装。

    重要

    不建议直接修改这些 Ignition 配置文件。您可以更新嵌套到 Ignition 配置文件中的清单文件,如上一节示例中所述。

    对于 PXE 安装,您可以使用 coreos.inst.ignition_url= 选项在 APPEND 行上传递 Ignition 配置。对于 ISO 安装,在 ISO 引导至 shell 提示符后,您可以使用带有 --ignition-url= 选项的 coreos-installer 命令行。在这两种情况下,只支持 HTTP 和 HTTPS 协议。

  • 实时安装 Ignition 配置 :可使用 coreos-installer customize 子命令及其各种选项来创建此类型。使用此方法,Ignition 配置会传递到 live 安装介质,在引导时立即运行,并在 RHCOS 系统安装到磁盘之前或之后执行设置任务。这个方法只用于必须执行一次且之后不能再次应用的任务,比如不能使用机器配置进行的高级分区。

    对于 PXE 或 ISO 引导,您可以创建 Ignition 配置,APP END ignition.config.url= 选项来标识 Ignition 配置的位置。您还需要附加 ignition.firstboot ignition.platform.id=metalignition.config.url 选项。

2.2.16.3.4. 默认控制台配置

从 OpenShift Container Platform 4.19 引导镜像安装的 Red Hat Enterprise Linux CoreOS (RHCOS) 节点使用默认控制台,旨在识别大多数虚拟化和裸机设置。不同的云和虚拟化平台可能会根据所选的架构使用不同的默认设置。裸机安装使用内核默认设置,这通常意味着图形控制台是主控制台,并且禁用串行控制台。

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

  • 您希望访问控制台上的紧急 shell 进行调试。
  • 您的云平台没有提供到图形控制台的互动访问,但提供了一个串行控制台。
  • 您需要启用多个控制台。

控制台配置继承自引导镜像。这意味着现有集群中的新节点不受默认控制台的影响。

您可以使用以下方法为裸机安装配置控制台:

  • 在命令行中手动使用 coreos-installer
  • 使用带有 --dest-console 选项的 coreos-installer iso customizecoreos-installer pxe customize 子命令,以创建可自动执行进程的自定义镜像。
注意

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

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

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

流程

  1. 引导 ISO 安装程序.
  2. 运行 coreos-installer 命令来安装系统,添加 --console 选项一次来指定图形控制台,然后第二次指定串行控制台:

    $ coreos-installer install \
    --console=tty0 \
    1
    
    --console=ttyS0,<options> \
    2
    
    --ignition-url=http://host/worker.ign /dev/disk/by-id/scsi-<serial_number>
    Copy to Clipboard Toggle word wrap
    1
    所需的二级控制台。在这种情况下,是图形控制台。省略这个选项将禁用图形控制台。
    2
    所需的主控制台。在这种情况下,是串行控制台。options 字段定义 baud 速率和其他设置。此字段的一个常见值为 115200n8。如果没有提供选项,则使用默认内核值 9600n8。有关这个选项格式的更多信息,请参阅 Linux 内核串口控制台 文档。
  3. 重启安装的系统。

    注意

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

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

2.2.16.3.6. 自定义 live RHCOS ISO 或 PXE 安装

您可以通过将 Ignition 配置文件直接注入镜像中来使用 live ISO 镜像或 PXE 环境来安装 RHCOS。这会创建一个自定义镜像,供您用来置备系统。

对于 ISO 镜像,此操作的机制是 coreos-installer iso custom 子命令,它使用您的配置修改 .iso 文件。同样,PXE 环境的机制是 coreos-installer pxe customize 子命令,它会创建一个包含自定义的新 initramfs 文件。

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

  • 当公司安全策略需要使用时,注入自定义的 CA 证书。
  • 在不需要内核参数的情况下配置网络设置。
  • 嵌入任意预安装和安装后脚本或二进制文件。
2.2.16.3.7. 自定义 live RHCOS ISO 镜像

您可以使用 coreos-installer iso custom 子命令直接自定义 live RHCOS ISO 镜像。当您引导 ISO 镜像时,会自动应用自定义。

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

流程

  1. coreos-installer 镜像镜像页面下载 coreos-installer 二进制文件。
  2. 从 RHCOS 镜像镜像页面和 Ignition 配置文件检索 RHCOS ISO 镜像,然后运行以下命令来直接将 Ignition 配置注入 ISO 镜像:

    $ coreos-installer iso customize rhcos-<version>-live.x86_64.iso \
        --dest-ignition bootstrap.ign \ 
    1
    
        --dest-device /dev/disk/by-id/scsi-<serial_number> 
    2
    Copy to Clipboard Toggle word wrap
    1
    openshift-installer 安装程序生成的 Ignition 配置文件。
    2
    当您指定这个选项时,ISO 镜像会自动运行安装。否则,镜像为安装配置,但不会自动安装,除非您指定了 coreos.inst.install_dev 内核参数。
  3. 可选: 要删除 ISO 镜像自定义并将镜像返回到其 pristine 状态,请运行:

    $ coreos-installer iso reset rhcos-<version>-live.x86_64.iso
    Copy to Clipboard Toggle word wrap

    现在,您可以重新自定义 live ISO 镜像,或者在其 pristine 状态中使用它。

应用您的自定义会影响每个后续 RHCOS 引导。

在使用 OpenShift Container Platform 4.12 及更高版本安装的集群中,串行控制台默认被禁用,所有输出都会写入图形控制台。您可以按照以下流程启用串行控制台。

流程

  1. coreos-installer 镜像镜像页面下载 coreos-installer 二进制文件。
  2. RHCOS image mirror 页中获取 RHCOS ISO 镜像,并运行以下命令来自定义 ISO 镜像,使串行控制台能够接收输出:

    $ coreos-installer iso customize rhcos-<version>-live.x86_64.iso \
      --dest-ignition <path> \
    1
    
      --dest-console tty0 \
    2
    
      --dest-console ttyS0,<options> \
    3
    
      --dest-device /dev/disk/by-id/scsi-<serial_number> 
    4
    Copy to Clipboard Toggle word wrap
    1
    要安装 Ignition 配置的位置。
    2
    所需的二级控制台。在这种情况下,是图形控制台。省略这个选项将禁用图形控制台。
    3
    所需的主控制台。在这种情况下,是串行控制台。options 字段定义 baud 速率和其他设置。此字段的一个常见值为 115200n8。如果没有提供选项,则使用默认内核值 9600n8。有关这个选项格式的更多信息,请参阅 Linux 内核串口控制台文档。
    4
    要安装到的指定磁盘。如果省略这个选项,ISO 镜像会自动运行安装程序,除非还指定了 coreos.inst.install_dev 内核参数。
    注意

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

    自定义会被应用,并影响每个后续 ISO 镜像引导。

  3. 可选: 要删除 ISO 镜像自定义并将镜像返回到其原始状态,请运行以下命令:

    $ coreos-installer iso reset rhcos-<version>-live.x86_64.iso
    Copy to Clipboard Toggle word wrap

    现在,您可以重新自定义 live ISO 镜像,或者在其原始状态中使用它。

您可以使用 custom 子命令的 --ignition-ca 标志向 Ignition 提供证书颁发机构(CA)证书。您可以在安装过程中使用 CA 证书,并在置备安装的系统时使用 CA 证书。

注意

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

流程

  1. coreos-installer 镜像镜像页面下载 coreos-installer 二进制文件。
  2. 从 RHCOS 镜像镜像页面检索 RHCOS ISO 镜像,并运行以下命令来自定义 ISO 镜像以用于自定义 CA:

    $ coreos-installer iso customize rhcos-<version>-live.x86_64.iso --ignition-ca cert.pem
    Copy to Clipboard Toggle word wrap
重要

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

应用自定义 CA 证书会影响每个后续 RHCOS 引导。

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

警告

在创建连接配置文件时,您必须在连接配置文件的文件名中使用 .nmconnection 文件名扩展名。如果不使用 .nmconnection 文件名扩展,集群会将连接配置集应用到 live 环境,但它不会在集群首次启动节点时应用配置,从而导致无法正常工作的设置。

流程

  1. coreos-installer 镜像镜像页面下载 coreos-installer 二进制文件。
  2. 为绑定接口创建连接配置集。例如,在本地目录中创建 bond0.nmconnection 文件,其内容如下:

    [connection]
    id=bond0
    type=bond
    interface-name=bond0
    multi-connect=1
    
    [bond]
    miimon=100
    mode=active-backup
    
    [ipv4]
    method=auto
    
    [ipv6]
    method=auto
    Copy to Clipboard Toggle word wrap
  3. 为二级接口创建连接配置集,以添加到绑定中。例如,在本地目录中创建 bond0-proxy-em1.nmconnection 文件,其内容如下:

    [connection]
    id=em1
    type=ethernet
    interface-name=em1
    master=bond0
    multi-connect=1
    slave-type=bond
    Copy to Clipboard Toggle word wrap
  4. 为二级接口创建连接配置集,以添加到绑定中。例如,在本地目录中创建 bond0-proxy-em2.nmconnection 文件,其内容如下:

    [connection]
    id=em2
    type=ethernet
    interface-name=em2
    master=bond0
    multi-connect=1
    slave-type=bond
    Copy to Clipboard Toggle word wrap
  5. RHCOS 镜像镜像页面检索 RHCOS ISO 镜像,并运行以下命令来使用您配置网络自定义 ISO 镜像:

    $ coreos-installer iso customize rhcos-<version>-live.x86_64.iso \
        --network-keyfile bond0.nmconnection \
        --network-keyfile bond0-proxy-em1.nmconnection \
        --network-keyfile bond0-proxy-em2.nmconnection
    Copy to Clipboard Toggle word wrap

    网络设置应用于实时系统,并传输到目标系统。

您可以设置 iSCSI 目标和 initiator 值,以便使用自定义的 live RHCOS 镜像版本自动挂载、引导和配置。

先决条件

  1. 您有一个 iSCSI 目标,您要在其中安装 RHCOS。

流程

  1. coreos-installer 镜像镜像页面下载 coreos-installer 二进制文件。
  2. RHCOS 镜像镜像页面检索 RHCOS ISO 镜像,并运行以下命令使用以下信息自定义 ISO 镜像:

    $ coreos-installer iso customize \
        --pre-install mount-iscsi.sh \ 
    1
    
        --post-install unmount-iscsi.sh \ 
    2
    
        --dest-device /dev/disk/by-path/<IP_address>:<port>-iscsi-<target_iqn>-lun-<lun> \ 
    3
    
        --dest-ignition config.ign \ 
    4
    
        --dest-karg-append rd.iscsi.initiator=<initiator_iqn> \ 
    5
    
        --dest-karg-append netroot=<target_iqn> \ 
    6
    
        -o custom.iso rhcos-<version>-live.x86_64.iso
    Copy to Clipboard Toggle word wrap
    1
    安装之前运行的脚本。它应包含用于挂载 iSCSI 目标以及启用多路径的任何命令的 iscsiadm 命令。
    2
    安装后运行的脚本。它应包含命令 iscsiadm --mode node --logout=all
    3
    目标系统的位置。您必须提供目标门户的 IP 地址、关联的端口号、目标 iSCSI 节点采用 IQN 格式,以及 iSCSI 逻辑单元号(LUN)。
    4
    目标系统的 Ignition 配置。
    5
    iSCSI 启动器或客户端,以 IQN 格式的名称。启动器构成连接到 iSCSI 目标的一个会话。
    6
    iSCSI 目标或服务器的名称(IQN 格式)。

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

您可以设置 iSCSI 目标和 initiator 值,以便使用自定义的 live RHCOS 镜像版本自动挂载、引导和配置。

先决条件

  1. 您有一个 iSCSI 目标,您要在其中安装 RHCOS。
  2. 可选:有多路径 iSCSI 目标。

流程

  1. coreos-installer 镜像镜像页面下载 coreos-installer 二进制文件。
  2. RHCOS 镜像镜像页面检索 RHCOS ISO 镜像,并运行以下命令使用以下信息自定义 ISO 镜像:

    $ coreos-installer iso customize \
        --pre-install mount-iscsi.sh \ 
    1
    
        --post-install unmount-iscsi.sh \ 
    2
    
        --dest-device /dev/mapper/mpatha \ 
    3
    
        --dest-ignition config.ign \ 
    4
    
        --dest-karg-append rd.iscsi.firmware=1 \ 
    5
    
        --dest-karg-append rd.multipath=default \ 
    6
    
        -o custom.iso rhcos-<version>-live.x86_64.iso
    Copy to Clipboard Toggle word wrap
    1
    安装之前运行的脚本。它应包含用于挂载 iSCSI 目标以及启用多路径的任何命令的 iscsiadm 命令。
    2
    安装后运行的脚本。它应包含命令 iscsiadm --mode node --logout=all
    3
    设备的路径。如果连接了多个多路径设备,或者需要明确指定,您使用多路径(/dev/mapper/mpatha),您可以使用 /dev/disk/by-path 中可用的 World Wide Name (WWN) 符号链接。
    4
    目标系统的 Ignition 配置。
    5
    iSCSI 参数从 BIOS 固件读取。
    6
    可选:如果您要启用多路径,请包含此参数。

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

2.2.16.3.8. 自定义 live RHCOS PXE 环境

您可以使用 coreos-installer pxe customize 子命令直接自定义 live RHCOS PXE 环境。当您引导 PXE 环境时,会自动应用自定义。

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

流程

  1. coreos-installer 镜像镜像页面下载 coreos-installer 二进制文件。
  2. RHCOS 镜像镜像页面和 Ignition 配置文件获取 RHCOS kernel, initramfsrootfs 文件,然后运行以下命令创建一个包含 Ignition 配置中的自定义的新 initramfs 文件:

    $ coreos-installer pxe customize rhcos-<version>-live-initramfs.x86_64.img \
        --dest-ignition bootstrap.ign \ 
    1
    
        --dest-device /dev/disk/by-id/scsi-<serial_number> \ 
    2
    
        -o rhcos-<version>-custom-initramfs.x86_64.img 
    3
    Copy to Clipboard Toggle word wrap
    1
    openshift-installer 生成的 Ignition 配置文件。
    2
    当您指定这个选项时,PXE 环境会自动运行安装。否则,为安装配置了镜像,除非指定了 coreos.inst.install_dev 内核参数,否则不会自动这样做。
    3
    在 PXE 配置中使用自定义 initramfs 文件。添加 ignition.firstbootignition.platform.id=metal 内核参数(如果它们尚不存在)。

应用您的自定义会影响每个后续 RHCOS 引导。

在使用 OpenShift Container Platform 4.12 及更高版本安装的集群中,串行控制台默认被禁用,所有输出都会写入图形控制台。您可以按照以下流程启用串行控制台。

流程

  1. coreos-installer 镜像镜像页面下载 coreos-installer 二进制文件。
  2. RHCOS image mirror 页面获取 kernel, initramfsrootfs 文件,然后运行以下命令来创建新的自定义 initramfs 文件,以便串行控制台接收输出:

    $ coreos-installer pxe customize rhcos-<version>-live-initramfs.x86_64.img \
      --dest-ignition <path> \
    1
    
      --dest-console tty0 \
    2
    
      --dest-console ttyS0,<options> \
    3
    
      --dest-device /dev/disk/by-id/scsi-<serial_number> \
    4
    
      -o rhcos-<version>-custom-initramfs.x86_64.img 
    5
    Copy to Clipboard Toggle word wrap
    1
    要安装 Ignition 配置的位置。
    2
    所需的二级控制台。在这种情况下,是图形控制台。省略这个选项将禁用图形控制台。
    3
    所需的主控制台。在这种情况下,是串行控制台。options 字段定义 baud 速率和其他设置。此字段的一个常见值为 115200n8。如果没有提供选项,则使用默认内核值 9600n8。有关这个选项格式的更多信息,请参阅 Linux 内核串口控制台文档。
    4
    要安装到的指定磁盘。如果省略这个选项,PXE 环境会自动运行安装程序,除非还指定了 coreos.inst.install_dev 内核参数。
    5
    在 PXE 配置中使用自定义 initramfs 文件。添加 ignition.firstbootignition.platform.id=metal 内核参数(如果它们尚不存在)。

    自定义会被应用,并影响 PXE 环境的每个后续引导。

您可以使用 custom 子命令的 --ignition-ca 标志向 Ignition 提供证书颁发机构(CA)证书。您可以在安装过程中使用 CA 证书,并在置备安装的系统时使用 CA 证书。

注意

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

流程

  1. coreos-installer 镜像镜像页面下载 coreos-installer 二进制文件。
  2. RHCOS 镜像镜像页面获取 RHCOS kernelinitramfsrootfs 文件,并运行以下命令来创建一个新的自定义 initramfs 文件以用于自定义 CA:

    $ coreos-installer pxe customize rhcos-<version>-live-initramfs.x86_64.img \
        --ignition-ca cert.pem \
        -o rhcos-<version>-custom-initramfs.x86_64.img
    Copy to Clipboard Toggle word wrap
  3. 在 PXE 配置中使用自定义 initramfs 文件。添加 ignition.firstbootignition.platform.id=metal 内核参数(如果它们尚不存在)。
重要

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

应用自定义 CA 证书会影响每个后续 RHCOS 引导。

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

警告

在创建连接配置文件时,您必须在连接配置文件的文件名中使用 .nmconnection 文件名扩展名。如果不使用 .nmconnection 文件名扩展,集群会将连接配置集应用到 live 环境,但它不会在集群首次启动节点时应用配置,从而导致无法正常工作的设置。

流程

  1. coreos-installer 镜像镜像页面下载 coreos-installer 二进制文件。
  2. 为绑定接口创建连接配置集。例如,在本地目录中创建 bond0.nmconnection 文件,其内容如下:

    [connection]
    id=bond0
    type=bond
    interface-name=bond0
    multi-connect=1
    
    [bond]
    miimon=100
    mode=active-backup
    
    [ipv4]
    method=auto
    
    [ipv6]
    method=auto
    Copy to Clipboard Toggle word wrap
  3. 为二级接口创建连接配置集,以添加到绑定中。例如,在本地目录中创建 bond0-proxy-em1.nmconnection 文件,其内容如下:

    [connection]
    id=em1
    type=ethernet
    interface-name=em1
    master=bond0
    multi-connect=1
    slave-type=bond
    Copy to Clipboard Toggle word wrap
  4. 为二级接口创建连接配置集,以添加到绑定中。例如,在本地目录中创建 bond0-proxy-em2.nmconnection 文件,其内容如下:

    [connection]
    id=em2
    type=ethernet
    interface-name=em2
    master=bond0
    multi-connect=1
    slave-type=bond
    Copy to Clipboard Toggle word wrap
  5. RHCOS 镜像镜像页面获取 RHCOS kernelinitramfsrootfs 文件,并运行以下命令来创建一个新的自定义 initramfs 文件,它包括您的配置网络:

    $ coreos-installer pxe customize rhcos-<version>-live-initramfs.x86_64.img \
        --network-keyfile bond0.nmconnection \
        --network-keyfile bond0-proxy-em1.nmconnection \
        --network-keyfile bond0-proxy-em2.nmconnection \
        -o rhcos-<version>-custom-initramfs.x86_64.img
    Copy to Clipboard Toggle word wrap
  6. 在 PXE 配置中使用自定义 initramfs 文件。添加 ignition.firstbootignition.platform.id=metal 内核参数(如果它们尚不存在)。

    网络设置应用于实时系统,并传输到目标系统。

您可以设置 iSCSI 目标和 initiator 值,以便使用自定义的 live RHCOS 镜像版本自动挂载、引导和配置。

先决条件

  1. 您有一个 iSCSI 目标,您要在其中安装 RHCOS。

流程

  1. coreos-installer 镜像镜像页面下载 coreos-installer 二进制文件。
  2. RHCOS image mirror 页获取 RHCOS kernelinitramfsrootfs 文件,并运行以下命令来使用以下信息创建新的自定义 initramfs 文件:

    $ coreos-installer pxe customize \
        --pre-install mount-iscsi.sh \ 
    1
    
        --post-install unmount-iscsi.sh \ 
    2
    
        --dest-device /dev/disk/by-path/<IP_address>:<port>-iscsi-<target_iqn>-lun-<lun> \ 
    3
    
        --dest-ignition config.ign \ 
    4
    
        --dest-karg-append rd.iscsi.initiator=<initiator_iqn> \ 
    5
    
        --dest-karg-append netroot=<target_iqn> \ 
    6
    
        -o custom.img rhcos-<version>-live-initramfs.x86_64.img
    Copy to Clipboard Toggle word wrap
    1
    安装之前运行的脚本。它应包含用于挂载 iSCSI 目标以及启用多路径的任何命令的 iscsiadm 命令。
    2
    安装后运行的脚本。它应包含命令 iscsiadm --mode node --logout=all
    3
    目标系统的位置。您必须提供目标门户的 IP 地址、关联的端口号、目标 iSCSI 节点采用 IQN 格式,以及 iSCSI 逻辑单元号(LUN)。
    4
    目标系统的 Ignition 配置。
    5
    iSCSI 启动器或客户端,以 IQN 格式的名称。启动器构成连接到 iSCSI 目标的一个会话。
    6
    iSCSI 目标或服务器的名称(IQN 格式)。

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

您可以设置 iSCSI 目标和 initiator 值,以便使用自定义的 live RHCOS 镜像版本自动挂载、引导和配置。

先决条件

  1. 您有一个 iSCSI 目标,您要在其中安装 RHCOS。
  2. 可选:有多路径 iSCSI 目标。

流程

  1. coreos-installer 镜像镜像页面下载 coreos-installer 二进制文件。
  2. RHCOS image mirror 页获取 RHCOS kernelinitramfsrootfs 文件,并运行以下命令来使用以下信息创建新的自定义 initramfs 文件:

    $ coreos-installer pxe customize \
        --pre-install mount-iscsi.sh \ 
    1
    
        --post-install unmount-iscsi.sh \ 
    2
    
        --dest-device /dev/mapper/mpatha \ 
    3
    
        --dest-ignition config.ign \ 
    4
    
        --dest-karg-append rd.iscsi.firmware=1 \ 
    5
    
        --dest-karg-append rd.multipath=default \ 
    6
    
        -o custom.img rhcos-<version>-live-initramfs.x86_64.img
    Copy to Clipboard Toggle word wrap
    1
    安装之前运行的脚本。它应包含用于挂载 iSCSI 目标的 iscsiadm 命令。
    2
    安装后运行的脚本。它应包含命令 iscsiadm --mode node --logout=all
    3
    设备的路径。如果连接了多个多路径设备,或者需要明确指定,您使用多路径(/dev/mapper/mpatha),您可以使用 /dev/disk/by-path 中可用的 World Wide Name (WWN) 符号链接。
    4
    目标系统的 Ignition 配置。
    5
    iSCSI 参数从 BIOS 固件读取。
    6
    可选:如果您要启用多路径,请包含此参数。

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

2.2.16.3.9. 高级 RHCOS 安装参考

本节演示了网络配置和其他高级选项,允许您修改 Red Hat Enterprise Linux CoreOS(RHCOS)手动安装过程。下表描述了您可以用于 RHCOS live 安装程序和 coreos-installer 命令的内核参数和命令行选项。

2.2.16.3.9.1. ISO 安装的网络和绑定选项

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

重要

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

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

注意

添加内核参数时顺序非常重要: ip=、name server=,然后 bond=

网络选项在系统引导过程中传递给 dracut 工具。有关 dracut 支持的网络选项的更多信息,请参阅 dracut.cmdline 手册页

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

2.2.16.3.9.1.1. 配置 DHCP 或静态 IP 地址

要配置 IP 地址,可使用 DHCP(ip=dhcp)或设置单独的静态 IP 地址(ip=<host_ip>)。如果设置静态 IP,则必须在每个节点上识别 DNS 服务器 IP 地址(名称服务器=<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
Copy to Clipboard Toggle word wrap
注意

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

2.2.16.3.9.1.2. 配置没有静态主机名的 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
Copy to Clipboard Toggle word wrap
2.2.16.3.9.1.3. 指定多个网络接口

您可以通过设置多个 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
Copy to Clipboard Toggle word wrap
2.2.16.3.9.1.4. 配置默认网关和路由

可选:您可以通过设置 a rd.route= 值来配置到额外网络的路由。

注意

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

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

    ip=::10.10.10.254::::
    Copy to Clipboard Toggle word wrap
  • 输入以下命令为额外网络配置路由:

    rd.route=20.20.20.0/24:20.20.20.254:enp2s0
    Copy to Clipboard Toggle word wrap
2.2.16.3.9.1.5. 在单个接口中禁用 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
Copy to Clipboard Toggle word wrap
2.2.16.3.9.1.6. 合并 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
Copy to Clipboard Toggle word wrap
2.2.16.3.9.1.7. 在独立接口上配置 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
    Copy to Clipboard Toggle word wrap
  • 要在网络接口中配置 VLAN 并使用 DHCP,请运行以下命令:

    ip=enp2s0.100:dhcp
    vlan=enp2s0.100:enp2s0
    Copy to Clipboard Toggle word wrap
2.2.16.3.9.1.8. 提供多个 DNS 服务器

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

nameserver=1.1.1.1
nameserver=8.8.8.8
Copy to Clipboard Toggle word wrap
2.2.16.3.9.1.9. 将多个网络接口绑定到一个接口

可选: 您可以使用 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
      Copy to Clipboard Toggle word wrap
    • 要将绑定接口配置为使用静态 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
      Copy to Clipboard Toggle word wrap

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

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

  1. 按照管理 SR-IOV 设备中的指导创建 SR-IOV 虚拟功能(VF)。按照"将 SR-IOV 网络设备附加到虚拟机"部分中的步骤操作。
  2. 创建绑定,将所需的 VF 附加到绑定,并根据配置网络绑定的指导设置绑定链接状态。按照任何描述的步骤创建绑定。

以下示例演示了您必须使用的语法:

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

    <name> 是绑定设备名称 (bond0)、<network_interfaces> 由内核中已知的名称来代表虚拟功能(VF),并显示在 ip link 命令的输出中 (eno1f0,eno2f0),options 是以逗号分隔的绑定选项列表。输入 modinfo bonding 查看可用选项。

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

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

      bond=bond0:eno1f0,eno2f0:mode=active-backup
      ip=bond0:dhcp
      Copy to Clipboard Toggle word wrap
    • 要将绑定接口配置为使用静态 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
      Copy to Clipboard Toggle word wrap
2.2.16.3.9.1.11. 使用网络团队

可选: 您可以使用 team= 参数来将网络团队用作绑定的替代选择:

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

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

注意

当 RHCOS 切换到即将推出的 RHEL 版本时,团队(team)功能被计划弃用。如需更多信息,请参阅红帽知识库文章

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

team=team0:em1,em2
ip=team0:dhcp
Copy to Clipboard Toggle word wrap
2.2.16.3.9.2. ISO 和 PXE 安装的 coreos-installer 选项

从 ISO 镜像引导 RHCOS live 环境后,您可以通过 在命令提示符下运行 coreos-installer install <options> <device > 来安装 RHCOS。

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

Expand
表 2.29. coreos-installer 子命令、命令行选项和参数

coreos-installer install 子命令

子命令

描述

$ coreos-installer install <options> <device>

在 ISO 镜像中嵌入 Ignition 配置。

coreos-installer install 子命令选项

选项

描述

-u, --image-url <url>

手动指定镜像 URL。

-f,--image-file <path>

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

-i, --ignition-file <path>

从文件中嵌入 Ignition 配置。

-i,--ignition-url <URL>

从 URL 嵌入 Ignition 配置。

--ignition-hash <digest>

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

-p, --platform <name>

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

--console <spec>

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

--append-karg <arg>…​

将默认内核参数附加到安装的系统中。

--delete-karg <arg>…​

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

-n, --copy-network

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

重要

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

--network-dir <path>

用于 -n。默认为 /etc/NetworkManager/system-connections/

--save-partlabel <lx>..

使用这个标签 glob 保存分区。

--save-partindex <id>…​

使用这个数值或范围保存分区。

--insecure

跳过 RHCOS 镜像签名验证。

--insecure-ignition

允许没有 HTTPS 或 hash 的 Ignition URL。

--architecture <name>

目标 CPU 架构.有效值为 x86_64aarch64

--preserve-on-error

出错时不要清除分区表。

-h,--help

打印帮助信息.

coreos-installer install 子命令参数

参数

描述

<device>

目标设备.

coreos-installer ISO 子命令

子命令

描述

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

自定义 RHCOS live ISO 镜像。

coreos-installer iso reset <options> <ISO_image>

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

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

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

coreos-installer ISO customize 子命令选项

选项

描述

--dest-ignition <path>

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

--dest-console <spec>

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

--dest-device <path>

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

--dest-karg-append <arg>

为每个目标系统引导添加一个内核参数。

--dest-karg-delete <arg>

从目标系统的每个引导中删除内核参数。

--network-keyfile <path>

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

--ignition-ca <path>

指定要被 Ignition 信任的额外 TLS 证书颁发机构。

--pre-install <path>

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

--post-install <path>

安装后运行指定的脚本。

--installer-config <path>

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

--live-ignition <path>

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

--live-karg-append <arg>

为每个实时环境引导添加一个内核参数。

--live-karg-delete <arg>

从实时环境每次引导时删除内核参数。

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

在每次启动 live 环境时替换内核参数,格式为 key=old=new

-f,--force

覆盖现有的 Ignition 配置。

-o,--output <path>

将 ISO 写入到新的输出文件。

-h,--help

打印帮助信息.

coreos-installer PXE 子命令

子命令

描述

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

coreos-installer pxe customize <options> <path>

自定义 RHCOS live PXE 引导配置。

coreos-installer pxe ignition wrap <options>

在镜像中嵌套 Ignition 配置。

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

在镜像中显示嵌套的 Ignition 配置。

coreos-installer PXE customize 子命令选项

选项

描述

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

--dest-ignition <path>

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

--dest-console <spec>

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

--dest-device <path>

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

--network-keyfile <path>

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

--ignition-ca <path>

指定要被 Ignition 信任的额外 TLS 证书颁发机构。

--pre-install <path>

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

post-install <path>

安装后运行指定的脚本。

--installer-config <path>

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

--live-ignition <path>

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

-o, --output <path>

将 initramfs 写入一个新输出文件。

注意

PXE 环境需要这个选项。

-h,--help

打印帮助信息.

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

  • 对于 ISO 安装,可以通过在启动加载器菜单中中断自动引导来添加 coreos.inst 选项。您可以在突出显示 RHEL CoreOS(Live) 菜单选项时按 TAB 来中断自动引导。
  • 对于 PXE 或 iPXE 安装,在引导 RHCOS live 安装程序前,coreos.inst 选项必须添加到 APPEND 行。

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

Expand
表 2.30. coreos.inst 引导选项
参数描述

coreos.inst.install_dev

必需。要安装到的系统中的块设备。

注意

建议您使用完整路径,如 /dev/sda,但 允许使用

coreos.inst.ignition_url

可选:嵌入到安装的系统中的 Ignition 配置的 URL。如果没有指定 URL,则不会嵌入 Ignition 配置。仅支持 HTTP 和 HTTPS 协议。

coreos.inst.save_partlabel

可选:在安装过程中要保留的分区分离标签。允许使用 glob 风格的通配符。指定分区不需要存在。

coreos.inst.save_partindex

可选:在安装过程中压缩要保留的分区索引。允许 m-n 范围,mn 可以被省略。指定分区不需要存在。

coreos.inst.insecure

可选:将 coreos.inst.image_url 指定的 OS 镜像提交取消签名。

coreos.inst.image_url

可选:下载并安装指定的 RHCOS 镜像。

  • 这个参数不应该在生产环境中使用,而是只用于调试目的。
  • 虽然此参数可用于安装与 live 介质不匹配的 RHCOS 版本,但建议您使用与您要安装版本匹配的介质。
  • 如果您使用 coreos.inst.image_url,还必须使用 coreos.inst.insecure。这是因为,裸机介质没有为 OpenShift Container Platform 进行 GPG 签名。
  • 仅支持 HTTP 和 HTTPS 协议。

coreos.inst.skip_reboot

可选:安装后系统不会重启。安装完成后,您将收到提示,提示您检查在安装过程中发生的情况。这个参数不应该在生产环境中使用,而是只用于调试目的。

coreos.inst.platform_id

可选:安装 RHCOS 镜像的平台的 Ignition 平台 ID。默认为 metal。这个选项决定是否从云供应商(如 VMware)请求 Ignition 配置。例如: coreos.inst.platform_id=vmware

ignition.config.url

可选:用于实时引导的 Ignition 配置的 URL。例如,这可用于自定义调用 coreos-installer 的方式,或者用于在安装前或安装后运行代码。这与 coreos.inst.ignition_url (这是已安装系统的 Ignition 配置)不同。

2.2.16.4. 在 RHCOS 上启用带有内核参数的多路径

RHCOS 支持主磁盘上的多路径,支持更强大的硬件故障弹性,以获得更高的主机可用性。

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

在任何 I/O 到未优化路径会导致 I/O 系统错误的设置中,您必须在安装时启用多路径。

重要

在 IBM Z® 和 IBM® LinuxONE 中,您只能在在安装过程中为它配置集群时启用多路径。如需更多信息,请参阅在 IBM Z® 和 IBM® LinuxONE 上安装使用 z/VM 的集群"安装 RHCOS 并启动 OpenShift Container Platform bootstrap 过程"。

以下流程在安装时启用多路径,并在 coreos-installer install 命令中附加内核参数,以便安装的系统本身将使用从第一次引导开始的多路径。

注意

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

先决条件

  • 已为集群创建 Ignition 配置文件。
  • 您已参阅 安装 RHCOS 并启动 OpenShift Container Platform bootstrap 过程

流程

  1. 要启用多路径并启动 multipathd 守护进程,请在安装主机上运行以下命令:

    $ mpathconf --enable && systemctl start multipathd.service
    Copy to Clipboard Toggle word wrap
    • 可选:如果引导 PXE 或 ISO,则可以通过从内核命令行添加 rd.multipath=default 来启用多路径。
  2. 通过调用 coreos-installer 程序附加内核参数:

    • 如果只有一个多路径设备连接到计算机,则应在路径 /dev/mapper/mpatha 上可用。例如:

      $ coreos-installer install /dev/mapper/mpatha \
      1
      
      --ignition-url=http://host/worker.ign \
      --append-karg rd.multipath=default \
      --append-karg root=/dev/disk/by-label/dm-mpath-root \
      --append-karg rw
      Copy to Clipboard Toggle word wrap
      1
      表示单一多路径设备的路径。
    • 如果有多个多路径设备连接到计算机,或者更为明确,而不是使用 /dev/mapper/mpatha,则建议使用 /dev/disk/by-id 中可用的 World Wide Name(WWN)符号链接。例如:

      $ coreos-installer install /dev/disk/by-id/wwn-<wwn_ID> \
      1
      
      --ignition-url=http://host/worker.ign \
      --append-karg rd.multipath=default \
      --append-karg root=/dev/disk/by-label/dm-mpath-root \
      --append-karg rw
      Copy to Clipboard Toggle word wrap
      1
      表示目标多路径设备的 WWN ID。例如: 0xx194e957fcedb4841

      当使用特殊 coreos.inst.* 参数指示 live 安装程序时,这个符号链接也可以用作 coreos.inst.install_dev 内核参数。如需更多信息,请参阅"安装 RHCOS 和启动 OpenShift Container Platform bootstrap 过程"。

  3. 重启安装的系统。
  4. 前往其中一个 worker 节点并列出内核命令行参数(主机上的 /proc/cmdline 中),以检查内核参数是否正常工作:

    $ oc debug node/ip-10-0-141-105.ec2.internal
    Copy to Clipboard Toggle word wrap

    输出示例

    Starting pod/ip-10-0-141-105ec2internal-debug ...
    To use host binaries, run `chroot /host`
    
    sh-4.2# cat /host/proc/cmdline
    ...
    rd.multipath=default root=/dev/disk/by-label/dm-mpath-root
    ...
    
    sh-4.2# exit
    Copy to Clipboard Toggle word wrap

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

2.2.16.4.1. 在辅助磁盘中启用多路径

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

先决条件

  • 您已阅读了磁盘分区一节。
  • 您已在 RHCOS 中使用内核参数读取启用多路径
  • 已安装 Butane 工具。

流程

  1. 使用类似如下的信息创建一个 Butane 配置:

    multipath-config.bu 示例

    variant: openshift
    version: 4.19.0
    systemd:
      units:
        - name: mpath-configure.service
          enabled: true
          contents: |
            [Unit]
            Description=Configure Multipath on Secondary Disk
            ConditionFirstBoot=true
            ConditionPathExists=!/etc/multipath.conf
            Before=multipathd.service 
    1
    
            DefaultDependencies=no
    
            [Service]
            Type=oneshot
            ExecStart=/usr/sbin/mpathconf --enable 
    2
    
    
            [Install]
            WantedBy=multi-user.target
        - name: mpath-var-lib-container.service
          enabled: true
          contents: |
            [Unit]
            Description=Set Up Multipath On /var/lib/containers
            ConditionFirstBoot=true 
    3
    
            Requires=dev-mapper-mpatha.device
            After=dev-mapper-mpatha.device
            After=ostree-remount.service
            Before=kubelet.service
            DefaultDependencies=no
    
            [Service] 
    4
    
            Type=oneshot
            ExecStart=/usr/sbin/mkfs.xfs -L containers -m reflink=1 /dev/mapper/mpatha
            ExecStart=/usr/bin/mkdir -p /var/lib/containers
    
            [Install]
            WantedBy=multi-user.target
        - name: var-lib-containers.mount
          enabled: true
          contents: |
            [Unit]
            Description=Mount /var/lib/containers
            After=mpath-var-lib-containers.service
            Before=kubelet.service 
    5
    
    
            [Mount] 
    6
    
            What=/dev/disk/by-label/dm-mpath-containers
            Where=/var/lib/containers
            Type=xfs
    
            [Install]
            WantedBy=multi-user.target
    Copy to Clipboard Toggle word wrap

    1
    在启动 multipath 守护进程前,必须设置配置。
    2
    启动 mpathconf 实用程序。
    3
    此字段必须设置为 true
    4
    创建文件系统和目录 /var/lib/containers
    5
    在启动任何节点前必须挂载该设备。
    6
    将设备挂载到 /var/lib/containers 挂载点。此位置不能是符号链接。
  2. 运行以下命令来创建 Ignition 配置:

    $ butane --pretty --strict multipath-config.bu > multipath-config.ign
    Copy to Clipboard Toggle word wrap
  3. 继续第一个引导 RHCOS 安装过程的其余部分。

    重要

    不要在安装过程中在命令行上添加 rd.multipathroot 内核参数,除非主磁盘也是多路径的。

2.2.16.5. 在 iSCSI 引导设备中手动安装 RHCOS

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

先决条件

  1. 您在 RHCOS live 环境中。
  2. 您有一个要在其上安装 RHCOS 的 iSCSI 目标。

流程

  1. 运行以下命令,从 live 环境中挂载 iSCSI 目标:

    $ iscsiadm \
        --mode discovery \
        --type sendtargets
        --portal <IP_address> \ 
    1
    
        --login
    Copy to Clipboard Toggle word wrap
    1
    目标门户的 IP 地址。
  2. 运行以下命令并使用必要的内核参数将 RHCOS 安装到 iSCSI 目标上,例如:

    $ coreos-installer install \
    /dev/disk/by-path/ip-<IP_address>:<port>-iscsi-<target_iqn>-lun-<lun> \ 
    1
    
    --append-karg rd.iscsi.initiator=<initiator_iqn> \ 
    2
    
    --append.karg netroot=<target_iqn> \ 
    3
    
    --console ttyS0,115200n8
    --ignition-file <path_to_file>
    Copy to Clipboard Toggle word wrap
    1
    您要安装到的位置。您必须提供目标门户的 IP 地址、关联的端口号、目标 iSCSI 节点采用 IQN 格式,以及 iSCSI 逻辑单元号(LUN)。
    2
    iSCSI 启动器或客户端,以 IQN 格式的名称。启动器构成连接到 iSCSI 目标的一个会话。
    3
    iSCSI 目标或服务器的名称(IQN 格式)。

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

  3. 使用以下命令卸载 iSCSI 磁盘:

    $ iscsiadm --mode node --logoutall=all
    Copy to Clipboard Toggle word wrap

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

2.2.16.6. 使用 iBFT 在 iSCSI 引导设备中安装 RHCOS

在一个完全无盘机器上,也可以通过 iBFT. iSCSI 多路径传递 iSCSI 目标和启动器值。

先决条件

  1. 您在 RHCOS live 环境中。
  2. 您有一个 iSCSI 目标,您要在其中安装 RHCOS。
  3. 可选:有多路径 iSCSI 目标。

流程

  1. 运行以下命令,从 live 环境中挂载 iSCSI 目标:

    $ iscsiadm \
        --mode discovery \
        --type sendtargets
        --portal <IP_address> \ 
    1
    
        --login
    Copy to Clipboard Toggle word wrap
    1
    目标门户的 IP 地址。
  2. 可选:使用以下命令启用多路径并启动守护进程:

    $ mpathconf --enable && systemctl start multipathd.service
    Copy to Clipboard Toggle word wrap
  3. 运行以下命令并使用必要的内核参数将 RHCOS 安装到 iSCSI 目标上,例如:

    $ coreos-installer install \
        /dev/mapper/mpatha \ 
    1
    
        --append-karg rd.iscsi.firmware=1 \ 
    2
    
        --append-karg rd.multipath=default \ 
    3
    
        --console ttyS0 \
        --ignition-file <path_to_file>
    Copy to Clipboard Toggle word wrap
    1
    单一多路径设备的路径。如果连接了多个多路径设备,或者需要明确指定,您可以使用 /dev/disk/by-path 中可用的 World Wide Name (WWN) 符号链接。
    2
    iSCSI 参数从 BIOS 固件读取。
    3
    可选:如果您要启用多路径,请包含此参数。

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

  4. 卸载 iSCSI 磁盘:

    $ iscsiadm --mode node --logout=all
    Copy to Clipboard Toggle word wrap

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

2.2.17. 等待 bootstrap 过程完成

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

先决条件

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

流程

  1. 监控 bootstrap 过程:

    $ ./openshift-install --dir <installation_directory> wait-for bootstrap-complete \ 
    1
    
        --log-level=info 
    2
    Copy to Clipboard Toggle word wrap
    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.32.3 up
    INFO Waiting up to 30m0s for bootstrapping to complete...
    INFO It is now safe to remove the bootstrap resources
    Copy to Clipboard Toggle word wrap

    当 Kubernetes API 服务器提示已在 control plane 机器上引导它时,该命令会成功。

  2. bootstrap 过程完成后,从负载均衡器中删除 bootstrap 机器。

    重要

    此时您必须从负载均衡器中删除 bootstrap 机器。您还可以删除或重新格式化 bootstrap 机器本身。

2.2.18. 使用 CLI 登录集群

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

先决条件

  • 已部署 OpenShift Container Platform 集群。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 运行以下命令来导出 kubeadmin 凭证:

    $ export KUBECONFIG=<installation_directory>/auth/kubeconfig 
    1
    Copy to Clipboard Toggle word wrap
    1
    对于 <installation_directory>,请指定安装文件保存到的目录的路径。
  2. 运行以下命令,使用导出的配置成功运行 oc 命令:

    $ oc whoami
    Copy to Clipboard Toggle word wrap

    输出示例

    system:admin
    Copy to Clipboard Toggle word wrap

2.2.19. 批准机器的证书签名请求

当您将机器添加到集群时,会为您添加的每台机器生成两个待处理证书签名请求(CSR)。您必须确认这些 CSR 已获得批准,或根据需要自行批准。必须首先批准客户端请求,然后批准服务器请求。

先决条件

  • 您已将机器添加到集群中。

流程

  1. 确认集群可以识别这些机器:

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME      STATUS    ROLES   AGE  VERSION
    master-0  Ready     master  63m  v1.32.3
    master-1  Ready     master  63m  v1.32.3
    master-2  Ready     master  64m  v1.32.3
    Copy to Clipboard Toggle word wrap

    输出中列出了您创建的所有机器。

    注意

    在有些 CSR 被批准前,前面的输出可能不包括计算节点(也称为 worker 节点)。

  2. 检查待处理的 CSR,并确保添加到集群中的每台机器都有 PendingApproved 状态的客户端请求:

    $ oc get csr
    Copy to Clipboard Toggle word wrap

    输出示例

    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
    ...
    Copy to Clipboard Toggle word wrap

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

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

    注意

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

    注意

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

    • 要单独批准,请对每个有效的 CSR 运行以下命令:

      $ oc adm certificate approve <csr_name> 
      1
      Copy to Clipboard Toggle word wrap
      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
      Copy to Clipboard Toggle word wrap
      注意

      在有些 CSR 被批准前,一些 Operator 可能无法使用。

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

    $ oc get csr
    Copy to Clipboard Toggle word wrap

    输出示例

    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
    ...
    Copy to Clipboard Toggle word wrap

  5. 如果剩余的 CSR 没有被批准,且处于 Pending 状态,请批准集群机器的 CSR:

    • 要单独批准,请对每个有效的 CSR 运行以下命令:

      $ oc adm certificate approve <csr_name> 
      1
      Copy to Clipboard Toggle word wrap
      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
      Copy to Clipboard Toggle word wrap
  6. 批准所有客户端和服务器 CSR 后,机器将 处于 Ready 状态。运行以下命令验证:

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME      STATUS    ROLES   AGE  VERSION
    master-0  Ready     master  73m  v1.32.3
    master-1  Ready     master  73m  v1.32.3
    master-2  Ready     master  74m  v1.32.3
    worker-0  Ready     worker  11m  v1.32.3
    worker-1  Ready     worker  11m  v1.32.3
    Copy to Clipboard Toggle word wrap

    注意

    批准服务器 CSR 后可能需要几分钟时间让机器过渡到 Ready 状态

其他信息

2.2.20. 初始 Operator 配置

在 control plane 初始化后,您必须立即配置一些 Operator,以便它们都可用。

先决条件

  • 您的 control plane 已初始化。

流程

  1. 观察集群组件上线:

    $ watch -n5 oc get clusteroperators
    Copy to Clipboard Toggle word wrap

    输出示例

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

  2. 配置不可用的 Operator。
2.2.20.1. 安装过程中删除的镜像 registry

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

安装后,您必须编辑 Image Registry Operator 配置,将 managementStateRemoved 切换到 Managed。完成此操作后,您必须配置存储。

2.2.20.2. 镜像 registry 存储配置

对于不提供默认存储的平台,Image Registry Operator 最初不可用。安装后,您必须将 registry 配置为使用存储,以便 Registry Operator 可用。

显示配置生产集群所需的持久性卷的说明。如果适用,显示有关将空目录配置为存储位置的说明,这仅适用于非生产集群。

提供了在升级过程中使用 Recreate rollout 策略来允许镜像 registry 使用块存储类型的说明。

2.2.20.3. 为裸机配置块 registry 存储

要允许镜像 registry 在作为集群管理员升级过程中使用块存储类型,您可以使用 Recreate rollout 策略

重要

支持块存储卷或块持久性卷,但不建议在生产环境中使用镜像 registry。在块存储上配置 registry 的安装不具有高可用性,因为 registry 无法具有多个副本。

如果您选择将块存储卷与镜像 registry 搭配使用,则必须使用文件系统持久性卷声明(PVC)。

流程

  1. 输入以下命令将镜像 registry 存储设置为块存储类型,对 registry 进行补丁,使其使用 Recreate rollout 策略,并只使用一个副本运行:1

    $ oc patch config.imageregistry.operator.openshift.io/cluster --type=merge -p '{"spec":{"rolloutStrategy":"Recreate","replicas":1}}'
    Copy to Clipboard Toggle word wrap
  2. 为块存储设备置备 PV,并为该卷创建 PVC。请求的块卷使用 ReadWriteOnce(RWO)访问模式。

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

      kind: PersistentVolumeClaim
      apiVersion: v1
      metadata:
        name: image-registry-storage 
      1
      
        namespace: openshift-image-registry 
      2
      
      spec:
        accessModes:
        - ReadWriteOnce 
      3
      
        resources:
          requests:
            storage: 100Gi 
      4
      Copy to Clipboard Toggle word wrap
      1
      代表 PersistentVolumeClaim 对象的唯一名称。
      2
      PersistentVolumeClaim 对象的命名空间,即 openshift-image-registry
      3
      持久性卷声明的访问模式。使用 ReadWriteOnce 时,单个节点可以通过读写权限挂载该卷。
      4
      持久性卷声明的大小。
    2. 输入以下命令从文件创建 PersistentVolumeClaim 对象:

      $ oc create -f pvc.yaml -n openshift-image-registry
      Copy to Clipboard Toggle word wrap
  3. 输入以下命令编辑 registry 配置,使其引用正确的 PVC:

    $ oc edit config.imageregistry.operator.openshift.io -o yaml
    Copy to Clipboard Toggle word wrap

    输出示例

    storage:
      pvc:
        claim: 
    1
    Copy to Clipboard Toggle word wrap

    1
    通过创建自定义 PVC,您可以将 claim 字段留空,以便默认自动创建 image-registry-storage PVC。

2.2.21. 在用户置备的基础架构上完成安装

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

先决条件

  • 您的 control plane 已初始化。
  • 已完成初始 Operator 配置。

流程

  1. 使用以下命令确认所有集群组件都在线:

    $ watch -n5 oc get clusteroperators
    Copy to Clipboard Toggle word wrap

    输出示例

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

    另外,当所有集群都可用时,以下命令会通知您。它还检索并显示凭证:

    $ ./openshift-install --dir <installation_directory> wait-for install-complete 
    1
    Copy to Clipboard Toggle word wrap
    1
    对于 <installation_directory>,请指定安装文件保存到的目录的路径。

    输出示例

    INFO Waiting up to 30m0s for the cluster to initialize...
    Copy to Clipboard Toggle word wrap

    Cluster Version Operator 完成从 Kubernetes API 服务器部署 OpenShift Container Platform 集群时,该命令会成功。

    重要
    • 安装程序生成的 Ignition 配置文件包含 24 小时后过期的证书,然后在该时进行续订。如果在更新证书前关闭集群,且集群在 24 小时后重启,集群会自动恢复过期的证书。一个例外是,您必须手动批准待处理的 node-bootstrapper 证书签名请求(CSR)来恢复 kubelet 证书。如需更多信息,请参阅从过期的 control plane 证书 中恢复的文档。
    • 建议您在 Ignition 配置文件生成后的 12 小时内使用它们,因为 24 小时的证书会在集群安装后的 16 小时到 22 小时间进行轮转。通过在 12 小时内使用 Ignition 配置文件,您可以避免在安装过程中因为执行了证书更新而导致安装失败的问题。
  2. 确认 Kubernetes API 服务器正在与 pod 通信。

    1. 要查看所有 pod 的列表,请使用以下命令:

      $ oc get pods --all-namespaces
      Copy to Clipboard Toggle word wrap

      输出示例

      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
      ...
      Copy to Clipboard Toggle word wrap

    2. 使用以下命令,查看上一命令的输出中所列 pod 的日志:

      $ oc logs <pod_name> -n <namespace> 
      1
      Copy to Clipboard Toggle word wrap
      1
      指定 pod 名称和命名空间,如上一命令的输出中所示。

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

  3. 对于使用光纤通道协议(FCP)的安装,还需要额外的步骤才能启用多路径。不要在安装过程中启用多路径。

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

2.2.22. OpenShift Container Platform 的 Telemetry 访问

在 OpenShift Container Platform 4.19 中,默认运行的 Telemetry 服务提供有关集群健康状况和成功更新的指标,需要访问互联网。如果您的集群连接到互联网,Telemetry 会自动运行,而且集群会注册到 OpenShift Cluster Manager

确认 OpenShift Cluster Manager 清单正确后,可以由 Telemetry 自动维护,也可以使用 OpenShift Cluster Manager 手动维护,使用订阅监控来跟踪帐户或多集群级别的 OpenShift Container Platform 订阅。

2.2.23. 后续步骤

在 OpenShift Container Platform 4.19 中,您可以在受限网络中置备的裸机基础架构上安装集群。

重要

虽然您可能能够按照以下步骤在虚拟化或云环境中部署集群,但您必须了解非裸机平台的其他注意事项。在尝试在此类环境中安装 OpenShift Container Platform 集群前,请参阅有关在未经测试的平台上部署 OpenShift Container Platform 的指南 中的信息。

2.3.1. 先决条件

2.3.2. 关于在受限网络中安装

在 OpenShift Container Platform 4.19 中,可以执行不需要有效的互联网连接来获取软件组件的安装。受限网络安装可以使用安装程序置备的基础架构或用户置备的基础架构完成,具体取决于您要安装集群的云平台。

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

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

重要

由于用户置备安装配置的复杂性,在尝试使用用户置备的基础架构受限网络安装前,请考虑完成标准用户置备的基础架构安装。完成此测试安装后,您可以更轻松地隔离和排除在受限网络中安装过程中可能出现的任何问题。

2.3.2.1. 其他限制

受限网络中的集群有以下额外限制和限制:

  • ClusterVersion 状态包含一个 Unable to retrieve available updates 错误。
  • 默认情况下,您无法使用 Developer Catalog 的内容,因为您无法访问所需的镜像流标签。

2.3.3. OpenShift Container Platform 互联网访问

在 OpenShift Container Platform 4.19 中,您需要访问互联网来获得用来安装集群的镜像。

您需要连接到互联网才能执行以下操作:

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

2.3.4. 具有用户置备基础架构的集群的要求

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

本节论述了在用户置备的基础架构上部署 OpenShift Container Platform 的要求。

2.3.4.1. 集群安装所需的机器

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

Expand
表 2.31. 最低所需的主机
主机描述

一个临时 bootstrap 机器

集群需要 bootstrap 机器在三台 control plane 机器上部署 OpenShift Container Platform 集群。您可在安装集群后删除 bootstrap 机器。

三台 control plane 机器

control plane 机器运行组成 control plane 的 Kubernetes 和 OpenShift Container Platform 服务。

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

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

注意

作为例外,您可以在裸机集群中运行零台计算机器,它们仅由三台 control plane 机器组成。这为集群管理员和开发人员提供了更小、效率更高的集群,用于测试、开发和生产。不支持运行一台计算机器。

重要

要保持集群的高可用性,请将独立的物理主机用于这些集群机器。

bootstrap 和 control plane 机器必须使用 Red Hat Enterprise Linux CoreOS(RHCOS)作为操作系统。但是,计算机器可以在 Red Hat Enterprise Linux CoreOS(RHCOS)、Red Hat Enterprise Linux(RHEL) 8.6 和更高的版本。

请注意,RHCOS 基于 Red Hat Enterprise Linux(RHEL) 9.2,并继承其所有硬件认证和要求。查看 红帽企业 Linux 技术功能和限制

2.3.4.2. 集群安装的最低资源要求

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

Expand
表 2.32. 最低资源要求
机器操作系统CPU [1]RAMStorage每秒输入/输出 (IOPS) [2]

bootstrap

RHCOS

4

16 GB

100 GB

300

Control plane(控制平面)

RHCOS

4

16 GB

100 GB

300

Compute

RHCOS、RHEL 8.6 及更新版本 [3]

2

8 GB

100 GB

300

  1. 当未启用并发多线程 (SMT) 或超线程时,一个 CPU 相当于一个物理内核。启用后,使用以下公式来计算对应的比例:(每个内核数的线程)× sockets = CPU。
  2. OpenShift Container Platform 和 Kubernetes 对磁盘性能非常敏感,建议使用更快的存储速度,特别是 control plane 节点上需要 10 ms p99 fsync 持续时间的 etcd。请注意,在许多云平台上,存储大小和 IOPS 可一起扩展,因此您可能需要过度分配存储卷来获取足够的性能。
  3. 与所有用户置备的安装一样,如果您选择在集群中使用 RHEL 计算机器,则负责所有操作系统生命周期管理和维护,包括执行系统更新、应用补丁和完成所有其他必要的任务。RHEL 7 计算机器的使用已弃用,并已在 OpenShift Container Platform 4.10 及更新的版本中删除。
注意

对于 OpenShift Container Platform 版本 4.19,RHCOS 基于 RHEL 版本 9.6,它会更新微架构要求。以下列表包含每个架构需要的最小指令集架构 (ISA):

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

如需更多信息,请参阅 架构 (RHEL 文档)。

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

2.3.4.3. 证书签名请求管理

在使用您置备的基础架构时,集群只能有限地访问自动机器管理,因此您必须提供一种在安装后批准集群证书签名请求 (CSR) 的机制。kube-controller-manager 只能批准 kubelet 客户端 CSR。machine-approver 无法保证使用 kubelet 凭证请求的提供证书的有效性,因为它不能确认是正确的机器发出了该请求。您必须决定并实施一种方法,以验证 kubelet 提供证书请求的有效性并进行批准。

2.3.4.4. 用户置备的基础架构对网络的要求

所有 Red Hat Enterprise Linux CoreOS(RHCOS)机器都需要在启动时在 initramfs 中配置联网,以获取它们的 Ignition 配置文件。

在初次启动过程中,机器需要 IP 地址配置,该配置通过 DHCP 服务器或静态设置,提供所需的引导选项。建立网络连接后,机器会从 HTTP 或 HTTPS 服务器下载 Ignition 配置文件。然后,Ignition 配置文件用于设置每台机器的确切状态。Machine Config Operator 在安装后完成对机器的更多更改,如应用新证书或密钥。

注意
  • 建议使用 DHCP 服务器对集群机器进行长期管理。确保 DHCP 服务器已配置为向集群机器提供持久的 IP 地址、DNS 服务器信息和主机名。
  • 如果用户置备的基础架构没有 DHCP 服务,您可以在 RHCOS 安装时向节点提供 IP 网络配置和 DNS 服务器地址。如果要从 ISO 镜像安装,这些参数可作为引导参数传递。如需有关静态 IP 置备和高级网络选项的更多信息,请参阅 安装 RHCOS 并启动 OpenShift Container Platform bootstrap 过程 部分。

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

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

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

另外,通过 DHCP 设置主机名可以绕过实施 DNS split-horizon 的环境中的手动 DNS 记录名称配置错误。

2.3.4.4.2. 网络连接要求

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

本节详细介绍了所需的端口。

Expand
表 2.33. 用于全机器到所有机器通信的端口
协议port描述

ICMP

N/A

网络可访问性测试

TCP

1936

指标

9000-9999

主机级别的服务,包括端口 9 100-9101 上的节点导出器,以及端口 9099 上的 Cluster Version Operator。

10250-10259

Kubernetes 保留的默认端口

22623

端口处理来自 Machine Config 服务器的流量,并将流量定向到 control plane 机器。

UDP

4789

VXLAN

6081

Geneve

9000-9999

主机级别的服务,包括端口 91009101 上的节点导出器。

500

IPsec IKE 数据包

4500

IPsec NAT-T 数据包

123

UDP 端口 123 上的网络时间协议 (NTP)如果配置了外部 NTP 时间服务器,需要打开 UDP 端口 123

TCP/UDP

30000-32767

Kubernetes 节点端口

ESP

N/A

IPsec Encapsulating Security Payload(ESP)

Expand
表 2.34. 用于所有机器控制平面通信的端口
协议port描述

TCP

6443

Kubernetes API

Expand
表 2.35. control plane 机器用于 control plane 机器通信的端口
协议port描述

TCP

2379-2380

etcd 服务器和对等端口

2.3.4.4.3. 用户置备的基础架构的 NTP 配置

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

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

2.3.4.5. 用户置备的 DNS 要求

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

  • The Kubernetes API
  • OpenShift Container Platform 应用程序通配符
  • bootstrap、control plane 和计算机器

Kubernetes API、bootstrap 机器、control plane 机器和计算机器也需要反向 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>.

Expand
表 2.36. 所需的 DNS 记录
组件记录描述

Kubernetes API

api.<cluster_name>.<base_domain>.

DNS A/AAAA 或 CNAME 记录,以及用于标识 API 负载均衡器的 DNS PTR 记录。这些记录必须由集群外的客户端和集群中的所有节点解析。

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

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

重要

API 服务器必须能够根据 Kubernetes 中记录的主机名解析 worker 节点。如果 API 服务器无法解析节点名称,则代理的 API 调用会失败,且您无法从 pod 检索日志。

Routes

*.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 机器

bootstrap.<cluster_name>.<base_domain>.

DNS A/AAAA 或 CNAME 记录,以及用于标识 bootstrap 机器的 DNS PTR 记录。这些记录必须由集群中的节点解析。

control plane 机器

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

DNS A/AAAA 或 CNAME 记录,以识别 control plane 节点的每台机器。这些记录必须由集群中的节点解析。

计算机器

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

DNS A/AAAA 或 CNAME 记录,用于识别 worker 节点的每台机器。这些记录必须由集群中的节点解析。

注意

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

提示

您可以使用 dig 命令验证名称和反向名称解析。如需了解详细的 验证步骤,请参阅为用户置备的基础架构验证 DNS 解析 一节。

2.3.4.5.1. 用户置备的集群的 DNS 配置示例

本节提供 A 和 PTR 记录配置示例,它们满足了在用户置备的基础架构上部署 OpenShift Container Platform 的 DNS 要求。样本不是为选择一个 DNS 解决方案提供建议。

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

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

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

例 2.7. 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 
6

control-plane2.ocp4.example.com.	IN	A	192.168.1.99 
7

;
compute0.ocp4.example.com.	IN	A	192.168.1.11 
8

compute1.ocp4.example.com.	IN	A	192.168.1.7 
9

;
;EOF
Copy to Clipboard Toggle word wrap
1
为 Kubernetes API 提供名称解析。记录引用 API 负载均衡器的 IP 地址。
2
为 Kubernetes API 提供名称解析。记录引用 API 负载均衡器的 IP 地址,用于内部集群通信。
3
为通配符路由提供名称解析。记录引用应用程序入口负载均衡器的 IP 地址。应用程序入口负载均衡器以运行 Ingress Controller Pod 的机器为目标。默认情况下,Ingress Controller Pod 在计算机器上运行。
注意

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

4
为 bootstrap 机器提供名称解析。
5 6 7
为 control plane 机器提供名称解析。
8 9
为计算机器提供名称解析。

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

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

例 2.8. 反向记录的 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. 
5

99.1.168.192.in-addr.arpa.	IN	PTR	control-plane2.ocp4.example.com. 
6

;
11.1.168.192.in-addr.arpa.	IN	PTR	compute0.ocp4.example.com. 
7

7.1.168.192.in-addr.arpa.	IN	PTR	compute1.ocp4.example.com. 
8

;
;EOF
Copy to Clipboard Toggle word wrap
1
为 Kubernetes API 提供反向 DNS 解析。PTR 记录引用 API 负载均衡器的记录名称。
2
为 Kubernetes API 提供反向 DNS 解析。PTR 记录引用 API 负载均衡器的记录名称,用于内部集群通信。
3
为 bootstrap 机器提供反向 DNS 解析。
4 5 6
为 control plane 机器提供反向 DNS 解析。
7 8
为计算机器提供反向 DNS 解析。
注意

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

2.3.4.6. 用户置备的基础架构的负载均衡要求

在安装 OpenShift Container Platform 前,您必须置备 API 和应用程序入口负载均衡基础架构。在生产环境中,您可以单独部署 API 和应用程序入口负载均衡器,以便可以隔离扩展每个负载均衡器基础架构。

注意

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

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

  1. API 负载均衡器 :提供一个通用端点,供用户(包括人工和机器)与平台交互和配置。配置以下条件:

    • 仅第 4 层负载均衡.这可被称为 Raw TCP 或 SSL Passthrough 模式。
    • 无状态负载平衡算法。这些选项根据负载均衡器的实施而有所不同。
    重要

    不要为 API 负载均衡器配置会话持久性。为 Kubernetes API 服务器配置会话持久性可能会导致出现过量 OpenShift Container Platform 集群应用程序流量,以及过量的在集群中运行的 Kubernetes API。

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

    Expand
    表 2.37. API 负载均衡器
    port后端机器(池成员)internal外部描述

    6443

    Bootstrap 和 control plane.bootstrap 机器初始化集群 control plane 后,您要从负载均衡器中删除 bootstrap 机器。您必须为 API 服务器健康检查探测配置 /readyz 端点。

    X

    X

    Kubernetes API 服务器

    22623

    Bootstrap 和 control plane.bootstrap 机器初始化集群 control plane 后,您要从负载均衡器中删除 bootstrap 机器。

    X

     

    机器配置服务器

    注意

    负载均衡器必须配置为,从 API 服务器关闭 /readyz 端点到从池中移除 API 服务器实例时最多需要 30 秒。在 /readyz 返回错误或健康后的时间范围内,端点必须被删除或添加。每 5 秒或 10 秒探测一次,有两个成功请求处于健康状态,三个成为不健康的请求是经过良好测试的值。

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

    配置以下条件:

    • 仅第 4 层负载均衡.这可被称为 Raw TCP 或 SSL Passthrough 模式。
    • 建议根据可用选项以及平台上托管的应用程序类型,使用基于连接的或基于会话的持久性。
    提示

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

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

    Expand
    表 2.38. 应用程序入口负载均衡器
    port后端机器(池成员)internal外部描述

    443

    默认情况下,运行 Ingress Controller Pod、计算或 worker 的机器。

    X

    X

    HTTPS 流量

    80

    默认情况下,运行 Ingress Controller Pod、计算或 worker 的机器。

    X

    X

    HTTP 流量

    注意

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

本节提供了一个满足用户置备集群的负载均衡要求的 API 和应用程序入口负载均衡器配置示例。示例是 HAProxy 负载均衡器的 /etc/haproxy/haproxy.cfg 配置。这个示例不是为选择一个负载平衡解决方案提供建议。

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

注意

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

例 2.9. 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 
4

  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 
5

  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 
6

  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
Copy to Clipboard Toggle word wrap
1
端口 6443 处理 Kubernetes API 流量并指向 control plane 机器。
2 4
bootstrap 条目必须在 OpenShift Container Platform 集群安装前就位,且必须在 bootstrap 过程完成后删除它们。
3
端口 22623 处理机器配置服务器流量并指向 control plane 机器。
5
端口 443 处理 HTTPS 流量,并指向运行 Ingress Controller pod 的机器。默认情况下,Ingress Controller Pod 在计算机器上运行。
6
端口 80 处理 HTTP 流量,并指向运行 Ingress Controller pod 的机器。默认情况下,Ingress Controller Pod 在计算机器上运行。
注意

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

提示

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

除了使用 configure-ovs.sh shell 脚本在裸机平台上设置 br-ex 网桥的替代选择,您可以创建一个包括 NMState 配置文件的 MachineConfig 对象。主机 nmstate-configuration.servicenmstate.service 将 NMState 配置文件应用到集群中运行的每个节点。

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

  • 您需要对网桥进行安装后更改,如更改 Open vSwitch (OVS) 或 OVN-Kubernetes br-ex 网桥网络。configure-ovs.sh shell 脚本不支持对网桥进行安装后更改。
  • 您希望将网桥部署到与主机或服务器 IP 地址上可用的接口不同的接口上。
  • 您希望通过 configure-ovs.sh shell 脚本对网桥进行高级配置。对这些配置使用脚本可能会导致网桥无法连接多个网络接口,并无法正确处理接口之间的数据转发。
注意

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

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

警告

以下接口名称列表被保留,您不能使用带有 NMstate 配置的名称:

  • br-ext
  • br-int
  • br-local
  • br-nexthop
  • br0
  • ext-vxlan
  • ext
  • genev_sys_*
  • int
  • k8s-*
  • ovn-k8s-*
  • patch-br-*
  • tun0
  • vxlan_sys_*

先决条件

  • 可选: 已安装 nmstate API,以便您可以验证 NMState 配置。

流程

  1. 为您的自定义 br-ex 网桥网络创建一个使用 base64 信息的 NMState 配置文件:

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

    interfaces:
    - name: enp2s0 
    1
    
      type: ethernet 
    2
    
      state: up 
    3
    
      ipv4:
        enabled: false 
    4
    
      ipv6:
        enabled: false
    - name: br-ex
      type: ovs-bridge
      state: up
      ipv4:
        enabled: false
        dhcp: false
      ipv6:
        enabled: false
        dhcp: false
      bridge:
        options:
          mcast-snooping-enable: true
        port:
        - name: enp2s0 
    5
    
        - name: br-ex
    - name: br-ex
      type: ovs-interface
      state: up
      copy-mac-from: enp2s0
      ipv4:
        enabled: true
        dhcp: true
        auto-route-metric: 48 
    6
    
      ipv6:
        enabled: true
        dhcp: true
        auto-route-metric: 48
    # ...
    Copy to Clipboard Toggle word wrap

    1
    接口的名称。
    2
    以太网的类型。
    3
    创建后接口的请求状态。
    4
    在这个示例中禁用 IPv4 和 IPv6。
    5
    网桥附加到的节点 NIC。
    6
    将参数设置为 48,以确保 br-ex 默认路由始终具有最高的优先级(最低指标)。此配置可防止与 NetworkManager 服务自动配置的任何其他接口冲突。
  2. 使用 cat 命令对 NMState 配置的内容进行 base64 编码:

    $ cat <nmstate_configuration>.yaml | base64 
    1
    Copy to Clipboard Toggle word wrap
    1
    <nmstate_configuration> 替换为 NMState 资源 YAML 文件的名称。
  3. 创建 MachineConfig 清单文件,并定义一个自定义 br-ex 网桥网络配置,如下例所示:

    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: worker
      name: 10-br-ex-worker 
    1
    
    spec:
      config:
        ignition:
          version: 3.2.0
        storage:
          files:
          - contents:
              source: data:text/plain;charset=utf-8;base64,<base64_encoded_nmstate_configuration> 
    2
    
            mode: 0644
            overwrite: true
            path: /etc/nmstate/openshift/worker-0.yml 
    3
    
          - contents:
              source: data:text/plain;charset=utf-8;base64,<base64_encoded_nmstate_configuration>
            mode: 0644
            overwrite: true
            path: /etc/nmstate/openshift/worker-1.yml 
    4
    
    # ...
    Copy to Clipboard Toggle word wrap
    1
    策略的名称。
    2
    将编码的 base64 信息写入指定路径。
    3 4
    对于集群中的每个节点,指定节点的主机名路径以及机器类型的 base-64 编码 Ignition 配置文件数据。worker 角色是集群中节点的默认角色。如果为每个节点或 MachineConfig 清单文件中的所有节点设置了短主机名、 hostname -s、路径,.yaml 扩展将无法工作。

    如果您在要应用到集群中的所有节点的 /etc/nmstate/openshift/cluster.yml 配置文件中指定了单个全局配置,则不需要为每个节点指定短主机名路径,如 /etc/nmstate/openshift/<node_hostname>.yml。例如:

    # ...
          - contents:
              source: data:text/plain;charset=utf-8;base64,<base64_encoded_nmstate_configuration>
            mode: 0644
            overwrite: true
            path: /etc/nmstate/openshift/cluster.yml
    # ...
    Copy to Clipboard Toggle word wrap

后续步骤

  • 扩展计算节点,以将包含自定义 br-ex 网桥的 manifest 对象应用到集群中存在的每个计算节点。如需更多信息,请参阅附加资源部分中的"扩展集群"。
2.3.5.1. 将每个机器集扩展到计算节点

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

配置这些资源后,您必须扩展机器集,以便机器集可以将资源配置应用到每个计算节点并重新引导节点。

先决条件

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

流程

  1. 输入以下命令编辑 MachineConfig CR:

    $ oc edit mc <machineconfig_custom_resource_name>
    Copy to Clipboard Toggle word wrap
  2. 将每个计算节点配置添加到 CR,以便 CR 可以管理集群中每个定义的计算节点的角色。
  3. 创建名为 extraworker-secretSecret 对象,该对象具有最小的静态 IP 配置。
  4. 输入以下命令将 extraworker-secret secret 应用到集群中的每个节点。此步骤提供每个计算节点对 Ignition 配置文件的访问权限。

    $ oc apply -f ./extraworker-secret.yaml
    Copy to Clipboard Toggle word wrap
  5. 创建 BareMetalHost 资源并在 preprovisioningNetworkDataName 参数中指定网络 secret:

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

    apiVersion: metal3.io/v1alpha1
    kind: BareMetalHost
    spec:
    # ...
      preprovisioningNetworkDataName: ostest-extraworker-0-network-config-secret
    # ...
    Copy to Clipboard Toggle word wrap

  6. 要在集群的 openshift-machine-api 命名空间中管理 BareMetalHost 对象,请输入以下命令来更改命名空间:

    $ oc project openshift-machine-api
    Copy to Clipboard Toggle word wrap
  7. 获取机器集:

    $ oc get machinesets
    Copy to Clipboard Toggle word wrap
  8. 输入以下命令扩展每个机器集。您必须为每个机器集运行这个命令。

    $ oc scale machineset <machineset_name> --replicas=<n> 
    1
    Copy to Clipboard Toggle word wrap
    1
    其中 <machineset_name> 是机器集的名称,<n> 是计算节点的数量。

2.3.6. 为集群启用 OVS balance-slb 模式

您可以启用 Open vSwitch (OVS) balance-slb 模式,以便两个或多个物理接口共享其网络流量。balance-slb 模式接口可以为运行虚拟化工作负载的集群提供源负载均衡(SLB)功能,而无需与网络交换机协商。

目前,源负载均衡在绑定接口上运行,该接口连接到辅助网桥,如 br-phy。源负载均衡仅在不同的 Media Access Control (MAC)地址和虚拟局域网(VLAN)组合之间平衡。请注意,所有 OVN-Kubernetes pod 流量都使用相同的 MAC 地址和 VLAN,因此此流量无法在多个物理接口负载平衡。

下图显示了简单集群基础架构布局上的 balance-slb 模式。虚拟机(VM)连接到特定的 localnet NetworkAttachmentDefinition (NAD)自定义资源定义(CRD)、NAD 0NAD 1。每个 NAD 均为虚拟机提供对底层物理网络的访问,支持 VLAN 标记或未标记的流量。br-ex OVS 网桥从虚拟机接收流量,并将流量传递到下一个 OVS 网桥 br-phybr-phy 网桥作为 SLB 绑定的控制器。SLB 绑定通过物理接口链接(如 eno0eno1)平衡来自不同虚拟机端口的流量。此外,来自一个物理接口的入口流量可以通过一组 OVS 网桥来访问虚拟机。

图 2.3. OVS balance-slb 模式在带有两个 NAD 的 localnet 上运行

您可以使用 OVS 绑定将 balance-slb 模式接口集成到主或二级网络类型中。注意关于 OVS 绑定的以下点:

  • 支持 OVN-Kubernetes CNI 插件,并轻松与插件集成。
  • 原生支持 balance-slb 模式。

先决条件

  • 将多个物理接口附加到主网络,并在 MachineConfig 文件中定义接口。
  • 您创建了清单对象,并在对象配置文件中定义了自定义 br-ex 网桥。
  • 您附加了多个物理接口,并在 NAD CRD 文件中定义接口。

流程

  1. 对于集群中的每个裸机主机,在 install-config.yaml 文件中为集群定义一个 networkConfig 部分,如下例所示:

    # ...
    networkConfig:
      interfaces:
        - name: enp1s0 
    1
    
          type: ethernet
          state: up
          ipv4:
            dhcp: true
            enabled: true
          ipv6:
            enabled: false
        - name: enp2s0 
    2
    
          type: ethernet
          state: up
          mtu: 1500 
    3
    
          ipv4:
            dhcp: true
            enabled: true
          ipv6:
            dhcp: true
            enabled: true
        - name: enp3s0 
    4
    
          type: ethernet
          state: up
          mtu: 1500
          ipv4:
            enabled: false
          ipv6:
            enabled: false
    # ...
    Copy to Clipboard Toggle word wrap
    1
    置备的网络接口控制器(NIC)的接口。
    2
    在绑定接口的 Ignition 配置文件中拉取的第一个绑定接口。
    3
    在绑定端口上手动设置 br-ex 最大传输单元(MTU)。
    4
    第二个绑定接口是在集群安装过程中拉取 ignition 的最小配置的一部分。
  2. 在 NMState 配置文件中定义每个网络接口:

    定义许多网络接口的 NMState 配置文件示例

    ovn:
      bridge-mappings:
        - localnet: localnet-network
          bridge: br-ex
          state: present
    interfaces:
      - name: br-ex
        type: ovs-bridge
        state: up
        bridge:
          allow-extra-patch-ports: true
          port:
            - name: br-ex
            - name: patch-ex-to-phy
        ovs-db:
          external_ids:
            bridge-uplink: "patch-ex-to-phy"
      - name: br-ex
        type: ovs-interface
        state: up
        mtu: 1500 
    1
    
        ipv4:
          enabled: true
          dhcp: true
          auto-route-metric: 48
        ipv6:
          enabled: false
          dhcp: false
          auto-route-metric: 48
      - name: br-phy
        type: ovs-bridge
        state: up
        bridge:
          allow-extra-patch-ports: true
          port:
            - name: patch-phy-to-ex
            - name: ovs-bond
              link-aggregation:
                mode: balance-slb
                port:
                  - name: enp2s0
                  - name: enp3s0
      - name: patch-ex-to-phy
        type: ovs-interface
        state: up
        patch:
          peer: patch-phy-to-ex
      - name: patch-phy-to-ex
        type: ovs-interface
        state: up
        patch:
          peer: patch-ex-to-phy
      - name: enp1s0
        type: ethernet
        state: up
        ipv4:
          dhcp: true
          enabled: true
        ipv6:
          enabled: false
      - name: enp2s0
        type: ethernet
        state: up
        mtu: 1500
        ipv4:
          enabled: false
        ipv6:
          enabled: false
      - name: enp3s0
        type: ethernet
        state: up
        mtu: 1500
        ipv4:
          enabled: false
        ipv6:
          enabled: false
    # ...
    Copy to Clipboard Toggle word wrap

    1
    在绑定端口上手动设置 br-ex MTU。
  3. 使用 base64 命令对 NMState 配置文件的接口内容进行编码:

    $ base64 -w0  <nmstate_configuration>.yml 
    1
    Copy to Clipboard Toggle word wrap
    1
    其中 -w0 选项可防止在 base64 编码操作中换行。
  4. master 角色和 worker 角色创建 MachineConfig 清单文件。确保将之前命令中的 base64 编码的字符串嵌入到每个 MachineConfig 清单文件中。以下示例清单文件为集群中存在的所有节点配置 master 角色。您还可以为特定于节点的 masterworker 角色创建清单文件。

    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: master
      name: 10-br-ex-master 
    1
    
    spec:
      config:
        ignition:
          version: 3.2.0
        storage:
          files:
          - contents:
              source: data:text/plain;charset=utf-8;base64,<base64_encoded_nmstate_configuration> 
    2
    
            mode: 0644
            overwrite: true
            path: /etc/nmstate/openshift/cluster.yml 
    3
    Copy to Clipboard Toggle word wrap
    1
    策略的名称。
    2
    将编码的 base64 信息写入指定路径。
    3
    指定 cluster.yml 文件的路径。对于集群中的每个节点,您可以指定节点的短主机名路径,如 <node_short_hostname>.yml。
  5. 将每个 MachineConfig 清单文件保存到 ./& lt;installation_directory>/manifests 目录,其中 &lt ;installation_directory > 是安装程序在其中创建文件的目录。

    Machine Config Operator (MCO)从每个清单文件中获取内容,并在滚动更新期间持续将内容应用到所有所选节点。

2.3.7. 准备用户置备的基础架构

在用户置备的基础架构上安装 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 bootstrap 过程 部分。

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

      注意

      如果没有使用 DHCP 服务,集群节点可以通过反向 DNS 查找来获取其主机名。

  2. 确保您的网络基础架构提供集群组件之间所需的网络连接。有关 要求的详情,请参阅用户置备的基础架构 的网络要求部分。
  3. 将防火墙配置为启用 OpenShift Container Platform 集群组件进行通信所需的端口。如需有关所需端口的详细信息,请参阅用户置备的基础架构 部分的网络要求。

    重要

    默认情况下,OpenShift Container Platform 集群可以访问端口 1936,因为每个 control plane 节点都需要访问此端口。

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

  4. 为集群设置所需的 DNS 基础架构。

    1. 为 Kubernetes API、应用程序通配符、bootstrap 机器、control plane 机器和计算机器配置 DNS 名称解析。
    2. 为 Kubernetes API、bootstrap 机器、control plane 机器和计算机器配置反向 DNS 解析。

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

  5. 验证您的 DNS 配置。

    1. 从安装节点,针对 Kubernetes API 的记录名称、通配符路由和集群节点运行 DNS 查找。验证响应中的 IP 地址是否与正确的组件对应。
    2. 从安装节点,针对负载均衡器和集群节点的 IP 地址运行反向 DNS 查找。验证响应中的记录名称是否与正确的组件对应。

      有关详细的 DNS 验证步骤,请参阅用户置备的基础架构 验证 DNS 解析部分。

  6. 置备所需的 API 和应用程序入口负载平衡基础架构。有关 要求的更多信息,请参阅用户置备的基础架构的负载平衡 要求部分。
注意

某些负载平衡解决方案要求在初始化负载平衡之前,对群集节点进行 DNS 名称解析。

2.3.8. 验证用户置备的基础架构的 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
      Copy to Clipboard Toggle word wrap
      1
      <nameserver_ip> 替换为 nameserver 的 IP 地址,<cluster_name> 替换为您的集群名称,<base_domain> 替换为您的基本域名。

      输出示例

      api.ocp4.example.com.		604800	IN	A	192.168.1.5
      Copy to Clipboard Toggle word wrap

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

      $ dig +noall +answer @<nameserver_ip> api-int.<cluster_name>.<base_domain>
      Copy to Clipboard Toggle word wrap

      输出示例

      api-int.ocp4.example.com.		604800	IN	A	192.168.1.5
      Copy to Clipboard Toggle word wrap

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

      $ dig +noall +answer @<nameserver_ip> random.apps.<cluster_name>.<base_domain>
      Copy to Clipboard Toggle word wrap

      输出示例

      random.apps.ocp4.example.com.		604800	IN	A	192.168.1.5
      Copy to Clipboard Toggle word wrap

      注意

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

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

      $ dig +noall +answer @<nameserver_ip> console-openshift-console.apps.<cluster_name>.<base_domain>
      Copy to Clipboard Toggle word wrap

      输出示例

      console-openshift-console.apps.ocp4.example.com. 604800 IN	A 192.168.1.5
      Copy to Clipboard Toggle word wrap

    4. 针对 bootstrap DNS 记录名称运行查询。检查结果是否指向 bootstrap 节点的 IP 地址:

      $ dig +noall +answer @<nameserver_ip> bootstrap.<cluster_name>.<base_domain>
      Copy to Clipboard Toggle word wrap

      输出示例

      bootstrap.ocp4.example.com.		604800	IN	A	192.168.1.96
      Copy to Clipboard Toggle word wrap

    5. 使用此方法对 control plane 和计算节点的 DNS 记录名称执行查找。检查结果是否与每个节点的 IP 地址对应。
  2. 从安装节点,针对负载均衡器和集群节点的 IP 地址运行反向 DNS 查找。验证响应中包含的记录名称是否与正确的组件对应。

    1. 对 API 负载均衡器的 IP 地址执行反向查找。检查响应是否包含 Kubernetes API 和 Kubernetes 内部 API 的记录名称:

      $ dig +noall +answer @<nameserver_ip> -x 192.168.1.5
      Copy to Clipboard Toggle word wrap

      输出示例

      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
      Copy to Clipboard Toggle word wrap

      1
      为 Kubernetes 内部 API 提供记录名称。
      2
      为 Kubernetes API 提供记录名称。
      注意

      OpenShift Container Platform 应用程序通配符不需要 PTR 记录。针对应用程序入口负载均衡器的 IP 地址解析反向 DNS 解析不需要验证步骤。

    2. 对 bootstrap 节点的 IP 地址执行反向查找。检查结果是否指向 bootstrap 节点的 DNS 记录名称:

      $ dig +noall +answer @<nameserver_ip> -x 192.168.1.96
      Copy to Clipboard Toggle word wrap

      输出示例

      96.1.168.192.in-addr.arpa. 604800	IN	PTR	bootstrap.ocp4.example.com.
      Copy to Clipboard Toggle word wrap

    3. 使用此方法对 control plane 和计算节点的 IP 地址执行反向查找。检查结果是否与每个节点的 DNS 记录名称对应。

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

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

将密钥传递给节点后,您可以使用密钥对作为用户 核心 通过 SSH 连接到 RHCOS 节点。若要通过 SSH 访问节点,必须由 SSH 为您的本地用户管理私钥身份。

如果要通过 SSH 连接到集群节点来执行安装调试或灾难恢复,则必须在安装过程中提供 SSH 公钥。./openshift-install gather 命令还需要在集群节点上设置 SSH 公钥。

重要

不要在生产环境中跳过这个过程,在生产环境中需要灾难恢复和调试。

注意

您必须使用本地密钥,而不是使用特定平台方法配置的密钥。

流程

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

    $ ssh-keygen -t ed25519 -N '' -f <path>/<file_name> 
    1
    Copy to Clipboard Toggle word wrap
    1
    指定新 SSH 密钥的路径和文件名,如 ~/.ssh/id_ed25519。如果您已有密钥对,请确保您的公钥位于 ~/.ssh 目录中。
    注意

    如果您计划在 x86_64ppc64les390x 架构上安装使用 RHEL 加密库(这些加密库已提交给 NIST 用于 FIPS 140-2/140-3 验证)的 OpenShift Container Platform 集群,则不要创建使用 ed25519 算法的密钥。相反,创建一个使用 rsaecdsa 算法的密钥。

  2. 查看公共 SSH 密钥:

    $ cat <path>/<file_name>.pub
    Copy to Clipboard Toggle word wrap

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

    $ cat ~/.ssh/id_ed25519.pub
    Copy to Clipboard Toggle word wrap
  3. 将 SSH 私钥身份添加到本地用户的 SSH 代理(如果尚未添加)。在集群节点上,或者要使用 ./openshift-install gather 命令,需要对该密钥进行 SSH 代理管理,才能在集群节点上进行免密码 SSH 身份验证。

    注意

    在某些发行版中,自动管理默认 SSH 私钥身份,如 ~/.ssh/id_rsa~/.ssh/id_dsa

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

      $ eval "$(ssh-agent -s)"
      Copy to Clipboard Toggle word wrap

      输出示例

      Agent pid 31874
      Copy to Clipboard Toggle word wrap

      注意

      如果集群处于 FIPS 模式,则只使用 FIPS 兼容算法来生成 SSH 密钥。密钥必须是 RSA 或 ECDSA。

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

    $ ssh-add <path>/<file_name> 
    1
    Copy to Clipboard Toggle word wrap
    1
    指定 SSH 私钥的路径和文件名,如 ~/.ssh/id_ed25519.pub

    输出示例

    Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
    Copy to Clipboard Toggle word wrap

后续步骤

  • 安装 OpenShift Container Platform 时,为安装程序提供 SSH 公钥。如果在您置备的基础架构上安装集群,则必须为安装程序提供密钥。

2.3.10. 手动创建安装配置文件

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

先决条件

  • 在本地机器上有一个 SSH 公钥用于安装程序。您可以使用密钥在集群节点上进行 SSH 身份验证,以进行调试和灾难恢复。
  • 已获取 OpenShift Container Platform 安装程序和集群的 pull secret。
  • 获取命令输出中的 imageContentSources 部分来 镜像存储库。
  • 获取您的镜像 registry 的证书内容。

流程

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

    $ mkdir <installation_directory>
    Copy to Clipboard Toggle word wrap
    重要

    您必须创建一个目录。有些安装资产,如 bootstrap X.509 证书的过期间隔较短,因此不得重复使用安装目录。如果要重复使用另一个集群安装中的单个文件,您可以将它们复制到您的目录中。但是,安装资产的文件名可能会在发行版本间有所变化。从以前的 OpenShift Container Platform 版本中复制安装文件时请小心。

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

    注意

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

    • 除非使用 RHCOS 默认信任的 registry,如 docker.io,否则必须在 additionalTrustBundle 部分中提供镜像存储库的证书内容。在大多数情况下,您必须为您的镜像提供证书。
    • 您必须包含命令输出 中的 imageContentSources 部分才能 镜像存储库。
    重要
    • 在镜像过程完成后,ImageContentSourcePolicy 文件作为 oc mirror 的输出生成。
    • oc mirror 命令会生成 ImageContentSourcePolicy 文件,其中包含定义 ImageContentSourcePolicy 所需的 YAML。复制此文件中的文本并将其粘贴到 install-config.yaml 文件中。
    • 您必须运行 'oc mirror' 命令两次。第一次运行 oc mirror 命令时,您将获得完整的 ImageContentSourcePolicy 文件。第二次运行 oc mirror 命令时,您只获得第一次运行和第二次运行之间的差别。由于此行为,您必须始终保留这些文件的备份,以防需要将这些文件合并到一个完整的 ImageContentSourcePolicy 文件中。备份这两个输出文件可确保您有完整的 ImageContentSourcePolicy 文件。
  3. 备份 install-config.yaml 文件,以便使用它来安装多个集群。

    重要

    现在备份 install-config.yaml 文件,因为安装过程会在下一步中消耗该文件。

2.3.10.1. 裸机 install-config.yaml 文件示例

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

apiVersion: v1
baseDomain: example.com 
1

compute: 
2

- hyperthreading: Enabled 
3

  name: worker
  replicas: 0 
4

controlPlane: 
5

  hyperthreading: Enabled 
6

  name: master
  replicas: 3 
7

metadata:
  name: test 
8

networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14 
9

    hostPrefix: 23 
10

  networkType: OVNKubernetes 
11

  serviceNetwork: 
12

  - 172.30.0.0/16
platform:
  none: {} 
13

fips: false 
14

pullSecret: '{"auths":{"<local_registry>": {"auth": "<credentials>","email": "you@example.com"}}}' 
15

sshKey: 'ssh-ed25519 AAAA...' 
16

additionalTrustBundle: | 
17

  -----BEGIN CERTIFICATE-----
  ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
  -----END CERTIFICATE-----
imageContentSources: 
18

- 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
Copy to Clipboard Toggle word wrap
1
集群的基域。所有 DNS 记录都必须是这个基域的子域,并包含集群名称。
2 5
controlPlane 部分是一个单个映射,但 compute 部分是一系列映射。为满足不同数据结构的要求,compute 部分的第一行必须以连字符 - 开头,controlPlane 部分 的第一行则不以连字符开头。仅使用一个 control plane 池。
3 6
指定要启用或禁用并发多线程(SMT)还是超线程。默认情况下,启用 SMT 可提高机器中内核的性能。您可以通过将 参数值设置为 Disabled 来禁用它。如果禁用 SMT,则必须在所有集群机器中禁用它;这包括 control plane 和计算机器。
注意

默认启用并发多线程(SMT)。如果您的 BIOS 设置中没有启用 SMT,超线程 参数无效。

重要

如果您禁用 超线程,无论是在 BIOS 中,还是在 install-config.yaml 文件中,请确保您的容量规划考虑机器性能显著降低的情况。

4
在用户置备的基础架构上安装 OpenShift Container Platform 时,必须将这个值设置为 0。在安装程序置备的安装中,参数控制集群为您创建和管理的计算机器数量。在用户置备的安装中,您必须在完成集群安装前手动部署计算机器。
注意

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

7
您添加到集群的 control plane 机器数量。由于集群使用这些值作为集群中的 etcd 端点数量,所以该值必须与您部署的 control plane 机器数量匹配。
8
您在 DNS 记录中指定的集群名称。
9
从中分配 Pod IP 地址的 IP 地址块。此块不得与现有物理网络重叠。这些 IP 地址用于 pod 网络。如果需要从外部网络访问 pod,您必须配置负载均衡器和路由器来管理流量。
注意

类 E CIDR 范围被保留以供以后使用。要使用 Class E CIDR 范围,您必须确保您的网络环境接受 Class E CIDR 范围内的 IP 地址。

10
分配给每个节点的子网前缀长度。例如,如果 hostPrefix 设为 23,则每个节点从 given cidr 中分配 a /23 子网,这样就能有 510(2^(32 - 23)- 2)个 pod IP 地址。如果需要从外部网络访问节点,请配置负载均衡器和路由器来管理流量。
11
要安装的集群网络插件。默认值 OVNKubernetes 是唯一支持的值。
12
用于服务 IP 地址的 IP 地址池。您只能输入一个 IP 地址池。此块不得与现有物理网络重叠。如果您需要从外部网络访问服务,请配置负载均衡器和路由器来管理流量。
13
您必须将平台设置为 none。您无法为您的平台提供额外的平台配置变量。
重要

使用平台类型 none 安装的集群无法使用一些功能,如使用 Machine API 管理计算机器。即使附加到集群的计算机器安装在通常支持该功能的平台上,也会应用这个限制。在安装后无法更改此参数。

14
是否启用或禁用 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 核心组件使用 RHEL 加密库,只有在 x86_64, ppc64le, 和 s390x 架构上的库被提交到 NIST 进行 FIPS 140-2/140-3 Validation。

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

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

17
提供用于镜像 registry 的证书文件内容。
18
根据您用来镜像存储库的命令输出提供 imageContentSources 部分。
重要
  • 使用 oc adm release mirror 命令时,请使用 imageContentSources 部分中的输出。
  • 使用 oc mirror 命令时,请使用运行该命令结果的 ImageContentSourcePolicy 文件的 repositoryDigestMirrors 部分。
  • ImageContentSourcePolicy 已被弃用。如需更多信息,请参阅配置镜像 registry 存储库镜像
2.3.10.2. 在安装过程中配置集群范围的代理

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

注意

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

先决条件

  • 您有一个现有的 install-config.yaml 文件。
  • 您检查了集群需要访问的站点,并确定它们中的任何站点是否需要绕过代理。默认情况下,所有集群出口流量都经过代理,包括对托管云供应商 API 的调用。如果需要,您将在 Proxy 对象的 spec.noProxy 字段中添加站点来绕过代理。

    注意

    Proxy 对象 status.noProxy 字段使用安装配置中的 networking.machineNetwork[].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
    Copy to Clipboard Toggle word wrap
    1
    用于创建集群外 HTTP 连接的代理 URL。URL 方案必须是 http
    2
    用于创建集群外 HTTPS 连接的代理 URL。
    3
    要从代理中排除的目标域名、IP 地址或其他网络 CIDR 的逗号分隔列表。在域前面加上 . 以仅匹配子域。例如,.y.com 匹配 x.y.com,但不匹配 y.com。使用 * 绕过所有目的地的代理。
    4
    如果提供,安装程序会在 openshift-config 命名空间中生成名为 user-ca-bundle 的配置映射,其包含代理 HTTPS 连接所需的一个或多个额外 CA 证书。然后,Cluster Network Operator 会创建一个 trusted-ca-bundle 配置映射,将这些内容与 Red Hat Enterprise Linux CoreOS (RHCOS)信任捆绑包合并,Proxy 对象的 trustedCA 字段中也会引用此配置映射。additionalTrustBundle 字段是必需的,除非代理的身份证书由来自 RHCOS 信任捆绑包的颁发机构签名。
    5
    可选:决定 Proxy 对象的配置以引用 trustedCA 字段中 user-ca-bundle 配置映射的策略。允许的值是 ProxyonlyAlways。仅在配置了 http/https 代理时,使用 Proxyonly 引用 user-ca-bundle 配置映射。使用 Always 始终引用 user-ca-bundle 配置映射。默认值为 Proxyonly
    注意

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

    注意

    如果安装程序超时,重启并使用安装程序的 wait-for 命令完成部署。例如:

    $ ./openshift-install wait-for install-complete --log-level debug
    Copy to Clipboard Toggle word wrap
  2. 保存该文件并在安装 OpenShift Container Platform 时引用。

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

注意

只支持名为 clusterProxy 对象,且无法创建额外的代理。

2.3.10.3. 配置三节点集群

另外,您可以在只由三台 control plane 机器组成的裸机集群中部署零台计算机器。这为集群管理员和开发人员提供了更小、效率更高的集群,用于测试、开发和生产。

在三节点 OpenShift Container Platform 环境中,三台 control plane 机器可以调度,这意味着应用程序工作负载被调度到它们上运行。

先决条件

  • 您有一个现有的 install-config.yaml 文件。

流程

  • 确保 install-config.yaml 文件中的计算副本数量设置为 0,如以下 计算 小节所示:

    compute:
    - name: worker
      platform: {}
      replicas: 0
    Copy to Clipboard Toggle word wrap
    注意

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

对于三节点集群安装,请按照以下步骤执行:

  • 如果要部署一个带有零计算节点的三节点集群,Ingress Controller Pod 在 control plane 节点上运行。在三节点集群部署中,您必须配置应用程序入口负载均衡器,将 HTTP 和 HTTPS 流量路由到 control plane 节点。如需更多信息,请参阅用户置备的基础架构的负载平衡要求 部分。
  • 在以下步骤中创建 Kubernetes 清单文件时,请确保 <installation_directory>/manifests/cluster-scheduler-02-config.yml 文件中的 mastersSchedulable 参数被设置为 true。这可让应用程序工作负载在 control plane 节点上运行。
  • 在创建 Red Hat Enterprise Linux CoreOS(RHCOS)机器时,不要部署任何计算节点。

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

由于您必须修改一些集群定义文件并手动启动集群机器,因此您必须生成 Kubernetes 清单和 Ignition 配置文件来配置机器。

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

重要
  • OpenShift Container Platform 安装程序生成的 Ignition 配置文件包含 24 小时后过期的证书,然后在该时进行续订。如果在更新证书前关闭集群,且集群在 24 小时后重启,集群会自动恢复过期的证书。一个例外是,您必须手动批准待处理的 node-bootstrapper 证书签名请求(CSR)来恢复 kubelet 证书。如需更多信息,请参阅从过期的 control plane 证书 中恢复的文档。
  • 建议您在 Ignition 配置文件生成后的 12 小时内使用它们,因为 24 小时的证书会在集群安装后的 16 小时到 22 小时间进行轮转。通过在 12 小时内使用 Ignition 配置文件,您可以避免在安装过程中因为执行了证书更新而导致安装失败的问题。

先决条件

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

流程

  1. 进入包含 OpenShift Container Platform 安装程序的目录,并为集群生成 Kubernetes 清单:

    $ ./openshift-install create manifests --dir <installation_directory> 
    1
    Copy to Clipboard Toggle word wrap
    1
    对于 <installation_directory>,请指定包含您创建的 install-config.yaml 文件的安装目录。
    警告

    如果您要安装一个三节点集群,请跳过以下步骤,以便可以调度 control plane 节点。

    重要

    当您将 control plane 节点从默认的不可调度配置为可以调度时,需要额外的订阅。这是因为 control plane 节点变为计算节点。

  2. 检查 <installation_directory>/manifests/cluster-scheduler-02-config.yml Kubernetes 清单文件中的 mastersSchedulable 参数是否已设置为 false。此设置可防止在 control plane 机器上调度 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
    Copy to Clipboard Toggle word wrap
    1
    对于 <installation_directory>,请指定相同的安装目录。

    为安装目录中的 bootstrap、control plane 和计算节点创建 Ignition 配置文件。kubeadmin-passwordkubeconfig 文件在 ./<installation_directory>/auth 目录中创建:

    .
    ├── auth
    │   ├── kubeadmin-password
    │   └── kubeconfig
    ├── bootstrap.ign
    ├── master.ign
    ├── metadata.json
    └── worker.ign
    Copy to Clipboard Toggle word wrap

2.3.12. 配置 chrony 时间服务

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

流程

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

    注意

    您在配置文件中指定的 Butane 版本应与 OpenShift Container Platform 版本匹配,并且始终以 0 结尾。例如,4.19.0。有关 Butane 的信息,请参阅"使用 Butane 创建机器配置"。

    variant: openshift
    version: 4.19.0
    metadata:
      name: 99-worker-chrony 
    1
    
      labels:
        machineconfiguration.openshift.io/role: worker 
    2
    
    storage:
      files:
      - path: /etc/chrony.conf
        mode: 0644 
    3
    
        overwrite: true
        contents:
          inline: |
            pool 0.rhel.pool.ntp.org iburst 
    4
    
            driftfile /var/lib/chrony/drift
            makestep 1.0 3
            rtcsync
            logdir /var/log/chrony
    Copy to Clipboard Toggle word wrap
    1 2
    在 control plane 节点上,在这两个位置中将 master 替换为 worker
    3
    为机器配置文件的 mode 字段指定数值模式。在创建文件并应用更改后,模式 将转换为十进制值。您可以使用 oc get mc <mc-name> -o yaml 命令来检查 YAML 文件。
    4
    指定任何有效的、可访问的时间源,如 DHCP 服务器提供的源。
    注意

    对于全机器与全机器的通信,UDP 上的网络时间协议(NTP)是端口 123。如果配置了外部 NTP 时间服务器,需要打开 UDP 端口 123

  2. 使用 Butane 生成 MachineConfig 对象文件 99-worker-chrony.yaml,其中包含要交付至节点的配置:

    $ butane 99-worker-chrony.bu -o 99-worker-chrony.yaml
    Copy to Clipboard Toggle word wrap
  3. 使用以下两种方式之一应用配置:

    • 如果集群还没有运行,在生成清单文件后,将 MachineConfig 对象文件添加到 <installation_directory>/openshift 目录中,然后继续创建集群。
    • 如果集群已在运行,请应用该文件:

      $ oc apply -f ./99-worker-chrony.yaml
      Copy to Clipboard Toggle word wrap

要在您置备的裸机基础架构上安装 OpenShift Container Platform,您必须在机器上安装 Red Hat Enterprise Linux CoreOS(RHCOS)。安装 RHCOS 时,您必须为您要安装的机器类型提供 OpenShift Container Platform 安装程序生成的 Ignition 配置文件。如果您配置了适当的网络、DNS 和负载均衡基础架构,OpenShift Container Platform bootstrap 过程会在 RHCOS 机器重启后自动启动。

要在机器上安装 RHCOS,请按照以下步骤使用 ISO 镜像或网络 PXE 引导。

注意

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

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

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

    注意

    0.17.0-3 起,coreos-installer 需要 RHEL 9 或更高版本来运行该程序。您仍然可以使用旧版本的 coreos-installer 自定义较新的 OpenShift Container Platform 版本的 RHCOS 工件,并将构建器镜像安装到磁盘。您可以从 coreos-installer image mirror 页下载旧版本的 coreos-installer 二进制文件。

使用 ISO 安装还是 PXE 安装取决于您的情况。PXE 安装需要可用的 DHCP 服务并进行更多准备,但可以使安装过程更加自动化。ISO 安装是一个更手动的过程,如果您设置的机器数超过几台,则可能不方便。

2.3.13.1. 使用 ISO 镜像安装 RHCOS

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

先决条件

  • 已为集群创建 Ignition 配置文件。
  • 您已配置了适当的网络、DNS 和负载平衡基础架构。
  • 您有一个可以从计算机以及您创建的机器访问的 HTTP 服务器。
  • 您已参阅 Advanced RHCOS 安装配置 部分来了解配置功能的不同方法,如网络和磁盘分区。

流程

  1. 获取每个 Ignition 配置文件的 SHA512 摘要。例如,您可以在运行 Linux 的系统上使用以下内容来获取 bootstrap.ign Ignition 配置文件的 SHA512 摘要:

    $ sha512sum <installation_directory>/bootstrap.ign
    Copy to Clipboard Toggle word wrap

    后续步骤中会向 coreos-installer 提供摘要,以验证集群节点上 Ignition 配置文件的真实性。

  2. 将安装程序创建的 bootstrap、control plane 和计算节点 Ignition 配置文件上传到 HTTP 服务器。注意这些文件的 URL。

    重要

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

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

    $ curl -k http://<HTTP_server>/bootstrap.ign 
    1
    Copy to Clipboard Toggle word wrap

    输出示例

      % 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...
    Copy to Clipboard Toggle word wrap

    在命令中将 bootstrap.ign 替换为 master.ignworker.ign,以验证 control plane 和计算节点的 Ignition 配置文件是否可用。

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

    $ openshift-install coreos print-stream-json | grep '\.iso[^.]'
    Copy to Clipboard Toggle word wrap

    输出示例

    "location": "<url>/art/storage/releases/rhcos-4.19-aarch64/<release>/aarch64/rhcos-<release>-live.aarch64.iso",
    "location": "<url>/art/storage/releases/rhcos-4.19-ppc64le/<release>/ppc64le/rhcos-<release>-live.ppc64le.iso",
    "location": "<url>/art/storage/releases/rhcos-4.19-s390x/<release>/s390x/rhcos-<release>-live.s390x.iso",
    "location": "<url>/art/storage/releases/rhcos-4.19/<release>/x86_64/rhcos-<release>-live.x86_64.iso",
    Copy to Clipboard Toggle word wrap

    重要

    RHCOS 镜像可能不会随着 OpenShift Container Platform 的每个发行版本而改变。您必须下载最高版本的镜像,其版本号应小于或等于您安装的 OpenShift Container Platform 版本。如果可用,请使用与 OpenShift Container Platform 版本匹配的镜像版本。这个过程只使用 ISO 镜像。此安装类型不支持 RHCOS qcow2 镜像。

    ISO 文件名类似以下示例:

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

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

    • 将 ISO 映像刻录到磁盘并直接启动。
    • 使用 light-out 管理(LOM)接口使用 ISO 重定向。
  6. 在不指定任何选项或中断实时引导序列的情况下引导 RHCOS ISO 镜像。等待安装程序在 RHCOS live 环境中引导进入 shell 提示符。

    注意

    可以中断 RHCOS 安装引导过程来添加内核参数。但是,在这个 ISO 过程中,您应该使用以下步骤中所述的 coreos-installer 命令,而不是添加内核参数。

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

    $ sudo coreos-installer install --ignition-url=http://<HTTP_server>/<node_type>.ign <device> \ 
    1
    
    --ignition-hash=sha512-<digest> --offline 
    2
    Copy to Clipboard Toggle word wrap
    1 1
    您必须使用 sudo 运行 coreos-installer 命令,因为 core 用户没有执行安装所需的 root 权限。
    2
    当 Ignition 配置文件通过 HTTP URL 获取时,需要 --ignition-hash 选项来验证集群节点上 Ignition 配置文件的真实性。<digest> 是上一步中获取的 Ignition 配置文件 SHA512 摘要。
    注意

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

    以下示例将引导节点安装初始化到 /dev/sda 设备。bootstrap 节点的 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 \
    --offline
    Copy to Clipboard Toggle word wrap
  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
    Copy to Clipboard Toggle word wrap

  11. 继续为集群创建其他机器。

    重要

    此时您必须创建 bootstrap 和 control plane 机器。如果 control plane 机器不可调度,请在安装 OpenShift Container Platform 前至少创建两台计算机器。

    如果存在所需的网络、DNS 和负载均衡器基础架构,OpenShift Container Platform bootstrap 过程会在 RHCOS 节点重启后自动启动。

    注意

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

2.3.13.2. 使用 PXE 或 iPXE 启动安装 RHCOS

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

先决条件

  • 已为集群创建 Ignition 配置文件。
  • 您已配置了适当的网络、DNS 和负载平衡基础架构。
  • 您已配置了合适的 PXE 或 iPXE 基础架构。
  • 您有一个可以从计算机以及您创建的机器访问的 HTTP 服务器。
  • 您已参阅 Advanced RHCOS 安装配置 部分来了解配置功能的不同方法,如网络和磁盘分区。

流程

  1. 将安装程序创建的 bootstrap、control plane 和计算节点 Ignition 配置文件上传到 HTTP 服务器。注意这些文件的 URL。

    重要

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

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

    $ curl -k http://<HTTP_server>/bootstrap.ign 
    1
    Copy to Clipboard Toggle word wrap

    输出示例

      % 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...
    Copy to Clipboard Toggle word wrap

    在命令中将 bootstrap.ign 替换为 master.ignworker.ign,以验证 control plane 和计算节点的 Ignition 配置文件是否可用。

  3. 虽然可以从 RHCOS image mirror 页面获取您选择的操作系统实例所需的 RHCOS kernelinitramfsrootfs 文件,但推荐的方法是从 openshift-install 命令的输出中获取 RHCOS 文件的正确版本:

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

    输出示例

    "<url>/art/storage/releases/rhcos-4.19-aarch64/<release>/aarch64/rhcos-<release>-live-kernel-aarch64"
    "<url>/art/storage/releases/rhcos-4.19-aarch64/<release>/aarch64/rhcos-<release>-live-initramfs.aarch64.img"
    "<url>/art/storage/releases/rhcos-4.19-aarch64/<release>/aarch64/rhcos-<release>-live-rootfs.aarch64.img"
    "<url>/art/storage/releases/rhcos-4.19-ppc64le/49.84.202110081256-0/ppc64le/rhcos-<release>-live-kernel-ppc64le"
    "<url>/art/storage/releases/rhcos-4.19-ppc64le/<release>/ppc64le/rhcos-<release>-live-initramfs.ppc64le.img"
    "<url>/art/storage/releases/rhcos-4.19-ppc64le/<release>/ppc64le/rhcos-<release>-live-rootfs.ppc64le.img"
    "<url>/art/storage/releases/rhcos-4.19-s390x/<release>/s390x/rhcos-<release>-live-kernel-s390x"
    "<url>/art/storage/releases/rhcos-4.19-s390x/<release>/s390x/rhcos-<release>-live-initramfs.s390x.img"
    "<url>/art/storage/releases/rhcos-4.19-s390x/<release>/s390x/rhcos-<release>-live-rootfs.s390x.img"
    "<url>/art/storage/releases/rhcos-4.19/<release>/x86_64/rhcos-<release>-live-kernel-x86_64"
    "<url>/art/storage/releases/rhcos-4.19/<release>/x86_64/rhcos-<release>-live-initramfs.x86_64.img"
    "<url>/art/storage/releases/rhcos-4.19/<release>/x86_64/rhcos-<release>-live-rootfs.x86_64.img"
    Copy to Clipboard Toggle word wrap

    重要

    RHCOS 工件可能不会随着 OpenShift Container Platform 的每个发行版本而改变。您必须下载最高版本的镜像,其版本号应小于或等于您安装的 OpenShift Container Platform 版本。这个过程只使用下面描述的适当 kernelinitram fs 和 rootfs 工件。此安装类型不支持 RHCOS QCOW2 镜像。

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

    • kernel:rhcos-<version>-live-kernel-<architecture>
    • initramfs: rhcos-<version>-live-initramfs.<architecture>.img
    • rootfs: rhcos-<version>-live-rootfs.<architecture>.img
  4. rootfskernelinitramfs 文件上传到 HTTP 服务器。

    重要

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

  5. 配置网络引导基础架构,以便在安装 RHCOS 后机器从本地磁盘启动。
  6. 为 RHCOS 镜像配置 PXE 或 iPXE 安装并开始安装。

    为环境修改以下示例菜单条目之一,并验证能否正确访问镜像和 Ignition 文件:

    • 对于 PXE(x86_64)

      DEFAULT pxeboot
      TIMEOUT 20
      PROMPT 0
      LABEL pxeboot
          KERNEL http://<HTTP_server>/rhcos-<version>-live-kernel-<architecture> 
      1
      
          APPEND initrd=http://<HTTP_server>/rhcos-<version>-live-initramfs.<architecture>.img coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/bootstrap.ign 
      2
       
      3
      Copy to Clipboard Toggle word wrap
      1 1
      指定上传到 HTTP 服务器的 live kernel 文件位置。URL 必须是 HTTP、TFTP 或 FTP;不支持 HTTPS 和 NFS。
      2
      如果您使用多个 NIC,请在 ip 选项中指定一个接口。例如,要在名为 eno1 的 NIC 上使用 DHCP,请设置 ip=eno1:dhcp
      3
      指定上传到 HTTP 服务器的 RHCOS 文件的位置。initrd 参数值是 initramfs 文件的位置,coreos.live.rootfs_url 参数值是 rootfs 文件的位置,coreos.inst.ignition_url 参数值则是 bootstrap Ignition 配置文件的位置。您还可以在 APPEND 行中添加更多内核参数来配置联网或其他引导选项。
      注意

      此配置不会在图形控制台的机器上启用串行控制台访问。要配置不同的控制台,请在 APPEND 行中添加一个或多个 console= 参数。例如,添加 console=tty0 console=ttyS0 以将第一个 PC 串口设置为主控制台,并将图形控制台设置为二级控制台。如需更多信息,请参阅如何在 Red Hat Enterprise Linux 中设置串行终端和/或控制台? 和"启用 PXE 和 ISO 安装的串行控制台"部分。

    • 对于 iPXE (x86_64 + aarch64 ):

      kernel http://<HTTP_server>/rhcos-<version>-live-kernel-<architecture> initrd=main coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/bootstrap.ign 
      1
       
      2
      
      initrd --name main http://<HTTP_server>/rhcos-<version>-live-initramfs.<architecture>.img 
      3
      
      boot
      Copy to Clipboard Toggle word wrap
      1
      指定上传到 HTTP 服务器的 RHCOS 文件的位置。kernel 参数值是 kernel 文件的位置,init rd=main 参数用于在 UEFI 系统中引导,coreos.live.rootfs_url 参数值是 rootfs 文件的位置,coreos.inst.ignition_url 参数值则是 bootstrap Ignition 配置文件的位置。
      2
      如果您使用多个 NIC,请在 ip 选项中指定一个接口。例如,要在名为 eno1 的 NIC 上使用 DHCP,请设置 ip=eno1:dhcp
      3
      指定上传到 HTTP 服务器的 initramfs 文件的位置。
      注意

      此配置不会在图形控制台的机器上启用串行控制台访问。要配置不同的控制台,请在 内核参数 中添加一个或多个 console= 参数。例如,添加 console=tty0 console=ttyS0 以将第一个 PC 串口设置为主控制台,并将图形控制台设置为二级控制台。如需更多信息,请参阅如何在 Red Hat Enterprise Linux 中设置串行终端和/或控制台? 和"启用 PXE 和 ISO 安装的串行控制台"部分。

      注意

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

    • 对于 aarch64 中的 PXE(使用 UEFI 和 Grub 作为第二阶段):

      menuentry 'Install CoreOS' {
          linux rhcos-<version>-live-kernel-<architecture>  coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/bootstrap.ign 
      1
       
      2
      
          initrd rhcos-<version>-live-initramfs.<architecture>.img 
      3
      
      }
      Copy to Clipboard Toggle word wrap
      1
      指定上传到 HTTP/TFTP 服务器的 RHCOS 文件的位置。kernel 参数值是 TFTP 服务器中的 kernel 文件的位置。coreos.live.rootfs_url 参数值是 rootfs 文件的位置,coreos.inst.ignition_url 参数值是 HTTP 服务器上的 bootstrap Ignition 配置文件的位置。
      2
      如果您使用多个 NIC,请在 ip 选项中指定一个接口。例如,要在名为 eno1 的 NIC 上使用 DHCP,请设置 ip=eno1:dhcp
      3
      指定上传到 TFTP 服务器的 initramfs 文件的位置。
  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
    Copy to Clipboard Toggle word wrap

  10. 继续为集群创建机器。

    重要

    此时您必须创建 bootstrap 和 control plane 机器。如果 control plane 机器不可调度,请在安装集群前至少创建两台计算机器。

    如果存在所需的网络、DNS 和负载均衡器基础架构,OpenShift Container Platform bootstrap 过程会在 RHCOS 节点重启后自动启动。

    注意

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

2.3.13.3. 高级 RHCOS 安装配置

为 OpenShift Container Platform 手动置备 Red Hat Enterprise Linux CoreOS(RHCOS)节点的一个关键优点是能够进行通过默认的 OpenShift Container Platform 安装方法无法进行的配置。本节介绍了您可以使用的一些技术进行配置,其中包括:

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

本节详述了与 Red Hat Enterprise Linux CoreOS(RHCOS)手动安装的高级配置相关的内容,如磁盘分区、网络以及使用 Ignition 配置的不同方式相关。

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

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

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

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

要配置 ISO 安装,请使用以下步骤:

流程

  1. 引导 ISO 安装程序.
  2. 在 live 系统 shell 提示符下,使用可用的 RHEL 工具(如 nmclinmtui )为 live 系统配置网络。
  3. 运行 coreos-installer 命令以安装系统,添加 --copy-network 选项来复制网络配置。例如:

    $ sudo coreos-installer install --copy-network \
    --ignition-url=http://host/worker.ign \
    --offline \
    /dev/disk/by-id/scsi-<serial_number>
    Copy to Clipboard Toggle word wrap
    重要

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

  4. 重启安装的系统。
2.3.13.3.2. 磁盘分区

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

重要

在节点上使用自定义分区方案可能会导致 OpenShift Container Platform 在某些节点分区上监控或警报。如果要覆盖默认分区,请参阅 了解 OpenShift 文件系统监控(驱除条件) 以了解有关 OpenShift Container Platform 如何监控主机文件系统的更多信息。

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

  • nodefs,这是包含 /var/lib/kubelet 的文件系统
  • imagefs,这是包含 /var/lib/containers 的文件系统

对于默认分区方案,nodefsimagefs 监控相同的根文件系统 /

要在 OpenShift Container Platform 集群节点上安装 RHCOS 时覆盖默认分区,您必须创建单独的分区。您可能想要为容器和容器镜像添加单独的存储分区。例如,通过在独立分区中挂载 /var/lib/containers,kubelet 会单独监控 /var/lib/containers 作为 imagefs 目录,以及 root 文件系统作为 nodefs 目录。

重要

如果您已将磁盘大小调整为托管更大的文件系统,请考虑创建单独的 /var/lib/containers 分区。考虑重新定义具有 xfs 格式的磁盘大小,以减少大量分配组导致的 CPU 时间问题。

2.3.13.3.2.1. 创建独立 /var 分区

通常,您应该使用在 RHCOS 安装过程中创建的默认磁盘分区。然而,在有些情况下您可能需要为预期增长的目录创建独立分区。

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

  • /var/lib/containers :保存随着系统中添加更多镜像和容器而增长的容器相关内容。
  • /var/lib/etcd :保存您可能希望独立保留的数据,比如 etcd 存储的性能优化。
  • /var :保存您可能希望独立保留的数据,以满足审计等目的。

    重要

    对于大于 100GB 的磁盘大小,特别是磁盘大小大于 1TB,请创建一个独立的 /var 分区。

通过单独存储 /var 目录的内容,可以更轻松地根据需要为区域扩展存储,并在以后重新安装 OpenShift Container Platform,并保持该数据的完整性。使用这个方法,您不必再次拉取所有容器,在更新系统时也不必复制大量日志文件。

将独立分区用于 /var 目录或 /var 的子目录也会防止分区目录中的数据增加填充根文件系统。

以下流程通过添加机器配置清单来设置独立的 /var 分区,该清单会在安装准备阶段封装到节点类型的 Ignition 配置文件中。

流程

  1. 在安装主机上,切换到包含 OpenShift Container Platform 安装程序的目录,并为集群生成 Kubernetes 清单:

    $ openshift-install create manifests --dir <installation_directory>
    Copy to Clipboard Toggle word wrap
  2. 创建用于配置额外分区的 Butane 配置。例如,将文件命名为 $HOME/clusterconfig/98-var-partition.bu,将磁盘设备名称改为 worker 系统上存储设备的名称,并根据情况设置存储大小。这个示例将 /var 目录放在一个单独的分区中:

    variant: openshift
    version: 4.19.0
    metadata:
      labels:
        machineconfiguration.openshift.io/role: worker
      name: 98-var-partition
    storage:
      disks:
      - device: /dev/disk/by-id/<device_name> 
    1
    
        partitions:
        - label: var
          start_mib: <partition_start_offset> 
    2
    
          size_mib: <partition_size> 
    3
    
          number: 5
      filesystems:
        - device: /dev/disk/by-partlabel/var
          path: /var
          format: xfs
          mount_options: [defaults, prjquota] 
    4
    
          with_mount_unit: true
    Copy to Clipboard Toggle word wrap
    1
    要分区的磁盘的存储设备名称。
    2
    当在引导磁盘中添加数据分区时,推荐最少使用偏移值 25000 兆字节。root 文件系统会自动调整大小以填充所有可用空间(最多到指定的偏移值)。如果没有指定偏移值,或者指定的值小于推荐的最小值,则生成的 root 文件系统会太小,而在以后进行的 RHCOS 重新安装可能会覆盖数据分区的开始部分。
    3
    以兆字节为单位的数据分区大小。
    4
    对于用于容器存储的文件系统,必须启用 prjquota 挂载选项。
    注意

    在创建单独的 /var 分区时,如果不同的实例类型没有相同的设备名称,则无法将不同的实例类型用于计算节点。

  3. 从 Butane 配置创建一个清单,并将它保存到 clusterconfig/openshift 目录中。例如,运行以下命令:

    $ butane $HOME/clusterconfig/98-var-partition.bu -o $HOME/clusterconfig/openshift/98-var-partition.yaml
    Copy to Clipboard Toggle word wrap
  4. 创建 Ignition 配置文件:

    $ openshift-install create ignition-configs --dir <installation_directory> 
    1
    Copy to Clipboard Toggle word wrap
    1
    对于 <installation_directory>,请指定相同的安装目录。

    为安装目录中的 bootstrap、control plane 和计算节点创建 Ignition 配置文件:

    .
    ├── auth
    │   ├── kubeadmin-password
    │   └── kubeconfig
    ├── bootstrap.ign
    ├── master.ign
    ├── metadata.json
    └── worker.ign
    Copy to Clipboard Toggle word wrap

    <installation_directory>/manifest<installation_directory>/openshift 目录中的文件被嵌套到 Ignition 配置文件中,包括包含 98-var-partition 自定义 MachineConfig 对象的文件。

后续步骤

  • 您可以通过在 RHCOS 安装过程中引用 Ignition 配置文件来应用自定义磁盘分区。
2.3.13.3.2.2. 保留现有分区

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

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

注意

如果您保存了现有分区,且这些分区没有为 RHCOS 留下足够空间,则安装将失败,而不影响保存的分区。

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

这个示例保留分区标签以 数据开头的任何分区(data *):

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

以下示例演示了在运行 coreos-installer 时要保留磁盘上的第 6 个分区:

# coreos-installer install --ignition-url http://10.0.2.2:8080/user.ign \
--save-partindex 6 \
--offline \
/dev/disk/by-id/scsi-<serial_number>
Copy to Clipboard Toggle word wrap

这个示例保留分区 5 及更高分区:

# coreos-installer install --ignition-url http://10.0.2.2:8080/user.ign \
--save-partindex 5- \
--offline \
/dev/disk/by-id/scsi-<serial_number>
Copy to Clipboard Toggle word wrap

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

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

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

coreos.inst.save_partlabel=data*
Copy to Clipboard Toggle word wrap

这个 APPEND 选项保留分区 5 及更高分区:

coreos.inst.save_partindex=5-
Copy to Clipboard Toggle word wrap

这个 APPEND 选项保留分区 6:

coreos.inst.save_partindex=6
Copy to Clipboard Toggle word wrap
2.3.13.3.3. 识别 Ignition 配置

在进行 RHCOS 手动安装时,您可以提供两种 Ignition 配置类型,它们有不同的原因:

  • 永久安装 Ignition 配置 :每个手动 RHCOS 安装都需要传递 openshift-installer 生成的 Ignition 配置文件之一,如 bootstrap.ignmaster.ignworker.ign,才能进行安装。

    重要

    不建议直接修改这些 Ignition 配置文件。您可以更新嵌套到 Ignition 配置文件中的清单文件,如上一节示例中所述。

    对于 PXE 安装,您可以使用 coreos.inst.ignition_url= 选项在 APPEND 行上传递 Ignition 配置。对于 ISO 安装,在 ISO 引导至 shell 提示符后,您可以使用带有 --ignition-url= 选项的 coreos-installer 命令行。在这两种情况下,只支持 HTTP 和 HTTPS 协议。

  • 实时安装 Ignition 配置 :可使用 coreos-installer customize 子命令及其各种选项来创建此类型。使用此方法,Ignition 配置会传递到 live 安装介质,在引导时立即运行,并在 RHCOS 系统安装到磁盘之前或之后执行设置任务。这个方法只用于必须执行一次且之后不能再次应用的任务,比如不能使用机器配置进行的高级分区。

    对于 PXE 或 ISO 引导,您可以创建 Ignition 配置,APP END ignition.config.url= 选项来标识 Ignition 配置的位置。您还需要附加 ignition.firstboot ignition.platform.id=metalignition.config.url 选项。

2.3.13.3.4. 默认控制台配置

从 OpenShift Container Platform 4.19 引导镜像安装的 Red Hat Enterprise Linux CoreOS (RHCOS) 节点使用默认控制台,旨在识别大多数虚拟化和裸机设置。不同的云和虚拟化平台可能会根据所选的架构使用不同的默认设置。裸机安装使用内核默认设置,这通常意味着图形控制台是主控制台,并且禁用串行控制台。

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

  • 您希望访问控制台上的紧急 shell 进行调试。
  • 您的云平台没有提供到图形控制台的互动访问,但提供了一个串行控制台。
  • 您需要启用多个控制台。

控制台配置继承自引导镜像。这意味着现有集群中的新节点不受默认控制台的影响。

您可以使用以下方法为裸机安装配置控制台:

  • 在命令行中手动使用 coreos-installer
  • 使用带有 --dest-console 选项的 coreos-installer iso customizecoreos-installer pxe customize 子命令,以创建可自动执行进程的自定义镜像。
注意

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

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

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

流程

  1. 引导 ISO 安装程序.
  2. 运行 coreos-installer 命令来安装系统,添加 --console 选项一次来指定图形控制台,然后第二次指定串行控制台:

    $ coreos-installer install \
    --console=tty0 \
    1
    
    --console=ttyS0,<options> \
    2
    
    --ignition-url=http://host/worker.ign \
    --offline \
    /dev/disk/by-id/scsi-<serial_number>
    Copy to Clipboard Toggle word wrap
    1
    所需的二级控制台。在这种情况下,是图形控制台。省略这个选项将禁用图形控制台。
    2
    所需的主控制台。在这种情况下,是串行控制台。options 字段定义 baud 速率和其他设置。此字段的一个常见值为 115200n8。如果没有提供选项,则使用默认内核值 9600n8。有关这个选项格式的更多信息,请参阅 Linux 内核串口控制台 文档。
  3. 重启安装的系统。

    注意

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

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

2.3.13.3.6. 自定义 live RHCOS ISO 或 PXE 安装

您可以通过将 Ignition 配置文件直接注入镜像中来使用 live ISO 镜像或 PXE 环境来安装 RHCOS。这会创建一个自定义镜像,供您用来置备系统。

对于 ISO 镜像,此操作的机制是 coreos-installer iso custom 子命令,它使用您的配置修改 .iso 文件。同样,PXE 环境的机制是 coreos-installer pxe customize 子命令,它会创建一个包含自定义的新 initramfs 文件。

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

  • 当公司安全策略需要使用时,注入自定义的 CA 证书。
  • 在不需要内核参数的情况下配置网络设置。
  • 嵌入任意预安装和安装后脚本或二进制文件。
2.3.13.3.7. 自定义 live RHCOS ISO 镜像

您可以使用 coreos-installer iso custom 子命令直接自定义 live RHCOS ISO 镜像。当您引导 ISO 镜像时,会自动应用自定义。

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

流程

  1. coreos-installer 镜像镜像页面下载 coreos-installer 二进制文件。
  2. 从 RHCOS 镜像镜像页面和 Ignition 配置文件检索 RHCOS ISO 镜像,然后运行以下命令来直接将 Ignition 配置注入 ISO 镜像:

    $ coreos-installer iso customize rhcos-<version>-live.x86_64.iso \
        --dest-ignition bootstrap.ign \ 
    1
    
        --dest-device /dev/disk/by-id/scsi-<serial_number> 
    2
    Copy to Clipboard Toggle word wrap
    1
    openshift-installer 安装程序生成的 Ignition 配置文件。
    2
    当您指定这个选项时,ISO 镜像会自动运行安装。否则,镜像为安装配置,但不会自动安装,除非您指定了 coreos.inst.install_dev 内核参数。
  3. 可选: 要删除 ISO 镜像自定义并将镜像返回到其 pristine 状态,请运行:

    $ coreos-installer iso reset rhcos-<version>-live.x86_64.iso
    Copy to Clipboard Toggle word wrap

    现在,您可以重新自定义 live ISO 镜像,或者在其 pristine 状态中使用它。

应用您的自定义会影响每个后续 RHCOS 引导。

在使用 OpenShift Container Platform 4.12 及更高版本安装的集群中,串行控制台默认被禁用,所有输出都会写入图形控制台。您可以按照以下流程启用串行控制台。

流程

  1. coreos-installer 镜像镜像页面下载 coreos-installer 二进制文件。
  2. RHCOS image mirror 页中获取 RHCOS ISO 镜像,并运行以下命令来自定义 ISO 镜像,使串行控制台能够接收输出:

    $ coreos-installer iso customize rhcos-<version>-live.x86_64.iso \
      --dest-ignition <path> \
    1
    
      --dest-console tty0 \
    2
    
      --dest-console ttyS0,<options> \
    3
    
      --dest-device /dev/disk/by-id/scsi-<serial_number> 
    4
    Copy to Clipboard Toggle word wrap
    1
    要安装 Ignition 配置的位置。
    2
    所需的二级控制台。在这种情况下,是图形控制台。省略这个选项将禁用图形控制台。
    3
    所需的主控制台。在这种情况下,是串行控制台。options 字段定义 baud 速率和其他设置。此字段的一个常见值为 115200n8。如果没有提供选项,则使用默认内核值 9600n8。有关这个选项格式的更多信息,请参阅 Linux 内核串口控制台文档。
    4
    要安装到的指定磁盘。如果省略这个选项,ISO 镜像会自动运行安装程序,除非还指定了 coreos.inst.install_dev 内核参数。
    注意

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

    自定义会被应用,并影响每个后续 ISO 镜像引导。

  3. 可选: 要删除 ISO 镜像自定义并将镜像返回到其原始状态,请运行以下命令:

    $ coreos-installer iso reset rhcos-<version>-live.x86_64.iso
    Copy to Clipboard Toggle word wrap

    现在,您可以重新自定义 live ISO 镜像,或者在其原始状态中使用它。

您可以使用 custom 子命令的 --ignition-ca 标志向 Ignition 提供证书颁发机构(CA)证书。您可以在安装过程中使用 CA 证书,并在置备安装的系统时使用 CA 证书。

注意

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

流程

  1. coreos-installer 镜像镜像页面下载 coreos-installer 二进制文件。
  2. 从 RHCOS 镜像镜像页面检索 RHCOS ISO 镜像,并运行以下命令来自定义 ISO 镜像以用于自定义 CA:

    $ coreos-installer iso customize rhcos-<version>-live.x86_64.iso --ignition-ca cert.pem
    Copy to Clipboard Toggle word wrap
重要

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

应用自定义 CA 证书会影响每个后续 RHCOS 引导。

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

警告

在创建连接配置文件时,您必须在连接配置文件的文件名中使用 .nmconnection 文件名扩展名。如果不使用 .nmconnection 文件名扩展,集群会将连接配置集应用到 live 环境,但它不会在集群首次启动节点时应用配置,从而导致无法正常工作的设置。

流程

  1. coreos-installer 镜像镜像页面下载 coreos-installer 二进制文件。
  2. 为绑定接口创建连接配置集。例如,在本地目录中创建 bond0.nmconnection 文件,其内容如下:

    [connection]
    id=bond0
    type=bond
    interface-name=bond0
    multi-connect=1
    
    [bond]
    miimon=100
    mode=active-backup
    
    [ipv4]
    method=auto
    
    [ipv6]
    method=auto
    Copy to Clipboard Toggle word wrap
  3. 为二级接口创建连接配置集,以添加到绑定中。例如,在本地目录中创建 bond0-proxy-em1.nmconnection 文件,其内容如下:

    [connection]
    id=em1
    type=ethernet
    interface-name=em1
    master=bond0
    multi-connect=1
    slave-type=bond
    Copy to Clipboard Toggle word wrap
  4. 为二级接口创建连接配置集,以添加到绑定中。例如,在本地目录中创建 bond0-proxy-em2.nmconnection 文件,其内容如下:

    [connection]
    id=em2
    type=ethernet
    interface-name=em2
    master=bond0
    multi-connect=1
    slave-type=bond
    Copy to Clipboard Toggle word wrap
  5. RHCOS 镜像镜像页面检索 RHCOS ISO 镜像,并运行以下命令来使用您配置网络自定义 ISO 镜像:

    $ coreos-installer iso customize rhcos-<version>-live.x86_64.iso \
        --network-keyfile bond0.nmconnection \
        --network-keyfile bond0-proxy-em1.nmconnection \
        --network-keyfile bond0-proxy-em2.nmconnection
    Copy to Clipboard Toggle word wrap

    网络设置应用于实时系统,并传输到目标系统。

您可以设置 iSCSI 目标和 initiator 值,以便使用自定义的 live RHCOS 镜像版本自动挂载、引导和配置。

先决条件

  1. 您有一个 iSCSI 目标,您要在其中安装 RHCOS。

流程

  1. coreos-installer 镜像镜像页面下载 coreos-installer 二进制文件。
  2. RHCOS 镜像镜像页面检索 RHCOS ISO 镜像,并运行以下命令使用以下信息自定义 ISO 镜像:

    $ coreos-installer iso customize \
        --pre-install mount-iscsi.sh \ 
    1
    
        --post-install unmount-iscsi.sh \ 
    2
    
        --dest-device /dev/disk/by-path/<IP_address>:<port>-iscsi-<target_iqn>-lun-<lun> \ 
    3
    
        --dest-ignition config.ign \ 
    4
    
        --dest-karg-append rd.iscsi.initiator=<initiator_iqn> \ 
    5
    
        --dest-karg-append netroot=<target_iqn> \ 
    6
    
        -o custom.iso rhcos-<version>-live.x86_64.iso
    Copy to Clipboard Toggle word wrap
    1
    安装之前运行的脚本。它应包含用于挂载 iSCSI 目标以及启用多路径的任何命令的 iscsiadm 命令。
    2
    安装后运行的脚本。它应包含命令 iscsiadm --mode node --logout=all
    3
    目标系统的位置。您必须提供目标门户的 IP 地址、关联的端口号、目标 iSCSI 节点采用 IQN 格式,以及 iSCSI 逻辑单元号(LUN)。
    4
    目标系统的 Ignition 配置。
    5
    iSCSI 启动器或客户端,以 IQN 格式的名称。启动器构成连接到 iSCSI 目标的一个会话。
    6
    iSCSI 目标或服务器的名称(IQN 格式)。

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

您可以设置 iSCSI 目标和 initiator 值,以便使用自定义的 live RHCOS 镜像版本自动挂载、引导和配置。

先决条件

  1. 您有一个 iSCSI 目标,您要在其中安装 RHCOS。
  2. 可选:有多路径 iSCSI 目标。

流程

  1. coreos-installer 镜像镜像页面下载 coreos-installer 二进制文件。
  2. RHCOS 镜像镜像页面检索 RHCOS ISO 镜像,并运行以下命令使用以下信息自定义 ISO 镜像:

    $ coreos-installer iso customize \
        --pre-install mount-iscsi.sh \ 
    1
    
        --post-install unmount-iscsi.sh \ 
    2
    
        --dest-device /dev/mapper/mpatha \ 
    3
    
        --dest-ignition config.ign \ 
    4
    
        --dest-karg-append rd.iscsi.firmware=1 \ 
    5
    
        --dest-karg-append rd.multipath=default \ 
    6
    
        -o custom.iso rhcos-<version>-live.x86_64.iso
    Copy to Clipboard Toggle word wrap
    1
    安装之前运行的脚本。它应包含用于挂载 iSCSI 目标以及启用多路径的任何命令的 iscsiadm 命令。
    2
    安装后运行的脚本。它应包含命令 iscsiadm --mode node --logout=all
    3
    设备的路径。如果连接了多个多路径设备,或者需要明确指定,您使用多路径(/dev/mapper/mpatha),您可以使用 /dev/disk/by-path 中可用的 World Wide Name (WWN) 符号链接。
    4
    目标系统的 Ignition 配置。
    5
    iSCSI 参数从 BIOS 固件读取。
    6
    可选:如果您要启用多路径,请包含此参数。

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

2.3.13.3.8. 自定义 live RHCOS PXE 环境

您可以使用 coreos-installer pxe customize 子命令直接自定义 live RHCOS PXE 环境。当您引导 PXE 环境时,会自动应用自定义。

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

流程

  1. coreos-installer 镜像镜像页面下载 coreos-installer 二进制文件。
  2. RHCOS 镜像镜像页面和 Ignition 配置文件获取 RHCOS kernel, initramfsrootfs 文件,然后运行以下命令创建一个包含 Ignition 配置中的自定义的新 initramfs 文件:

    $ coreos-installer pxe customize rhcos-<version>-live-initramfs.x86_64.img \
        --dest-ignition bootstrap.ign \ 
    1
    
        --dest-device /dev/disk/by-id/scsi-<serial_number> \ 
    2
    
        -o rhcos-<version>-custom-initramfs.x86_64.img 
    3
    Copy to Clipboard Toggle word wrap
    1
    openshift-installer 生成的 Ignition 配置文件。
    2
    当您指定这个选项时,PXE 环境会自动运行安装。否则,为安装配置了镜像,除非指定了 coreos.inst.install_dev 内核参数,否则不会自动这样做。
    3
    在 PXE 配置中使用自定义 initramfs 文件。添加 ignition.firstbootignition.platform.id=metal 内核参数(如果它们尚不存在)。

应用您的自定义会影响每个后续 RHCOS 引导。

在使用 OpenShift Container Platform 4.12 及更高版本安装的集群中,串行控制台默认被禁用,所有输出都会写入图形控制台。您可以按照以下流程启用串行控制台。

流程

  1. coreos-installer 镜像镜像页面下载 coreos-installer 二进制文件。
  2. RHCOS image mirror 页面获取 kernel, initramfsrootfs 文件,然后运行以下命令来创建新的自定义 initramfs 文件,以便串行控制台接收输出:

    $ coreos-installer pxe customize rhcos-<version>-live-initramfs.x86_64.img \
      --dest-ignition <path> \
    1
    
      --dest-console tty0 \
    2
    
      --dest-console ttyS0,<options> \
    3
    
      --dest-device /dev/disk/by-id/scsi-<serial_number> \
    4
    
      -o rhcos-<version>-custom-initramfs.x86_64.img 
    5
    Copy to Clipboard Toggle word wrap
    1
    要安装 Ignition 配置的位置。
    2
    所需的二级控制台。在这种情况下,是图形控制台。省略这个选项将禁用图形控制台。
    3
    所需的主控制台。在这种情况下,是串行控制台。options 字段定义 baud 速率和其他设置。此字段的一个常见值为 115200n8。如果没有提供选项,则使用默认内核值 9600n8。有关这个选项格式的更多信息,请参阅 Linux 内核串口控制台文档。
    4
    要安装到的指定磁盘。如果省略这个选项,PXE 环境会自动运行安装程序,除非还指定了 coreos.inst.install_dev 内核参数。
    5
    在 PXE 配置中使用自定义 initramfs 文件。添加 ignition.firstbootignition.platform.id=metal 内核参数(如果它们尚不存在)。

    自定义会被应用,并影响 PXE 环境的每个后续引导。

您可以使用 custom 子命令的 --ignition-ca 标志向 Ignition 提供证书颁发机构(CA)证书。您可以在安装过程中使用 CA 证书,并在置备安装的系统时使用 CA 证书。

注意

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

流程

  1. coreos-installer 镜像镜像页面下载 coreos-installer 二进制文件。
  2. RHCOS 镜像镜像页面获取 RHCOS kernelinitramfsrootfs 文件,并运行以下命令来创建一个新的自定义 initramfs 文件以用于自定义 CA:

    $ coreos-installer pxe customize rhcos-<version>-live-initramfs.x86_64.img \
        --ignition-ca cert.pem \
        -o rhcos-<version>-custom-initramfs.x86_64.img
    Copy to Clipboard Toggle word wrap
  3. 在 PXE 配置中使用自定义 initramfs 文件。添加 ignition.firstbootignition.platform.id=metal 内核参数(如果它们尚不存在)。
重要

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

应用自定义 CA 证书会影响每个后续 RHCOS 引导。

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

警告

在创建连接配置文件时,您必须在连接配置文件的文件名中使用 .nmconnection 文件名扩展名。如果不使用 .nmconnection 文件名扩展,集群会将连接配置集应用到 live 环境,但它不会在集群首次启动节点时应用配置,从而导致无法正常工作的设置。

流程

  1. coreos-installer 镜像镜像页面下载 coreos-installer 二进制文件。
  2. 为绑定接口创建连接配置集。例如,在本地目录中创建 bond0.nmconnection 文件,其内容如下:

    [connection]
    id=bond0
    type=bond
    interface-name=bond0
    multi-connect=1
    
    [bond]
    miimon=100
    mode=active-backup
    
    [ipv4]
    method=auto
    
    [ipv6]
    method=auto
    Copy to Clipboard Toggle word wrap
  3. 为二级接口创建连接配置集,以添加到绑定中。例如,在本地目录中创建 bond0-proxy-em1.nmconnection 文件,其内容如下:

    [connection]
    id=em1
    type=ethernet
    interface-name=em1
    master=bond0
    multi-connect=1
    slave-type=bond
    Copy to Clipboard Toggle word wrap
  4. 为二级接口创建连接配置集,以添加到绑定中。例如,在本地目录中创建 bond0-proxy-em2.nmconnection 文件,其内容如下:

    [connection]
    id=em2
    type=ethernet
    interface-name=em2
    master=bond0
    multi-connect=1
    slave-type=bond
    Copy to Clipboard Toggle word wrap
  5. RHCOS 镜像镜像页面获取 RHCOS kernelinitramfsrootfs 文件,并运行以下命令来创建一个新的自定义 initramfs 文件,它包括您的配置网络:

    $ coreos-installer pxe customize rhcos-<version>-live-initramfs.x86_64.img \
        --network-keyfile bond0.nmconnection \
        --network-keyfile bond0-proxy-em1.nmconnection \
        --network-keyfile bond0-proxy-em2.nmconnection \
        -o rhcos-<version>-custom-initramfs.x86_64.img
    Copy to Clipboard Toggle word wrap
  6. 在 PXE 配置中使用自定义 initramfs 文件。添加 ignition.firstbootignition.platform.id=metal 内核参数(如果它们尚不存在)。

    网络设置应用于实时系统,并传输到目标系统。

您可以设置 iSCSI 目标和 initiator 值,以便使用自定义的 live RHCOS 镜像版本自动挂载、引导和配置。

先决条件

  1. 您有一个 iSCSI 目标,您要在其中安装 RHCOS。

流程

  1. coreos-installer 镜像镜像页面下载 coreos-installer 二进制文件。
  2. RHCOS image mirror 页获取 RHCOS kernelinitramfsrootfs 文件,并运行以下命令来使用以下信息创建新的自定义 initramfs 文件:

    $ coreos-installer pxe customize \
        --pre-install mount-iscsi.sh \ 
    1
    
        --post-install unmount-iscsi.sh \ 
    2
    
        --dest-device /dev/disk/by-path/<IP_address>:<port>-iscsi-<target_iqn>-lun-<lun> \ 
    3
    
        --dest-ignition config.ign \ 
    4
    
        --dest-karg-append rd.iscsi.initiator=<initiator_iqn> \ 
    5
    
        --dest-karg-append netroot=<target_iqn> \ 
    6
    
        -o custom.img rhcos-<version>-live-initramfs.x86_64.img
    Copy to Clipboard Toggle word wrap
    1
    安装之前运行的脚本。它应包含用于挂载 iSCSI 目标以及启用多路径的任何命令的 iscsiadm 命令。
    2
    安装后运行的脚本。它应包含命令 iscsiadm --mode node --logout=all
    3
    目标系统的位置。您必须提供目标门户的 IP 地址、关联的端口号、目标 iSCSI 节点采用 IQN 格式,以及 iSCSI 逻辑单元号(LUN)。
    4
    目标系统的 Ignition 配置。
    5
    iSCSI 启动器或客户端,以 IQN 格式的名称。启动器构成连接到 iSCSI 目标的一个会话。
    6
    iSCSI 目标或服务器的名称(IQN 格式)。

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

您可以设置 iSCSI 目标和 initiator 值,以便使用自定义的 live RHCOS 镜像版本自动挂载、引导和配置。

先决条件

  1. 您有一个 iSCSI 目标,您要在其中安装 RHCOS。
  2. 可选:有多路径 iSCSI 目标。

流程

  1. coreos-installer 镜像镜像页面下载 coreos-installer 二进制文件。
  2. RHCOS image mirror 页获取 RHCOS kernelinitramfsrootfs 文件,并运行以下命令来使用以下信息创建新的自定义 initramfs 文件:

    $ coreos-installer pxe customize \
        --pre-install mount-iscsi.sh \ 
    1
    
        --post-install unmount-iscsi.sh \ 
    2
    
        --dest-device /dev/mapper/mpatha \ 
    3
    
        --dest-ignition config.ign \ 
    4
    
        --dest-karg-append rd.iscsi.firmware=1 \ 
    5
    
        --dest-karg-append rd.multipath=default \ 
    6
    
        -o custom.img rhcos-<version>-live-initramfs.x86_64.img
    Copy to Clipboard Toggle word wrap
    1
    安装之前运行的脚本。它应包含用于挂载 iSCSI 目标的 iscsiadm 命令。
    2
    安装后运行的脚本。它应包含命令 iscsiadm --mode node --logout=all
    3
    设备的路径。如果连接了多个多路径设备,或者需要明确指定,您使用多路径(/dev/mapper/mpatha),您可以使用 /dev/disk/by-path 中可用的 World Wide Name (WWN) 符号链接。
    4
    目标系统的 Ignition 配置。
    5
    iSCSI 参数从 BIOS 固件读取。
    6
    可选:如果您要启用多路径,请包含此参数。

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

2.3.13.3.9. 高级 RHCOS 安装参考

本节演示了网络配置和其他高级选项,允许您修改 Red Hat Enterprise Linux CoreOS(RHCOS)手动安装过程。下表描述了您可以用于 RHCOS live 安装程序和 coreos-installer 命令的内核参数和命令行选项。

2.3.13.3.9.1. ISO 安装的网络和绑定选项

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

重要

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

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

注意

添加内核参数时顺序非常重要: ip=、name server=,然后 bond=

网络选项在系统引导过程中传递给 dracut 工具。有关 dracut 支持的网络选项的更多信息,请参阅 dracut.cmdline 手册页

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

2.3.13.3.9.1.1. 配置 DHCP 或静态 IP 地址

要配置 IP 地址,可使用 DHCP(ip=dhcp)或设置单独的静态 IP 地址(ip=<host_ip>)。如果设置静态 IP,则必须在每个节点上识别 DNS 服务器 IP 地址(名称服务器=<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
Copy to Clipboard Toggle word wrap
注意

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

2.3.13.3.9.1.2. 配置没有静态主机名的 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
Copy to Clipboard Toggle word wrap
2.3.13.3.9.1.3. 指定多个网络接口

您可以通过设置多个 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
Copy to Clipboard Toggle word wrap
2.3.13.3.9.1.4. 配置默认网关和路由

可选:您可以通过设置 a rd.route= 值来配置到额外网络的路由。

注意

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

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

    ip=::10.10.10.254::::
    Copy to Clipboard Toggle word wrap
  • 输入以下命令为额外网络配置路由:

    rd.route=20.20.20.0/24:20.20.20.254:enp2s0
    Copy to Clipboard Toggle word wrap
2.3.13.3.9.1.5. 在单个接口中禁用 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
Copy to Clipboard Toggle word wrap
2.3.13.3.9.1.6. 合并 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
Copy to Clipboard Toggle word wrap
2.3.13.3.9.1.7. 在独立接口上配置 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
    Copy to Clipboard Toggle word wrap
  • 要在网络接口中配置 VLAN 并使用 DHCP,请运行以下命令:

    ip=enp2s0.100:dhcp
    vlan=enp2s0.100:enp2s0
    Copy to Clipboard Toggle word wrap
2.3.13.3.9.1.8. 提供多个 DNS 服务器

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

nameserver=1.1.1.1
nameserver=8.8.8.8
Copy to Clipboard Toggle word wrap
2.3.13.3.9.1.9. 将多个网络接口绑定到一个接口

可选: 您可以使用 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
      Copy to Clipboard Toggle word wrap
    • 要将绑定接口配置为使用静态 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
      Copy to Clipboard Toggle word wrap

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

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

  1. 按照管理 SR-IOV 设备中的指导创建 SR-IOV 虚拟功能(VF)。按照"将 SR-IOV 网络设备附加到虚拟机"部分中的步骤操作。
  2. 创建绑定,将所需的 VF 附加到绑定,并根据配置网络绑定的指导设置绑定链接状态。按照任何描述的步骤创建绑定。

以下示例演示了您必须使用的语法:

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

    <name> 是绑定设备名称 (bond0)、<network_interfaces> 由内核中已知的名称来代表虚拟功能(VF),并显示在 ip link 命令的输出中 (eno1f0,eno2f0),options 是以逗号分隔的绑定选项列表。输入 modinfo bonding 查看可用选项。

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

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

      bond=bond0:eno1f0,eno2f0:mode=active-backup
      ip=bond0:dhcp
      Copy to Clipboard Toggle word wrap
    • 要将绑定接口配置为使用静态 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
      Copy to Clipboard Toggle word wrap
2.3.13.3.9.1.11. 使用网络团队

可选: 您可以使用 team= 参数来将网络团队用作绑定的替代选择:

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

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

注意

当 RHCOS 切换到即将推出的 RHEL 版本时,团队(team)功能被计划弃用。如需更多信息,请参阅红帽知识库文章

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

team=team0:em1,em2
ip=team0:dhcp
Copy to Clipboard Toggle word wrap
2.3.13.3.9.2. ISO 和 PXE 安装的 coreos-installer 选项

从 ISO 镜像引导 RHCOS live 环境后,您可以通过 在命令提示符下运行 coreos-installer install <options> <device > 来安装 RHCOS。

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

Expand
表 2.39. coreos-installer 子命令、命令行选项和参数

coreos-installer install 子命令

子命令

描述

$ coreos-installer install <options> <device>

在 ISO 镜像中嵌入 Ignition 配置。

coreos-installer install 子命令选项

选项

描述

-u, --image-url <url>

手动指定镜像 URL。

-f,--image-file <path>

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

-i, --ignition-file <path>

从文件中嵌入 Ignition 配置。

-i,--ignition-url <URL>

从 URL 嵌入 Ignition 配置。

--ignition-hash <digest>

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

-p, --platform <name>

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

--console <spec>

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

--append-karg <arg>…​

将默认内核参数附加到安装的系统中。

--delete-karg <arg>…​

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

-n, --copy-network

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

重要

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

--network-dir <path>

用于 -n。默认为 /etc/NetworkManager/system-connections/

--save-partlabel <lx>..

使用这个标签 glob 保存分区。

--save-partindex <id>…​

使用这个数值或范围保存分区。

--insecure

跳过 RHCOS 镜像签名验证。

--insecure-ignition

允许没有 HTTPS 或 hash 的 Ignition URL。

--architecture <name>

目标 CPU 架构.有效值为 x86_64aarch64

--preserve-on-error

出错时不要清除分区表。

-h,--help

打印帮助信息.

coreos-installer install 子命令参数

参数

描述

<device>

目标设备.

coreos-installer ISO 子命令

子命令

描述

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

自定义 RHCOS live ISO 镜像。

coreos-installer iso reset <options> <ISO_image>

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

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

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

coreos-installer ISO customize 子命令选项

选项

描述

--dest-ignition <path>

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

--dest-console <spec>

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

--dest-device <path>

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

--dest-karg-append <arg>

为每个目标系统引导添加一个内核参数。

--dest-karg-delete <arg>

从目标系统的每个引导中删除内核参数。

--network-keyfile <path>

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

--ignition-ca <path>

指定要被 Ignition 信任的额外 TLS 证书颁发机构。

--pre-install <path>

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

--post-install <path>

安装后运行指定的脚本。

--installer-config <path>

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

--live-ignition <path>

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

--live-karg-append <arg>

为每个实时环境引导添加一个内核参数。

--live-karg-delete <arg>

从实时环境每次引导时删除内核参数。

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

在每次启动 live 环境时替换内核参数,格式为 key=old=new

-f,--force

覆盖现有的 Ignition 配置。

-o,--output <path>

将 ISO 写入到新的输出文件。

-h,--help

打印帮助信息.

coreos-installer PXE 子命令

子命令

描述

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

coreos-installer pxe customize <options> <path>

自定义 RHCOS live PXE 引导配置。

coreos-installer pxe ignition wrap <options>

在镜像中嵌套 Ignition 配置。

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

在镜像中显示嵌套的 Ignition 配置。

coreos-installer PXE customize 子命令选项

选项

描述

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

--dest-ignition <path>

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

--dest-console <spec>

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

--dest-device <path>

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

--network-keyfile <path>

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

--ignition-ca <path>

指定要被 Ignition 信任的额外 TLS 证书颁发机构。

--pre-install <path>

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

post-install <path>

安装后运行指定的脚本。

--installer-config <path>

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

--live-ignition <path>

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

-o, --output <path>

将 initramfs 写入一个新输出文件。

注意

PXE 环境需要这个选项。

-h,--help

打印帮助信息.

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

  • 对于 ISO 安装,可以通过在启动加载器菜单中中断自动引导来添加 coreos.inst 选项。您可以在突出显示 RHEL CoreOS(Live) 菜单选项时按 TAB 来中断自动引导。
  • 对于 PXE 或 iPXE 安装,在引导 RHCOS live 安装程序前,coreos.inst 选项必须添加到 APPEND 行。

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

Expand
表 2.40. coreos.inst 引导选项
参数描述

coreos.inst.install_dev

必需。要安装到的系统中的块设备。

注意

建议您使用完整路径,如 /dev/sda,但 允许使用

coreos.inst.ignition_url

可选:嵌入到安装的系统中的 Ignition 配置的 URL。如果没有指定 URL,则不会嵌入 Ignition 配置。仅支持 HTTP 和 HTTPS 协议。

coreos.inst.save_partlabel

可选:在安装过程中要保留的分区分离标签。允许使用 glob 风格的通配符。指定分区不需要存在。

coreos.inst.save_partindex

可选:在安装过程中压缩要保留的分区索引。允许 m-n 范围,mn 可以被省略。指定分区不需要存在。

coreos.inst.insecure

可选:将 coreos.inst.image_url 指定的 OS 镜像提交取消签名。

coreos.inst.image_url

可选:下载并安装指定的 RHCOS 镜像。

  • 这个参数不应该在生产环境中使用,而是只用于调试目的。
  • 虽然此参数可用于安装与 live 介质不匹配的 RHCOS 版本,但建议您使用与您要安装版本匹配的介质。
  • 如果您使用 coreos.inst.image_url,还必须使用 coreos.inst.insecure。这是因为,裸机介质没有为 OpenShift Container Platform 进行 GPG 签名。
  • 仅支持 HTTP 和 HTTPS 协议。

coreos.inst.skip_reboot

可选:安装后系统不会重启。安装完成后,您将收到提示,提示您检查在安装过程中发生的情况。这个参数不应该在生产环境中使用,而是只用于调试目的。

coreos.inst.platform_id

可选:安装 RHCOS 镜像的平台的 Ignition 平台 ID。默认为 metal。这个选项决定是否从云供应商(如 VMware)请求 Ignition 配置。例如: coreos.inst.platform_id=vmware

ignition.config.url

可选:用于实时引导的 Ignition 配置的 URL。例如,这可用于自定义调用 coreos-installer 的方式,或者用于在安装前或安装后运行代码。这与 coreos.inst.ignition_url (这是已安装系统的 Ignition 配置)不同。

2.3.13.4. 在 RHCOS 上启用带有内核参数的多路径

RHCOS 支持主磁盘上的多路径,支持更强大的硬件故障弹性,以获得更高的主机可用性。

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

在任何 I/O 到未优化路径会导致 I/O 系统错误的设置中,您必须在安装时启用多路径。

重要

在 IBM Z® 和 IBM® LinuxONE 中,您只能在在安装过程中为它配置集群时启用多路径。如需更多信息,请参阅在 IBM Z® 和 IBM® LinuxONE 上安装使用 z/VM 的集群"安装 RHCOS 并启动 OpenShift Container Platform bootstrap 过程"。

以下流程在安装时启用多路径,并在 coreos-installer install 命令中附加内核参数,以便安装的系统本身将使用从第一次引导开始的多路径。

注意

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

先决条件

  • 已为集群创建 Ignition 配置文件。
  • 您已参阅 安装 RHCOS 并启动 OpenShift Container Platform bootstrap 过程

流程

  1. 要启用多路径并启动 multipathd 守护进程,请在安装主机上运行以下命令:

    $ mpathconf --enable && systemctl start multipathd.service
    Copy to Clipboard Toggle word wrap
    • 可选:如果引导 PXE 或 ISO,则可以通过从内核命令行添加 rd.multipath=default 来启用多路径。
  2. 通过调用 coreos-installer 程序附加内核参数:

    • 如果只有一个多路径设备连接到计算机,则应在路径 /dev/mapper/mpatha 上可用。例如:

      $ coreos-installer install /dev/mapper/mpatha \
      1
      
      --ignition-url=http://host/worker.ign \
      --append-karg rd.multipath=default \
      --append-karg root=/dev/disk/by-label/dm-mpath-root \
      --append-karg rw \
      --offline
      Copy to Clipboard Toggle word wrap
      1
      表示单一多路径设备的路径。
    • 如果有多个多路径设备连接到计算机,或者更为明确,而不是使用 /dev/mapper/mpatha,则建议使用 /dev/disk/by-id 中可用的 World Wide Name(WWN)符号链接。例如:

      $ coreos-installer install /dev/disk/by-id/wwn-<wwn_ID> \
      1
      
      --ignition-url=http://host/worker.ign \
      --append-karg rd.multipath=default \
      --append-karg root=/dev/disk/by-label/dm-mpath-root \
      --append-karg rw \
      --offline
      Copy to Clipboard Toggle word wrap
      1
      表示目标多路径设备的 WWN ID。例如: 0xx194e957fcedb4841

      当使用特殊 coreos.inst.* 参数指示 live 安装程序时,这个符号链接也可以用作 coreos.inst.install_dev 内核参数。如需更多信息,请参阅"安装 RHCOS 和启动 OpenShift Container Platform bootstrap 过程"。

  3. 重启安装的系统。
  4. 前往其中一个 worker 节点并列出内核命令行参数(主机上的 /proc/cmdline 中),以检查内核参数是否正常工作:

    $ oc debug node/ip-10-0-141-105.ec2.internal
    Copy to Clipboard Toggle word wrap

    输出示例

    Starting pod/ip-10-0-141-105ec2internal-debug ...
    To use host binaries, run `chroot /host`
    
    sh-4.2# cat /host/proc/cmdline
    ...
    rd.multipath=default root=/dev/disk/by-label/dm-mpath-root
    ...
    
    sh-4.2# exit
    Copy to Clipboard Toggle word wrap

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

2.3.13.4.1. 在辅助磁盘中启用多路径

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

先决条件

  • 您已阅读了磁盘分区一节。
  • 您已在 RHCOS 中使用内核参数读取启用多路径
  • 已安装 Butane 工具。

流程

  1. 使用类似如下的信息创建一个 Butane 配置:

    multipath-config.bu 示例

    variant: openshift
    version: 4.19.0
    systemd:
      units:
        - name: mpath-configure.service
          enabled: true
          contents: |
            [Unit]
            Description=Configure Multipath on Secondary Disk
            ConditionFirstBoot=true
            ConditionPathExists=!/etc/multipath.conf
            Before=multipathd.service 
    1
    
            DefaultDependencies=no
    
            [Service]
            Type=oneshot
            ExecStart=/usr/sbin/mpathconf --enable 
    2
    
    
            [Install]
            WantedBy=multi-user.target
        - name: mpath-var-lib-container.service
          enabled: true
          contents: |
            [Unit]
            Description=Set Up Multipath On /var/lib/containers
            ConditionFirstBoot=true 
    3
    
            Requires=dev-mapper-mpatha.device
            After=dev-mapper-mpatha.device
            After=ostree-remount.service
            Before=kubelet.service
            DefaultDependencies=no
    
            [Service] 
    4
    
            Type=oneshot
            ExecStart=/usr/sbin/mkfs.xfs -L containers -m reflink=1 /dev/mapper/mpatha
            ExecStart=/usr/bin/mkdir -p /var/lib/containers
    
            [Install]
            WantedBy=multi-user.target
        - name: var-lib-containers.mount
          enabled: true
          contents: |
            [Unit]
            Description=Mount /var/lib/containers
            After=mpath-var-lib-containers.service
            Before=kubelet.service 
    5
    
    
            [Mount] 
    6
    
            What=/dev/disk/by-label/dm-mpath-containers
            Where=/var/lib/containers
            Type=xfs
    
            [Install]
            WantedBy=multi-user.target
    Copy to Clipboard Toggle word wrap

    1
    在启动 multipath 守护进程前,必须设置配置。
    2
    启动 mpathconf 实用程序。
    3
    此字段必须设置为 true
    4
    创建文件系统和目录 /var/lib/containers
    5
    在启动任何节点前必须挂载该设备。
    6
    将设备挂载到 /var/lib/containers 挂载点。此位置不能是符号链接。
  2. 运行以下命令来创建 Ignition 配置:

    $ butane --pretty --strict multipath-config.bu > multipath-config.ign
    Copy to Clipboard Toggle word wrap
  3. 继续第一个引导 RHCOS 安装过程的其余部分。

    重要

    不要在安装过程中在命令行上添加 rd.multipathroot 内核参数,除非主磁盘也是多路径的。

2.3.13.5. 在 iSCSI 引导设备中手动安装 RHCOS

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

先决条件

  1. 您在 RHCOS live 环境中。
  2. 您有一个要在其上安装 RHCOS 的 iSCSI 目标。

流程

  1. 运行以下命令,从 live 环境中挂载 iSCSI 目标:

    $ iscsiadm \
        --mode discovery \
        --type sendtargets
        --portal <IP_address> \ 
    1
    
        --login
    Copy to Clipboard Toggle word wrap
    1
    目标门户的 IP 地址。
  2. 运行以下命令并使用必要的内核参数将 RHCOS 安装到 iSCSI 目标上,例如:

    $ coreos-installer install \
    /dev/disk/by-path/ip-<IP_address>:<port>-iscsi-<target_iqn>-lun-<lun> \ 
    1
    
    --append-karg rd.iscsi.initiator=<initiator_iqn> \ 
    2
    
    --append.karg netroot=<target_iqn> \ 
    3
    
    --console ttyS0,115200n8 \
    --ignition-file <path_to_file> \
    --offline
    Copy to Clipboard Toggle word wrap
    1
    您要安装到的位置。您必须提供目标门户的 IP 地址、关联的端口号、目标 iSCSI 节点采用 IQN 格式,以及 iSCSI 逻辑单元号(LUN)。
    2
    iSCSI 启动器或客户端,以 IQN 格式的名称。启动器构成连接到 iSCSI 目标的一个会话。
    3
    iSCSI 目标或服务器的名称(IQN 格式)。

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

  3. 使用以下命令卸载 iSCSI 磁盘:

    $ iscsiadm --mode node --logoutall=all
    Copy to Clipboard Toggle word wrap

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

2.3.13.6. 使用 iBFT 在 iSCSI 引导设备中安装 RHCOS

在一个完全无盘机器上,也可以通过 iBFT. iSCSI 多路径传递 iSCSI 目标和启动器值。

先决条件

  1. 您在 RHCOS live 环境中。
  2. 您有一个 iSCSI 目标,您要在其中安装 RHCOS。
  3. 可选:有多路径 iSCSI 目标。

流程

  1. 运行以下命令,从 live 环境中挂载 iSCSI 目标:

    $ iscsiadm \
        --mode discovery \
        --type sendtargets
        --portal <IP_address> \ 
    1
    
        --login
    Copy to Clipboard Toggle word wrap
    1
    目标门户的 IP 地址。
  2. 可选:使用以下命令启用多路径并启动守护进程:

    $ mpathconf --enable && systemctl start multipathd.service
    Copy to Clipboard Toggle word wrap
  3. 运行以下命令并使用必要的内核参数将 RHCOS 安装到 iSCSI 目标上,例如:

    $ coreos-installer install \
        /dev/mapper/mpatha \ 
    1
    
        --append-karg rd.iscsi.firmware=1 \ 
    2
    
        --append-karg rd.multipath=default \ 
    3
    
        --console ttyS0 \
        --ignition-file <path_to_file> \
        --offline
    Copy to Clipboard Toggle word wrap
    1
    单一多路径设备的路径。如果连接了多个多路径设备,或者需要明确指定,您可以使用 /dev/disk/by-path 中可用的 World Wide Name (WWN) 符号链接。
    2
    iSCSI 参数从 BIOS 固件读取。
    3
    可选:如果您要启用多路径,请包含此参数。

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

  4. 卸载 iSCSI 磁盘:

    $ iscsiadm --mode node --logout=all
    Copy to Clipboard Toggle word wrap

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

2.3.14. 等待 bootstrap 过程完成

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

先决条件

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

流程

  1. 监控 bootstrap 过程:

    $ ./openshift-install --dir <installation_directory> wait-for bootstrap-complete \ 
    1
    
        --log-level=info 
    2
    Copy to Clipboard Toggle word wrap
    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.32.3 up
    INFO Waiting up to 30m0s for bootstrapping to complete...
    INFO It is now safe to remove the bootstrap resources
    Copy to Clipboard Toggle word wrap

    当 Kubernetes API 服务器提示已在 control plane 机器上引导它时,该命令会成功。

  2. bootstrap 过程完成后,从负载均衡器中删除 bootstrap 机器。

    重要

    此时您必须从负载均衡器中删除 bootstrap 机器。您还可以删除或重新格式化 bootstrap 机器本身。

2.3.15. 使用 CLI 登录集群

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

先决条件

  • 已部署 OpenShift Container Platform 集群。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 运行以下命令来导出 kubeadmin 凭证:

    $ export KUBECONFIG=<installation_directory>/auth/kubeconfig 
    1
    Copy to Clipboard Toggle word wrap
    1
    对于 <installation_directory>,请指定安装文件保存到的目录的路径。
  2. 运行以下命令,使用导出的配置成功运行 oc 命令:

    $ oc whoami
    Copy to Clipboard Toggle word wrap

    输出示例

    system:admin
    Copy to Clipboard Toggle word wrap

2.3.16. 批准机器的证书签名请求

当您将机器添加到集群时,会为您添加的每台机器生成两个待处理证书签名请求(CSR)。您必须确认这些 CSR 已获得批准,或根据需要自行批准。必须首先批准客户端请求,然后批准服务器请求。

先决条件

  • 您已将机器添加到集群中。

流程

  1. 确认集群可以识别这些机器:

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME      STATUS    ROLES   AGE  VERSION
    master-0  Ready     master  63m  v1.32.3
    master-1  Ready     master  63m  v1.32.3
    master-2  Ready     master  64m  v1.32.3
    Copy to Clipboard Toggle word wrap

    输出中列出了您创建的所有机器。

    注意

    在有些 CSR 被批准前,前面的输出可能不包括计算节点(也称为 worker 节点)。

  2. 检查待处理的 CSR,并确保添加到集群中的每台机器都有 PendingApproved 状态的客户端请求:

    $ oc get csr
    Copy to Clipboard Toggle word wrap

    输出示例

    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
    ...
    Copy to Clipboard Toggle word wrap

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

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

    注意

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

    注意

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

    • 要单独批准,请对每个有效的 CSR 运行以下命令:

      $ oc adm certificate approve <csr_name> 
      1
      Copy to Clipboard Toggle word wrap
      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
      Copy to Clipboard Toggle word wrap
      注意

      在有些 CSR 被批准前,一些 Operator 可能无法使用。

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

    $ oc get csr
    Copy to Clipboard Toggle word wrap

    输出示例

    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
    ...
    Copy to Clipboard Toggle word wrap

  5. 如果剩余的 CSR 没有被批准,且处于 Pending 状态,请批准集群机器的 CSR:

    • 要单独批准,请对每个有效的 CSR 运行以下命令:

      $ oc adm certificate approve <csr_name> 
      1
      Copy to Clipboard Toggle word wrap
      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
      Copy to Clipboard Toggle word wrap
  6. 批准所有客户端和服务器 CSR 后,机器将 处于 Ready 状态。运行以下命令验证:

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME      STATUS    ROLES   AGE  VERSION
    master-0  Ready     master  73m  v1.32.3
    master-1  Ready     master  73m  v1.32.3
    master-2  Ready     master  74m  v1.32.3
    worker-0  Ready     worker  11m  v1.32.3
    worker-1  Ready     worker  11m  v1.32.3
    Copy to Clipboard Toggle word wrap

    注意

    批准服务器 CSR 后可能需要几分钟时间让机器过渡到 Ready 状态

其他信息

2.3.17. 初始 Operator 配置

在 control plane 初始化后,您必须立即配置一些 Operator,以便它们都可用。

先决条件

  • 您的 control plane 已初始化。

流程

  1. 观察集群组件上线:

    $ watch -n5 oc get clusteroperators
    Copy to Clipboard Toggle word wrap

    输出示例

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

  2. 配置不可用的 Operator。
2.3.17.1. 禁用默认的 OperatorHub 目录源

在 OpenShift Container Platform 安装过程中,默认为 OperatorHub 配置由红帽和社区项目提供的源内容的 operator 目录。在受限网络环境中,必须以集群管理员身份禁用默认目录。

流程

  • 通过在 OperatorHub 对象中添加 disableAllDefaultSources: true 来 禁用默认目录的源:

    $ oc patch OperatorHub cluster --type json \
        -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'
    Copy to Clipboard Toggle word wrap
提示

或者,您可以使用 Web 控制台管理目录源。在 AdministrationCluster SettingsConfigurationOperatorHub 页面中,点 Sources 选项卡,您可以在其中创建、更新、删除、禁用和启用单独的源。

2.3.17.2. 镜像 registry 存储配置

对于不提供默认存储的平台,Image Registry Operator 最初不可用。安装后,您必须将 registry 配置为使用存储,以便 Registry Operator 可用。

显示配置生产集群所需的持久性卷的说明。如果适用,显示有关将空目录配置为存储位置的说明,这仅适用于非生产集群。

提供了在升级过程中使用 Recreate rollout 策略来允许镜像 registry 使用块存储类型的说明。

2.3.17.2.1. 更改镜像 registry 的管理状态

要启动镜像 registry,您必须将 Image Registry Operator 配置的 managementStateRemoved 改为 Managed

流程

  • managementState Image Registry Operator 配置从 Removed 改为 Managed。例如:

    $ oc patch configs.imageregistry.operator.openshift.io cluster --type merge --patch '{"spec":{"managementState":"Managed"}}'
    Copy to Clipboard Toggle word wrap

作为集群管理员,在安装后需要配置 registry 来使用存储。

先决条件

  • 您可以使用具有 cluster-admin 角色的用户访问集群。
  • 您有一个使用手动置备的 Red Hat Enterprise Linux CoreOS(RHCOS)节点(如裸机)的集群。
  • 您已为集群置备持久性存储,如 Red Hat OpenShift Data Foundation。

    重要

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

  • 必须具有 100Gi 容量。

流程

  1. 要将 registry 配置为使用存储,修改 configs.imageregistry/cluster 资源中的 spec.storage.pvc

    注意

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

  2. 验证您没有 registry pod:

    $ oc get pod -n openshift-image-registry -l docker-registry=default
    Copy to Clipboard Toggle word wrap

    输出示例

    No resources found in openshift-image-registry namespace
    Copy to Clipboard Toggle word wrap

    注意

    如果您的输出中有一个 registry pod,则不需要继续这个过程。

  3. 检查 registry 配置:

    $ oc edit configs.imageregistry.operator.openshift.io
    Copy to Clipboard Toggle word wrap

    输出示例

    storage:
      pvc:
        claim:
    Copy to Clipboard Toggle word wrap

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

  4. 检查 clusteroperator 状态:

    $ oc get clusteroperator image-registry
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME             VERSION              AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
    image-registry   4.19                 True        False         False      6h50m
    Copy to Clipboard Toggle word wrap

  5. 确保 registry 设置为 managed,以启用镜像的构建和推送。

    • 运行:

      $ oc edit configs.imageregistry/cluster
      Copy to Clipboard Toggle word wrap

      然后,更改行

      managementState: Removed
      Copy to Clipboard Toggle word wrap

      managementState: Managed
      Copy to Clipboard Toggle word wrap

您必须为 Image Registry Operator 配置存储。对于非生产集群,您可以将镜像 registry 设置为空目录。如果您这样做,重启 registry 时会丢失所有镜像。

流程

  • 将镜像 registry 存储设置为空目录:

    $ oc patch configs.imageregistry.operator.openshift.io cluster --type merge --patch '{"spec":{"storage":{"emptyDir":{}}}}'
    Copy to Clipboard Toggle word wrap
    警告

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

    如果在 Image Registry Operator 初始化其组件前运行这个命令,oc patch 命令会失败并显示以下错误:

    Error from server (NotFound): configs.imageregistry.operator.openshift.io "cluster" not found
    Copy to Clipboard Toggle word wrap

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

2.3.17.2.4. 为裸机配置块 registry 存储

要允许镜像 registry 在作为集群管理员升级过程中使用块存储类型,您可以使用 Recreate rollout 策略

重要

支持块存储卷或块持久性卷,但不建议在生产环境中使用镜像 registry。在块存储上配置 registry 的安装不具有高可用性,因为 registry 无法具有多个副本。

如果您选择将块存储卷与镜像 registry 搭配使用,则必须使用文件系统持久性卷声明(PVC)。

流程

  1. 输入以下命令将镜像 registry 存储设置为块存储类型,对 registry 进行补丁,使其使用 Recreate rollout 策略,并只使用一个副本运行:1

    $ oc patch config.imageregistry.operator.openshift.io/cluster --type=merge -p '{"spec":{"rolloutStrategy":"Recreate","replicas":1}}'
    Copy to Clipboard Toggle word wrap
  2. 为块存储设备置备 PV,并为该卷创建 PVC。请求的块卷使用 ReadWriteOnce(RWO)访问模式。

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

      kind: PersistentVolumeClaim
      apiVersion: v1
      metadata:
        name: image-registry-storage 
      1
      
        namespace: openshift-image-registry 
      2
      
      spec:
        accessModes:
        - ReadWriteOnce 
      3
      
        resources:
          requests:
            storage: 100Gi 
      4
      Copy to Clipboard Toggle word wrap
      1
      代表 PersistentVolumeClaim 对象的唯一名称。
      2
      PersistentVolumeClaim 对象的命名空间,即 openshift-image-registry
      3
      持久性卷声明的访问模式。使用 ReadWriteOnce 时,单个节点可以通过读写权限挂载该卷。
      4
      持久性卷声明的大小。
    2. 输入以下命令从文件创建 PersistentVolumeClaim 对象:

      $ oc create -f pvc.yaml -n openshift-image-registry
      Copy to Clipboard Toggle word wrap
  3. 输入以下命令编辑 registry 配置,使其引用正确的 PVC:

    $ oc edit config.imageregistry.operator.openshift.io -o yaml
    Copy to Clipboard Toggle word wrap

    输出示例

    storage:
      pvc:
        claim: 
    1
    Copy to Clipboard Toggle word wrap

    1
    通过创建自定义 PVC,您可以将 claim 字段留空,以便默认自动创建 image-registry-storage PVC。

2.3.18. 在用户置备的基础架构上完成安装

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

先决条件

  • 您的 control plane 已初始化。
  • 已完成初始 Operator 配置。

流程

  1. 使用以下命令确认所有集群组件都在线:

    $ watch -n5 oc get clusteroperators
    Copy to Clipboard Toggle word wrap

    输出示例

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

    另外,当所有集群都可用时,以下命令会通知您。它还检索并显示凭证:

    $ ./openshift-install --dir <installation_directory> wait-for install-complete 
    1
    Copy to Clipboard Toggle word wrap
    1
    对于 <installation_directory>,请指定安装文件保存到的目录的路径。

    输出示例

    INFO Waiting up to 30m0s for the cluster to initialize...
    Copy to Clipboard Toggle word wrap

    Cluster Version Operator 完成从 Kubernetes API 服务器部署 OpenShift Container Platform 集群时,该命令会成功。

    重要
    • 安装程序生成的 Ignition 配置文件包含 24 小时后过期的证书,然后在该时进行续订。如果在更新证书前关闭集群,且集群在 24 小时后重启,集群会自动恢复过期的证书。一个例外是,您必须手动批准待处理的 node-bootstrapper 证书签名请求(CSR)来恢复 kubelet 证书。如需更多信息,请参阅从过期的 control plane 证书 中恢复的文档。
    • 建议您在 Ignition 配置文件生成后的 12 小时内使用它们,因为 24 小时的证书会在集群安装后的 16 小时到 22 小时间进行轮转。通过在 12 小时内使用 Ignition 配置文件,您可以避免在安装过程中因为执行了证书更新而导致安装失败的问题。
  2. 确认 Kubernetes API 服务器正在与 pod 通信。

    1. 要查看所有 pod 的列表,请使用以下命令:

      $ oc get pods --all-namespaces
      Copy to Clipboard Toggle word wrap

      输出示例

      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
      ...
      Copy to Clipboard Toggle word wrap

    2. 使用以下命令,查看上一命令的输出中所列 pod 的日志:

      $ oc logs <pod_name> -n <namespace> 
      1
      Copy to Clipboard Toggle word wrap
      1
      指定 pod 名称和命名空间,如上一命令的输出中所示。

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

  3. 对于使用光纤通道协议(FCP)的安装,还需要额外的步骤才能启用多路径。不要在安装过程中启用多路径。

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

  4. Cluster registration 页面注册 您的集群。

2.3.19. OpenShift Container Platform 的 Telemetry 访问

在 OpenShift Container Platform 4.19 中,默认运行的 Telemetry 服务提供有关集群健康状况和成功更新的指标,需要访问互联网。如果您的集群连接到互联网,Telemetry 会自动运行,而且集群会注册到 OpenShift Cluster Manager

确认 OpenShift Cluster Manager 清单正确后,可以由 Telemetry 自动维护,也可以使用 OpenShift Cluster Manager 手动维护,使用订阅监控来跟踪帐户或多集群级别的 OpenShift Container Platform 订阅。

2.3.20. 后续步骤

2.4. 使用 Bare Metal Operator 扩展用户置备的集群

部署用户置备的基础架构集群后,您可以使用 Bare Metal Operator (BMO)和其他裸机3 组件来扩展集群中的裸机主机。这种方法可帮助您以更自动化的方式扩展用户置备的集群。

您可以使用 Bare Metal Operator (BMO)和其他裸机3 组件扩展用户置备的基础架构集群。用户置备的基础架构安装不支持 Machine API Operator。Machine API Operator 通常管理集群中裸机节点的生命周期。但是,可以使用 BMO 和其他裸机3 组件在用户置备的集群中扩展节点,而无需 Machine API Operator。

2.4.1.1. 扩展用户置备的集群的先决条件
  • 您在裸机上安装了用户置备的基础架构集群。
  • 您有到主机的基板管理控制器 (BMC) 访问权限。
2.4.1.2. 扩展用户置备的集群的限制
  • 您不能使用 provisioning 网络来扩展用户置备的基础架构集群,使用 Bare Metal Operator (BMO)。

    • 因此,您只能使用支持虚拟介质网络的裸机主机驱动程序,如 redfish-virtualmediaidrac-virtualmedia
  • 您不能使用 BMO 在用户置备的基础架构集群中扩展 MachineSet 对象。

2.4.2. 配置置备资源以扩展用户置备的集群

创建 Provisioning 自定义资源 (CR),以便在用户置备的基础架构集群中启用裸机平台组件。

先决条件

  • 您在裸机上安装了用户置备的基础架构集群。

流程

  1. 创建 Provisioning CR。

    1. 将以下 YAML 保存到 provisioning.yaml 文件中:

      apiVersion: metal3.io/v1alpha1
      kind: Provisioning
      metadata:
        name: provisioning-configuration
      spec:
        provisioningNetwork: "Disabled"
        watchAllNamespaces: false
      Copy to Clipboard Toggle word wrap
      注意

      在使用 Bare Metal Operator 扩展用户置备的集群时,OpenShift Container Platform 4.19 不支持启用 provisioning 网络。

  2. 运行以下命令来创建 Provisioning CR:

    $ oc create -f provisioning.yaml
    Copy to Clipboard Toggle word wrap

    输出示例

    provisioning.metal3.io/provisioning-configuration created
    Copy to Clipboard Toggle word wrap

验证

  • 运行以下命令验证置备服务是否正在运行:

    $ oc get pods -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME                                                  READY   STATUS    RESTARTS        AGE
    cluster-autoscaler-operator-678c476f4c-jjdn5          2/2     Running   0               5d21h
    cluster-baremetal-operator-6866f7b976-gmvgh           2/2     Running   0               5d21h
    control-plane-machine-set-operator-7d8566696c-bh4jz   1/1     Running   0               5d21h
    ironic-proxy-64bdw                                    1/1     Running   0               5d21h
    ironic-proxy-rbggf                                    1/1     Running   0               5d21h
    ironic-proxy-vj54c                                    1/1     Running   0               5d21h
    machine-api-controllers-544d6849d5-tgj9l              7/7     Running   1 (5d21h ago)   5d21h
    machine-api-operator-5c4ff4b86d-6fjmq                 2/2     Running   0               5d21h
    metal3-6d98f84cc8-zn2mx                               5/5     Running   0               5d21h
    metal3-image-customization-59d745768d-bhrp7           1/1     Running   0               5d21h
    Copy to Clipboard Toggle word wrap

您可以通过创建一个 BareMetalHost 自定义资源 (CR),使用 Bare Metal Operator (BMO) 在用户置备的集群中置备裸机主机。

注意

使用 BMO 在集群中置备裸机主机将 BareMetalHost 自定义资源中的 spec.externallyProvisioned 规格默认设置为 false。不要将 spec.externallyProvisioned 规格设置为 true,因为此设置会导致意外行为。

先决条件

  • 您创建了用户置备的裸机集群。
  • 您有到主机的基板管理控制器 (BMC) 访问权限。
  • 通过创建一个 Provisioning CR,在集群中部署了置备服务。

流程

  1. 为裸机节点创建配置文件。根据您使用静态配置或 DHCP 服务器,请选择以下示例 bmh.yaml 文件之一,并通过替换 YAML 中的值来根据您的需要进行配置:

    • 要使用静态配置进行部署,请创建以下 bmh.yaml 文件:

      ---
      apiVersion: v1
      kind: Secret
      metadata:
        name: openshift-worker-<num>-network-config-secret 
      1
      
        namespace: openshift-machine-api
      type: Opaque
      stringData:
        nmstate: | 
      2
      
          interfaces: 
      3
      
          - name: <nic1_name> 
      4
      
            type: ethernet
            state: up
            ipv4:
              address:
              - ip: <ip_address> 
      5
      
                prefix-length: 24
              enabled: true
          dns-resolver:
            config:
              server:
              - <dns_ip_address> 
      6
      
          routes:
            config:
            - destination: 0.0.0.0/0
              next-hop-address: <next_hop_ip_address> 
      7
      
              next-hop-interface: <next_hop_nic1_name> 
      8
      
      ---
      apiVersion: v1
      kind: Secret
      metadata:
        name: openshift-worker-<num>-bmc-secret
        namespace: openshift-machine-api
      type: Opaque
      data:
        username: <base64_of_uid> 
      9
      
        password: <base64_of_pwd>
      ---
      apiVersion: metal3.io/v1alpha1
      kind: BareMetalHost
      metadata:
        name: openshift-worker-<num>
        namespace: openshift-machine-api
      spec:
        online: true
        bootMACAddress: <nic1_mac_address> 
      10
      
        bmc:
          address: <protocol>://<bmc_url> 
      11
      
          credentialsName: openshift-worker-<num>-bmc-secret
          disableCertificateVerification: false
        customDeploy:
          method: install_coreos
        userData:
          name: worker-user-data-managed
          namespace: openshift-machine-api
        rootDeviceHints:
          deviceName: <root_device_hint> 
      12
      
        preprovisioningNetworkDataName: openshift-worker-<num>-network-config-secret
      Copy to Clipboard Toggle word wrap
      1
      <num> 的所有实例替换为用于裸机节点的唯一的计算节点名称(在 name, credentialsName, 和 preprovisioningNetworkDataName 字段中)。
      2
      添加 NMState YAML 语法来配置主机接口。要为新创建的节点配置网络接口,请指定具有网络配置的 secret 名称。按照 nmstate 语法为节点定义网络配置。有关配置 NMState 语法的详情,请参阅"准备裸机节点"。
      3
      可选:如果您使用 nmstate 配置网络接口,并且您要禁用接口,请将 state: 设置为 enabled: false
      4
      <nic1_name> 替换为裸机节点的第一个网络接口控制器(NIC)的名称。
      5
      <ip_address> 替换为裸机节点 NIC 的 IP 地址。
      6
      <dns_ip_address> 替换为裸机节点 DNS 解析器的 IP 地址。
      7
      <next_hop_ip_address> 替换为裸机节点外部网关的 IP 地址。
      8
      <next_hop_nic1_name> 替换为裸机节点的外部网关的名称。
      9
      <base64_of_uid><base64_of_pwd> 替换为用户名和密码的 base64 字符串。
      10
      <nic1_mac_address> 替换为裸机节点第一个 NIC 的 MAC 地址。如需了解更多 BMC 配置选项,请参阅"BMC 寻址"部分。
      11
      <protocol> 替换为 BMC 协议,如 IPMI、Redfish 或其他。将 <bmc_url> 替换为裸机节点基板管理控制器的 URL。
      12
      可选:如果您指定了 root 设备提示,将 <root_device_hint> 替换为设备路径。详情请查看"Root 设备提示"。
    • 当使用 nmstate 配置带有静态配置的网络接口时,将 state: 设置为 enabled: false

      ---
      apiVersion: v1
      kind: Secret
      metadata:
        name: openshift-worker-<num>-network-config-secret
        namespace: openshift-machine-api
       # ...
      interfaces:
        - name: <nic_name>
          type: ethernet
          state: up
          ipv4:
            enabled: false
          ipv6:
            enabled: false
      # ...
      Copy to Clipboard Toggle word wrap
    • 要使用 DHCP 配置进行部署,请创建以下 bmh.yaml 文件:

      ---
      apiVersion: v1
      kind: Secret
      metadata:
        name: openshift-worker-<num>-bmc-secret 
      1
      
        namespace: openshift-machine-api
      type: Opaque
      data:
        username: <base64_of_uid> 
      2
      
        password: <base64_of_pwd>
      ---
      apiVersion: metal3.io/v1alpha1
      kind: BareMetalHost
      metadata:
        name: openshift-worker-<num>
        namespace: openshift-machine-api
      spec:
        online: true
        bootMACAddress: <nic1_mac_address> 
      3
      
        bmc:
          address: <protocol>://<bmc_url> 
      4
      
          credentialsName: openshift-worker-<num>-bmc
          disableCertificateVerification: false
        customDeploy:
          method: install_coreos
        userData:
          name: worker-user-data-managed
          namespace: openshift-machine-api
        rootDeviceHints:
          deviceName: <root_device_hint> 
      5
      Copy to Clipboard Toggle word wrap
      1
      namecredentialsName 字段中,将 <num> 替换为裸机节点的唯一计算节点号。
      2
      <base64_of_uid><base64_of_pwd> 替换为用户名和密码的 base64 字符串。
      3
      <nic1_mac_address> 替换为裸机节点第一个 NIC 的 MAC 地址。如需了解更多 BMC 配置选项,请参阅"BMC 寻址"部分。
      4
      <protocol> 替换为 BMC 协议,如 IPMI、Redfish 或其他。将 <bmc_url> 替换为裸机节点基板管理控制器的 URL。
      5
      可选:如果您指定了 root 设备提示,将 <root_device_hint> 替换为设备路径。详情请查看"Root 设备提示"。
      重要

      如果现有裸机节点的 MAC 地址与您试图置备的裸机主机的 MAC 地址匹配,则安装将失败。如果主机注册、检查、清理或其他步骤失败,Bare Metal Operator 会持续重试安装。如需了解更多详细信息,请参阅"在集群中置备新主机时诊断重复的 MAC 地址"。

  2. 运行以下命令来创建裸机节点:

    $ oc create -f bmh.yaml
    Copy to Clipboard Toggle word wrap

    输出示例

    secret/openshift-worker-<num>-network-config-secret created
    secret/openshift-worker-<num>-bmc-secret created
    baremetalhost.metal3.io/openshift-worker-<num> created
    Copy to Clipboard Toggle word wrap

  3. 运行以下命令检查裸机节点:

    $ oc -n openshift-machine-api get bmh openshift-worker-<num>
    Copy to Clipboard Toggle word wrap

    其中:

    <num>

    指定计算节点数量。

    输出示例

    NAME                    STATE       CONSUMER   ONLINE   ERROR
    openshift-worker-<num>  provisioned true
    Copy to Clipboard Toggle word wrap

  4. 批准所有证书签名请求 (CSR)。

    1. 运行以下命令,获取待处理的 CSR 列表:

      $ oc get csr
      Copy to Clipboard Toggle word wrap

      输出示例

      NAME        AGE   SIGNERNAME                                    REQUESTOR                                         REQUESTEDDURATION CONDITION
      csr-gfm9f   33s   kubernetes.io/kube-apiserver-client-kubelet   system:serviceaccount:openshift-machine-config-o
      perator:node-bootstrapper   <none>              Pending
      Copy to Clipboard Toggle word wrap

    2. 运行以下命令来批准 CSR:

      $ oc adm certificate approve <csr_name>
      Copy to Clipboard Toggle word wrap

      输出示例

      certificatesigningrequest.certificates.k8s.io/<csr_name> approved
      Copy to Clipboard Toggle word wrap

验证

  • 运行以下命令验证节点是否已就绪:

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME        STATUS   ROLES           AGE     VERSION
    app1        Ready    worker          47s     v1.24.0+dc5a2fd
    controller1 Ready    master,worker   2d22h   v1.24.0+dc5a2fd
    Copy to Clipboard Toggle word wrap

另外,您可以通过为现有主机创建一个 BareMetalHost 对象来管理用户置备的集群中的现有裸机控制器主机,来使用 Bare Metal Operator (BMO) 来管理用户置备集群中的现有裸机控制器主机。它不是必须的来管理现有用户置备的主机;但是,您可以将它们注册为外部置备主机,以实现清单目的。

重要

要使用 BMO 管理现有主机,您必须将 BareMetalHost 自定义资源中的 spec.externallyProvisioned 规格设置为 true,以防止 BMO 重新置备主机。

先决条件

  • 您创建了用户置备的裸机集群。
  • 您有到主机的基板管理控制器 (BMC) 访问权限。
  • 通过创建一个 Provisioning CR,在集群中部署了置备服务。

流程

  1. 创建 Secret CR 和 BareMetalHost CR。

    1. 将以下 YAML 保存到 controller.yaml 文件中:

      ---
      apiVersion: v1
      kind: Secret
      metadata:
        name: controller1-bmc
        namespace: openshift-machine-api
      type: Opaque
      data:
        username: <base64_of_uid>
        password: <base64_of_pwd>
      ---
      apiVersion: metal3.io/v1alpha1
      kind: BareMetalHost
      metadata:
        name: controller1
        namespace: openshift-machine-api
      spec:
        bmc:
          address: <protocol>://<bmc_url> 
      1
      
          credentialsName: "controller1-bmc"
        bootMACAddress: <nic1_mac_address>
        customDeploy:
          method: install_coreos
        externallyProvisioned: true 
      2
      
        online: true
        userData:
          name: controller-user-data-managed
          namespace: openshift-machine-api
      Copy to Clipboard Toggle word wrap
      1
      您只能使用支持虚拟介质网络引导的裸机主机驱动程序,如 redfish-virtualmediaidrac-virtualmedia
      2
      您必须将值设为 true,以防止 BMO 重新置备裸机控制器主机。
  2. 运行以下命令来创建裸机主机对象:

    $ oc create -f controller.yaml
    Copy to Clipboard Toggle word wrap

    输出示例

    secret/controller1-bmc created
    baremetalhost.metal3.io/controller1 created
    Copy to Clipboard Toggle word wrap

验证

  • 运行以下命令,验证 BMO 创建了裸机主机对象:

    $ oc get bmh -A
    Copy to Clipboard Toggle word wrap

    输出示例

    NAMESPACE               NAME          STATE                    CONSUMER   ONLINE   ERROR   AGE
    openshift-machine-api   controller1   externally provisioned              true             13s
    Copy to Clipboard Toggle word wrap

2.4.5. 使用 BMO 从用户置备的集群中删除主机

您可以使用 Bare Metal Operator (BMO)从用户置备的集群中删除裸机主机。

先决条件

  • 您创建了用户置备的裸机集群。
  • 您有到主机的基板管理控制器 (BMC) 访问权限。
  • 通过创建一个 Provisioning CR,在集群中部署了置备服务。

流程

  1. 运行以下命令 cordon 和 drain 节点:

    $ oc adm drain app1 --force --ignore-daemonsets=true
    Copy to Clipboard Toggle word wrap

    输出示例

    node/app1 cordoned
    WARNING: ignoring DaemonSet-managed Pods: openshift-cluster-node-tuning-operator/tuned-tvthg, openshift-dns/dns-
    default-9q6rz, openshift-dns/node-resolver-zvt42, openshift-image-registry/node-ca-mzxth, openshift-ingress-cana
    ry/ingress-canary-qq5lf, openshift-machine-config-operator/machine-config-daemon-v79dm, openshift-monitoring/nod
    e-exporter-2vn59, openshift-multus/multus-additional-cni-plugins-wssvj, openshift-multus/multus-fn8tg, openshift
    -multus/network-metrics-daemon-5qv55, openshift-network-diagnostics/network-check-target-jqxn2, openshift-ovn-ku
    bernetes/ovnkube-node-rsvqg
    evicting pod openshift-operator-lifecycle-manager/collect-profiles-27766965-258vp
    evicting pod openshift-operator-lifecycle-manager/collect-profiles-27766950-kg5mk
    evicting pod openshift-operator-lifecycle-manager/collect-profiles-27766935-stf4s
    pod/collect-profiles-27766965-258vp evicted
    pod/collect-profiles-27766950-kg5mk evicted
    pod/collect-profiles-27766935-stf4s evicted
    node/app1 drained
    Copy to Clipboard Toggle word wrap

  2. BareMetalHost CR 中删除 customDeploy 规格。

    1. 运行以下命令,为主机编辑 BareMetalHost CR:

      $ oc edit bmh -n openshift-machine-api <host_name>
      Copy to Clipboard Toggle word wrap
    2. 删除 spec.customDeployspec.customDeploy.method 行:

      ...
        customDeploy:
          method: install_coreos
      Copy to Clipboard Toggle word wrap
    3. 运行以下命令,验证主机的置备状态是否更改为 deprovisioning

      $ oc get bmh -A
      Copy to Clipboard Toggle word wrap

      输出示例

      NAMESPACE               NAME          STATE                    CONSUMER   ONLINE   ERROR   AGE
      openshift-machine-api   controller1   externally provisioned              true             58m
      openshift-machine-api   worker1       deprovisioning                      true             57m
      Copy to Clipboard Toggle word wrap

  3. BareMetalHost 状态更改为 available 时,运行以下命令来删除主机:

    $ oc delete bmh -n openshift-machine-api <bmh_name>
    Copy to Clipboard Toggle word wrap
    注意

    您可以运行这个步骤,而无需编辑 BareMetalHost CR。可能需要过些时间,BareMetalHost 状态才会从 deprovisioning 变为 available

  4. 运行以下命令来删除节点:

    $ oc delete node <node_name>
    Copy to Clipboard Toggle word wrap

验证

  • 运行以下命令验证您是否删除了节点:

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME          STATUS   ROLES           AGE     VERSION
    controller1   Ready    master,worker   2d23h   v1.24.0+dc5a2fd
    Copy to Clipboard Toggle word wrap

2.5. 裸机的安装配置参数

在部署 OpenShift Container Platform 集群前,您可以提供一个自定义 的 install-config.yaml 安装配置文件,该文件描述了您的环境的详情。

2.5.1. 裸机的可用安装配置参数

下表指定您可以在安装过程中设置所需的、可选和特定于裸机的安装配置参数。

重要

安装后,您无法更改 install-config.yaml 文件中的这些参数。

2.5.1.1. 所需的配置参数

下表描述了所需的安装配置参数:

Expand
表 2.41. 所需的参数
参数描述
apiVersion:
Copy to Clipboard Toggle word wrap

install-config.yaml 内容的 API 版本。当前版本为 v1。安装程序可能还支持旧的 API 版本。

字符串

baseDomain:
Copy to Clipboard Toggle word wrap

云供应商的基域。基域用于创建到 OpenShift Container Platform 集群组件的路由。集群的完整 DNS 名称是 baseDomainmetadata.name 参数值的组合,其格式为 <metadata.name>.<baseDomain>

完全限定域名或子域名,如 example.com

metadata:
Copy to Clipboard Toggle word wrap

Kubernetes 资源 ObjectMeta,其中只消耗 name 参数。

对象

metadata:
  name:
Copy to Clipboard Toggle word wrap

集群的名称。集群的 DNS 记录是 {{.metadata.name}}.{{.baseDomain}} 的子域。

小写字母和连字符 (-) 的字符串,如 dev

platform:
Copy to Clipboard Toggle word wrap

对于特定平台的配置取决于执行安装的环境: aws, baremetal, azure, gcp, ibmcloud, nutanix, openstack, powervs, vsphere, 或 {}.有关 platform.<platform> 参数的更多信息,请参考下表中您的特定平台。

对象

pullSecret:
Copy to Clipboard Toggle word wrap

从 Red Hat OpenShift Cluster Manager 获取 pull secret,验证从 Quay.io 等服务中下载 OpenShift Container Platform 组件的容器镜像。

{
   "auths":{
      "cloud.openshift.com":{
         "auth":"b3Blb=",
         "email":"you@example.com"
      },
      "quay.io":{
         "auth":"b3Blb=",
         "email":"you@example.com"
      }
   }
}
Copy to Clipboard Toggle word wrap
2.5.1.2. 网络配置参数

您可以根据现有网络基础架构的要求自定义安装配置。例如,您可以扩展集群网络的 IP 地址块,或者配置与默认值不同的 IP 地址块。

在为集群配置网络参数前,请考虑以下信息:

  • 如果使用 Red Hat OpenShift Networking OVN-Kubernetes 网络插件,则支持 IPv4 和 IPv6 地址系列。
  • 如果您在带有支持 IPv4 和非本地 IPv6 地址的网络的 OpenShift Container Platform 集群中部署了节点,请将集群配置为使用双栈网络。

    • 对于为双栈网络配置的集群,IPv4 和 IPv6 流量都必须使用与默认网关相同的网络接口。这样可确保在一个多个网络接口控制器(NIC)环境中,集群可以根据可用的网络接口检测要使用的 NIC。如需更多信息,请参阅关于 OVN-Kubernetes 网络插件中的"OVN-Kubernetes IPv6 和双栈限制"。
    • 为防止网络连接问题,请不要在支持双栈网络的主机上安装单堆栈 IPv4 集群。

如果将集群配置为使用两个 IP 地址系列,请查看以下要求:

  • 两个 IP 系列都必须将相同的网络接口用于默认网关。
  • 两个 IP 系列都必须具有默认网关。
  • 您必须为所有网络配置参数指定 IPv4 和 IPv6 地址。例如,在以下配置中,IPv4 地址会在 IPv6 地址之前列出:

    networking:
      clusterNetwork:
      - cidr: 10.128.0.0/14
        hostPrefix: 23
      - cidr: fd00:10:128::/56
        hostPrefix: 64
      serviceNetwork:
      - 172.30.0.0/16
      - fd00:172:16::/112
    Copy to Clipboard Toggle word wrap
Expand
表 2.42. 网络参数
参数描述
networking:
Copy to Clipboard Toggle word wrap

集群网络的配置。

对象

注意

您不能在安装后更改 networking 对象指定的参数。

networking:
  networkType:
Copy to Clipboard Toggle word wrap

要安装的 Red Hat OpenShift Networking 网络插件。

OVNKubernetesOVNKubernetes 是 Linux 网络和包含 Linux 和 Windows 服务器的混合网络的 Container Network Interface (CNI)插件。默认值为 OVNKubernetes

networking:
  clusterNetwork:
Copy to Clipboard Toggle word wrap

pod 的 IP 地址块。

默认值为 10.128.0.0/14,主机前缀为 /23

如果您指定了多个 IP 地址块,块不得重叠。

对象数组。例如:

networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  - cidr: fd01::/48
    hostPrefix: 64
Copy to Clipboard Toggle word wrap
networking:
  clusterNetwork:
    cidr:
Copy to Clipboard Toggle word wrap

使用 networking.clusterNetwork 时需要此项。IP 地址块。

如果使用 OVN-Kubernetes 网络插件,您可以指定 IPv4 和 IPv6 网络。

使用 CIDR 形式的 IP 地址块。IPv4 块的前缀长度介于 032 之间。IPv6 块的前缀长度介于 0128 之间。例如,10.128.0.0/14fd01::/48

networking:
  clusterNetwork:
    hostPrefix:
Copy to Clipboard Toggle word wrap

分配给每个节点的子网前缀长度。例如,如果 hostPrefix 设为 23,则每个节点从 given cidr 中分配 a /23 子网。hostPrefix23 提供 510(2^(32 - 23)- 2)pod IP 地址。

子网前缀。

对于 IPv4 网络,默认值为 23。对于 IPv6 网络,默认值为 64。默认值也是 IPv6 的最小值。

networking:
  serviceNetwork:
Copy to Clipboard Toggle word wrap

服务的 IP 地址块。默认值为 172.30.0.0/16

OVN-Kubernetes 网络插件只支持服务网络的一个 IP 地址块。

如果使用 OVN-Kubernetes 网络插件,您可以为 IPv4 和 IPv6 地址系列指定一个 IP 地址块。

CIDR 格式具有 IP 地址块的数组。例如:

networking:
  serviceNetwork:
   - 172.30.0.0/16
   - fd02::/112
Copy to Clipboard Toggle word wrap
networking:
  machineNetwork:
Copy to Clipboard Toggle word wrap

机器的 IP 地址块。

如果您指定了多个 IP 地址块,块不得重叠。

对象数组。例如:

networking:
  machineNetwork:
  - cidr: 10.0.0.0/16
Copy to Clipboard Toggle word wrap
networking:
  machineNetwork:
    cidr:
Copy to Clipboard Toggle word wrap

使用 networking.machineNetwork 时需要此项。IP 地址块。对于 libvirt 和 IBM Power® Virtual Server 以外的所有平台,默认值为 10.0.0.0/16。对于 libvirt,默认值 为 192.168.126.0/24。对于 IBM Power® Virtual Server,默认值为 192.168.0.0/24

CIDR 表示法中的 IP 网络块。

例如。10.0.0.0/16fd00::/48

注意

networking.machineNetwork 设置为与首选 NIC 所在的 CIDR 匹配。

networking:
  ovnKubernetesConfig:
    ipv4:
      internalJoinSubnet:
Copy to Clipboard Toggle word wrap

配置 ovn-kubernetes 内部使用的 IPv4 加入子网。此子网不得与 OpenShift Container Platform 使用的任何其他子网重叠,包括节点网络。子网的大小必须大于节点的数量。您不能在安装后更改值。

CIDR 表示法中的 IP 网络块。默认值为 100.64.0.0/16

2.5.1.3. 可选的配置参数

下表描述了可选的安装配置参数:

Expand
表 2.43. 可选参数
参数描述
additionalTrustBundle:
Copy to Clipboard Toggle word wrap

添加到节点可信证书存储中的 PEM 编码 X.509 证书捆绑包。配置代理时,也可以使用此信任捆绑包。

字符串

capabilities:
Copy to Clipboard Toggle word wrap

控制可选核心组件的安装。您可以通过禁用可选组件来减少 OpenShift Container Platform 集群的空间。如需更多信息,请参阅安装中的"集群功能"页面。

字符串数组

capabilities:
  baselineCapabilitySet:
Copy to Clipboard Toggle word wrap

选择要启用的一组初始可选功能。有效值为 Nonev4.11v4.12vCurrent。默认值为 vCurrent

字符串

capabilities:
  additionalEnabledCapabilities:
Copy to Clipboard Toggle word wrap

将可选功能集合扩展到您在 baselineCapabilitySet 中指定的范围。您可以在此参数中指定多个功能。

字符串数组

cpuPartitioningMode:
Copy to Clipboard Toggle word wrap

启用工作负载分区,它会隔离 OpenShift Container Platform 服务、集群管理工作负载和基础架构 pod,以便在保留的一组 CPU 上运行。您只能在安装过程中启用工作负载分区。您不能在安装后禁用它。虽然此字段启用工作负载分区,但它不会将工作负载配置为使用特定的 CPU。如需更多信息,请参阅 Scalability and Performance 部分中的 Workload partitioning 页面。

NoneAllNodes.None 是默认值。

compute:
Copy to Clipboard Toggle word wrap

组成计算节点的机器的配置。

MachinePool 对象的数组。

compute:
  architecture:
Copy to Clipboard Toggle word wrap

决定池中机器的指令集合架构。目前,不支持具有不同架构的集群。所有池都必须指定相同的架构。有效值为 amd64arm64

字符串

compute:
  hyperthreading:
Copy to Clipboard Toggle word wrap

是否在计算机器上启用或禁用并发多 线程或超线程。默认情况下,启用并发多线程以提高机器内核的性能。

重要

如果您禁用并发多线程,请确保您的容量规划考虑机器性能显著降低的情况。

enabledDisabled

compute:
  name:
Copy to Clipboard Toggle word wrap

使用 compute 时需要此项。机器池的名称。

worker

compute:
  platform:
Copy to Clipboard Toggle word wrap

使用 compute 时需要此项。使用此参数指定托管 worker 机器的云供应商。此参数值必须与 controlPlane.platform 参数值匹配。

aws, azure, gcp, ibmcloud, nutanix, openstack, powervs, vsphere, 或 {}

compute:
  replicas:
Copy to Clipboard Toggle word wrap

要置备的计算机器数量,也称为 worker 机器。

大于或等于 2 的正整数。默认值为 3

featureSet:
Copy to Clipboard Toggle word wrap

为功能集启用集群。功能集是 OpenShift Container Platform 功能的集合,默认情况下不启用。有关在安装过程中启用功能集的更多信息,请参阅"使用功能门启用功能"。

字符串.要启用的功能集的名称,如 TechPreviewNoUpgrade

controlPlane:
Copy to Clipboard Toggle word wrap

组成 control plane 的机器的配置。

MachinePool 对象的数组。

controlPlane:
  architecture:
Copy to Clipboard Toggle word wrap

决定池中机器的指令集合架构。目前,不支持具有不同架构的集群。所有池都必须指定相同的架构。有效值为 amd64arm64

字符串

controlPlane:
  hyperthreading:
Copy to Clipboard Toggle word wrap

是否在 control plane 机器上启用或禁用并发多 线程或超线程。默认情况下,启用并发多线程以提高机器内核的性能。

重要

如果您禁用并发多线程,请确保您的容量规划考虑机器性能显著降低的情况。

enabledDisabled

controlPlane:
  name:
Copy to Clipboard Toggle word wrap

使用 controlPlane 时需要此项。机器池的名称。

master

controlPlane:
  platform:
Copy to Clipboard Toggle word wrap

使用 controlPlane 时需要此项。使用此参数指定托管 control plane 机器的云供应商。此参数值必须与 compute.platform 参数值匹配。

aws, azure, gcp, ibmcloud, nutanix, openstack, powervs, vsphere, 或 {}

controlPlane:
  replicas:
Copy to Clipboard Toggle word wrap

要置备的 control plane 机器数量。

部署单节点 OpenShift 时支持的值为 31

credentialsMode:
Copy to Clipboard Toggle word wrap

Cloud Credential Operator(CCO)模式。如果没有指定模式,CCO 会动态尝试决定提供的凭证的功能,在支持多个模式的平台上首选 mint 模式。

注意

不是所有 CCO 模式都支持所有云供应商。有关 CCO 模式的更多信息,请参阅身份验证和授权内容中的"管理云供应商凭证"条目。

MintPassthroughManual 或空字符串("")。

fips:
Copy to Clipboard Toggle word wrap

启用或禁用 FIPS 模式。默认值为 false (禁用)。如果启用 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 核心组件使用 RHEL 加密库,只有在 x86_64, ppc64le, 和 s390x 架构上的库被提交到 NIST 进行 FIPS 140-2/140-3 Validation。

重要

如果使用 Azure File 存储,则无法启用 FIPS 模式。

falsetrue

imageContentSources:
Copy to Clipboard Toggle word wrap

release-image 内容的源和存储库。

对象数组。包括一个 source 以及可选的 mirrors,如本表的以下行所述。

imageContentSources:
  source:
Copy to Clipboard Toggle word wrap

使用 imageContentSources 时需要此项。指定用户在镜像拉取规格中引用的存储库。

字符串

imageContentSources:
  mirrors:
Copy to Clipboard Toggle word wrap

指定可能还包含同一镜像的一个或多个存储库。

字符串数组

publish:
Copy to Clipboard Toggle word wrap

如何发布或公开集群的面向用户的端点,如 Kubernetes API、OpenShift 路由。

内部或外部 .默认值为 External

在非云平台上不支持将此字段设置为 Internal

重要

如果字段的值设为 Internal,集群就会变得无法正常工作。如需更多信息,请参阅 BZ#1953035

sshKey:
Copy to Clipboard Toggle word wrap

用于验证对集群机器的访问的 SSH 密钥。

注意

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

例如,sshKey: ssh-ed25519 AAAA..

第 3 章 安装程序置备的基础架构

3.1. 概述

裸机节点上的安装程序置备安装会部署并配置运行 OpenShift Container Platform 集群的基础架构。本指南提供了一种成功实现安装程序置备的裸机安装的方法。下图演示了部署阶段 1 中的安装环境:

对于安装,上图中的关键元素是:

  • Provisioner:运行安装程序的物理计算机,并托管部署新 OpenShift Container Platform 集群的控制平面的 bootstrap 虚拟机。
  • Bootstrap 虚拟机 :部署 OpenShift Container Platform 集群过程中使用的虚拟机。
  • 网络桥接 :bootstrap 虚拟机连接到裸机网络,如果存在,通过网桥 eno1eno2 连接到 provisioning 网络。
  • API VIP :API 虚拟 IP 地址 (VIP) 用于在 control plane 节点上提供 API 服务器的故障切换。API VIP 首先位于 bootstrap 虚拟机上。在启动服务前,脚本会生成 keepalived.conf 配置文件。在 bootstrap 过程完成后,VIP 被移到一个 control plane 节点,bootstrap 虚拟机会停止。

在部署阶段 2 中,置备程序会自动销毁 bootstrap 虚拟机,并将虚拟 IP 地址 (VIP) 移到适当的节点。

keepalived.conf 文件会将 control plane 机器设置为其虚拟路由器冗余协议 (VRRP 优先级比 bootstrap 虚拟机的设置低,这样可确保在 API VIP 从 bootstrap 虚拟机移到控制平面机器前,控制平面上的 API 可以完全正常工作。当 API VIP 移动到其中一个 control plane 节点后,从外部客户端发送到 API VIP 路由的流量发送到该 control plane 节点上运行的 haproxy 负载均衡器。此 haproxy 实例在 control plane 节点之间负载均衡 API VIP 流量。

Ingress VIP 移到计算节点。keepalived 实例还管理 Ingress VIP。

下图演示了部署的阶段 2:

此时,置备程序使用的节点可以被移除或重新使用。在这里,所有额外的置备任务都由 control plane 执行。

注意

对于安装程序置备的基础架构安装,CoreDNS 在节点级别公开端口 53,使其可以从其他可路由网络访问。

重要

provisioning 网络是可选的,但 PXE 启动需要它。如果在没有 provisioning 网络的情况下部署,则必须使用虚拟介质管理控制器 (BMC) 寻址选项,如 redfish-virtualmediaidrac-virtualmedia

3.2. 先决条件

OpenShift Container Platform 安装程序置备的安装需要:

  1. 安装了 Red Hat Enterprise Linux(RHEL) 9.x 的一个置备程序节点。在安装后可以删除置备程序。
  2. 三个 control plane 节点
  3. 对每个节点的 Baseboard 管理控制器 (BMC) 访问
  4. 至少一个网络:

    1. 一个必需的可路由网络
    2. 一个可选的 provisioning 网络
    3. 一个可选的管理网络

在开始 OpenShift Container Platform 安装程序置备的安装前,请确保硬件环境满足以下要求。

3.2.1. 节点要求

安装程序置备的安装涉及多个硬件节点要求:

  • CPU 架构: 所有节点都必须使用 x86_64aarch64 CPU 架构。
  • 类似的节点: 红帽建议每个角色都有相同的配置。也就是说,红帽建议节点具有相同的品牌和型号,它们具有相同的 CPU、内存和存储配置。
  • Baseboard Management Controller: provisioner 节点必须能够访问每个 OpenShift Container Platform 集群节点的基板管理控制器(BMC)。您可以使用 IPMI、Redfish 或专有协议。
  • 最新一代: 节点必须是最新一代。安装程序置备的安装依赖于 BMC 协议,这些协议必须在节点间兼容。另外,RHEL 9.x 附带了 RAID 控制器的最新驱动程序。确保节点足以支持 provisioner 节点的 RHEL 9.x,支持 control plane 和 worker 节点的 RHCOS 9.x。
  • registry 节点:( 可选)如果设置了一个断开连接的镜像 registry,建议 registry 驻留在自己的节点上。
  • provisioner 节点: 安装程序置备的安装需要一个 provisioner 节点。
  • control plane: 安装程序置备的安装需要三个 control plane 节点才能实现高可用性。您可以部署仅具有三个 control plane 节点的 OpenShift Container Platform 集群,使 control plane 节点可以作为 worker 节点调度。较小的集群在开发、生产和测试过程中为管理员和开发人员提供更多资源。
  • Worker 节点: 虽然不是必须的的,但典型的生产环境集群一般会有两个或者多个 worker 节点。

    重要

    不要只部署一个 worker 节点的集群,因为集群将使用降级状态的路由器和入口流量进行部署。

  • 网络接口: 每个节点必须至少有一个网络接口用于可路由的 baremetal 网络。在使用 provisioning 网络进行部署时,每个节点都必须有一个网络接口用于 provisioning 网络。使用 provisioning 网络是默认配置。

    注意

    在同一子网上只能有一个网卡 (NIC) 可以通过网关路由流量。默认情况下,地址解析协议 (ARP) 使用编号最低的 NIC。对同一子网中的每个节点都使用一个单独的 NIC,以确保网络负载均衡按预期工作。当为同一子网中的一个节点使用多个 NIC 时,需要使用一个绑定或组接口。然后,以一个别名 IP 地址的形式将其他 IP 地址添加到该接口。如果您需要在网络接口级别进行容错或负载均衡,请在绑定或团队接口上使用别名 IP 地址。或者,您可以在同一子网中禁用二级 NIC,或者确保它没有 IP 地址。

  • 统一可扩展固件接口(UEFI): 安装程序置备的安装需要在 置备 网络中使用 IPv6 时在所有 OpenShift Container Platform 节点上进行 UEFI 引导。另外,UEFI Device PXE 设置必须设置为在 provisioning 网络 NIC 中使用 IPv6 协议,但忽略 provisioning 网络会删除这个要求。

    重要

    从 ISO 镜像启动安装时,删除所有旧的 UEFI 引导条目。如果引导条目包含不是固件提供通用条目的条目,则安装可能会失败。

  • 安全引导: 许多生产环境中需要启用安全引导的节点来验证节点仅使用可信软件引导,如 UEFI 固件驱动程序、EFI 应用程序和操作系统。您可以使用安全引导手动或管理进行部署。

    1. 手动: 要使用安全引导机制手动部署 OpenShift Container Platform 集群,您必须在每个 control plane 节点上和每个 worker 节点上启用 UEFI 引导模式和安全引导。红帽支持仅在安装程序置备的安装使用 Redfish 虚拟介质时手动启用 UEFI 和安全引导。如需了解更多详细信息,请参阅"配置节点"一节中的"手动配置安全引导节点"。
    2. Managed: 要使用受管安全引导机制部署 OpenShift Container Platform 集群,您必须在 install-config.yaml 文件中将 bootMode 值设置为 UEFISecureBoot。红帽仅在第 10 代 HPE 硬件和 13 代运行固件版本 2.75.75.75 或更高版本的 Dell 硬件中支持带受管安全引导的安装程序置备安装。使用受管安全引导进行部署不需要 Redfish 虚拟介质。详情请参阅"为 OpenShift 安装设置环境"一节中的"配置受管安全引导"。

      注意

      红帽不支持为安全引导管理自生成的密钥或其他密钥。

3.2.2. 集群安装的最低资源要求

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

Expand
表 3.1. 最低资源要求
机器操作系统CPU [1]RAMStorage每秒输入/输出 (IOPS) [2]

bootstrap

RHEL

4

16 GB

100 GB

300

Control plane(控制平面)

RHCOS

4

16 GB

100 GB

300

Compute

RHCOS

2

8 GB

100 GB

300

  1. 当未启用并发多线程 (SMT) 或超线程时,一个 CPU 相当于一个物理内核。启用后,使用以下公式来计算对应的比例:(每个内核数的线程)× sockets = CPU。
  2. OpenShift Container Platform 和 Kubernetes 对磁盘性能敏感,建议使用更快的存储,特别是 control plane 节点上的 etcd。请注意,在许多云平台上,存储大小和 IOPS 可一起扩展,因此您可能需要过度分配存储卷来获取足够的性能。
注意

对于 OpenShift Container Platform 版本 4.19,RHCOS 基于 RHEL 版本 9.6,它会更新微架构要求。以下列表包含每个架构需要的最小指令集架构 (ISA):

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

如需更多信息,请参阅 架构 (RHEL 文档)。

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

3.2.3. 为 OpenShift Virtualization 规划裸机集群

如果使用 OpenShift Virtualization,必须在安装裸机集群前了解一些要求。

  • 如果要使用实时迁移功能,在集群安装时需要有多个 worker 节点。这是因为实时迁移需要集群级别的高可用性 (HA) 标记设置为 true。当安装集群时,会设置 HA 标志,之后无法更改。如果在安装集群时定义少于两个 worker 节点,则集群生命周期中的 HA 标记被设置为 false。

    注意

    您可以在单节点集群中安装 OpenShift Virtualization,但单节点 OpenShift 不支持高可用性。

  • 实时迁移需要共享存储。OpenShift Virtualization 的存储必须支持并使用 ReadWriteMany (RWX) 访问模式。
  • 如果您计划使用单根 I/O 虚拟化 (SR-IOV),请确保 OpenShift Container Platform 支持网络接口控制器 (NIC)。

3.2.4. 使用虚拟介质安装的固件要求

安装程序置备的 OpenShift Container Platform 集群的安装程序会验证与 Redfish 虚拟介质的硬件和固件兼容性。如果节点固件不兼容,安装程序不会在节点上开始安装。下表列出了经过测试并验证以使用 Redfish 虚拟介质部署的安装程序置备的 OpenShift Container Platform 集群的最低固件版本。

注意

红帽不测试固件、硬件或其他第三方组件的组合。有关第三方支持的更多信息,请参阅红帽第三方支持政策。有关更新固件的详情,请查看硬件文档了解节点或联系硬件厂商。

Expand
表 3.2. HP 硬件与 Redfish 虚拟介质的固件兼容性
model管理固件版本

第 11 代

iLO6

1.57 或更高版本

第 10 代

iLO5

2.63 或更高版本

Expand
表 3.3. Dell 硬件与 Redfish 虚拟介质的固件兼容性
model管理固件版本

第 16 代

iDRAC 9

v7.10.70.00

第 15 代

iDRAC 9

v6.10.30.00, v7.10.50.00, 和 v7.10.70.00

第 14 代

iDRAC 9

v6.10.30.00

Expand
表 3.4. 带有 Redfish 虚拟介质的 Cisco UCS 硬件的固件兼容性
model管理固件版本

UCS X 系列服务器

Intersight Managed Mode

5.2 (2) 或更高版本

FI-Attached UCS C-Series 服务器

Intersight Managed Mode

4.3 或更高版本

Standalone UCS C-Series 服务器

Standalone / Intersight

4.3 或更高版本

注意

始终确认您的服务器支持 UCSHCL 上的 Red Hat Enterprise Linux CoreOS (RHCOS)。

3.2.5. 裸机的 NC-SI 硬件要求

要在裸机上部署带有 Network Controller Sideband Interface (NC-SI) 的 OpenShift Container Platform 4.19 及更新的版本,您必须使用支持 NC-SI 的基板管理控制器(BMC)和网络接口卡(NIC)。NC-SI 启用 BMC 与主机共享系统 NIC,需要 DisablePowerOff 功能来防止在电源关闭过程中丢失 BMC 连接。

Expand
表 3.5. NC-SI 的服务器兼容性
VendorModelsGeneration管理

Dell

PowerEdge

第 14 代及更高版本

iDRAC 9 及更新的版本(Redfish、IPMI、racadm、WS-MAN)

HPE

ProLiant

第 10 代及更高版本

iLO 5 及更高版本(Redfish、IPMI、i iLO RESTful API)

Lenovo

ThinkSystem SR

1st 生成及更高版本

XClarity Controller (Redfish、IPMI、专有 API)

Supermicro

SuperServer

X11 系列及更高版本

Supermicro BMC (Redfish、IPMI、专有 Web/CLI)

Intel

服务器系统

S2600BP 及更高版本

Intel BMC (Redfish、IPMI、专有 API)

Fujitsu

PRIMERGY

M4 系列及更新版本

iRMC S5 及更高版本(Red Hatfish、IPMI、专有 Web/CLI)

Cisco

UCS C-Series

M5 系列及更新版本

Cisco IMC (Redfish、IPMI、专有 XML API)

Expand
表 3.6. NC-SI 的兼容网络接口卡(NIC)
VendorModelsSpecifications

Broadcom

NetXtreme BCM5720, BCM57416, BCM57504

Gigabit 和 10/25/100GbE、RMII sideband、支持 Redfish、IPMI 和厂商协议。

Intel

I210, X710, XXV710, E810

Gigabit 到 100GbE、RMII 和 SMBus sideband、支持 Redfish、IPMI 和厂商协议。

NVIDIA

ConnectX-5, ConnectX-6, ConnectX-7

25/50/100/200/400GbE、RMII 侧带、支持 Redfish、IPMI 和 NVIDIA BMC API。

NVIDIA

BlueField-2 及更新的版本

200/400GbE、支持 Redfish、IPMI 和 NVIDIA BMC API。

Marvell/Cavium

ThunderX CN88xx, FastLinQ QL41000

10/25/50GbE、RMII 侧带、支持 Redfish、IPMI 和供应商协议。

Mellanox (NVIDIA)

MCX4121A-ACAT, MCX512A-ACAT

10/25/50GbE、RMII 侧带、支持 Redfish、IPMI 和 Mellanox API。

注意

验证 NC-SI 支持供应商文档,因为兼容性取决于 BMC、NIC 和固件配置。NC-SI NIC 需要兼容的 BMC 来启用共享的 NIC 功能。

3.2.6. 网络要求

OpenShift Container Platform 安装程序置备的安装涉及多网络要求。首先,安装程序置备的安装涉及一个可选的不可路由 置备 网络,用于在每个裸机节点上置备操作系统。其次,安装程序置备的安装涉及一个可路由的 baremetal 网络。

3.2.6.1. 确保打开所需的端口

某些端口必须在集群节点之间打开,才能成功完成安装程序置备的安装。在某些情况下,比如在边缘 worker 节点中使用单独的子网,您必须确保这些子网中的节点可以与以下所需端口上其他子网中的节点通信。

Expand
表 3.7. 所需端口
port描述

67,68

在使用 provisioning 网络时,集群节点使用端口 6768 访问 dnsmasq DHCP 服务器。

69

在使用 provisioning 网络时,集群节点使用它们的置备网络接口与端口 69 上的 TFTP 服务器通信。TFTP 服务器在 bootstrap 虚拟机上运行。bootstrap 虚拟机在 provisioner 节点上运行。

80

如果没有使用镜像缓存选项或使用虚拟介质,则 provisioner 节点必须在 baremetal 机器网络接口上打开端口 80,才能将来自 provisioner 节点的 Red Hat Enterprise Linux CoreOS (RHCOS)镜像流传输到集群节点。

123

集群节点必须使用 baremetal 机器网络访问端口 123 上的 NTP 服务器。

5050

Ironic Inspector API 在 control plane 节点上运行,并侦听端口 5050。Inspector API 负责硬件内省,它收集有关裸机节点的硬件特征的信息。

5051

端口 5050 使用端口 5051 作为代理。

6180

当使用虚拟介质而不是 TLS 部署时,provisioner 节点和 control plane 节点必须在 baremetal 机器网络接口上打开端口 6180,以便 worker 节点的基板管理控制器(BMC)可以访问 RHCOS 镜像。从 OpenShift Container Platform 4.13 开始,默认 HTTP 端口为 6180

6183

当使用虚拟介质并使用 TLS 部署时,provisioner 节点和 control plane 节点必须在 baremetal 机器网络接口上打开端口 6183,以便 worker 节点的 BMC 可以访问 RHCOS 镜像。

6385

Ironic API 服务器最初在 bootstrap 虚拟机上运行,稍后在 control plane 节点上运行,并侦听端口 6385。Ironic API 允许客户端与 Ironic 交互以进行裸机节点置备和管理,包括注册新节点、管理电源状态、部署镜像和清理硬件等操作。

6388

端口 6385 使用端口 6388 作为代理。

8080

在不使用 TLS 的情况下使用镜像缓存时,必须在 provisioner 节点上打开端口 8080,并可以被集群节点的 BMC 接口访问。

8083

当将镜像缓存选项与 TLS 搭配使用时,必须在 provisioner 节点上打开端口 8083,并可以被集群节点的 BMC 接口访问。

9999

默认情况下,Ironic Python 代理(IPA)侦听来自 Ironic 编排器服务的 API 调用的 TCP 端口 9999。运行 IPA 的裸机节点之间的通信,Ironic 编排器服务使用此端口。

3.2.6.2. 增加网络 MTU

在部署 OpenShift Container Platform 前,将网络最大传输单元 (MTU) 增加到 1500 或更多。如果 MTU 小于 1500,用于引导节点的 Ironic 镜像可能无法与 Ironic 检查 pod 通信,检查将失败。如果发生了这种情况,安装会停止,因为节点无法用于安装。

3.2.6.3. 配置 NIC

OpenShift Container Platform 使用两个网络部署:

  • provisioning置备 网络是一个可选的不可路由的网络,用于在作为 OpenShift Container Platform 集群一部分的每个节点上置备底层操作系统。每个集群节点上 provisioning 网络的网络接口必须将 BIOS 或 UEFI 配置为 PXE 引导。

    provisioningNetworkInterface 配置设置指定 control plane 节点上的 provisioning 网络 NIC 名称,它在 control plane 节点上必须相同。bootMACAddress 配置设置提供了一种方法,用于在每个节点上为 provisioning 网络指定特定的 NIC。

    调配 网络是可选的,但 PXE 引导需要该网络。如果您在没有 provisioning 网络的情况下部署,则必须使用虚拟介质 BMC 寻址选项,如 redfish-virtualmediaidrac-virtualmedia

  • baremetalbaremetal 网络是一个可路由的网络。您可以使用任何 NIC 与 baremetal 网络 进行接口,只要 NIC 没有配置为使用 provisioning 网络。
重要

在使用 VLAN 时,每个 NIC 必须位于与相应网络对应的独立 VLAN 中。

3.2.6.4. DNS 要求

客户端通过 baremetal 网络访问 OpenShift Container Platform 集群节点。网络管理员必须配置子域或子区,其中规范名称扩展是集群名称。

<cluster_name>.<base_domain>
Copy to Clipboard Toggle word wrap

例如:

test-cluster.example.com
Copy to Clipboard Toggle word wrap

OpenShift Container Platform 包含使用集群成员资格信息来生成 A/AAAA 记录的功能。这会将节点名称解析为其 IP 地址。使用 API 注册节点后,集群可以在不使用 CoreDNS-mDNS 的情况下分散节点信息。这可消除与多播 DNS 关联的网络流量。

CoreDNS 需要 TCP 和 UDP 连接到上游 DNS 服务器才能正常工作。确保上游 DNS 服务器可以从 OpenShift Container Platform 集群节点接收 TCP 和 UDP 连接。

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

  • The Kubernetes API
  • OpenShift Container Platform 应用程序通配符入口 API

A/AAAA 记录用于名称解析,而 PTR 记录用于反向名称解析。Red Hat Enterprise Linux CoreOS(RHCOS)使用反向记录或 DHCP 为所有节点设置主机名。

安装程序置备的安装包括使用集群成员资格信息生成 A/AAAA 记录的功能。这会将节点名称解析为其 IP 地址。在每个记录中,<cluster_name> 是集群名称,<base_domain> 是您在 install-config.yaml 文件中指定的基域。完整的 DNS 记录采用以下形式: <component>.<cluster_name>.<base_domain>.

Expand
表 3.8. 所需的 DNS 记录
组件记录描述

Kubernetes API

api.<cluster_name>.<base_domain>.

A/AAAA 记录和 PTR 记录可识别 API 负载均衡器。这些记录必须由集群外的客户端和集群中的所有节点解析。

Routes

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

通配符 A/AAAA 记录指的是应用程序入口负载均衡器。应用程序入口负载均衡器以运行 Ingress Controller pod 的节点为目标。默认情况下,Ingress Controller pod 在 worker 节点上运行。这些记录必须由集群外的客户端和集群中的所有节点解析。

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

提示

您可以使用 dig 命令验证 DNS 解析。

3.2.6.5. 动态主机配置协议(DHCP)要求

默认情况下,安装程序置备的安装会在 provisioning 网络启用了 DHCP 的情况下部署 ironic-dnsmasq。当 provisioningNetwork 配置设置为 managed 时(默认值),不能有其他 DHCP 服务器在 provisioning 网络中运行。如果您在 provisioning 网络上运行 DHCP 服务器,则必须在 install-config.yaml 文件中将 provisioningNetwork 配置设置设置为 非受管

网络管理员必须为 OpenShift Container Platform 集群中的各个节点为外部 DHCP 服务器上的 baremetal 网络 保留 IP 地址。

3.2.6.6. 使用 DHCP 服务器为节点保留 IP 地址

对于 baremetal 网络,网络管理员必须保留几个 IP 地址,包括:

  1. 两个唯一的虚拟 IP 地址。

    • API 端点的一个虚拟 IP 地址。
    • 一个用于通配符入口端点的虚拟 IP 地址。
  2. 一个用于 provisioner 节点的 IP 地址。
  3. 每个 control plane 节点有一个 IP 地址。
  4. 每个 worker 节点有一个 IP 地址(如果适用)。
保留 IP 地址,以便其成为静态 IP 地址

有些管理员更喜欢使用静态 IP 地址,以便在没有 DHCP 服务器时每个节点的 IP 地址保持恒定状态。要使用 NMState 配置静态 IP 地址,请参阅"设置 OpenShift 安装环境"部分中的" (可选)配置节点网络接口"。

外部负载均衡器和 control plane 节点间的网络

当使用 VLAN 在负载均衡服务和 control plane 节点之间路由流量时,外部负载平衡服务和 control plane 节点必须在同一个 L2 网络上运行,并使用 VLAN 来路由负载平衡服务和 control plane 节点之间的流量。

重要

存储接口需要 DHCP 保留或静态 IP。

下表提供了完全限定域名的实例化。API 和 Nameserver 地址以规范名称扩展开头。control plane 和 worker 节点的主机名是示例,您可以使用您喜欢的任何主机命名规则。

Expand
用法主机名IP

API

api.<cluster_name>.<base_domain>

<ip>

Ingress LB(apps)

*.apps.<cluster_name>.<base_domain>

<ip>

provisioner 节点

provisioner.<cluster_name>.<base_domain>

<ip>

control-plane-0

openshift-control-plane-0.<cluster_name>.<base_domain>

<ip>

Control-plane-1

openshift-control-plane-1.<cluster_name>-.<base_domain>

<ip>

Control-plane-2

openshift-control-plane-2.<cluster_name>.<base_domain>

<ip>

Worker-0

openshift-worker-0.<cluster_name>.<base_domain>

<ip>

Worker-1

openshift-worker-1.<cluster_name>.<base_domain>

<ip>

Worker-n

openshift-worker-n.<cluster_name>.<base_domain>

<ip>

注意

如果您不创建 DHCP 保留,安装程序需要反向 DNS 解析来为 Kubernetes API 节点、provisioner 节点、control plane 节点和 worker 节点设置主机名。

3.2.6.7. provisioner 节点要求

您必须在安装配置中为 provisioner 节点指定 MAC 地址。bootMacAddress 规范通常与 PXE 网络引导关联。但是,Ironic 置备服务还需要 bootMacAddress 规格,以便在检查集群期间或集群中重新部署节点时识别节点。

provisioner 节点需要第 2 层连接才能进行网络引导、DHCP 和 DNS 解析,以及本地网络通信。provisioner 节点需要第 3 层连接才能进行虚拟介质引导。

3.2.6.8. 网络时间协议(NTP)

集群中的每个 OpenShift Container Platform 节点都必须有权访问 NTP 服务器。OpenShift Container Platform 节点使用 NTP 来同步其时钟。例如,集群节点使用需要验证的 SSL/TLS 证书,如果节点之间的日期和时间未同步,则可能会失败。

重要

在每个群集节点的 BIOS 设置中定义一致的时钟日期和时间格式,或者安装可能会失败。

您可以重新配置 control plane 节点,作为断开连接的集群中的 NTP 服务器,并重新配置 worker 节点以从 control plane 节点检索时间。

3.2.6.9. 带外管理 IP 地址的端口访问

带外管理 IP 地址位于与节点分开的网络中。为确保带外管理可以在安装过程中与 provisioner 节点通信,带外管理 IP 地址必须被授予对 provisioner 节点和 OpenShift Container Platform control plane 节点上端口 6180 的访问权限。虚拟介质安装需要 TLS 端口 6183,例如使用 Redfish。

3.2.7. 配置节点

3.2.7.1. 在使用 provisioning 网络时配置节点

集群中的每个节点都需要以下配置才能正确安装。

警告

在节点间不匹配将导致安装失败。

虽然集群节点可以包含多于 2 个 NIC,但安装过程只关注于前两个 NIC:在下表中,NIC1 是一个不可路由的网络(置备),它仅用于安装 OpenShift Container Platform 集群。

Expand
NIC网络VLAN

NIC1

provisioning

<provisioning_vlan>

NIC2

baremetal

<baremetal_vlan>

provisioner 节点上的 Red Hat Enterprise Linux(RHEL) 9.x 安装过程可能会有所不同。要使用本地 Satellite 服务器或 PXE 服务器安装 Red Hat Enterprise Linux(RHEL) 9.x,PXE 启用 NIC2。

Expand
PXE引导顺序

NIC1 PXE-enabled provisioning 网络

1

NIC2 baremetal 网络.启用 PXE 是可选的。

2

注意

确保在所有其他 NIC 上禁用 PXE。

配置 control plane 和 worker 节点,如下所示:

Expand
PXE引导顺序

NIC1 PXE-enabled(调配网络)

1

安装过程需要一个 NIC:

Expand
NIC网络VLAN

NICx

baremetal

<baremetal_vlan>

NICx 是一个可路由的网络(baremetal),用于安装 OpenShift Container Platform 集群,并可路由到互联网。

重要

调配 网络是可选的,但 PXE 引导需要该网络。如果您在没有 provisioning 网络的情况下部署,则必须使用虚拟介质 BMC 寻址选项,如 redfish-virtualmediaidrac-virtualmedia

3.2.7.3. 为安全引导手动配置节点

安全引导可防止节点引导,除非它只验证节点只使用可信软件,如 UEFI 固件驱动程序、EFI 应用程序和操作系统。

注意

红帽仅在使用 Redfish 虚拟介质部署时支持手动配置安全引导机制。

要手动启用安全引导,请参阅节点的硬件指南并执行以下内容:

流程

  1. 引导节点并进入 BIOS 菜单。
  2. 将节点的引导模式设置为 UEFI Enabled
  3. 启用安全引导.
重要

红帽不支持使用自生成的密钥进行安全引导。

3.2.8. 带外管理

节点通常有一个额外的 NIC,供 Baseboard Management Controller(BMC)使用。这些 BMC 必须可以从 provisioner 节点访问。

每个节点必须通过带外管理进行访问。在使用带外管理网络时,provisioner 节点需要访问带外管理网络才能成功安装 OpenShift Container Platform。

带外管理设置超出了本文档的范围。使用单独的管理网络进行带外管理可能会提高性能并提高安全性。但是,使用 provisioning 网络或 baremetal 网络是有效的选项。

注意

bootstrap 虚拟机具有最多两个网络接口。如果您为带外管理配置一个单独的管理网络,并且您使用 provisioning 网络,bootstrap 虚拟机需要通过其中一个网络接口路由到管理网络。在这种情况下,bootstrap 虚拟机可以访问三个网络:

  • 裸机网络
  • provisioning 网络
  • 通过其中一个网络接口的管理网络

3.2.9. 安装所需的数据

在安装 OpenShift Container Platform 集群前,从所有集群节点收集以下信息:

  • 带外管理 IP

    • 示例

      • Dell(iDRAC)IP
      • HP(iLO)IP
      • Fujitsu(iRMC)IP

在使用 provisioning 网络时

  • NIC(置备)MAC 地址
  • NIC(裸机)MAC 地址

在省略 provisioning 网络时

  • NIC(裸机)MAC 地址

3.2.10. 节点验证清单

在使用 provisioning 网络时

  • ❏ 为 provisioning 网络配置了 NIC1 VLAN。
  • 置备网络的 NIC1 在 provisioner、control plane 和 worker 节点上启用了 PXE。
  • ❏ 为 baremetal 网络 配置了 NIC2 VLAN。
  • ❏ PXE 在所有其他 NIC 上都被禁用。
  • ❏ DNS 被配置为使用 API 和 Ingress 端点。
  • ❏ 已配置 control plane 和 worker 节点。
  • ❏ 所有节点都可通过带外管理访问。
  • ❏ (可选)已创建一个单独的管理网络。
  • ❏ 安装所需的数据。

在省略 provisioning 网络时

  • ❏ 为 baremetal 网络配置了 NIC1 VLAN。
  • ❏ DNS 被配置为使用 API 和 Ingress 端点。
  • ❏ 已配置 control plane 和 worker 节点。
  • ❏ 所有节点都可通过带外管理访问。
  • ❏ (可选)已创建一个单独的管理网络。
  • ❏ 安装所需的数据。

3.2.11. 安装概述

安装程序支持互动模式。但是,您可以提前准备一个 install-config.yaml 文件,其中包含所有裸机主机的置备详情,以及相关的集群详情。

安装程序加载 install-config.yaml 文件,管理员会生成清单并验证所有先决条件。

安装程序执行以下任务:

  • 注册集群中的所有节点
  • 启动 bootstrap 虚拟机(VM)
  • 启动裸机平台组件作为 systemd 服务,它们包括以下容器:

    • ironic-dnsmasq:负责将 IP 地址移入到置备网络上不同节点的调配接口的 DHCP 服务器。只有在使用 provisioning 网络部署 OpenShift Container Platform 集群时,才会启用 ironic-dnsmasq。
    • ironic-httpd :用于将镜像发送到节点的 HTTP 服务器。
    • Image-customization
    • Ironic
    • ironic-inspector (在 OpenShift Container Platform 4.16 及更早版本中可用)
    • Ironic-ramdisk-logs
    • Extract-machine-os
    • Provisioning-interface
    • Metal3-baremetal-operator

节点进入验证阶段,其中每个节点在 Ironic 验证凭证可以访问 Baseboard Management Controller (BMC) 后都会变为 manageable 状态。

当节点处于 manageable 状态时,inspection 阶段会启动。inspection 阶段可确保硬件满足成功部署 OpenShift Container Platform 所需的最低要求。

install-config.yaml 文件包括了 provisioning 网络的详情。在 bootstrap 虚拟机上,安装程序使用 Pre-Boot Execution Environment (PXE) 将实时镜像推送到载入的每个节点。在使用虚拟介质时,它会直接连接到每个节点的 BMC 来虚拟附加镜像。

在使用 PXE 引导时,所有节点都重新引导以启动该过程:

  • bootstrap 虚拟机上运行的 ironic-dnsmasq 服务提供节点的 IP 地址和 TFTP 引导服务器。
  • 第一引导软件通过 HTTP 加载 root 文件系统。
  • bootstrap 虚拟机上的 ironic 服务从每个节点接收硬件信息。

节点进入 cleaning 状态,其中每个节点都必须清理所有磁盘,然后才能继续配置。

在 cleaning 状态完成后,节点进入 available 状态,安装程序会将节点移到 deploying 状态。

IPA 运行 coreos-installer 命令,在 install-config.yaml 文件中的 rootDeviceHints 参数定义的磁盘上安装 Red Hat Enterprise Linux CoreOS (RHCOS) 镜像。节点使用 RHCOS 引导。

在安装程序配置了 control plane 节点后,它会将控制权从 bootstrap 虚拟机移到 control plane 节点,并删除 bootstrap 虚拟机。

Bare-Metal Operator 会继续部署 worker、存储和 infra 节点。

在安装完成后,节点将移至 active 状态。然后,您可以继续进行安装后配置,以及其他第 2 天任务。

3.3. 为 OpenShift 安装设置环境

3.3.1. 在置备程序节点上安装 RHEL

完成先决条件后,下一步是在置备程序节点上安装 RHEL 9.x。安装 OpenShift Container Platform 集群时,安装程序使用 provisioner 节点作为编配器。在本文档中,在 provisioner 节点上安装 RHEL 超出了范围。但是,选项包括但不限于使用 RHEL Satellite 服务器、PXE 或安装介质。

执行以下步骤准备环境。

流程

  1. 通过 ssh 登录到 provisioner 节点。
  2. 创建非 root 用户(kni)并为该用户提供 sudo 权限:

    # useradd kni
    Copy to Clipboard Toggle word wrap
    # passwd kni
    Copy to Clipboard Toggle word wrap
    # echo "kni ALL=(root) NOPASSWD:ALL" | tee -a /etc/sudoers.d/kni
    Copy to Clipboard Toggle word wrap
    # chmod 0440 /etc/sudoers.d/kni
    Copy to Clipboard Toggle word wrap
  3. 为新用户创建 ssh 密钥:

    # su - kni -c "ssh-keygen -t ed25519 -f /home/kni/.ssh/id_rsa -N ''"
    Copy to Clipboard Toggle word wrap
  4. 以新用户身份登录到 provisioner 节点:

    # su - kni
    Copy to Clipboard Toggle word wrap
  5. 使用 Red Hat Subscription Manager 注册 provisioner 节点:

    $ sudo subscription-manager register --username=<user> --password=<pass> --auto-attach
    Copy to Clipboard Toggle word wrap
    $ sudo subscription-manager repos --enable=rhel-9-for-<architecture>-appstream-rpms --enable=rhel-9-for-<architecture>-baseos-rpms
    Copy to Clipboard Toggle word wrap
    注意

    有关 Red Hat Subscription Manager 的更多信息,请参阅使用命令行工具注册 RHEL 系统

  6. 安装以下软件包:

    $ sudo dnf install -y libvirt qemu-kvm mkisofs python3-devel jq ipmitool
    Copy to Clipboard Toggle word wrap
  7. 修改用户,将 libvirt 组添加到新创建的用户:

    $ sudo usermod --append --groups libvirt <user>
    Copy to Clipboard Toggle word wrap
  8. 重启 firewalld 并启用 http 服务:

    $ sudo systemctl start firewalld
    Copy to Clipboard Toggle word wrap
    $ sudo firewall-cmd --zone=public --add-service=http --permanent
    Copy to Clipboard Toggle word wrap
    $ sudo firewall-cmd --reload
    Copy to Clipboard Toggle word wrap
  9. 启动模块 libvirt 守护进程套接字:

    $ for drv in qemu interface network nodedev nwfilter secret storage; do sudo systemctl start virt${drv}d{,-ro,-admin}.socket; done
    Copy to Clipboard Toggle word wrap
  10. 创建 默认 存储池并启动它:

    $ sudo virsh pool-define-as --name default --type dir --target /var/lib/libvirt/images
    Copy to Clipboard Toggle word wrap
    $ sudo virsh pool-start default
    Copy to Clipboard Toggle word wrap
    $ sudo virsh pool-autostart default
    Copy to Clipboard Toggle word wrap
  11. 创建 pull-secret.txt 文件:

    $ vim pull-secret.txt
    Copy to Clipboard Toggle word wrap

    在 Web 浏览器中,进入 Install OpenShift on Bare Metal with installer-provisioned infrastructure。点 Copy pull secret。将内容粘贴到 pull-secret.txt 文件中,并将内容保存到 kni 用户的主目录中。

3.3.3. 检查 NTP 服务器同步

OpenShift Container Platform 安装程序在集群节点上安装 chrony 网络时间协议(NTP)服务。要完成安装,每个节点都必须有权访问 NTP 时间服务器。您可以使用 chrony 服务验证 NTP 服务器同步。

对于断开连接的集群,您必须在 control plane 节点上配置 NTP 服务器。如需更多信息,请参阅附加资源部分

先决条件

  • 在目标节点上安装了 chrony 软件包。

流程

  1. 使用 ssh 命令登录节点。
  2. 运行以下命令,查看节点可用的 NTP 服务器:

    $ chronyc sources
    Copy to Clipboard Toggle word wrap

    输出示例

    MS Name/IP address         Stratum Poll Reach LastRx Last sample
    ===============================================================================
    ^+ time.cloudflare.com           3  10   377   187   -209us[ -209us] +/-   32ms
    ^+ t1.time.ir2.yahoo.com         2  10   377   185  -4382us[-4382us] +/-   23ms
    ^+ time.cloudflare.com           3  10   377   198   -996us[-1220us] +/-   33ms
    ^* brenbox.westnet.ie            1  10   377   193  -9538us[-9761us] +/-   24ms
    Copy to Clipboard Toggle word wrap

  3. 使用 ping 命令确保节点可以访问 NTP 服务器,例如:

    $ ping time.cloudflare.com
    Copy to Clipboard Toggle word wrap

    输出示例

    PING time.cloudflare.com (162.159.200.123) 56(84) bytes of data.
    64 bytes from time.cloudflare.com (162.159.200.123): icmp_seq=1 ttl=54 time=32.3 ms
    64 bytes from time.cloudflare.com (162.159.200.123): icmp_seq=2 ttl=54 time=30.9 ms
    64 bytes from time.cloudflare.com (162.159.200.123): icmp_seq=3 ttl=54 time=36.7 ms
    ...
    Copy to Clipboard Toggle word wrap

3.3.4. 配置网络

在安装前,您必须在 provisioner 节点上配置网络。安装程序置备的集群使用裸机网桥和网络部署,以及可选的 provisioning 网桥和网络。

注意

您还可以从 Web 控制台配置网络。

流程

  1. 运行以下命令导出裸机网络 NIC 名称:

    $ export PUB_CONN=<baremetal_nic_name>
    Copy to Clipboard Toggle word wrap
  2. 配置裸机网络:

    注意

    执行这些步骤后 SSH 连接可能会断开。

    1. 对于使用 DHCP 的网络,运行以下命令:

      $ sudo nohup bash -c "
          nmcli con down \"$PUB_CONN\"
          nmcli con delete \"$PUB_CONN\"
          # RHEL 8.1 appends the word \"System\" in front of the connection, delete in case it exists
          nmcli con down \"System $PUB_CONN\"
          nmcli con delete \"System $PUB_CONN\"
          nmcli connection add ifname baremetal type bridge <con_name> baremetal bridge.stp no 
      1
      
          nmcli con add type bridge-slave ifname \"$PUB_CONN\" master baremetal
          pkill dhclient;dhclient baremetal
      "
      Copy to Clipboard Toggle word wrap
      1
      <con_name> 替换为连接名称。
    2. 对于使用静态 IP 地址并且没有 DHCP 的网络,请运行以下命令:

      $ sudo nohup bash -c "
          nmcli con down \"$PUB_CONN\"
          nmcli con delete \"$PUB_CONN\"
          # RHEL 8.1 appends the word \"System\" in front of the connection, delete in case it exists
          nmcli con down \"System $PUB_CONN\"
          nmcli con delete \"System $PUB_CONN\"
          nmcli connection add ifname baremetal type bridge con-name baremetal bridge.stp no ipv4.method manual ipv4.addr "x.x.x.x/yy" ipv4.gateway "a.a.a.a" ipv4.dns "b.b.b.b" 
      1
      
          nmcli con add type bridge-slave ifname \"$PUB_CONN\" master baremetal
          nmcli con up baremetal
      "
      Copy to Clipboard Toggle word wrap
      1
      <con_name> 替换为连接名称。将 x.x.x.x/yy 替换为网络的 IP 地址和 CIDR。将 a.a.a.a 替换为网络网关。将 b.b.b.b 替换为 DNS 服务器的 IP 地址。
  3. 可选:如果您使用 provisioning 网络部署,请运行以下命令导出 provisioning 网络 NIC 名称:

    $ export PROV_CONN=<prov_nic_name>
    Copy to Clipboard Toggle word wrap
  4. 可选:如果您使用 provisioning 网络部署,请运行以下命令配置 provisioning 网络:

    $ sudo nohup bash -c "
        nmcli con down \"$PROV_CONN\"
        nmcli con delete \"$PROV_CONN\"
        nmcli connection add ifname provisioning type bridge con-name provisioning
        nmcli con add type bridge-slave ifname \"$PROV_CONN\" master provisioning
        nmcli connection modify provisioning ipv6.addresses fd00:1101::1/64 ipv6.method manual
        nmcli con down provisioning
        nmcli con up provisioning
    "
    Copy to Clipboard Toggle word wrap
    注意

    执行这些步骤后 SSH 连接可能会断开。

    IPv6 地址可以是任何无法通过裸机网络路由的地址。

    在使用 IPv6 地址时,请确保启用了 UEFI,并将 UEFI PXE 设置设置为 IPv6 协议。

  5. 可选:如果您使用 provisioning 网络部署,请运行以下命令在 provisioning 网络连接上配置 IPv4 地址:

    $ nmcli connection modify provisioning ipv4.addresses 172.22.0.254/24 ipv4.method manual
    Copy to Clipboard Toggle word wrap
  6. 运行以下命令,重新 SSH 到 provisioner 节点(如果需要):

    # ssh kni@provisioner.<cluster-name>.<domain>
    Copy to Clipboard Toggle word wrap
  7. 运行以下命令验证连接网桥是否已正确创建:

    $ sudo nmcli con show
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME               UUID                                  TYPE      DEVICE
    baremetal          4d5133a5-8351-4bb9-bfd4-3af264801530  bridge    baremetal
    provisioning       43942805-017f-4d7d-a2c2-7cb3324482ed  bridge    provisioning
    virbr0             d9bca40f-eee1-410b-8879-a2d4bb0465e7  bridge    virbr0
    bridge-slave-eno1  76a8ed50-c7e5-4999-b4f6-6d9014dd0812  ethernet  eno1
    bridge-slave-eno2  f31c3353-54b7-48de-893a-02d2b34c4736  ethernet  eno2
    Copy to Clipboard Toggle word wrap

除了使用 configure-ovs.sh shell 脚本在裸机平台上设置 br-ex 网桥的替代选择,您可以创建一个包括 NMState 配置文件的 MachineConfig 对象。主机 nmstate-configuration.servicenmstate.service 将 NMState 配置文件应用到集群中运行的每个节点。

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

  • 您需要对网桥进行安装后更改,如更改 Open vSwitch (OVS) 或 OVN-Kubernetes br-ex 网桥网络。configure-ovs.sh shell 脚本不支持对网桥进行安装后更改。
  • 您希望将网桥部署到与主机或服务器 IP 地址上可用的接口不同的接口上。
  • 您希望通过 configure-ovs.sh shell 脚本对网桥进行高级配置。对这些配置使用脚本可能会导致网桥无法连接多个网络接口,并无法正确处理接口之间的数据转发。
注意

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

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

警告

以下接口名称列表被保留,您不能使用带有 NMstate 配置的名称:

  • br-ext
  • br-int
  • br-local
  • br-nexthop
  • br0
  • ext-vxlan
  • ext
  • genev_sys_*
  • int
  • k8s-*
  • ovn-k8s-*
  • patch-br-*
  • tun0
  • vxlan_sys_*

先决条件

  • 可选: 已安装 nmstate API,以便您可以验证 NMState 配置。

流程

  1. 为您的自定义 br-ex 网桥网络创建一个使用 base64 信息的 NMState 配置文件:

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

    interfaces:
    - name: enp2s0 
    1
    
      type: ethernet 
    2
    
      state: up 
    3
    
      ipv4:
        enabled: false 
    4
    
      ipv6:
        enabled: false
    - name: br-ex
      type: ovs-bridge
      state: up
      ipv4:
        enabled: false
        dhcp: false
      ipv6:
        enabled: false
        dhcp: false
      bridge:
        options:
          mcast-snooping-enable: true
        port:
        - name: enp2s0 
    5
    
        - name: br-ex
    - name: br-ex
      type: ovs-interface
      state: up
      copy-mac-from: enp2s0
      ipv4:
        enabled: true
        dhcp: true
        auto-route-metric: 48 
    6
    
      ipv6:
        enabled: true
        dhcp: true
        auto-route-metric: 48
    # ...
    Copy to Clipboard Toggle word wrap

    1
    接口的名称。
    2
    以太网的类型。
    3
    创建后接口的请求状态。
    4
    在这个示例中禁用 IPv4 和 IPv6。
    5
    网桥附加到的节点 NIC。
    6
    将参数设置为 48,以确保 br-ex 默认路由始终具有最高的优先级(最低指标)。此配置可防止与 NetworkManager 服务自动配置的任何其他接口冲突。
  2. 使用 cat 命令对 NMState 配置的内容进行 base64 编码:

    $ cat <nmstate_configuration>.yaml | base64 
    1
    Copy to Clipboard Toggle word wrap
    1
    <nmstate_configuration> 替换为 NMState 资源 YAML 文件的名称。
  3. 创建 MachineConfig 清单文件,并定义一个自定义 br-ex 网桥网络配置,如下例所示:

    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: worker
      name: 10-br-ex-worker 
    1
    
    spec:
      config:
        ignition:
          version: 3.2.0
        storage:
          files:
          - contents:
              source: data:text/plain;charset=utf-8;base64,<base64_encoded_nmstate_configuration> 
    2
    
            mode: 0644
            overwrite: true
            path: /etc/nmstate/openshift/worker-0.yml 
    3
    
          - contents:
              source: data:text/plain;charset=utf-8;base64,<base64_encoded_nmstate_configuration>
            mode: 0644
            overwrite: true
            path: /etc/nmstate/openshift/worker-1.yml 
    4
    
    # ...
    Copy to Clipboard Toggle word wrap
    1
    策略的名称。
    2
    将编码的 base64 信息写入指定路径。
    3 4
    对于集群中的每个节点,指定节点的主机名路径以及机器类型的 base-64 编码 Ignition 配置文件数据。worker 角色是集群中节点的默认角色。如果为每个节点或 MachineConfig 清单文件中的所有节点设置了短主机名、 hostname -s、路径,.yaml 扩展将无法工作。

    如果您在要应用到集群中的所有节点的 /etc/nmstate/openshift/cluster.yml 配置文件中指定了单个全局配置,则不需要为每个节点指定短主机名路径,如 /etc/nmstate/openshift/<node_hostname>.yml。例如:

    # ...
          - contents:
              source: data:text/plain;charset=utf-8;base64,<base64_encoded_nmstate_configuration>
            mode: 0644
            overwrite: true
            path: /etc/nmstate/openshift/cluster.yml
    # ...
    Copy to Clipboard Toggle word wrap

后续步骤

  • 扩展计算节点,以将包含自定义 br-ex 网桥的 manifest 对象应用到集群中存在的每个计算节点。如需更多信息,请参阅附加资源部分中的"扩展集群"。
3.3.5.1. 将每个机器集扩展到计算节点

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

配置这些资源后,您必须扩展机器集,以便机器集可以将资源配置应用到每个计算节点并重新引导节点。

先决条件

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

流程

  1. 输入以下命令编辑 MachineConfig CR:

    $ oc edit mc <machineconfig_custom_resource_name>
    Copy to Clipboard Toggle word wrap
  2. 将每个计算节点配置添加到 CR,以便 CR 可以管理集群中每个定义的计算节点的角色。
  3. 创建名为 extraworker-secretSecret 对象,该对象具有最小的静态 IP 配置。
  4. 输入以下命令将 extraworker-secret secret 应用到集群中的每个节点。此步骤提供每个计算节点对 Ignition 配置文件的访问权限。

    $ oc apply -f ./extraworker-secret.yaml
    Copy to Clipboard Toggle word wrap
  5. 创建 BareMetalHost 资源并在 preprovisioningNetworkDataName 参数中指定网络 secret:

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

    apiVersion: metal3.io/v1alpha1
    kind: BareMetalHost
    spec:
    # ...
      preprovisioningNetworkDataName: ostest-extraworker-0-network-config-secret
    # ...
    Copy to Clipboard Toggle word wrap

  6. 要在集群的 openshift-machine-api 命名空间中管理 BareMetalHost 对象,请输入以下命令来更改命名空间:

    $ oc project openshift-machine-api
    Copy to Clipboard Toggle word wrap
  7. 获取机器集:

    $ oc get machinesets
    Copy to Clipboard Toggle word wrap
  8. 输入以下命令扩展每个机器集。您必须为每个机器集运行这个命令。

    $ oc scale machineset <machineset_name> --replicas=<n> 
    1
    Copy to Clipboard Toggle word wrap
    1
    其中 <machineset_name> 是机器集的名称,<n> 是计算节点的数量。

3.3.6. 为集群启用 OVS balance-slb 模式

您可以启用 Open vSwitch (OVS) balance-slb 模式,以便两个或多个物理接口共享其网络流量。balance-slb 模式接口可以为运行虚拟化工作负载的集群提供源负载均衡(SLB)功能,而无需与网络交换机协商。

目前,源负载均衡在绑定接口上运行,该接口连接到辅助网桥,如 br-phy。源负载均衡仅在不同的 Media Access Control (MAC)地址和虚拟局域网(VLAN)组合之间平衡。请注意,所有 OVN-Kubernetes pod 流量都使用相同的 MAC 地址和 VLAN,因此此流量无法在多个物理接口负载平衡。

下图显示了简单集群基础架构布局上的 balance-slb 模式。虚拟机(VM)连接到特定的 localnet NetworkAttachmentDefinition (NAD)自定义资源定义(CRD)、NAD 0NAD 1。每个 NAD 均为虚拟机提供对底层物理网络的访问,支持 VLAN 标记或未标记的流量。br-ex OVS 网桥从虚拟机接收流量,并将流量传递到下一个 OVS 网桥 br-phybr-phy 网桥作为 SLB 绑定的控制器。SLB 绑定通过物理接口链接(如 eno0eno1)平衡来自不同虚拟机端口的流量。此外,来自一个物理接口的入口流量可以通过一组 OVS 网桥来访问虚拟机。

图 3.1. OVS balance-slb 模式在带有两个 NAD 的 localnet 上运行

您可以使用 OVS 绑定将 balance-slb 模式接口集成到主或二级网络类型中。注意关于 OVS 绑定的以下点:

  • 支持 OVN-Kubernetes CNI 插件,并轻松与插件集成。
  • 原生支持 balance-slb 模式。

先决条件

  • 将多个物理接口附加到主网络,并在 MachineConfig 文件中定义接口。
  • 您创建了清单对象,并在对象配置文件中定义了自定义 br-ex 网桥。
  • 您附加了多个物理接口,并在 NAD CRD 文件中定义接口。

流程

  1. 对于集群中的每个裸机主机,在 install-config.yaml 文件中为集群定义一个 networkConfig 部分,如下例所示:

    # ...
    networkConfig:
      interfaces:
        - name: enp1s0 
    1
    
          type: ethernet
          state: up
          ipv4:
            dhcp: true
            enabled: true
          ipv6:
            enabled: false
        - name: enp2s0 
    2
    
          type: ethernet
          state: up
          mtu: 1500 
    3
    
          ipv4:
            dhcp: true
            enabled: true
          ipv6:
            dhcp: true
            enabled: true
        - name: enp3s0 
    4
    
          type: ethernet
          state: up
          mtu: 1500
          ipv4:
            enabled: false
          ipv6:
            enabled: false
    # ...
    Copy to Clipboard Toggle word wrap
    1
    置备的网络接口控制器(NIC)的接口。
    2
    在绑定接口的 Ignition 配置文件中拉取的第一个绑定接口。
    3
    在绑定端口上手动设置 br-ex 最大传输单元(MTU)。
    4
    第二个绑定接口是在集群安装过程中拉取 ignition 的最小配置的一部分。
  2. 在 NMState 配置文件中定义每个网络接口:

    定义许多网络接口的 NMState 配置文件示例

    ovn:
      bridge-mappings:
        - localnet: localnet-network
          bridge: br-ex
          state: present
    interfaces:
      - name: br-ex
        type: ovs-bridge
        state: up
        bridge:
          allow-extra-patch-ports: true
          port:
            - name: br-ex
            - name: patch-ex-to-phy
        ovs-db:
          external_ids:
            bridge-uplink: "patch-ex-to-phy"
      - name: br-ex
        type: ovs-interface
        state: up
        mtu: 1500 
    1
    
        ipv4:
          enabled: true
          dhcp: true
          auto-route-metric: 48
        ipv6:
          enabled: false
          dhcp: false
          auto-route-metric: 48
      - name: br-phy
        type: ovs-bridge
        state: up
        bridge:
          allow-extra-patch-ports: true
          port:
            - name: patch-phy-to-ex
            - name: ovs-bond
              link-aggregation:
                mode: balance-slb
                port:
                  - name: enp2s0
                  - name: enp3s0
      - name: patch-ex-to-phy
        type: ovs-interface
        state: up
        patch:
          peer: patch-phy-to-ex
      - name: patch-phy-to-ex
        type: ovs-interface
        state: up
        patch:
          peer: patch-ex-to-phy
      - name: enp1s0
        type: ethernet
        state: up
        ipv4:
          dhcp: true
          enabled: true
        ipv6:
          enabled: false
      - name: enp2s0
        type: ethernet
        state: up
        mtu: 1500
        ipv4:
          enabled: false
        ipv6:
          enabled: false
      - name: enp3s0
        type: ethernet
        state: up
        mtu: 1500
        ipv4:
          enabled: false
        ipv6:
          enabled: false
    # ...
    Copy to Clipboard Toggle word wrap

    1
    在绑定端口上手动设置 br-ex MTU。
  3. 使用 base64 命令对 NMState 配置文件的接口内容进行编码:

    $ base64 -w0  <nmstate_configuration>.yml 
    1
    Copy to Clipboard Toggle word wrap
    1
    其中 -w0 选项可防止在 base64 编码操作中换行。
  4. master 角色和 worker 角色创建 MachineConfig 清单文件。确保将之前命令中的 base64 编码的字符串嵌入到每个 MachineConfig 清单文件中。以下示例清单文件为集群中存在的所有节点配置 master 角色。您还可以为特定于节点的 masterworker 角色创建清单文件。

    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: master
      name: 10-br-ex-master 
    1
    
    spec:
      config:
        ignition:
          version: 3.2.0
        storage:
          files:
          - contents:
              source: data:text/plain;charset=utf-8;base64,<base64_encoded_nmstate_configuration> 
    2
    
            mode: 0644
            overwrite: true
            path: /etc/nmstate/openshift/cluster.yml 
    3
    Copy to Clipboard Toggle word wrap
    1
    策略的名称。
    2
    将编码的 base64 信息写入指定路径。
    3
    指定 cluster.yml 文件的路径。对于集群中的每个节点,您可以指定节点的短主机名路径,如 <node_short_hostname>.yml。
  5. 将每个 MachineConfig 清单文件保存到 ./& lt;installation_directory>/manifests 目录,其中 &lt ;installation_directory > 是安装程序在其中创建文件的目录。

    Machine Config Operator (MCO)从每个清单文件中获取内容,并在滚动更新期间持续将内容应用到所有所选节点。

3.3.7. 在子网间建立通信

在典型的 OpenShift Container Platform 集群设置中,所有节点(包括 control plane 和计算节点)都驻留在同一网络中。但是,对于边缘计算场景,定位接近边缘的计算节点会很有用。这通常涉及将不同的网络段或子网用于与 control plane 和本地计算节点使用的子网不同的网络段或子网。此类设置可以降低边缘的延迟并允许增强的可扩展性。

在安装 OpenShift Container Platform 前,您必须正确配置网络,以确保包含远程节点的边缘子网可以访问包含 control plane 节点的子网,并从 control plane 接收流量。

重要

在集群安装过程中,将永久 IP 地址分配给 install-config.yaml 配置文件的网络配置中的节点。如果不这样做,节点可能会被分配一个临时 IP 地址,该地址可能会影响流量到达节点的方式。例如,如果节点分配了临时 IP 地址,并且为节点配置了绑定接口,则绑定接口可能会收到不同的 IP 地址。

您可以通过配置用户管理的负载均衡器来代替默认负载均衡器,在同一子网或多个子网中运行 control plane 节点。使用多个子网环境,您可以降低 OpenShift Container Platform 集群因为硬件故障或网络中断而失败的问题。如需更多信息,请参阅"配置用户管理的负载均衡器"和"配置用户管理的负载均衡器"。

在多个子网环境中运行 control plane 节点需要完成以下关键任务:

  • 通过在 install-config.yaml 文件的 loadBalancer.type 参数中指定 UserManaged 来配置用户管理的负载均衡器,而不是默认的负载均衡器。
  • install-config.yaml 文件的 ingressVIPsapiVIPs 参数中配置用户管理的负载均衡器地址。
  • 将多个子网无类别域间路由 (CIDR) 和用户管理的负载均衡器 IP 地址添加到 install-config.yaml 文件中的 networking.machineNetworks 参数。
注意

使用多个子网部署集群需要使用虚拟介质,如 redfish-virtualmediaidrac-virtualmedia

此流程详细介绍了允许第二个子网中的远程计算节点与第一个子网中的 control plane 节点有效通信所需的网络配置,并允许第一个子网中的 control plane 节点与第二个子网中的远程 worker 节点有效通信。

在此过程中,集群跨越两个子网:

  • 第一个子网 (10.0.0.0) 包含 control plane 和本地计算节点。
  • 第二个子网 (192.168.0.0) 包含边缘计算节点。

流程

  1. 配置第一个子网与第二个子网通信:

    1. 运行以下命令,以 root 用户身份登录 control plane 节点:

      $ sudo su -
      Copy to Clipboard Toggle word wrap
    2. 运行以下命令,获取网络接口的名称:

      # nmcli dev status
      Copy to Clipboard Toggle word wrap
    3. 运行以下命令,通过网关向第二个子网(192.168.0.0)添加路由:

      # nmcli connection modify <interface_name> +ipv4.routes "192.168.0.0/24 via <gateway>"
      Copy to Clipboard Toggle word wrap

      <interface_name> 替换为接口名称。使用实际网关的 IP 地址替换 <gateway>

      示例

      # nmcli connection modify eth0 +ipv4.routes "192.168.0.0/24 via 192.168.0.1"
      Copy to Clipboard Toggle word wrap

    4. 运行以下命令来应用更改:

      # nmcli connection up <interface_name>
      Copy to Clipboard Toggle word wrap

      <interface_name> 替换为接口名称。

    5. 验证路由表以确保路由已被成功添加:

      # ip route
      Copy to Clipboard Toggle word wrap
    6. 对第一个子网中的每个 control plane 节点重复前面的步骤。

      注意

      调整命令以匹配您的实际接口名称和网关。

  2. 将第二个子网配置为与第一个子网通信:

    1. 运行以下命令,以 root 用户身份登录远程计算节点:

      $ sudo su -
      Copy to Clipboard Toggle word wrap
    2. 运行以下命令,获取网络接口的名称:

      # nmcli dev status
      Copy to Clipboard Toggle word wrap
    3. 运行以下命令,通过网关向第一个子网(10.0.0.0)添加路由:

      # nmcli connection modify <interface_name> +ipv4.routes "10.0.0.0/24 via <gateway>"
      Copy to Clipboard Toggle word wrap

      <interface_name> 替换为接口名称。使用实际网关的 IP 地址替换 <gateway>

      示例

      # nmcli connection modify eth0 +ipv4.routes "10.0.0.0/24 via 10.0.0.1"
      Copy to Clipboard Toggle word wrap

    4. 运行以下命令来应用更改:

      # nmcli connection up <interface_name>
      Copy to Clipboard Toggle word wrap

      <interface_name> 替换为接口名称。

    5. 运行以下命令,验证路由表以确保路由已被成功添加:

      # ip route
      Copy to Clipboard Toggle word wrap
    6. 对第二个子网中的每一计算节点重复前面的步骤。

      注意

      调整命令以匹配您的实际接口名称和网关。

  3. 配置网络后,测试连接以确保远程节点可以访问 control plane 节点,control plane 节点可以访问远程节点。

    1. 从第一个子网中的 control plane 节点,运行以下命令来 ping 第二个子网中的远程节点:

      $ ping <remote_node_ip_address>
      Copy to Clipboard Toggle word wrap

      如果 ping 成功,则意味着第一个子网中的 control plane 节点可以访问第二个子网中的远程节点。如果您没有收到响应,请检查网络配置并重复该节点的步骤。

    2. 在第二个子网中的远程节点中,运行以下命令来 ping 第一个子网中的 control plane 节点:

      $ ping <control_plane_node_ip_address>
      Copy to Clipboard Toggle word wrap

      如果 ping 成功,则意味着第二个子网中的远程计算节点可以访问第一个子网中的 control plane。如果您没有收到响应,请检查网络配置并重复该节点的步骤。

3.3.8. 检索 OpenShift Container Platform 安装程序

使用安装程序的 stable-4.x 版本和您选择的架构来部署 OpenShift Container Platform 的一般稳定版本:

$ export VERSION=stable-4.19
Copy to Clipboard Toggle word wrap
$ export RELEASE_ARCH=<architecture>
Copy to Clipboard Toggle word wrap
$ export RELEASE_IMAGE=$(curl -s https://mirror.openshift.com/pub/openshift-v4/$RELEASE_ARCH/clients/ocp/$VERSION/release.txt | grep 'Pull From: quay.io' | awk -F ' ' '{print $3}')
Copy to Clipboard Toggle word wrap

3.3.9. 提取 OpenShift Container Platform 安装程序

在获取安装程序后,下一步是提取它。

流程

  1. 设置环境变量:

    $ export cmd=openshift-baremetal-install
    Copy to Clipboard Toggle word wrap
    $ export pullsecret_file=~/pull-secret.txt
    Copy to Clipboard Toggle word wrap
    $ export extract_dir=$(pwd)
    Copy to Clipboard Toggle word wrap
  2. 获取 oc 二进制文件:

    $ curl -s https://mirror.openshift.com/pub/openshift-v4/clients/ocp/$VERSION/openshift-client-linux.tar.gz | tar zxvf - oc
    Copy to Clipboard Toggle word wrap
  3. 解压安装程序:

    $ sudo cp oc /usr/local/bin
    Copy to Clipboard Toggle word wrap
    $ oc adm release extract --registry-config "${pullsecret_file}" --command=$cmd --to "${extract_dir}" ${RELEASE_IMAGE}
    Copy to Clipboard Toggle word wrap
    $ sudo cp openshift-baremetal-install /usr/local/bin
    Copy to Clipboard Toggle word wrap

3.3.10. 创建 RHCOS 镜像缓存

要使用镜像缓存,您必须下载 bootstrap 虚拟机使用的 Red Hat Enterprise Linux CoreOS(RHCOS)镜像,以置备集群节点。镜像缓存是可选的,但在有限带宽的网络中运行安装程序时特别有用。

注意

安装程序不再需要 clusterOSImage RHCOS 镜像,因为正确的镜像位于发行版本有效负载中。

如果您在带有有限带宽的网络中运行安装程序,且 RHCOS 镜像下载时间超过 15 到 20 分钟,安装程序会超时。在这种情况下,将映像缓存到 Web 服务器上将有所帮助。

警告

如果为 HTTPD 服务器启用 TLS,您必须确认 root 证书由客户端信任的颁发机构签名,并验证 OpenShift Container Platform hub 和 spoke 集群和 HTTPD 服务器之间的可信证书链。使用配置了不受信任的证书的服务器可防止将镜像下载到创建镜像中。不支持使用不受信任的 HTTPS 服务器。

安装包含镜像的容器。

流程

  1. 安装 podman:

    $ sudo dnf install -y podman
    Copy to Clipboard Toggle word wrap
  2. 打开防火墙端口 8080 以用于 RHCOS 镜像缓存:

    $ sudo firewall-cmd --add-port=8080/tcp --zone=public --permanent
    Copy to Clipboard Toggle word wrap
    $ sudo firewall-cmd --reload
    Copy to Clipboard Toggle word wrap
  3. 创建用于存储 bootstraposimage 的目录:

    $ mkdir /home/kni/rhcos_image_cache
    Copy to Clipboard Toggle word wrap
  4. 为新创建的目录设置适当的 SELinux 上下文:

    $ sudo semanage fcontext -a -t httpd_sys_content_t "/home/kni/rhcos_image_cache(/.*)?"
    Copy to Clipboard Toggle word wrap
    $ sudo restorecon -Rv /home/kni/rhcos_image_cache/
    Copy to Clipboard Toggle word wrap
  5. 获取安装程序要在 bootstrap 虚拟机上部署的 RHCOS 镜像的 URI:

    $ export RHCOS_QEMU_URI=$(/usr/local/bin/openshift-baremetal-install coreos print-stream-json | jq -r --arg ARCH "$(arch)" '.architectures[$ARCH].artifacts.qemu.formats["qcow2.gz"].disk.location')
    Copy to Clipboard Toggle word wrap
  6. 获取安装程序要在 bootstrap 虚拟机上部署的镜像名称:

    $ export RHCOS_QEMU_NAME=${RHCOS_QEMU_URI##*/}
    Copy to Clipboard Toggle word wrap
  7. 获取要在 bootstrap 虚拟机上部署的 RHCOS 镜像的 SHA 哈希:

    $ export RHCOS_QEMU_UNCOMPRESSED_SHA256=$(/usr/local/bin/openshift-baremetal-install coreos print-stream-json | jq -r --arg ARCH "$(arch)" '.architectures[$ARCH].artifacts.qemu.formats["qcow2.gz"].disk["uncompressed-sha256"]')
    Copy to Clipboard Toggle word wrap
  8. 下载镜像并将其放在 /home/kni/rhcos_image_cache 目录中:

    $ curl -L ${RHCOS_QEMU_URI} -o /home/kni/rhcos_image_cache/${RHCOS_QEMU_NAME}
    Copy to Clipboard Toggle word wrap
  9. 为新文件确认 SELinux 类型为 httpd_sys_content_t

    $ ls -Z /home/kni/rhcos_image_cache
    Copy to Clipboard Toggle word wrap
  10. 创建 pod:

    $ podman run -d --name rhcos_image_cache \
    1
    
    -v /home/kni/rhcos_image_cache:/var/www/html \
    -p 8080:8080/tcp \
    registry.access.redhat.com/ubi9/httpd-24
    Copy to Clipboard Toggle word wrap
    1
    创建名为 rhcos_image_cache 的缓存 webserver。此 pod 在 install-config.yaml 文件中为部署提供 bootstrapOSImage 镜像。
  11. 生成 bootstrapOSImage 配置:

    $ export BAREMETAL_IP=$(ip addr show dev baremetal | awk '/inet /{print $2}' | cut -d"/" -f1)
    Copy to Clipboard Toggle word wrap
    $ export BOOTSTRAP_OS_IMAGE="http://${BAREMETAL_IP}:8080/${RHCOS_QEMU_NAME}?sha256=${RHCOS_QEMU_UNCOMPRESSED_SHA256}"
    Copy to Clipboard Toggle word wrap
    $ echo "    bootstrapOSImage=${BOOTSTRAP_OS_IMAGE}"
    Copy to Clipboard Toggle word wrap
  12. 在 platform. baremetal 下将所需的配置添加到 install-config.yaml 文件中:

    platform:
      baremetal:
        bootstrapOSImage: <bootstrap_os_image>  
    1
    Copy to Clipboard Toggle word wrap
    1
    <bootstrap_os_image> 替换为 $BOOTSTRAP_OS_IMAGE 的值。

    如需了解更多详细信息,请参阅"配置 install-config.yaml 文件"部分。

3.3.11. 用户管理的负载均衡器的服务

您可以将 OpenShift Container Platform 集群配置为使用用户管理的负载均衡器来代替默认负载均衡器。

重要

配置用户管理的负载均衡器取决于您的厂商的负载均衡器。

本节中的信息和示例仅用于指导目的。有关供应商负载均衡器的更多信息,请参阅供应商文档。

红帽支持用户管理的负载均衡器的以下服务:

  • Ingress Controller
  • OpenShift API
  • OpenShift MachineConfig API

您可以选择是否要为用户管理的负载均衡器配置一个或多个所有服务。仅配置 Ingress Controller 服务是一个通用的配置选项。要更好地了解每个服务,请查看以下图表:

图 3.2. 显示 OpenShift Container Platform 环境中运行的 Ingress Controller 的网络工作流示例

图 3.3. 显示 OpenShift Container Platform 环境中运行的 OpenShift API 的网络工作流示例

图 3.4. 显示 OpenShift Container Platform 环境中运行的 OpenShift MachineConfig API 的网络工作流示例

用户管理的负载均衡器支持以下配置选项:

  • 使用节点选择器将 Ingress Controller 映射到一组特定的节点。您必须为这个集合中的每个节点分配一个静态 IP 地址,或者将每个节点配置为从动态主机配置协议(DHCP)接收相同的 IP 地址。基础架构节点通常接收这种类型的配置。
  • 以子网上的所有 IP 地址为目标。此配置可减少维护开销,因为您可以在这些网络中创建和销毁节点,而无需重新配置负载均衡器目标。如果您使用较小的网络上的机器集来部署入口 pod,如 /27/28,您可以简化负载均衡器目标。

    提示

    您可以通过检查机器配置池的资源来列出网络中存在的所有 IP 地址。

在为 OpenShift Container Platform 集群配置用户管理的负载均衡器前,请考虑以下信息:

  • 对于前端 IP 地址,您可以对前端 IP 地址、Ingress Controller 的负载均衡器和 API 负载均衡器使用相同的 IP 地址。查看厂商的文档以获取此功能的相关信息。
  • 对于后端 IP 地址,请确保 OpenShift Container Platform control plane 节点的 IP 地址在用户管理的负载均衡器生命周期内不会改变。您可以通过完成以下操作之一来实现此目的:

    • 为每个 control plane 节点分配一个静态 IP 地址。
    • 将每个节点配置为在每次节点请求 DHCP 租期时从 DHCP 接收相同的 IP 地址。根据供应商,DHCP 租期可能采用 IP 保留或静态 DHCP 分配的形式。
  • 在 Ingress Controller 后端服务的用户管理的负载均衡器中手动定义运行 Ingress Controller 的每个节点。例如,如果 Ingress Controller 移到未定义节点,则可能会出现连接中断。
3.3.11.1. 配置用户管理的负载均衡器

您可以将 OpenShift Container Platform 集群配置为使用用户管理的负载均衡器来代替默认负载均衡器。

重要

在配置用户管理的负载均衡器前,请确保阅读用户管理的负载均衡器部分。

阅读适用于您要为用户管理的负载均衡器配置的服务的以下先决条件。

注意

MetalLB,在集群中运行,充当用户管理的负载均衡器。

OpenShift API 的先决条件

  • 您定义了前端 IP 地址。
  • TCP 端口 6443 和 22623 在负载均衡器的前端 IP 地址上公开。检查以下项:

    • 端口 6443 提供对 OpenShift API 服务的访问。
    • 端口 22623 可以为节点提供 ignition 启动配置。
  • 前端 IP 地址和端口 6443 可以被您的系统的所有用户访问,其位置为 OpenShift Container Platform 集群外部。
  • 前端 IP 地址和端口 22623 只能被 OpenShift Container Platform 节点访问。
  • 负载均衡器后端可以在端口 6443 和 22623 上与 OpenShift Container Platform control plane 节点通信。

Ingress Controller 的先决条件

  • 您定义了前端 IP 地址。
  • TCP 端口 443 和 80 在负载均衡器的前端 IP 地址上公开。
  • 前端 IP 地址、端口 80 和端口 443 可以被您的系统所有用户访问,以及 OpenShift Container Platform 集群外部的位置。
  • 前端 IP 地址、端口 80 和端口 443 可被 OpenShift Container Platform 集群中运行的所有节点访问。
  • 负载均衡器后端可以在端口 80、443 和 1936 上与运行 Ingress Controller 的 OpenShift Container Platform 节点通信。

健康检查 URL 规格的先决条件

您可以通过设置健康检查 URL 来配置大多数负载均衡器,以确定服务是否可用或不可用。OpenShift Container Platform 为 OpenShift API、Machine Configuration API 和 Ingress Controller 后端服务提供这些健康检查。

以下示例显示了之前列出的后端服务的健康检查规格:

Kubernetes API 健康检查规格示例

Path: HTTPS:6443/readyz
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 10
Interval: 10
Copy to Clipboard Toggle word wrap

Machine Config API 健康检查规格示例

Path: HTTPS:22623/healthz
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 10
Interval: 10
Copy to Clipboard Toggle word wrap

Ingress Controller 健康检查规格示例

Path: HTTP:1936/healthz/ready
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 5
Interval: 10
Copy to Clipboard Toggle word wrap

流程

  1. 配置 HAProxy Ingress Controller,以便您可以在端口 6443、22623、443 和 80 上从负载均衡器访问集群。根据您的需要,您可以在 HAProxy 配置中指定来自多个子网的单个子网或 IP 地址的 IP 地址。

    带有列出子网的 HAProxy 配置示例

    # ...
    listen my-cluster-api-6443
        bind 192.168.1.100:6443
        mode tcp
        balance roundrobin
      option httpchk
      http-check connect
      http-check send meth GET uri /readyz
      http-check expect status 200
        server my-cluster-master-2 192.168.1.101:6443 check inter 10s rise 2 fall 2
        server my-cluster-master-0 192.168.1.102:6443 check inter 10s rise 2 fall 2
        server my-cluster-master-1 192.168.1.103:6443 check inter 10s rise 2 fall 2
    
    listen my-cluster-machine-config-api-22623
        bind 192.168.1.100:22623
        mode tcp
        balance roundrobin
      option httpchk
      http-check connect
      http-check send meth GET uri /healthz
      http-check expect status 200
        server my-cluster-master-2 192.168.1.101:22623 check inter 10s rise 2 fall 2
        server my-cluster-master-0 192.168.1.102:22623 check inter 10s rise 2 fall 2
        server my-cluster-master-1 192.168.1.103:22623 check inter 10s rise 2 fall 2
    
    listen my-cluster-apps-443
        bind 192.168.1.100:443
        mode tcp
        balance roundrobin
      option httpchk
      http-check connect
      http-check send meth GET uri /healthz/ready
      http-check expect status 200
        server my-cluster-worker-0 192.168.1.111:443 check port 1936 inter 10s rise 2 fall 2
        server my-cluster-worker-1 192.168.1.112:443 check port 1936 inter 10s rise 2 fall 2
        server my-cluster-worker-2 192.168.1.113:443 check port 1936 inter 10s rise 2 fall 2
    
    listen my-cluster-apps-80
       bind 192.168.1.100:80
       mode tcp
       balance roundrobin
      option httpchk
      http-check connect
      http-check send meth GET uri /healthz/ready
      http-check expect status 200
        server my-cluster-worker-0 192.168.1.111:80 check port 1936 inter 10s rise 2 fall 2
        server my-cluster-worker-1 192.168.1.112:80 check port 1936 inter 10s rise 2 fall 2
        server my-cluster-worker-2 192.168.1.113:80 check port 1936 inter 10s rise 2 fall 2
    # ...
    Copy to Clipboard Toggle word wrap

    带有多个列出子网的 HAProxy 配置示例

    # ...
    listen api-server-6443
        bind *:6443
        mode tcp
          server master-00 192.168.83.89:6443 check inter 1s
          server master-01 192.168.84.90:6443 check inter 1s
          server master-02 192.168.85.99:6443 check inter 1s
          server bootstrap 192.168.80.89:6443 check inter 1s
    
    listen machine-config-server-22623
        bind *:22623
        mode tcp
          server master-00 192.168.83.89:22623 check inter 1s
          server master-01 192.168.84.90:22623 check inter 1s
          server master-02 192.168.85.99:22623 check inter 1s
          server bootstrap 192.168.80.89:22623 check inter 1s
    
    listen ingress-router-80
        bind *:80
        mode tcp
        balance source
          server worker-00 192.168.83.100:80 check inter 1s
          server worker-01 192.168.83.101:80 check inter 1s
    
    listen ingress-router-443
        bind *:443
        mode tcp
        balance source
          server worker-00 192.168.83.100:443 check inter 1s
          server worker-01 192.168.83.101:443 check inter 1s
    
    listen ironic-api-6385
        bind *:6385
        mode tcp
        balance source
          server master-00 192.168.83.89:6385 check inter 1s
          server master-01 192.168.84.90:6385 check inter 1s
          server master-02 192.168.85.99:6385 check inter 1s
          server bootstrap 192.168.80.89:6385 check inter 1s
    
    listen inspector-api-5050
        bind *:5050
        mode tcp
        balance source
          server master-00 192.168.83.89:5050 check inter 1s
          server master-01 192.168.84.90:5050 check inter 1s
          server master-02 192.168.85.99:5050 check inter 1s
          server bootstrap 192.168.80.89:5050 check inter 1s
    # ...
    Copy to Clipboard Toggle word wrap

  2. 使用 curl CLI 命令验证用户管理的负载均衡器及其资源是否正常运行:

    1. 运行以下命令并查看响应,验证集群机器配置 API 是否可以被 Kubernetes API 服务器资源访问:

      $ curl https://<loadbalancer_ip_address>:6443/version --insecure
      Copy to Clipboard Toggle word wrap

      如果配置正确,您会收到 JSON 对象的响应:

      {
        "major": "1",
        "minor": "11+",
        "gitVersion": "v1.11.0+ad103ed",
        "gitCommit": "ad103ed",
        "gitTreeState": "clean",
        "buildDate": "2019-01-09T06:44:10Z",
        "goVersion": "go1.10.3",
        "compiler": "gc",
        "platform": "linux/amd64"
      }
      Copy to Clipboard Toggle word wrap
    2. 运行以下命令并观察输出,验证集群机器配置 API 是否可以被 Machine 配置服务器资源访问:

      $ curl -v https://<loadbalancer_ip_address>:22623/healthz --insecure
      Copy to Clipboard Toggle word wrap

      如果配置正确,命令的输出会显示以下响应:

      HTTP/1.1 200 OK
      Content-Length: 0
      Copy to Clipboard Toggle word wrap
    3. 运行以下命令并观察输出,验证控制器是否可以被端口 80 上的 Ingress Controller 资源访问:

      $ curl -I -L -H "Host: console-openshift-console.apps.<cluster_name>.<base_domain>" http://<load_balancer_front_end_IP_address>
      Copy to Clipboard Toggle word wrap

      如果配置正确,命令的输出会显示以下响应:

      HTTP/1.1 302 Found
      content-length: 0
      location: https://console-openshift-console.apps.ocp4.private.opequon.net/
      cache-control: no-cache
      Copy to Clipboard Toggle word wrap
    4. 运行以下命令并观察输出,验证控制器是否可以被端口 443 上的 Ingress Controller 资源访问:

      $ curl -I -L --insecure --resolve console-openshift-console.apps.<cluster_name>.<base_domain>:443:<Load Balancer Front End IP Address> https://console-openshift-console.apps.<cluster_name>.<base_domain>
      Copy to Clipboard Toggle word wrap

      如果配置正确,命令的输出会显示以下响应:

      HTTP/1.1 200 OK
      referrer-policy: strict-origin-when-cross-origin
      set-cookie: csrf-token=UlYWOyQ62LWjw2h003xtYSKlh1a0Py2hhctw0WmV2YEdhJjFyQwWcGBsja261dGLgaYO0nxzVErhiXt6QepA7g==; Path=/; Secure; SameSite=Lax
      x-content-type-options: nosniff
      x-dns-prefetch-control: off
      x-frame-options: DENY
      x-xss-protection: 1; mode=block
      date: Wed, 04 Oct 2023 16:29:38 GMT
      content-type: text/html; charset=utf-8
      set-cookie: 1e2670d92730b515ce3a1bb65da45062=1bf5e9573c9a2760c964ed1659cc1673; path=/; HttpOnly; Secure; SameSite=None
      cache-control: private
      Copy to Clipboard Toggle word wrap
  3. 配置集群的 DNS 记录,使其以用户管理的负载均衡器的前端 IP 地址为目标。您必须在负载均衡器上将记录更新为集群 API 和应用程序的 DNS 服务器。

    修改 DNS 记录示例

    <load_balancer_ip_address>  A  api.<cluster_name>.<base_domain>
    A record pointing to Load Balancer Front End
    Copy to Clipboard Toggle word wrap

    <load_balancer_ip_address>   A apps.<cluster_name>.<base_domain>
    A record pointing to Load Balancer Front End
    Copy to Clipboard Toggle word wrap
    重要

    DNS 传播可能需要一些时间才能获得每个 DNS 记录。在验证每个记录前,请确保每个 DNS 记录传播。

  4. 要使 OpenShift Container Platform 集群使用用户管理的负载均衡器,您必须在集群的 install-config.yaml 文件中指定以下配置:

    # ...
    platform:
      baremetal:
        loadBalancer:
          type: UserManaged 
    1
    
        apiVIPs:
        - <api_ip> 
    2
    
        ingressVIPs:
        - <ingress_ip> 
    3
    
    # ...
    Copy to Clipboard Toggle word wrap
    1
    type 参数设置 UserManaged,为集群指定用户管理的负载均衡器。参数默认为 OpenShiftManagedDefault,它表示默认的内部负载均衡器。对于 openshift-kni-infra 命名空间中定义的服务,用户管理的负载均衡器可将 coredns 服务部署到集群中的 pod,但忽略 keepalivedhaproxy 服务。
    2
    指定用户管理的负载均衡器时所需的参数。指定用户管理的负载均衡器的公共 IP 地址,以便 Kubernetes API 可以与用户管理的负载均衡器通信。
    3
    指定用户管理的负载均衡器时所需的参数。指定用户管理的负载均衡器的公共 IP 地址,以便用户管理的负载均衡器可以管理集群的入口流量。

验证

  1. 使用 curl CLI 命令验证用户管理的负载均衡器和 DNS 记录配置是否正常工作:

    1. 运行以下命令并查看输出,验证您可以访问集群 API:

      $ curl https://api.<cluster_name>.<base_domain>:6443/version --insecure
      Copy to Clipboard Toggle word wrap

      如果配置正确,您会收到 JSON 对象的响应:

      {
        "major": "1",
        "minor": "11+",
        "gitVersion": "v1.11.0+ad103ed",
        "gitCommit": "ad103ed",
        "gitTreeState": "clean",
        "buildDate": "2019-01-09T06:44:10Z",
        "goVersion": "go1.10.3",
        "compiler": "gc",
        "platform": "linux/amd64"
        }
      Copy to Clipboard Toggle word wrap
    2. 运行以下命令并查看输出,验证您可以访问集群机器配置:

      $ curl -v https://api.<cluster_name>.<base_domain>:22623/healthz --insecure
      Copy to Clipboard Toggle word wrap

      如果配置正确,命令的输出会显示以下响应:

      HTTP/1.1 200 OK
      Content-Length: 0
      Copy to Clipboard Toggle word wrap
    3. 运行以下命令并查看输出,验证您可以在端口上访问每个集群应用程序:

      $ curl http://console-openshift-console.apps.<cluster_name>.<base_domain> -I -L --insecure
      Copy to Clipboard Toggle word wrap

      如果配置正确,命令的输出会显示以下响应:

      HTTP/1.1 302 Found
      content-length: 0
      location: https://console-openshift-console.apps.<cluster-name>.<base domain>/
      cache-control: no-cacheHTTP/1.1 200 OK
      referrer-policy: strict-origin-when-cross-origin
      set-cookie: csrf-token=39HoZgztDnzjJkq/JuLJMeoKNXlfiVv2YgZc09c3TBOBU4NI6kDXaJH1LdicNhN1UsQWzon4Dor9GWGfopaTEQ==; Path=/; Secure
      x-content-type-options: nosniff
      x-dns-prefetch-control: off
      x-frame-options: DENY
      x-xss-protection: 1; mode=block
      date: Tue, 17 Nov 2020 08:42:10 GMT
      content-type: text/html; charset=utf-8
      set-cookie: 1e2670d92730b515ce3a1bb65da45062=9b714eb87e93cf34853e87a92d6894be; path=/; HttpOnly; Secure; SameSite=None
      cache-control: private
      Copy to Clipboard Toggle word wrap
    4. 运行以下命令并查看输出,验证您可以在端口 443 上访问每个集群应用程序:

      $ curl https://console-openshift-console.apps.<cluster_name>.<base_domain> -I -L --insecure
      Copy to Clipboard Toggle word wrap

      如果配置正确,命令的输出会显示以下响应:

      HTTP/1.1 200 OK
      referrer-policy: strict-origin-when-cross-origin
      set-cookie: csrf-token=UlYWOyQ62LWjw2h003xtYSKlh1a0Py2hhctw0WmV2YEdhJjFyQwWcGBsja261dGLgaYO0nxzVErhiXt6QepA7g==; Path=/; Secure; SameSite=Lax
      x-content-type-options: nosniff
      x-dns-prefetch-control: off
      x-frame-options: DENY
      x-xss-protection: 1; mode=block
      date: Wed, 04 Oct 2023 16:29:38 GMT
      content-type: text/html; charset=utf-8
      set-cookie: 1e2670d92730b515ce3a1bb65da45062=1bf5e9573c9a2760c964ed1659cc1673; path=/; HttpOnly; Secure; SameSite=None
      cache-control: private
      Copy to Clipboard Toggle word wrap

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

在 Red Hat Enterprise Linux CoreOS (RHCOS)机器上,NetworkManager 会设置主机名。默认情况下,DHCP 为 NetworkManager 提供主机名,这是推荐的方法。在以下情况下,NetworkManager 通过反向 DNS 查找获取主机名:

  • 如果 DHCP 不提供主机名
  • 如果您使用内核参数设置主机名
  • 如果您使用其它方法设置主机名

反向 DNS 查找发生在网络在节点上初始化后,并可增加 NetworkManager 设置主机名所需的时间。其他系统服务可以在 NetworkManager 设置主机名之前启动,这可能会导致这些服务使用默认的主机名,如 localhost

提示

您可以使用 DHCP 为每个集群节点提供主机名,以避免在分配主机名时避免此延迟。另外,通过 DHCP 设置主机名可以绕过实施 DNS split-horizon 的环境中的手动 DNS 记录名称配置错误。

3.3.13. 配置本地仲裁节点

您可以配置带有两个 control plane 节点的 OpenShift Container Platform 集群,以及一个本地仲裁程序节点,以便在降低集群的基础架构成本时保持高可用性 (HA)。此配置只支持裸机安装。

重要

配置本地仲裁节点只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围

本地仲裁程序节点是一个低成本、共存的机器,它参与 control plane 仲裁决策。与标准的 control plane 节点不同,仲裁程序节点不会运行完整的 control plane 服务集合。通过此配置,只使用两个置备的 control plane 节点而不是三个就可以维护集群的高可用性(HA)。

重要

您只能配置本地仲裁节点。不支持远程仲裁程序节点。

要部署有两个 control plane 节点和一个本地仲裁节点的集群,您必须在 install-config.yaml 文件中定义以下节点:

  • 2 个 control plane 节点
  • 1 个仲裁节点

您必须在 FeatureGate 自定义资源(CR)中启用 TechPreviewNoUpgrade 功能集来启用仲裁节点功能。有关功能门的更多信息,请参阅 "Understanding feature gates"。

仲裁程序节点必须满足以下最低系统要求:

  • 2 个线程
  • 8 GB RAM
  • 120 GB SSD 或等同存储

仲裁程序节点必须位于带有小于 500 毫秒的端到端延迟(包括磁盘 I/O)的网络环境中。在高延迟环境中,您可能需要应用 etcd slow 配置集。

control plane 节点必须满足以下最低系统要求:

  • 4 个线程
  • 16 GB RAM
  • 120 GB SSD 或等同存储

另外,control plane 节点还必须有足够的存储工作负载。

先决条件

  • 您已下载了 OpenShift CLI (oc)和安装程序。
  • 您已登录到 OpenShift CLI (oc)。

流程

  1. 编辑 install-config.yaml 文件,以定义仲裁节点和 control plane 节点。

    用于部署仲裁节点的 install-config.yaml 配置示例

    apiVersion: v1
    baseDomain: devcluster.openshift.com
    compute:
      - architecture: amd64
        hyperthreading: Enabled
        name: worker
        platform: {}
        replicas: 0
    arbiter: 
    1
    
      architecture: amd64
      hyperthreading: Enabled
      replicas: 1 
    2
    
      name: arbiter 
    3
    
      platform:
        baremetal: {}
    controlPlane: 
    4
    
      architecture: amd64
      hyperthreading: Enabled
      name: master
      platform:
        baremetal: {}
      replicas: 2 
    5
    
    featureSet: TechPreviewNoUpgrade
    platform:
      baremetal:
    # ...
        hosts:
          - name: cluster-master-0
            role: master
    # ...
          - name: cluster-master-1
            role: master
            ...
          - name: cluster-arbiter-0
            role: arbiter
    # ...
    Copy to Clipboard Toggle word wrap

    1
    定义仲裁机器池。您必须将此字段配置为使用仲裁节点部署集群。
    2
    将 arbiter 池的 replicas 字段设置为 1。您不能将此字段设置为大于 1 的值。
    3
    为仲裁机器池指定一个名称。
    4
    定义 control plane 机器池。
    5
    当定义仲裁池时,两个 control plane 副本有效。
  2. 保存修改后的 install-config.yaml 文件。

后续步骤

3.3.14. 配置 install-config.yaml 文件

3.3.14.1. 配置 install-config.yaml 文件

install-config.yaml 文件需要一些额外的详情。大多数信息都教授安装程序,生成的集群有足够的集群来完全管理它。

注意

安装程序不再需要 clusterOSImage RHCOS 镜像,因为正确的镜像位于发行版本有效负载中。

  1. 配置 install-config.yaml。更改适当的变量以匹配环境,包括 pullSecretsshKey

    apiVersion: v1
    baseDomain: <domain>
    metadata:
      name: <cluster_name>
    networking:
      machineNetwork:
      - cidr: <public_cidr>
      networkType: OVNKubernetes
    compute:
    - name: worker
      replicas: 2 
    1
    
    controlPlane:
      name: master
      replicas: 3
      platform:
        baremetal: {}
    platform:
      baremetal:
        additionalNTPServers: 
    2
    
          - <ntp_domain_or_ip>
        apiVIPs:
          - <api_ip>
        ingressVIPs:
          - <wildcard_ip>
        provisioningNetworkCIDR: <CIDR>
        bootstrapExternalStaticIP: <bootstrap_static_ip_address> 
    3
    
        bootstrapExternalStaticGateway: <bootstrap_static_gateway> 
    4
    
        bootstrapExternalStaticDNS: <bootstrap_static_dns> 
    5
    
        hosts:
          - name: openshift-master-0
            role: master
            bmc:
              address: ipmi://<out_of_band_ip> 
    6
    
              username: <user>
              password: <password>
            bootMACAddress: <NIC1_mac_address>
            rootDeviceHints:
             deviceName: "<installation_disk_drive_path>" 
    7
    
          - name: <openshift_master_1>
            role: master
            bmc:
              address: ipmi://<out_of_band_ip>
              username: <user>
              password: <password>
            bootMACAddress: <NIC1_mac_address>
            rootDeviceHints:
             deviceName: "<installation_disk_drive_path>"
          - name: <openshift_master_2>
            role: master
            bmc:
              address: ipmi://<out_of_band_ip>
              username: <user>
              password: <password>
            bootMACAddress: <NIC1_mac_address>
            rootDeviceHints:
             deviceName: "<installation_disk_drive_path>"
          - name: <openshift_worker_0>
            role: worker
            bmc:
              address: ipmi://<out_of_band_ip>
              username: <user>
              password: <password>
            bootMACAddress: <NIC1_mac_address>
          - name: <openshift_worker_1>
            role: worker
            bmc:
              address: ipmi://<out_of_band_ip>
              username: <user>
              password: <password>
            bootMACAddress: <NIC1_mac_address>
            rootDeviceHints:
             deviceName: "<installation_disk_drive_path>"
    pullSecret: '<pull_secret>'
    sshKey: '<ssh_pub_key>'
    Copy to Clipboard Toggle word wrap
    1
    根据作为 OpenShift Container Platform 集群一部分的计算节点数量扩展计算机器。replicas 值可以是 0,以及大于或等于 2 的整数。将副本数设置为 0 以部署一个三节点集群,该集群仅包含三个 control plane 机器。三节点集群是一个较小的、效率更高的集群,可用于测试、开发和生产。您不能只使用一个计算节点安装集群。
    2
    当集群主机时钟不同步时,一个额外的 NTP 服务器域名或 IP 地址的可选列表会添加到每个主机配置中。
    3
    当使用静态 IP 地址部署集群时,您必须设置 bootstrapExternalStaticIP 配置设置,以便在裸机网络上没有 DHCP 服务器时可以指定 bootstrap 虚拟机的静态 IP 地址。
    4
    当使用静态 IP 地址部署集群时,您必须设置 bootstrapExternalStaticGateway 配置设置,以便当裸机网络上没有 DHCP 服务器时可以为 bootstrap 虚拟机指定网关 IP 地址。
    5
    当使用静态 IP 地址部署集群时,您必须设置 bootstrapExternalStaticDNS 配置设置,以便在裸机网络上没有 DHCP 服务器时指定 bootstrap 虚拟机的 DNS 地址。
    6
    如需了解更多选项,请参阅 BMC 寻址部分。
    7
    要设置安装磁盘驱动器的路径,请输入磁盘的内核名称。例如:/dev/sda
    重要

    由于磁盘发现顺序无法保证,因此磁盘的内核名称可以在具有多个磁盘的机器的引导选项之间更改。例如: /dev/sda 变为 /dev/sdb,反之亦然。要避免这个问题,您必须使用持久性磁盘属性,如 disk World Wide Name (WWN) 或 /dev/disk/by-path/。建议您使用 /dev/disk/by-path/<device_path> 链接到存储位置。要使用磁盘 WWN,请将 deviceName 参数替换为 wwnWithExtension 参数。根据您使用的参数,输入以下值之一:

    • 磁盘名称。例如: /dev/sda/dev/disk/by-path/
    • 磁盘 WWN。例如,"0x64cd98f04fde100024684cf3034da5c2"。确保您在引号中输入磁盘 WWN 值,使其用作字符串值,而不是十六进制值。

    无法满足 rootDeviceHints 参数的这些要求可能会导致以下错误:

    ironic-inspector inspection failed: No disks satisfied root device hints
    Copy to Clipboard Toggle word wrap
    注意

    在 OpenShift Container Platform 4.12 之前,集群安装程序只接受 apiVIPingressVIP 配置设置的 IPv4 地址或 IPv6 地址。在 OpenShift Container Platform 4.12 及更新的版本中,这些配置设置已弃用。反之,使用 apiVIPsingressVIPs 配置设置中的列表格式来指定 IPv4 地址、IPv6 地址或两个 IP 地址格式。

  2. 创建用于存储集群配置的目录:

    $ mkdir ~/clusterconfigs
    Copy to Clipboard Toggle word wrap
  3. install-config.yaml 文件复制到新目录中:

    $ cp install-config.yaml ~/clusterconfigs
    Copy to Clipboard Toggle word wrap
  4. 在安装 OpenShift Container Platform 集群前,请确保关闭所有裸机节点:

    $ ipmitool -I lanplus -U <user> -P <password> -H <management-server-ip> power off
    Copy to Clipboard Toggle word wrap
  5. 如果以前的部署尝试中保留了旧的 bootstrap 资源,请删除旧的 bootstrap 资源:

    for i in $(sudo virsh list | tail -n +3 | grep bootstrap | awk {'print $2'});
    do
      sudo virsh destroy $i;
      sudo virsh undefine $i;
      sudo virsh vol-delete $i --pool $i;
      sudo virsh vol-delete $i.ign --pool $i;
      sudo virsh pool-destroy $i;
      sudo virsh pool-undefine $i;
    done
    Copy to Clipboard Toggle word wrap
3.3.14.2. 其他 install-config 参数

下表列出了 install-config.yaml 文件所需的 参数hosts 参数和 bmc 参数。

Expand
表 3.9. 所需的参数
参数default描述

baseDomain

 

集群的域名。例如: example.com

bootMode

UEFI

节点的引导模式。选项为 legacyU EFI 和 UEFISecureBoot。如果没有设置 bootMode,Ironic 在检查节点时设置它。

platform:
  baremetal:
    bootstrapExternalStaticDNS
Copy to Clipboard Toggle word wrap
 

bootstrap 节点的静态网络 DNS。当裸机网络上没有动态主机配置协议 (DHCP) 服务器时,您必须使用静态 IP 地址部署集群时设置这个值。如果没有设置这个值,安装程序将使用 bootstrapExternalStaticGateway 的值,这会导致在网关和 DNS 的 IP 地址值不同时出现问题。

platform:
  baremetal:
    bootstrapExternalStaticIP
Copy to Clipboard Toggle word wrap
 

bootstrap 虚拟机的静态 IP 地址。当 bare-metal 网络中没有 DHCP 服务器时部署使用静态 IP 地址的集群时,必须设置这个值。

platform:
  baremetal:
    bootstrapExternalStaticGateway
Copy to Clipboard Toggle word wrap
 

bootstrap 虚拟机网关的静态 IP 地址。当 bare-metal 网络中没有 DHCP 服务器时部署使用静态 IP 地址的集群时,必须设置这个值。

sshKey

 

sshKey 配置设置包含 ~/.ssh/id_rsa.pub 文件中访问 control plane 节点和计算节点所需的密钥。通常,这个密钥来自 provisioner 节点。

pullSecret

 

pullSecret 配置设置包含准备 provisioner 节点时从 Install OpenShift on Bare Metal 页下载的 pull secret 的副本。

metadata:
    name:
Copy to Clipboard Toggle word wrap
 

OpenShift Container Platform 集群的名称。例如: openshift

networking:
    machineNetwork:
    - cidr:
Copy to Clipboard Toggle word wrap
 

外部网络的公共 CIDR(Classless Inter-Domain Routing)。例如:10.0.0.0/24

compute:
  - name: worker
Copy to Clipboard Toggle word wrap
 

OpenShift Container Platform 集群需要为计算节点提供一个名称,即使没有节点也是如此。

compute:
    replicas: 2
Copy to Clipboard Toggle word wrap
 

replicas 设置 OpenShift Container Platform 集群中的计算节点数量。

controlPlane:
    name: master
Copy to Clipboard Toggle word wrap
 

OpenShift Container Platform 集群需要一个 control plane 节点的名称。

controlPlane:
    replicas: 3
Copy to Clipboard Toggle word wrap
 

replicas 设置作为 OpenShift Container Platform 集群一部分的 control plane 节点数量。

arbiter:
    name: arbiter
Copy to Clipboard Toggle word wrap
 

OpenShift Container Platform 集群需要一个用于仲裁节点的名称。

arbiter:
    replicas: 1
Copy to Clipboard Toggle word wrap
 

replicas 参数为 OpenShift Container Platform 集群设置仲裁节点的数量。

provisioningNetworkInterface

 

连接到 provisioning 网络的节点上的网络接口名称。对于 OpenShift Container Platform 4.9 及更新的版本,使用 bootMACAddress 配置设置来启用 Ironic 标识 NIC 的 IP 地址,而不使用 provisioningNetworkInterface 配置设置来标识 NIC 的名称。

defaultMachinePlatform

 

用于没有平台配置的机器池的默认配置。

apiVIPs

 

(可选)用于 Kubernetes API 通信的虚拟 IP 地址。

您必须在 install-config.yaml 文件中提供此设置,作为来自 MachineNetwork 参数的保留 IP,或在 DNS 中预先配置了默认名称,以便正确解析默认名称。在 install-config.yaml 文件中的 apiVIPs 配置设置中添加值时,请使用虚拟 IP 地址而不是 FQDN。在使用双栈网络时,主 IP 地址必须来自 IPv4 网络。如果没有设置,安装程序将使用 api.<cluster_name>.<base_domain> 从 DNS 派生 IP 地址。

注意

在 OpenShift Container Platform 4.12 之前,集群安装程序只接受 apiVIP 配置设置的 IPv4 地址或 IPv6 地址。在 OpenShift Container Platform 4.12 或更高版本中,apiVIP 配置设置已弃用。反之,使用 apiVIPs 配置设置的列表格式来指定 IPv4 地址、IPv6 地址或两个 IP 地址格式。

disableCertificateVerification

False

RedFishredfish-virtualmedia 需要这个参数来管理 BMC 地址。当 BMC 地址使用自签名证书时,这个值应该是 True

ingressVIPs

 

(可选)入口流量的虚拟 IP 地址。

您必须在 install-config.yaml 文件中提供此设置,作为来自 MachineNetwork 参数的保留 IP,或在 DNS 中预先配置了默认名称,以便正确解析默认名称。在 install-config.yaml 文件中的 ingressVIPs 配置设置中添加值时,请使用虚拟 IP 地址而不是 FQDN。在使用双栈网络时,主 IP 地址必须来自 IPv4 网络。如果没有设置,安装程序将使用 test.apps.<cluster_name>.<base_domain> 从 DNS 派生 IP 地址。

注意

在 OpenShift Container Platform 4.12 之前,集群安装程序只接受 ingressVIP 配置设置的 IPv4 地址或 IPv6 地址。在 OpenShift Container Platform 4.12 及更新的版本中,ingressVIP 配置设置已弃用。反之,使用 ingressVIPs 配置设置的列表格式来指定 IPv4 地址、IPv6 地址或两个 IP 地址格式。

Expand
表 3.10. 可选参数
参数default描述
platform:
  baremetal:
    additionalNTPServers:
    - <ip_address_or_domain_name>
Copy to Clipboard Toggle word wrap
 

要添加到每个主机的额外 NTP 服务器的一个可选列表。您可以使用 IP 地址或域名来指定每个 NTP 服务器。其他 NTP 服务器是用户定义的 NTP 服务器,可在集群主机时钟不同步时启用预安装时钟同步。

provisioningDHCPRange

172.22.0.10,172.22.0.100

定义 provisioning 网络上节点的 IP 范围。

provisioningNetworkCIDR

172.22.0.0/24

用于置备的网络的 CIDR。当 provisioning 网络中不使用默认地址范围时,安装程序需要这个选项。

clusterProvisioningIP

provisioningNetworkCIDR 的第三个 IP 地址。

运行置备服务的集群中的 IP 地址。默认为 provisioning 子网的第三个 IP 地址。例如: 172.22.0.3

bootstrapProvisioningIP

provisioningNetworkCIDR 的第二个 IP 地址。

在安装程序部署 control plane (master)节点时运行置备服务的 bootstrap 虚拟机上的 IP 地址。默认为 provisioning 子网的第二个 IP 地址。例如: 172.22.0.2 或 2620:52:0:1307::2

externalBridge

baremetal

附加到裸机网络的虚拟机监控程序的裸机网桥名称。

provisioningBridge

provisioning

附加到 provisioning 网络的 provisioner 主机上的 provisioning 网桥的名称。

架构

 

定义集群的主机架构。有效值为 amd64arm64

defaultMachinePlatform

 

用于没有平台配置的机器池的默认配置。

bootstrapOSImage

 

用于覆盖 bootstrap 节点的默认操作系统镜像的 URL。URL 必须包含镜像的 SHA-256 哈希。例如: https://mirror.openshift.com/rhcos-<version>-qemu.qcow2.gz?sha256=<uncompressed_sha256>

provisioningNetwork

 

provisioningNetwork 配置设置决定了集群是否使用 provisioning 网络。如果存在,配置设置也会决定集群是否管理网络。

disabled :将此参数设置为 Disabled,以禁用对 provisioning 网络的要求。当设置为 Disabled 时,您必须只使用基于虚拟介质的置备,或使用 Assisted Installer 启动集群。如果设置为 Disabled 并使用电源管理,则必须可从裸机网络访问 BMC。如果设置为 Disabled,则必须在安装程序用于置备服务的裸机网络上提供两个 IP 地址。

Managed :将此参数设置为 Managed( 默认设置),以全面管理调配网络,包括 DHCP、TFTP 等。

Unmanaged :将此参数 设置为 Unmanaged 以启用调配网络,但需要手动配置 DHCP。建议进行虚拟介质调配,但在需要时仍可使用 PXE。

httpProxy

 

将此参数设置为环境中使用的适当 HTTP 代理。

httpsProxy

 

将此参数设置为环境中使用的适当 HTTPS 代理。

noProxy

 

将此参数设置为适合环境中代理使用的排除项。

3.3.14.2.1. 主机

hosts 参数是用于构建集群的独立裸机资产列表。

Expand
表 3.11. 主机
名称default描述

名称

 

与详细信息 关联的 BareMetalHost 资源的名称。例如: openshift-master-0

role

 

裸机节点的角色。master (control plane 节点) 或 worker (计算节点)。

bmc

 

基板管理控制器的连接详情。如需了解更多详细信息,请参阅 BMC 寻址部分。

bootMACAddress

 

主机用于 provisioning 网络的 NIC 的 MAC 地址。Ironic 使用 bootMACAddress 配置设置检索 IP 地址。然后,它将绑定到 主机。

注意

如果您禁用了 provisioning 网络,则必须从主机提供有效的 MAC 地址。

networkConfig

 

设置此可选参数来配置主机的网络接口。如需了解更多详细信息,请参阅"(可选)配置主机网络接口"。

3.3.14.3. BMC 地址

大多数供应商支持使用智能平台管理接口(IPMI)寻址的基板管理控制器(BMC)。IPMI 不加密通信。它适用于通过安全或专用管理网络在数据中心内使用。检查您的供应商,了解它们是否支持 Redfish 网络引导。RedFish 为融合、混合型 IT 和软件定义型数据中心(SDDC)提供简单而安全的管理。RedFish 是人类可读的,能够使用通用的互联网和 Web 服务标准将信息直接公开给现代工具链。如果您的硬件不支持 Redfish 网络引导,请使用 IPMI。

如果节点处于 Registering 状态,则可以在安装过程中修改 BMC 地址。当节点已不再为 Registering 状态时,如果需要修改 BMC 地址,您需要首先断开节点与 Ironic 的连接,编辑 BareMetalHost 资源,并将节点重新连接到 Ironic。详情请参阅编辑 BareMetalHost 资源部分。

3.3.14.3.1. IPMI

使用 IPMI 的主机使用 ipmi://<out-of-band-ip>:<port> 地址格式,如果未指定则默认为端口 623。以下示例演示了 install-config.yaml 文件中的 IPMI 配置。

platform:
  baremetal:
    hosts:
      - name: openshift-master-0
        role: master
        bmc:
          address: ipmi://<out-of-band-ip>
          username: <user>
          password: <password>
Copy to Clipboard Toggle word wrap
重要

当 PXE 引导使用 IPMI 进行 BMC 寻址时,需要 provisioning 网络。没有 provisioning 网络,就无法 PXE 引导主机。如果您在没有 provisioning 网络的情况下部署,则必须使用虚拟介质 BMC 寻址选项,如 redfish-virtualmediaidrac-virtualmedia。详情请查看 "Redfish 虚拟介质 for HPE iLO" 部分的"适用于 HPE iLO 的 BMC 寻址"部分或"适用于戴尔 iDRAC 的"红帽虚拟媒体"部分中的"红帽虚拟介质"。

3.3.14.3.2. RedFish 网络引导

要启用 Redfish,请使用 redfish://redfish+http:// 禁用 TLS。安装程序需要主机名或 IP 地址,以及系统 ID 的路径。以下示例演示了 install-config.yaml 文件中的 Redfish 配置。

platform:
  baremetal:
    hosts:
      - name: openshift-master-0
        role: master
        bmc:
          address: redfish://<out-of-band-ip>/redfish/v1/Systems/1
          username: <user>
          password: <password>
Copy to Clipboard Toggle word wrap

虽然建议为带外管理地址提供颁发机构证书,但在使用自签名证书时,您必须在 bmc 配置中包含 disableCertificateVerification: True。以下示例演示了在 install-config.yaml 文件中使用 disableCertificateVerification: True 配置参数的 Redfish 配置。

platform:
  baremetal:
    hosts:
      - name: openshift-master-0
        role: master
        bmc:
          address: redfish://<out-of-band-ip>/redfish/v1/Systems/1
          username: <user>
          password: <password>
          disableCertificateVerification: True
Copy to Clipboard Toggle word wrap
3.3.14.4. 验证对 Redfish API 的支持

当使用 Redfish API 安装时,安装程序会在裸机上使用安装程序置备的基础架构时,调用基板管理控制器 (BMC) 上的几个 Redfish 端点。如果使用 Redfish,请确保 BMC 在安装前支持所有 Redfish API。

流程

  1. 运行以下命令设置 BMC 的 IP 地址或主机名:

    $ export SERVER=<ip_address> 
    1
    Copy to Clipboard Toggle word wrap
    1
    <ip_address> 替换为 BMC 的 IP 地址或主机名。
  2. 运行以下命令设定系统的 ID:

    $ export SystemID=<system_id> 
    1
    Copy to Clipboard Toggle word wrap
    1
    <system_id> 替换为系统 ID。例如:System.Embedded.11。详情请查看以下特定于供应商的 BMC 部分。

Redfish API 列表

  1. 运行以下命令检查 power on 支持:

    $ curl -u $USER:$PASS -X POST -H'Content-Type: application/json' -H'Accept: application/json' -d '{"ResetType": "On"}' https://$SERVER/redfish/v1/Systems/$SystemID/Actions/ComputerSystem.Reset
    Copy to Clipboard Toggle word wrap
  2. 运行以下命令检查 power off 支持:

    $ curl -u $USER:$PASS -X POST -H'Content-Type: application/json' -H'Accept: application/json' -d '{"ResetType": "ForceOff"}' https://$SERVER/redfish/v1/Systems/$SystemID/Actions/ComputerSystem.Reset
    Copy to Clipboard Toggle word wrap
  3. 运行以下命令,检查使用 pxe 的临时引导实现:

    $ curl -u $USER:$PASS -X PATCH -H "Content-Type: application/json" -H "If-Match: <ETAG>"  https://$Server/redfish/v1/Systems/$SystemID/ -d '{"Boot": {"BootSourceOverrideTarget": "pxe", "BootSourceOverrideEnabled": "Once"}}
    Copy to Clipboard Toggle word wrap
  4. 运行以下命令,检查使用 LegacyUEFI 的固件引导模式的状态:

    $ curl -u $USER:$PASS -X PATCH -H "Content-Type: application/json" -H "If-Match: <ETAG>"  https://$Server/redfish/v1/Systems/$SystemID/ -d '{"Boot": {"BootSourceOverrideMode":"UEFI"}}
    Copy to Clipboard Toggle word wrap

Redfish 虚拟介质 API 列表

  1. 运行以下命令,检查使用 cddvd 的临时引导设备的功能:

    $ curl -u $USER:$PASS -X PATCH -H "Content-Type: application/json" -H "If-Match: <ETAG>" https://$Server/redfish/v1/Systems/$SystemID/ -d '{"Boot": {"BootSourceOverrideTarget": "cd", "BootSourceOverrideEnabled": "Once"}}'
    Copy to Clipboard Toggle word wrap
  2. 虚拟介质可能会根据您的硬件使用 POSTPATCH。运行以下命令之一检查挂载虚拟介质的功能:

    $ curl -u $USER:$PASS -X POST -H "Content-Type: application/json" https://$Server/redfish/v1/Managers/$ManagerID/VirtualMedia/$VmediaId -d '{"Image": "https://example.com/test.iso", "TransferProtocolType": "HTTPS", "UserName": "", "Password":""}'
    Copy to Clipboard Toggle word wrap
    $ curl -u $USER:$PASS -X PATCH -H "Content-Type: application/json" -H "If-Match: <ETAG>" https://$Server/redfish/v1/Managers/$ManagerID/VirtualMedia/$VmediaId -d '{"Image": "https://example.com/test.iso", "TransferProtocolType": "HTTPS", "UserName": "", "Password":""}'
    Copy to Clipboard Toggle word wrap
注意

Redfish API 的 PowerOnPowerOff 命令与 Redfish 虚拟介质 API 相同。在某些硬件中,您可能仅能在 Systems/$SystemID 下而不是 Managers/$ManagerID 下找到 VirtualMedia 资源。对于 VirtualMedia 资源,UserNamePassword 字段是可选的。

重要

HTTPSHTTPTransferProtocolTypes 唯一支持的参数类型。

3.3.14.5. 适用于 Dell iDRAC 的 BMC 寻址

每个 bmc 条目的 address 配置设置是连接到 OpenShift Container Platform 集群节点的 URL,包括 URL 方案中的控制器类型及其网络中的位置。每个 bmc 条目的 username 配置都必须指定具有 Administrator 特权的用户。

platform:
  baremetal:
    hosts:
      - name: <hostname>
        role: <master | worker>
        bmc:
          address: <address> 
1

          username: <user> 
2

          password: <password>
Copy to Clipboard Toggle word wrap
1
地址 配置设置指定协议。
2
username 配置设置必须指定具有 Administrator 特权的用户。

对于 Dell 硬件,红帽支持集成 Dell Remote Access Controller(iDRAC)虚拟介质、Redfish 网络引导和 IPMI。

3.3.14.5.1. Dell iDRAC 的 BMC 地址格式
Expand
协议地址格式

iDRAC 虚拟介质

idrac-virtualmedia://<out_of_band_ip>/redfish/v1/Systems/System.Embedded.1

RedFish 网络引导

redfish://<out_of_band_ip>/redfish/v1/Systems/System.Embedded.1

IPMI

ipmi://<out_of_band_ip>

重要

使用 idrac-virtualmedia 作为 Redfish 虚拟介质的协议。RedFish-virtualmedia 无法在 Dell 硬件上运行。Dell 的 idrac-virtualmedia 使用带 Dell OEM 扩展的 Redfish 标准。

详情请查看以下部分。

3.3.14.5.2. Dell iDRAC 的 RedFish 虚拟介质

对于 Dell 服务器上的 Redfish 虚拟介质,在 address 设置中使用 idrac-virtualmedia://。使用 redfish-virtualmedia:// 无法正常工作。

注意

使用 idrac-virtualmedia:// 作为 Redfish 虚拟介质的协议。使用 redfish-virtualmedia:// 无法在 Dell 硬件中工作,因为 idrac-virtualmedia:// 协议与 Ironic 中的 idrac 硬件类型和 Redfish 协议对应。Dell 的 idrac-virtualmedia:// 协议使用带有 Dell OEM 扩展的 Redfish 标准。Ironic 还支持带有 WSMAN 协议的 idrac 类型。因此,您必须指定 idrac-virtualmedia://,以避免在 Dell 硬件上选择使用 Redfish 和虚拟介质时出现意外行为。

以下示例演示了在 install-config.yaml 文件中使用 iDRAC 虚拟介质。

platform:
  baremetal:
    hosts:
      - name: openshift-master-0
        role: master
        bmc:
          address: idrac-virtualmedia://<out_of_band_ip>/redfish/v1/Systems/System.Embedded.1
          username: <user>
          password: <password>
Copy to Clipboard Toggle word wrap

虽然建议为带外管理地址提供颁发机构证书,但在使用自签名证书时,您必须在 bmc 配置中包含 disableCertificateVerification: True

注意

通过 iDRAC 控制台,确保 OpenShift Container Platform 集群节点启用了 AutoAttach。菜单路径为: ConfigurationVirtual MediaAttach ModeAutoAttach

以下示例演示了在 install-config.yaml 文件中使用 disableCertificateVerification: True 配置参数的 Redfish 配置。

platform:
  baremetal:
    hosts:
      - name: openshift-master-0
        role: master
        bmc:
          address: idrac-virtualmedia://<out_of_band_ip>/redfish/v1/Systems/System.Embedded.1
          username: <user>
          password: <password>
          disableCertificateVerification: True
Copy to Clipboard Toggle word wrap
3.3.14.5.3. iDRAC 的 RedFish 网络引导

要启用 Redfish,请使用 redfish://redfish+http:// 禁用传输层安全(TLS)。安装程序需要主机名或 IP 地址以及到系统 ID 的路径。以下示例演示了 install-config.yaml 文件中的 Redfish 配置。

platform:
  baremetal:
    hosts:
      - name: openshift-master-0
        role: master
        bmc:
          address: redfish://<out_of_band_ip>/redfish/v1/Systems/System.Embedded.1
          username: <user>
          password: <password>
Copy to Clipboard Toggle word wrap

虽然建议为带外管理地址提供颁发机构证书,但在使用自签名证书时,您必须在 bmc 配置中包含 disableCertificateVerification: True。以下示例演示了在 install-config.yaml 文件中使用 disableCertificateVerification: True 配置参数的 Redfish 配置。

platform:
  baremetal:
    hosts:
      - name: openshift-master-0
        role: master
        bmc:
          address: redfish://<out_of_band_ip>/redfish/v1/Systems/System.Embedded.1
          username: <user>
          password: <password>
          disableCertificateVerification: True
Copy to Clipboard Toggle word wrap
注意

Dell iDRAC 9 中存在一个已知问题,带有固件版本 04.40.00.00,所有版本都包括 5xx 系列,用于裸机部署中的安装程序置备安装。虚拟控制台插件默认为 eHTML5,它是 HTML5 的增强版本,这会导致 InsertVirtualMedia 工作流出现问题。将插件设置为使用 HTML5 以避免出现这个问题。菜单路径为 ConfigurationVirtual consolePlug-in TypeHTML5

通过 iDRAC 控制台,确保 OpenShift Container Platform 集群节点启用了 AutoAttach。菜单路径为: ConfigurationVirtual MediaAttach ModeAutoAttach

3.3.14.6. HPE iLO 的 BMC 寻址

每个 bmc 条目 的地址 字段是连接到 OpenShift Container Platform 集群节点的 URL,包括 URL 方案中的控制器类型及其网络中的位置。

platform:
  baremetal:
    hosts:
      - name: <hostname>
        role: <master | worker>
        bmc:
          address: <address> 
1

          username: <user>
          password: <password>
Copy to Clipboard Toggle word wrap
1
地址 配置设置指定协议。

对于 HPE 集成 Lights Out(iLO),红帽支持红帽虚拟媒体、Redfish 网络引导和 IPMI。

Expand
表 3.12. HPE iLO 的 BMC 地址格式
协议地址格式

RedFish 虚拟介质

redfish-virtualmedia://<out-of-band-ip>/redfish/v1/Systems/1

RedFish 网络引导

redfish://<out-of-band-ip>/redfish/v1/Systems/1

IPMI

ipmi://<out-of-band-ip>

详情请查看以下部分。

3.3.14.6.1. HPE iLO 的 RedFish 虚拟介质

要为 HPE 服务器启用 Redfish 虚拟介质,请在 address 设置中使用 redfish-virtualmedia://。以下示例演示了在 install-config.yaml 文件中使用 Redfish 虚拟介质。

platform:
  baremetal:
    hosts:
      - name: openshift-master-0
        role: master
        bmc:
          address: redfish-virtualmedia://<out-of-band-ip>/redfish/v1/Systems/1
          username: <user>
          password: <password>
Copy to Clipboard Toggle word wrap

虽然建议为带外管理地址提供颁发机构证书,但在使用自签名证书时,您必须在 bmc 配置中包含 disableCertificateVerification: True。以下示例演示了在 install-config.yaml 文件中使用 disableCertificateVerification: True 配置参数的 Redfish 配置。

platform:
  baremetal:
    hosts:
      - name: openshift-master-0
        role: master
        bmc:
          address: redfish-virtualmedia://<out-of-band-ip>/redfish/v1/Systems/1
          username: <user>
          password: <password>
          disableCertificateVerification: True
Copy to Clipboard Toggle word wrap
注意

运行 iLO4 的 9 代系统上不支持 RedFish 虚拟介质,因为 Ironic 不支持使用虚拟介质的 iLO4。

3.3.14.6.2. HPE iLO 的 RedFish 网络引导

要启用 Redfish,请使用 redfish://redfish+http:// 禁用 TLS。安装程序需要主机名或 IP 地址,以及系统 ID 的路径。以下示例演示了 install-config.yaml 文件中的 Redfish 配置。

platform:
  baremetal:
    hosts:
      - name: openshift-master-0
        role: master
        bmc:
          address: redfish://<out-of-band-ip>/redfish/v1/Systems/1
          username: <user>
          password: <password>
Copy to Clipboard Toggle word wrap

虽然建议为带外管理地址提供颁发机构证书,但在使用自签名证书时,您必须在 bmc 配置中包含 disableCertificateVerification: True。以下示例演示了在 install-config.yaml 文件中使用 disableCertificateVerification: True 配置参数的 Redfish 配置。

platform:
  baremetal:
    hosts:
      - name: openshift-master-0
        role: master
        bmc:
          address: redfish://<out-of-band-ip>/redfish/v1/Systems/1
          username: <user>
          password: <password>
          disableCertificateVerification: True
Copy to Clipboard Toggle word wrap
3.3.14.7. Fujitsu iRMC 的 BMC 寻址

每个 bmc 条目 的地址 字段是连接到 OpenShift Container Platform 集群节点的 URL,包括 URL 方案中的控制器类型及其网络中的位置。

platform:
  baremetal:
    hosts:
      - name: <hostname>
        role: <master | worker>
        bmc:
          address: <address> 
1

          username: <user>
          password: <password>
Copy to Clipboard Toggle word wrap
1
地址 配置设置指定协议。

对于富士通硬件,红帽支持集成远程管理控制器(iRMC)和 IPMI。

Expand
表 3.13. Fujitsu iRMC 的 BMC 地址格式
协议地址格式

iRMC

irmc://<out-of-band-ip>

IPMI

ipmi://<out-of-band-ip>

iRMC

Fujitsu 节点可以使用 irmc://<out-of-band-ip>,默认为端口 443。以下示例演示了 install-config.yaml 文件中的 iRMC 配置。

platform:
  baremetal:
    hosts:
      - name: openshift-master-0
        role: master
        bmc:
          address: irmc://<out-of-band-ip>
          username: <user>
          password: <password>
Copy to Clipboard Toggle word wrap
注意

目前,Fujitsu 支持 iRMC S5 固件版本 3.05 及更高版本用于裸机上的安装程序置备安装。

3.3.14.8. Cisco CIMC 的 BMC 地址

每个 bmc 条目 的地址 字段是连接到 OpenShift Container Platform 集群节点的 URL,包括 URL 方案中的控制器类型及其网络中的位置。

platform:
  baremetal:
    hosts:
      - name: <hostname>
        role: <master | worker>
        bmc:
          address: <address> 
1

          username: <user>
          password: <password>
Copy to Clipboard Toggle word wrap
1
地址 配置设置指定协议。

对于 Cisco UCS C-Series 和 X-Series 服务器,红帽支持 Cisco Integrated Management Controller (CIMC)。

Expand
表 3.14. Cisco CIMC 的 BMC 地址格式
协议地址格式

RedFish 虚拟介质

redfish-virtualmedia://<server_kvm_ip>/redfish/v1/Systems/<serial_number>

要为 Cisco UCS C-Series 和 X-Series 服务器启用 Redfish 虚拟介质,请在 address 设置中使用 redfish-virtualmedia://。以下示例演示了在 install-config.yaml 文件中使用 Redfish 虚拟介质。

platform:
  baremetal:
    hosts:
      - name: openshift-master-0
        role: master
        bmc:
          address: redfish-virtualmedia://<server_kvm_ip>/redfish/v1/Systems/<serial_number>
          username: <user>
          password: <password>
Copy to Clipboard Toggle word wrap

虽然建议为带外管理地址提供颁发机构证书,但在使用自签名证书时,您必须在 bmc 配置中包含 disableCertificateVerification: True。以下示例演示了在 install-config.yaml 文件中使用 disableCertificateVerification: True 配置参数的 Redfish 配置。

platform:
  baremetal:
    hosts:
      - name: openshift-master-0
        role: master
        bmc:
          address: redfish-virtualmedia://<server_kvm_ip>/redfish/v1/Systems/<serial_number>
          username: <user>
          password: <password>
          disableCertificateVerification: True
Copy to Clipboard Toggle word wrap
3.3.14.9. Root 设备提示

rootDeviceHints 参数可让安装程序将 Red Hat Enterprise Linux CoreOS(RHCOS)镜像置备到特定的设备。安装程序会按照发现设备的顺序检查设备,并将发现的值与 hint 值进行比较。安装程序使用第一个与 hint 值匹配的发现设备。配置可以组合多个 hint,但设备必须与所有提示匹配,以便安装程序进行选择。

Expand
表 3.15. 子字段
子字段描述

deviceName

包含 Linux 设备名称的字符串(如 /dev/vda/dev/disk/by-path/ )。

注意

建议您使用 /dev/disk/by-path/<device_path> 链接到存储位置。

hint 必须与实际值完全匹配。

hctl

包含类似 0:0:0:0:0 的 SCSI 总线地址的字符串。hint 必须与实际值完全匹配。

model

包含特定厂商的设备标识符的字符串。hint 可以是实际值的子字符串。

vendor

包含该设备厂商或制造商名称的字符串。hint 可以是实际值的子字符串。

serialNumber

包含设备序列号的字符串。hint 必须与实际值完全匹配。

minSizeGigabytes

以 GB 为单位代表设备的最小大小的整数。

wwn

包含唯一存储标识符的字符串。hint 必须与实际值完全匹配。

wwnWithExtension

包含唯一存储标识符的字符串,并附加厂商扩展。hint 必须与实际值完全匹配。

wwnVendorExtension

包含唯一厂商存储标识符的字符串。hint 必须与实际值完全匹配。

rotational

指明该设备为旋转磁盘(true)还是非旋转磁盘(false)的布尔值。

用法示例

     - name: master-0
       role: master
       bmc:
         address: ipmi://10.10.0.3:6203
         username: admin
         password: redhat
       bootMACAddress: de:ad:be:ef:00:40
       rootDeviceHints:
         deviceName: "/dev/sda"
Copy to Clipboard Toggle word wrap

3.3.14.10. 设置代理设置

要使用代理部署 OpenShift Container Platform 集群,请对 install-config.yaml 文件进行以下更改。

流程

  1. proxy 键映射下添加代理值:

    apiVersion: v1
    baseDomain: <domain>
    proxy:
      httpProxy: http://USERNAME:PASSWORD@proxy.example.com:PORT
      httpsProxy: https://USERNAME:PASSWORD@proxy.example.com:PORT
      noProxy: <WILDCARD_OF_DOMAIN>,<PROVISIONING_NETWORK/CIDR>,<BMC_ADDRESS_RANGE/CIDR>
    Copy to Clipboard Toggle word wrap

    以下是带有值的 noProxy 示例。

    noProxy: .example.com,172.22.0.0/24,10.10.0.0/24
    Copy to Clipboard Toggle word wrap
  2. 启用代理后,在对应的键/值对中设置代理的适当值。

    主要考虑:

    • 如果代理没有 HTTPS 代理,请将 httpsProxy 的值从 https :// 改为 http://
    • 如果集群使用 provisioning 网络,将其包含在 noProxy 设置中,否则安装程序会失败。
    • 将所有代理设置设置为 provisioner 节点中的环境变量。例如: HTTP_PROXYHTTPS_PROXYNO_PROXY
3.3.14.11. 没有 provisioning 网络进行部署

要在没有 provisioning 网络的情况下部署 OpenShift Container Platform 集群,请对 install-config.yaml 文件进行以下更改。

platform:
  baremetal:
    apiVIPs:
      - <api_VIP>
    ingressVIPs:
      - <ingress_VIP>
    provisioningNetwork: "Disabled" 
1
Copy to Clipboard Toggle word wrap
1
如果需要,添加 provisioningNetwork 配置设置并将其设置为 Disabled
重要

PXE 引导需要 provisioning 网络。如果您在没有 provisioning 网络的情况下部署,则必须使用虚拟介质 BMC 寻址选项,如 redfish-virtualmediaidrac-virtualmedia。详情请查看 "Redfish 虚拟介质 for HPE iLO" 部分的"适用于 HPE iLO 的 BMC 寻址"部分或"适用于戴尔 iDRAC 的"红帽虚拟媒体"部分中的"红帽虚拟介质"。

3.3.14.12. 使用双栈网络进行部署

对于 OpenShift Container Platform 集群中的双栈网络,您可以为集群节点配置 IPv4 和 IPv6 地址端点。要为集群节点配置 IPv4 和 IPv6 地址端点,请编辑 install-config.yaml 文件中的 machineNetworkclusterNetworkserviceNetwork 配置设置。每个设置必须分别有两个 CIDR 条目。对于将 IPv4 系列用作主地址系列的集群,请首先指定 IPv4 设置。对于将 IPv6 系列用作主地址系列的集群,请首先指定 IPv6 设置。

machineNetwork:
- cidr: {{ extcidrnet }}
- cidr: {{ extcidrnet6 }}
clusterNetwork:
- cidr: 10.128.0.0/14
  hostPrefix: 23
- cidr: fd02::/48
  hostPrefix: 64
serviceNetwork:
- 172.30.0.0/16
- fd03::/112
Copy to Clipboard Toggle word wrap
重要

在裸机平台上,如果您在 install-config.yaml 文件的 networkConfig 部分中指定了 NMState 配置,请将 interfaces.wait-ip: ipv4+ipv6 添加到 NMState YAML 文件中,以解决阻止集群在双栈网络上部署的问题。

包含 wait-ip 参数的 NMState YAML 配置文件示例

networkConfig:
  nmstate:
    interfaces:
    - name: <interface_name>
# ...
      wait-ip: ipv4+ipv6
# ...
Copy to Clipboard Toggle word wrap

要为使用 IPv4 和 IPv6 地址的应用程序提供接口,请为 Ingress VIP 和 API VIP 服务配置 IPv4 和 IPv6 虚拟 IP (VIP) 地址端点。要配置 IPv4 和 IPv6 地址端点,请编辑 install-config.yaml 文件中的 apiVIPsingressVIPs 配置设置。apiVIPsingressVIPs 配置设置使用列表格式。列表的顺序决定了每个服务的主 VIP 地址和次 VIP 地址。

platform:
  baremetal:
    apiVIPs:
      - <api_ipv4>
      - <api_ipv6>
    ingressVIPs:
      - <wildcard_ipv4>
      - <wildcard_ipv6>
Copy to Clipboard Toggle word wrap
注意

对于具有双栈网络配置的集群,您必须将 IPv4 和 IPv6 地址分配到同一接口。

3.3.14.13. 配置主机网络接口

在安装前,您可以在 install-config.yaml 文件中设置 networkConfig 配置设置,以使用 NMState 配置主机网络接口。

此功能的最常见用例是在 bare-metal 网络中指定一个静态 IP 地址,但您也可以配置其他网络,如存储网络。此功能支持 VLAN、VXLAN、网桥、绑定、路由、MTU 和 DNS 解析器设置等其他 NMState 功能。

警告

不要在集群的 DNS 解析器设置中设置不支持的 rotate 选项。选项会破坏内部 API 的 DNS 解析功能。

先决条件

  • 使用静态 IP 地址为每个节点配置带有有效主机名的 PTR DNS 记录。
  • 安装 NMState CLI (nmstate)。
重要

如果您使用 provisioning 网络,在 Ironic 中使用 dnsmasq 工具进行配置。要进行完全静态部署,您必须使用虚拟介质。

流程

  1. 可选:在 install-config.yaml 文件中包括语法前,使用 nmstatectl gc 测试 NMState 语法,因为安装程序不会检查 NMState YAML 语法。

    注意

    YAML 语法中的错误可能会导致无法应用网络配置。另外,在部署后或在扩展集群时应用 Kubernetes NMState 更改时,维护所验证的 YAML 语法会很有用。

    1. 创建 NMState YAML 文件:

      interfaces: 
      1
      
      - name: <nic1_name>
        type: ethernet
        state: up
        ipv4:
          address:
          - ip: <ip_address>
            prefix-length: 24
          enabled: true
      dns-resolver:
        config:
          server:
          - <dns_ip_address>
      routes:
        config:
        - destination: 0.0.0.0/0
          next-hop-address: <next_hop_ip_address>
          next-hop-interface: <next_hop_nic1_name>
      Copy to Clipboard Toggle word wrap
      1
      使用适当的值替换 <nic1_name>, <ip_address>, <dns_ip_address>, <next_hop_ip_address><next_hop_nic1_name>
    2. 运行以下命令来测试配置文件:

      $ nmstatectl gc <nmstate_yaml_file>
      Copy to Clipboard Toggle word wrap

      <nmstate_yaml_file> 替换为配置文件名称。

  2. 通过在 install-config.yaml 文件中的主机中添加 NMState 配置,使用 networkConfig 配置设置:

        hosts:
          - name: openshift-master-0
            role: master
            bmc:
              address: redfish+http://<out_of_band_ip>/redfish/v1/Systems/
              username: <user>
              password: <password>
              disableCertificateVerification: null
            bootMACAddress: <NIC1_mac_address>
            bootMode: UEFI
            rootDeviceHints:
              deviceName: "/dev/sda"
            networkConfig: 
    1
    
              interfaces: 
    2
    
              - name: <nic1_name>
                type: ethernet
                state: up
                ipv4:
                  address:
                  - ip: <ip_address>
                    prefix-length: 24
                  enabled: true
              dns-resolver:
                config:
                  server:
                  - <dns_ip_address>
              routes:
                config:
                - destination: 0.0.0.0/0
                  next-hop-address: <next_hop_ip_address>
                  next-hop-interface: <next_hop_nic1_name>
    Copy to Clipboard Toggle word wrap
    1
    添加 NMState YAML 语法来配置主机接口。
    2
    使用适当的值替换 <nic1_name>, <ip_address>, <dns_ip_address>, <next_hop_ip_address><next_hop_nic1_name>
    重要

    部署集群后,您无法修改 install-config.yaml 文件的 networkConfig 配置设置,以更改主机网络接口。在部署后,使用 Kubernetes NMState Operator 更改主机网络接口。

3.3.14.14. 为子网配置主机网络接口

对于边缘计算场景,定位接近边缘的计算节点会很有用。要在子网中定位远程节点,您可以对远程节点使用不同的网络片段或子网,而不是用于 control plane 子网和本地计算节点。您可以通过为边缘计算场景设置子网来减少边缘延迟并允许增强可扩展性。

重要

当使用默认负载均衡器时,OpenShiftManagedDefault 并将远程节点添加到 OpenShift Container Platform 集群中,所有 control plane 节点必须在同一子网中运行。当使用多个子网时,您还可以使用清单将 Ingress VIP 配置为在 control plane 节点上运行。详情请参阅"配置要在 control plane 上运行的网络组件"。

如果您为远程节点创建了不同的网络段或子网,如 "Establishing communication" 部分所述,如果 worker 使用静态 IP 地址、绑定或其他高级网络,您必须在 machineNetwork 配置设置中指定子网。当为每个远程节点在 networkConfig 参数中设置节点 IP 地址时,还必须在使用静态 IP 地址时为包含 control plane 节点的子网指定网关和 DNS 服务器。这样可确保远程节点可以访问包含 control plane 的子网,并可从 control plane 接收网络流量。

注意

使用多个子网部署集群需要使用虚拟介质,如 redfish-virtualmediaidrac-virtualmedia,因为远程节点无法访问本地置备网络。

流程

  1. 在使用静态 IP 地址时,将子网添加到 install-config.yaml 文件中的 machineNetwork 中:

    networking:
      machineNetwork:
      - cidr: 10.0.0.0/24
      - cidr: 192.168.0.0/24
      networkType: OVNKubernetes
    Copy to Clipboard Toggle word wrap
  2. 在使用静态 IP 地址或高级网络(如绑定)时,使用 NMState 语法将网关和 DNS 配置添加到每个边缘计算节点的 networkConfig 参数中:

    networkConfig:
      interfaces:
      - name: <interface_name> 
    1
    
        type: ethernet
        state: up
        ipv4:
          enabled: true
          dhcp: false
          address:
          - ip: <node_ip> 
    2
    
            prefix-length: 24
          gateway: <gateway_ip> 
    3
    
      dns-resolver:
        config:
          server:
          - <dns_ip> 
    4
    Copy to Clipboard Toggle word wrap
    1
    <interface_name> 替换为接口名称。
    2
    <node_ip> 替换为节点的 IP 地址。
    3
    使用网关的 IP 地址替换 <gateway_ip>
    4
    <dns_ip> 替换为 DNS 服务器的 IP 地址。

对于使用 Stateless Address AutoConfiguration (SLAAC)的双栈集群,您必须为 ipv6.addr-gen-mode 网络设置指定一个全局值。您可以使用 NMState 设置这个值来配置 RAM 磁盘和集群配置文件。如果您没有在这些位置配置一致的 ipv6.addr-gen-mode,则集群中的 CSR 资源和 BareMetalHost 资源之间可能会发生 IPv6 地址不匹配。

先决条件

  • 安装 NMState CLI (nmstate)。

流程

  1. 可选:在 install-config.yaml 文件中包括 nmstatectl gc 命令前使用 nmstatectl gc 命令测试 NMState YAML 语法,因为安装程序不会检查 NMState YAML 语法。

    1. 创建 NMState YAML 文件:

      interfaces:
      - name: eth0
        ipv6:
          addr-gen-mode: <address_mode> 
      1
      Copy to Clipboard Toggle word wrap
      1
      <address_mode> 替换为集群中 IPv6 地址所需的地址生成模式类型。有效值为 eui64stable-privacyrandom
    2. 运行以下命令来测试配置文件:

      $ nmstatectl gc <nmstate_yaml_file> 
      1
      Copy to Clipboard Toggle word wrap
      1
      <nmstate_yaml_file> 替换为测试配置文件的名称。
  2. 将 NMState 配置添加到 install-config.yaml 文件中的 hosts.networkConfig 部分:

        hosts:
          - name: openshift-master-0
            role: master
            bmc:
              address: redfish+http://<out_of_band_ip>/redfish/v1/Systems/
              username: <user>
              password: <password>
              disableCertificateVerification: null
            bootMACAddress: <NIC1_mac_address>
            bootMode: UEFI
            rootDeviceHints:
              deviceName: "/dev/sda"
            networkConfig:
              interfaces:
              - name: eth0
                ipv6:
                  addr-gen-mode: <address_mode> 
    1
    
    ...
    Copy to Clipboard Toggle word wrap
    1
    <address_mode> 替换为集群中 IPv6 地址所需的地址生成模式类型。有效值为 eui64stable-privacyrandom
3.3.14.16. 为双端口 NIC 配置主机网络接口

在安装前,您可以在 install-config.yaml 文件中设置 networkConfig 配置设置,以使用 NMState 支持双端口网络接口控制器(NIC)来配置主机网络接口。

OpenShift Virtualization 只支持以下绑定模式:

  • mode=1 active-backup
  • mode=2 balance-xor
  • mode=4 802.3ad

先决条件

  • 使用静态 IP 地址为每个节点配置带有有效主机名的 PTR DNS 记录。
  • 安装 NMState CLI (nmstate)。
注意

YAML 语法中的错误可能会导致无法应用网络配置。另外,在部署后或在扩展集群时应用 Kubernetes NMState 更改时,维护所验证的 YAML 语法会很有用。

流程

  1. 将 NMState 配置添加到 install-config.yaml 文件中的 networkConfig 主机中:

        hosts:
          - name: worker-0
            role: worker
            bmc:
              address: redfish+http://<out_of_band_ip>/redfish/v1/Systems/
              username: <user>
              password: <password>
              disableCertificateVerification: false
            bootMACAddress: <NIC1_mac_address>
            bootMode: UEFI
            networkConfig: 
    1
    
              interfaces: 
    2
    
               - name: eno1 
    3
    
                 type: ethernet 
    4
    
                 state: up
                 mac-address: 0c:42:a1:55:f3:06
                 ipv4:
                   enabled: true
                   dhcp: false 
    5
    
                 ethernet:
                   sr-iov:
                     total-vfs: 2 
    6
    
                 ipv6:
                   enabled: false
                   dhcp: false
               - name: sriov:eno1:0
                 type: ethernet
                 state: up 
    7
    
                 ipv4:
                   enabled: false 
    8
    
                 ipv6:
                   enabled: false
               - name: sriov:eno1:1
                 type: ethernet
                 state: down
               - name: eno2
                 type: ethernet
                 state: up
                 mac-address: 0c:42:a1:55:f3:07
                 ipv4:
                   enabled: true
                 ethernet:
                   sr-iov:
                     total-vfs: 2
                 ipv6:
                   enabled: false
               - name: sriov:eno2:0
                 type: ethernet
                 state: up
                 ipv4:
                   enabled: false
                 ipv6:
                   enabled: false
               - name: sriov:eno2:1
                 type: ethernet
                 state: down
               - name: bond0
                 type: bond
                 state: up
                 min-tx-rate: 100 
    9
    
                 max-tx-rate: 200 
    10
    
                 link-aggregation:
                   mode: active-backup 
    11
    
                   options:
                     primary: sriov:eno1:0 
    12
    
                   port:
                     - sriov:eno1:0
                     - sriov:eno2:0
                 ipv4:
                   address:
                     - ip: 10.19.16.57 
    13
    
                       prefix-length: 23
                   dhcp: false
                   enabled: true
                 ipv6:
                   enabled: false
              dns-resolver:
                config:
                  server:
                    - 10.11.5.160
                    - 10.2.70.215
              routes:
                config:
                  - destination: 0.0.0.0/0
                    next-hop-address: 10.19.17.254
                    next-hop-interface: bond0 
    14
    
                    table-id: 254
    Copy to Clipboard Toggle word wrap
    1
    networkConfig 字段包含主机的网络配置的信息,子字段包括 interfacesdns-resolverroutes
    2
    interfaces 字段是为主机定义的网络接口数组。
    3
    接口的名称。
    4
    接口的类型。这个示例创建了一个以太网接口。
    5
    如果物理功能 (PF) 没有被严格要求,则将其设置为 'false 以禁用 DHCP。
    6
    设置为要实例化的 SR-IOV 虚拟功能 (VF) 的数量。
    7
    把它设置为 up
    8
    把它设置为 false,以禁用附加到绑定的 VF 的 IPv4 寻址。
    9
    为 VF 设置最小传输率(以 Mbps 为单位)。这个示例值设置 100 Mbps 的速度。
    • 这个值必须小于或等于最大传输率。
    • Intel NIC 不支持 min-tx-rate 参数。如需更多信息,请参阅 BZ#1772847
    10
    为 VF 设置最大传输率(以 Mbps 为单位)。此示例值设置 200 Mbps 的速度。
    11
    设置所需的绑定模式。
    12
    设置绑定接口的首选端口。该绑定使用主设备作为绑定接口的第一个设备。这个绑定不会取消主设备接口,除非失败。当绑定接口中的一个 NIC 速度更快时,此设置特别有用,因此可以处理较大的负载。只有在绑定接口处于 active-backup 模式(模式 1)时,此设置才有效。
    13
    为绑定接口设置静态 IP 地址。这是节点 IP 地址。
    14
    bond0 设置为默认路由的网关。
    重要

    部署集群后,您无法更改 install-config.yaml 文件的 networkConfig 配置设置,以更改主机网络接口。在部署后,使用 Kubernetes NMState Operator 更改主机网络接口。

3.3.14.17. 配置多个集群节点

您可以使用相同的设置同时配置 OpenShift Container Platform 集群节点。配置多个集群节点可避免在 install-config.yaml 文件中添加每个节点的冗余信息。这个文件包含特定的参数,可将相同的配置应用到集群中的多个节点。

Compute 节点与控制器节点独立配置。但是,两个节点类型的配置都使用 install-config.yaml 文件中突出显示的参数启用多节点配置。将 networkConfig 参数设置为 BOND,如下例所示:

hosts:
- name: ostest-master-0
 [...]
 networkConfig: &BOND
   interfaces:
   - name: bond0
     type: bond
     state: up
     ipv4:
       dhcp: true
       enabled: true
     link-aggregation:
       mode: active-backup
       port:
       - enp2s0
       - enp3s0
- name: ostest-master-1
 [...]
 networkConfig: *BOND
- name: ostest-master-2
 [...]
 networkConfig: *BOND
Copy to Clipboard Toggle word wrap
注意

配置多个集群节点仅适用于安装程序置备的基础架构上的初始部署。

3.3.14.18. 配置受管安全引导

在使用 Redfish BMC 寻址(如 redfish, redfish-virtualmedia, 或 idrac-virtualmedia)部署安装程序置备的集群时,您可以启用受管安全引导。要启用受管安全引导,请在每个节点中添加 bootMode 配置设置:

示例

hosts:
  - name: openshift-master-0
    role: master
    bmc:
      address: redfish://<out_of_band_ip> 
1

      username: <username>
      password: <password>
    bootMACAddress: <NIC1_mac_address>
    rootDeviceHints:
     deviceName: "/dev/sda"
    bootMode: UEFISecureBoot 
2
Copy to Clipboard Toggle word wrap

1
确保 bmc.address 设置使用 redfishredfish-virtualmediaidrac-virtualmedia 作为协议。如需了解更多详细信息,请参阅"HPE iLO"或"BMC 寻址用于 Dell iDRAC"的"BMC 寻址"。
2
bootMode 设置默认为 UEFI。将它更改为 UEFISecureBoot 以启用受管安全引导。
注意

请参阅"先决条件"中的"配置节点",以确保节点能够支持受管安全引导。如果节点不支持受管安全引导,请参阅"配置节点"部分中的"手动配置安全引导节点"。手动配置安全引导机制需要 Redfish 虚拟介质。

注意

红帽不支持使用 IPMI 进行安全引导,因为 IPMI 不提供安全引导管理功能。

3.3.15. 清单配置文件

3.3.15.1. 创建 OpenShift Container Platform 清单
  1. 创建 OpenShift Container Platform 清单。

    $ ./openshift-baremetal-install --dir ~/clusterconfigs create manifests
    Copy to Clipboard Toggle word wrap
    INFO Consuming Install Config from target directory
    WARNING Making control-plane schedulable by setting MastersSchedulable to true for Scheduler cluster settings
    WARNING Discarding the OpenShift Manifest that was provided in the target directory because its dependencies are dirty and it needs to be regenerated
    Copy to Clipboard Toggle word wrap
3.3.15.2. 为断开连接的集群配置 NTP

OpenShift Container Platform 在集群节点上安装 chrony 网络时间协议(NTP)服务。

OpenShift Container Platform 节点必须在日期和时间上达成一致才能正确运行。当计算节点从 control plane 节点上的 NTP 服务器检索日期和时间时,它会启用未连接到可路由网络的集群的安装和操作,因此无法访问更高的 stratum NTP 服务器。

流程

  1. 使用以下命令在安装主机上安装 Butane:

    $ sudo dnf -y install butane
    Copy to Clipboard Toggle word wrap
  2. 为 control plane 节点创建一个 Butane 配置 99-master-chrony-conf-override.bu,包括 chrony.conf 文件的内容。

    注意

    如需有关 Butane 的信息,请参阅"使用 Butane 创建机器配置"。

    但ane 配置示例

    variant: openshift
    version: 4.19.0
    metadata:
      name: 99-master-chrony-conf-override
      labels:
        machineconfiguration.openshift.io/role: master
    storage:
      files:
        - path: /etc/chrony.conf
          mode: 0644
          overwrite: true
          contents:
            inline: |
              # Use public servers from the pool.ntp.org project.
              # Please consider joining the pool (https://www.pool.ntp.org/join.html).
    
              # The Machine Config Operator manages this file
              server openshift-master-0.<cluster-name>.<domain> iburst 
    1
    
              server openshift-master-1.<cluster-name>.<domain> iburst
              server openshift-master-2.<cluster-name>.<domain> iburst
    
              stratumweight 0
              driftfile /var/lib/chrony/drift
              rtcsync
              makestep 10 3
              bindcmdaddress 127.0.0.1
              bindcmdaddress ::1
              keyfile /etc/chrony.keys
              commandkey 1
              generatecommandkey
              noclientlog
              logchange 0.5
              logdir /var/log/chrony
    
              # Configure the control plane nodes to serve as local NTP servers
              # for all compute nodes, even if they are not in sync with an
              # upstream NTP server.
    
              # Allow NTP client access from the local network.
              allow all
              # Serve time even if not synchronized to a time source.
              local stratum 3 orphan
    Copy to Clipboard Toggle word wrap

    1
    您必须将 <cluster-name> 替换为集群名称,并将 <domain> 替换为完全限定域名。
  3. 使用 Butane 生成 MachineConfig 对象文件 99-master-chrony-conf-override.yaml,其中包含要发送到 control plane 节点的配置:

    $ butane 99-master-chrony-conf-override.bu -o 99-master-chrony-conf-override.yaml
    Copy to Clipboard Toggle word wrap
  4. 为引用 control plane 节点上的 NTP 服务器的计算节点创建 Butane 配置 99-worker-chrony-conf-override.bu,包括 chrony.conf 文件的内容。

    但ane 配置示例

    variant: openshift
    version: 4.19.0
    metadata:
      name: 99-worker-chrony-conf-override
      labels:
        machineconfiguration.openshift.io/role: worker
    storage:
      files:
        - path: /etc/chrony.conf
          mode: 0644
          overwrite: true
          contents:
            inline: |
              # The Machine Config Operator manages this file.
              server openshift-master-0.<cluster-name>.<domain> iburst 
    1
    
              server openshift-master-1.<cluster-name>.<domain> iburst
              server openshift-master-2.<cluster-name>.<domain> iburst
    
              stratumweight 0
              driftfile /var/lib/chrony/drift
              rtcsync
              makestep 10 3
              bindcmdaddress 127.0.0.1
              bindcmdaddress ::1
              keyfile /etc/chrony.keys
              commandkey 1
              generatecommandkey
              noclientlog
              logchange 0.5
              logdir /var/log/chrony
    Copy to Clipboard Toggle word wrap

    1
    您必须将 <cluster-name> 替换为集群名称,并将 <domain> 替换为完全限定域名。
  5. 使用 Butane 生成 MachineConfig 对象文件 99-worker-chrony-conf-override.yaml,其中包含要交付至 worker 节点的配置:

    $ butane 99-worker-chrony-conf-override.bu -o 99-worker-chrony-conf-override.yaml
    Copy to Clipboard Toggle word wrap

您可以配置网络组件,使其仅在 control plane 节点上运行。默认情况下,OpenShift Container Platform 允许机器配置池中的任何节点托管 ingressVIP 虚拟 IP 地址。但是,有些环境在与 control plane 节点独立的子网中部署计算节点,这需要将 ingressVIP 虚拟 IP 地址配置为在 control plane 节点上运行。

重要

在单独的子网中部署远程节点时,您必须将 ingressVIP 虚拟 IP 地址专门用于 control plane 节点。

流程

  1. 进入存储 install-config.yaml 文件的目录:

    $ cd ~/clusterconfigs
    Copy to Clipboard Toggle word wrap
  2. 切换到 manifests 子目录:

    $ cd manifests
    Copy to Clipboard Toggle word wrap
  3. 创建名为 cluster-network-avoid-workers-99-config.yaml 的文件:

    $ touch cluster-network-avoid-workers-99-config.yaml
    Copy to Clipboard Toggle word wrap
  4. 在编辑器中打开 cluster-network-avoid-workers-99-config.yaml 文件,并输入描述 Operator 配置的自定义资源(CR):

    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      name: 50-worker-fix-ipi-rwn
      labels:
        machineconfiguration.openshift.io/role: worker
    spec:
      config:
        ignition:
          version: 3.2.0
        storage:
          files:
            - path: /etc/kubernetes/manifests/keepalived.yaml
              mode: 0644
              contents:
                source: data:,
    Copy to Clipboard Toggle word wrap

    此清单将 ingressVIP 虚拟 IP 地址放在 control plane 节点上。另外,此清单仅在 control plane 节点上部署以下进程:

    • openshift-ingress-operator
    • keepalived
  5. 保存 cluster-network-avoid-workers-99-config.yaml 文件。
  6. 创建 manifests/cluster-ingress-default-ingresscontroller.yaml 文件:

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: default
      namespace: openshift-ingress-operator
    spec:
      nodePlacement:
        nodeSelector:
          matchLabels:
            node-role.kubernetes.io/master: ""
    Copy to Clipboard Toggle word wrap
  7. 考虑备份 manifests 目录。在创建集群时,安装程序会删除 manifests/ 目录。
  8. 通过将 mastersSchedulable 字段设置为 true 来修改 cluster-scheduler-02-config.yml 清单,使 control plane 节点可以调度。默认情况下,control plane 节点不可调度。例如:

    $ sed -i "s;mastersSchedulable: false;mastersSchedulable: true;g" clusterconfigs/manifests/cluster-scheduler-02-config.yml
    Copy to Clipboard Toggle word wrap
    注意

    如果在完成此步骤后 control plane 节点不可调度,则部署集群将失败。

3.3.15.4. 在计算节点上部署路由器

在安装过程中,安装程序会在计算节点上部署路由器 pod。默认情况下,安装程序会安装两个路由器 pod。如果部署的集群需要额外的路由器来处理用于 OpenShift Container Platform 集群中服务的外部流量负载,您可以创建一个 yaml 文件来设置适当数量的路由器副本。

重要

不支持只使用一个计算节点部署集群。虽然在使用一个计算节点时修改路由器副本数量会解决降级状态的问题,但集群丢失了入口 API 的高可用性,它不适用于生产环境。

注意

默认情况下,安装程序会部署两个路由器。如果集群没有计算节点,安装程序会默认在 control plane 节点上部署两个路由器。

流程

  1. 创建 router-replicas.yaml 文件:

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: default
      namespace: openshift-ingress-operator
    spec:
      replicas: <num-of-router-pods>
      endpointPublishingStrategy:
        type: HostNetwork
      nodePlacement:
        nodeSelector:
          matchLabels:
            node-role.kubernetes.io/worker: ""
    Copy to Clipboard Toggle word wrap
    注意

    <num-of-router-pods> 替换为适当的值。如果只使用一个计算节点,请将 replicas: 设置为 1。如果使用超过 3 个计算节点,您可以根据情况增加 replicas: 的值(默认值为 2)。

  2. router-replicas.yaml 文件复制到 clusterconfigs/openshift 目录中:

    $ cp ~/router-replicas.yaml clusterconfigs/openshift/99_router-replicas.yaml
    Copy to Clipboard Toggle word wrap
3.3.15.5. 配置 BIOS

以下流程在安装过程中配置 BIOS。

流程

  1. 创建清单。
  2. 修改与节点对应的 BareMetalHost 资源文件:

    $ vim clusterconfigs/openshift/99_openshift-cluster-api_hosts-*.yaml
    Copy to Clipboard Toggle word wrap
  3. 将 BIOS 配置添加到 BareMetalHost 资源的 spec 部分:

    spec:
      firmware:
        simultaneousMultithreadingEnabled: true
        sriovEnabled: true
        virtualizationEnabled: true
    Copy to Clipboard Toggle word wrap
    注意

    红帽支持三种 BIOS 配置:仅支持 BMC 类型 irmc 的服务器。目前不支持其他类型的服务器。

  4. 创建集群。
3.3.15.6. 配置 RAID

以下流程在安装过程中使用基板管理控制器 (BMC) 配置独立磁盘的冗余阵列 (RAID)。

注意

如果要为节点配置硬件 RAID,请验证节点是否具有支持的 RAID 控制器。OpenShift Container Platform 4.19 不支持软件 RAID。

Expand
表 3.16. 厂商的硬件 RAID 支持
VendorBMC 和协议固件版本RAID 级别

Fujitsu

iRMC

N/A

0、1、5、6 和 10

Dell

使用 Redfish 的 iDRAC

版本 6.10.30.20 或更高版本

0、1 和 5

流程

  1. 创建清单。
  2. 修改与节点对应的 BareMetalHost 资源:

    $ vim clusterconfigs/openshift/99_openshift-cluster-api_hosts-*.yaml
    Copy to Clipboard Toggle word wrap
    注意

    以下示例使用硬件 RAID 配置,因为 OpenShift Container Platform 4.19 不支持软件 RAID。

    1. 如果您在 spec 部分添加了特定的 RAID 配置,这会导致节点在 preparing 阶段删除原始 RAID 配置,并在 RAID 上执行指定的配置。例如:

      spec:
        raid:
          hardwareRAIDVolumes:
          - level: "0" 
      1
      
            name: "sda"
            numberOfPhysicalDisks: 1
            rotational: true
            sizeGibibytes: 0
      Copy to Clipboard Toggle word wrap
      1
      level 是必填字段,另一个是可选字段。
    2. 如果您在 spec 部分添加了空的 RAID 配置,空配置会导致节点在 preparing 阶段删除原始 RAID 配置,但不执行新配置。例如:

      spec:
        raid:
          hardwareRAIDVolumes: []
      Copy to Clipboard Toggle word wrap
    3. 如果您没有在 spec 部分添加 raid 字段,则原始 RAID 配置不会被删除,且不会执行新的配置。
  3. 创建集群。
3.3.15.7. 在节点上配置存储

您可以通过创建由 Machine Config Operator (MCO) 管理的 MachineConfig 对象来更改 OpenShift Container Platform 节点上的操作系统。

MachineConfig 规格包括一个 ignition 配置,用于在第一次引导时配置机器。此配置对象可用于修改 OpenShift Container Platform 机器上运行的文件、systemd 服务和其他操作系统功能。

流程

使用 ignition 配置在节点上配置存储。以下 MachineSet 清单示例演示了如何将分区添加到主节点上的设备中。在本例中,在安装前应用清单,其名为 restore 的分区,大小为 16 GiB。

  1. 创建 custom-partitions.yaml 文件,并包含一个包含分区布局的 MachineConfig 对象:

    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: primary
      name: 10_primary_storage_config
    spec:
      config:
        ignition:
          version: 3.2.0
        storage:
          disks:
            - device: </dev/xxyN>
              partitions:
                - label: recovery
                  startMiB: 32768
                  sizeMiB: 16384
          filesystems:
            - device: /dev/disk/by-partlabel/recovery
              label: recovery
              format: xfs
    Copy to Clipboard Toggle word wrap
  2. custom-partitions.yaml 文件复制到 clusterconfigs/openshift 目录中:

    $ cp ~/<MachineConfig_manifest> ~/clusterconfigs/openshift
    Copy to Clipboard Toggle word wrap

3.3.16. 创建断开连接的 registry

在某些情况下,您可能想要使用安装 registry 的本地副本安装 OpenShift Container Platform 集群。这可能是为了提高网络效率,因为集群节点位于无法访问互联网的网络中。

一个本地的或被镜像的 registry 副本需要以下内容:

  • registry 节点的证书。这可以是自签名证书。
  • 系统中的容器将服务的 Web 服务器。
  • 包含证书和本地存储库信息的更新的 pull secret。
注意

在 registry 节点上创建断开连接的 registry 是可选的。如果需要在 registry 节点上创建断开连接的 registry,您必须完成以下所有子章节。

3.3.16.1. 先决条件

在裸机上托管镜像的 registry 之前,必须完成以下步骤。

流程

  1. 打开 registry 节点上的防火墙端口:

    $ sudo firewall-cmd --add-port=5000/tcp --zone=libvirt  --permanent
    Copy to Clipboard Toggle word wrap
    $ sudo firewall-cmd --add-port=5000/tcp --zone=public   --permanent
    Copy to Clipboard Toggle word wrap
    $ sudo firewall-cmd --reload
    Copy to Clipboard Toggle word wrap
  2. 为 registry 节点安装所需的软件包:

    $ sudo yum -y install python3 podman httpd httpd-tools jq
    Copy to Clipboard Toggle word wrap
  3. 创建保存存储库信息的目录结构:

    $ sudo mkdir -p /opt/registry/{auth,certs,data}
    Copy to Clipboard Toggle word wrap

完成以下步骤,为断开连接的 registry 镜像 OpenShift Container Platform 镜像存储库。

先决条件

流程

  1. 查看 OpenShift Container Platform 下载页,以确定您要安装的 OpenShift Container Platform 版本,并决定 Repository Tags 页中的相应标签(tag)。
  2. 设置所需的环境变量:

    1. 导出发行版本信息:

      $ OCP_RELEASE=<release_version>
      Copy to Clipboard Toggle word wrap

      对于 <release_version>,请指定与 OpenShift Container Platform 版本对应的标签,用于您的架构,如 4.5.4

    2. 导出本地 registry 名称和主机端口:

      $ LOCAL_REGISTRY='<local_registry_host_name>:<local_registry_host_port>'
      Copy to Clipboard Toggle word wrap

      对于 <local_registry_host_name>,请指定镜像存储库的 registry 域名;对于 <local_registry_host_port>,请指定用于提供内容的端口。

    3. 导出本地存储库名称:

      $ LOCAL_REPOSITORY='<local_repository_name>'
      Copy to Clipboard Toggle word wrap

      对于 <local_repository_name>,请指定要在 registry 中创建的仓库名称,如 ocp4/openshift4

    4. 导出要进行镜像的存储库名称:

      $ PRODUCT_REPO='openshift-release-dev'
      Copy to Clipboard Toggle word wrap

      对于生产环境版本,必须指定 openshift-release-dev

    5. 导出 registry pull secret 的路径:

      $ LOCAL_SECRET_JSON='<path_to_pull_secret>'
      Copy to Clipboard Toggle word wrap

      对于 <path_to_pull_secret>,请指定您创建的镜像 registry 的 pull secret 的绝对路径和文件名。

    6. 导出发行版本镜像:

      $ RELEASE_NAME="ocp-release"
      Copy to Clipboard Toggle word wrap

      对于生产环境版本,您必须指定 ocp-release

    7. 为您的集群导出构架类型:

      $ ARCHITECTURE=<cluster_architecture> 
      1
      Copy to Clipboard Toggle word wrap
      1
      指定集群的构架,如 x86_64, aarch64, s390x, 获 ppc64le
    8. 导出托管镜像的目录的路径:

      $ REMOVABLE_MEDIA_PATH=<path> 
      1
      Copy to Clipboard Toggle word wrap
      1
      指定完整路径,包括开始的前斜杠(/)字符。
  3. 将版本镜像(mirror)到镜像 registry:

    • 如果您的镜像主机无法访问互联网,请执行以下操作:

      1. 将可移动介质连接到连接到互联网的系统。
      2. 查看要镜像的镜像和配置清单:

        $ oc adm release mirror -a ${LOCAL_SECRET_JSON}  \
             --from=quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE} \
             --to=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY} \
             --to-release-image=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE} --dry-run
        Copy to Clipboard Toggle word wrap
      3. 记录上一命令输出中的 imageContentSources 部分。您的镜像信息与您的镜像存储库相对应,您必须在安装过程中将 imageContentSources 部分添加到 install-config.yaml 文件中。
      4. 将镜像镜像到可移动介质的目录中:

        $ oc adm release mirror -a ${LOCAL_SECRET_JSON} --to-dir=${REMOVABLE_MEDIA_PATH}/mirror quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE}
        Copy to Clipboard Toggle word wrap
      5. 将介质上传到受限网络环境中,并将镜像上传到本地容器 registry。

        $ oc image mirror -a ${LOCAL_SECRET_JSON} --from-dir=${REMOVABLE_MEDIA_PATH}/mirror "file://openshift/release:${OCP_RELEASE}*" ${LOCAL_REGISTRY}/${LOCAL_REPOSITORY} 
        1
        Copy to Clipboard Toggle word wrap
        1
        对于 REMOVABLE_MEDIA_PATH,您必须使用与镜像镜像时指定的同一路径。
    • 如果本地容器 registry 连接到镜像主机,请执行以下操作:

      1. 使用以下命令直接将发行版镜像推送到本地 registry:

        $ oc adm release mirror -a ${LOCAL_SECRET_JSON}  \
             --from=quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE} \
             --to=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY} \
             --to-release-image=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}
        Copy to Clipboard Toggle word wrap

        该命令将发行信息提取为摘要,其输出包括安装集群时所需的 imageContentSources 数据。

      2. 记录上一命令输出中的 imageContentSources 部分。您的镜像信息与您的镜像存储库相对应,您必须在安装过程中将 imageContentSources 部分添加到 install-config.yaml 文件中。

        注意

        镜像名称在镜像过程中被修补到 Quay.io, podman 镜像将在 bootstrap 虚拟机的 registry 中显示 Quay.io。

  4. 要创建基于您镜像内容的安装程序,请提取内容并将其固定到发行版中:

    • 如果您的镜像主机无法访问互联网,请运行以下命令:

      $ oc adm release extract -a ${LOCAL_SECRET_JSON} --command=openshift-baremetal-install "${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}"
      Copy to Clipboard Toggle word wrap
    • 如果本地容器 registry 连接到镜像主机,请运行以下命令:

      $ oc adm release extract -a ${LOCAL_SECRET_JSON} --command=openshift-baremetal-install "${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}"
      Copy to Clipboard Toggle word wrap
      重要

      要确保将正确的镜像用于您选择的 OpenShift Container Platform 版本,您必须从镜像内容中提取安装程序。

      您必须在有活跃互联网连接的机器上执行这个步骤。

      如果您位于断开连接的环境中,请使用 --image 标志作为 must-gather 的一部分,指向有效负载镜像。

  5. 对于使用安装程序置备的基础架构的集群,运行以下命令:

    $ openshift-baremetal-install
    Copy to Clipboard Toggle word wrap

在 provisioner 节点上,install -config.yaml 文件应该使用从 pull-secret- update.txt 文件中新创建的 pull-secretinstall-config.yaml 文件还必须包含断开连接的 registry 节点的证书和 registry 信息。

流程

  1. 将断开连接的 registry 节点的证书添加到 install-config.yaml 文件中:

    $ echo "additionalTrustBundle: |" >> install-config.yaml
    Copy to Clipboard Toggle word wrap

    证书应跟在 "additionalTrustBundle: |" 行后面,并正确缩进(通常为两个空格)。

    $ sed -e 's/^/  /' /opt/registry/certs/domain.crt >> install-config.yaml
    Copy to Clipboard Toggle word wrap
  2. 将 registry 的镜像信息添加到 install-config.yaml 文件中:

    $ echo "imageContentSources:" >> install-config.yaml
    Copy to Clipboard Toggle word wrap
    $ echo "- mirrors:" >> install-config.yaml
    Copy to Clipboard Toggle word wrap
    $ echo "  - registry.example.com:5000/ocp4/openshift4" >> install-config.yaml
    Copy to Clipboard Toggle word wrap

    registry.example.com 替换为 registry 的完全限定域名。

    $ echo "  source: quay.io/openshift-release-dev/ocp-release" >> install-config.yaml
    Copy to Clipboard Toggle word wrap
    $ echo "- mirrors:" >> install-config.yaml
    Copy to Clipboard Toggle word wrap
    $ echo "  - registry.example.com:5000/ocp4/openshift4" >> install-config.yaml
    Copy to Clipboard Toggle word wrap

    registry.example.com 替换为 registry 的完全限定域名。

    $ echo "  source: quay.io/openshift-release-dev/ocp-v4.0-art-dev" >> install-config.yaml
    Copy to Clipboard Toggle word wrap

3.3.17. 安装的验证清单

  • ❏ 已检索到 OpenShift Container Platform 安装程序。
  • ❏ 已提取 OpenShift Container Platform 安装程序。
  • ❏ 已配置了 install-config.yaml 的必要参数。
  • ❏ 已配置了 install-config.yamlhosts 参数。
  • ❏ 已配置了 install-config.yamlbmc 参数。
  • ❏ 在 bmc address 字段中配置的值已被应用。
  • ❏ 创建 OpenShift Container Platform 清单。
  • ❏ (Optional) 可选)在计算节点上部署路由器。
  • ❏ (可选)创建断开连接的 registry。
  • ❏ (可选)如果使用,验证断开连接的 registry 设置。

3.4. 安装集群

3.4.1. 清理以前的安装

如果以前部署失败,请在尝试再次部署 OpenShift Container Platform 前从失败的尝试中删除工件。

流程

  1. 使用以下命令安装 OpenShift Container Platform 集群前关闭所有裸机节点:

    $ ipmitool -I lanplus -U <user> -P <password> -H <management_server_ip> power off
    Copy to Clipboard Toggle word wrap
  2. 使用以下脚本,删除所有旧的 bootstrap 资源:

    for i in $(sudo virsh list | tail -n +3 | grep bootstrap | awk {'print $2'});
    do
      sudo virsh destroy $i;
      sudo virsh undefine $i;
      sudo virsh vol-delete $i --pool $i;
      sudo virsh vol-delete $i.ign --pool $i;
      sudo virsh pool-destroy $i;
      sudo virsh pool-undefine $i;
    done
    Copy to Clipboard Toggle word wrap
  3. 使用以下命令删除早期安装生成的工件:

    $ cd ; /bin/rm -rf auth/ bootstrap.ign master.ign worker.ign metadata.json \
    .openshift_install.log .openshift_install_state.json
    Copy to Clipboard Toggle word wrap
  4. 使用以下命令重新创建 OpenShift Container Platform 清单:

    $ ./openshift-baremetal-install --dir ~/clusterconfigs create manifests
    Copy to Clipboard Toggle word wrap

运行 OpenShift Container Platform 安装程序:

$ ./openshift-baremetal-install --dir ~/clusterconfigs --log-level debug create cluster
Copy to Clipboard Toggle word wrap

3.4.3. 监控安装进度

在部署过程中,您可以通过向安装目录文件夹中的 .openshift_install.log 日志文件发出 tail 命令来检查安装的整体状态:

$ tail -f /path/to/install-dir/.openshift_install.log
Copy to Clipboard Toggle word wrap

3.4.4. 验证静态 IP 地址配置

如果集群节点的 DHCP 保留指定了无限租期,安装程序成功置备该节点后,分配程序脚本会检查节点的网络配置。如果脚本确定网络配置包含无限 DHCP 租期,它将 DHCP 租期的 IP 地址用作静态 IP 地址来创建新连接。

注意

分配程序脚本可能会在成功置备的节点上运行,同时持续置备集群中的其他节点。

验证网络配置是否正常工作。

流程

  1. 检查节点上的网络接口配置。
  2. 关闭 DHCP 服务器并重启 OpenShift Container Platform 节点,并确保网络配置可以正常工作。

3.5. 安装故障排除

3.5.1. 安装程序工作流故障排除

在对安装环境进行故障排除前,务必要了解裸机上安装程序置备安装的整体流。下图显示了一个故障排除流程,并按步骤划分环境。

Flow-Diagram-1

install-config.yaml 文件出错或者无法访问 Red Hat Enterprise Linux CoreOS(RHCOS)镜像时,工作流 1(共 4 步) 的工作流演示了故障排除工作流。有关故障排除的建议,请参阅install-config.yaml 进行故障排除

Flow-Diagram-2

工作流 2(共 4 步)描述了对 bootstrap 虚拟机问题 无法引导集群节点的 bootstrap 虚拟机 以及 检查日志 的故障排除工作流。当在没有 provisioning 网络的情况下安装 OpenShift Container Platform 集群时,此工作流将不应用。

Flow-Diagram-3

工作流 3(共 4 步)描述了 不能 PXE 引导的集群节点 的故障排除工作流。如果使用 Redfish 虚拟介质进行安装,则每个节点都必须满足安装程序部署该节点的最低固件要求。如需了解更多详细信息,请参阅先决条件部分中的使用虚拟介质安装的固件要求

Flow-Diagram-4

工作流 4(共 4 步) 演示了 无法访问 API 的故障排除工作流,以及 经过验证的安装

3.5.2. install-config.yaml故障排除

install-config.yaml 配置文件代表属于 OpenShift Container Platform 集群的所有节点。该文件包含由 apiVersion、baseDomain、imageContentSources 和虚拟 IP 地址组成的必要选项。如果在 OpenShift Container Platform 集群部署早期发生错误,install-config.yaml 配置文件中可能会出现错误。

流程

  1. 使用 YAML-tips 中的指南。
  2. 使用 syntax-check 验证 YAML 语法是否正确。
  3. 验证 Red Hat Enterprise Linux CoreOS(RHCOS)QEMU 镜像是否已正确定义,并可通过 install-config.yaml 提供的 URL 访问。例如:

    $ curl -s -o /dev/null -I -w "%{http_code}\n" http://webserver.example.com:8080/rhcos-44.81.202004250133-0-qemu.<architecture>.qcow2.gz?sha256=7d884b46ee54fe87bbc3893bf2aa99af3b2d31f2e19ab5529c60636fbd0f1ce7
    Copy to Clipboard Toggle word wrap

    如果输出为 200,则会从存储 bootstrap 虚拟机镜像的 webserver 获得有效的响应。

3.5.3. bootstrap 虚拟机问题故障排除

OpenShift Container Platform 安装程序生成 bootstrap 节点虚拟机,该虚拟机处理置备 OpenShift Container Platform 集群节点。

流程

  1. 触发安装程序后大约 10 到 15 分钟,使用 virsh 命令检查 bootstrap 虚拟机是否正常工作:

    $ sudo virsh list
    Copy to Clipboard Toggle word wrap
     Id    Name                           State
     --------------------------------------------
     12    openshift-xf6fq-bootstrap      running
    Copy to Clipboard Toggle word wrap
    注意

    bootstrap 虚拟机的名称始终是集群名称,后跟一组随机字符,并以"bootstrap"结尾。

  2. 如果 bootstrap 虚拟机在 10-15 分钟后没有运行,请执行以下命令来验证 libvirtd 是否在系统中运行:

    $ systemctl status libvirtd
    Copy to Clipboard Toggle word wrap
    ● libvirtd.service - Virtualization daemon
       Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled; vendor preset: enabled)
       Active: active (running) since Tue 2020-03-03 21:21:07 UTC; 3 weeks 5 days ago
         Docs: man:libvirtd(8)
               https://libvirt.org
     Main PID: 9850 (libvirtd)
        Tasks: 20 (limit: 32768)
       Memory: 74.8M
       CGroup: /system.slice/libvirtd.service
               ├─ 9850 /usr/sbin/libvirtd
    Copy to Clipboard Toggle word wrap

    如果 bootstrap 虚拟机可以正常工作,请登录它。

  3. 使用 virsh console 命令查找 bootstrap 虚拟机的 IP 地址:

    $ sudo virsh console example.com
    Copy to Clipboard Toggle word wrap
    Connected to domain example.com
    Escape character is ^]
    Red Hat Enterprise Linux CoreOS 43.81.202001142154.0 (Ootpa) 4.3
    SSH host key: SHA256:BRWJktXZgQQRY5zjuAV0IKZ4WM7i4TiUyMVanqu9Pqg (ED25519)
    SSH host key: SHA256:7+iKGA7VtG5szmk2jB5gl/5EZ+SNcJ3a2g23o0lnIio (ECDSA)
    SSH host key: SHA256:DH5VWhvhvagOTaLsYiVNse9ca+ZSW/30OOMed8rIGOc (RSA)
    ens3:  fd35:919d:4042:2:c7ed:9a9f:a9ec:7
    ens4: 172.22.0.2 fe80::1d05:e52e:be5d:263f
    localhost login:
    Copy to Clipboard Toggle word wrap
    重要

    当在没有 provisioning 网络的情况下部署 OpenShift Container Platform 集群时,您必须使用公共 IP 地址,而不是专用 IP 地址,如 172.22.0.2

  4. 获取 IP 地址后,使用 ssh 命令登录到 bootstrap 虚拟机:

    注意

    在上一步的控制台输出中,您可以使用 ens3 提供的 IPv6 IP 地址或 ens 4 提供的 IPv4 IP 地址

    $ ssh core@172.22.0.2
    Copy to Clipboard Toggle word wrap

如果您无法成功登录 bootstrap 虚拟机,您可能会遇到以下情况之一:

  • 您无法访问 172.22.0.0/24 网络。验证 provisioner 和 provisioning 网桥之间的网络连接。如果您使用 provisioning 网络,则可能会出现此问题。
  • 您无法通过公共网络访问 bootstrap 虚拟机。当尝试 SSH via baremetal 网络 时,验证 provisioner 主机上的连接情况,特别是 baremetal 网桥的连接。
  • 您遇到了 Permission denied(publickey,password,keyboard-interactive) 的问题。当尝试访问 bootstrap 虚拟机时,可能会出现 Permission denied 错误。验证尝试登录到虚拟机的用户的 SSH 密钥是否在 install-config.yaml 文件中设置。
3.5.3.1. Bootstrap 虚拟机无法引导集群节点

在部署过程中,bootstrap 虚拟机可能无法引导集群节点,这会阻止虚拟机使用 RHCOS 镜像置备节点。这可能是因为以下原因:

  • install-config.yaml 文件存在问题。
  • 使用 baremetal 网络时出现带外网络访问的问题。

要验证这个问题,有三个与 ironic 相关的容器:

  • ironic
  • ironic-inspector

流程

  1. 登录到 bootstrap 虚拟机:

    $ ssh core@172.22.0.2
    Copy to Clipboard Toggle word wrap
  2. 要检查容器日志,请执行以下操作:

    [core@localhost ~]$ sudo podman logs -f <container_name>
    Copy to Clipboard Toggle word wrap

    <container_name> 替换为 ironicironic-inspector 之一。如果您遇到 control plane 节点没有从 PXE 引导的问题,请检查 ironic pod。ironic pod 包含有关尝试引导集群节点的信息,因为它尝试通过 IPMI 登录节点。

潜在原因

集群节点在部署启动时可能处于 ON 状态。

解决方案

在通过 IPMI 开始安装前关闭 OpenShift Container Platform 集群节点:

$ ipmitool -I lanplus -U root -P <password> -H <out_of_band_ip> power off
Copy to Clipboard Toggle word wrap
3.5.3.2. 检查日志

在下载或访问 RHCOS 镜像时,首先验证 install-config.yaml 配置文件中的 URL 是否正确。

内部 webserver 托管 RHCOS 镜像的示例

bootstrapOSImage: http://<ip:port>/rhcos-43.81.202001142154.0-qemu.<architecture>.qcow2.gz?sha256=9d999f55ff1d44f7ed7c106508e5deecd04dc3c06095d34d36bf1cd127837e0c
clusterOSImage: http://<ip:port>/rhcos-43.81.202001142154.0-openstack.<architecture>.qcow2.gz?sha256=a1bda656fa0892f7b936fdc6b6a6086bddaed5dafacedcd7a1e811abb78fe3b0
Copy to Clipboard Toggle word wrap

coreos-downloader 容器从 webserver 或外部 quay.io registry 下载资源(由 install-config.yaml 配置文件指定)。验证 coreos-downloader 容器是否正在运行,并根据需要检查其日志。

流程

  1. 登录到 bootstrap 虚拟机:

    $ ssh core@172.22.0.2
    Copy to Clipboard Toggle word wrap
  2. 运行以下命令,检查 bootstrap 虚拟机中的 coreos-downloader 容器的状态:

    [core@localhost ~]$ sudo podman logs -f coreos-downloader
    Copy to Clipboard Toggle word wrap

    如果 bootstrap 虚拟机无法访问镜像的 URL,请使用 curl 命令验证虚拟机是否可以访问镜像。

  3. 要检查 bootkube 日志,以指示部署阶段是否启动了所有容器,请执行以下操作:

    [core@localhost ~]$ journalctl -xe
    Copy to Clipboard Toggle word wrap
    [core@localhost ~]$ journalctl -b -f -u bootkube.service
    Copy to Clipboard Toggle word wrap
  4. 验证包括 dnsmasq、mariadbhttpd ironic 等所有 pod 都在运行:

    [core@localhost ~]$ sudo podman ps
    Copy to Clipboard Toggle word wrap
  5. 如果 pod 存在问题,请检查有问题的容器日志。要检查 ironic 服务的日志,请运行以下命令:

    [core@localhost ~]$ sudo podman logs ironic
    Copy to Clipboard Toggle word wrap

3.5.4. 调查不可用的 Kubernetes API

当 Kubernetes API 不可用时,检查 control plane 节点以确保它们运行正确的组件。另外,检查主机名解析。

流程

  1. 运行以下命令,确保 etcd 在每个 control plane 节点上运行:

    $ sudo crictl logs $(sudo crictl ps --pod=$(sudo crictl pods --name=etcd-member --quiet) --quiet)
    Copy to Clipboard Toggle word wrap
  2. 如果上一命令失败,请运行以下命令确保 Kubelet 创建 etcd pod:

    $ sudo crictl pods --name=etcd-member
    Copy to Clipboard Toggle word wrap

    如果没有 pod,请调查 etcd

  3. 使用以下命令检查集群节点,以确保它们具有完全限定域名,而不只是 localhost.localdomain

    $ hostname
    Copy to Clipboard Toggle word wrap

    如果没有设置主机名,请设置正确的主机名。例如:

    $ sudo hostnamectl set-hostname <hostname>
    Copy to Clipboard Toggle word wrap
  4. 使用 dig 命令,确保每个节点在 DNS 服务器中具有正确的名称解析:

    $ dig api.<cluster_name>.example.com
    Copy to Clipboard Toggle word wrap
    ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el8 <<>> api.<cluster_name>.example.com
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37551
    ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2
    
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 4096
    ; COOKIE: 866929d2f8e8563582af23f05ec44203d313e50948d43f60 (good)
    ;; QUESTION SECTION:
    ;api.<cluster_name>.example.com. IN A
    
    ;; ANSWER SECTION:
    api.<cluster_name>.example.com. 10800 IN	A 10.19.13.86
    
    ;; AUTHORITY SECTION:
    <cluster_name>.example.com. 10800 IN NS	<cluster_name>.example.com.
    
    ;; ADDITIONAL SECTION:
    <cluster_name>.example.com. 10800 IN A	10.19.14.247
    
    ;; Query time: 0 msec
    ;; SERVER: 10.19.14.247#53(10.19.14.247)
    ;; WHEN: Tue May 19 20:30:59 UTC 2020
    ;; MSG SIZE  rcvd: 140
    Copy to Clipboard Toggle word wrap

    示例中的输出显示 api.<cluster_name>.example.com VIP 的适当 IP 地址为 10.19.13.86。此 IP 地址应当位于 baremetal 网络中。

3.5.5. 对初始化集群失败进行故障排除

安装程序使用 Cluster Version Operator 创建 OpenShift Container Platform 集群的所有组件。当安装程序无法初始化集群时,您可以从 ClusterVersionClusterOperator 对象检索最重要的信息。

流程

  1. 运行以下命令检查 ClusterVersion 对象:

    $ oc --kubeconfig=${INSTALL_DIR}/auth/kubeconfig get clusterversion -o yaml
    Copy to Clipboard Toggle word wrap

    输出示例

    apiVersion: config.openshift.io/v1
    kind: ClusterVersion
    metadata:
      creationTimestamp: 2019-02-27T22:24:21Z
      generation: 1
      name: version
      resourceVersion: "19927"
      selfLink: /apis/config.openshift.io/v1/clusterversions/version
      uid: 6e0f4cf8-3ade-11e9-9034-0a923b47ded4
    spec:
      channel: stable-4.1
      clusterID: 5ec312f9-f729-429d-a454-61d4906896ca
    status:
      availableUpdates: null
      conditions:
      - lastTransitionTime: 2019-02-27T22:50:30Z
        message: Done applying 4.1.1
        status: "True"
        type: Available
      - lastTransitionTime: 2019-02-27T22:50:30Z
        status: "False"
        type: Failing
      - lastTransitionTime: 2019-02-27T22:50:30Z
        message: Cluster version is 4.1.1
        status: "False"
        type: Progressing
      - lastTransitionTime: 2019-02-27T22:24:31Z
        message: 'Unable to retrieve available updates: unknown version 4.1.1
        reason: RemoteFailed
        status: "False"
        type: RetrievedUpdates
      desired:
        image: registry.svc.ci.openshift.org/openshift/origin-release@sha256:91e6f754975963e7db1a9958075eb609ad226968623939d262d1cf45e9dbc39a
        version: 4.1.1
      history:
      - completionTime: 2019-02-27T22:50:30Z
        image: registry.svc.ci.openshift.org/openshift/origin-release@sha256:91e6f754975963e7db1a9958075eb609ad226968623939d262d1cf45e9dbc39a
        startedTime: 2019-02-27T22:24:31Z
        state: Completed
        version: 4.1.1
      observedGeneration: 1
      versionHash: Wa7as_ik1qE=
    Copy to Clipboard Toggle word wrap

  2. 运行以下命令来查看条件:

    $ oc --kubeconfig=${INSTALL_DIR}/auth/kubeconfig get clusterversion version \
         -o=jsonpath='{range .status.conditions[*]}{.type}{" "}{.status}{" "}{.message}{"\n"}{end}'
    Copy to Clipboard Toggle word wrap

    某些最重要的条件包括 FailingAvailableProgressing

    输出示例

    Available True Done applying 4.1.1
    Failing False
    Progressing False Cluster version is 4.0.0-0.alpha-2019-02-26-194020
    RetrievedUpdates False Unable to retrieve available updates: unknown version 4.1.1
    Copy to Clipboard Toggle word wrap

  3. 运行以下命令检查 ClusterOperator 对象:

    $ oc --kubeconfig=${INSTALL_DIR}/auth/kubeconfig get clusteroperator
    Copy to Clipboard Toggle word wrap

    该命令返回集群 Operator 的状态。

    输出示例

    NAME                                  VERSION   AVAILABLE   PROGRESSING   FAILING   SINCE
    cluster-baremetal-operator                      True        False         False     17m
    cluster-autoscaler                              True        False         False     17m
    cluster-storage-operator                        True        False         False     10m
    console                                         True        False         False     7m21s
    dns                                             True        False         False     31m
    image-registry                                  True        False         False     9m58s
    ingress                                         True        False         False     10m
    kube-apiserver                                  True        False         False     28m
    kube-controller-manager                         True        False         False     21m
    kube-scheduler                                  True        False         False     25m
    machine-api                                     True        False         False     17m
    machine-config                                  True        False         False     17m
    marketplace-operator                            True        False         False     10m
    monitoring                                      True        False         False     8m23s
    network                                         True        False         False     13m
    node-tuning                                     True        False         False     11m
    openshift-apiserver                             True        False         False     15m
    openshift-authentication                        True        False         False     20m
    openshift-cloud-credential-operator             True        False         False     18m
    openshift-controller-manager                    True        False         False     10m
    openshift-samples                               True        False         False     8m42s
    operator-lifecycle-manager                      True        False         False     17m
    service-ca                                      True        False         False     30m
    Copy to Clipboard Toggle word wrap

  4. 运行以下命令检查单个集群 Operator:

    $ oc --kubeconfig=${INSTALL_DIR}/auth/kubeconfig get clusteroperator <operator> -oyaml 
    1
    Copy to Clipboard Toggle word wrap
    1
    <operator> 替换为集群 Operator 的名称。此命令可用于识别集群 Operator 没有达到 Available 状态的原因或处于 Failed 状态。

    输出示例

    apiVersion: config.openshift.io/v1
    kind: ClusterOperator
    metadata:
      creationTimestamp: 2019-02-27T22:47:04Z
      generation: 1
      name: monitoring
      resourceVersion: "24677"
      selfLink: /apis/config.openshift.io/v1/clusteroperators/monitoring
      uid: 9a6a5ef9-3ae1-11e9-bad4-0a97b6ba9358
    spec: {}
    status:
      conditions:
      - lastTransitionTime: 2019-02-27T22:49:10Z
        message: Successfully rolled out the stack.
        status: "True"
        type: Available
      - lastTransitionTime: 2019-02-27T22:49:10Z
        status: "False"
        type: Progressing
      - lastTransitionTime: 2019-02-27T22:49:10Z
        status: "False"
        type: Failing
      extension: null
      relatedObjects: null
      version: ""
    Copy to Clipboard Toggle word wrap

  5. 要获取集群 Operator 的状态条件,请运行以下命令:

    $ oc --kubeconfig=${INSTALL_DIR}/auth/kubeconfig get clusteroperator <operator> \
         -o=jsonpath='{range .status.conditions[*]}{.type}{" "}{.status}{" "}{.message}{"\n"}{end}'
    Copy to Clipboard Toggle word wrap

    <operator> 替换为以上其中一个 Operator 的名称。

    输出示例

    Available True Successfully rolled out the stack
    Progressing False
    Failing False
    Copy to Clipboard Toggle word wrap

  6. 要检索集群 Operator 拥有的对象列表,请执行以下命令:

    oc --kubeconfig=${INSTALL_DIR}/auth/kubeconfig get clusteroperator kube-apiserver \
       -o=jsonpath='{.status.relatedObjects}'
    Copy to Clipboard Toggle word wrap

    输出示例

    [map[resource:kubeapiservers group:operator.openshift.io name:cluster] map[group: name:openshift-config resource:namespaces] map[group: name:openshift-config-managed resource:namespaces] map[group: name:openshift-kube-apiserver-operator resource:namespaces] map[group: name:openshift-kube-apiserver resource:namespaces]]
    Copy to Clipboard Toggle word wrap

3.5.6. 对获取控制台 URL 失败进行故障排除

安装程序通过在 openshift-console 命名空间中使用 [route][route-object] 检索 OpenShift Container Platform 控制台的 URL。如果安装程序失败,请检索控制台的 URL,请使用以下步骤。

流程

  1. 运行以下命令,检查控制台路由器是否处于 AvailableFailing 状态:

    $ oc --kubeconfig=${INSTALL_DIR}/auth/kubeconfig get clusteroperator console -oyaml
    Copy to Clipboard Toggle word wrap
    apiVersion: config.openshift.io/v1
    kind: ClusterOperator
    metadata:
      creationTimestamp: 2019-02-27T22:46:57Z
      generation: 1
      name: console
      resourceVersion: "19682"
      selfLink: /apis/config.openshift.io/v1/clusteroperators/console
      uid: 960364aa-3ae1-11e9-bad4-0a97b6ba9358
    spec: {}
    status:
      conditions:
      - lastTransitionTime: 2019-02-27T22:46:58Z
        status: "False"
        type: Failing
      - lastTransitionTime: 2019-02-27T22:50:12Z
        status: "False"
        type: Progressing
      - lastTransitionTime: 2019-02-27T22:50:12Z
        status: "True"
        type: Available
      - lastTransitionTime: 2019-02-27T22:46:57Z
        status: "True"
        type: Upgradeable
      extension: null
      relatedObjects:
      - group: operator.openshift.io
        name: cluster
        resource: consoles
      - group: config.openshift.io
        name: cluster
        resource: consoles
      - group: oauth.openshift.io
        name: console
        resource: oauthclients
      - group: ""
        name: openshift-console-operator
        resource: namespaces
      - group: ""
        name: openshift-console
        resource: namespaces
      versions: null
    Copy to Clipboard Toggle word wrap
  2. 执行以下命令手动检索控制台 URL:

    $ oc --kubeconfig=${INSTALL_DIR}/auth/kubeconfig get route console -n openshift-console \
         -o=jsonpath='{.spec.host}' console-openshift-console.apps.adahiya-1.devcluster.openshift.com
    Copy to Clipboard Toggle word wrap

安装程序将默认入口证书添加到 ${INSTALL_DIR}/auth/kubeconfig 中的可信客户端证书颁发机构列表中。如果安装程序无法将入口证书添加到 kubeconfig 文件中,您可以从集群中检索证书并添加它。

流程

  1. 使用以下命令从集群中删除证书:

    $ oc --kubeconfig=${INSTALL_DIR}/auth/kubeconfig get configmaps default-ingress-cert \
         -n openshift-config-managed -o=jsonpath='{.data.ca-bundle\.crt}'
    Copy to Clipboard Toggle word wrap
    -----BEGIN CERTIFICATE-----
    MIIC/TCCAeWgAwIBAgIBATANBgkqhkiG9w0BAQsFADAuMSwwKgYDVQQDDCNjbHVz
    dGVyLWluZ3Jlc3Mtb3BlcmF0b3JAMTU1MTMwNzU4OTAeFw0xOTAyMjcyMjQ2Mjha
    Fw0yMTAyMjYyMjQ2MjlaMC4xLDAqBgNVBAMMI2NsdXN0ZXItaW5ncmVzcy1vcGVy
    YXRvckAxNTUxMzA3NTg5MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA
    uCA4fQ+2YXoXSUL4h/mcvJfrgpBfKBW5hfB8NcgXeCYiQPnCKblH1sEQnI3VC5Pk
    2OfNCF3PUlfm4i8CHC95a7nCkRjmJNg1gVrWCvS/ohLgnO0BvszSiRLxIpuo3C4S
    EVqqvxValHcbdAXWgZLQoYZXV7RMz8yZjl5CfhDaaItyBFj3GtIJkXgUwp/5sUfI
    LDXW8MM6AXfuG+kweLdLCMm3g8WLLfLBLvVBKB+4IhIH7ll0buOz04RKhnYN+Ebw
    tcvFi55vwuUCWMnGhWHGEQ8sWm/wLnNlOwsUz7S1/sW8nj87GFHzgkaVM9EOnoNI
    gKhMBK9ItNzjrP6dgiKBCQIDAQABoyYwJDAOBgNVHQ8BAf8EBAMCAqQwEgYDVR0T
    AQH/BAgwBgEB/wIBADANBgkqhkiG9w0BAQsFAAOCAQEAq+vi0sFKudaZ9aUQMMha
    CeWx9CZvZBblnAWT/61UdpZKpFi4eJ2d33lGcfKwHOi2NP/iSKQBebfG0iNLVVPz
    vwLbSG1i9R9GLdAbnHpPT9UG6fLaDIoKpnKiBfGENfxeiq5vTln2bAgivxrVlyiq
    +MdDXFAWb6V4u2xh6RChI7akNsS3oU9PZ9YOs5e8vJp2YAEphht05X0swA+X8V8T
    C278FFifpo0h3Q0Dbv8Rfn4UpBEtN4KkLeS+JeT+0o2XOsFZp7Uhr9yFIodRsnNo
    H/Uwmab28ocNrGNiEVaVH6eTTQeeZuOdoQzUbClElpVmkrNGY0M42K0PvOQ/e7+y
    AQ==
    -----END CERTIFICATE-----
    Copy to Clipboard Toggle word wrap
  2. 将证书添加到 ${INSTALL_DIR}/auth/kubeconfig 文件中的 client-certificate-authority-data 字段中。

3.5.8. 对集群节点的 SSH 访问故障排除

为提高安全性,您无法默认从集群外部通过 SSH 连接到集群。但是,您可以从 provisioner 节点访问 control plane 和 worker 节点。如果无法从 provisioner 节点通过 SSH 连接到集群节点,则节点可能会在 bootstrap 虚拟机上等待。control plane 节点从 bootstrap 虚拟机检索其引导配置,如果它们没有检索引导配置,则无法成功引导。

流程

  1. 如果您有对节点的物理访问权限,请检查其控制台输出以确定它们是否已成功引导。如果节点仍然检索其引导配置,则 bootstrap 虚拟机可能会出现问题。
  2. 确保您在 install-config.yaml 文件中配置了 sshKey: '<ssh_pub_key>' 设置,其中 <ssh_pub_key> 是 provisioner 节点上的 kni 用户的公钥。

3.5.9. 集群节点不能 PXE 引导

当 OpenShift Container Platform 集群节点无法 PXE 引导时,请在不能 PXE 引导的集群节点上执行以下检查。在没有 provisioning 网络安装 OpenShift Container Platform 集群时,此流程不适用。

流程

  1. 检查与 provisioning 网络的网络连接。
  2. 确保 provisioning 网络的 NIC 上启用了 PXE,并为所有其他 NIC 禁用 PXE。
  3. 验证 install-config.yaml 配置文件是否包含 rootDeviceHints 参数,以及连接到 provisioning 网络的 NIC 的引导 MAC 地址。例如:

    control plane 节点设置

    bootMACAddress: 24:6E:96:1B:96:90 # MAC of bootable provisioning NIC
    Copy to Clipboard Toggle word wrap

    Worker 节点设置

    bootMACAddress: 24:6E:96:1B:96:90 # MAC of bootable provisioning NIC
    Copy to Clipboard Toggle word wrap

3.5.10. 安装不会创建 worker 节点

安装程序不会直接置备 worker 节点。相反,Machine API Operator 会在受支持的平台上扩展节点。如果 worker 节点在 15 到 20 分钟后没有创建,具体取决于集群互联网连接的速度,请调查 Machine API Operator。

流程

  1. 运行以下命令检查 Machine API Operator:

    $ oc --kubeconfig=${INSTALL_DIR}/auth/kubeconfig \
       --namespace=openshift-machine-api get deployments
    Copy to Clipboard Toggle word wrap

    如果环境中没有设置 ${INSTALL_DIR},请将该值替换为安装目录的名称。

    输出示例

    NAME                          READY   UP-TO-DATE   AVAILABLE   AGE
    cluster-autoscaler-operator   1/1     1            1           86m
    cluster-baremetal-operator    1/1     1            1           86m
    machine-api-controllers       1/1     1            1           85m
    machine-api-operator          1/1     1            1           86m
    Copy to Clipboard Toggle word wrap

  2. 运行以下命令检查机器控制器日志:

    $ oc --kubeconfig=${INSTALL_DIR}/auth/kubeconfig \
         --namespace=openshift-machine-api logs deployments/machine-api-controllers \
         --container=machine-controller
    Copy to Clipboard Toggle word wrap

3.5.11. Cluster Network Operator 故障排除

Cluster Network Operator 负责部署网络组件。它在安装过程中的早期运行,在 control plane 节点启动后,但安装程序删除 bootstrap control plane 前。此 Operator 的问题可能表示安装程序问题。

流程

  1. 运行以下命令确保网络配置存在:

    $ oc get network -o yaml cluster
    Copy to Clipboard Toggle word wrap

    如果不存在,安装程序不会创建它。要找出原因,请运行以下命令:

    $ openshift-install create manifests
    Copy to Clipboard Toggle word wrap

    查看清单,以确定安装程序没有创建网络配置的原因。

  2. 输入以下命令来确保网络正在运行:

    $ oc get po -n openshift-network-operator
    Copy to Clipboard Toggle word wrap

3.5.12. 无法使用 BMC 发现新的裸机主机

在某些情况下,安装程序将无法发现新的裸机主机并发出错误,因为它无法挂载远程虚拟介质共享。

例如:

ProvisioningError 51s metal3-baremetal-controller Image provisioning failed: Deploy step deploy.deploy failed with BadRequestError: HTTP POST
https://<bmc_address>/redfish/v1/Managers/iDRAC.Embedded.1/VirtualMedia/CD/Actions/VirtualMedia.InsertMedia
returned code 400.
Base.1.8.GeneralError: A general error has occurred. See ExtendedInfo for more information
Extended information: [
  {
    "Message": "Unable to mount remote share https://<ironic_address>/redfish/boot-<uuid>.iso.",
    "MessageArgs": [
      "https://<ironic_address>/redfish/boot-<uuid>.iso"
    ],
    "MessageArgs@odata.count": 1,
    "MessageId": "IDRAC.2.5.RAC0720",
    "RelatedProperties": [
      "#/Image"
    ],
    "RelatedProperties@odata.count": 1,
    "Resolution": "Retry the operation.",
    "Severity": "Informational"
  }
].
Copy to Clipboard Toggle word wrap

在这种情况下,如果您使用带有未知证书颁发机构的虚拟介质,您可以配置基板管理控制器 (BMC) 远程文件共享设置,以信任未知证书颁发机构以避免这个错误。

注意

这个解析已在带有 Dell iDRAC 9 的 OpenShift Container Platform 4.11 上测试,固件版本 5.10.50。

3.5.13. 无法加入集群的 worker 节点故障排除

安装程序置备的集群使用 DNS 服务器部署,其中包含 api-int.<cluster_name>.<base_domain> URL 的 DNS 条目。如果集群中的节点使用外部或上游 DNS 服务器解析 api-int.<cluster_name>.<base_domain> URL,且没有这样的条目,则 worker 节点可能无法加入集群。确保集群中的所有节点都可以解析域名。

流程

  1. 添加 DNS A/AAAA 或 CNAME 记录,以内部标识 API 负载均衡器。例如,在使用 dnsmasq 时,修改 dnsmasq.conf 配置文件:

    $ sudo nano /etc/dnsmasq.conf
    Copy to Clipboard Toggle word wrap
    address=/api-int.<cluster_name>.<base_domain>/<IP_address>
    address=/api-int.mycluster.example.com/192.168.1.10
    address=/api-int.mycluster.example.com/2001:0db8:85a3:0000:0000:8a2e:0370:7334
    Copy to Clipboard Toggle word wrap
  2. 添加 DNS PTR 记录以内部标识 API 负载均衡器。例如,在使用 dnsmasq 时,修改 dnsmasq.conf 配置文件:

    $ sudo nano /etc/dnsmasq.conf
    Copy to Clipboard Toggle word wrap
    ptr-record=<IP_address>.in-addr.arpa,api-int.<cluster_name>.<base_domain>
    ptr-record=10.1.168.192.in-addr.arpa,api-int.mycluster.example.com
    Copy to Clipboard Toggle word wrap
  3. 重启 DNS 服务器。例如,在使用 dnsmasq 时执行以下命令:

    $ sudo systemctl restart dnsmasq
    Copy to Clipboard Toggle word wrap

这些记录必须可以从集群中的所有节点解析。

3.5.14. 清理以前的安装

如果以前部署失败,请在尝试再次部署 OpenShift Container Platform 前从失败的尝试中删除工件。

流程

  1. 使用以下命令安装 OpenShift Container Platform 集群前关闭所有裸机节点:

    $ ipmitool -I lanplus -U <user> -P <password> -H <management_server_ip> power off
    Copy to Clipboard Toggle word wrap
  2. 使用以下脚本,删除所有旧的 bootstrap 资源:

    for i in $(sudo virsh list | tail -n +3 | grep bootstrap | awk {'print $2'});
    do
      sudo virsh destroy $i;
      sudo virsh undefine $i;
      sudo virsh vol-delete $i --pool $i;
      sudo virsh vol-delete $i.ign --pool $i;
      sudo virsh pool-destroy $i;
      sudo virsh pool-undefine $i;
    done
    Copy to Clipboard Toggle word wrap
  3. 使用以下命令删除早期安装生成的工件:

    $ cd ; /bin/rm -rf auth/ bootstrap.ign master.ign worker.ign metadata.json \
    .openshift_install.log .openshift_install_state.json
    Copy to Clipboard Toggle word wrap
  4. 使用以下命令重新创建 OpenShift Container Platform 清单:

    $ ./openshift-baremetal-install --dir ~/clusterconfigs create manifests
    Copy to Clipboard Toggle word wrap

3.5.15. 创建 registry 的问题

在创建断开连接的 registry 时,在尝试镜像 registry 时,可能会遇到 "User Not Authorized" 错误。如果您没有将新身份验证附加到现有的 pull-secret.txt 文件中,可能会发生这个错误。

流程

  1. 检查以确保身份验证成功:

    $ /usr/local/bin/oc adm release mirror \
      -a pull-secret-update.json
      --from=$UPSTREAM_REPO \
      --to-release-image=$LOCAL_REG/$LOCAL_REPO:${VERSION} \
      --to=$LOCAL_REG/$LOCAL_REPO
    Copy to Clipboard Toggle word wrap
    注意

    用于镜像安装镜像的变量输出示例:

    UPSTREAM_REPO=${RELEASE_IMAGE}
    LOCAL_REG=<registry_FQDN>:<registry_port>
    LOCAL_REPO='ocp4/openshift4'
    Copy to Clipboard Toggle word wrap

    在为 OpenShift 安装设置环境 部分的 获取 OpenShift 安装程序 步骤中,设置了 RELEASE_IMAGEVERSION 的值。

  2. 镜像 registry 后,确认您可以在断开连接的环境中访问它:

    $ curl -k -u <user>:<password> https://registry.example.com:<registry_port>/v2/_catalog
    {"repositories":["<Repo_Name>"]}
    Copy to Clipboard Toggle word wrap

3.5.16. 其它问题

3.5.16.1. 解决 运行时网络未就绪 错误

部署集群后,您可能会收到以下错误:

`runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: Missing CNI default network`
Copy to Clipboard Toggle word wrap

Cluster Network Operator 负责部署网络组件以响应安装程序创建的特殊对象。它会在安装过程的早期阶段运行(在 control plane(master)节点启动后,bootstrap control plane 被停止前运行。它可能会显示更细微的安装程序问题,比如启动 control plane (master)节点时延迟时间过长,或者 apiserver 通讯的问题。

流程

  1. 检查 openshift-network-operator 命名空间中的 pod:

    $ oc get all -n openshift-network-operator
    Copy to Clipboard Toggle word wrap
    NAME                                    READY STATUS            RESTARTS   AGE
    pod/network-operator-69dfd7b577-bg89v   0/1   ContainerCreating 0          149m
    Copy to Clipboard Toggle word wrap
  2. provisioner 节点上,确定存在网络配置:

    $ kubectl get network.config.openshift.io cluster -oyaml
    Copy to Clipboard Toggle word wrap
    apiVersion: config.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
      serviceNetwork:
      - 172.30.0.0/16
      clusterNetwork:
      - cidr: 10.128.0.0/14
        hostPrefix: 23
      networkType: OVNKubernetes
    Copy to Clipboard Toggle word wrap

    如果不存在,安装程序不会创建它。要确定安装程序没有创建它的原因,请执行以下操作:

    $ openshift-install create manifests
    Copy to Clipboard Toggle word wrap
  3. 检查 network-operator 是否正在运行:

    $ kubectl -n openshift-network-operator get pods
    Copy to Clipboard Toggle word wrap
  4. 检索日志:

    $ kubectl -n openshift-network-operator logs -l "name=network-operator"
    Copy to Clipboard Toggle word wrap

    在具有三个或更多 control plane 节点的高可用性集群中,Operator 将执行领导选举机制,所有其他 Operator 将会休眠。如需了解更多详细信息,请参阅 故障排除

部署集群后,您可能会收到以下出错信息:

No disk found with matching rootDeviceHints
Copy to Clipboard Toggle word wrap

要解决 No disk found with matching rootDeviceHints 错误,一个临时解决方法是将 rootDeviceHints 更改为 minSizeGigabytes: 300

更改 rootDeviceHints 设置后,使用以下命令引导 CoreOS,然后使用以下命令验证磁盘信息:

$ udevadm info /dev/sda
Copy to Clipboard Toggle word wrap

如果您使用 DL360 Gen 10 服务器,请注意它们有一个 SD-card 插槽,它可能会被分配 /dev/sda 设备名称。如果服务器中没有 SD 卡,可能会导致冲突。确定在服务器的 BIOS 设置中禁用 SD 卡插槽。

如果 minSizeGigabytes 临时解决方案没有满足要求,您可能需要将 rootDeviceHints 恢复为 /dev/sda。此更改允许 ironic 镜像成功引导。

修复此问题的另一种方法是使用磁盘的串行 ID。但是,请注意,发现串行 ID 可能具有挑战性,并且可能会导致配置文件无法读取。如果选择此路径,请确保使用之前记录的命令收集串行 ID,并将其合并到您的配置中。

如果集群节点没有通过 DHCP 获得正确的 IPv6 地址,请检查以下内容:

  1. 确保保留的 IPv6 地址不在 DHCP 范围内。
  2. 在 DHCP 服务器上的 IP 地址保留中,确保保留指定了正确的 DHCP 唯一标识符(DUID)。例如:

    # This is a dnsmasq dhcp reservation, 'id:00:03:00:01' is the client id and '18:db:f2:8c:d5:9f' is the MAC Address for the NIC
    id:00:03:00:01:18:db:f2:8c:d5:9f,openshift-master-1,[2620:52:0:1302::6]
    Copy to Clipboard Toggle word wrap
  3. 确保路由声明正常工作。
  4. 确保 DHCP 服务器正在侦听提供 IP 地址范围所需的接口。

在 IPv6 部署过程中,集群节点必须通过 DHCP 获得其主机名。有时 NetworkManager 不会立即分配主机名。control plane(master)节点可能会报告错误,例如:

Failed Units: 2
  NetworkManager-wait-online.service
  nodeip-configuration.service
Copy to Clipboard Toggle word wrap

这个错误表示集群节点可能在没有从 DHCP 服务器接收主机名的情况下引导,这会导致 kubelet 使用 localhost.localdomain 主机名引导。要解决错误,请强制节点更新主机名。

流程

  1. 检索 主机名

    [core@master-X ~]$ hostname
    Copy to Clipboard Toggle word wrap

    如果主机名是 localhost,请执行以下步骤。

    注意

    其中 X 是 control plane 节点号。

  2. 强制集群节点续订 DHCP 租期:

    [core@master-X ~]$ sudo nmcli con up "<bare_metal_nic>"
    Copy to Clipboard Toggle word wrap

    <bare_metal_nic> 替换为与 baremetal 网络对应的有线连接。

  3. 再次检查 主机名

    [core@master-X ~]$ hostname
    Copy to Clipboard Toggle word wrap
  4. 如果主机名仍然是 localhost.localdomain,重启 NetworkManager

    [core@master-X ~]$ sudo systemctl restart NetworkManager
    Copy to Clipboard Toggle word wrap
  5. 如果主机名仍然是 localhost.localdomain,请等待几分钟并再次检查。如果主机名仍为 localhost.localdomain,请重复前面的步骤。
  6. 重启 nodeip-configuration 服务:

    [core@master-X ~]$ sudo systemctl restart nodeip-configuration.service
    Copy to Clipboard Toggle word wrap

    此服务将使用正确的主机名引用来重新配置 kubelet 服务。

  7. 因为 kubelet 在上一步中更改,所以重新载入单元文件定义:

    [core@master-X ~]$ sudo systemctl daemon-reload
    Copy to Clipboard Toggle word wrap
  8. 重启 kubelet 服务:

    [core@master-X ~]$ sudo systemctl restart kubelet.service
    Copy to Clipboard Toggle word wrap
  9. 确保 kubelet 使用正确的主机名引导:

    [core@master-X ~]$ sudo journalctl -fu kubelet.service
    Copy to Clipboard Toggle word wrap

如果集群节点在集群启动并运行后没有通过 DHCP 获得正确的主机名,比如在重启过程中,集群会有一个待处理的 csr不要 批准 csr,否则可能会出现其他问题。

处理 csr

  1. 在集群上获取 CSR:

    $ oc get csr
    Copy to Clipboard Toggle word wrap
  2. 验证待处理的 csr 是否包含 Subject Name: localhost.localdomain:

    $ oc get csr <pending_csr> -o jsonpath='{.spec.request}' | base64 --decode | openssl req -noout -text
    Copy to Clipboard Toggle word wrap
  3. 删除包含 Subject Name: localhost.localdomain 的任何 csr

    $ oc delete csr <wrong_csr>
    Copy to Clipboard Toggle word wrap
3.5.16.5. 路由无法访问端点

在安装过程中,可能会出现虚拟路由器冗余协议(VRRP)冲突。如果之前使用特定集群名称部署的 OpenShift Container Platform 节点仍在运行,但不是使用相同集群名称部署的当前 OpenShift Container Platform 集群的一部分,则可能会出现冲突。例如,一个集群使用集群名称 openshift 部署,它 部署了三个 control plane(master)节点和三个 worker 节点。之后,一个单独的安装使用相同的集群名称 openshift,但这个重新部署只安装了三个 control plane(master)节点,使以前部署的三个 worker 节点处于 ON 状态。这可能导致 Virtual Router Identifier(VRID)冲突和 VRRP 冲突。

  1. 获取路由:

    $ oc get route oauth-openshift
    Copy to Clipboard Toggle word wrap
  2. 检查服务端点:

    $ oc get svc oauth-openshift
    Copy to Clipboard Toggle word wrap
    NAME              TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
    oauth-openshift   ClusterIP   172.30.19.162   <none>        443/TCP   59m
    Copy to Clipboard Toggle word wrap
  3. 尝试从 control plane(master)节点访问该服务:

    [core@master0 ~]$ curl -k https://172.30.19.162
    Copy to Clipboard Toggle word wrap
    {
      "kind": "Status",
      "apiVersion": "v1",
      "metadata": {
      },
      "status": "Failure",
      "message": "forbidden: User \"system:anonymous\" cannot get path \"/\"",
      "reason": "Forbidden",
      "details": {
      },
      "code": 403
    Copy to Clipboard Toggle word wrap
  4. 识别 provisioner 节点的 authentication-operator 错误:

    $ oc logs deployment/authentication-operator -n openshift-authentication-operator
    Copy to Clipboard Toggle word wrap
    Event(v1.ObjectReference{Kind:"Deployment", Namespace:"openshift-authentication-operator", Name:"authentication-operator", UID:"225c5bd5-b368-439b-9155-5fd3c0459d98", APIVersion:"apps/v1", ResourceVersion:"", FieldPath:""}): type: 'Normal' reason: 'OperatorStatusChanged' Status for clusteroperator/authentication changed: Degraded message changed from "IngressStateEndpointsDegraded: All 2 endpoints for oauth-server are reporting"
    Copy to Clipboard Toggle word wrap

解决方案

  1. 确保每个部署的集群名称都是唯一的,确保没有冲突。
  2. 关闭所有不是使用相同集群名称的集群部署的一部分的节点。否则,OpenShift Container Platform 集群的身份验证 pod 可能无法成功启动。
3.5.16.6. 在 Firstboot 过程中 Ignition 失败

在 Firstboot 过程中,Ignition 配置可能会失败。

流程

  1. 连接到 Ignition 配置失败的节点:

    Failed Units: 1
      machine-config-daemon-firstboot.service
    Copy to Clipboard Toggle word wrap
  2. 重启 machine-config-daemon-firstboot 服务:

    [core@worker-X ~]$ sudo systemctl restart machine-config-daemon-firstboot.service
    Copy to Clipboard Toggle word wrap
3.5.16.7. NTP 不同步

OpenShift Container Platform 集群的部署需要集群节点间的 NTP 同步时钟。如果没有同步时钟,如果时间差大于 2 秒,则部署可能会因为时钟偏移而失败。

流程

  1. 检查集群节点的 AGE 的不同。例如:

    $ oc get nodes
    Copy to Clipboard Toggle word wrap
    NAME                         STATUS   ROLES    AGE   VERSION
    master-0.cloud.example.com   Ready    master   145m   v1.32.3
    master-1.cloud.example.com   Ready    master   135m   v1.32.3
    master-2.cloud.example.com   Ready    master   145m   v1.32.3
    worker-2.cloud.example.com   Ready    worker   100m   v1.32.3
    Copy to Clipboard Toggle word wrap
  2. 检查时钟偏移导致的时间延迟。例如:

    $ oc get bmh -n openshift-machine-api
    Copy to Clipboard Toggle word wrap
    master-1   error registering master-1  ipmi://<out_of_band_ip>
    Copy to Clipboard Toggle word wrap
    $ sudo timedatectl
    Copy to Clipboard Toggle word wrap
                   Local time: Tue 2020-03-10 18:20:02 UTC
               Universal time: Tue 2020-03-10 18:20:02 UTC
                     RTC time: Tue 2020-03-10 18:36:53
                    Time zone: UTC (UTC, +0000)
    System clock synchronized: no
                  NTP service: active
              RTC in local TZ: no
    Copy to Clipboard Toggle word wrap

处理现有集群中的时钟偏移

  1. 创建一个 Butane 配置文件,其中包含要发送到节点的 chrony.conf 文件的内容。在以下示例中,创建 99-master-chrony.bu 将文件添加到 control plane 节点。您可以修改 worker 节点的 文件,或者对 worker 角色重复此步骤。

    注意

    有关 Butane 的信息,请参阅"使用 Butane 创建机器配置"。

    variant: openshift
    version: 4.19.0
    metadata:
      name: 99-master-chrony
      labels:
        machineconfiguration.openshift.io/role: master
    storage:
      files:
      - path: /etc/chrony.conf
        mode: 0644
        overwrite: true
        contents:
          inline: |
            server <NTP_server> iburst 
    1
    
            stratumweight 0
            driftfile /var/lib/chrony/drift
            rtcsync
            makestep 10 3
            bindcmdaddress 127.0.0.1
            bindcmdaddress ::1
            keyfile /etc/chrony.keys
            commandkey 1
            generatecommandkey
            noclientlog
            logchange 0.5
            logdir /var/log/chrony
    Copy to Clipboard Toggle word wrap
    1
    <NTP_server> 替换为 NTP 服务器的 IP 地址。
  2. 使用 Butane 生成 MachineConfig 对象文件 99-master-chrony.yaml,其中包含要交付至节点的配置:

    $ butane 99-master-chrony.bu -o 99-master-chrony.yaml
    Copy to Clipboard Toggle word wrap
  3. 应用 MachineConfig 对象文件:

    $ oc apply -f 99-master-chrony.yaml
    Copy to Clipboard Toggle word wrap
  4. 确保 系统时钟同步 值为 yes

    $ sudo timedatectl
    Copy to Clipboard Toggle word wrap
                   Local time: Tue 2020-03-10 19:10:02 UTC
               Universal time: Tue 2020-03-10 19:10:02 UTC
                     RTC time: Tue 2020-03-10 19:36:53
                    Time zone: UTC (UTC, +0000)
    System clock synchronized: yes
                  NTP service: active
              RTC in local TZ: no
    Copy to Clipboard Toggle word wrap

    要在部署前设置时钟同步,请生成清单文件并将此文件添加到 openshift 目录中。例如:

    $ cp chrony-masters.yaml ~/clusterconfigs/openshift/99_masters-chrony-configuration.yaml
    Copy to Clipboard Toggle word wrap

    然后,继续创建集群。

3.5.17. 检查安装

安装后,请确保安装程序成功部署节点和 pod。

流程

  1. 当正确安装 OpenShift Container Platform 集群节点时,在 STATUS 列中会显示以下 Ready 状态

    $ oc get nodes
    Copy to Clipboard Toggle word wrap
    NAME                   STATUS   ROLES           AGE  VERSION
    master-0.example.com   Ready    master,worker   4h   v1.32.3
    master-1.example.com   Ready    master,worker   4h   v1.32.3
    master-2.example.com   Ready    master,worker   4h   v1.32.3
    Copy to Clipboard Toggle word wrap
  2. 确认安装程序成功部署了所有 pod。以下命令将移除仍在运行或已完成的 pod 作为输出的一部分。

    $ oc get pods --all-namespaces | grep -iv running | grep -iv complete
    Copy to Clipboard Toggle word wrap

第 4 章 安装后配置

成功部署裸机集群后,请考虑以下安装后流程。

4.1. 关于集群 API

OpenShift Container Platform 4.19 及更新的版本可以使用 Cluster API 管理机器。

重要

使用集群 API 管理机器只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围

您可以在集群安装完成后使用 Cluster API 执行计算节点置备管理操作。Cluster API 允许动态管理计算节点机器集和机器。但是,不支持 control plane 机器。

4.2. 为断开连接的集群配置 NTP

OpenShift Container Platform 在集群节点上安装 chrony 网络时间协议(NTP)服务。使用以下步骤在 control plane 节点上配置 NTP 服务器,并将计算节点配置为成功部署后,将 worker 节点配置为 control plane 节点的 NTP 客户端。

OpenShift Container Platform 节点必须在日期和时间上达成一致才能正确运行。当计算节点从 control plane 节点上的 NTP 服务器检索日期和时间时,它会启用未连接到可路由网络的集群的安装和操作,因此无法访问更高的 stratum NTP 服务器。

流程

  1. 使用以下命令在安装主机上安装 Butane:

    $ sudo dnf -y install butane
    Copy to Clipboard Toggle word wrap
  2. 为 control plane 节点创建一个 Butane 配置 99-master-chrony-conf-override.bu,包括 chrony.conf 文件的内容。

    注意

    如需有关 Butane 的信息,请参阅"使用 Butane 创建机器配置"。

    但ane 配置示例

    variant: openshift
    version: 4.19.0
    metadata:
      name: 99-master-chrony-conf-override
      labels:
        machineconfiguration.openshift.io/role: master
    storage:
      files:
        - path: /etc/chrony.conf
          mode: 0644
          overwrite: true
          contents:
            inline: |
              # Use public servers from the pool.ntp.org project.
              # Please consider joining the pool (https://www.pool.ntp.org/join.html).
    
              # The Machine Config Operator manages this file
              server openshift-master-0.<cluster-name>.<domain> iburst 
    1
    
              server openshift-master-1.<cluster-name>.<domain> iburst
              server openshift-master-2.<cluster-name>.<domain> iburst
    
              stratumweight 0
              driftfile /var/lib/chrony/drift
              rtcsync
              makestep 10 3
              bindcmdaddress 127.0.0.1
              bindcmdaddress ::1
              keyfile /etc/chrony.keys
              commandkey 1
              generatecommandkey
              noclientlog
              logchange 0.5
              logdir /var/log/chrony
    
              # Configure the control plane nodes to serve as local NTP servers
              # for all compute nodes, even if they are not in sync with an
              # upstream NTP server.
    
              # Allow NTP client access from the local network.
              allow all
              # Serve time even if not synchronized to a time source.
              local stratum 3 orphan
    Copy to Clipboard Toggle word wrap

    1
    您必须将 <cluster-name> 替换为集群名称,并将 <domain> 替换为完全限定域名。
  3. 使用 Butane 生成 MachineConfig 对象文件 99-master-chrony-conf-override.yaml,其中包含要发送到 control plane 节点的配置:

    $ butane 99-master-chrony-conf-override.bu -o 99-master-chrony-conf-override.yaml
    Copy to Clipboard Toggle word wrap
  4. 为引用 control plane 节点上的 NTP 服务器的计算节点创建 Butane 配置 99-worker-chrony-conf-override.bu,包括 chrony.conf 文件的内容。

    但ane 配置示例

    variant: openshift
    version: 4.19.0
    metadata:
      name: 99-worker-chrony-conf-override
      labels:
        machineconfiguration.openshift.io/role: worker
    storage:
      files:
        - path: /etc/chrony.conf
          mode: 0644
          overwrite: true
          contents:
            inline: |
              # The Machine Config Operator manages this file.
              server openshift-master-0.<cluster-name>.<domain> iburst 
    1
    
              server openshift-master-1.<cluster-name>.<domain> iburst
              server openshift-master-2.<cluster-name>.<domain> iburst
    
              stratumweight 0
              driftfile /var/lib/chrony/drift
              rtcsync
              makestep 10 3
              bindcmdaddress 127.0.0.1
              bindcmdaddress ::1
              keyfile /etc/chrony.keys
              commandkey 1
              generatecommandkey
              noclientlog
              logchange 0.5
              logdir /var/log/chrony
    Copy to Clipboard Toggle word wrap

    1
    您必须将 <cluster-name> 替换为集群名称,并将 <domain> 替换为完全限定域名。
  5. 使用 Butane 生成 MachineConfig 对象文件 99-worker-chrony-conf-override.yaml,其中包含要交付至 worker 节点的配置:

    $ butane 99-worker-chrony-conf-override.bu -o 99-worker-chrony-conf-override.yaml
    Copy to Clipboard Toggle word wrap
  6. 99-master-chrony-conf-override.yaml 策略应用到 control plane 节点。

    $ oc apply -f 99-master-chrony-conf-override.yaml
    Copy to Clipboard Toggle word wrap

    输出示例

    machineconfig.machineconfiguration.openshift.io/99-master-chrony-conf-override created
    Copy to Clipboard Toggle word wrap

  7. 99-worker-chrony-conf-override.yaml 策略应用到计算节点。

    $ oc apply -f 99-worker-chrony-conf-override.yaml
    Copy to Clipboard Toggle word wrap

    输出示例

    machineconfig.machineconfiguration.openshift.io/99-worker-chrony-conf-override created
    Copy to Clipboard Toggle word wrap

  8. 检查应用的 NTP 设置的状态。

    $ oc describe machineconfigpool
    Copy to Clipboard Toggle word wrap

4.3. 安装后启用置备网络

通过为裸机集群提供支持的安装程序和安装程序置备安装,可以在没有 provisioning 网络的情况下部署集群。当每个节点的基板管理控制器可以通过 baremetal 网络 路由时,此功能适用于概念验证集群或仅使用 Redfish 虚拟介质单独部署的情况。

您可在安装后使用 Cluster Baremetal Operator(CBO)启用 置备 网络。

先决条件

  • 必须存在专用物理网络,连接到所有 worker 和 control plane 节点。
  • 您必须隔离原生、未标记的物理网络。
  • provisioningNetwork 配置设置为 Managed 时,网络无法有一个 DHCP 服务器。
  • 您可以省略 OpenShift Container Platform 4.10 中的 provisioningInterface 设置,以使用 bootMACAddress 配置设置。

流程

  1. 设置 provisioningInterface 设置时,首先确定集群节点的调配接口名称。例如: eth0 or eno1
  2. 在集群节点的 调配 网络接口上启用预引导执行环境(PXE)。
  3. 检索 provisioning 网络的当前状态,并将其保存到 provisioning 自定义资源(CR)文件中:

    $ oc get provisioning -o yaml > enable-provisioning-nw.yaml
    Copy to Clipboard Toggle word wrap
  4. 修改 provisioning CR 文件:

    $ vim ~/enable-provisioning-nw.yaml
    Copy to Clipboard Toggle word wrap

    向下滚动到 provisioningNetwork 配置设置,并将它从 Disabled 改为 Managed。然后,在 provisioningNetwork 设置后添加 provisioningIPprovisioningNetworkCIDRprovisioningDHCPRangeprovisioningInterfacewatchAllNameSpaces 配置设置。为每项设置提供适当的值。

    apiVersion: v1
    items:
    - apiVersion: metal3.io/v1alpha1
      kind: Provisioning
      metadata:
        name: provisioning-configuration
      spec:
        provisioningNetwork: 
    1
    
        provisioningIP: 
    2
    
        provisioningNetworkCIDR: 
    3
    
        provisioningDHCPRange: 
    4
    
        provisioningInterface: 
    5
    
        watchAllNameSpaces: 
    6
    Copy to Clipboard Toggle word wrap
    1
    provisioningNetworkManagedUnmanaged 或 Disabled 之一。当设置为 Managed 时,Metal3 管理调配网络,CBO 使用配置的 DHCP 服务器部署 Metal3 pod。当设置为 Unmanaged 时,系统管理员手动配置 DHCP 服务器。
    2
    provisioningIP 是 DHCP 服务器和 ironic 用于调配网络的静态 IP 地址。这个静态 IP 地址必须在 provisioning 子网内,且不在 DHCP 范围内。如果配置这个设置,它必须具有有效的 IP 地址,即使 provisioning 网络是 Disabled。静态 IP 地址绑定到 metal3 pod。如果 metal3 pod 失败并移动到其他服务器,静态 IP 地址也会移到新服务器。
    3
    无类别域间路由(CIDR)地址。如果配置这个设置,它必须具有有效的 CIDR 地址,即使 provisioning 网络是 Disabled。例如:192.168.0.1/24
    4
    DHCP 范围。此设置仅适用于 受管 置备网络。如果 provisioning 网络为 Disabled,则省略此配置设置。例如:192.168.0.64, 192.168.0.253
    5
    集群节点上 置备 接口的 NIC 名称。provisioningInterface 设置仅适用于 受管和非受管 置备 网络。如果 provisioning 网络为 Disabled,忽略 provisioningInterface 配置设置。省略 provisioningInterface 配置设置,以使用 bootMACAddress 配置设置。
    6
    如果您希望 metal3 监视默认 openshift-machine-api 命名空间以外的命名空间,请将此设置设置为 true。默认值为 false
  5. 保存对 provisioning CR 文件的更改。
  6. 将 provisioning CR 文件应用到集群:

    $ oc apply -f enable-provisioning-nw.yaml
    Copy to Clipboard Toggle word wrap

作为使用 configure-ovs.sh shell 脚本在裸机平台上设置 br-ex 网桥的替代选择,您可以创建一个包括 NMState 配置文件的 NodeNetworkConfigurationPolicy (NNCP) 自定义资源(CR)。Kubernetes NMState Operator 使用 NMState 配置文件在集群的每个节点上创建自定义的 br-ex 网桥网络配置。

重要

创建 NodeNetworkConfigurationPolicy CR 后,将在集群安装过程中创建的 NMState 配置文件中的内容复制到 NNCP CR。NNCP CR 文件不完整,表示文件中描述的网络策略无法应用到集群中的节点。

此功能支持以下任务:

  • 修改集群的最大传输单元 (MTU)。
  • 修改不同绑定接口的属性,如 MIImon (媒体独立接口监控器)、绑定模式或服务质量 (QoS)。
  • 更新 DNS 值。

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

  • 您需要对网桥进行安装后更改,如更改 Open vSwitch (OVS) 或 OVN-Kubernetes br-ex 网桥网络。configure-ovs.sh shell 脚本不支持对网桥进行安装后更改。
  • 您希望将网桥部署到与主机或服务器 IP 地址上可用的接口不同的接口上。
  • 您希望通过 configure-ovs.sh shell 脚本对网桥进行高级配置。对这些配置使用脚本可能会导致网桥无法连接多个网络接口,并无法正确处理接口之间的数据转发。
警告

以下接口名称列表被保留,您不能使用带有 NMstate 配置的名称:

  • br-ext
  • br-int
  • br-local
  • br-nexthop
  • br0
  • ext-vxlan
  • ext
  • genev_sys_*
  • int
  • k8s-*
  • ovn-k8s-*
  • patch-br-*
  • tun0
  • vxlan_sys_*

先决条件

  • 您可以使用 configure-ovs 的替代方法来设置一个自定义的 br-ex
  • 已安装 Kubernetes NMState Operator。

流程

  • 创建 NodeNetworkConfigurationPolicy (NNCP) CR,并定义自定义的 br-ex 网桥网络配置。根据您的需要,请确保为 ipv4.address.ipipv6.address.ip 或这两个参数设置了一个伪装 IP。在 NNCP CR 中始终包括伪装 IP 地址,此地址必须与正在使用的 IP 地址块匹配。

    重要

    作为安装后任务,您可以为现有 NNCP CR 中定义的自定义 br-ex 网桥配置大多数参数,但自定义 br-ex 网桥的主要 IP 地址除外。

    如果要将单堆栈集群网络转换为双栈集群网络,您可以在 NNCP CR 中添加或更改辅助 IPv6 地址,但无法更改现有的主 IP 地址。

    设置 IPv6 和 IPv4 伪装 IP 地址的 NNCP CR 示例

    apiVersion: nmstate.io/v1
    kind: NodeNetworkConfigurationPolicy
    metadata:
      name: worker-0-br-ex 
    1
    
    spec:
      nodeSelector:
        kubernetes.io/hostname: worker-0
        desiredState:
        interfaces:
        - name: enp2s0 
    2
    
          type: ethernet 
    3
    
          state: up 
    4
    
          ipv4:
            enabled: false 
    5
    
          ipv6:
            enabled: false
        - name: br-ex
          type: ovs-bridge
          state: up
          ipv4:
            enabled: false
            dhcp: false
          ipv6:
            enabled: false
            dhcp: false
          bridge:
            options:
              mcast-snooping-enable: true
            port:
            - name: enp2s0 
    6
    
            - name: br-ex
        - name: br-ex
          type: ovs-interface
          state: up
          copy-mac-from: enp2s0
          ipv4:
            enabled: true
            dhcp: true
            auto-route-metric: 48 
    7
    
            address:
            - ip: "169.254.169.2"
              prefix-length: 29
          ipv6:
            enabled: true
            dhcp: true
            auto-route-metric: 48
            address:
            - ip: "fd69::2"
            prefix-length: 125
    # ...
    Copy to Clipboard Toggle word wrap

    1
    策略的名称。
    2
    接口的名称。
    3
    以太网的类型。
    4
    创建后接口的请求状态。
    5
    在这个示例中禁用 IPv4 和 IPv6。
    6
    网桥附加到的节点 NIC。
    7
    将参数设置为 48,以确保 br-ex 默认路由始终具有最高的优先级(最低指标)。此配置可防止与 NetworkManager 服务自动配置的任何其他接口冲突。

后续步骤

  • 扩展计算节点,以将包含自定义 br-ex 网桥的 manifest 对象应用到集群中存在的每个计算节点。如需更多信息,请参阅附加资源部分中的"扩展集群"。

4.5. 对自定义 br-ex 网桥进行破坏性更改

在某些情况下,您可能需要对计划的维护或网络配置更新对 br-ex 网桥进行破坏性更改。br-ex 网桥是来自您的工作负载的所有外部网络流量的网关,因此对网桥的任何更改都可能会临时断开与外部网络的 pod 和虚拟机(VM)的连接。

以下流程使用示例来演示对 br-ex 网桥进行破坏性更改,以最大程度降低对运行集群工作负载的任何影响。

对于集群中的所有节点,若要接收 br-ex 网桥的更改,您必须重启集群。编辑现有的 MachineConfig 对象不会强制重启操作,因此您必须创建额外的 MachineConfig 对象来强制对集群进行重启操作。

重要

红帽不支持将节点的 IP 地址作为 postintallation 任务更改。

先决条件

  • 您创建了包含 br-ex 网桥的清单对象。
  • 您已部署了配置了 br-ex 网桥的集群。

流程

  1. 对集群安装期间创建的 NMState 配置文件进行更改,以自定义 br-ex 网桥网络接口。

    重要

    在保存 MachineConfig 对象前,检查更改的参数值。如果您输入了错误的值并保存文件,则无法将文件恢复到其原始状态,这会影响集群的网络功能。

  2. 输入以下命令,使用 base64 命令重新编码 NMState 配置的内容:

    $ base64 -w0 <nmstate_configuration>.yml 
    1
    Copy to Clipboard Toggle word wrap
    1
    <nmstate_configuration> 替换为 NMState 资源 YAML 文件的名称。
  3. 更新您在集群安装过程中创建的 MachineConfig 清单文件,并重新定义自定义的 br-ex 网桥网络接口。
  4. 输入以下命令将 MachineConfig 对象中的更新应用到集群:

    $ oc apply -f <machine_config>.yml
    Copy to Clipboard Toggle word wrap
  5. 创建裸机 MachineConfig 对象,但不对该文件进行任何更改。

    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: master
      name: 10-force-reboot-master
    spec:
      config:
        ignition:
          version: 3.2.0
        storage:
          files:
          - contents:
              source: data:text/plain;charset=utf-8;base64,
            mode: 0644
            overwrite: true
            path: /etc/force-reboot
    ---
    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: worker
      name: 10-force-reboot-worker
    spec:
      config:
        ignition:
          version: 3.2.0
        storage:
          files:
          - contents:
              source: data:text/plain;charset=utf-8;base64,
            mode: 0644
            overwrite: true
            path: /etc/force-reboot
    # ...
    Copy to Clipboard Toggle word wrap
  6. 输入以下命令,将裸机 MachineConfig 对象配置应用到集群来开始重启操作:

    $ oc apply -f <bare_machine_config>.yml
    Copy to Clipboard Toggle word wrap
  7. 输入以下命令检查集群中的每个节点是否具有 Ready 状态,以指示它们是否已重新引导:

    $ oc get nodes
    Copy to Clipboard Toggle word wrap
  8. 输入以下命令删除裸机 MachineConfig 对象:

    $ oc delete machineconfig <machine_config_name>
    Copy to Clipboard Toggle word wrap

验证

  • 运行以下命令,使用 nmstatectl 工具检查 br-ex 网桥接口的配置。该工具检查运行 br-ex 网桥接口的节点,而不是部署 MachineConfig 对象的位置。

    $ sudo nmstatectl show br-ex
    Copy to Clipboard Toggle word wrap

4.6. 用户管理的负载均衡器的服务

您可以将 OpenShift Container Platform 集群配置为使用用户管理的负载均衡器来代替默认负载均衡器。

重要

配置用户管理的负载均衡器取决于您的厂商的负载均衡器。

本节中的信息和示例仅用于指导目的。有关供应商负载均衡器的更多信息,请参阅供应商文档。

红帽支持用户管理的负载均衡器的以下服务:

  • Ingress Controller
  • OpenShift API
  • OpenShift MachineConfig API

您可以选择是否要为用户管理的负载均衡器配置一个或多个所有服务。仅配置 Ingress Controller 服务是一个通用的配置选项。要更好地了解每个服务,请查看以下图表:

图 4.1. 显示 OpenShift Container Platform 环境中运行的 Ingress Controller 的网络工作流示例

图 4.2. 显示 OpenShift Container Platform 环境中运行的 OpenShift API 的网络工作流示例

图 4.3. 显示 OpenShift Container Platform 环境中运行的 OpenShift MachineConfig API 的网络工作流示例

用户管理的负载均衡器支持以下配置选项:

  • 使用节点选择器将 Ingress Controller 映射到一组特定的节点。您必须为这个集合中的每个节点分配一个静态 IP 地址,或者将每个节点配置为从动态主机配置协议(DHCP)接收相同的 IP 地址。基础架构节点通常接收这种类型的配置。
  • 以子网上的所有 IP 地址为目标。此配置可减少维护开销,因为您可以在这些网络中创建和销毁节点,而无需重新配置负载均衡器目标。如果您使用较小的网络上的机器集来部署入口 pod,如 /27/28,您可以简化负载均衡器目标。

    提示

    您可以通过检查机器配置池的资源来列出网络中存在的所有 IP 地址。

在为 OpenShift Container Platform 集群配置用户管理的负载均衡器前,请考虑以下信息:

  • 对于前端 IP 地址,您可以对前端 IP 地址、Ingress Controller 的负载均衡器和 API 负载均衡器使用相同的 IP 地址。查看厂商的文档以获取此功能的相关信息。
  • 对于后端 IP 地址,请确保 OpenShift Container Platform control plane 节点的 IP 地址在用户管理的负载均衡器生命周期内不会改变。您可以通过完成以下操作之一来实现此目的:

    • 为每个 control plane 节点分配一个静态 IP 地址。
    • 将每个节点配置为在每次节点请求 DHCP 租期时从 DHCP 接收相同的 IP 地址。根据供应商,DHCP 租期可能采用 IP 保留或静态 DHCP 分配的形式。
  • 在 Ingress Controller 后端服务的用户管理的负载均衡器中手动定义运行 Ingress Controller 的每个节点。例如,如果 Ingress Controller 移到未定义节点,则可能会出现连接中断。

4.6.1. 配置用户管理的负载均衡器

您可以将 OpenShift Container Platform 集群配置为使用用户管理的负载均衡器来代替默认负载均衡器。

重要

在配置用户管理的负载均衡器前,请确保阅读用户管理的负载均衡器部分。

阅读适用于您要为用户管理的负载均衡器配置的服务的以下先决条件。

注意

MetalLB,在集群中运行,充当用户管理的负载均衡器。

OpenShift API 的先决条件

  • 您定义了前端 IP 地址。
  • TCP 端口 6443 和 22623 在负载均衡器的前端 IP 地址上公开。检查以下项:

    • 端口 6443 提供对 OpenShift API 服务的访问。
    • 端口 22623 可以为节点提供 ignition 启动配置。
  • 前端 IP 地址和端口 6443 可以被您的系统的所有用户访问,其位置为 OpenShift Container Platform 集群外部。
  • 前端 IP 地址和端口 22623 只能被 OpenShift Container Platform 节点访问。
  • 负载均衡器后端可以在端口 6443 和 22623 上与 OpenShift Container Platform control plane 节点通信。

Ingress Controller 的先决条件

  • 您定义了前端 IP 地址。
  • TCP 端口 443 和 80 在负载均衡器的前端 IP 地址上公开。
  • 前端 IP 地址、端口 80 和端口 443 可以被您的系统所有用户访问,以及 OpenShift Container Platform 集群外部的位置。
  • 前端 IP 地址、端口 80 和端口 443 可被 OpenShift Container Platform 集群中运行的所有节点访问。
  • 负载均衡器后端可以在端口 80、443 和 1936 上与运行 Ingress Controller 的 OpenShift Container Platform 节点通信。

健康检查 URL 规格的先决条件

您可以通过设置健康检查 URL 来配置大多数负载均衡器,以确定服务是否可用或不可用。OpenShift Container Platform 为 OpenShift API、Machine Configuration API 和 Ingress Controller 后端服务提供这些健康检查。

以下示例显示了之前列出的后端服务的健康检查规格:

Kubernetes API 健康检查规格示例

Path: HTTPS:6443/readyz
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 10
Interval: 10
Copy to Clipboard Toggle word wrap

Machine Config API 健康检查规格示例

Path: HTTPS:22623/healthz
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 10
Interval: 10
Copy to Clipboard Toggle word wrap

Ingress Controller 健康检查规格示例

Path: HTTP:1936/healthz/ready
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 5
Interval: 10
Copy to Clipboard Toggle word wrap

流程

  1. 配置 HAProxy Ingress Controller,以便您可以在端口 6443、22623、443 和 80 上从负载均衡器访问集群。根据您的需要,您可以在 HAProxy 配置中指定来自多个子网的单个子网或 IP 地址的 IP 地址。

    带有列出子网的 HAProxy 配置示例

    # ...
    listen my-cluster-api-6443
        bind 192.168.1.100:6443
        mode tcp
        balance roundrobin
      option httpchk
      http-check connect
      http-check send meth GET uri /readyz
      http-check expect status 200
        server my-cluster-master-2 192.168.1.101:6443 check inter 10s rise 2 fall 2
        server my-cluster-master-0 192.168.1.102:6443 check inter 10s rise 2 fall 2
        server my-cluster-master-1 192.168.1.103:6443 check inter 10s rise 2 fall 2
    
    listen my-cluster-machine-config-api-22623
        bind 192.168.1.100:22623
        mode tcp
        balance roundrobin
      option httpchk
      http-check connect
      http-check send meth GET uri /healthz
      http-check expect status 200
        server my-cluster-master-2 192.168.1.101:22623 check inter 10s rise 2 fall 2
        server my-cluster-master-0 192.168.1.102:22623 check inter 10s rise 2 fall 2
        server my-cluster-master-1 192.168.1.103:22623 check inter 10s rise 2 fall 2
    
    listen my-cluster-apps-443
        bind 192.168.1.100:443
        mode tcp
        balance roundrobin
      option httpchk
      http-check connect
      http-check send meth GET uri /healthz/ready
      http-check expect status 200
        server my-cluster-worker-0 192.168.1.111:443 check port 1936 inter 10s rise 2 fall 2
        server my-cluster-worker-1 192.168.1.112:443 check port 1936 inter 10s rise 2 fall 2
        server my-cluster-worker-2 192.168.1.113:443 check port 1936 inter 10s rise 2 fall 2
    
    listen my-cluster-apps-80
       bind 192.168.1.100:80
       mode tcp
       balance roundrobin
      option httpchk
      http-check connect
      http-check send meth GET uri /healthz/ready
      http-check expect status 200
        server my-cluster-worker-0 192.168.1.111:80 check port 1936 inter 10s rise 2 fall 2
        server my-cluster-worker-1 192.168.1.112:80 check port 1936 inter 10s rise 2 fall 2
        server my-cluster-worker-2 192.168.1.113:80 check port 1936 inter 10s rise 2 fall 2
    # ...
    Copy to Clipboard Toggle word wrap

    带有多个列出子网的 HAProxy 配置示例

    # ...
    listen api-server-6443
        bind *:6443
        mode tcp
          server master-00 192.168.83.89:6443 check inter 1s
          server master-01 192.168.84.90:6443 check inter 1s
          server master-02 192.168.85.99:6443 check inter 1s
          server bootstrap 192.168.80.89:6443 check inter 1s
    
    listen machine-config-server-22623
        bind *:22623
        mode tcp
          server master-00 192.168.83.89:22623 check inter 1s
          server master-01 192.168.84.90:22623 check inter 1s
          server master-02 192.168.85.99:22623 check inter 1s
          server bootstrap 192.168.80.89:22623 check inter 1s
    
    listen ingress-router-80
        bind *:80
        mode tcp
        balance source
          server worker-00 192.168.83.100:80 check inter 1s
          server worker-01 192.168.83.101:80 check inter 1s
    
    listen ingress-router-443
        bind *:443
        mode tcp
        balance source
          server worker-00 192.168.83.100:443 check inter 1s
          server worker-01 192.168.83.101:443 check inter 1s
    
    listen ironic-api-6385
        bind *:6385
        mode tcp
        balance source
          server master-00 192.168.83.89:6385 check inter 1s
          server master-01 192.168.84.90:6385 check inter 1s
          server master-02 192.168.85.99:6385 check inter 1s
          server bootstrap 192.168.80.89:6385 check inter 1s
    
    listen inspector-api-5050
        bind *:5050
        mode tcp
        balance source
          server master-00 192.168.83.89:5050 check inter 1s
          server master-01 192.168.84.90:5050 check inter 1s
          server master-02 192.168.85.99:5050 check inter 1s
          server bootstrap 192.168.80.89:5050 check inter 1s
    # ...
    Copy to Clipboard Toggle word wrap

  2. 使用 curl CLI 命令验证用户管理的负载均衡器及其资源是否正常运行:

    1. 运行以下命令并查看响应,验证集群机器配置 API 是否可以被 Kubernetes API 服务器资源访问:

      $ curl https://<loadbalancer_ip_address>:6443/version --insecure
      Copy to Clipboard Toggle word wrap

      如果配置正确,您会收到 JSON 对象的响应:

      {
        "major": "1",
        "minor": "11+",
        "gitVersion": "v1.11.0+ad103ed",
        "gitCommit": "ad103ed",
        "gitTreeState": "clean",
        "buildDate": "2019-01-09T06:44:10Z",
        "goVersion": "go1.10.3",
        "compiler": "gc",
        "platform": "linux/amd64"
      }
      Copy to Clipboard Toggle word wrap
    2. 运行以下命令并观察输出,验证集群机器配置 API 是否可以被 Machine 配置服务器资源访问:

      $ curl -v https://<loadbalancer_ip_address>:22623/healthz --insecure
      Copy to Clipboard Toggle word wrap

      如果配置正确,命令的输出会显示以下响应:

      HTTP/1.1 200 OK
      Content-Length: 0
      Copy to Clipboard Toggle word wrap
    3. 运行以下命令并观察输出,验证控制器是否可以被端口 80 上的 Ingress Controller 资源访问:

      $ curl -I -L -H "Host: console-openshift-console.apps.<cluster_name>.<base_domain>" http://<load_balancer_front_end_IP_address>
      Copy to Clipboard Toggle word wrap

      如果配置正确,命令的输出会显示以下响应:

      HTTP/1.1 302 Found
      content-length: 0
      location: https://console-openshift-console.apps.ocp4.private.opequon.net/
      cache-control: no-cache
      Copy to Clipboard Toggle word wrap
    4. 运行以下命令并观察输出,验证控制器是否可以被端口 443 上的 Ingress Controller 资源访问:

      $ curl -I -L --insecure --resolve console-openshift-console.apps.<cluster_name>.<base_domain>:443:<Load Balancer Front End IP Address> https://console-openshift-console.apps.<cluster_name>.<base_domain>
      Copy to Clipboard Toggle word wrap

      如果配置正确,命令的输出会显示以下响应:

      HTTP/1.1 200 OK
      referrer-policy: strict-origin-when-cross-origin
      set-cookie: csrf-token=UlYWOyQ62LWjw2h003xtYSKlh1a0Py2hhctw0WmV2YEdhJjFyQwWcGBsja261dGLgaYO0nxzVErhiXt6QepA7g==; Path=/; Secure; SameSite=Lax
      x-content-type-options: nosniff
      x-dns-prefetch-control: off
      x-frame-options: DENY
      x-xss-protection: 1; mode=block
      date: Wed, 04 Oct 2023 16:29:38 GMT
      content-type: text/html; charset=utf-8
      set-cookie: 1e2670d92730b515ce3a1bb65da45062=1bf5e9573c9a2760c964ed1659cc1673; path=/; HttpOnly; Secure; SameSite=None
      cache-control: private
      Copy to Clipboard Toggle word wrap
  3. 配置集群的 DNS 记录,使其以用户管理的负载均衡器的前端 IP 地址为目标。您必须在负载均衡器上将记录更新为集群 API 和应用程序的 DNS 服务器。

    修改 DNS 记录示例

    <load_balancer_ip_address>  A  api.<cluster_name>.<base_domain>
    A record pointing to Load Balancer Front End
    Copy to Clipboard Toggle word wrap

    <load_balancer_ip_address>   A apps.<cluster_name>.<base_domain>
    A record pointing to Load Balancer Front End
    Copy to Clipboard Toggle word wrap
    重要

    DNS 传播可能需要一些时间才能获得每个 DNS 记录。在验证每个记录前,请确保每个 DNS 记录传播。

  4. 要使 OpenShift Container Platform 集群使用用户管理的负载均衡器,您必须在集群的 install-config.yaml 文件中指定以下配置:

    # ...
    platform:
        loadBalancer:
          type: UserManaged 
    1
    
        apiVIPs:
        - <api_ip> 
    2
    
        ingressVIPs:
        - <ingress_ip> 
    3
    
    # ...
    Copy to Clipboard Toggle word wrap
    1
    type 参数设置 UserManaged,为集群指定用户管理的负载均衡器。参数默认为 OpenShiftManagedDefault,它表示默认的内部负载均衡器。对于 openshift-kni-infra 命名空间中定义的服务,用户管理的负载均衡器可将 coredns 服务部署到集群中的 pod,但忽略 keepalivedhaproxy 服务。
    2
    指定用户管理的负载均衡器时所需的参数。指定用户管理的负载均衡器的公共 IP 地址,以便 Kubernetes API 可以与用户管理的负载均衡器通信。
    3
    指定用户管理的负载均衡器时所需的参数。指定用户管理的负载均衡器的公共 IP 地址,以便用户管理的负载均衡器可以管理集群的入口流量。

验证

  1. 使用 curl CLI 命令验证用户管理的负载均衡器和 DNS 记录配置是否正常工作:

    1. 运行以下命令并查看输出,验证您可以访问集群 API:

      $ curl https://api.<cluster_name>.<base_domain>:6443/version --insecure
      Copy to Clipboard Toggle word wrap

      如果配置正确,您会收到 JSON 对象的响应:

      {
        "major": "1",
        "minor": "11+",
        "gitVersion": "v1.11.0+ad103ed",
        "gitCommit": "ad103ed",
        "gitTreeState": "clean",
        "buildDate": "2019-01-09T06:44:10Z",
        "goVersion": "go1.10.3",
        "compiler": "gc",
        "platform": "linux/amd64"
        }
      Copy to Clipboard Toggle word wrap
    2. 运行以下命令并查看输出,验证您可以访问集群机器配置:

      $ curl -v https://api.<cluster_name>.<base_domain>:22623/healthz --insecure
      Copy to Clipboard Toggle word wrap

      如果配置正确,命令的输出会显示以下响应:

      HTTP/1.1 200 OK
      Content-Length: 0
      Copy to Clipboard Toggle word wrap
    3. 运行以下命令并查看输出,验证您可以在端口上访问每个集群应用程序:

      $ curl http://console-openshift-console.apps.<cluster_name>.<base_domain> -I -L --insecure
      Copy to Clipboard Toggle word wrap

      如果配置正确,命令的输出会显示以下响应:

      HTTP/1.1 302 Found
      content-length: 0
      location: https://console-openshift-console.apps.<cluster-name>.<base domain>/
      cache-control: no-cacheHTTP/1.1 200 OK
      referrer-policy: strict-origin-when-cross-origin
      set-cookie: csrf-token=39HoZgztDnzjJkq/JuLJMeoKNXlfiVv2YgZc09c3TBOBU4NI6kDXaJH1LdicNhN1UsQWzon4Dor9GWGfopaTEQ==; Path=/; Secure
      x-content-type-options: nosniff
      x-dns-prefetch-control: off
      x-frame-options: DENY
      x-xss-protection: 1; mode=block
      date: Tue, 17 Nov 2020 08:42:10 GMT
      content-type: text/html; charset=utf-8
      set-cookie: 1e2670d92730b515ce3a1bb65da45062=9b714eb87e93cf34853e87a92d6894be; path=/; HttpOnly; Secure; SameSite=None
      cache-control: private
      Copy to Clipboard Toggle word wrap
    4. 运行以下命令并查看输出,验证您可以在端口 443 上访问每个集群应用程序:

      $ curl https://console-openshift-console.apps.<cluster_name>.<base_domain> -I -L --insecure
      Copy to Clipboard Toggle word wrap

      如果配置正确,命令的输出会显示以下响应:

      HTTP/1.1 200 OK
      referrer-policy: strict-origin-when-cross-origin
      set-cookie: csrf-token=UlYWOyQ62LWjw2h003xtYSKlh1a0Py2hhctw0WmV2YEdhJjFyQwWcGBsja261dGLgaYO0nxzVErhiXt6QepA7g==; Path=/; Secure; SameSite=Lax
      x-content-type-options: nosniff
      x-dns-prefetch-control: off
      x-frame-options: DENY
      x-xss-protection: 1; mode=block
      date: Wed, 04 Oct 2023 16:29:38 GMT
      content-type: text/html; charset=utf-8
      set-cookie: 1e2670d92730b515ce3a1bb65da45062=1bf5e9573c9a2760c964ed1659cc1673; path=/; HttpOnly; Secure; SameSite=None
      cache-control: private
      Copy to Clipboard Toggle word wrap

4.7. 使用 Bare Metal Operator 配置

在裸机主机上部署 OpenShift Container Platform 时,在置备前或置备后,有时您需要对主机进行更改。这包括检查主机的硬件、固件和固件详情。它还可以包含格式化磁盘或更改可修改的固件设置。

您可以使用 Bare Metal Operator (BMO) 来置备、管理和检查集群中的裸机主机。BMO 可以完成以下操作:

  • 使用特定镜像置备裸机主机到集群。
  • 打开或关闭主机。
  • 检查主机的硬件详情,并将它们报告到裸机主机。
  • 将主机的固件升级或降级到特定版本。
  • 检查固件并配置 BIOS 设置。
  • 在置备主机之前或之后清理主机的磁盘内容。

BMO 使用以下资源来完成这些任务:

  • BareMetalHost
  • HostFirmwareSettings
  • FirmwareSchema
  • HostFirmwareComponents
  • HostUpdatePolicy

BMO 通过将每个裸机主机映射到 BareMetalHost 自定义资源定义的实例来维护集群中的物理主机清单。每个 BareMetalHost 资源都有硬件、软件和固件详情。BMO 持续检查集群中的裸机主机,以确保每个 BareMetalHost 资源准确详细说明相应主机的组件。

BMO 还使用 HostFirmwareSettings 资源、FirmwareSchema 资源和 HostFirmwareComponents 资源来详细说明固件规格,以及为裸机主机升级或降级固件。

使用 Ironic API 服务在集群中的裸机主机的 BMO 接口。Ironic 服务使用主机上的 Baseboard Management Controller (BMC) 来与机器进行接口。

BMO HostUpdatePolicy 可以在置备主机后启用或禁用对裸机主机的固件设置、BMC 设置或 BIOS 设置的实时更新。默认情况下,BMO 禁用实时更新。

4.7.1. 裸机 Operator 架构

Bare Metal Operator (BMO) 使用以下资源来置备、管理和检查集群中的裸机主机。下图演示了这些资源的架构:

BareMetalHost

BareMetalHost 资源定义物理主机及其属性。将裸机主机置备到集群时,您必须为该主机定义 BareMetalHost 资源。对于主机的持续管理,您可以检查 BareMetalHost 资源中的信息或更新此信息。

BareMetalHost 资源具有置备信息,如下所示:

  • 部署规格,如操作系统引导镜像或自定义 RAM 磁盘
  • 置备状态
  • 基板管理控制器 (BMC) 地址
  • 所需的电源状态

BareMetalHost 资源具有硬件信息,如下所示:

  • CPU 数量
  • NIC 的 MAC 地址
  • 主机的存储设备的大小
  • 当前电源状态

HostFirmwareSettings

您可以使用 HostFirmwareSettings 资源来检索和管理主机的固件设置。当主机进入 Available 状态时,Ironic 服务读取主机的固件设置并创建 HostFirmwareSettings 资源。BareMetalHost 资源和 HostFirmwareSettings 资源之间存在一对一映射。

您可以使用 HostFirmwareSettings 资源来检查主机的固件规格,或更新主机的固件规格。

注意

在编辑 HostFirmwareSettings 资源的 spec 字段时,您必须遵循特定于供应商固件的 schema。这个模式在只读 FirmwareSchema 资源中定义。

FirmwareSchema

固件设置因硬件供应商和主机模型而异。FirmwareSchema 资源是一个只读资源,其中包含每个主机模型中每个固件设置的类型和限制。数据通过使用 Ironic 服务直接从 BMC 传递。您可以使用 FirmwareSchema 资源来识别 HostFirmwareSettings 资源的 spec 字段中可以指定的有效值。

如果 schema 相同,则 FirmwareSchema 资源可应用到许多 BareMetalHost 资源。

HostFirmwareComponents

Metal3 提供了 HostFirmwareComponents 资源,它描述了 BIOS 和基板管理控制器 (BMC) 固件版本。您可以通过编辑 HostFirmwareComponents 资源的 spec 字段,将主机的固件升级到一个特定版本。这在使用针对特定固件版本测试的验证模式部署时很有用。

HostUpdatePolicy

HostUpdatePolicy 资源可以启用或禁用裸机主机固件设置、BMC 设置或 BIOS 设置的实时更新。默认情况下,每个裸机主机的 HostUpdatePolicy 资源会限制在置备过程中对主机的更新。当您要在置备主机后更新固件设置、BMC 设置或 BIOS 设置时,您必须修改主机的 HostUpdatePolicy 资源。

4.7.2. 关于 BareMetalHost 资源

裸机3 引入了 BareMetalHost 资源的概念,它定义了物理主机及其属性。BareMetalHost 资源包含两个部分:

  1. BareMetalHost 规格
  2. BareMetalHost 状态
4.7.2.1. BareMetalHost 规格

BareMetalHost 资源的 spec 部分定义了主机所需状态。

Expand
表 4.1. BareMetalHost spec
参数描述

automatedCleaningMode

在置备和取消置备过程中启用或禁用自动清理的接口。当设置为 disabled 时,它将跳过自动清理。当设置为 metadata 时,会自动清理会被启用。默认设置为 metadata

bmc:
  address:
  credentialsName:
  disableCertificateVerification:
Copy to Clipboard Toggle word wrap

bmc 配置设置包含主机上基板管理控制器(BMC)的连接信息。这些字段包括:

  • address :与主机的 BMC 控制器通信的 URL。
  • credentialsName :引用包含 BMC 的用户名和密码的 secret。
  • disableCertificateVerification :当设置为 true 时跳过证书验证的布尔值。

bootMACAddress

用于置备主机的 NIC 的 MAC 地址。

bootMode

主机的引导模式。它默认为 UEFI,但也可以设置为 legacy 用于 BIOS 引导,或 UEFISecureBoot

consumerRef

对使用主机的另一个资源的引用。如果另一个资源目前没有使用主机,则它可能为空。例如,当 machine-api 使用主机时,Machine 资源可能会使用主机。

description

提供的字符串,用于帮助识别主机。

externallyProvisioned

指明主机置备和取消置备是在外部管理的布尔值。当设置时:

  • 仍可使用在线字段管理电源状态。
  • 将监控硬件清单,但不会在主机上执行置备或取消置备操作。

firmware

包含有关裸机主机的 BIOS 配置的信息。目前,只有 iRMC、S iDRAC、i iLO4 和 iLO5 BMC 支持 firmware。子字段有:

  • simultaneousMultithreadingEnabled:允许单个物理处理器内核显示为多个逻辑处理器。有效设置为 truefalse
  • sriovEnabled: SR-IOV 支持可让虚拟机监控程序创建 PCI-express 设备的虚拟实例,这可能会提高性能。有效设置为 truefalse
  • virtualizationEnabled:支持平台硬件的虚拟化。有效设置为 truefalse
image:
  url:
  checksum:
  checksumType:
  format:
Copy to Clipboard Toggle word wrap

image 配置设置包含要部署到主机上的镜像的详细信息。Ironic 需要镜像字段。但是,当 externallyProvisioned 配置设置被设置为 true,且外部管理不需要电源控制时,字段可以为空。此设置支持以下字段:

  • url:部署到主机的镜像的 URL。
  • checksum :位于 image.url 的镜像的实际校验和值,或包括镜像的校验和的文件 URL。
  • checksumType :指定 checksum 算法。目前,Image.checksumType 只支持 md5sha256sha512。默认 checksum 类型为 md5
  • format :镜像的磁盘格式。它可以是 raw, qcow2, vdi, vmdk, live-iso 或不设置。把它设置为 raw 可为该镜像在 Ironic 代理中进行原始镜像流处理。将它设置为 live-iso 会启用 iso 镜像在没有部署到磁盘的情况下进行实时引导,它会忽略 checksum 字段。

networkData

对包含网络配置数据及其命名空间的 secret 的引用,以便在主机引导以设置网络前将其附加到主机。

online

指示主机是否应开启的布尔值,true 代表开启,false 代表关闭。更改此值将触发对物理主机的电源状态变化。

raid:
  hardwareRAIDVolumes:
  softwareRAIDVolumes:
Copy to Clipboard Toggle word wrap

(可选)包含有关裸机主机的 RAID 配置的信息。如果没有指定,它会保留当前的配置。

注意

OpenShift Container Platform 4.19 支持 BMC 的安装驱动器中的硬件 RAID,包括:

  • Fujitsu iRMC 支持 RAID 0、1、5、6 和 10
  • Dell iDRAC 使用带有固件版本 6.10.30.20 或更高版本和 RAID 级别 0、1 和 5 的 Redfish API

OpenShift Container Platform 4.19 不支持安装驱动器中的软件 RAID。

请参见以下配置设置:

  • hardwareRAIDVolumes :包含硬件 RAID 的逻辑驱动器列表,并在硬件 RAID 中定义所需的卷配置。如果没有指定 rootDeviceHints,则第一个卷是 root 卷。子字段是:

    • level :逻辑驱动器的 RAID 级别。支持以下级别:0,1,2,5,6,1+0,5+0,6+0.
    • name :卷名称(字符串)。它在服务器中应该是唯一的。如果未指定,则自动生成卷名称。
    • numberOfPhysicalDisks :物理驱动器的数量,作为用于逻辑 drove 的整数。默认为特定 RAID 级别所需的最小磁盘驱动器数。
    • physicalDisks :物理磁盘驱动器的名称列表作为字符串。这是可选字段。如果指定,还必须指定 controller 字段。
    • controller :(可选)RAID 控制器的名称作为要在硬件 RAID 卷中使用的字符串。
    • rotational :如果设为 true,则它只会选择轮转磁盘驱动器。如果设置为 false,它将只选择固态和 NVMe 驱动器。如果没有设置,则会选择任何驱动器类型,这是默认行为。
    • sizeGibibytes :逻辑驱动器的大小作为在 GiB 中创建的整数。如果未指定或设置为 0,它将为逻辑驱动器使用物理驱动器的最大容量。
  • softwareRAIDVolumes: OpenShift Container Platform 4.19 不支持安装驱动器中的软件 RAID。这个配置包含软件 RAID 的逻辑磁盘列表。如果没有指定 rootDeviceHints,则第一个卷是 root 卷。如果您设置了 HardwareRAIDVolumes,则此项将无效。软件 RAID 总是被删除。创建的软件 RAID 设备的数量必须是 12。如果只有一个软件 RAID 设备,它必须是 RAID-1。如果有两个 RAID 设备,则第一个设备必须是 RAID-1,而第二个设备的 RAID 级别可以为 0, 1, 或 1+0。第一个 RAID 设备将是部署设备,该设备不能是软件 RAID 卷。强制 RAID-1 在设备失败时降低非引导节点的风险。softwareRAIDVolume 字段定义软件 RAID 中卷所需的配置。子字段是:

    • level :逻辑驱动器的 RAID 级别。支持以下级别:0,1,1+0
    • physicalDisks :设备提示列表.项目数量应大于或等于 2
    • sizeGibibytes :逻辑磁盘驱动器的大小作为整数,以 GiB 为单位创建。如果未指定或设置为 0,它将为逻辑驱动器使用物理驱动器的最大容量。

您可以将 hardwareRAIDVolume 设置为空片段,以清除硬件 RAID 配置。例如:

spec:
   raid:
     hardwareRAIDVolume: []
Copy to Clipboard Toggle word wrap

如果您收到出错信息表示驱动程序不支持 RAID,则将 raid, hardwareRAIDVolumessoftwareRAIDVolumes 设置为 nil。您可能需要确保主机具有 RAID 控制器。

rootDeviceHints:
  deviceName:
  hctl:
  model:
  vendor:
  serialNumber:
  minSizeGigabytes:
  wwn:
  wwnWithExtension:
  wwnVendorExtension:
  rotational:
Copy to Clipboard Toggle word wrap

rootDeviceHints 参数启用将 RHCOS 镜像置备到特定设备。它会按照发现设备的顺序检查设备,并将发现的值与 hint 值进行比较。它使用第一个与 hint 值匹配的发现设备。该配置可组合多个 hints,但设备必须与所有提示都匹配才能被选择。这些字段包括:

  • deviceName:包含类似 /dev/vda 的 Linux 设备名称的字符串。hint 必须与实际值完全匹配。
  • hctl :包含类似 0:0:0:0 的 SCSI 总线地址的字符串。hint 必须与实际值完全匹配。
  • model :包含特定厂商的设备标识符的字符串。hint 可以是实际值的子字符串。
  • vendor :包含该设备厂商或制造商名称的字符串。hint 可以是实际值的子字符串。
  • serialNumber :包含设备序列号的字符串。hint 必须与实际值完全匹配。
  • minSizeGigabytes :一个整数,代表设备的最小大小(以 GB 为单位)。
  • wwn :包含唯一存储标识符的字符串。hint 必须与实际值完全匹配。
  • wwnWithExtension :包含附加厂商扩展的唯一存储标识符的字符串。hint 必须与实际值完全匹配。
  • wwnVendorExtension :包含唯一厂商存储标识符的字符串。hint 必须与实际值完全匹配。
  • rotational :指示该设备应该是旋转磁盘(true)还是非旋转磁盘(false)的布尔值。
4.7.2.2. BareMetalHost 状态

BareMetalHost 状态代表主机的当前状态,包括经过测试的凭证、当前的硬件详情和其他信息。

Expand
表 4.2. BareMetalHost 状态
参数描述

goodCredentials

对 secret 及其命名空间的引用,其中包含最近一组基板管理控制器(BMC)凭证,以便系统能够验证。

errorMessage

置备后端的最后一个错误的详情(若有)。

errorType

表示导致主机进入错误状态的问题类别。错误类型包括:

  • provisioned registration error:当控制器无法重新注册已置备的主机时发生。
  • registration error :当控制器无法连接到主机的基板管理控制器时,请注意。
  • inspection error :尝试从主机获取硬件详细信息时发生错误。
  • preparation error :在清理失败时生成。
  • provisioning error :当控制器无法置备或取消置备主机时会发生。
  • power management error :当控制器无法修改主机的电源状态时会发生。
  • detach error: 当控制器无法从置备程序卸载主机时会发生。
hardware:
  cpu
    arch:
    model:
    clockMegahertz:
    flags:
    count:
Copy to Clipboard Toggle word wrap

系统中的 CPU 的 hardware.cpu 字段详情。这些字段包括:

  • arch :CPU 的架构。
  • model: CPU 系列(字符串)
  • clockMegahertz :CPU 的速度(MHz)。
  • flags: CPU 标记列表。例如,'mmx','sse','sse2','vmx' 等。
  • count: 系统中可用的 CPU 数量。
hardware:
  firmware:
Copy to Clipboard Toggle word wrap

包含 BIOS 固件信息。例如,硬件供应商和版本。

hardware:
  nics:
  - ip:
    name:
    mac:
    speedGbps:
    vlans:
    vlanId:
    pxe:
Copy to Clipboard Toggle word wrap

hardware.nics 字段包含主机的网络接口列表。这些字段包括:

  • ip:NIC 的 IP 地址,如果在发现代理运行时是否被分配。
  • name: 标识网络设备的字符串。例如,nic-1
  • mac: NIC 的 MAC 地址。
  • speedGbps: 设备的速度(Gbps)。
  • vlans: 保存此 NIC 可用的所有 VLAN 的列表。
  • vlanId :未标记的 VLAN ID。
  • pxe: NIC 是否能够使用 PXE 引导。
hardware:
  ramMebibytes:
Copy to Clipboard Toggle word wrap

主机的内存量(兆字节(MiB))。

hardware:
  storage:
  - name:
    rotational:
    sizeBytes:
    serialNumber:
Copy to Clipboard Toggle word wrap

hardware.storage 字段包含可用于主机的存储设备列表。这些字段包括:

  • name: 标识存储设备的字符串。例如,disk 1 (boot).
  • rotational :指示磁盘是否为轮转的,返回 truefalse
  • sizeBytes :存储设备的大小。
  • serialNumber :设备的序列号。
hardware:
  systemVendor:
    manufacturer:
    productName:
    serialNumber:
Copy to Clipboard Toggle word wrap

包含主机的 manufacturer, productName, 和 serialNumber 的信息。

lastUpdated

主机状态最后一次更新的时间戳。

operationalStatus

服务器的状态。状态为以下之一:

  • OK :指示主机的所有详细信息均为已知、正确配置、正常工作和可以管理。
  • discovered: 指定某些主机的详细信息无法正常工作或缺失。例如,BMC 地址已知,但登录凭证未知。
  • error: 指示系统发现某种不可恢复的错误。如需更多详细信息,请参阅 status 部分中的 errorMessage 字段。
  • delayed:指示置备延迟来限制同时置备多个主机。
  • detached: 指示主机被标记为 unmanaged

poweredOn

指明主机是否开机的布尔值。

provisioning:
  state:
  id:
  image:
  raid:
  firmware:
  rootDeviceHints:
Copy to Clipboard Toggle word wrap

provisioning 字段包含与主机部署镜像相关的值。子字段包括:

  • state: 任何持续置备操作的当前状态。状态包括:

    • <empty string>: 目前没有进行置备。
    • unmanaged: 没有足够的信息来注册主机。
    • registering: 用来检查主机的 BMC 详情的代理
    • match profile :代理将主机上发现的硬件详情与已知的配置集进行比较。
    • available: 主机可用于置备。这个状态之前被称为 ready
    • preparing :现有配置将被删除,新的配置将在主机上设置。
    • provisioning :置备程序正在将镜像写入主机的存储。
    • provisioned: 置备程序已将镜像写入主机的存储。
    • externally provisioned: Metal3 不管理主机上的镜像。
    • deprovisioning: 置备程序正在从主机的存储中清除镜像。
    • inspecting: 代理正在收集主机的硬件详情。
    • deleting: 代理正在从集群中删除。
  • id: 底层调配工具中服务的唯一标识符。
  • Image :最近部署到主机的镜像。
  • raid: 最近设定的硬件或软件 RAID 卷列表。
  • firmware: 裸机服务器的 BIOS 配置。
  • rootDeviceHints :用于最新置备操作的根设备选择说明。

triedCredentials

对 secret 及其命名空间的引用,其中包含发送到置备后端的最后一个 BMC 凭证集合。

4.7.3. 获取 BareMetalHost 资源

BareMetalHost 资源包含物理主机的属性。您必须获取物理主机的 BareMetalHost 资源才能查看其属性。

流程

  1. 获取 BareMetalHost 资源列表:

    $ oc get bmh -n openshift-machine-api -o yaml
    Copy to Clipboard Toggle word wrap
    注意

    您可以使用 baremetalhost 作为 oc get 命令的 bmh 长形式。

  2. 获取主机列表:

    $ oc get bmh -n openshift-machine-api
    Copy to Clipboard Toggle word wrap
  3. 获取特定主机的 BareMetalHost 资源:

    $ oc get bmh <host_name> -n openshift-machine-api -o yaml
    Copy to Clipboard Toggle word wrap

    其中 <host_name> 是主机的名称。

    输出示例

    apiVersion: metal3.io/v1alpha1
    kind: BareMetalHost
    metadata:
      creationTimestamp: "2022-06-16T10:48:33Z"
      finalizers:
      - baremetalhost.metal3.io
      generation: 2
      name: openshift-worker-0
      namespace: openshift-machine-api
      resourceVersion: "30099"
      uid: 1513ae9b-e092-409d-be1b-ad08edeb1271
    spec:
      automatedCleaningMode: metadata
      bmc:
        address: redfish://10.46.61.19:443/redfish/v1/Systems/1
        credentialsName: openshift-worker-0-bmc-secret
        disableCertificateVerification: true
      bootMACAddress: 48:df:37:c7:f7:b0
      bootMode: UEFI
      consumerRef:
        apiVersion: machine.openshift.io/v1beta1
        kind: Machine
        name: ocp-edge-958fk-worker-0-nrfcg
        namespace: openshift-machine-api
      customDeploy:
        method: install_coreos
      online: true
      rootDeviceHints:
        deviceName: /dev/disk/by-id/scsi-<serial_number>
      userData:
        name: worker-user-data-managed
        namespace: openshift-machine-api
    status:
      errorCount: 0
      errorMessage: ""
      goodCredentials:
        credentials:
          name: openshift-worker-0-bmc-secret
          namespace: openshift-machine-api
        credentialsVersion: "16120"
      hardware:
        cpu:
          arch: x86_64
          clockMegahertz: 2300
          count: 64
          flags:
          - 3dnowprefetch
          - abm
          - acpi
          - adx
          - aes
          model: Intel(R) Xeon(R) Gold 5218 CPU @ 2.30GHz
        firmware:
          bios:
            date: 10/26/2020
            vendor: HPE
            version: U30
        hostname: openshift-worker-0
        nics:
        - mac: 48:df:37:c7:f7:b3
          model: 0x8086 0x1572
          name: ens1f3
        ramMebibytes: 262144
        storage:
        - hctl: "0:0:0:0"
          model: VK000960GWTTB
          name: /dev/disk/by-id/scsi-<serial_number>
          sizeBytes: 960197124096
          type: SSD
          vendor: ATA
        systemVendor:
          manufacturer: HPE
          productName: ProLiant DL380 Gen10 (868703-B21)
          serialNumber: CZ200606M3
      lastUpdated: "2022-06-16T11:41:42Z"
      operationalStatus: OK
      poweredOn: true
      provisioning:
        ID: 217baa14-cfcf-4196-b764-744e184a3413
        bootMode: UEFI
        customDeploy:
          method: install_coreos
        image:
          url: ""
        raid:
          hardwareRAIDVolumes: null
          softwareRAIDVolumes: []
        rootDeviceHints:
          deviceName: /dev/disk/by-id/scsi-<serial_number>
        state: provisioned
      triedCredentials:
        credentials:
          name: openshift-worker-0-bmc-secret
          namespace: openshift-machine-api
        credentialsVersion: "16120"
    Copy to Clipboard Toggle word wrap

4.7.4. 编辑 BareMetalHost 资源

在裸机上部署 OpenShift Container Platform 集群后,您可能需要编辑节点的 BareMetalHost 资源。请考虑以下示例:

  • 您可以使用 Assisted Installer 部署集群,并需要添加或编辑基板管理控制器 (BMC) 主机名或 IP 地址。
  • 您需要在不取消置备的情况下将节点从一个集群移到另一个集群。

先决条件

  • 确保节点处于 Provisioned, ExternallyProvisioned, 或 Available 状态。

流程

  1. 获取节点列表:

    $ oc get bmh -n openshift-machine-api
    Copy to Clipboard Toggle word wrap
  2. 在编辑节点的 BareMetalHost 资源前,运行以下命令从 Ironic 分离节点:

    $ oc annotate baremetalhost <node_name> -n openshift-machine-api 'baremetalhost.metal3.io/detached=true' 
    1
    Copy to Clipboard Toggle word wrap
    1
    <node_name> 替换为节点的名称。
  3. 运行以下命令来编辑 BareMetalHost 资源:

    $ oc edit bmh <node_name> -n openshift-machine-api
    Copy to Clipboard Toggle word wrap
  4. 运行以下命令,将节点重新附加到 Ironic:

    $ oc annotate baremetalhost <node_name> -n openshift-machine-api 'baremetalhost.metal3.io/detached'-
    Copy to Clipboard Toggle word wrap

4.7.5. 删除 BareMetalHost 资源时的延迟故障排除

当 Bare Metal Operator (BMO)删除 BareMetalHost 资源时,Ironic 会使用名为 cleaning 的进程取消置备裸机主机。当清理失败时,Ironic 会重试清理过程三次,这是延迟的来源。清理过程可能无法成功,从而导致裸机主机的置备状态无限期处于 deleting 状态。当发生这种情况时,请使用以下步骤禁用清理过程。

警告

不要从 BareMetalHost 资源中删除终结器。

流程

  1. 如果清理过程失败并重启,请等待它完成。这大约可能需要 5 分钟。
  2. 如果置备状态处于 deleting 状态,请通过修改 BareMetalHost 资源并将 automatedCleaningMode 字段设置为 disabled 来禁用清理过程。

如需了解更多详细信息,请参阅"编辑 BareMetalHost 资源"。

4.7.6. 将不可启动的 ISO 附加到裸机节点

您可以使用 DataImage 资源将通用、不可启动的 ISO 虚拟介质镜像附加到置备的节点上。在应用了资源后,操作系统引导后,ISO 镜像将可以被操作系统访问。这可用于在置备操作系统后配置节点,并在节点第一次引导前配置节点。

先决条件

  • 节点必须使用 Redfish 或从中派生的驱动程序来支持此功能。
  • 节点必须处于 ProvisionedExternallyProvisioned 状态。
  • 名称必须与其在 BareMetalHost 资源中定义的节点名称相同。
  • 有 ISO 镜像的有效 url

流程

  1. 创建一个 DataImage 资源:

    apiVersion: metal3.io/v1alpha1
    kind: DataImage
    metadata:
      name: <node_name> 
    1
    
    spec:
      url: "http://dataimage.example.com/non-bootable.iso" 
    2
    Copy to Clipboard Toggle word wrap
    1
    指定其在 BareMetalHost 资源中定义的节点名称。
    2
    指定 ISO 镜像的 URL 和路径。
  2. 运行以下命令,将 DataImage 资源保存到文件中:

    $ vim <node_name>-dataimage.yaml
    Copy to Clipboard Toggle word wrap
  3. 运行以下命令来应用 DataImage 资源:

    $ oc apply -f <node_name>-dataimage.yaml -n <node_namespace> 
    1
    Copy to Clipboard Toggle word wrap
    1
    替换 <node_namespace>,以便命名空间与 BareMetalHost 资源的命名空间匹配。例如,openshift-machine-api
  4. 重新引导节点。

    注意

    要重新引导节点,请附加 reboot.metal3.io 注解,或重置 BareMetalHost 资源中的 online 状态。对裸机节点强制重启会使节点的状态在一段事件内变为 NotReady。例如,5 分钟或更长时间。

  5. 运行以下命令来查看 DataImage 资源:

    $ oc get dataimage <node_name> -n openshift-machine-api -o yaml
    Copy to Clipboard Toggle word wrap

    输出示例

    apiVersion: v1
    items:
    - apiVersion: metal3.io/v1alpha1
      kind: DataImage
      metadata:
        annotations:
          kubectl.kubernetes.io/last-applied-configuration: |
            {"apiVersion":"metal3.io/v1alpha1","kind":"DataImage","metadata":{"annotations":{},"name":"bmh-node-1","namespace":"openshift-machine-api"},"spec":{"url":"http://dataimage.example.com/non-bootable.iso"}}
        creationTimestamp: "2024-06-10T12:00:00Z"
        finalizers:
        - dataimage.metal3.io
        generation: 1
        name: bmh-node-1
        namespace: openshift-machine-api
        ownerReferences:
        - apiVersion: metal3.io/v1alpha1
          blockOwnerDeletion: true
          controller: true
          kind: BareMetalHost
          name: bmh-node-1
          uid: 046cdf8e-0e97-485a-8866-e62d20e0f0b3
        resourceVersion: "21695581"
        uid: c5718f50-44b6-4a22-a6b7-71197e4b7b69
      spec:
        url: http://dataimage.example.com/non-bootable.iso
      status:
        attachedImage:
          url: http://dataimage.example.com/non-bootable.iso
        error:
          count: 0
          message: ""
        lastReconciled: "2024-06-10T12:05:00Z"
    Copy to Clipboard Toggle word wrap

4.7.7. 为共享 NIC 配置 NC-SI 和 DisablePowerOff

Network Controller Sideband Interface (NC-SI)使 Baseboard Management Controller (BMC)与主机共享系统网络接口卡(NIC),使用 Redfish、IPMI 或特定供应商接口等协议管理流量。DisablePowerOff 功能可防止硬电源关闭,从而确保软重启来保持 BMC 的连接。

先决条件

  • 支持 NC-SI 的硬件和 NIC.
  • 配置了 IP 地址和网络连接的 BMC。
  • 对 BMC 的管理访问权限。
  • 使用 cluster-admin 特权访问 OpenShift 集群。

流程

  1. 将 BMC 配置为为共享 NIC 启用 NC-SI。
  2. 运行以下命令,使用 Redfish 或 IPMI 验证 BMC 连接:

    $ curl -k https://<bmc_ip>/redfish/v1/Systems/1
    Copy to Clipboard Toggle word wrap
    $ ipmitool -I lanplus -H <bmc_ip> -U <user> -P <pass> power status
    Copy to Clipboard Toggle word wrap
  3. 通过编辑 openshift-machine-api 命名空间中的 BareMetalHost 资源来启用 DisablePowerOff 功能:

    apiVersion: metal3.io/v1alpha1
    kind: BareMetalHost
    metadata:
      name: example-host
      namespace: openshift-machine-api
    spec:
      online: true
      bmc:
        address: <protocol>://<bmc_ip>/<bmc_address_format>
        credentialsName: bmc-secret
      disablePowerOff: true
    Copy to Clipboard Toggle word wrap

    有关支持的协议和 BMC 地址格式的详情,请参阅"BMC 寻址"部分。

  4. 运行以下命令来应用更改:

    $ oc apply -f <filename>.yaml
    Copy to Clipboard Toggle word wrap

验证

  • 运行以下命令检查 BareMetalHost 状态:

    $ oc get baremetalhost example-host -n openshift-machine-api -o yaml
    Copy to Clipboard Toggle word wrap

    确认 disablePowerOff: true 位于 spec 部分。

  • 通过重启节点 pod 来测试重启,并验证 BMC 连接是否保持活跃状态。
  • 尝试设置 BareMetalHost.spec.online=false。它应该会失败,并显示禁用 power-off 的错误。

4.7.8. 关于 HostFirmwareSettings 资源

您可以使用 HostFirmwareSettings 资源来检索和管理主机的 BIOS 设置。当主机进入 Available 状态时,Ironic 会读取主机的 BIOS 设置并创建 HostFirmwareSettings 资源。资源包含从基板管理控制器(BMC)返回的完整 BIOS 配置。BareMetalHost 资源中的 firmware 字段会返回三个供应商独立的字段,HostFirmwareSettings 资源通常包含每个主机中特定供应商的字段的许多 BIOS 设置。

HostFirmwareSettings 资源包含两个部分:

  1. HostFirmwareSettings spec。
  2. HostFirmwareSettings 状态。
注意

仅根据独立于厂商的 Redfish 协议、Fujitu iRMC 或 HP iLO 的驱动程序才支持读和修改固件设置。

4.7.8.1. HostFirmwareSettings spec

HostFirmwareSettings 资源的 spec 部分定义了主机的 BIOS 所需的状态,默认为空。Ironic 使用 spec.settings 部分中的设置,在主机处于 Preparing 状态时更新基板管理控制器(BMC)。使用 FirmwareSchema 资源,确保不向主机发送无效的名称/值对。如需了解更多详细信息,请参阅 "About the FirmwareSchema resource"。

示例

spec:
  settings:
    ProcTurboMode: Disabled
1
Copy to Clipboard Toggle word wrap

1
在foregoing示例中,spec.settings 部分包含一个 name/value 对,它将把 ProcTurboMode BIOS 设置为 Disabled
注意

status 部分中列出的整数参数显示为字符串。例如,"1"。当在 spec.settings 部分中设置整数时,这些值应设置为不带引号的整数。例如,1.

4.7.8.2. HostFirmwareSettings 状态

status 代表主机的 BIOS 的当前状态。

Expand
表 4.3. HostFirmwareSettings
参数描述
status:
  conditions:
  - lastTransitionTime:
    message:
    observedGeneration:
    reason:
    status:
    type:
Copy to Clipboard Toggle word wrap

conditions 字段包含状态更改列表。子字段包括:

  • lastTransitionTime :状态更改最后一次的时间。
  • message: 状态更改的描述。
  • observedGeneration :当前 status 的世代。如果 metadata.generation 和此字段不同,则 status.conditions 可能已过时。
  • reason: 状态更改的原因。
  • status: 状态更改的状态。状态可以是 True, FalseUnknown
  • type: 状态更改的类型。类型为 ValidChangeDetected
status:
  schema:
    name:
    namespace:
    lastUpdated:
Copy to Clipboard Toggle word wrap

固件设置的 FirmwareSchema。这些字段包括:

  • name: 引用该模式的名称或唯一标识符。
  • namespace :存储 schema 的命名空间。
  • lastUpdated: 资源最后一次更新的时间。
status:
  settings:
Copy to Clipboard Toggle word wrap

settings 字段包含主机当前 BIOS 设置的名称/值对列表。

4.7.9. 获取 HostFirmwareSettings 资源

HostFirmwareSettings 资源包含物理主机的特定于供应商的 BIOS 属性。您必须获取物理主机的 HostFirmwareSettings 资源才能查看其 BIOS 属性。

流程

  1. 运行以下命令,获取 HostFirmwareSettings 资源的详细列表:

    $ oc get hfs -n openshift-machine-api -o yaml
    Copy to Clipboard Toggle word wrap
    注意

    您可以使用 hostfirmwaresettings 作为 oc get 命令的 hfs 长形式。

  2. 运行以下命令,获取 HostFirmwareSettings 资源列表:

    $ oc get hfs -n openshift-machine-api
    Copy to Clipboard Toggle word wrap
  3. 运行以下命令,获取特定主机的 HostFirmwareSettings 资源:

    $ oc get hfs <host_name> -n openshift-machine-api -o yaml
    Copy to Clipboard Toggle word wrap

    其中 <host_name> 是主机的名称。

要更改置备的主机的 HostFirmwareSettings spec,请执行以下操作:

  • 编辑主机 HostFirmwareSettings 资源。
  • 从机器集中删除主机。
  • 缩减机器集。
  • 扩展机器集以使更改生效。
重要

您只能在主机处于 provisioned 状态时编辑主机,不包括只读值。您不能编辑状态为 externally provisioned 的主机。

流程

  1. 运行以下命令,获取 HostFirmwareSettings 资源列表:

    $ oc get hfs -n openshift-machine-api
    Copy to Clipboard Toggle word wrap
  2. 运行以下命令来编辑主机 HostFirmwareSettings 资源:

    $ oc edit hfs <hostname> -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

    其中 <hostname> 是置备的主机的名称。HostFirmwareSettings 资源将在终端的默认编辑器中打开。

  3. 运行以下命令,在 spec.settings 部分添加 name 和 value 对:

    Example

    spec:
      settings:
        name: value 
    1
    Copy to Clipboard Toggle word wrap

    1
    使用 FirmwareSchema 资源来识别主机的可用设置。您不能设置只读值。
  4. 保存更改并退出编辑器。
  5. 运行以下命令来获取主机名:

     $ oc get bmh <hostname> -n openshift-machine name
    Copy to Clipboard Toggle word wrap

    其中 <hostname> 是主机的名称。终端在 CONSUMER 字段下显示机器名称。

  6. 运行以下命令,注解机器将其从机器集中删除:

    $ oc annotate machine <machine_name> machine.openshift.io/delete-machine=true -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

    其中 <machine_name> 是要删除的机器的名称。

  7. 运行以下命令,获取节点列表并计算 worker 节点数量:

    $ oc get nodes
    Copy to Clipboard Toggle word wrap
  8. 运行以下命令来获取机器集:

    $ oc get machinesets -n openshift-machine-api
    Copy to Clipboard Toggle word wrap
  9. 运行以下命令来扩展机器集:

    $ oc scale machineset <machineset_name> -n openshift-machine-api --replicas=<n-1>
    Copy to Clipboard Toggle word wrap

    其中 <machineset_name> 是集群集的名称,<n-1> 是减少的 worker 节点数量。

  10. 当主机进入 Available 状态时,运行以下命令扩展机器集,使 HostFirmwareSettings 资源更改生效:

    $ oc scale machineset <machineset_name> -n openshift-machine-api --replicas=<n>
    Copy to Clipboard Toggle word wrap

    其中 <machineset_name> 是机器集的名称,<n> 是 worker 节点的数量。

4.7.11. 对 HostFirmwareSettings 资源执行实时更新

您可以在运行工作负载后对 HostFirmareSettings 资源执行实时更新。实时更新不会触发取消置备和重新置备主机。

重要

实时更新主机只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围

先决条件

  • HostUpdatePolicy 资源必须将 firmwareSettings 参数设置为 onReboot

流程

  1. 运行以下命令来更新 HostFirmwareSettings 资源:

    $ oc patch hostfirmwaresettings <hostname> --type merge -p \
    1
    
        '{"spec": {"settings": {"<name>": "<value>"}}}' 
    2
    Copy to Clipboard Toggle word wrap
    1
    <hostname> 替换为主机的名称。
    2
    <name> 替换为设置的名称。将 <value> 替换为设置的值。您可以设置多个 name-value 对。
    注意

    获取 FirmwareSchema 资源,以确定硬件支持哪些设置以及您可以更新哪些设置和值。您无法更新只读值,您无法更新 FirmwareSchema 资源。您还可以使用 oc edit <hostname> hostfirmwaresettings -n openshift-machine-api 命令更新 HostFirmwareSettings 资源。

  2. 运行以下命令 cordon 和 drain 节点:

    $ oc drain <node_name> --force 
    1
    Copy to Clipboard Toggle word wrap
    1
    <node_name> 替换为节点的名称。
  3. 运行以下命令,关闭主机持续 5 分钟:

    $ oc patch bmh <hostname> --type merge -p '{"spec": {"online": false}}'
    Copy to Clipboard Toggle word wrap

    此步骤可确保 daemonset 或控制器可以将主机上运行的任何基础架构 pod 标记为离线,而剩余的主机处理传入的请求。

  4. 在 5 分钟后,运行以下命令来打开主机:

    $ oc patch bmh <hostname> --type merge -p '{"spec": {"online": true}}'
    Copy to Clipboard Toggle word wrap

    服务操作开始,Bare Metal Operator (BMO) 会将 BareMetalHostoperationalStatus 参数设置为 servicing。BMO 在更新资源后将 operationalStatus 参数更新为 OK。如果发生错误,BMO 会将 operationalStatus 参数更新为 error 并重试操作。

  5. Ironic 完成更新和主机电源后,运行以下命令取消协调节点:

    $ oc uncordon <node_name>
    Copy to Clipboard Toggle word wrap

4.7.12. 验证 HostFirmware Settings 资源是否有效

当用户编辑 spec.settings 部分以更改为 HostFirmwareSetting(HFS)资源时,BMO 会针对 FimwareSchema 资源验证更改,这是只读资源。如果设置无效,BMO 会将 status.ConditionType 值设置为 False,并生成事件并将其存储在 HFS 资源中。使用以下步骤验证资源是否有效。

流程

  1. 获取 HostFirmwareSetting 资源列表:

    $ oc get hfs -n openshift-machine-api
    Copy to Clipboard Toggle word wrap
  2. 验证特定主机的 HostFirmwareSettings 资源是否有效:

    $ oc describe hfs <host_name> -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

    其中 <host_name> 是主机的名称。

    输出示例

    Events:
      Type    Reason            Age    From                                    Message
      ----    ------            ----   ----                                    -------
      Normal  ValidationFailed  2m49s  metal3-hostfirmwaresettings-controller  Invalid BIOS setting: Setting ProcTurboMode is invalid, unknown enumeration value - Foo
    Copy to Clipboard Toggle word wrap

    重要

    如果响应返回 ValidationFailed,资源配置中会出现一个错误,您必须更新这些值以符合 FirmwareSchema 资源。

4.7.13. 关于 FirmwareSchema 资源

BIOS 设置因硬件供应商和主机模型而异。FirmwareSchema 资源是一个只读资源,其中包含每个主机模型中的每个 BIOS 设置的类型和限值。数据直接通过 Ironic 来自 BMC。FirmwareSchema 允许您识别 HostFirmwareSettings 资源的 spec 字段中可以指定的有效值。FirmwareSchema 资源具有从其设置和限值派生的唯一标识符。相同的主机模型使用相同的 FirmwareSchema 标识符。HostFirmwareSettings 的多个实例可能使用相同的 FirmwareSchema

Expand
表 4.4. FirmwareSchema 规格
参数描述
<BIOS_setting_name>
  attribute_type:
  allowable_values:
  lower_bound:
  upper_bound:
  min_length:
  max_length:
  read_only:
  unique:
Copy to Clipboard Toggle word wrap

spec 是由 BIOS 设置名称和设置的限制组成的简单映射。这些字段包括:

  • attribute_type :设置类型。支持的类型有:

    • Enumeration
    • 整数
    • 字符串
    • 布尔值
  • allowable_values :当 attribute_typeEnumeration 时,允许值的列表。
  • lower_boundattribute_typeInteger 时允许的最小值。
  • upper_boundattribute_typeInteger 时允许的最大值。
  • min_length :当 attribute_typeString 时,值的字符串最短长度。
  • max_length :当 attribute_typeString 时,值第字符串最长长度。
  • read_only : 设置为只读,不可修改。
  • unique :该设置特定于此主机。

4.7.14. 获取 FirmwareSchema 资源

每个供应商的每个主机模型都有不同的 BIOS 设置。在编辑 HostFirmwareSettings 资源的 spec 部分时,您设置的名称/值对必须符合该主机的固件模式。要确保设置有效的名称/值对,请获取主机的 FirmwareSchema 并查看它。

流程

  1. 运行以下命令,获取 FirmwareSchema 资源实例列表:

    $ oc get firmwareschema -n openshift-machine-api
    Copy to Clipboard Toggle word wrap
  2. 运行以下命令来获取特定的 FirmwareSchema 实例:

    $ oc get firmwareschema <instance_name> -n openshift-machine-api -o yaml
    Copy to Clipboard Toggle word wrap

    其中 <instance_name>HostFirmwareSettings 资源中所述的 schema 实例的名称(请参阅表 3)。

4.7.15. 关于 HostFirmwareComponents 资源

Metal3 提供了 HostFirmwareComponents 资源,它描述了 BIOS 和基板管理控制器 (BMC) 固件版本。HostFirmwareComponents 资源包含两个部分:

  1. HostFirmwareComponents spec
  2. HostFirmwareComponents 状态
4.7.15.1. HostFirmwareComponents spec

HostFirmwareComponents 资源的 spec 部分定义主机的 BIOS 和 BMC 版本的所需状态。

Expand
表 4.5. HostFirmwareComponents spec
参数描述
updates:
  component:
  url:
Copy to Clipboard Toggle word wrap

updates 配置设置包含要更新的组件。这些字段包括:

  • component:组件的名称。有效设置为 biosbmc
  • url : 组件固件规格和版本的 URL。
4.7.15.2. HostFirmwareComponents 状态

HostFirmwareComponents 资源的 status 部分返回主机的 BIOS 和 BMC 版本的当前状态。

Expand
表 4.6. HostFirmwareComponents 状态
参数描述
components:
  component:
  initialVersion:
  currentVersion:
  lastVersionFlashed:
  updatedAt:
Copy to Clipboard Toggle word wrap

components 部分包含组件的状态。这些字段包括:

  • component :固件组件的名称。它返回 biosbmc
  • initialVersion :组件的初始固件版本。在创建 BareMetalHost 资源时,Ironic 会检索此信息。您不能更改它。
  • currentVersion :组件的当前固件版本。最初,该值与 initialVersion 值匹配,直到 Ironic 更新了裸机主机上的固件。
  • lastVersionFlashed: 在裸机主机上闪存的组件的最新版本。此字段返回 null,直到 Ironic 更新了固件。
  • updatedAt :Ironic 更新裸机主机的固件时的时间戳。
updates:
  component:
  url:
Copy to Clipboard Toggle word wrap

updates 配置设置包含更新的组件。这些字段包括:

  • component:组件的名称。
  • url : 组件固件规格和版本的 URL。

4.7.16. 获取 HostFirmwareComponents 资源

HostFirmwareComponents 资源包含 BIOS 的特定固件版本,以及物理主机的基板管理控制器 (BMC)。您必须获取物理主机的 HostFirmwareComponents 资源,才能查看固件版本和状态。

流程

  1. 运行以下命令,获取 HostFirmwareComponents 资源的详细列表:

    $ oc get hostfirmwarecomponents -n openshift-machine-api -o yaml
    Copy to Clipboard Toggle word wrap
  2. 运行以下命令,获取 HostFirmwareComponents 资源列表:

    $ oc get hostfirmwarecomponents -n openshift-machine-api
    Copy to Clipboard Toggle word wrap
  3. 运行以下命令,获取特定主机的 HostFirmwareComponents 资源:

    $ oc get hostfirmwarecomponents <host_name> -n openshift-machine-api -o yaml
    Copy to Clipboard Toggle word wrap

    其中 <host_name> 是主机的名称。

    输出示例

    ---
    apiVersion: metal3.io/v1alpha1
    kind: HostFirmwareComponents
    metadata:
      creationTimestamp: 2024-04-25T20:32:06Z"
      generation: 1
      name: ostest-master-2
      namespace: openshift-machine-api
      ownerReferences:
      - apiVersion: metal3.io/v1alpha1
        blockOwnerDeletion: true
        controller: true
        kind: BareMetalHost
        name: ostest-master-2
        uid: 16022566-7850-4dc8-9e7d-f216211d4195
      resourceVersion: "2437"
      uid: 2038d63f-afc0-4413-8ffe-2f8e098d1f6c
    spec:
      updates: []
    status:
      components:
      - component: bios
        currentVersion: 1.0.0
        initialVersion: 1.0.0
      - component: bmc
        currentVersion: "1.00"
        initialVersion: "1.00"
      conditions:
      - lastTransitionTime: "2024-04-25T20:32:06Z"
        message: ""
        observedGeneration: 1
        reason: OK
        status: "True"
        type: Valid
      - lastTransitionTime: "2024-04-25T20:32:06Z"
        message: ""
        observedGeneration: 1
        reason: OK
        status: "False"
        type: ChangeDetected
      lastUpdated: "2024-04-25T20:32:06Z"
      updates: []
    Copy to Clipboard Toggle word wrap

您可以编辑置备主机的 HostFirmwareComponents 资源。

流程

  1. 运行以下命令,获取 HostFirmwareComponents 资源的详细列表:

    $ oc get hostfirmwarecomponents -n openshift-machine-api -o yaml
    Copy to Clipboard Toggle word wrap
  2. 运行以下命令来编辑 HostFirmwareComponents 资源:

    $ oc edit <hostname> hostfirmwarecomponents -n openshift-machine-api 
    1
    Copy to Clipboard Toggle word wrap
    1
    其中 <hostname> 是主机的名称。HostFirmwareComponents 资源将在终端的默认编辑器中打开。
  3. 进行适当的编辑。

    输出示例

    ---
    apiVersion: metal3.io/v1alpha1
    kind: HostFirmwareComponents
    metadata:
      creationTimestamp: 2024-04-25T20:32:06Z"
      generation: 1
      name: ostest-master-2
      namespace: openshift-machine-api
      ownerReferences:
      - apiVersion: metal3.io/v1alpha1
        blockOwnerDeletion: true
        controller: true
        kind: BareMetalHost
        name: ostest-master-2
        uid: 16022566-7850-4dc8-9e7d-f216211d4195
      resourceVersion: "2437"
      uid: 2038d63f-afc0-4413-8ffe-2f8e098d1f6c
    spec:
      updates:
        - name: bios 
    1
    
          url: https://myurl.with.firmware.for.bios 
    2
    
        - name: bmc 
    3
    
          url: https://myurl.with.firmware.for.bmc 
    4
    
    status:
      components:
      - component: bios
        currentVersion: 1.0.0
        initialVersion: 1.0.0
      - component: bmc
        currentVersion: "1.00"
        initialVersion: "1.00"
      conditions:
      - lastTransitionTime: "2024-04-25T20:32:06Z"
        message: ""
        observedGeneration: 1
        reason: OK
        status: "True"
        type: Valid
      - lastTransitionTime: "2024-04-25T20:32:06Z"
        message: ""
        observedGeneration: 1
        reason: OK
        status: "False"
        type: ChangeDetected
      lastUpdated: "2024-04-25T20:32:06Z"
    Copy to Clipboard Toggle word wrap

    1
    要设置 BIOS 版本,请将 name 属性设置为 bios
    2
    要设置 BIOS 版本,请将 url 属性设置为 BIOS 固件版本的 URL。
    3
    要设置 BMC 版本,请将 name 属性设置为 bmc
    4
    要设置 BMC 版本,将 url 属性设置为 BMC 固件版本的 URL。
  4. 保存更改并退出编辑器。
  5. 运行以下命令来获取主机名:

    $ oc get bmh <host_name> -n openshift-machine name 
    1
    Copy to Clipboard Toggle word wrap
    1
    其中 <host_name> 是主机的名称。终端在 CONSUMER 字段下显示机器名称。
  6. 运行以下命令,注解机器将其从机器集中删除:

    $ oc annotate machine <machine_name> machine.openshift.io/delete-machine=true -n openshift-machine-api 
    1
    Copy to Clipboard Toggle word wrap
    1
    其中 <machine_name> 是要删除的机器的名称。
  7. 运行以下命令,获取节点列表并计算 worker 节点数量:

    $ oc get nodes
    Copy to Clipboard Toggle word wrap
  8. 运行以下命令来获取机器集:

    $ oc get machinesets -n openshift-machine-api
    Copy to Clipboard Toggle word wrap
  9. 运行以下命令缩减机器集:

    $ oc scale machineset <machineset_name> -n openshift-machine-api --replicas=<n-1> 
    1
    Copy to Clipboard Toggle word wrap
    1
    其中 <machineset_name> 是集群集的名称,<n-1> 是减少的 worker 节点数量。
  10. 当主机进入 Available 状态时,运行以下命令扩展机器集,使 HostFirmwareComponents 资源更改生效:

    $ oc scale machineset <machineset_name> -n openshift-machine-api --replicas=<n> 
    1
    Copy to Clipboard Toggle word wrap
    1
    其中 <machineset_name> 是机器集的名称,<n> 是 worker 节点的数量。

4.7.18. 对 HostFirmwareComponents 资源执行实时更新

您可以对已经置备的主机上的 HostFirmwareComponents 资源执行实时更新。实时更新不会触发取消置备和重新置备主机。

重要

实时更新主机只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围

重要

不要在生产环境主机上执行实时更新。您可以对 BIOS 执行实时更新以进行测试。我们不建议在 OpenShift Container Platform 4.19 上对 BMC 进行实时更新,以满足测试目的,特别是在早期生成的硬件上。

先决条件

  • HostUpdatePolicy 资源必须将 firmwareUpdates 参数设置为 onReboot

流程

  1. 运行以下命令更新 HostFirmwareComponents 资源:

    $ oc patch hostfirmwarecomponents <hostname> --type merge -p \
    1
    
        '{"spec": {"updates": [{"component": "<type>", \
    2
    
                            "url": "<url>"}]}}' 
    3
    Copy to Clipboard Toggle word wrap
    1
    <hostname> 替换为主机的名称。
    2
    <type> 替换为组件的类型。指定 biosbmc
    3
    <url> 替换为组件的 URL。
    注意

    您还可以使用 oc edit <hostname> hostfirmwarecomponents -n openshift-machine-api 命令来更新资源。

  2. 运行以下命令 cordon 和 drain 节点:

    $ oc drain <node_name> --force 
    1
    Copy to Clipboard Toggle word wrap
    1
    <node_name> 替换为节点的名称。
  3. 运行以下命令,关闭主机持续 5 分钟:

    $ oc patch bmh <hostname> --type merge -p '{"spec": {"online": false}}'
    Copy to Clipboard Toggle word wrap

    此步骤可确保 daemonset 或控制器将节点上可能运行的任何基础架构 pod 标记为离线,而剩余的节点处理传入的请求。

  4. 在 5 分钟后,运行以下命令来打开主机:

    $ oc patch bmh <hostname> --type merge -p '{"spec": {"online": true}}'
    Copy to Clipboard Toggle word wrap

    服务操作开始,Bare Metal Operator (BMO) 会将 BareMetalHostoperationalStatus 参数设置为 servicing。BMO 在更新资源后将 operationalStatus 参数更新为 OK。如果发生错误,BMO 会将 operationalStatus 参数更新为 error 并重试操作。

  5. 运行以下命令,取消协调节点:

    $ oc uncordon <node_name>
    Copy to Clipboard Toggle word wrap

4.7.19. 关于 HostUpdatePolicy 资源

您可以使用 HostUpdatePolicy 资源来启用或禁用每个裸机主机的固件设置、BMC 设置或固件设置。默认情况下,Operator 会默认禁用对已置备的裸机主机的实时更新。

HostUpdatePolicy 规格

HostUpdatePolicy 资源的 spec 部分提供两个设置:

firmwareSettings
此设置对应于 HostFirmwareSettings 资源。
firmwareUpdates
此设置对应于 HostFirmwareComponents 资源。

当您将值设为 onPreparing 时,您只能在置备过程中更新主机,这是默认设置。当您将值设为 onReboot 时,您可以通过应用资源并重启裸机主机来更新置备的主机。然后,按照编辑 HostFirmwareSettingsHostFirmwareComponents 资源的步骤进行操作。

HostUpdatePolicy 资源示例

apiVersion: metal3.io/v1alpha1
kind: HostUpdatePolicy
metadata:
  name: <hostname> 
1

  namespace: openshift-machine-api
spec:
  firmwareSettings: <setting> 
2

  firmwareUpdates: <setting>
Copy to Clipboard Toggle word wrap

1
裸机主机的名称。
2
更新策略设置。指定 onPreparing 来禁用实时更新。指定 onReboot 启用实时更新。

4.7.20. 设置 HostUpdatePolicy 资源

默认情况下,HostUpdatePolicy 禁用实时更新。要启用实时更新,请使用以下流程:

重要

设置 HostUpdatePolicy 资源只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围

流程

  1. 运行以下命令来创建 HostUpdatePolicy 资源:

    $ vim hup.yaml
    Copy to Clipboard Toggle word wrap

    您可以使用您喜欢的任何文本编辑器。

    HostUpdatePolicy 资源示例

    apiVersion: metal3.io/v1alpha1
    kind: HostUpdatePolicy
    metadata:
      name: <hostname> 
    1
    
      namespace: openshift-machine-api
    spec:
      firmwareSettings: onReboot
      firmwareUpdates: onReboot
    Copy to Clipboard Toggle word wrap

    1
    <hostname> 替换为主机的名称。
  2. 将更改保存到 hup.yaml 文件。
  3. 运行以下命令来应用策略:

    $ oc apply -f hup.yaml
    Copy to Clipboard Toggle word wrap

第 5 章 扩展集群

部署裸机集群后,您可以使用以下步骤扩展 worker 节点的数量。确保每个 worker 节点都满足先决条件。

注意

使用 RedFish Virtual Media 扩展集群需要满足最低固件要求。有关使用 RedFish Virtual Media 扩展集群的详情,请参阅先决条件部分中的使用虚拟介质安装的固件要求

5.1. 准备裸机节点

要扩展集群,必须为节点提供相关 IP 地址。这可以通过静态配置,或使用 DHCP (动态主机配置协议)服务器来完成。在使用 DHCP 服务器扩展集群时,每个节点都必须有 DHCP 保留。

保留 IP 地址,以便其成为静态 IP 地址

有些管理员更喜欢使用静态 IP 地址,以便在没有 DHCP 服务器时每个节点的 IP 地址保持恒定状态。要使用 NMState 配置静态 IP 地址,请参阅 install-config.yaml 文件中的 "可选:配置主机网络接口,以了解更多详细信息。

准备裸机节点需要从 provisioner 节点执行以下步骤。

流程

  1. 获取 oc 二进制文件:

    $ curl -s https://mirror.openshift.com/pub/openshift-v4/clients/ocp/$VERSION/openshift-client-linux-$VERSION.tar.gz | tar zxvf - oc
    Copy to Clipboard Toggle word wrap
    $ sudo cp oc /usr/local/bin
    Copy to Clipboard Toggle word wrap
  2. 使用基板管理控制器 (BMC) 关闭裸机节点,并确保它已关闭。
  3. 检索裸机节点基板管理控制器的用户名和密码。然后,从用户名和密码创建 base64 字符串:

    $ echo -ne "root" | base64
    Copy to Clipboard Toggle word wrap
    $ echo -ne "password" | base64
    Copy to Clipboard Toggle word wrap
  4. 为裸机节点创建配置文件。根据您是否使用静态配置还是 DHCP 服务器,请使用以下示例 bmh.yaml 文件,替换 YAML 中的值以匹配您的环境:

    $ vim bmh.yaml
    Copy to Clipboard Toggle word wrap
    • 静态配置 bmh.yaml

      ---
      apiVersion: v1 
      1
      
      kind: Secret
      metadata:
       name: openshift-worker-<num>-network-config-secret 
      2
      
       namespace: openshift-machine-api
      type: Opaque
      stringData:
       nmstate: | 
      3
      
        interfaces: 
      4
      
        - name: <nic1_name> 
      5
      
          type: ethernet
          state: up
          ipv4:
            address:
            - ip: <ip_address> 
      6
      
              prefix-length: 24
            enabled: true
        dns-resolver:
          config:
            server:
            - <dns_ip_address> 
      7
      
        routes:
          config:
          - destination: 0.0.0.0/0
            next-hop-address: <next_hop_ip_address> 
      8
      
            next-hop-interface: <next_hop_nic1_name> 
      9
      
      ---
      apiVersion: v1
      kind: Secret
      metadata:
        name: openshift-worker-<num>-bmc-secret 
      10
      
        namespace: openshift-machine-api
      type: Opaque
      data:
        username: <base64_of_uid> 
      11
      
        password: <base64_of_pwd> 
      12
      
      ---
      apiVersion: metal3.io/v1alpha1
      kind: BareMetalHost
      metadata:
        name: openshift-worker-<num> 
      13
      
        namespace: openshift-machine-api
      spec:
        online: True
        bootMACAddress: <nic1_mac_address> 
      14
      
        bmc:
          address: <protocol>://<bmc_url> 
      15
      
          credentialsName: openshift-worker-<num>-bmc-secret 
      16
      
          disableCertificateVerification: True 
      17
      
          username: <bmc_username> 
      18
      
          password: <bmc_password> 
      19
      
        rootDeviceHints:
          deviceName: <root_device_hint> 
      20
      
        preprovisioningNetworkDataName: openshift-worker-<num>-network-config-secret 
      21
      Copy to Clipboard Toggle word wrap
      1
      要为新创建的节点配置网络接口,请指定包含网络配置的 secret 的名称。按照 nmstate 语法为节点定义网络配置。有关配置 NMState 语法的详情,请参阅"可选:在 install-config.yaml 文件中配置主机网络接口"。
      2 10 13 16
      namecredentialsName 字段和 preprovisioningNetworkDataName 字段中,使用裸机节点的 worker 数量替换 <num>
      3
      添加 NMState YAML 语法来配置主机接口。
      4
      可选:如果您使用 nmstate 配置网络接口,并且您要禁用接口,请将 state: 设置为 enabled: false,如下所示:
      ---
         interfaces:
         - name: <nic_name>
           type: ethernet
           state: up
           ipv4:
             enabled: false
           ipv6:
             enabled: false
      Copy to Clipboard Toggle word wrap
      5 6 7 8 9
      使用适当的值替换 <nic1_name>, <ip_address>, <dns_ip_address>, <next_hop_ip_address><next_hop_nic1_name>
      11 12
      <base64_of_uid><base64_of_pwd> 替换为用户名和密码的 base64 字符串。
      14
      <nic1_mac_address> 替换为裸机节点第一个 NIC 的 MAC 地址。如需了解更多 BMC 配置选项,请参阅"BMC 寻址"部分。
      15
      <protocol> 替换为 BMC 协议,如 IPMI、RedFish 或其他协议。将 <bmc_url> 替换为裸机节点基板管理控制器的 URL。
      17
      要跳过证书验证,将 disableCertificateVerification 设为 true。
      18 19
      <bmc_username><bmc_password> 替换为 BMC 用户名和密码的字符串。
      20
      可选:如果您指定了 root 设备提示,将 <root_device_hint> 替换为设备路径。
      21
      可选: 如果您为新创建的节点配置了网络接口,请在 BareMetalHost CR 的 preprovisioningNetworkDataName 中提供网络配置 secret 名称。
    • DHCP 配置 bmh.yaml

      ---
      apiVersion: v1
      kind: Secret
      metadata:
        name: openshift-worker-<num>-bmc-secret 
      1
      
        namespace: openshift-machine-api
      type: Opaque
      data:
        username: <base64_of_uid> 
      2
      
        password: <base64_of_pwd> 
      3
      
      ---
      apiVersion: metal3.io/v1alpha1
      kind: BareMetalHost
      metadata:
        name: openshift-worker-<num> 
      4
      
        namespace: openshift-machine-api
      spec:
        online: True
        bootMACAddress: <nic1_mac_address> 
      5
      
        bmc:
          address: <protocol>://<bmc_url> 
      6
      
          credentialsName: openshift-worker-<num>-bmc-secret 
      7
      
          disableCertificateVerification: True 
      8
      
          username: <bmc_username> 
      9
      
          password: <bmc_password> 
      10
      
        rootDeviceHints:
          deviceName: <root_device_hint> 
      11
      
        preprovisioningNetworkDataName: openshift-worker-<num>-network-config-secret 
      12
      Copy to Clipboard Toggle word wrap
      1 4 7
      namecredentialsName 字段和 preprovisioningNetworkDataName 字段中,使用裸机节点的 worker 数量替换 <num>
      2 3
      <base64_of_uid><base64_of_pwd> 替换为用户名和密码的 base64 字符串。
      5
      <nic1_mac_address> 替换为裸机节点第一个 NIC 的 MAC 地址。如需了解更多 BMC 配置选项,请参阅"BMC 寻址"部分。
      6
      <protocol> 替换为 BMC 协议,如 IPMI、RedFish 或其他协议。将 <bmc_url> 替换为裸机节点基板管理控制器的 URL。
      8
      要跳过证书验证,将 disableCertificateVerification 设为 true。
      9 10
      <bmc_username><bmc_password> 替换为 BMC 用户名和密码的字符串。
      11
      可选:如果您指定了 root 设备提示,将 <root_device_hint> 替换为设备路径。
      12
      可选: 如果您为新创建的节点配置了网络接口,请在 BareMetalHost CR 的 preprovisioningNetworkDataName 中提供网络配置 secret 名称。
    注意

    如果现有裸机节点的 MAC 地址与您试图置备的裸机主机的 MAC 地址匹配,则 Ironic 安装将失败。如果主机注册、检查、清理或其他 Ironic 步骤失败,Bare Metal Operator 会持续重试安装。如需更多信息,请参阅"诊断主机重复的 MAC 地址"。

  5. 创建裸机节点:

    $ oc -n openshift-machine-api create -f bmh.yaml
    Copy to Clipboard Toggle word wrap

    输出示例

    secret/openshift-worker-<num>-network-config-secret created
    secret/openshift-worker-<num>-bmc-secret created
    baremetalhost.metal3.io/openshift-worker-<num> created
    Copy to Clipboard Toggle word wrap

    其中 <num> 是 worker 号。

  6. 启动并检查裸机节点:

    $ oc -n openshift-machine-api get bmh openshift-worker-<num>
    Copy to Clipboard Toggle word wrap

    其中 <num> 是 worker 节点号。

    输出示例

    NAME                    STATE       CONSUMER   ONLINE   ERROR
    openshift-worker-<num>  available              true
    Copy to Clipboard Toggle word wrap

    注意

    要允许 worker 节点加入集群,请将 machineset 对象扩展到 BareMetalHost 对象的数量。您可以手动或自动缩放节点。要自动扩展节点,请为 machineset 使用 metal3.io/autoscale-to-hosts 注解。

5.2. 替换裸机 control plane 节点

使用以下步骤替换 OpenShift Container Platform control plane 节点。

重要

如果您从现有 control plane 主机重复使用 BareMetalHost 对象定义,请不要将 externallyProvisioned 字段保留为 true

如果 OpenShift Container Platform 安装程序置备,现有 control plane BareMetalHost 对象可能会将 externallyProvisioned 标记设为 true

先决条件

  • 您可以使用具有 cluster-admin 角色的用户访问集群。
  • 已进行 etcd 备份。

    重要

    执行此流程前进行 etcd 备份,以便在遇到任何问题时可以恢复集群。有关获取 etcd 备份的更多信息,请参阅附加资源部分。

流程

  1. 确保 Bare Metal Operator 可用:

    $ oc get clusteroperator baremetal
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME        VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
    baremetal   4.19     True          False      False   3d15h
    Copy to Clipboard Toggle word wrap

  2. 删除旧的 BareMetalHostMachine 对象:

    $ oc delete bmh -n openshift-machine-api <host_name>
    $ oc delete machine -n openshift-machine-api <machine_name>
    Copy to Clipboard Toggle word wrap

    <host_name> 替换为主机名,<machine_name> 替换为机器的名称。机器名称会出现在 CONSUMER 字段下。

    删除 BareMetalHostMachine 对象后,机器控制器会自动删除 Node 对象。

  3. 创建新的 BareMetalHost 对象和 secret,以存储 BMC 凭证:

    $ cat <<EOF | oc apply -f -
    apiVersion: v1
    kind: Secret
    metadata:
      name: control-plane-<num>-bmc-secret 
    1
    
      namespace: openshift-machine-api
    data:
      username: <base64_of_uid> 
    2
    
      password: <base64_of_pwd> 
    3
    
    type: Opaque
    ---
    apiVersion: metal3.io/v1alpha1
    kind: BareMetalHost
    metadata:
      name: control-plane-<num> 
    4
    
      namespace: openshift-machine-api
    spec:
      automatedCleaningMode: disabled
      bmc:
        address: <protocol>://<bmc_ip> 
    5
    
        credentialsName: control-plane-<num>-bmc-secret 
    6
    
      bootMACAddress: <NIC1_mac_address> 
    7
    
      bootMode: UEFI
      externallyProvisioned: false
      online: true
    EOF
    Copy to Clipboard Toggle word wrap
    1 4 6
    name 字段和 credentialsName 字段中,使用裸机节点的 control plane 数量替换 <num>
    2
    <base64_of_uid> 替换为用户名的 base64 格式的字符串。
    3
    <base64_of_pwd> 替换为密码的 base64 格式的字符串。
    5
    <protocol> 替换为 BMC 协议,如 redfishredfish-virtualmediaidrac-virtualmedia 或其他。将 <bmc_ip> 替换为裸机节点基板管理控制器的 IP 地址。如需了解更多 BMC 配置选项,请参阅附加资源部分中的 "BMC 寻址"。
    7
    <NIC1_mac_address> 替换为裸机节点第一个 NIC 的 MAC 地址。

    检查完成后,BareMetalHost 对象会被创建并可用置备。

  4. 查看可用的 BareMetalHost 对象:

    $ oc get bmh -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME                          STATE                    CONSUMER                   ONLINE   ERROR   AGE
    control-plane-1.example.com   available                control-plane-1            true             1h10m
    control-plane-2.example.com   externally provisioned   control-plane-2            true             4h53m
    control-plane-3.example.com   externally provisioned   control-plane-3            true             4h53m
    compute-1.example.com         provisioned              compute-1-ktmmx            true             4h53m
    compute-1.example.com         provisioned              compute-2-l2zmb            true             4h53m
    Copy to Clipboard Toggle word wrap

    control plane 节点没有 MachineSet 对象,因此您必须创建 Machine 对象。您可以从另一个 control plane Machine 对象复制 providerSpec

  5. 创建 Machine 对象:

    $ cat <<EOF | oc apply -f -
    apiVersion: machine.openshift.io/v1beta1
    kind: Machine
    metadata:
      annotations:
        metal3.io/BareMetalHost: openshift-machine-api/control-plane-<num>
      labels:
        machine.openshift.io/cluster-api-cluster: control-plane-<num>
        machine.openshift.io/cluster-api-machine-role: master
        machine.openshift.io/cluster-api-machine-type: master
      name: control-plane-<num>
      namespace: openshift-machine-api
    spec:
      metadata: {}
      providerSpec:
        value:
          apiVersion: baremetal.cluster.k8s.io/v1alpha1
          customDeploy:
            method: install_coreos
          hostSelector: {}
          image:
            checksum: ""
            url: ""
          kind: BareMetalMachineProviderSpec
          metadata:
            creationTimestamp: null
          userData:
            name: master-user-data-managed
    EOF
    Copy to Clipboard Toggle word wrap

    annotations, labelsname 字段中,将 <num> 替换为裸机节点的 control plane 数量。

  6. 要查看 BareMetalHost 对象,请运行以下命令:

    $ oc get bmh -A
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME                          STATE                    CONSUMER                   ONLINE   ERROR   AGE
    control-plane-1.example.com   provisioned              control-plane-1            true             2h53m
    control-plane-2.example.com   externally provisioned   control-plane-2            true             5h53m
    control-plane-3.example.com   externally provisioned   control-plane-3            true             5h53m
    compute-1.example.com         provisioned              compute-1-ktmmx            true             5h53m
    compute-2.example.com         provisioned              compute-2-l2zmb            true             5h53m
    Copy to Clipboard Toggle word wrap

  7. 在 RHCOS 安装后,验证 BareMetalHost 是否已添加到集群中:

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME                           STATUS      ROLES     AGE   VERSION
    control-plane-1.example.com    available   master    4m2s  v1.32.3
    control-plane-2.example.com    available   master    141m  v1.32.3
    control-plane-3.example.com    available   master    141m  v1.32.3
    compute-1.example.com          available   worker    87m   v1.32.3
    compute-2.example.com          available   worker    87m   v1.32.3
    Copy to Clipboard Toggle word wrap

    注意

    替换新的 control plane 节点后,在新节点上运行的 etcd pod 处于 crashloopback 状态。如需更多信息,请参阅附加资源部分中的 "替换不健康的 etcd 成员"。

如果启用了 provisioning 网络,且您要使用 baremetal 网络中的 Virtual Media 扩展集群,请使用以下步骤。

先决条件

  • 有一个带有 a baremetal 网络和 provisioning 网络的现有集群。

流程

  1. 编辑 置备 自定义资源(CR),以在 baremetal 网络中使用 Virtual Media 启用部署:

    oc edit provisioning
    Copy to Clipboard Toggle word wrap
      apiVersion: metal3.io/v1alpha1
      kind: Provisioning
      metadata:
        creationTimestamp: "2021-08-05T18:51:50Z"
        finalizers:
        - provisioning.metal3.io
        generation: 8
        name: provisioning-configuration
        resourceVersion: "551591"
        uid: f76e956f-24c6-4361-aa5b-feaf72c5b526
      spec:
        provisioningDHCPRange: 172.22.0.10,172.22.0.254
        provisioningIP: 172.22.0.3
        provisioningInterface: enp1s0
        provisioningNetwork: Managed
        provisioningNetworkCIDR: 172.22.0.0/24
        virtualMediaViaExternalNetwork: true 
    1
    
      status:
        generations:
        - group: apps
          hash: ""
          lastGeneration: 7
          name: metal3
          namespace: openshift-machine-api
          resource: deployments
        - group: apps
          hash: ""
          lastGeneration: 1
          name: metal3-image-cache
          namespace: openshift-machine-api
          resource: daemonsets
        observedGeneration: 8
        readyReplicas: 0
    Copy to Clipboard Toggle word wrap
    1
    virtualMediaViaExternalNetwork: true 添加到 provisioning CR。
  2. 如果镜像 URL 存在,请编辑 machineset 以使用 API VIP 地址。此步骤只适用于在 4.9 或更早版本安装的集群。

    oc edit machineset
    Copy to Clipboard Toggle word wrap
      apiVersion: machine.openshift.io/v1beta1
      kind: MachineSet
      metadata:
        creationTimestamp: "2021-08-05T18:51:52Z"
        generation: 11
        labels:
          machine.openshift.io/cluster-api-cluster: ostest-hwmdt
          machine.openshift.io/cluster-api-machine-role: worker
          machine.openshift.io/cluster-api-machine-type: worker
        name: ostest-hwmdt-worker-0
        namespace: openshift-machine-api
        resourceVersion: "551513"
        uid: fad1c6e0-b9da-4d4a-8d73-286f78788931
      spec:
        replicas: 2
        selector:
          matchLabels:
            machine.openshift.io/cluster-api-cluster: ostest-hwmdt
            machine.openshift.io/cluster-api-machineset: ostest-hwmdt-worker-0
        template:
          metadata:
            labels:
              machine.openshift.io/cluster-api-cluster: ostest-hwmdt
              machine.openshift.io/cluster-api-machine-role: worker
              machine.openshift.io/cluster-api-machine-type: worker
              machine.openshift.io/cluster-api-machineset: ostest-hwmdt-worker-0
          spec:
            metadata: {}
            providerSpec:
              value:
                apiVersion: baremetal.cluster.k8s.io/v1alpha1
                hostSelector: {}
                image:
                  checksum: http:/172.22.0.3:6181/images/rhcos-<version>.<architecture>.qcow2.<md5sum> 
    1
    
                  url: http://172.22.0.3:6181/images/rhcos-<version>.<architecture>.qcow2 
    2
    
                kind: BareMetalMachineProviderSpec
                metadata:
                  creationTimestamp: null
                userData:
                  name: worker-user-data
      status:
        availableReplicas: 2
        fullyLabeledReplicas: 2
        observedGeneration: 11
        readyReplicas: 2
        replicas: 2
    Copy to Clipboard Toggle word wrap
    1
    编辑 校验和 URL,以使用 API VIP 地址。
    2
    编辑 URL 以使用 API VIP 地址。

如果集群中现有裸机节点的 MAC 地址与您试图添加到集群的裸机主机的 MAC 地址匹配,Bare Metal Operator 将主机与现有节点关联。如果主机注册、检查、清理或其他 Ironic 步骤失败,Bare Metal Operator 会持续重试安装。失败的裸机主机会显示注册错误。

您可以通过检查在 openshift-machine-api 命名空间中运行的裸机主机来诊断重复的 MAC 地址。

先决条件

  • 在裸机上安装 OpenShift Container Platform 集群。
  • 安装 OpenShift Container Platform CLI oc
  • 以具有 cluster-admin 权限的用户身份登录。

流程

要确定置备失败的裸机主机是否具有与现有节点相同的 MAC 地址,请执行以下操作:

  1. 获取在 openshift-machine-api 命名空间中运行的裸机主机:

    $ oc get bmh -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

    输出示例

    NAME                 STATUS   PROVISIONING STATUS      CONSUMER
    openshift-master-0   OK       externally provisioned   openshift-zpwpq-master-0
    openshift-master-1   OK       externally provisioned   openshift-zpwpq-master-1
    openshift-master-2   OK       externally provisioned   openshift-zpwpq-master-2
    openshift-worker-0   OK       provisioned              openshift-zpwpq-worker-0-lv84n
    openshift-worker-1   OK       provisioned              openshift-zpwpq-worker-0-zd8lm
    openshift-worker-2   error    registering
    Copy to Clipboard Toggle word wrap

  2. 要查看失败主机状态的更多详细信息,请运行以下命令将 <bare_metal_host_name> 替换为主机名称:

    $ oc get -n openshift-machine-api bmh <bare_metal_host_name> -o yaml
    Copy to Clipboard Toggle word wrap

    输出示例

    ...
    status:
      errorCount: 12
      errorMessage: MAC address b4:96:91:1d:7c:20 conflicts with existing node openshift-worker-1
      errorType: registration error
    ...
    Copy to Clipboard Toggle word wrap

5.5. 置备裸机节点

置备裸机节点需要从 provisioner 节点执行以下步骤。

流程

  1. 在置备裸机节点前,请确保 STATEavailable

    $  oc -n openshift-machine-api get bmh openshift-worker-<num>
    Copy to Clipboard Toggle word wrap

    其中 <num> 是 worker 节点号。

    NAME              STATE     ONLINE ERROR  AGE
    openshift-worker  available true          34h
    Copy to Clipboard Toggle word wrap
  2. 获取 worker 节点数量。

    $ oc get nodes
    Copy to Clipboard Toggle word wrap
    NAME                                                STATUS   ROLES           AGE     VERSION
    openshift-master-1.openshift.example.com            Ready    master          30h     v1.32.3
    openshift-master-2.openshift.example.com            Ready    master          30h     v1.32.3
    openshift-master-3.openshift.example.com            Ready    master          30h     v1.32.3
    openshift-worker-0.openshift.example.com            Ready    worker          30h     v1.32.3
    openshift-worker-1.openshift.example.com            Ready    worker          30h     v1.32.3
    Copy to Clipboard Toggle word wrap
  3. 获取计算机器集。

    $ oc get machinesets -n openshift-machine-api
    Copy to Clipboard Toggle word wrap
    NAME                                DESIRED   CURRENT   READY   AVAILABLE   AGE
    ...
    openshift-worker-0.example.com      1         1         1       1           55m
    openshift-worker-1.example.com      1         1         1       1           55m
    Copy to Clipboard Toggle word wrap
  4. 将 worker 节点数量增加一个。

    $ oc scale --replicas=<num> machineset <machineset> -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

    <num> 替换为新的 worker 节点数。将 <machineset> 替换为上一步中计算机器设置的名称。

  5. 检查裸机节点的状态。

    $ oc -n openshift-machine-api get bmh openshift-worker-<num>
    Copy to Clipboard Toggle word wrap

    其中 <num> 是 worker 节点号。STATE 从 ready 变为 provisioning

    NAME                    STATE             CONSUMER                          ONLINE   ERROR
    openshift-worker-<num>  provisioning      openshift-worker-<num>-65tjz      true
    Copy to Clipboard Toggle word wrap

    provisioning 状态会保持,直到 OpenShift Container Platform 集群置备节点。这可能需要 30 分钟或更长时间。在调配节点后,其状态将更改为 provisioned

    NAME                    STATE             CONSUMER                          ONLINE   ERROR
    openshift-worker-<num>  provisioned       openshift-worker-<num>-65tjz      true
    Copy to Clipboard Toggle word wrap
  6. 在置备完成后,确保裸机节点就绪。

    $ oc get nodes
    Copy to Clipboard Toggle word wrap
    NAME                                          STATUS   ROLES   AGE     VERSION
    openshift-master-1.openshift.example.com      Ready    master  30h     v1.32.3
    openshift-master-2.openshift.example.com      Ready    master  30h     v1.32.3
    openshift-master-3.openshift.example.com      Ready    master  30h     v1.32.3
    openshift-worker-0.openshift.example.com      Ready    worker  30h     v1.32.3
    openshift-worker-1.openshift.example.com      Ready    worker  30h     v1.32.3
    openshift-worker-<num>.openshift.example.com  Ready    worker  3m27s   v1.32.3
    Copy to Clipboard Toggle word wrap

    您还可以检查 kubelet。

    $ ssh openshift-worker-<num>
    Copy to Clipboard Toggle word wrap
    [kni@openshift-worker-<num>]$ journalctl -fu kubelet
    Copy to Clipboard Toggle word wrap

第 6 章 使用裸机作为服务

OpenShift Container Platform 的 Bare Metal as Service (BMaaS)功能可让您使用 Metal3 API 和 Bare Metal Operator (BMO)来配置和管理裸机主机。这些主机(OpenShift Container Platform 集群外部)可以运行可能不适用于容器化或虚拟化的工作负载。例如,需要直接访问硬件的应用程序等工作负载,执行高性能计算任务或是传统应用程序。BMaaS 具有以下功能:

  • 调配裸机主机,包括初始配置。
  • 使用 BMO 进行生命周期管理,如电源管理、固件更新和停用。

作为独立系统,这些主机独立于 OpenShift Container Platform 集群运行,并通过将裸机资源与容器化和虚拟化应用程序集成来支持各种工作负载。BMaaS 可以运行其他操作系统,但只测试了 Red Hat Enterprise Linux (RHEL) 和 CentOS Stream 9。

重要

BMaaS 只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围

6.1. 使用 BMaaS 的先决条件

要将裸机用作服务(BMaaS)技术预览,请完成以下先决条件:

BareMetalHost 配置
所有裸机主机都必须使用配置了 Redfish 协议和虚拟介质(redfish-virtualmedia)驱动程序的 Baseboard Management Controller (BMC)。每个裸机主机都需要一个引导接口,其 MAC 地址配置为接收 IP 地址租期。
网络要求
与 OpenShift Container Platform 和裸机3 基础架构分开的 DHCP 服务器必须在与裸机主机相同的第 2 层网络上操作。DHCP 服务器必须配置为与裸机主机上引导接口的 MAC 地址匹配,从而启用 IP 地址分配以与裸机3 组件通信。
集群特权
您必须在 OpenShift Container Platform 集群上具有 cluster-admin 权限,才能执行 BMaaS 配置任务。
带有镜像的 Web 服务器

BMaaS 不提供在硬件上部署的镜像。您必须使用您要使用的镜像和校验和配置 web 服务器。BareMetalHost spec 的 image 字段在部署过程中引用这些镜像。确保裸机主机可以访问 Web 服务器 URL。以下是镜像和校验和的示例:

这些先决条件确保 BMaaS 可以有效地调配和管理裸机主机。

要使 Bare Metal Operator (BMO) 在 OpenShift Container Platform 集群的所有命名空间中管理 BareMetalHost 资源,您必须配置 Operator 来监视所有命名空间。此配置对于避免将非 OpenShift Container Platform 工作负载与同一命名空间中的其他组件混合非常重要。

先决条件

  • 如果使用用户置备的安装,且 Provisioning CR 不存在,您必须手动创建。具体步骤请参阅配置置备资源以扩展用户置备的集群。对于安装程序置备的安装,安装程序会自动创建 Provisioning 自定义资源(CR)。

流程

  • 运行以下命令来修补置备配置以启用监视所有命名空间:

    $ oc patch provisioning/provisioning-configuration \
      --type merge -p '{"spec": {"watchAllNamespaces": true}}'
    Copy to Clipboard Toggle word wrap

    BMO 会自动应用此更改。

6.3. 设置专用命名空间

为防止裸机即服务(BMaaS)工作负载和 OpenShift Container Platform 基础架构之间的意外干扰,请设置专用命名空间。为每个 BMaaS 项目重复此步骤。

先决条件

流程

  1. 在身份提供程序中配置 BMaaS bmadmin 用户,并在 OpenShift 中创建 secret:

    1. 在身份提供程序中创建 bmadmin 用户。例如,如果使用 htpasswd 身份提供程序,请运行以下命令:

      $ htpasswd -c -B -b ./users_htpasswd <username> <password>
      Copy to Clipboard Toggle word wrap
      <username>
      身份提供程序的用户名。将 <username> 替换为您的首选用户名。本例使用 bmadmin
      <password>
      用户的密码。将 <password> 替换为安全的密码。
    2. 运行以下命令,在 openshift-config 命名空间中创建 secret 来存储身份提供程序配置:

      $ oc create secret generic <identity_provider_arguments> -n openshift-config
      Copy to Clipboard Toggle word wrap

      例如,在使用 htpasswd 身份提供程序时,运行以下命令:

      $ oc create secret generic htpass-secret --from-file=htpasswd=users_htpasswd -n openshift-config
      Copy to Clipboard Toggle word wrap
      <identity_provider_arguments>
      特定于身份提供程序 secret 的参数。将 <identity_provider_arguments> 替换为身份提供程序的适当参数。
  2. 配置 OAuth 以使用身份提供程序:

    1. 运行以下命令来编辑 OAuth 资源:

      $ oc edit oauth cluster
      Copy to Clipboard Toggle word wrap

      编辑器会打开并显示 Oauth 资源。

    2. 将身份提供程序配置添加到 spec.identityProviders 列表中:

      Expand
      表 6.1. 身份提供程序配置示例
      类型Example

      htpasswd

      # ...
      - name: my_bmaas_provider
        mappingMethod: claim
        type: htpasswd
        htpasswd:
          fileData:
            name: <secret>
      # ...
      Copy to Clipboard Toggle word wrap

      LDAP

      # ...
      - name: my_bmaas_provider
        mappingMethod: claim
        type: ldap
        ldap:
          attributes:
            id:
            - dn
            email:
            - mail
            name:
            - cn
            preferredUsername:
            - uid
      # ...
      Copy to Clipboard Toggle word wrap

      GitHub

      # ...
      - name: my_bmaas_provider
        mappingMethod: claim
        type: GitHub
          github:
            ca:
              name: ca-config-map
            clientID: {...}
            clientSecret:
              name: github-secret
            hostname: ...
            organizations:
            - myorganization1
            - myorganization2
            teams:
            - myorganization1/team-a
            - myorganization2/team-b
      # ...
      Copy to Clipboard Toggle word wrap

      有关标识提供程序的更多信息,请参阅身份验证和授权

    3. 保存并退出编辑器。
  3. 运行以下命令来创建 BMaaS bmadmin 用户:

    $ oc create user <username>
    Copy to Clipboard Toggle word wrap
    <username>
    用户名。将 <username> 替换为您的用户名。以下示例使用 bmadmin 作为用户名。
  4. 运行以下命令,为 BMaaS 主机创建一个专用的 bmaas 命名空间:

    $ oc new-project <namespace>
    Copy to Clipboard Toggle word wrap
    <namespace>
    将 <namespace> 替换为您要使用的命名空间名称。这个示例使用 bmaas
  5. 运行以下命令,将 edit 角色分配给 bmaas 命名空间中的 BMaaS bmadmin 用户:

    $ oc adm policy add-role-to-user edit <username> -n bmaas
    Copy to Clipboard Toggle word wrap
  6. 运行以下命令克隆 baremetal-operator 存储库,以获取基于角色的访问控制(RBAC)角色定义:

    $ git clone -b release-4.19 https://github.com/openshift/baremetal-operator.git
    Copy to Clipboard Toggle word wrap
  7. 对于您要添加的每个角色,运行以下命令来从存储库应用适当的 RBAC 角色 YAML 文件:

    $ oc apply -f baremetal-operator/config/base/rbac/<role_filename>.yaml
    Copy to Clipboard Toggle word wrap
  8. 运行以下命令,将自定义 RBAC 角色分配给 bmaas 命名空间中的 BMaaS bmadmin 用户:

    $ oc adm policy add-role-to-user <role_name> bmadmin -n bmaas
    Copy to Clipboard Toggle word wrap
  9. 运行以下命令,以 bmadmin 用户身份登录:

    $ oc login <api_server_url>:6443
    Copy to Clipboard Toggle word wrap
    <api_server_url>
    Kubernetes API 的 URL。

6.4. 创建 BMC secret

要部署裸机主机,您必须创建一个 secret 来访问基板管理控制器(BMC)。

流程

  1. 运行以下命令来创建 BMC secret 文件:

    $ vim bmaas-<name>-bmc-secret.yaml
    Copy to Clipboard Toggle word wrap

    <name> 替换为裸机主机的名称。

  2. 编辑 secret:

    apiVersion: v1
    kind: Secret
    metadata:
      name: bmaas-<name>-bmc-secret
      namespace: bmaas
    type: Opaque
    data:
      username: <base64_of_uid>
      password: <base64_of_pwd>
    Copy to Clipboard Toggle word wrap
    <base64_of_uid>
    <base64_of_uid> 替换为 BMC 用户名作为 Base64 编码的字符串。
    <base64_of_pwd>
    <base64_of_pwd> 替换为 BMC 密码作为 Base64 编码的字符串。
  3. 运行以下命令来应用 BMC secret:

    $ oc apply -f bmaas-<name>-bmc-secret.yaml
    Copy to Clipboard Toggle word wrap

6.5. 创建裸机主机资源

要部署裸机主机,您必须创建一个 BareMetalHost 资源。

流程

  1. 运行以下命令来创建 BareMetalHost 自定义资源(CR)文件:

    $ vim bmaas-<name>-bmh.yaml
    Copy to Clipboard Toggle word wrap
    <name>
    <name> 替换为裸机主机的名称。
  2. 编辑 CR:

    apiVersion: metal3.io/v1alpha1
    kind: BareMetalHost
    metadata:
      name: bmaas-<name>
      namespace:  bmaas
    spec:
      online: true
      bootMACAddress: <mac_addr>
      bmc:
        address: redfish-virtualmedia+<address>/redfish/v1/Systems/System.Embedded.1
        credentialsName: bmaas-<num>-bmc-secret
    Copy to Clipboard Toggle word wrap
    <mac_addr>
    <mac_addr> 替换为裸机主机上第一个 NIC 的 MAC 地址。
    <address>
    <address> 替换为主机的 IP 地址或 FQDN。
  3. 运行以下命令来应用 CR:

    $ oc apply -f bmaas-<name>-bmh.yaml
    Copy to Clipboard Toggle word wrap

验证

  • 运行以下命令检查 BareMetalHost 状态:

    $ oc get baremetalhost -n bmaas
    Copy to Clipboard Toggle word wrap

    状态的过程是从 registeringinspecting,最终变为 available

6.6. 为 BMaaS 主机配置用户

配置裸机主机用户,并将它们添加到 Kubernetes secret 中。然后,创建并应用机密以自定义主机。

流程

  1. 创建名为 <hostname>-user-data.yaml 的文件,其内容如下:

    users:
      - name: <name>
        sudo: [<sudo_config>]
        ssh_authorized_keys:
          - <key_type>
          <key>
        shell: <shell_path>
        groups: [<groups>]
        lock_passwd: true|false
    Copy to Clipboard Toggle word wrap
    <hostname>
    裸机主机的名称。
    <name>
    用户名。
    <sudo_config>
    用户的 sudo 配置。
    <key_type>
    SSH 密钥类型。
    <key>
    <name> 用户身份访问此主机时使用的公共 SSH 密钥。
    <shell_path>
    访问主机时要使用的 shell。
    <groups>
    用户所属的组。
    lock_passwd

    是否锁定用户密码。如果为 true,用户无法使用密码登录,但仍然可以使用 SSH 登录。

    示例用户

    users:
      - name: sysadmin
        sudo: ["ALL=(ALL) NOPASSWD:ALL"]
        ssh_authorized_keys:
          - ssh-rsa AAAAB3NzaC1yc2E... sysadmin@workstation.example.com
        shell: /bin/bash
        groups: [adm, sudo]
        lock_passwd: true
    Copy to Clipboard Toggle word wrap

  2. 运行以下命令,从 <hostname>-user-data.yaml 文件创建一个 secret:

    $ oc create secret generic <hostname>-user-data \
      --from-file=userData=<hostname>-user-data.yaml -n bmaas
    Copy to Clipboard Toggle word wrap
    <hostname>
    裸机主机的名称。
  3. 运行以下命令,将 BareMetalHost 配置为使用 <hostname>-user-data.yaml 文件:

    $ oc patch baremetalhost <hostname> -n bmaas \
         --type merge -p '{"spec":{"userData":{"name":"<hostname>-user-data"}}}'
    Copy to Clipboard Toggle word wrap
    <hostname>
    裸机主机的名称。

6.7. 在 BareMetalHost 资源中配置 networkData 参数

BareMetalHost 自定义资源(CR)中的 networkData 字段允许您在创建时控制裸机主机的网络配置。对于大多数操作系统,这通过使用封装在 Kubernetes secret 中的配置文件来实现。然后,cloud-init 服务使用它来自定义服务。

流程

  1. 使用以下内容创建一个名为 network-data.yaml 的文件:

    links:
      - id: <interface_id>
        type: phy
        ethernet_mac_address: <mac_address>
    networks:
      - id: <interface_id>
        link: <interface_id>
        type: ipv4_dhcp
    services:
      - type: dns
        address: <dns_server>
    Copy to Clipboard Toggle word wrap
    <interface_id>
    网络接口的 ID,如 enp2s0
    <mac_address>
    网络接口的 MAC 地址。
    <dns_server>
    DNS 服务器的 IP 地址。
  2. 运行以下命令,从 networkData 文件创建 secret:

    $ oc create secret generic <hostname>-network-data \
      --from-file=networkData=network-data.yaml -n bmaas
    Copy to Clipboard Toggle word wrap
    <hostname>
    裸机主机的主机名。
  3. 运行以下命令,将 BareMetalHost 配置为使用 networkData 文件:

    $ oc patch baremetalhost <hostname> -n bmaas \
      --type merge -p '{"spec":{"networkData":{"name":"<hostname>-network-data"}}}'
    Copy to Clipboard Toggle word wrap

6.8. 将镜像部署到裸机主机

要将镜像部署到主机,请更新 BareMetalHost 资源的 spec 部分中的 image 字段。更新 image 字段后,置备会立即开始。

流程

  • 运行以下命令,更新 BareMetalHost CR 中的 image 字段:

    $ oc patch baremetalhost <hostname> \
      --type merge -p '{"spec": {"image": {"url": "<image_url>", "checksum": "<checksum_url>", "checksumType": "auto"}}}'
    Copy to Clipboard Toggle word wrap
    <hostname>
    BareMetalHost 资源的名称。
    <image_url>
    要部署的镜像的 URL。
    <checksum_url>
    镜像的校验和文件的 URL。

Legal Notice

Copyright © 2025 Red Hat

OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).

Modified versions must remove all Red Hat trademarks.

Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.

Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

Theme

© 2025 Red Hat