关于 AWS 上 Red Hat OpenShift 服务的可用性

根据设计，Pod 的存在时间很短。适当地扩展服务，以便运行应用程序 Pod 的多个实例，可以防止任何单个 Pod 或容器出现问题。OpenShift 节点调度程序还可以确保这些工作负载分布在不同的工作节点上，以进一步提高弹性。

在考虑可能的 Pod 故障时，还必须了解存储如何连接到您的应用程序。连接到单个 Pod 的单个持久卷无法充分利用 Pod 扩展的全部好处，而复制数据库、数据库服务或共享存储则可以。

为了避免在计划的维护（例如升级）期间中断您的应用程序，定义 Pod 中断预算非常重要。这些是 Kubernetes API 的一部分，可以使用 `oc` 命令（如其他对象类型）进行管理。它们允许在操作期间指定对 Pod 的安全约束，例如为了维护而清空节点。

工作节点是包含应用程序 Pod 的虚拟机。默认情况下，单可用区集群的 ROSA 集群至少有两个工作节点。如果工作节点发生故障，只要有足够的容量，Pod 就会重新定位到正常运行的工作节点，直到解决现有节点的任何问题或更换节点为止。更多的工作节点意味着针对单节点停机的更多保护，并确保在节点发生故障时为重新调度的 Pod 提供足够的集群容量。

单 AZ ROSA 集群在私有子网的同一可用区 (AZ) 中至少有三个控制平面和两个基础设施节点。

多 AZ ROSA 集群至少有三个控制平面节点和三个基础设施节点，这些节点预先配置为高可用性，具体取决于您选择的集群类型，它们可能位于单个区域或多个区域中。控制平面和基础设施节点具有与工作节点相同的弹性，并且还具有由 Red Hat 完全管理的额外优势。

如果发生完整的控制平面中断，OpenShift API 将无法运行，并且现有工作节点 Pod 不会受到影响。但是，如果同时还存在 Pod 或节点中断，则控制平面必须恢复才能添加或调度新的 Pod 或节点。

在基础设施节点上运行的所有服务都由 Red Hat 配置为高可用性并在基础设施节点之间分布。如果发生完全的基础设施中断，则这些服务将不可用，直到这些节点恢复为止。

来自 AWS 的区域故障会影响所有虚拟组件，例如特定于单个可用区的 worker 节点、块存储或共享存储以及负载均衡器。为了防止区域故障，ROSA 提供了跨三个可用区分布的集群的选项，称为多可用区集群。如果发生中断，现有的无状态工作负载将重新分配到不受影响的区域，只要有足够的容量。

如果您已部署有状态应用程序，则存储是一个关键组件，在考虑高可用性时必须考虑在内。单个块存储 PV 甚至无法承受 Pod 级别的中断。维护存储可用性的最佳方法是使用复制存储解决方案、不受中断影响的共享存储或独立于集群的数据库服务。