了解 OpenShift Dedicated 的可用性

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

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

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

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

OpenShift Dedicated集群至少具有三个预配置为高可用性的控制平面节点和三个基础设施节点，具体取决于您选择的集群类型，这些节点可以位于单个区域或多个区域中。这意味着控制平面和基础设施节点与工作节点具有相同的弹性，并且额外的好处是完全由Red Hat管理。

如果控制平面节点完全发生故障，OpenShift API将无法运行，而现有工作节点Pod不会受到影响。但是，如果同时发生Pod或节点故障，则必须先恢复控制平面节点，然后才能添加或调度新的Pod或节点。

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

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

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