×

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

自定义 OpenShift Container Platform 网络时,必须在安装期间设置大部分网络配置参数。只能在运行的集群中修改kubeProxy网络配置参数。

先决条件

OpenShift Container Platform 的互联网访问

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

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

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

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

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

如果您的集群无法直接访问互联网,您可以在您配置的某些类型的基础设施上执行受限网络安装。在此过程中,您将下载所需的内容并使用它来填充包含安装包的镜像注册表。对于某些安装类型,安装集群的环境将不需要互联网访问。在更新集群之前,请更新镜像注册表的内容。

其他资源

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

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

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

集群安装所需的机器

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

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

一台临时引导机器

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

三台控制平面机器

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

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

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

作为例外,您可以在仅包含三台控制平面机器的裸机集群中运行零台计算机器。这为集群管理员和开发人员提供了更小、更高效的集群,可用于测试、开发和生产。不支持运行一台计算机器。

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

引导和控制平面机器必须使用 Red Hat Enterprise Linux CoreOS (RHCOS) 作为操作系统。但是,计算机器可以在 Red Hat Enterprise Linux CoreOS (RHCOS)、Red Hat Enterprise Linux (RHEL) 8.6 及更高版本之间进行选择。

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

集群安装的最低资源要求

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

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

引导

RHCOS

4

16 GB

100 GB

300

控制平面

RHCOS

4

16 GB

100 GB

300

计算

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

2

8 GB

100 GB

300

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

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

  3. 与所有用户配置的安装一样,如果您选择在集群中使用 RHEL 计算机器,则您将负责所有操作系统生命周期管理和维护,包括执行系统更新、应用补丁和完成所有其他必需的任务。RHEL 7 计算机器的使用已弃用,并在 OpenShift Container Platform 4.10 及更高版本中已移除。

从 OpenShift Container Platform 4.13 版本开始,RHCOS 基于 RHEL 9.2 版本,更新了微架构要求。以下列表包含每种架构所需的最低指令集架构 (ISA):

  • x86-64 架构需要 x86-64-v2 ISA

  • ARM64 架构需要 ARMv8.0-A ISA

  • IBM Power 架构需要 Power 9 ISA

  • s390x 架构需要 z14 ISA

更多信息,请参阅RHEL 架构

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

其他资源

证书签名请求管理

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

其他资源

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

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

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

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

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

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

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

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

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

网络连接要求

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

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

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

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

ICMP

N/A

网络可达性测试

TCP

1936

指标

9000-9999

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

10250-10259

Kubernetes 保留的默认端口

UDP

4789

VXLAN

6081

Geneve

9000-9999

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

500

IPsec IKE 数据包

4500

IPsec NAT-T 数据包

123

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

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

TCP/UDP

30000-32767

Kubernetes 节点端口

ESP

N/A

IPsec 封装安全有效载荷 (ESP)

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

TCP

6443

Kubernetes API

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

TCP

2379-2380

etcd 服务器和对等端口

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

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

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

用户预配 DNS 要求

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

  • Kubernetes API

  • OpenShift Container Platform 应用程序通配符

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

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

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

建议使用 DHCP 服务器向每个集群节点提供主机名。有关更多信息,请参见用户预配基础设施的 DHCP 建议部分。

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

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

Kubernetes API

api.<cluster_name>.<base_domain>.

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

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

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

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

路由

*.apps.<cluster_name>.<base_domain>.

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

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

引导程序机器

bootstrap.<cluster_name>.<base_domain>.

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

控制平面机器

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

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

计算机器

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

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

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

您可以使用dig命令验证名称和反向名称解析。有关详细的验证步骤,请参阅为用户自备基础设施验证 DNS 解析部分。

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

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

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

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

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

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

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

4 提供引导机器的名称解析。
5 提供控制平面机器的名称解析。
6 提供计算机器的名称解析。
用户自备集群的示例 DNS PTR 记录配置

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

反向记录的示例 DNS 区域数据库
$TTL 1W
@	IN	SOA	ns1.example.com.	root (
			2019070700	; serial
			3H		; refresh (3 hours)
			30M		; retry (30 minutes)
			2W		; expiry (2 weeks)
			1W )		; minimum (1 week)
	IN	NS	ns1.example.com.
;
5.1.168.192.in-addr.arpa.	IN	PTR	api.ocp4.example.com. (1)
5.1.168.192.in-addr.arpa.	IN	PTR	api-int.ocp4.example.com. (2)
;
96.1.168.192.in-addr.arpa.	IN	PTR	bootstrap.ocp4.example.com. (3)
;
97.1.168.192.in-addr.arpa.	IN	PTR	control-plane0.ocp4.example.com. (4)
98.1.168.192.in-addr.arpa.	IN	PTR	control-plane1.ocp4.example.com. (4)
99.1.168.192.in-addr.arpa.	IN	PTR	control-plane2.ocp4.example.com. (4)
;
11.1.168.192.in-addr.arpa.	IN	PTR	compute0.ocp4.example.com. (5)
7.1.168.192.in-addr.arpa.	IN	PTR	compute1.ocp4.example.com. (5)
;
;EOF
1 提供 Kubernetes API 的反向 DNS 解析。PTR 记录指向 API 负载均衡器的记录名称。
2 提供 Kubernetes API 的反向 DNS 解析。PTR 记录指向 API 负载均衡器的记录名称,并用于内部集群通信。
3 提供引导机器的反向 DNS 解析。
4 提供控制平面机器的反向 DNS 解析。
5 提供计算机器的反向 DNS 解析。

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

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

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

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

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

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

    • 仅限第 4 层负载均衡。这可以称为原始 TCP 或 SSL 直通模式。

    • 无状态负载均衡算法。选项因负载均衡器实现而异。

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

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

    表 7. API 负载均衡器
    端口 后端机器(池成员) 内部 外部 描述

    6443

    引导程序和控制平面。引导程序机器初始化集群控制平面后,您可以从负载均衡器中移除引导程序机器。您必须为 API 服务器运行状况检查探针配置/readyz端点。

    X

    X

    Kubernetes API 服务器

    22623

    引导程序和控制平面。引导程序机器初始化集群控制平面后,您可以从负载均衡器中移除引导程序机器。

    X

    机器配置服务器

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

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

    配置以下条件

    • 仅限第 4 层负载均衡。这可以称为原始 TCP 或 SSL 直通模式。

    • 建议使用基于连接或基于会话的持久性,具体取决于可用的选项和将在平台上托管的应用程序类型。

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

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

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

    443

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

    X

    X

    HTTPS 流量

    80

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

    X

    X

    HTTP 流量

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

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

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

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

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

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

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

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

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

作为使用 `configure-ovs.sh` shell 脚本在裸机平台上设置自定义 `br-ex` 桥接的替代方案,您可以创建一个包含自定义 `br-ex` 桥接网络配置的 `MachineConfig` 对象。

创建包含自定义 `br-ex` 桥接的 `MachineConfig` 对象只是一个技术预览功能。技术预览功能不受 Red Hat 生产服务级别协议 (SLA) 的支持,并且可能功能不完整。Red Hat 不建议在生产环境中使用它们。这些功能可让您抢先体验即将推出的产品功能,从而能够在开发过程中测试功能并提供反馈。

有关 Red Hat 技术预览功能的支持范围的更多信息,请参阅 技术预览功能支持范围

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

  • 您希望对桥接进行安装后更改,例如更改 Open vSwitch (OVS) 或 OVN-Kubernetes `br-ex` 桥接网络。`configure-ovs.sh` shell 脚本不支持对桥接进行安装后更改。

  • 您希望在主机或服务器 IP 地址上可用接口之外的另一个接口上部署桥接。

  • 您希望对桥接进行 `configure-ovs.sh` shell 脚本无法实现的高级配置。对于这些配置使用该脚本可能会导致桥接无法连接多个网络接口并促进接口之间的数据转发。

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

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

先决条件
  • 可选:您已安装 `nmstate` API,以便您可以验证 NMState 配置。

步骤
  1. 创建一个 NMState 配置文件,其中包含您自定义 `br-ex` 桥接网络的已解码 base64 信息

    自定义 `br-ex` 桥接网络的 NMState 配置示例
    interfaces:
    - name: enp2s0 (1)
      type: ethernet (2)
      state: up (3)
      ipv4:
        enabled: false (4)
      ipv6:
        enabled: false
    - name: br-ex
      type: ovs-bridge
      state: up
      ipv4:
        enabled: false
        dhcp: false
      ipv6:
        enabled: false
        dhcp: false
      bridge:
        port:
        - name: enp2s0 (5)
        - name: br-ex
    - name: br-ex
      type: ovs-interface
      state: up
      copy-mac-from: enp2s0
      ipv4:
        enabled: true
        dhcp: true
      ipv6:
        enabled: false
        dhcp: false
    # ...
    1 接口的名称。
    2 以太网类型。
    3 创建后接口的请求状态。
    4 在此示例中禁用 IPv4 和 IPv6。
    5 桥接连接到的节点 NIC。
  2. 使用 `cat` 命令对 NMState 配置的内容进行 base64 编码

    $ cat <nmstate_configuration>.yaml | base64 (1)
    1 将 `<nmstate_configuration>` 替换为您的 NMState 资源 YAML 文件的名称。
  3. 创建一个 `MachineConfig` 清单文件并定义类似于以下示例的自定义 `br-ex` 桥接网络配置

    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: worker (1)
      name: 10-br-ex-worker (2)
    spec:
      config:
        ignition:
          version: 3.2.0
        storage:
          files:
          - contents:
              source: data:text/plain;charset=utf-8;base64,<base64_encoded_nmstate_configuration> (3)
            mode: 0644
            overwrite: true
            path: /etc/nmstate/openshift/cluster.yml
    # ...
    1 为集群中的每个节点指定节点的主机名路径和机器类型的 base-64 编码的 Ignition 配置文件数据。如果您在 ` /etc/nmstate/openshift/cluster.yml` 配置文件中指定了一个要应用于集群中所有节点的单个全局配置,则无需为每个节点指定主机名路径。`worker` 角色是集群中节点的默认角色。在 `MachineConfig` 清单文件中为每个节点或所有节点指定主机名路径时,`.yaml` 扩展名不起作用。
    2 策略的名称。
    3 将编码的 base64 信息写入指定路径。

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

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

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

先决条件
  • 您创建了一个包含自定义 `br-ex` 桥接配置的 `MachineConfig` 清单对象。

步骤
  1. 通过输入以下命令编辑 `MachineConfig` CR

    $ oc edit mc <machineconfig_custom_resource_name>
  2. 将每个计算节点配置添加到 CR,以便 CR 可以管理集群中每个已定义计算节点的角色。

  3. 创建一个名为 `extraworker-secret` 的 `Secret` 对象,该对象具有最小的静态 IP 配置。

  4. 通过输入以下命令将 `extraworker-secret` 密钥应用于集群中的每个节点。此步骤为每个计算节点提供对 Ignition 配置文件的访问权限。

    $ oc apply -f ./extraworker-secret.yaml
  5. 创建一个 `BareMetalHost` 资源并在 `preprovisioningNetworkDataName` 参数中指定网络密钥

    带有附加网络密钥的 `BareMetalHost` 资源示例
    apiVersion: metal3.io/v1alpha1
    kind: BareMetalHost
    spec:
    # ...
      preprovisioningNetworkDataName: ostest-extraworker-0-network-config-secret
    # ...
  6. 要在集群的 `openshift-machine-api` 命名空间内管理 `BareMetalHost` 对象,请通过输入以下命令更改到该命名空间

    $ oc project openshift-machine-api
  7. 获取机器集

    $ oc get machinesets
  8. 通过输入以下命令来扩展每个机器集。必须为每个机器集运行此命令。

    $ oc scale machineset <machineset_name> --replicas=<n> (1)
    1 其中 `<machineset_name>` 是机器集的名称,`<n>` 是计算节点的数量。

准备用户配置的基础架构

在用户配置的基础架构上安装 OpenShift Container Platform 之前,必须准备基础架构。

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

准备之后,集群基础架构必须满足“用户配置的基础架构集群要求”部分中概述的要求。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  5. 验证您的 DNS 配置。

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

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

      有关详细的 DNS 验证步骤,请参阅用户预配基础设施的 DNS 解析验证部分。

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

某些负载均衡解决方案要求在初始化负载均衡之前,集群节点的 DNS 名称解析已就绪。

验证用户预配基础设施的 DNS 解析

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

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

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

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

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

      $ dig +noall +answer @<nameserver_ip> api.<cluster_name>.<base_domain> (1)
      1 <nameserver_ip>替换为名称服务器的 IP 地址,将<cluster_name>替换为您的集群名称,并将<base_domain>替换为您的基础域名。
      示例输出
      api.ocp4.example.com.		604800	IN	A	192.168.1.5
    2. 对 Kubernetes 内部 API 记录名称执行查找。检查结果是否指向 API 负载均衡器的 IP 地址。

      $ dig +noall +answer @<nameserver_ip> api-int.<cluster_name>.<base_domain>
      示例输出
      api-int.ocp4.example.com.		604800	IN	A	192.168.1.5
    3. 测试示例*.apps.<cluster_name>.<base_domain> DNS 通配符查找。所有应用程序通配符查找都必须解析到应用程序入口负载均衡器的 IP 地址。

      $ dig +noall +answer @<nameserver_ip> random.apps.<cluster_name>.<base_domain>
      示例输出
      random.apps.ocp4.example.com.		604800	IN	A	192.168.1.5

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

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

      $ dig +noall +answer @<nameserver_ip> console-openshift-console.apps.<cluster_name>.<base_domain>
      示例输出
      console-openshift-console.apps.ocp4.example.com. 604800 IN	A 192.168.1.5
    4. 对引导 DNS 记录名称运行查找。检查结果是否指向引导节点的 IP 地址。

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

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

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

      $ dig +noall +answer @<nameserver_ip> -x 192.168.1.5
      示例输出
      5.1.168.192.in-addr.arpa. 604800	IN	PTR	api-int.ocp4.example.com. (1)
      5.1.168.192.in-addr.arpa. 604800	IN	PTR	api.ocp4.example.com. (2)
      
      1 提供 Kubernetes 内部 API 的记录名称。
      2 提供 Kubernetes API 的记录名称。

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

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

      $ dig +noall +answer @<nameserver_ip> -x 192.168.1.96
      示例输出
      96.1.168.192.in-addr.arpa. 604800	IN	PTR	bootstrap.ocp4.example.com.
    3. 使用此方法对控制平面和计算节点的 IP 地址执行反向查找。检查结果是否与每个节点的 DNS 记录名称相对应。

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

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

密钥传递到节点后,您可以使用密钥对以用户core身份通过 SSH 登录到 RHCOS 节点。要通过 SSH 访问节点,必须由您的本地用户的 SSH 管理私钥标识。

如果您想通过 SSH 登录到您的集群节点以执行安装调试或灾难恢复,则必须在安装过程中提供 SSH 公钥。./openshift-install gather命令也要求集群节点上存在 SSH 公钥。

在需要灾难恢复和调试的生产环境中,请勿跳过此过程。

您必须使用本地密钥,而不是使用平台特定方法(例如AWS 密钥对)配置的密钥。

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

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

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

  2. 查看公钥 SSH 密钥

    $ cat <path>/<file_name>.pub

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

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

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

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

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

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

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

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

获取安装程序

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

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

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

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

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

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

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

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

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

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

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

安装 OpenShift CLI

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

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

在 Linux 上安装 OpenShift CLI

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

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

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

  3. 版本下拉列表中选择合适的版本。

  4. 单击OpenShift v4.17 Linux 客户端条目旁边的立即下载,然后保存文件。

  5. 解压归档文件。

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

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

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

    $ oc <command>

在 Windows 上安装 OpenShift CLI

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

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

  2. 版本下拉列表中选择合适的版本。

  3. 单击OpenShift v4.17 Windows 客户端条目旁边的立即下载,然后保存文件。

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

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

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

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

    C:\> oc <command>

在 macOS 上安装 OpenShift CLI

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

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

  2. 版本下拉列表中选择合适的版本。

  3. 单击OpenShift v4.17 macOS 客户端条目旁边的立即下载,然后保存文件。

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

  4. 解压归档文件。

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

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

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

    $ oc <command>

手动创建安装配置文件

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

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

  • 您已获得 OpenShift Container Platform 安装程序和集群的拉取密钥。

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

    $ mkdir <installation_directory>

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

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

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

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

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

裸机示例 install-config.yaml 文件

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

apiVersion: v1
baseDomain: example.com (1)
compute: (2)
- hyperthreading: Enabled (3)
  name: worker
  replicas: 0 (4)
controlPlane: (2)
  hyperthreading: Enabled (3)
  name: master
  replicas: 3 (5)
metadata:
  name: test (6)
networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14 (7)
    hostPrefix: 23 (8)
  networkType: OVNKubernetes (9)
  serviceNetwork: (10)
  - 172.30.0.0/16
platform:
  none: {} (11)
fips: false (12)
pullSecret: '{"auths": ...}' (13)
sshKey: 'ssh-ed25519 AAAA...' (14)
1 集群的基本域。所有 DNS 记录都必须为此基本域的子域,并且包含集群名称。
2 controlPlane 部分是一个单映射,但 compute 部分是一系列映射。为了满足不同数据结构的要求,compute 部分的第一行必须以连字符 - 开头,而 controlPlane 部分的第一行则不能。只使用一个控制平面池。
3 指定是否启用或禁用同时多线程 (SMT) 或超线程。默认情况下,启用 SMT 以提高机器中内核的性能。您可以通过将参数值设置为 Disabled 来禁用它。如果禁用 SMT,则必须在所有集群机器中禁用它;这包括控制平面机器和计算机器。

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

如果您在 BIOS 或 install-config.yaml 文件中禁用了 hyperthreading,请确保您的容量规划考虑了机器性能的显著下降。

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

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

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

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

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

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

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

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

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

13 来自 Red Hat OpenShift 集群管理器的 pull 密钥。此 pull 密钥允许您对包含的权威机构(包括提供 OpenShift Container Platform 组件容器映像的 Quay.io)提供的服务进行身份验证。
14 Red Hat Enterprise Linux CoreOS (RHCOS) 中 core 用户的 SSH 公钥。

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

其他资源

网络配置阶段

在 OpenShift Container Platform 安装之前,有两个阶段可以自定义网络配置。

阶段 1

您可以在创建清单文件之前自定义 install-config.yaml 文件中的以下与网络相关的字段

  • networking.networkType

  • networking.clusterNetwork

  • networking.serviceNetwork

  • networking.machineNetwork

    有关更多信息,请参阅“安装配置参数”。

    networking.machineNetwork 设置为与首选子网所在的无类域间路由 (CIDR) 匹配。

    CIDR 范围 172.17.0.0/16libVirt 保留。您不能对集群中的网络使用任何其他与 172.17.0.0/16 CIDR 范围重叠的 CIDR 范围。

阶段 2

在通过运行 openshift-install create manifests 创建清单文件后,您可以仅使用要修改的字段定义自定义集群网络运算符清单。您可以使用清单来指定高级网络配置。

在阶段 2 中,您不能覆盖在阶段 1 中在 install-config.yaml 文件中指定的值。但是,您可以在阶段 2 中自定义网络插件。

指定高级网络配置

您可以使用网络插件的高级网络配置将您的集群集成到您的现有网络环境中。

您只能在安装集群之前指定高级网络配置。

不支持通过修改安装程序创建的 OpenShift Container Platform 清单文件来自定义网络配置。支持应用您创建的清单文件,如下所示。

先决条件
  • 您已创建 install-config.yaml 文件并完成了对其的任何修改。

步骤
  1. 更改到包含安装程序的目录并创建清单

    $ ./openshift-install create manifests --dir <installation_directory> (1)
    1 <installation_directory> 指定包含集群 install-config.yaml 文件的目录的名称。
  2. 为高级网络配置创建存根清单文件,该文件名为 cluster-network-03-config.yml,位于 <installation_directory>/manifests/ 目录中

    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
  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
  4. 可选:备份 manifests/cluster-network-03-config.yml 文件。当您创建 Ignition 配置文件时,安装程序会使用 manifests/ 目录。

集群网络运算符配置

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

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

clusterNetwork

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

serviceNetwork

服务的 IP 地址池。

defaultNetwork.type

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

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

集群网络操作符配置对象

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

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

metadata.name

字符串

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

spec.clusterNetwork

数组

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

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

spec.serviceNetwork

数组

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

spec:
  serviceNetwork:
  - 172.30.0.0/14

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

spec.defaultNetwork

对象

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

spec.kubeProxyConfig

对象

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

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

defaultNetwork 对象配置

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

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

type

字符串

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

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

ovnKubernetesConfig

对象

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

OVN-Kubernetes 网络插件的配置

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

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

mtu

整数

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

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

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

genevePort

整数

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

ipsecConfig

对象

指定一个配置对象来定制 IPsec 配置。

ipv4

对象

指定 IPv4 设置的配置对象。

ipv6

对象

指定 IPv6 设置的配置对象。

policyAuditConfig

对象

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

gatewayConfig

对象

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

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

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

internalTransitSwitchSubnet

字符串

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

默认值为100.88.0.0/16

internalJoinSubnet

字符串

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

默认值为100.64.0.0/16

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

internalTransitSwitchSubnet

字符串

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

默认值为fd97::/64

internalJoinSubnet

字符串

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

默认值为fd98::/64

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

rateLimit

整数

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

maxFileSize

整数

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

maxLogFiles

整数

保留的最大日志文件数。

destination

字符串

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

libc

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

udp:<host>:<port>

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

unix:<file>

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

null

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

syslogFacility

字符串

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

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

routingViaHost

布尔值

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

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

ipForwarding

对象

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

ipv4

对象

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

ipv6

对象

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

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

internalMasqueradeSubnet

字符串

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

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

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

internalMasqueradeSubnet

字符串

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

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

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

mode

字符串

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

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

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

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

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

创建 Ignition 配置文件

因为您必须手动启动集群机器,所以您必须生成集群使其机器所需的 Ignition 配置文件。

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

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

先决条件
  • 获取 OpenShift Container Platform 安装程序和集群的 pull 密钥。

步骤
  • 获取 Ignition 配置文件

    $ ./openshift-install create ignition-configs --dir <installation_directory> (1)
    1 对于<installation_directory>,指定用于存储安装程序创建文件的目录名称。

    如果您创建了install-config.yaml文件,请指定包含它的目录。否则,指定一个空目录。某些安装资源(如 bootstrap X.509 证书)具有较短的过期时间间隔,因此您不能重用安装目录。如果您想重用来自另一个集群安装的单个文件,您可以将它们复制到您的目录中。但是,安装资源的文件名可能会在发行版之间发生更改。从早期 OpenShift Container Platform 版本复制安装文件时,请谨慎操作。

    在目录中生成以下文件

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

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

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

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

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

您可以通过以下方法在 ISO 和 PXE 安装期间配置 RHCOS

  • 内核参数:您可以使用内核参数提供安装特定的信息。例如,您可以指定已上传到 HTTP 服务器的 RHCOS 安装文件的位置以及您正在安装的节点类型的 Ignition 配置文件的位置。对于 PXE 安装,您可以使用 `APPEND` 参数将参数传递到实时安装程序的内核。对于 ISO 安装,您可以中断实时安装引导过程以添加内核参数。在这两种安装情况下,您可以使用特殊的 `coreos.inst.*` 参数来引导实时安装程序,以及用于启用或禁用标准内核服务的标准安装引导参数。

  • Ignition 配置:OpenShift Container Platform Ignition 配置文件(`*.ign`)特定于您正在安装的节点类型。您在 RHCOS 安装期间传递引导程序、控制平面或计算节点 Ignition 配置文件的位置,以便它在第一次启动时生效。在特殊情况下,您可以创建一个单独的、有限的 Ignition 配置文件传递到实时系统。该 Ignition 配置文件可以执行某些任务,例如在完成安装后向配置系统报告成功。此特殊的 Ignition 配置文件由 `coreos-installer` 使用,并在安装系统的首次启动时应用。请勿直接向实时 ISO 提供标准的控制平面和计算节点 Ignition 配置文件。

  • `coreos-installer`:您可以将实时 ISO 安装程序引导到 shell 提示符,这允许您在首次启动之前以各种方式准备永久系统。特别是,您可以运行 `coreos-installer` 命令来识别要包含的各种工件、处理磁盘分区以及设置网络。在某些情况下,您可以配置实时系统上的功能并将它们复制到已安装的系统。

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

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

使用 ISO 镜像安装 RHCOS

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

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

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

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

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

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

    $ sha512sum <installation_directory>/bootstrap.ign

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

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

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

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

    $ curl -k http://<HTTP_server>/bootstrap.ign (1)
    示例输出
      % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                     Dload  Upload   Total   Spent    Left  Speed
      0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0{"ignition":{"version":"3.2.0"},"passwd":{"users":[{"name":"core","sshAuthorizedKeys":["ssh-rsa...

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

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

    $ openshift-install coreos print-stream-json | grep '\.iso[^.]'
    示例输出
    "location": "<url>/art/storage/releases/rhcos-4.17-aarch64/<release>/aarch64/rhcos-<release>-live.aarch64.iso",
    "location": "<url>/art/storage/releases/rhcos-4.17-ppc64le/<release>/ppc64le/rhcos-<release>-live.ppc64le.iso",
    "location": "<url>/art/storage/releases/rhcos-4.17-s390x/<release>/s390x/rhcos-<release>-live.s390x.iso",
    "location": "<url>/art/storage/releases/rhcos-4.17/<release>/x86_64/rhcos-<release>-live.x86_64.iso",

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

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

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

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

    • 将 ISO 镜像刻录到磁盘并直接引导。

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

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

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

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

    $ sudo coreos-installer install --ignition-url=http://<HTTP_server>/<node_type>.ign <device> --ignition-hash=sha512-<digest> (1) (2)
    1 您必须使用 `sudo` 运行 `coreos-installer` 命令,因为 `core` 用户没有执行安装所需的 root 权限。
    2 `--ignition-hash` 选项在通过 HTTP URL 获取 Ignition 配置文件时是必需的,用于验证集群节点上 Ignition 配置文件的真实性。`` 是在前面步骤中获得的 Ignition 配置文件的 SHA512 散列值。

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

    以下示例将引导节点安装初始化到 `/dev/sda` 设备。引导节点的 Ignition 配置文件是从 IP 地址为 192.168.1.2 的 HTTP Web 服务器获取的。

    $ sudo coreos-installer install --ignition-url=http://192.168.1.2:80/installation_directory/bootstrap.ign /dev/sda --ignition-hash=sha512-a5a2d43879223273c9b60af66b44202a1d1248fc01cf156c46d4a79f552b6bad47bc8cc78ddf0116e80c59d2ea9e32ba53bc807afbca581aa059311def2c3e3b
  8. 监控机器控制台上 RHCOS 安装的进度。

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

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

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

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

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

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

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

使用PXE或iPXE启动安装RHCOS

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

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

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

  • 您已配置合适的PXE或iPXE基础设施。

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

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

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

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

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

    $ curl -k http://<HTTP_server>/bootstrap.ign (1)
    示例输出
      % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                     Dload  Upload   Total   Spent    Left  Speed
      0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0{"ignition":{"version":"3.2.0"},"passwd":{"users":[{"name":"core","sshAuthorizedKeys":["ssh-rsa...

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

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

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

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

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

    • 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)
      1 指定您上传到HTTP服务器的实时kernel文件的位置。URL必须是HTTP、TFTP或FTP;不支持HTTPS和NFS。
      2 如果您使用多个网卡,请在ip选项中指定单个接口。例如,要在名为eno1的网卡上使用DHCP,请设置ip=eno1:dhcp
      3 指定您上传到HTTP服务器的RHCOS文件的位置。initrd参数值是initramfs文件的位置,coreos.live.rootfs_url参数值是rootfs文件的位置,coreos.inst.ignition_url参数值是引导Ignition配置文件的位置。您还可以向APPEND行添加更多内核参数来配置网络或其他引导选项。

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

    • 对于iPXE (x86_64 + aarch64)

      kernel http://<HTTP_server>/rhcos-<version>-live-kernel-<architecture> initrd=main coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/bootstrap.ign (1) (2)
      initrd --name main http://<HTTP_server>/rhcos-<version>-live-initramfs.<architecture>.img (3)
      boot
      1 指定您上传到HTTP服务器的RHCOS文件的位置。kernel参数值是kernel文件的位置,initrd=main参数对于在UEFI系统上启动是必需的,coreos.live.rootfs_url参数值是rootfs文件的位置,coreos.inst.ignition_url参数值是引导Ignition配置文件的位置。
      2 如果您使用多个网卡,请在ip选项中指定单个接口。例如,要在名为eno1的网卡上使用DHCP,请设置ip=eno1:dhcp
      3 指定您上传到HTTP服务器的initramfs文件的位置。

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

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

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

      menuentry 'Install CoreOS' {
          linux rhcos-<version>-live-kernel-<architecture>  coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/bootstrap.ign (1) (2)
          initrd rhcos-<version>-live-initramfs.<architecture>.img (3)
      }
      1 指定您上传到HTTP/TFTP服务器的RHCOS文件的位置。kernel参数值是您TFTP服务器上kernel文件的位置。coreos.live.rootfs_url参数值是rootfs文件的位置,coreos.inst.ignition_url参数值是您HTTP服务器上引导Ignition配置文件的位置。
      2 如果您使用多个网卡,请在ip选项中指定单个接口。例如,要在名为eno1的网卡上使用DHCP,请设置ip=eno1:dhcp
      3 指定您上传到TFTP服务器的initramfs文件的位置。
  7. 监控机器控制台上 RHCOS 安装的进度。

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

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

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

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

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

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

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

高级RHCOS安装配置

手动配置OpenShift Container Platform的Red Hat Enterprise Linux CoreOS (RHCOS)节点的一个主要好处是可以进行默认OpenShift Container Platform安装方法无法提供的配置。本节介绍您可以使用的一些配置,这些配置使用的方法包括

  • 向实时安装程序传递内核参数

  • 从实时系统手动运行coreos-installer

  • 自定义实时ISO映像或PXE引导映像

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

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

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

  • 启动实时安装程序时传递特殊的内核参数。

  • 使用机器配置将网络文件复制到已安装的系统。

  • 从实时安装程序的 shell 提示符配置网络,然后将这些设置复制到已安装的系统,以便在已安装的系统第一次启动时生效。

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

  • 请参阅“高级 RHCOS 安装参考”表。

  • 使用机器配置将网络文件复制到已安装的系统。

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

步骤
  1. 启动 ISO 安装程序。

  2. 在实时系统 shell 提示符下,使用可用的 RHEL 工具(例如nmclinmtui)配置实时系统的网络。

  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-network选项仅复制位于/etc/NetworkManager/system-connections下的网络配置。特别是,它不会复制系统主机名。

  4. 重新启动进入已安装的系统。

其他资源

磁盘分区

在 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目录,并将根文件系统监控为nodefs目录。

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

创建单独的/var分区

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

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

  • /var/lib/containers:保存与容器相关的內容,随着向系统添加更多镜像和容器,它可能会增长。

  • /var/lib/etcd:保存您可能出于性能优化 etcd 存储等目的而希望单独保存的数据。

  • /var:保存您可能出于审计等目的而希望单独保存的数据。

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

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

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

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

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

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

    variant: openshift
    version: 4.17.0
    metadata:
      labels:
        machineconfiguration.openshift.io/role: worker
      name: 98-var-partition
    storage:
      disks:
      - device: /dev/disk/by-id/<device_name> (1)
        partitions:
        - label: var
          start_mib: <partition_start_offset> (2)
          size_mib: <partition_size> (3)
          number: 5
      filesystems:
        - device: /dev/disk/by-partlabel/var
          path: /var
          format: xfs
          mount_options: [defaults, prjquota] (4)
          with_mount_unit: true
    1 您要分区的磁盘的存储设备名称。
    2 向引导磁盘添加数据分区时,建议最小偏移值为 25000 MiB。根文件系统将自动调整大小以填充所有可用空间,直至指定的偏移量。如果未指定偏移值,或指定的偏移值小于建议的最小值,则生成的根文件系统将太小,并且以后重新安装 RHCOS 可能会覆盖数据分区的开头。
    3 数据分区的大小(以 MiB 为单位)。
    4 必须为用于容器存储的文件系统启用prjquota挂载选项。

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

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

    $ butane $HOME/clusterconfig/98-var-partition.bu -o $HOME/clusterconfig/openshift/98-var-partition.yaml
  4. 创建 Ignition 配置文件

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

    Ignition 配置文件是在安装目录中为引导程序、控制平面和计算节点创建的。

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

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

后续步骤
  • 您可以在 RHCOS 安装过程中引用 Ignition 配置文件来应用自定义磁盘分区。

保留现有分区

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

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

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

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

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

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

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

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

此示例保留分区 5 及更高版本的分区。

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

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

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

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

coreos.inst.save_partlabel=data*

APPEND 选项保留分区 5 及更高版本的分区。

coreos.inst.save_partindex=5-

APPEND 选项保留分区 6。

coreos.inst.save_partindex=6

识别 Ignition 配置文件

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

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

    不建议直接修改这些 Ignition 配置文件。您可以更新封装到 Ignition 配置文件中的清单文件,如前面部分的示例中所述。

    对于 PXE 安装,您可以使用 coreos.inst.ignition_url= 选项在 APPEND 行上传递 Ignition 配置文件。对于 ISO 安装,在 ISO 启动到 shell 提示符后,您可以使用 --ignition-url= 选项在 coreos-installer 命令行上识别 Ignition 配置文件。在这两种情况下,仅支持 HTTP 和 HTTPS 协议。

  • 实时安装 Ignition 配置文件:此类型可以使用 coreos-installercustomize 子命令及其各种选项创建。使用此方法,Ignition 配置文件将传递到实时安装介质,在启动后立即运行,并在 RHCOS 系统安装到磁盘之前或之后执行设置任务。此方法仅应用于执行必须执行一次且以后不再应用的任务,例如使用无法使用机器配置完成的高级分区。

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

默认控制台配置

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

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

  • 您想访问控制台上的紧急 shell 以进行调试。

  • 您的云平台不提供对图形控制台的交互式访问,但提供串行控制台。

  • 您想启用多个控制台。

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

您可以通过以下方式配置裸机安装的控制台:

  • 在命令行上手动使用 coreos-installer

  • 使用 coreos-installer iso customizecoreos-installer pxe customize 子命令以及 --dest-console 选项来创建自动执行此过程的自定义映像。

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

为 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>
    1 所需的辅助控制台。在本例中,为图形控制台。省略此选项将禁用图形控制台。
    2 所需的主控制台。在本例中为串行控制台。options 字段定义波特率和其他设置。此字段的常见值为 11520n8。如果未提供选项,则使用默认内核值 9600n8。有关此选项格式的更多信息,请参阅 Linux 内核串行控制台 文档。
  3. 重新启动进入已安装的系统。

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

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

自定义实时 RHCOS ISO 或 PXE 安装

您可以使用实时 ISO 映像或 PXE 环境通过将 Ignition 配置文件直接注入映像来安装 RHCOS。这将创建一个自定义映像,您可以使用它来预配您的系统。

对于 ISO 映像,执行此操作的机制是 coreos-installer iso customize 子命令,它使用您的配置修改 .iso 文件。类似地,PXE 环境的机制是 coreos-installer pxe customize 子命令,它创建一个包含自定义内容的新 initramfs 文件。

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

  • 当公司安全策略要求使用时,注入自定义 CA 证书。

  • 配置网络设置,无需内核参数。

  • 嵌入任意预安装和后安装脚本或二进制文件。

自定义 RHCOS Live ISO 镜像

您可以使用 coreos-installer iso customize 子命令直接自定义 RHCOS Live ISO 镜像。启动 ISO 镜像时,自定义项会自动应用。

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

步骤
  1. coreos-installer镜像站点 下载 coreos-installer 二进制文件。

  2. RHCOS镜像站点 获取 RHCOS ISO 镜像和 Ignition 配置文件,然后运行以下命令将 Ignition 配置直接注入 ISO 镜像

    $ coreos-installer iso customize rhcos-<version>-live.x86_64.iso \
        --dest-ignition bootstrap.ign \ (1)
        --dest-device /dev/disk/by-id/scsi-<serial_number> (2)
    
    1 openshift-installer 安装程序生成的 Ignition 配置文件。
    2 指定此选项时,ISO 镜像会自动运行安装程序。否则,镜像仍然配置为安装,但除非您指定 coreos.inst.install_dev 内核参数,否则不会自动安装。
  3. 可选:要删除 ISO 镜像自定义项并将镜像恢复到原始状态,请运行

    $ coreos-installer iso reset rhcos-<version>-live.x86_64.iso

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

应用您的自定义项会影响 RHCOS 的每次后续启动。

修改 Live 安装 ISO 镜像以启用串行控制台

在使用 OpenShift Container Platform 4.12 及更高版本的集群中,串行控制台默认情况下处于禁用状态,所有输出都写入图形控制台。您可以按照以下步骤启用串行控制台。

步骤
  1. coreos-installer镜像站点 下载 coreos-installer 二进制文件。

  2. RHCOS镜像站点 获取 RHCOS ISO 镜像,并运行以下命令自定义 ISO 镜像以启用串行控制台以接收输出

    $ coreos-installer iso customize rhcos-<version>-live.x86_64.iso \
      --dest-ignition <path> \(1)
      --dest-console tty0 \(2)
      --dest-console ttyS0,<options> \(3)
      --dest-device /dev/disk/by-id/scsi-<serial_number> (4)
    1 要安装的 Ignition 配置文件的位置。
    2 所需的辅助控制台。在本例中,为图形控制台。省略此选项将禁用图形控制台。
    3 所需的 primary console。在本例中,为串行控制台。options 字段定义波特率和其他设置。此字段的常用值为 115200n8。如果未提供选项,则使用默认内核值 9600n8。有关此选项格式的更多信息,请参阅 Linux 内核串行控制台 文档。
    4 要安装到的指定磁盘。如果您省略此选项,ISO 镜像将自动运行安装程序,除非您还指定 coreos.inst.install_dev 内核参数,否则安装程序将失败。

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

    您的自定义项已应用,并会影响 ISO 镜像的每次后续启动。

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

    $ coreos-installer iso reset rhcos-<version>-live.x86_64.iso

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

修改 Live 安装 ISO 镜像以使用自定义证书颁发机构

您可以使用 customize 子命令的 --ignition-ca 标志向 Ignition 提供证书颁发机构 (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

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

应用您的自定义 CA 证书会影响 RHCOS 的每次后续启动。

使用自定义网络设置修改 Live 安装 ISO 镜像

您可以将 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
  3. 创建连接配置文件以添加到绑定中的辅助接口。例如,在本地目录中创建 bond0-proxy-em1.nmconnection 文件,内容如下:

    [connection]
    id=em1
    type=ethernet
    interface-name=em1
    master=bond0
    multi-connect=1
    slave-type=bond
  4. 创建连接配置文件以添加到绑定中的辅助接口。例如,在本地目录中创建 bond0-proxy-em2.nmconnection 文件,内容如下:

    [connection]
    id=em2
    type=ethernet
    interface-name=em2
    master=bond0
    multi-connect=1
    slave-type=bond
  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

    网络设置将应用于 Live 系统,并延续到目标系统。

自定义 Live 安装 ISO 镜像以用于 iSCSI 引导设备

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

先决条件
  1. 您有一个要安装 RHCOS 的 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/disk/by-path/<IP_address>:<port>-iscsi-<target_iqn>-lun-<lun> \ (3)
        --dest-ignition config.ign \ (4)
        --dest-karg-append rd.iscsi.initiator=<initiator_iqn> \ (5)
        --dest-karg-append netroot=<target_iqn> \ (6)
        -o custom.iso rhcos-<version>-live.x86_64.iso
    1 安装前运行的脚本。它应包含用于挂载 iSCSI 目标的 iscsiadm 命令以及任何启用多路径的命令。
    2 安装后运行的脚本。它应包含命令 iscsiadm --mode node --logout=all
    3 目标系统的位置。您必须提供目标门户的 IP 地址、关联的端口号、以 IQN 格式表示的 iSCSI 目标节点以及 iSCSI 逻辑单元号 (LUN)。
    4 目标系统的 Ignition 配置。
    5 以 IQN 格式表示的 iSCSI 启动器或客户端名称。启动器形成一个会话以连接到 iSCSI 目标。
    6 以 IQN 格式表示的 iSCSI 目标或服务器名称。

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

使用 iBFT 自定义 Live 安装 ISO 镜像以用于 iSCSI 引导设备

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

先决条件
  1. 您有一个要安装 RHCOS 的 iSCSI 目标。

  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
    1 安装前运行的脚本。它应包含用于挂载 iSCSI 目标的 iscsiadm 命令以及任何启用多路径的命令。
    2 安装后运行的脚本。它应包含命令 iscsiadm --mode node --logout=all
    3 设备的路径。如果您使用多路径,则为多路径设备 /dev/mapper/mpatha,如果连接了多个多路径设备,或者为了明确起见,您可以使用 /dev/disk/by-path 中可用的世界范围名称 (WWN) 符号链接。
    4 目标系统的 Ignition 配置。
    5 iSCSI 参数从 BIOS 固件读取。
    6 可选:如果启用多路径,请包含此参数。

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

自定义 RHCOS PXE 动态环境

您可以使用coreos-installer pxe customize子命令直接自定义 RHCOS PXE 动态环境。启动 PXE 环境时,自定义设置会自动应用。

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

步骤
  1. coreos-installer镜像站点 下载 coreos-installer 二进制文件。

  2. RHCOS 镜像站点检索 RHCOS 的kernelinitramfsrootfs文件以及 Ignition 配置文件,然后运行以下命令创建一个包含 Ignition 配置自定义设置的新initramfs文件

    $ coreos-installer pxe customize rhcos-<version>-live-initramfs.x86_64.img \
        --dest-ignition bootstrap.ign \ (1)
        --dest-device /dev/disk/by-id/scsi-<serial_number> \ (2)
        -o rhcos-<version>-custom-initramfs.x86_64.img (3)
    1 openshift-installer生成的 Ignition 配置文件。
    2 指定此选项后,PXE 环境会自动运行安装程序。否则,映像将保持已配置为安装的状态,但除非您指定coreos.inst.install_dev内核参数,否则不会自动执行安装。
    3 在您的 PXE 配置中使用自定义的initramfs文件。如果不存在,请添加ignition.firstbootignition.platform.id=metal内核参数。

应用您的自定义项会影响 RHCOS 的每次后续启动。

修改 RHCOS 动态安装 PXE 环境以启用串行控制台

在使用 OpenShift Container Platform 4.12 及更高版本的集群中,串行控制台默认情况下处于禁用状态,所有输出都写入图形控制台。您可以按照以下步骤启用串行控制台。

步骤
  1. coreos-installer镜像站点 下载 coreos-installer 二进制文件。

  2. RHCOS 镜像站点检索 RHCOS 的kernelinitramfsrootfs文件以及 Ignition 配置文件,然后运行以下命令创建一个新的自定义initramfs文件,该文件允许串行控制台接收输出

    $ coreos-installer pxe customize rhcos-<version>-live-initramfs.x86_64.img \
      --dest-ignition <path> \(1)
      --dest-console tty0 \(2)
      --dest-console ttyS0,<options> \(3)
      --dest-device /dev/disk/by-id/scsi-<serial_number> \(4)
      -o rhcos-<version>-custom-initramfs.x86_64.img (5)
    1 要安装的 Ignition 配置文件的位置。
    2 所需的辅助控制台。在本例中,为图形控制台。省略此选项将禁用图形控制台。
    3 所需的 primary console。在本例中,为串行控制台。options 字段定义波特率和其他设置。此字段的常用值为 115200n8。如果未提供选项,则使用默认内核值 9600n8。有关此选项格式的更多信息,请参阅 Linux 内核串行控制台 文档。
    4 指定的安装磁盘。如果您省略此选项,PXE 环境将自动运行安装程序,除非您还指定了coreos.inst.install_dev内核参数,否则安装程序将会失败。
    5 在您的 PXE 配置中使用自定义的initramfs文件。如果不存在,请添加ignition.firstbootignition.platform.id=metal内核参数。

    您的自定义设置已应用,并将影响 PXE 环境的每次后续启动。

修改 RHCOS 动态安装 PXE 环境以使用自定义证书颁发机构

您可以使用 customize 子命令的 --ignition-ca 标志向 Ignition 提供证书颁发机构 (CA) 证书。您可以在安装引导期间和配置已安装的系统时使用 CA 证书。

自定义 CA 证书会影响 Ignition 如何获取远程资源,但不会影响安装到系统上的证书。

步骤
  1. coreos-installer镜像站点 下载 coreos-installer 二进制文件。

  2. RHCOS 镜像站点检索 RHCOS 的kernelinitramfsrootfs文件,然后运行以下命令创建一个用于自定义 CA 的新的自定义initramfs文件

    $ coreos-installer pxe customize rhcos-<version>-live-initramfs.x86_64.img \
        --ignition-ca cert.pem \
        -o rhcos-<version>-custom-initramfs.x86_64.img
  3. 在您的 PXE 配置中使用自定义的initramfs文件。如果不存在,请添加ignition.firstbootignition.platform.id=metal内核参数。

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

应用您的自定义 CA 证书会影响 RHCOS 的每次后续启动。

使用自定义网络设置修改 RHCOS 动态安装 PXE 环境

您可以将 NetworkManager 密钥文件嵌入到 RHCOS 动态 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
  3. 创建连接配置文件以添加到绑定中的辅助接口。例如,在本地目录中创建 bond0-proxy-em1.nmconnection 文件,内容如下:

    [connection]
    id=em1
    type=ethernet
    interface-name=em1
    master=bond0
    multi-connect=1
    slave-type=bond
  4. 创建连接配置文件以添加到绑定中的辅助接口。例如,在本地目录中创建 bond0-proxy-em2.nmconnection 文件,内容如下:

    [connection]
    id=em2
    type=ethernet
    interface-name=em2
    master=bond0
    multi-connect=1
    slave-type=bond
  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
  6. 在您的 PXE 配置中使用自定义的initramfs文件。如果不存在,请添加ignition.firstbootignition.platform.id=metal内核参数。

    网络设置将应用于 Live 系统,并延续到目标系统。

为 iSCSI 引导设备自定义 RHCOS 动态安装 PXE 环境

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

先决条件
  1. 您有一个要安装 RHCOS 的 iSCSI 目标。

步骤
  1. coreos-installer镜像站点 下载 coreos-installer 二进制文件。

  2. RHCOS 镜像站点检索 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
    1 安装前运行的脚本。它应包含用于挂载 iSCSI 目标的 iscsiadm 命令以及任何启用多路径的命令。
    2 安装后运行的脚本。它应包含命令 iscsiadm --mode node --logout=all
    3 目标系统的位置。您必须提供目标门户的 IP 地址、关联的端口号、以 IQN 格式表示的 iSCSI 目标节点以及 iSCSI 逻辑单元号 (LUN)。
    4 目标系统的 Ignition 配置。
    5 以 IQN 格式表示的 iSCSI 启动器或客户端名称。启动器形成一个会话以连接到 iSCSI 目标。
    6 以 IQN 格式表示的 iSCSI 目标或服务器名称。

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

使用 iBFT 为 iSCSI 引导设备自定义 RHCOS 动态安装 PXE 环境

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

先决条件
  1. 您有一个要安装 RHCOS 的 iSCSI 目标。

  2. 可选:您已将 iSCSI 目标多路径化。

步骤
  1. coreos-installer镜像站点 下载 coreos-installer 二进制文件。

  2. RHCOS 镜像站点检索 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
    1 安装前运行的脚本。它应包含用于挂载 iSCSI 目标的iscsiadm命令。
    2 安装后运行的脚本。它应包含命令 iscsiadm --mode node --logout=all
    3 设备的路径。如果您使用多路径,则为多路径设备 /dev/mapper/mpatha,如果连接了多个多路径设备,或者为了明确起见,您可以使用 /dev/disk/by-path 中可用的世界范围名称 (WWN) 符号链接。
    4 目标系统的 Ignition 配置。
    5 iSCSI 参数从 BIOS 固件读取。
    6 可选:如果启用多路径,请包含此参数。

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

高级 RHCOS 安装参考

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

ISO 安装的网络和绑定选项

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

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

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

添加内核参数时的顺序很重要:ip=nameserver=,然后是bond=

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

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

配置 DHCP 或静态 IP 地址

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

  • 节点的 IP 地址为10.10.10.2

  • 网关地址为10.10.10.254

  • 子网掩码为255.255.255.0

  • 主机名为core0.example.com

  • DNS 服务器地址为4.4.4.41

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

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

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

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

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

  • 节点的 IP 地址为10.10.10.2

  • 网关地址为10.10.10.254

  • 子网掩码为255.255.255.0

  • DNS 服务器地址为4.4.4.41

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. 按照管理SR-IOV设备中的指南创建SR-IOV虚拟功能 (VF)。请按照“将SR-IOV网络设备连接到虚拟机”部分中的步骤操作。

  2. 按照配置网络绑定中的指南创建绑定,将所需的VF连接到绑定并设置绑定链路状态为up。请按照所述的任何步骤创建绑定。

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

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

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

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

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

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

      bond=bond0:eno1f0,eno2f0:mode=active-backup
      ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:bond0:none
使用网络组队

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

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

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

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

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

team=team0:em1,em2
ip=team0:dhcp
ISO和PXE安装的coreos-installer选项

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

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

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

coreos-installer install子命令

子命令

描述

$ coreos-installer install <options> <device>

将Ignition配置嵌入ISO映像中。

coreos-installer install子命令选项

选项

描述

-u, --image-url <url>

手动指定映像URL。

-f, --image-file <path>

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

-i, --ignition-file <path>

从文件嵌入Ignition配置。

-I, --ignition-url <URL>

从URL嵌入Ignition配置。

--ignition-hash <digest>

Ignition配置的摘要type-value

-p, --platform <name>

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

--console <spec>

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

--append-karg <arg>…​

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

--delete-karg <arg>…​

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

-n, --copy-network

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

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

--network-dir <path>

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

--save-partlabel <lx>..

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

--save-partindex <id>…​

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

--insecure

跳过RHCOS映像签名验证。

--insecure-ignition

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

--architecture <name>

目标CPU架构。有效值为x86_64aarch64

--preserve-on-error

错误时不清除分区表。

-h, --help

打印帮助信息。

coreos-installer install子命令参数

参数

描述

<device>

目标设备。

coreos-installer ISO子命令

子命令

描述

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

自定义RHCOS实时ISO映像。

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

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

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

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

coreos-installer ISO customize子命令选项

选项

描述

--dest-ignition <path>

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

--dest-console <spec>

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

--dest-device <path>

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

--dest-karg-append <arg>

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

--dest-karg-delete <arg>

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

--network-keyfile <path>

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

--ignition-ca <path>

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

--pre-install <path>

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

--post-install <path>

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

--installer-config <path>

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

--live-ignition <path>

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

--live-karg-append <arg>

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

--live-karg-delete <arg>

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

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

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

-f, --force

覆盖现有的 Ignition 配置。

-o, --output <path>

将 ISO 写入新的输出文件。

-h, --help

打印帮助信息。

coreos-installer PXE 子命令

子命令

描述

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

coreos-installer pxe customize <options> <path>

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

coreos-installer pxe ignition wrap <options>

将 Ignition 配置打包到镜像中。

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

显示镜像中打包的 Ignition 配置。

coreos-installer PXE customize 子命令选项

选项

描述

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

--dest-ignition <path>

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

--dest-console <spec>

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

--dest-device <path>

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

--network-keyfile <path>

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

--ignition-ca <path>

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

--pre-install <path>

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

post-install <path>

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

--installer-config <path>

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

--live-ignition <path>

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

-o, --output <path>

将 initramfs 写入新的输出文件。

此选项对于 PXE 环境是必需的。

-h, --help

打印帮助信息。

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

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

  • 对于 ISO 安装,可以通过在引导加载程序菜单中中断自动引导来添加 `coreos.inst` 选项。当 **RHEL CoreOS (Live)** 菜单选项高亮显示时,您可以按 `TAB` 键中断自动引导。

  • 对于 PXE 或 iPXE 安装,必须在引导 RHCOS 实时安装程序之前将 `coreos.inst` 选项添加到 `APPEND` 行。

下表显示了 ISO 和 PXE 安装的 RHCOS 实时安装程序 `coreos.inst` 引导选项。

表 20. `coreos.inst` 引导选项
参数 描述

coreos.inst.install_dev

必需。系统上要安装到的块设备。建议使用完整路径,例如 ` /dev/sda`,尽管允许使用 `sda`。

coreos.inst.ignition_url

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

coreos.inst.save_partlabel

可选:安装期间要保留的分区的逗号分隔标签。允许使用 glob 风格的通配符。指定的分区不需要存在。

coreos.inst.save_partindex

可选:安装期间要保留的分区的逗号分隔索引。允许使用范围 `m-n`,并且可以省略 `m` 或 `n`。指定的分区不需要存在。

coreos.inst.insecure

可选:允许 `coreos.inst.image_url` 指定的 OS 镜像未签名。

coreos.inst.image_url

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

  • 此参数不应在生产环境中使用,仅用于调试目的。

  • 虽然此参数可用于安装与实时介质不匹配的 RHCOS 版本,但建议您使用与要安装的版本匹配的介质。

  • 如果您使用 `coreos.inst.image_url`,则还必须使用 `coreos.inst.insecure`。这是因为裸机介质未针对 OpenShift Container Platform 进行 GPG 签名。

  • 仅支持 HTTP 和 HTTPS 协议。

coreos.inst.skip_reboot

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

coreos.inst.platform_id

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

ignition.config.url

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

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

RHCOS 支持在主磁盘上使用多路径,允许更强的硬件故障恢复能力,以实现更高的主机可用性。

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

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

在 IBM Z® 和 IBM® LinuxONE 上,只有在安装期间为其配置集群时才能启用多路径。有关更多信息,请参阅《在 IBM Z® 和 IBM® LinuxONE 上使用 z/VM 安装集群》中的“安装 RHCOS 并启动 OpenShift Container Platform 引导过程”。

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

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

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

  • 您已查看《安装 RHCOS 并启动 OpenShift Container Platform 引导过程》。

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

    $ mpathconf --enable && systemctl start multipathd.service
    • 可选:如果引导 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
      1 指示单个多路径设备的路径。
    • 如果有多个多路径设备连接到机器,或者更明确地说,建议使用/dev/disk/by-id目录中可用的世界范围名称 (WWN) 符号链接,而不是使用/dev/mapper/mpatha

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

      使用特殊的coreos.inst.*参数引导实时安装程序时,此符号链接也可以用作coreos.inst.install_dev内核参数。有关更多信息,请参见“安装 RHCOS 并启动 OpenShift Container Platform 引导过程”。

  3. 重新启动进入已安装的系统。

  4. 通过转到其中一个工作节点并列出内核命令行参数(主机上的/proc/cmdline)来检查内核参数是否有效。

    $ oc debug node/ip-10-0-141-105.ec2.internal
    示例输出
    Starting pod/ip-10-0-141-105ec2internal-debug ...
    To use host binaries, run `chroot /host`
    
    sh-4.2# cat /host/proc/cmdline
    ...
    rd.multipath=default root=/dev/disk/by-label/dm-mpath-root
    ...
    
    sh-4.2# exit

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

启用辅助磁盘上的多路径

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

先决条件
  • 您已阅读磁盘分区部分。

  • 您已阅读在 RHCOS 上使用内核参数启用多路径

  • 您已安装 Butane 实用程序。

步骤
  1. 创建一个类似于以下内容的 Butane 配置文件

    示例multipath-config.bu
    variant: openshift
    version: 4.17.0
    systemd:
      units:
        - name: mpath-configure.service
          enabled: true
          contents: |
            [Unit]
            Description=Configure Multipath on Secondary Disk
            ConditionFirstBoot=true
            ConditionPathExists=!/etc/multipath.conf
            Before=multipathd.service (1)
            DefaultDependencies=no
    
            [Service]
            Type=oneshot
            ExecStart=/usr/sbin/mpathconf --enable (2)
    
            [Install]
            WantedBy=multi-user.target
        - name: mpath-var-lib-container.service
          enabled: true
          contents: |
            [Unit]
            Description=Set Up Multipath On /var/lib/containers
            ConditionFirstBoot=true (3)
            Requires=dev-mapper-mpatha.device
            After=dev-mapper-mpatha.device
            After=ostree-remount.service
            Before=kubelet.service
            DefaultDependencies=no
    
            [Service] (4)
            Type=oneshot
            ExecStart=/usr/sbin/mkfs.xfs -L containers -m reflink=1 /dev/mapper/mpatha
            ExecStart=/usr/bin/mkdir -p /var/lib/containers
    
            [Install]
            WantedBy=multi-user.target
        - name: var-lib-containers.mount
          enabled: true
          contents: |
            [Unit]
            Description=Mount /var/lib/containers
            After=mpath-var-lib-containers.service
            Before=kubelet.service (5)
    
            [Mount] (6)
            What=/dev/disk/by-label/dm-mpath-containers
            Where=/var/lib/containers
            Type=xfs
    
            [Install]
            WantedBy=multi-user.target
    1 必须在启动多路径守护程序之前设置此配置。
    2 启动mpathconf实用程序。
    3 此字段必须设置为true
    4 创建文件系统和目录/var/lib/containers
    5 必须在启动任何节点之前挂载设备。
    6 将设备挂载到/var/lib/containers挂载点。此位置不能是符号链接。
  2. 运行以下命令创建 Ignition 配置

    $ butane --pretty --strict multipath-config.bu > multipath-config.ign
  3. 继续执行其余的首次启动 RHCOS 安装过程。

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

在 iSCSI 启动设备上手动安装 RHCOS

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

先决条件
  1. 您位于 RHCOS 实时环境中。

  2. 您有一个要安装 RHCOS 的 iSCSI 目标。

步骤
  1. 运行以下命令从实时环境挂载 iSCSI 目标

    $ iscsiadm \
        --mode discovery \
        --type sendtargets
        --portal <IP_address> \ (1)
        --login
    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>
    1 您要安装到的位置。您必须提供目标入口点的 IP 地址、关联的端口号、IQN 格式的 iSCSI 目标节点和 iSCSI 逻辑单元号 (LUN)。
    2 以 IQN 格式表示的 iSCSI 启动器或客户端名称。启动器形成一个会话以连接到 iSCSI 目标。
    3 以 IQN 格式表示的 iSCSI 目标或服务器名称。

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

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

    $ iscsiadm --mode node --logoutall=all

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

使用 iBFT 在 iSCSI 启动设备上安装 RHCOS

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

先决条件
  1. 您位于 RHCOS 实时环境中。

  2. 您有一个要安装 RHCOS 的 iSCSI 目标。

  3. 可选:您已将 iSCSI 目标多路径化。

步骤
  1. 运行以下命令从实时环境挂载 iSCSI 目标

    $ iscsiadm \
        --mode discovery \
        --type sendtargets
        --portal <IP_address> \ (1)
        --login
    1 目标入口点的 IP 地址。
  2. 可选:使用以下命令启用多路径并启动守护程序

    $ mpathconf --enable && systemctl start multipathd.service
  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>
    1 单个多路径设备的路径。如果连接了多个多路径设备,或者更明确地说,可以使用/dev/disk/by-path中可用的世界范围名称 (WWN) 符号链接。
    2 iSCSI 参数从 BIOS 固件读取。
    3 可选:如果启用多路径,请包含此参数。

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

  4. 卸载 iSCSI 磁盘

    $ iscsiadm --mode node --logout=all

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

等待引导过程完成

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

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

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

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

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

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

步骤
  1. 监控引导过程

    $ ./openshift-install --dir <installation_directory> wait-for bootstrap-complete \ (1)
        --log-level=info (2)
    
    1 对于<installation_directory>,请指定存储安装文件的目录的路径。
    2 要查看不同的安装细节,请指定warndebugerror而不是info
    示例输出
    INFO Waiting up to 30m0s for the Kubernetes API at https://api.test.example.com:6443...
    INFO API v1.30.3 up
    INFO Waiting up to 30m0s for bootstrapping to complete...
    INFO It is now safe to remove the bootstrap resources

    当 Kubernetes API 服务器发出信号表明它已在控制平面机器上启动时,命令成功。

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

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

其他资源
  • 有关监控安装日志和在安装问题出现时检索诊断数据的更多信息,请参见监控安装进度

使用 CLI 登录集群

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

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

  • 您已安装oc CLI。

步骤
  1. 导出kubeadmin凭据

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

    $ oc whoami
    示例输出
    system:admin

批准机器的证书签名请求

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

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

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

    $ oc get nodes
    示例输出
    NAME      STATUS    ROLES   AGE  VERSION
    master-0  Ready     master  63m  v1.30.3
    master-1  Ready     master  63m  v1.30.3
    master-2  Ready     master  64m  v1.30.3

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

    在批准某些 CSR 之前,上述输出可能不包括计算节点(也称为工作节点)。

  2. 查看挂起的 CSR,并确保您看到为添加到集群的每台机器显示“挂起”或“已批准”状态的客户端请求

    $ oc get csr
    示例输出
    NAME        AGE     REQUESTOR                                                                   CONDITION
    csr-8b2br   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
    csr-8vnps   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
    ...

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

  3. 如果未批准 CSR,则在添加到集群的所有机器的挂起 CSR 都处于“挂起”状态后,请批准集群机器的 CSR

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

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

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

      $ oc adm certificate approve <csr_name> (1)
      1 <csr_name> 是当前 CSR 列表中 CSR 的名称。
    • 要批准所有挂起的 CSR,请运行以下命令

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

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

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

    $ oc get csr
    示例输出
    NAME        AGE     REQUESTOR                                                                   CONDITION
    csr-bfd72   5m26s   system:node:ip-10-0-50-126.us-east-2.compute.internal                       Pending
    csr-c57lv   5m26s   system:node:ip-10-0-95-157.us-east-2.compute.internal                       Pending
    ...
  5. 如果剩余的 CSR 未获批准且状态为Pending,请批准集群机器的 CSR

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

      $ oc adm certificate approve <csr_name> (1)
      1 <csr_name> 是当前 CSR 列表中 CSR 的名称。
    • 要批准所有挂起的 CSR,请运行以下命令

      $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve
  6. 批准所有客户端和服务器 CSR 后,机器将具有Ready 状态。通过运行以下命令验证这一点

    $ oc get nodes
    示例输出
    NAME      STATUS    ROLES   AGE  VERSION
    master-0  Ready     master  73m  v1.30.3
    master-1  Ready     master  73m  v1.30.3
    master-2  Ready     master  74m  v1.30.3
    worker-0  Ready     worker  11m  v1.30.3
    worker-1  Ready     worker  11m  v1.30.3

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

附加信息

初始 Operator 配置

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

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

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

    $ watch -n5 oc get clusteroperators
    示例输出
    NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
    authentication                             4.17.0    True        False         False      19m
    baremetal                                  4.17.0    True        False         False      37m
    cloud-credential                           4.17.0    True        False         False      40m
    cluster-autoscaler                         4.17.0    True        False         False      37m
    config-operator                            4.17.0    True        False         False      38m
    console                                    4.17.0    True        False         False      26m
    csi-snapshot-controller                    4.17.0    True        False         False      37m
    dns                                        4.17.0    True        False         False      37m
    etcd                                       4.17.0    True        False         False      36m
    image-registry                             4.17.0    True        False         False      31m
    ingress                                    4.17.0    True        False         False      30m
    insights                                   4.17.0    True        False         False      31m
    kube-apiserver                             4.17.0    True        False         False      26m
    kube-controller-manager                    4.17.0    True        False         False      36m
    kube-scheduler                             4.17.0    True        False         False      36m
    kube-storage-version-migrator              4.17.0    True        False         False      37m
    machine-api                                4.17.0    True        False         False      29m
    machine-approver                           4.17.0    True        False         False      37m
    machine-config                             4.17.0    True        False         False      36m
    marketplace                                4.17.0    True        False         False      37m
    monitoring                                 4.17.0    True        False         False      29m
    network                                    4.17.0    True        False         False      38m
    node-tuning                                4.17.0    True        False         False      37m
    openshift-apiserver                        4.17.0    True        False         False      32m
    openshift-controller-manager               4.17.0    True        False         False      30m
    openshift-samples                          4.17.0    True        False         False      32m
    operator-lifecycle-manager                 4.17.0    True        False         False      37m
    operator-lifecycle-manager-catalog         4.17.0    True        False         False      37m
    operator-lifecycle-manager-packageserver   4.17.0    True        False         False      32m
    service-ca                                 4.17.0    True        False         False      38m
    storage                                    4.17.0    True        False         False      37m
  2. 配置不可用的 Operator。

其他资源

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

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

安装后,您必须编辑镜像注册表 Operator 配置,将managementStateRemoved 切换到Managed。完成后,您必须配置存储。

镜像注册表存储配置

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

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

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

为裸机配置块注册表存储

为了允许镜像注册表在升级期间作为集群管理员使用块存储类型,您可以使用Recreate 展开策略。

块存储卷或块持久卷受支持,但不建议在生产集群中与镜像注册表一起使用。注册表配置在块存储上的安装不是高可用的,因为注册表不能有多个副本。

如果您选择将块存储卷与镜像注册表一起使用,则必须使用文件系统持久卷声明 (PVC)。

步骤
  1. 输入以下命令以将镜像注册表存储设置为块存储类型,修补注册表以使其使用Recreate 展开策略,并仅运行一个 (1) 副本

    $ oc patch config.imageregistry.operator.openshift.io/cluster --type=merge -p '{"spec":{"rolloutStrategy":"Recreate","replicas":1}}'
  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)
      1 代表PersistentVolumeClaim 对象的唯一名称。
      2 PersistentVolumeClaim 对象的命名空间,即openshift-image-registry
      3 持久卷声明的访问模式。使用ReadWriteOnce,该卷可以由单个节点以读写权限挂载。
      4 持久卷声明的大小。
    2. 输入以下命令以从文件创建PersistentVolumeClaim 对象

      $ oc create -f pvc.yaml -n openshift-image-registry
  3. 输入以下命令以编辑注册表配置,使其引用正确的 PVC

    $ oc edit config.imageregistry.operator.openshift.io -o yaml
    示例输出
    storage:
      pvc:
        claim: (1)
    1 通过创建自定义 PVC,您可以将claim 字段留空,以默认自动创建image-registry-storage PVC。

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

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

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

  • 您已完成初始 Operator 配置。

步骤
  1. 使用以下命令确认所有集群组件均在线

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

    或者,以下命令会在所有集群可用时通知您。它还会检索和显示凭据

    $ ./openshift-install --dir <installation_directory> wait-for install-complete (1)
    1 对于<installation_directory>,请指定存储安装文件的目录的路径。
    示例输出
    INFO Waiting up to 30m0s for the cluster to initialize...

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

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

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

  2. 确认 Kubernetes API 服务器正在与 Pod 通信。

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

      $ oc get pods --all-namespaces
      示例输出
      NAMESPACE                         NAME                                            READY   STATUS      RESTARTS   AGE
      openshift-apiserver-operator      openshift-apiserver-operator-85cb746d55-zqhs8   1/1     Running     1          9m
      openshift-apiserver               apiserver-67b9g                                 1/1     Running     0          3m
      openshift-apiserver               apiserver-ljcmx                                 1/1     Running     0          1m
      openshift-apiserver               apiserver-z25h4                                 1/1     Running     0          2m
      openshift-authentication-operator authentication-operator-69d5d8bf84-vh2n8        1/1     Running     0          5m
      ...
    2. 使用以下命令查看先前命令输出中列出的 Pod 的日志

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

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

  3. 对于使用光纤通道协议 (FCP) 的安装,需要执行其他步骤才能启用多路径。请勿在安装过程中启用多路径。

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

OpenShift Container Platform 的遥测访问

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

确认您的OpenShift 集群管理器清单正确无误后(可以通过 Telemetry 自动维护,也可以通过 OpenShift 集群管理器手动维护),请使用订阅监控来跟踪您在帐户或多集群级别上的 OpenShift Container Platform 订阅。

其他资源