第 3 章 用户置备的基础架构
3.1. 用户置备的基础架构的 vSphere 安装要求
在您置备的基础架构上开始安装前，请确保您的 vSphere 环境满足以下安装要求。
3.1.1. VMware vSphere 基础架构要求
您必须在满足您使用的组件要求的 VMware vSphere 实例之一上安装 OpenShift Container Platform 集群：
- Version 7.0 Update 2 或更新版本，或 VMware Cloud Foundation 4.3 或更新版本
- Version 8.0 Update 1 或更新版本，或 VMware Cloud Foundation 5.0 或更新版本
这两个版本都支持 Container Storage Interface (CSI) 迁移，它在 OpenShift Container Platform 4.14 中默认启用。
您可以在内部或 VMware Cloud 验证的供应商中托管 VMware vSphere 基础架构，以满足下表中概述的要求：
| 虚拟环境产品 | 所需的版本 |
|---|---|
| VMware 虚拟硬件 | 15 或更高版本 |
| vSphere ESXi 主机 | 7.0 Update 2 或更新版本，或 VMware Cloud Foundation 4.3 或更新版本，8.0 Update 1 或更新版本，或r VMware Cloud Foundation 5.0 或更新版本 |
| vCenter 主机 | 7.0 Update 2 或更新版本，或 VMware Cloud Foundation 4.3 或更新版本，8.0 Update 1 或更新版本，或r VMware Cloud Foundation 5.0 或更新版本 |
您必须确保在安装 OpenShift Container Platform 前同步 ESXi 主机上的时间。请参阅 VMware 文档中的 编辑主机时间配置。
| 组件 | 最低支持版本 | 描述 |
|---|---|---|
| 虚拟机监控程序（Hypervisor） | vSphere 7.0 Update 2 或更新版本，VMware Cloud Foundation 4.3 或更新版本，vSphere 8.0 Update 1 或更新版本，或 VMware Cloud Foundation 5.0 或更新版本，带有 virtual hardware version 15 | 此 hypervisor 版本是 Red Hat Enterprise Linux CoreOS (RHCOS) 支持的最低版本。有关与 RHCOS 兼容的 Red Hat Enterprise Linux (RHEL) 最新版本中支持的硬件的更多信息，请参阅红帽客户门户网站中的硬件。 |
| 可选： Networking(NSX-T) | vSphere 7.0 Update 2 或更新版本，或 VMware Cloud Foundation 4.3 或更新版本，vSphere 8.0 Update 1 或更新版本，或 VMware Cloud Foundation 5.0 或更新版本 | 有关 NSX 和 OpenShift Container Platform 兼容性的更多信息，请参阅 VMware 的 NSX 容器插件文档中的发行注记部分。 |
| CPU 微架构 | x86-64-v2 或更高版本 | OpenShift 4.13 及更高版本基于 RHEL 9.2 主机操作系统，这提高了 x86-64-v2 的微架构要求。请参阅 RHEL Microarchitecture 要求文档。您可以按照这个 KCS 文章中介绍的步骤验证兼容性。 |
为确保在 Oracle® Cloud Infrastructure (OCI) 和 Oracle® Cloud VMware Solution (OCVS) 服务上运行的集群工作负载的最佳性能条件，请确保块卷的卷性能单元 (VPU) 为您的工作负载的大小。
以下列表提供了一些有关选择特定性能需要 VPU 的指导信息：
- 测试或概念验证环境：100 GB，20 到 30 个 VPU。
- 基础生产环境：500 GB 和 60 个 VPU.
- 高度使用生产环境：超过 500 GB，100 个或更多 VPU。
考虑分配额外的 VPU，以便为更新和扩展活动提供足够的容量。请参阅块卷性能级别(Oracle 文档)。
3.1.2. VMware vSphere CSI Driver Operator 要求
要安装 vSphere CSI Driver Operator，必须满足以下要求：
- VMware vSphere 版本: 7.0 Update 2 或更新版本，或 VMware Cloud Foundation 4.3 或更新版本，8.0 Update 1 或更新版本，或 VMware Cloud Foundation 5.0 或更新版本
- vCenter 版本: 7.0 Update 2 或更新版本，或 VMware Cloud Foundation 4.3 或更新版本，8.0 Update 1 或更新版本，或 VMware Cloud Foundation 5.0 或更新版本
- 硬件版本 15 或更高版本的虚拟机
- 集群中还没有安装第三方 vSphere CSI 驱动程序
如果集群中存在第三方 vSphere CSI 驱动程序，OpenShift Container Platform 不会覆盖它。存在第三方 vSphere CSI 驱动程序可防止 OpenShift Container Platform 更新到 OpenShift Container Platform 4.13 或更高版本。
只有在安装清单中使用 platform: vsphere 部署的集群中才支持 VMware vSphere CSI Driver Operator。
其他资源
- 要删除第三方 vSphere CSI 驱动程序，请参阅删除第三方 vSphere CSI 驱动程序。
- 要为您的 vSphere 节点更新硬件版本，请参阅在 vSphere 中运行的节点上更新硬件。
3.1.3. 具有用户置备基础架构的集群的要求
对于包含用户置备的基础架构的集群，您必须部署所有所需的机器。
本节论述了在用户置备的基础架构上部署 OpenShift Container Platform 的要求。
3.1.3.1. vCenter 要求
在使用您提供的基础架构的 vCenter 上安装 OpenShift Container Platform 集群前，您必须准备您的环境。
所需的 vCenter 帐户权限
要在 vCenter 中安装 OpenShift Container Platform 集群，您的 vSphere 帐户必须包含读取和创建所需资源的权限。使用具有全局管理特权的帐户是访问所有所需权限的最简单方法。
例 3.1. 在 vSphere API 中安装所需的角色和权限
| 适用于角色的 vSphere 对象 | 必要时 | vSphere API 中所需的权限 |
|---|---|---|
| vSphere vCenter | Always |
|
| vSphere vCenter 集群 | 如果在集群 root 中创建虚拟机 |
|
| vSphere vCenter 资源池 | 如果提供了现有的资源池 |
|
| vSphere Datastore | Always |
|
| vSphere 端口组 | Always |
|
| 虚拟机文件夹 | Always |
|
| vSphere vCenter Datacenter |
如果安装程序创建虚拟机文件夹对于 UPI，如果集群没有使用 Machine API，则 |
|
例 3.2. 在 vCenter 图形用户界面 (GUI) 中安装所需的角色和权限
| 适用于角色的 vSphere 对象 | 必要时 | vCenter GUI 中所需的权限 |
|---|---|---|
| vSphere vCenter | Always |
|
| vSphere vCenter 集群 | 如果在集群 root 中创建虚拟机 |
|
| vSphere vCenter 资源池 | 如果提供了现有的资源池 |
|
| vSphere Datastore | Always |
|
| vSphere 端口组 | Always |
|
| 虚拟机文件夹 | Always |
|
| vSphere vCenter Datacenter |
如果安装程序创建虚拟机文件夹对于 UPI，如果集群没有使用 Machine API，则 |
|
此外，用户需要一些 ReadOnly 权限，一些角色需要相应的权限来将权限代理到子对象。这些设置会因您是否将集群安装到现有文件夹而有所不同。
例 3.3. 所需的权限和传播设置
| vSphere object | 必要时 | 传播到子对象 | 所需的权限 |
|---|---|---|---|
| vSphere vCenter | Always | False | 列出所需的权限 |
| vSphere vCenter Datacenter | 现有文件夹 | False |
|
| 安装程序创建文件夹 | True | 列出所需的权限 | |
| vSphere vCenter 集群 | 现有资源池 | False |
|
| 集群 root 中的虚拟机 | True | 列出所需的权限 | |
| vSphere vCenter 数据存储 | Always | False | 列出所需的权限 |
| vSphere Switch | Always | False |
|
| vSphere 端口组 | Always | False | 列出所需的权限 |
| vSphere vCenter 虚拟机文件夹 | 现有文件夹 | True | 列出所需的权限 |
| vSphere vCenter 资源池 | 现有资源池 | True | 列出所需的权限 |
有关只使用所需权限创建帐户的更多信息，请参阅 vSphere 文档中的 vSphere 权限和用户管理任务。
将 OpenShift Container Platform 与 vMotion 搭配使用
如果要在 vSphere 环境中使用 vMotion，请在安装 OpenShift Container Platform 集群前考虑以下内容。
- 使用 Storage vMotion 可能会导致问题且不受支持。
使用 VMware compute vMotion 为 OpenShift Container Platform 计算机器和 control plane 机器迁移工作负载通常被支持，通常意味着您满足 vMotion 的所有 VMware 最佳实践。
为了帮助确保计算和 control plane 节点的正常运行时间，请确保遵循 VMware 最佳实践进行 vMotion，并使用 VMware 反关联性规则提高 OpenShift Container Platform 在维护或硬件问题期间的可用性。
有关 vMotion 和 anti-affinity 规则的更多信息，请参阅 VMware vSphere 文档以了解 vMotion 网络要求和虚拟机反关联性规则。
- 如果您在 pod 中使用 VMware vSphere 卷，请手动或通过 Storage vMotion 在数据存储间迁移虚拟机，这会导致 OpenShift Container Platform 持久性卷(PV)对象中的无效引用，这可能会导致数据丢失。
OpenShift Container Platform 不支持在数据存储间有选择地迁移 VMDK，使用数据存储集群进行虚拟机置备或动态或静态置备 PV，或使用作为数据存储集群一部分的数据存储来动态或静态置备 PV。
重要您可以指定数据存储集群中存在的任何数据存储路径。默认情况下，使用 Storage vMotion 的存储分布式资源调度程序(SDRS)会自动为数据存储集群启用。红帽不支持 Storage vMotion，因此您必须禁用 Storage DRS 以避免 OpenShift Container Platform 集群的数据丢失问题。
如果需要在多个数据存储间指定虚拟机，请使用
数据存储对象在集群install-config.yaml配置文件中指定故障域。如需更多信息，请参阅"VMware vSphere 区域和区启用"。
集群资源
当您部署使用您提供的基础架构的 OpenShift Container Platform 集群时，您必须在 vCenter 实例中创建以下资源：
- 1 个文件夹
- 1 标签类别
- 1 标签
虚拟机：
- 1 个模板
- 1 个临时 bootstrap 节点
- 3 个 control plane 节点
- 3 个计算机器
虽然这些资源使用 856 GB 存储，但 bootstrap 节点会在集群安装过程中销毁。使用标准集群至少需要 800 GB 存储。
如果部署更多计算机器，OpenShift Container Platform 集群将使用更多存储。
集群限制
可用资源因集群而异。vCenter 中可能的集群数量主要受可用存储空间以及对所需资源数量的限制。确保考虑集群创建的 vCenter 资源的限制和部署集群所需的资源，如 IP 地址和网络。
网络要求
您可以在网络中使用 DHCP，配置 DHCP 服务器来为集群中的机器分配基于持久性的 IP 地址。在 DHCP 租期中，您必须将 DHCP 配置为使用默认网关。
如果要使用静态 IP 地址置备节点，则不需要将 DHCP 用于网络。
如果您要为在用户置备的基础架构上安装的集群在不同 VLAN 中指定节点或节点组，您需要确保集群中的机器满足用户置备的基础架构的"网络连接要求"部分中支持的要求。
如果要安装到受限环境中，受限网络中的虚拟机必须有权访问 vCenter，以便它可以置备和管理节点、持久性卷声明 (PVC) 和其他资源。
确保集群中的每个 OpenShift Container Platform 节点都可以访问通过 DHCP 发现的网络时间协议 (NTP) 服务器。没有 NTP 服务器即可安装。但是，异步服务器时钟将导致错误，NTP 服务器会阻止。
另外，在安装 OpenShift Container Platform 集群前，您必须创建以下网络资源：
所需的 IP 地址
DNS 记录
您必须在适当的 DNS 服务器中为托管 OpenShift Container Platform 集群的 vCenter 实例创建两个静态 IP 地址的 DNS 记录。在每个记录中，<cluster_name> 是集群名称，<base_domain> 是您 在安装集群时指定的集群基域。完整的 DNS 记录采用以下形式： <component>.<cluster_name>.<base_domain>.。
| 组件 | 记录 | 描述 |
|---|---|---|
| API VIP |
| 此 DNS A/AAAA 或 CNAME 记录必须指向 control plane 机器的负载均衡器。此记录必须由集群外的客户端和集群中的所有节点解析。 |
| Ingress VIP |
| 通配符 DNS A/AAAA 或 CNAME 记录，指向以运行入口路由器 Pod 的机器（默认为 worker 节点）为目标的负载均衡器。此记录必须由集群外的客户端和集群中的所有节点解析。 |
其他资源
3.1.3.2. 集群安装所需的机器
最小的 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 用户请求的工作负载在计算机器上运行。 |
要保持集群的高可用性，请将独立的物理主机用于这些集群机器。
bootstrap 和 control plane 机器必须使用 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，并继承其所有硬件认证和要求。查看 红帽企业 Linux 技术功能和限制。
3.1.3.3. 集群安装的最低资源要求
每台集群机器都必须满足以下最低要求：
| 机器 | 操作系统 | vCPU [1] | 虚拟内存 | Storage | 每秒输入/输出 (IOPS) [2] |
|---|---|---|---|---|---|
| bootstrap | RHCOS | 4 | 16 GB | 100 GB | 300 |
| Control plane（控制平面） | RHCOS | 4 | 16 GB | 100 GB | 300 |
| Compute | RHCOS、RHEL 8.6 及更新版本 [3] | 2 | 8 GB | 100 GB | 300 |
- 当未启用并发多线程 (SMT) 或超线程时，一个 vCPU 相当于一个物理内核。启用后，使用以下公式来计算对应的比例：（每个内核数的线程）× sockets = vCPU。
- OpenShift Container Platform 和 Kubernetes 对磁盘性能非常敏感，建议使用更快的存储速度，特别是 control plane 节点上需要 10 ms p99 fsync 持续时间的 etcd。请注意，在许多云平台上，存储大小和 IOPS 可一起扩展，因此您可能需要过度分配存储卷来获取足够的性能。
- 与所有用户置备的安装一样，如果您选择在集群中使用 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 支持使用它。
其他资源
3.1.3.4. 加密虚拟机的要求
您可以通过满足以下要求，在安装 OpenShift Container Platform 4.14 前对虚拟机进行加密。
您已在 vSphere 中配置了标准密钥供应商。如需更多信息，请参阅在 vCenter 服务器中添加 KMS。
重要不支持 vCenter 中的原生密钥供应商。如需更多信息，请参阅 vSphere 原生密钥提供程序概述。
- 您已在托管集群的所有 ESXi 主机上启用了主机加密模式。如需更多信息，请参阅启用主机加密模式。
- 您有一个启用了所有加密权限的 vSphere 帐户。如需更多信息，请参阅 Cryptographic Operations Privileges。
当您在标题为"安装 RHCOS 并启动 OpenShift Container Platform bootstrap 过程"的部分中部署 OVF 模板时，在为 OVF 模板选择存储时选择 "Encrypt this virtual virtual machine"。完成集群安装后，创建一个使用您用来加密虚拟机的加密存储策略的存储类。
其他资源
3.1.3.5. 证书签名请求管理
在使用您置备的基础架构时，集群只能有限地访问自动机器管理，因此您必须提供一种在安装后批准集群证书签名请求 (CSR) 的机制。kube-controller-manager 只能批准 kubelet 客户端 CSR。machine-approver 无法保证使用 kubelet 凭证请求的提供证书的有效性，因为它不能确认是正确的机器发出了该请求。您必须决定并实施一种方法，以验证 kubelet 提供证书请求的有效性并进行批准。
3.1.3.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.1.3.6.1. 通过 DHCP 设置集群节点主机名
在 Red Hat Enterprise Linux CoreOS(RHCOS)机器上，主机名是通过 NetworkManager 设置的。默认情况下，机器通过 DHCP 获取其主机名。如果主机名不是由 DHCP 提供，请通过内核参数或者其它方法进行静态设置，请通过反向 DNS 查找获取。反向 DNS 查找在网络初始化后进行，可能需要一些时间来解决。其他系统服务可以在此之前启动，并将主机名检测为 localhost 或类似的内容。您可以使用 DHCP 为每个集群节点提供主机名来避免这种情况。
另外，通过 DHCP 设置主机名可以绕过实施 DNS split-horizon 的环境中的手动 DNS 记录名称配置错误。
3.1.3.6.2. 网络连接要求
您必须配置机器之间的网络连接，以允许 OpenShift Container Platform 集群组件进行通信。每台机器都必须能够解析集群中所有其他机器的主机名。
本节详细介绍了所需的端口。
在连接的 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 时间服务 的文档。
如果 DHCP 服务器提供 NTP 服务器信息，Red Hat Enterprise Linux CoreOS(RHCOS)机器上的 chrony 时间服务会读取信息，并可以把时钟与 NTP 服务器同步。
其他资源
3.1.3.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>.。
| 组件 | 记录 | 描述 |
|---|---|---|
| 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.1.3.7.1. 用户置备的集群的 DNS 配置示例
本节提供 A 和 PTR 记录配置示例，它们满足了在用户置备的基础架构上部署 OpenShift Container Platform 的 DNS 要求。样本不是为选择一个 DNS 解决方案提供建议。
在这个示例中，集群名称为 ocp4，基域是 example.com。
用户置备的集群的 DNS A 记录配置示例
以下示例是 BIND 区域文件，其中显示了用户置备的集群中名称解析的 A 记录示例。
例 3.4. 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.5. 反向记录的 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.1.3.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.10. 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.11. 应用程序入口负载均衡器 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.1.3.8.1. 用户置备的集群的负载均衡器配置示例
本节提供了一个满足用户置备集群的负载均衡要求的 API 和应用程序入口负载均衡器配置示例。示例是 HAProxy 负载均衡器的 /etc/haproxy/haproxy.cfg 配置。这个示例不是为选择一个负载平衡解决方案提供建议。
在这个示例中，将相同的负载均衡器用于 Kubernetes API 和应用入口流量。在生产环境中，您可以单独部署 API 和应用程序入口负载均衡器，以便可以隔离扩展每个负载均衡器基础架构。
如果您使用 HAProxy 作为负载均衡器，并且 SELinux 设置为 enforcing，您必须通过运行 setsebool -P haproxy_connect_any=1 来确保 HAProxy 服务可以绑定到配置的 TCP 端口。
例 3.6. 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。
