OpenShift 文档正在迁移，很快将仅在 docs.redhat.com（所有 Red Hat 产品文档的所在地）提供。立即体验 新的文档体验。
  1. 文档
    2. history bug_report picture_as_pdf
×

IBM Z 和 IBM LinuxONE 基础设施的安装要求

在 IBM Z® 基础设施上开始安装之前，请确保您的 IBM Z® 环境满足以下安装要求。

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

集群安装所需的机器

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

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

一台临时引导机器

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

三台控制平面机器

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

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

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

为了提高集群的高可用性，请将控制平面机器分布在至少两台物理机器上的不同虚拟机管理程序实例上。

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

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

集群安装的最低资源要求

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

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

引导程序

RHCOS

4

16 GB

100 GB

N/A

控制平面

RHCOS

4

16 GB

100 GB

N/A

计算

RHCOS

2

8 GB

100 GB

N/A

  1. 启用 SMT-2 时，一个物理核心 (IFL) 提供两个逻辑核心（线程）。虚拟机管理程序可以提供两个或更多 vCPU。

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

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

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

  • IBM Power 架构需要 Power 9 ISA

  • s390x 架构需要 z14 ISA

更多信息，请参阅 RHEL 架构。

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

其他资源

IBM Z 系统的最低环境要求

以下 IBM® 硬件受 OpenShift Container Platform 4.17 版本支持。

表 3. 受支持的 IBM® 硬件
z/VM LPAR [1] RHEL KVM [2]

IBM® z16（所有型号）

支持

支持

支持

IBM® z15（所有型号）

支持

支持

支持

IBM® z14（所有型号）

支持

支持

支持

IBM® LinuxONE 4（所有型号）

支持

支持

支持

IBM® LinuxONE III（所有型号）

支持

支持

支持

IBM® LinuxONE Emperor II

支持

支持

支持

IBM® LinuxONE Rockhopper II

支持

支持

支持

  1. 在 IBM Z® 上运行 OpenShift Container Platform 且无 hypervisor 时，请使用动态分区管理器 (DPM) 来管理您的机器。

  2. 您环境中的 RHEL KVM 主机必须满足某些要求才能托管您计划用于 OpenShift Container Platform 环境的虚拟机。请参阅RHEL 8 中虚拟化的入门指南。

硬件要求

  • 每个集群需要相当于六个启用 SMT2 的集成 Linux 设施 (IFL)。

  • 至少一个网络连接，用于连接到 `LoadBalancer` 服务并为集群外部的流量提供数据。

  • 您可以使用专用或共享 IFL 来分配足够的计算资源。资源共享是 IBM Z® 的主要优势之一。但是，您必须正确调整每个 hypervisor 层上的容量，并确保每个 OpenShift Container Platform 集群都有足够的资源。

  • 由于集群的整体性能可能会受到影响，因此用于设置 OpenShift Container Platform 集群的 LPAR 必须提供足够的计算能力。在这种情况下，hypervisor 层上的 LPAR 权重管理、授权和 CPU 共享起着重要作用。更多信息，请参阅“IBM Z® 和 IBM LinuxONE 环境的推荐主机实践”。

IBM Z 操作系统要求

表 4. 操作系统要求
z/VM LPAR RHEL KVM

Hypervisor

一个或多个 z/VM 7.2 或更高版本实例

具有 DPM 或 PR/SM 的 IBM® z14 或更高版本

在 RHEL 8.6 或更高版本上运行并由 libvirt 管理的、具有 KVM 的一个 LPAR

OpenShift Container Platform 控制平面机器

三个客户机虚拟机

三个 LPAR

三个客户机虚拟机

OpenShift Container Platform 计算机器

两个客户机虚拟机

两个 LPAR

两个客户机虚拟机

临时 OpenShift Container Platform 引导机器

一台机器

一台机器

一台机器

IBM Z 网络连接

表 5. 网络连接要求
z/VM LPAR RHEL KVM

网络接口卡 (NIC)

一个在 2 层模式下的 z/VM 虚拟 NIC

-

-

虚拟交换机 (vSwitch)

z/VM VSWITCH

-

-

网络适配器

直连 OSA、RoCE 或 HiperSockets

直连 OSA、RoCE 或 HiperSockets

配置了 OSA、RoCE 或 HiperSockets 的 RHEL KVM 主机

配置为在 libvirt 中使用桥接网络或 MacVTap 将网络连接到客户机的 RHEL KVM 主机。

请参阅虚拟网络连接类型。
磁盘存储
表 6. 磁盘存储要求
z/VM LPAR RHEL KVM

光纤连接 (FICON)

z/VM 微型磁盘、全包微型磁盘或专用 DASD，所有这些都必须格式化为 CDL（默认格式）。要达到 Red Hat Enterprise Linux CoreOS (RHCOS) 安装所需的最小 DASD 大小，您需要扩展地址卷 (EAV)。如果可用，请使用 HyperPAV 以确保最佳性能。

必须格式化为 CDL（默认格式）的专用 DASD。要达到 Red Hat Enterprise Linux CoreOS (RHCOS) 安装所需的最小 DASD 大小，您需要扩展地址卷 (EAV)。如果可用，请使用 HyperPAV 以确保最佳性能。

虚拟块设备

光纤通道协议 (FCP)

专用 FCP 或 EDEV

专用 FCP 或 EDEV

虚拟块设备

QCOW

不支持

不支持

支持

NVMe

不支持

支持

虚拟块设备

推荐的 IBM Z 系统环境

在 IBM Z® 硬件上运行 OpenShift Container Platform 4.17 版本的首选系统环境如下所示：

硬件要求

  • 三个逻辑分区 (LPAR)，每个分区都具有每个集群相当于六个启用 SMT2 的集成 Linux 设施 (IFL)。

  • 两个网络连接，用于连接到 `LoadBalancer` 服务并为集群外部的流量提供数据。

  • 直接作为设备连接到节点的 HiperSockets。要将 HiperSockets 直接连接到节点，您必须通过 RHEL 8 客户机设置到外部网络的网关，以桥接到 HiperSockets 网络。

    在 z/VM 环境中安装时，您还可以使用一个 z/VM VSWITCH 桥接 HiperSockets，以便对 z/VM 客户机透明。

IBM Z 操作系统要求

表 7. 操作系统要求
z/VM [1] LPAR RHEL KVM

Hypervisor

一个或多个 z/VM 7.2 或更高版本实例

具有 DPM 或 PR/S 的 IBM® z14 或更高版本

在 RHEL 8.6 或更高版本上运行并由 libvirt 管理的、具有 KVM 的一个 LPAR

OpenShift Container Platform 控制平面机器

三个客户机虚拟机

三个客户机虚拟机

三个 LPAR

OpenShift Container Platform 计算机器

六个客户机虚拟机

六个客户机虚拟机

六个 LPAR

临时 OpenShift Container Platform 引导机器

一台机器

一台机器

一台机器

  1. 为了确保在超额分配环境中整体组件的可用性，请使用 CP 命令 `SET SHARE` 来提高控制平面的优先级。如果存在基础设施节点，也对它们执行相同的操作。请参阅SET SHARE（IBM® 文档）。

其他资源

证书签名请求管理

由于在使用您自己配置的基础设施时，您的集群对自动机器管理的访问权限有限，因此您必须提供一种机制来批准安装后的集群证书签名请求 (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 提供遥测数据。
表 8. 所有机器到所有机器通信使用的端口
协议 端口 描述

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)
表 9. 所有机器到控制平面通信使用的端口
协议 端口 描述

TCP

6443

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

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

表 11. 必需的 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 为目标。集群外部的客户端和集群内的所有节点都必须能够解析这些记录。

例如，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 层负载均衡。这可以称为 Raw TCP 或 SSL 直通模式。

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

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

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

    表 12. API 负载均衡器
    端口 后端机器（池成员） 内部 外部 描述

    6443

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

    X

    X

    Kubernetes API 服务器

    22623

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

    X

    机器配置服务器

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

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

    配置以下条件

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

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

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

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

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

    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。