红帽全球峰会第 2 章 带有隔离的双节点
2.1. 准备安装带有隔离的双节点 OpenShift 集群
带有隔离的双节点 OpenShift 集群只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议（SLA）支持，且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能，并有机会在开发阶段提供反馈意见。
有关红帽技术预览功能支持范围的更多信息，请参阅以下链接：
具有隔离的双节点 OpenShift 集群提供可用性(HA)，且对硬件的要求较小。此配置是为部署完整的三节点 control plane 集群的分布式或边缘环境而设计的。
双节点集群不包括计算节点。除了管理集群外，两个 control plane 机器还运行用户工作负载。
隔离由 Pacemaker 管理，它可以使用节点的 Baseboard Management Console (BMC) 来隔离无响应的节点。在隔离无响应节点后，剩余的节点可以安全地继续运行集群，而不会造成资源崩溃的风险。
您可以使用用户置备的基础架构方法或安装程序置备的基础架构方法部署带有隔离的双节点 OpenShift 集群。
带有隔离的双节点 OpenShift 集群需要以下主机：
| 主机 | 描述 |
|---|---|
| 两个 control plane 机器 | control plane 机器运行组成 control plane 的 Kubernetes 和 OpenShift Container Platform 服务。 |
| 一个临时 bootstrap 机器 | 您需要一个 bootstrap 机器，在 control plane 机器上部署 OpenShift Container Platform 集群。您可在安装集群后删除 bootstrap 机器。 |
bootstrap 和 control plane 机器必须使用 Red Hat Enterprise Linux CoreOS(RHCOS)作为操作系统。有关安装 RHCOS 并启动 bootstrap 过程的说明，请参阅安装 RHCOS 并启动 OpenShift Container Platform bootstrap 过程
使用 RHCOS 的要求只适用于用户置备的基础架构部署。对于安装程序置备的基础架构部署，安装程序会自动置备 bootstrap 和 control plane 机器，您不需要手动安装 RHCOS。
2.1.1. 安装带有隔离的双节点 OpenShift 集群的最低资源要求
每台集群机器都必须满足以下最低要求：
| 机器 | 操作系统 | CPU [1] | RAM | Storage | Input/Output Per Second (IOPS) [1] |
|---|---|---|---|---|---|
| bootstrap | RHCOS | 4 | 16 GB | 120 GB | 300 |
| Control plane（控制平面） | RHCOS | 4 | 16 GB | 120 GB | 300 |
- 当未启用并发多线程 (SMT) 或超线程时，一个 CPU 相当于一个物理内核。启用后，使用以下公式来计算对应的比例：（每个内核数的线程）× sockets = CPU。
- OpenShift Container Platform 和 Kubernetes 对磁盘性能敏感，建议使用更快的存储，特别是 control plane 节点上的 etcd。请注意，在许多云平台上，存储大小和 IOPS 可一起扩展，因此您可能需要过度分配存储卷来获取足够的性能。
2.1.2. 用户置备的 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 在计算节点上运行。在没有专用计算节点的集群拓扑中，如双节点或三节点集群，control plane 节点也会执行 worker 标签，因此 Ingress pod 会调度到 control plane 节点上。这些记录必须由集群外的客户端和集群中的所有节点解析。
例如，console |
| bootstrap 机器 |
| DNS A/AAAA 或 CNAME 记录，以及用于标识 bootstrap 机器的 DNS PTR 记录。这些记录必须由集群中的节点解析。 |
| control plane 机器 |
| DNS A/AAAA 或 CNAME 记录，以识别 control plane 节点的每台机器。这些记录必须由集群中的节点解析。 |
在 OpenShift Container Platform 4.4 及更新的版本中，您不需要在 DNS 配置中指定 etcd 主机和 SRV 记录。
您可以使用 dig 命令验证名称和反向名称解析。如需了解详细的 验证步骤，请参阅为用户置备的基础架构验证 DNS 解析 一节。
2.1.2.1. 用户置备的集群的 DNS 配置示例
本节提供 A 和 PTR 记录配置示例，它们满足了在用户置备的基础架构上部署 OpenShift Container Platform 的 DNS 要求。样本不是为选择一个 DNS 解决方案提供建议。
在这个示例中，集群名称为 ocp4，基域是 example.com。
在带有隔离的双节点集群中，control plane 机器也是可调度的 worker 节点。因此，DNS 配置必须只包含两个 control plane 节点。如果您稍后添加计算机器，请为它们提供对应的 A 和 PTR 记录，就像在标准用户置备的安装中一样。
用户置备的集群的 DNS A 记录配置示例
以下示例是 BIND 区域文件，其中显示了用户置备的集群中名称解析的 A 记录示例。
例 2.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
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
;
;
;EOF-
api.ocp4.example.com.: 为 Kubernetes API 提供名称解析。记录引用 API 负载均衡器的 IP 地址。 -
api-int.ocp4.example.com.: 为 Kubernetes API 提供名称解析。记录引用 API 负载均衡器的 IP 地址，用于内部集群通信。 8.apps.ocp4.example.com.: 为通配符路由提供名称解析。记录引用应用程序入口负载均衡器的 IP 地址。应用程序入口负载均衡器以运行 Ingress Controller Pod 的机器为目标。注意在这个示例中，将相同的负载均衡器用于 Kubernetes API 和应用入口流量。在生产环境中，您可以单独部署 API 和应用程序入口负载均衡器，以便可以隔离扩展每个负载均衡器基础架构。
-
bootstrap.ocp4.example.com.: 为 bootstrap 机器提供名称解析。 -
control-plane0.ocp4.example.com.: 为 control plane 机器提供名称解析。
用户置备的集群的 DNS PTR 记录配置示例
以下示例 BIND 区域文件显示了用户置备的集群中反向名称解析的 PTR 记录示例。
例 2.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.
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.
;
;
;EOF-
api.ocp4.example.com.: 为 Kubernetes API 提供反向 DNS 解析。PTR 记录引用 API 负载均衡器的记录名称。 -
api-int.ocp4.example.com.: 为 Kubernetes API 提供反向 DNS 解析。PTR 记录引用 API 负载均衡器的记录名称，用于内部集群通信。 -
bootstrap.ocp4.example.com.: 为 bootstrap 机器提供反向 DNS 解析。 -
control-plane0.ocp4.example.com.: 为 control plane 机器提供 rebootstrap.ocp4.example.com.verse DNS 解析。
OpenShift Container Platform 应用程序通配符不需要 PTR 记录。
2.1.3. 安装程序置备的 DNS 要求
客户端通过 baremetal 网络访问 OpenShift Container Platform 集群节点。网络管理员必须配置子域或子区，其中规范名称扩展是集群名称。
<cluster_name>.<base_domain>例如：
test-cluster.example.comOpenShift Container Platform 包含使用集群成员资格信息来生成 A/AAAA 记录的功能。这会将节点名称解析为其 IP 地址。使用 API 注册节点后，集群可以在不使用 CoreDNS-mDNS 的情况下分散节点信息。这可消除与多播 DNS 关联的网络流量。
CoreDNS 需要 TCP 和 UDP 连接到上游 DNS 服务器才能正常工作。确保上游 DNS 服务器可以从 OpenShift Container Platform 集群节点接收 TCP 和 UDP 连接。
在 OpenShift Container Platform 部署中，以下组件需要 DNS 名称解析：
- The Kubernetes API
- OpenShift Container Platform 应用程序通配符入口 API
A/AAAA 记录用于名称解析，而 PTR 记录用于反向名称解析。Red Hat Enterprise Linux CoreOS(RHCOS)使用反向记录或 DHCP 为所有节点设置主机名。
安装程序置备的安装包括使用集群成员资格信息生成 A/AAAA 记录的功能。这会将节点名称解析为其 IP 地址。在每个记录中，<cluster_name> 是集群名称，<base_domain> 是您在 install-config.yaml 文件中指定的基域。完整的 DNS 记录采用以下形式： <component>.<cluster_name>.<base_domain>.。
| 组件 | 记录 | 描述 |
|---|---|---|
| Kubernetes API |
| A/AAAA 记录和 PTR 记录可识别 API 负载均衡器。这些记录必须由集群外的客户端和集群中的所有节点解析。 |
| Routes |
| 通配符 A/AAAA 记录指的是应用程序入口负载均衡器。应用程序入口负载均衡器以运行 Ingress Controller pod 的节点为目标。默认情况下，Ingress Controller pod 在 worker 节点上运行。这些记录必须由集群外的客户端和集群中的所有节点解析。
例如，console |
您可以使用 dig 命令验证 DNS 解析。
2.1.4. 为带有隔离的双节点集群配置 Ingress 负载均衡器
在安装带有隔离的双节点 OpenShift 集群前，您必须配置外部入口负载均衡器(LB)。Ingress LB 将外部应用程序流量转发到 control plane 节点上运行的 Ingress Controller pod。两个节点都可以主动接收流量。
先决条件
- 您有两个启用了隔离功能的 control plane 节点。
- 您有从负载均衡器到两个 control plane 节点的网络连接。
-
为
api.<cluster_name>.<base_domain>和*.apps.<cluster_name>.<base_domain>创建 DNS 记录。 - 您有一个支持端点上的健康检查的外部负载均衡器。
流程
将负载均衡器配置为转发以下端口的流量：
-
6443: Kubernetes API 服务器 80和443：应用程序入口您必须将流量转发到两个 control plane 节点。
-
- 在负载平衡器上配置健康检查。您必须监控后端端点，以便负载均衡器仅将流量发送到响应的节点。
配置负载均衡器，将流量转发到两个 control plane 节点。以下示例演示了如何配置两个 control plane 节点：
frontend api_frontend bind *:6443 mode tcp default_backend api_backend backend api_backend mode tcp balance roundrobin server cp0 <cp0_ip>:6443 check server cp1 <cp1_ip>:6443 check frontend ingress_frontend bind *:80 bind *:443 mode tcp default_backend ingress_backend backend ingress_backend mode tcp balance roundrobin server cp0 <cp0_ip>:80 check server cp1 <cp1_ip>:80 check server cp0 <cp0_ip>:443 check server cp1 <cp1_ip>:443 check验证负载均衡器配置：
在外部客户端中运行以下命令：
$ curl -k https://api.<cluster_name>.<base_domain>:6443/version从外部客户端，运行以下命令来访问应用程序路由：
$ curl https://<app>.<cluster_name>.<base_domain>
您可以关闭 control plane 节点，并验证负载均衡器是否在其他节点继续服务请求时停止向该节点发送流量。
2.1.5. 为自定义 br-ex 网桥创建清单对象
您必须创建一个清单对象，以在安装后修改集群的网络配置。清单配置 br-ex 网桥，后者管理集群的外部网络连接。
有关创建此清单的说明，请参阅"为自定义 br-ex 网桥创建清单文件"。
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}