红帽全球峰会3.4. 具有用户置备基础架构的集群的要求
对于包含用户置备的基础架构的集群，您必须部署所有所需的机器。
本节论述了在用户置备的基础架构上部署 OpenShift Container Platform 的要求。
3.4.1. 集群安装所需的机器
最小的 OpenShift Container Platform 集群需要以下主机：
| 主机 | 描述 |
|---|---|
| 一个临时 bootstrap 机器 | 集群需要 bootstrap 机器在三台 control plane 机器上部署 OpenShift Container Platform 集群。您可在安装集群后删除 bootstrap 机器。 |
| 三台 control plane 机器 | control plane 机器运行组成 control plane 的 Kubernetes 和 OpenShift Container Platform 服务。 |
| 至少两台计算机器，也称为 worker 机器。 | OpenShift Container Platform 用户请求的工作负载在计算机器上运行。 |
要提高集群的高可用性，请在至少两台物理机器的不同 z/VM 实例中分发 control plane 机器。
bootstrap、control plane 和计算机器必须使用 Red Hat Enterprise Linux CoreOS(RHCOS)作为操作系统。
请注意，RHCOS 基于 Red Hat Enterprise Linux(RHEL) 9.2，并继承其所有硬件认证和要求。查看 红帽企业 Linux 技术功能和限制。
3.4.2. 集群安装的最低资源要求
每台集群机器都必须满足以下最低要求：
| 机器 | 操作系统 | 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。
从 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 Z 系统环境
您可以在以下 IBM 硬件上安装 OpenShift Container Platform 版本 4.13：
- IBM z16 （所有型号）、IBM z15 （所有型号）、IBM z14 （所有型号）
- IBM® LinuxONE 4 （所有型号）、IBM® LinuxONE （所有型号）、IBM® LinuxONE Emperor II、IBM® LinuxONE Rockhopper II
硬件要求
- Linux(IFL)等效的、启用了 SMT2 的 Linux 集成设施，每个群集都启用了 SMT2。
-
至少一个网络连接连接到
LoadBalancer服务，并为集群外的流量提供数据。
您可以使用专用或共享的 IFL 来分配足够的计算资源。资源共享是 IBM Z 的一个关键优势。但是，您必须正确调整每个虚拟机监控程序层上的容量，并确保每个 OpenShift Container Platform 集群都有充足的资源。
由于集群的整体性能会受到影响，用于设置 OpenShift Container Platform 集群的 LPAR 必须提供足够的计算容量。就此而言，管理程序级别上的 LPAR 权重管理、授权和 CPU 共享扮演着重要角色。
操作系统要求
- 一个 z/VM 7.2 或更高版本实例
在 z/VM 实例中设置：
- 用于 OpenShift Container Platform control plane 机器的三台客户机虚拟机
- 用于 OpenShift Container Platform 计算机器的两个客户机虚拟机
- 一个客户虚拟机作为临时 OpenShift Container Platform bootstrap 机器
IBM Z 网络连接要求
要在 z/VM 中安装 IBM Z，您需要使用第 2 层模式的单一 z/VM 虚拟 NIC。您还需要：
- 直接附加的 OSA 或 RoCE 网络适配器
- z/VM VSwitch 设置。对于首选设置，请使用 OSA 链接聚合。
z/VM 客户机虚拟机的磁盘存储
- 附加了 FICON 的磁盘存储(DASD)。可以是 z/VM Minidisks、fullpack Minidisks 或专用 DASD，它们都必须格式化为 CDL（默认 CDL）。要达到 Red Hat Enterprise Linux CoreOS(RHCOS)安装所需的最小 DASD 大小，您需要扩展地址卷(EAV)。如果可用，请使用 HyperPAV 来确保最佳性能。
- FCP 连接的磁盘存储
存储/主内存
- OpenShift Container Platform control plane 机器需要 16 GB
- OpenShift Container Platform 计算机器需要 8 GB
- 临时 OpenShift Container Platform bootstrap 机器需要 16 GB
3.4.4. 首选 IBM Z 系统环境
硬件要求
- 三个 LPARS，每个都相当于 6 个 IFL（每个集群启用了 SMT2）。
-
两个网络连接连接到
LoadBalancer服务，并为集群外的流量提供数据。 - HiperSockets，可直接作为设备附加到节点，或通过使用 一 个 z/VM VSWITCH 进行桥接以对 z/VM 客户机进行透明连接。要将 HiperSockets 直接连接到节点，您必须通过 RHEL 8 客户机设置到外部网络的网关来桥接到 HiperSockets 网络。
操作系统要求
- 两个或多个 z/VM 7.2 或更高版本实例以实现高可用性
在 z/VM 实例中设置：
- 用于 OpenShift Container Platform control plane 机器的三台客户虚拟机，每个 z/VM 实例一个。
- 至少 6 个用于 OpenShift Container Platform 计算机器的虚拟机，分布在 z/VM 实例中。
- 一个客户虚拟机作为临时 OpenShift Container Platform bootstrap 机器。
-
要确保在过量使用的环境中集成组件可用，使用 CP 命令
SET SHARE增加 control plane 的优先级。如果存在基础架构节点，则对它们执行相同的操作。请参阅 IBM 文档中的SET SHARE.
IBM Z 网络连接要求
要在 z/VM 中安装 IBM Z，您需要使用第 2 层模式的单一 z/VM 虚拟 NIC。您还需要：
- 直接附加的 OSA 或 RoCE 网络适配器
- z/VM VSwitch 设置。对于首选设置，请使用 OSA 链接聚合。
z/VM 客户机虚拟机的磁盘存储
- 附加了 FICON 的磁盘存储(DASD)。可以是 z/VM Minidisks、fullpack Minidisks 或专用 DASD，它们都必须格式化为 CDL（默认 CDL）。要达到 Red Hat Enterprise Linux CoreOS(RHCOS)安装所需的最小 DASD 大小，您需要扩展地址卷(EAV)。如果可用，请使用 HyperPAV 和高性能 FICON(zHPF)来确保最佳性能。
- FCP 连接的磁盘存储
存储/主内存
- OpenShift Container Platform control plane 机器需要 16 GB
- OpenShift Container Platform 计算机器需要 8 GB
- 临时 OpenShift Container Platform bootstrap 机器需要 16 GB
3.4.5. 证书签名请求管理
在使用您置备的基础架构时，集群只能有限地访问自动机器管理，因此您必须提供一种在安装后批准集群证书签名请求 (CSR) 的机制。kube-controller-manager 只能批准 kubelet 客户端 CSR。machine-approver 无法保证使用 kubelet 凭证请求的提供证书的有效性，因为它不能确认是正确的机器发出了该请求。您必须决定并实施一种方法，以验证 kubelet 提供证书请求的有效性并进行批准。
其他资源
- 请参阅 IBM 文档中的使用 z/VM 虚拟交换机桥接 HiperSockets LAN。
- 请参阅在 z/VM 上的 Linux 客户端上扩展 HyperPAV 别名设备 以获得性能优化。
- 有关 LPAR 权重管理和权利的信息，请参阅 LPAR 性能的主题。
- IBM Z 和 IBM® LinuxONE 环境的推荐主机实践
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 集群组件进行通信。每台机器都必须能够解析集群中所有其他机器的主机名。
本节详细介绍了所需的端口。
| 协议 | port | 描述 |
|---|---|---|
| ICMP | N/A | 网络可访问性测试 |
| TCP |
| 指标 |
|
|
主机级别的服务，包括端口 9 | |
|
| Kubernetes 保留的默认端口 | |
|
| openshift-sdn | |
| UDP |
| VXLAN |
|
| Geneve | |
|
|
主机级别的服务，包括端口 | |
|
| IPsec IKE 数据包 | |
|
| IPsec NAT-T 数据包 | |
|
|
UDP 端口
如果配置了外部 NTP 时间服务器，需要打开 UDP 端口 | |
| TCP/UDP |
| Kubernetes 节点端口 |
| ESP | N/A | IPsec Encapsulating Security Payload(ESP) |
| 协议 | port | 描述 |
|---|---|---|
| TCP |
| Kubernetes API |
| 协议 | port | 描述 |
|---|---|---|
| TCP |
| etcd 服务器和对等端口 |
用户置备的基础架构的 NTP 配置
OpenShift Container Platform 集群被配置为默认使用公共网络时间协议(NTP)服务器。如果要使用本地企业 NTP 服务器，或者集群部署在断开连接的网络中，您可以将集群配置为使用特定的时间服务器。如需更多信息，请参阅配置 chrony 时间服务 的文档。
其他资源
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)。
用户置备的 OpenShift Container Platform 集群需要以下 DNS 记录，这些记录必须在安装前就位。在每个记录中，<cluster_name> 是集群名称，<base_domain> 是您在 install-config.yaml 文件中指定的基域。完整的 DNS 记录采用以下形式： <component>.<cluster_name>.<base_domain>.。
| 组件 | 记录 | 描述 |
|---|---|---|
| Kubernetes API |
| DNS A/AAAA 或 CNAME 记录，以及用于标识 API 负载均衡器的 DNS PTR 记录。这些记录必须由集群外的客户端和集群中的所有节点解析。 |
|
| DNS A/AAAA 或 CNAME 记录，以及用于内部标识 API 负载均衡器的 DNS PTR 记录。这些记录必须可以从集群中的所有节点解析。 重要 API 服务器必须能够根据 Kubernetes 中记录的主机名解析 worker 节点。如果 API 服务器无法解析节点名称，则代理的 API 调用会失败，且您无法从 pod 检索日志。 | |
| Routes |
| 通配符 DNS A/AAAA 或 CNAME 记录，指向应用程序入口负载均衡器。应用程序入口负载均衡器以运行 Ingress Controller Pod 的机器为目标。默认情况下，Ingress Controller Pod 在计算机器上运行。这些记录必须由集群外的客户端和集群中的所有节点解析。
例如，console |
| bootstrap 机器 |
| DNS A/AAAA 或 CNAME 记录，以及用于标识 bootstrap 机器的 DNS PTR 记录。这些记录必须由集群中的节点解析。 |
| control plane 机器 |
| DNS A/AAAA 或 CNAME 记录，以识别 control plane 节点的每台机器。这些记录必须由集群中的节点解析。 |
| 计算机器 |
| 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
OpenShift Container Platform 应用程序通配符不需要 PTR 记录。
3.4.8. 用户置备的基础架构的负载均衡要求
在安装 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。
在负载均衡器的前端和后端配置以下端口：
表 3.7. API 负载均衡器 port 后端机器（池成员） internal 外部 描述 6443Bootstrap 和 control plane.bootstrap 机器初始化集群 control plane 后，您要从负载均衡器中删除 bootstrap 机器。您必须为 API 服务器健康检查探测配置
/readyz端点。X
X
Kubernetes API 服务器
22623Bootstrap 和 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 加密的应用程序的性能。
在负载均衡器的前端和后端配置以下端口：
表 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。
