Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

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

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

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

3.4.1. 集群安装所需的机器

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

表 3.1. 最低所需的主机
主机描述

一个临时 bootstrap 机器

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

三台 control plane 机器

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

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

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

重要

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

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

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

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

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

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

bootstrap

RHCOS

2

16 GB

100 GB

300

Control plane（控制平面）

RHCOS

2

16 GB

100 GB

300

Compute

RHCOS

2

8 GB

100 GB

300

  1. 当未启用并发多线程 (SMT) 或超线程时，一个 vCPU 相当于一个物理内核。启用后，使用以下公式来计算对应的比例：（每个内核数的线程）× sockets = vCPU。
  2. OpenShift Container Platform 和 Kubernetes 对磁盘性能敏感，建议使用更快的存储，特别是 control plane 节点上的 etcd。请注意，在许多云平台上，存储大小和 IOPS 可一起扩展，因此您可能需要过度分配存储卷来获取足够的性能。
注意

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

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

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

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

其他资源

3.4.3. 最低 IBM Power 要求

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

  • IBM Power9 或 Power10 处理器的系统
注意

OpenShift Container Platform 4.13 中弃用了所有 IBM Power8 模型、IBM Power AC922、IBM Power IC922 和 IBM Power LC922 的 RHCOS 功能。红帽建议您使用后续的硬件模型。

硬件要求
  • 在多个 PowerVM 服务器间有六个 IBM Power 裸机服务器或六个 LPAR
操作系统要求
  • IBM Power9 或 Power10 处理器系统的一个实例

在 IBM Power 实例中设置：

  • 用于 OpenShift Container Platform control plane 机器的三台客户机虚拟机
  • 用于 OpenShift Container Platform 计算机器的两个客户机虚拟机
  • 一个客户虚拟机作为临时 OpenShift Container Platform bootstrap 机器
IBM Power 客户机虚拟机的磁盘存储
  • 本地存储或由虚拟 I/O 服务器使用 vSCSI、NPIV(N-Port ID Virtualization)或 SSP（共享存储池）置备的存储
PowerVM 客户机虚拟机的网络
  • 专用物理适配器或 SR-IOV 虚拟功能
  • 虚拟 I/O 服务器使用共享以太网适配器提供
  • 虚拟 I/O 服务器使用 IBM vNIC 虚拟化
存储/主内存
  • OpenShift Container Platform control plane 机器需要 100 GB / 16 GB
  • OpenShift Container Platform 计算机器需要 100 GB / 8 GB
  • 临时 OpenShift Container Platform bootstrap 机器需要 100 GB / 16 GB

3.4.5. 证书签名请求管理

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

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

所有 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 请求中的完全限定域名引用主机。

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

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

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

3.4.6.2. 网络连接要求

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

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

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

ICMP

N/A

网络可访问性测试

TCP

1936

指标

9000-9999

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

10250-10259

Kubernetes 保留的默认端口

10256

openshift-sdn

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)

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

TCP

6443

Kubernetes API

表 3.5. 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 服务器同步。

其他资源

3.4.7. 用户置备的 DNS 要求

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

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

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

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

注意

建议使用 DHCP 服务器为每个群集节点提供主机名。如需更多信息，请参阅用户置备的基础架构部分的 DHCP 建议。

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

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

Kubernetes API

api.<cluster_name>.<base_domain>.

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

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

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

重要

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

Routes

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

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

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

bootstrap 机器

bootstrap.<cluster_name>.<base_domain>.

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

control plane 机器

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

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

计算机器

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

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

注意

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

提示

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

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

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

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

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

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

例 3.1. DNS 区数据库示例

$TTL 1W
@	IN	SOA	ns1.example.com.	root (
			2019070700	; serial
			3H		; refresh (3 hours)
			30M		; retry (30 minutes)
			2W		; expiry (2 weeks)
			1W )		; minimum (1 week)
	IN	NS	ns1.example.com.
	IN	MX 10	smtp.example.com.
;
;
ns1.example.com.		IN	A	192.168.1.5
smtp.example.com.		IN	A	192.168.1.5
;
helper.example.com.		IN	A	192.168.1.5
helper.ocp4.example.com.	IN	A	192.168.1.5
;
api.ocp4.example.com.		IN	A	192.168.1.5 1
api-int.ocp4.example.com.	IN	A	192.168.1.5 2
;
*.apps.ocp4.example.com.	IN	A	192.168.1.5 3
;
bootstrap.ocp4.example.com.	IN	A	192.168.1.96 4
;
control-plane0.ocp4.example.com.	IN	A	192.168.1.97 5
control-plane1.ocp4.example.com.	IN	A	192.168.1.98 6
control-plane2.ocp4.example.com.	IN	A	192.168.1.99 7
;
compute0.ocp4.example.com.	IN	A	192.168.1.11 8
compute1.ocp4.example.com.	IN	A	192.168.1.7 9
;
;EOF
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 记录示例。

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

$TTL 1W
@	IN	SOA	ns1.example.com.	root (
			2019070700	; serial
			3H		; refresh (3 hours)
			30M		; retry (30 minutes)
			2W		; expiry (2 weeks)
			1W )		; minimum (1 week)
	IN	NS	ns1.example.com.
;
5.1.168.192.in-addr.arpa.	IN	PTR	api.ocp4.example.com. 1
5.1.168.192.in-addr.arpa.	IN	PTR	api-int.ocp4.example.com. 2
;
96.1.168.192.in-addr.arpa.	IN	PTR	bootstrap.ocp4.example.com. 3
;
97.1.168.192.in-addr.arpa.	IN	PTR	control-plane0.ocp4.example.com. 4
98.1.168.192.in-addr.arpa.	IN	PTR	control-plane1.ocp4.example.com. 5
99.1.168.192.in-addr.arpa.	IN	PTR	control-plane2.ocp4.example.com. 6
;
11.1.168.192.in-addr.arpa.	IN	PTR	compute0.ocp4.example.com. 7
7.1.168.192.in-addr.arpa.	IN	PTR	compute1.ocp4.example.com. 8
;
;EOF
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 记录。

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

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

注意

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

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

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

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

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

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

    表 3.7. API 负载均衡器
    port后端机器（池成员）internal外部描述

    6443

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

    X

    X

    Kubernetes API 服务器

    22623

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

    X

    		 

    机器配置服务器

    注意

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

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

    配置以下条件：

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

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

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

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

    443

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

    X

    X

    HTTPS 流量

    80

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

    X

    X

    HTTP 流量

    注意

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

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

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

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

注意

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

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

global
  log         127.0.0.1 local2
  pidfile     /var/run/haproxy.pid
  maxconn     4000
  daemon
defaults
  mode                    http
  log                     global
  option                  dontlognull
  option http-server-close
  option                  redispatch
  retries                 3
  timeout http-request    10s
  timeout queue           1m
  timeout connect         10s
  timeout client          1m
  timeout server          1m
  timeout http-keep-alive 10s
  timeout check           10s
  maxconn                 3000
listen api-server-6443 1
  bind *:6443
  mode tcp
  option  httpchk GET /readyz HTTP/1.0
  option  log-health-checks
  balance roundrobin
  server bootstrap bootstrap.ocp4.example.com:6443 verify none check check-ssl inter 10s fall 2 rise 3 backup 2
  server master0 master0.ocp4.example.com:6443 weight 1 verify none check check-ssl inter 10s fall 2 rise 3
  server master1 master1.ocp4.example.com:6443 weight 1 verify none check check-ssl inter 10s fall 2 rise 3
  server master2 master2.ocp4.example.com:6443 weight 1 verify none check check-ssl inter 10s fall 2 rise 3
listen machine-config-server-22623 3
  bind *:22623
  mode tcp
  server bootstrap bootstrap.ocp4.example.com:22623 check inter 1s backup 4
  server master0 master0.ocp4.example.com:22623 check inter 1s
  server master1 master1.ocp4.example.com:22623 check inter 1s
  server master2 master2.ocp4.example.com:22623 check inter 1s
listen ingress-router-443 5
  bind *:443
  mode tcp
  balance source
  server worker0 worker0.ocp4.example.com:443 check inter 1s
  server worker1 worker1.ocp4.example.com:443 check inter 1s
listen ingress-router-80 6
  bind *:80
  mode tcp
  balance source
  server worker0 worker0.ocp4.example.com:80 check inter 1s
  server worker1 worker1.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。

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

© 2024 Red Hat, Inc.