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

5.4.1. 所需的机器

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

表 5.1. 最低所需的主机
主机	描述
一个临时 bootstrap 机器	集群需要 bootstrap 机器在三台 control plane 机器上部署 OpenShift Container Platform 集群。您可在安装集群后删除 bootstrap 机器。
三台 control plane 机器	control plane 机器运行组成 control plane 的 Kubernetes 和 OpenShift Container Platform 服务。
至少两台计算机器，也称为 worker 机器。	OpenShift Container Platform 用户请求的工作负载在计算机器上运行。

重要

要提高集群的高可用性，请在至少两台物理机器的不同 RHEL 实例上分发 control plane 机器。

bootstrap、control plane 和计算机器必须使用 Red Hat Enterprise Linux CoreOS(RHCOS)作为操作系统。

查看红帽企业 Linux 技术功能和限制。

5.4.2. 网络连接要求

OpenShift Container Platform 安装程序创建 Ignition 文件，这是所有 Red Hat Enterprise Linux CoreOS(RHCOS)虚拟机所必需的。OpenShift Container Platform 的自动安装由 bootstrap 机器执行。它在每个节点上启动 OpenShift Container Platform 安装，启动 Kubernetes 集群，然后完成。在这个 bootstrap 中，虚拟机必须通过 DHCP 服务器或静态 IP 地址建立网络连接。

5.4.3. IBM Z 网络连接要求

要在 RHEL KVM 中安装 IBM Z®，您需要：

使用 OSA 或 RoCE 网络适配器配置的 RHEL KVM 主机。
在 libvirt 中使用桥接网络的 RHEL KVM 主机或 MacVTap 将网络连接到客户机。
请参阅虚拟机网络连接的类型。

5.4.4. 主机机器资源要求

环境中的 RHEL KVM 主机必须满足以下要求，才能托管您计划用于 OpenShift Container Platform 环境的虚拟机。请参阅在 IBM Z® 上启用虚拟化。

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

IBM® z16 （所有型号）、IBM® z15 （所有型号）、IBM® z14 （所有型号）
IBM® LinuxONE 4 （所有型号）、IBM® LinuxONE （所有型号）、IBM® LinuxONE Emperor II、IBM® LinuxONE Rockhopper II

5.4.5. 最低 IBM Z 系统环境

硬件要求

Linux(IFL)等效的、启用了 SMT2 的 Linux 集成设施，每个群集都启用了 SMT2。
至少一个网络连接连接到 LoadBalancer 服务，并为集群外的流量提供数据。

注意

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

重要

由于集群的整体性能会受到影响，用于设置 OpenShift Container Platform 集群的 LPAR 必须提供足够的计算容量。就此而言，管理程序级别上的 LPAR 权重管理、授权和 CPU 共享扮演着重要角色。

操作系统要求

使用 KVM 在 RHEL 8.6 或更高版本上运行的一个 LPAR，由 libvirt 管理

在 RHEL KVM 主机上设置：

用于 OpenShift Container Platform control plane 机器的三台客户机虚拟机
用于 OpenShift Container Platform 计算机器的两个客户机虚拟机
一个客户虚拟机作为临时 OpenShift Container Platform bootstrap 机器

5.4.6. 最低资源要求

每个集群虚拟机都必须满足以下最低要求：

虚拟机	操作系统	vCPU ^[1]	虚拟内存	Storage	IOPS
bootstrap	RHCOS	4	16 GB	100 GB	N/A
Control plane（控制平面）	RHCOS	4	16 GB	100 GB	N/A
Compute	RHCOS	2	8 GB	100 GB	N/A

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

5.4.7. 首选 IBM Z 系统环境

硬件要求

三个 LPARS，每个都相当于 6 个 IFL（每个集群启用了 SMT2）。
两个网络连接连接到 LoadBalancer 服务，并为集群外的流量提供数据。

操作系统要求

为获得高可用性，在 RHEL 8.6 或更高版本上运行的两个或者三个 LPAR 使用 KVM（由 libvirt 管理）。

在 RHEL KVM 主机上设置：

3 个用于 OpenShift Container Platform control plane 机器的虚拟机，分布在 RHEL KVM 主机中。
至少 6 个用于 OpenShift Container Platform 计算机器的虚拟机，分布在 RHEL KVM 主机中。
一个客户虚拟机作为临时 OpenShift Container Platform bootstrap 机器。
要确保过量使用环境中组件的可用性，请使用 cpu_shares 增加 control plane 的优先级。如果存在基础架构节点，则对它们执行相同的操作。请参阅 IBM® 文档中的 schedinfo。

5.4.8. 首选资源要求

每个集群虚拟机的首选要求如下：

虚拟机	操作系统	vCPU	虚拟内存	Storage
bootstrap	RHCOS	4	16 GB	120 GB
Control plane（控制平面）	RHCOS	8	16 GB	120 GB
Compute	RHCOS	6	8 GB	120 GB

5.4.9. 证书签名请求管理

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

其他资源

IBM Z® 和 IBM® LinuxONE 环境的推荐主机实践

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

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

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

注意

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

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

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

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

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

5.4.10.2. 网络连接要求

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

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

表 5.2. 用于全机器到所有机器通信的端口
协议	port	描述
ICMP	N/A	网络可访问性测试
TCP	`1936`	指标
	`9000`-`9999`	主机级别的服务，包括端口 9 `100`-`9101 上的节点导出器`，以及端口 `9099` 上的 Cluster Version Operator。
	`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 Encapsulating Security Payload(ESP)

表 5.3. 用于所有机器控制平面通信的端口
协议	port	描述
TCP	`6443`	Kubernetes API

表 5.4. control plane 机器用于 control plane 机器通信的端口
协议	port	描述
TCP	`2379`-`2380`	etcd 服务器和对等端口

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

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

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

其他资源

配置 chrony 时间服务

5.4.11. 用户置备的 DNS 要求

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

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

Kubernetes API、bootstrap 机器、control plane 机器和计算机器也需要反向 DNS 解析。

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

用户置备的 OpenShift Container Platform 集群需要以下 DNS 记录，这些记录必须在安装前就位。在每个记录中，<cluster_name> 是集群名称，<base_domain> 是您在 install-config.yaml 文件中指定的基域。完整的 DNS 记录采用以下形式： <component>.<cluster_name>.<base_domain>.。

表 5.5. 所需的 DNS 记录
组件	记录	描述
Kubernetes API	`api.<cluster_name>.<base_domain>.`	DNS A/AAAA 或 CNAME 记录，以及用于标识 API 负载均衡器的 DNS PTR 记录。这些记录必须由集群外的客户端和集群中的所有节点解析。
Kubernetes API	`api-int.<cluster_name>.<base_domain>.`	DNS A/AAAA 或 CNAME 记录，以及用于内部标识 API 负载均衡器的 DNS PTR 记录。这些记录必须可以从集群中的所有节点解析。重要 API 服务器必须能够根据 Kubernetes 中记录的主机名解析 worker 节点。如果 API 服务器无法解析节点名称，则代理的 API 调用会失败，且您无法从 pod 检索日志。
Routes	`*.apps.<cluster_name>.<base_domain>.`	通配符 DNS A/AAAA 或 CNAME 记录，指向应用程序入口负载均衡器。应用程序入口负载均衡器以运行 Ingress Controller Pod 的机器为目标。默认情况下，Ingress Controller Pod 在计算机器上运行。这些记录必须由集群外的客户端和集群中的所有节点解析。例如，console `-openshift-console.apps.<cluster_name>.<base_domain>` 用作到 OpenShift Container Platform 控制台的通配符路由。
bootstrap 机器	`bootstrap.<cluster_name>.<base_domain>.`	DNS A/AAAA 或 CNAME 记录，以及用于标识 bootstrap 机器的 DNS PTR 记录。这些记录必须由集群中的节点解析。
control plane 机器	`<control_plane><n>.<cluster_name>.<base_domain>.`	DNS A/AAAA 或 CNAME 记录，以识别 control plane 节点的每台机器。这些记录必须由集群中的节点解析。
计算机器	`<compute><n>.<cluster_name>.<base_domain>.`	DNS A/AAAA 或 CNAME 记录，用于识别 worker 节点的每台机器。这些记录必须由集群中的节点解析。

注意

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

提示

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

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

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

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

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

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

例 5.1. DNS 区数据库示例

Copy to Clipboard Toggle word wrap

$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 
api-int.ocp4.example.com.	IN	A	192.168.1.5 
;
*.apps.ocp4.example.com.	IN	A	192.168.1.5 
;
bootstrap.ocp4.example.com.	IN	A	192.168.1.96 
;
control-plane0.ocp4.example.com.	IN	A	192.168.1.97 
control-plane1.ocp4.example.com.	IN	A	192.168.1.98 
control-plane2.ocp4.example.com.	IN	A	192.168.1.99 
;
compute0.ocp4.example.com.	IN	A	192.168.1.11 
compute1.ocp4.example.com.	IN	A	192.168.1.7 
;
;EOF

$TTL 1W
@	IN	SOA	ns1.example.com.	root (
			2019070700	; serial
			3H		; refresh (3 hours)
			30M		; retry (30 minutes)
			2W		; expiry (2 weeks)
			1W )		; minimum (1 week)
	IN	NS	ns1.example.com.
	IN	MX 10	smtp.example.com.
;
;
ns1.example.com.		IN	A	192.168.1.5
smtp.example.com.		IN	A	192.168.1.5
;
helper.example.com.		IN	A	192.168.1.5
helper.ocp4.example.com.	IN	A	192.168.1.5
;
api.ocp4.example.com.		IN	A	192.168.1.5

1


api-int.ocp4.example.com.	IN	A	192.168.1.5

2


;
*.apps.ocp4.example.com.	IN	A	192.168.1.5

3


;
bootstrap.ocp4.example.com.	IN	A	192.168.1.96

4


;
control-plane0.ocp4.example.com.	IN	A	192.168.1.97

5


control-plane1.ocp4.example.com.	IN	A	192.168.1.98

6


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

7


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

8


compute1.ocp4.example.com.	IN	A	192.168.1.7

9


;
;EOF

1: 为 Kubernetes API 提供名称解析。记录引用 API 负载均衡器的 IP 地址。
2: 为 Kubernetes API 提供名称解析。记录引用 API 负载均衡器的 IP 地址，用于内部集群通信。
3: 为通配符路由提供名称解析。记录引用应用程序入口负载均衡器的 IP 地址。应用程序入口负载均衡器以运行 Ingress Controller Pod 的机器为目标。默认情况下，Ingress Controller Pod 在计算机器上运行。
注意
在这个示例中，将相同的负载均衡器用于 Kubernetes API 和应用入口流量。在生产环境中，您可以单独部署 API 和应用程序入口负载均衡器，以便可以隔离扩展每个负载均衡器基础架构。
4: 为 bootstrap 机器提供名称解析。
5 6 7: 为 control plane 机器提供名称解析。
8 9: 为计算机器提供名称解析。

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

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

例 5.2. 反向记录的 DNS 区数据库示例

Copy to Clipboard Toggle word wrap

$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. 
5.1.168.192.in-addr.arpa.	IN	PTR	api-int.ocp4.example.com. 
;
96.1.168.192.in-addr.arpa.	IN	PTR	bootstrap.ocp4.example.com. 
;
97.1.168.192.in-addr.arpa.	IN	PTR	control-plane0.ocp4.example.com. 
98.1.168.192.in-addr.arpa.	IN	PTR	control-plane1.ocp4.example.com. 
99.1.168.192.in-addr.arpa.	IN	PTR	control-plane2.ocp4.example.com. 
;
11.1.168.192.in-addr.arpa.	IN	PTR	compute0.ocp4.example.com. 
7.1.168.192.in-addr.arpa.	IN	PTR	compute1.ocp4.example.com. 
;
;EOF

$TTL 1W
@	IN	SOA	ns1.example.com.	root (
			2019070700	; serial
			3H		; refresh (3 hours)
			30M		; retry (30 minutes)
			2W		; expiry (2 weeks)
			1W )		; minimum (1 week)
	IN	NS	ns1.example.com.
;
5.1.168.192.in-addr.arpa.	IN	PTR	api.ocp4.example.com.

1


5.1.168.192.in-addr.arpa.	IN	PTR	api-int.ocp4.example.com.

2


;
96.1.168.192.in-addr.arpa.	IN	PTR	bootstrap.ocp4.example.com.

3


;
97.1.168.192.in-addr.arpa.	IN	PTR	control-plane0.ocp4.example.com.

4


98.1.168.192.in-addr.arpa.	IN	PTR	control-plane1.ocp4.example.com.

5


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

6


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

7


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

8


;
;EOF

1: 为 Kubernetes API 提供反向 DNS 解析。PTR 记录引用 API 负载均衡器的记录名称。
2: 为 Kubernetes API 提供反向 DNS 解析。PTR 记录引用 API 负载均衡器的记录名称，用于内部集群通信。
3: 为 bootstrap 机器提供反向 DNS 解析。
4 5 6: 为 control plane 机器提供反向 DNS 解析。
7 8: 为计算机器提供反向 DNS 解析。

注意

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

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

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

注意

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

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

API 负载均衡器 ：提供一个通用端点，供用户（包括人工和机器）与平台交互和配置。配置以下条件：

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

重要

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

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

表 5.6. API 负载均衡器
port	后端机器（池成员）	internal	外部	描述
`6443`	Bootstrap 和 control plane.bootstrap 机器初始化集群 control plane 后，您要从负载均衡器中删除 bootstrap 机器。您必须为 API 服务器健康检查探测配置 `/readyz` 端点。	X	X	Kubernetes API 服务器
`22623`	Bootstrap 和 control plane.bootstrap 机器初始化集群 control plane 后，您要从负载均衡器中删除 bootstrap 机器。	X		机器配置服务器

注意

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

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

配置以下条件：

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

提示

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

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

表 5.7. 应用程序入口负载均衡器
port	后端机器（池成员）	internal	外部	描述
`443`	默认情况下，运行 Ingress Controller Pod、计算或 worker 的机器。	X	X	HTTPS 流量
`80`	默认情况下，运行 Ingress Controller Pod、计算或 worker 的机器。	X	X	HTTP 流量

注意

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

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

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

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

注意

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

例 5.3. API 和应用程序入口负载均衡器配置示例

Copy to Clipboard Toggle word wrap

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 
  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 
  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 
  bind *:22623
  mode tcp
  server bootstrap bootstrap.ocp4.example.com:22623 check inter 1s backup 
  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 
  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 
  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

global
  log         127.0.0.1 local2
  pidfile     /var/run/haproxy.pid
  maxconn     4000
  daemon
defaults
  mode                    http
  log                     global
  option                  dontlognull
  option http-server-close
  option                  redispatch
  retries                 3
  timeout http-request    10s
  timeout queue           1m
  timeout connect         10s
  timeout client          1m
  timeout server          1m
  timeout http-keep-alive 10s
  timeout check           10s
  maxconn                 3000
listen api-server-6443

1


  bind *:6443
  mode tcp
  option  httpchk GET /readyz HTTP/1.0
  option  log-health-checks
  balance roundrobin
  server bootstrap bootstrap.ocp4.example.com:6443 verify none check check-ssl inter 10s fall 2 rise 3 backup

2


  server master0 master0.ocp4.example.com:6443 weight 1 verify none check check-ssl inter 10s fall 2 rise 3
  server master1 master1.ocp4.example.com:6443 weight 1 verify none check check-ssl inter 10s fall 2 rise 3
  server master2 master2.ocp4.example.com:6443 weight 1 verify none check check-ssl inter 10s fall 2 rise 3
listen machine-config-server-22623

3


  bind *:22623
  mode tcp
  server bootstrap bootstrap.ocp4.example.com:22623 check inter 1s backup

4


  server master0 master0.ocp4.example.com:22623 check inter 1s
  server master1 master1.ocp4.example.com:22623 check inter 1s
  server master2 master2.ocp4.example.com:22623 check inter 1s
listen ingress-router-443

5


  bind *:443
  mode tcp
  balance source
  server compute0 compute0.ocp4.example.com:443 check inter 1s
  server compute1 compute1.ocp4.example.com:443 check inter 1s
listen ingress-router-80

6


  bind *:80
  mode tcp
  balance source
  server compute0 compute0.ocp4.example.com:80 check inter 1s
  server compute1 compute1.ocp4.example.com:80 check inter 1s

1: 端口 6443 处理 Kubernetes API 流量并指向 control plane 机器。
2 4: bootstrap 条目必须在 OpenShift Container Platform 集群安装前就位，且必须在 bootstrap 过程完成后删除它们。
3: 端口 22623 处理机器配置服务器流量并指向 control plane 机器。
5: 端口 443 处理 HTTPS 流量，并指向运行 Ingress Controller pod 的机器。默认情况下，Ingress Controller Pod 在计算机器上运行。
6: 端口 80 处理 HTTP 流量，并指向运行 Ingress Controller pod 的机器。默认情况下，Ingress Controller Pod 在计算机器上运行。
注意
如果要部署一个带有零计算节点的三节点集群，Ingress Controller Pod 在 control plane 节点上运行。在三节点集群部署中，您必须配置应用程序入口负载均衡器，将 HTTP 和 HTTPS 流量路由到 control plane 节点。

提示

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

5.4.1. 所需的机器

5.4.2. 网络连接要求

5.4.3. IBM Z 网络连接要求

5.4.4. 主机机器资源要求

5.4.5. 最低 IBM Z 系统环境

硬件要求

操作系统要求

5.4.6. 最低资源要求

5.4.7. 首选 IBM Z 系统环境

硬件要求

操作系统要求

5.4.8. 首选资源要求

5.4.9. 证书签名请求管理

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

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

5.4.10.2. 网络连接要求

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

5.4.11. 用户置备的 DNS 要求

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

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

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

学习

尝试、购买和销售

社区

关于红帽文档

让开源更具包容性

關於紅帽

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links