2.5. 了解 OpenShift Dedicated 的可用性

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

在考虑可能的 pod 故障时，了解存储如何附加到应用程序上非常重要。连接到单个 pod 的单个持久性卷无法利用 pod 扩展的完整优点，而复制的数据库、数据库服务或共享存储可以：

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

Worker 节点是包含应用程序 pod 的虚拟机。默认情况下，对于单个可用区集群，OpenShift Dedicated 集群至少有四个 worker 节点。如果 worker 节点失败，pod 会重新定位到可正常工作的 worker 节点，只要有足够的容量，直到现有节点出现任何问题解决或节点被替换。更多 worker 节点意味着可以更好地保护单节点停机，并确保在出现节点失败时重新调度 pod 容量。

根据您选择的集群类型，OpenShift Dedicated 集群至少有三个 control plane 节点，以及为高可用性（在一个区或多个区域）预先配置的三个基础架构节点。这意味着 control plane 和基础架构节点对 worker 节点具有相同的弹性，并添加了由红帽完全管理的好处。

如果出现完整的 control plane 节点中断，OpenShift API 将无法正常工作，现有的 worker 节点 pod 不受影响。但是，如果同时存在 pod 或节点中断，则 control plane 节点必须在添加新 pod 或节点前恢复。

在基础架构节点上运行的所有服务都由红帽配置成高度可用，并分布到基础架构节点。如果出现完整的基础架构中断，则这些服务将不可用，直到节点恢复为止。

来自公有云供应商的区故障会影响所有虚拟组件，如 worker 节点、块存储或共享存储以及特定于单个可用区的负载均衡器。为了防止区故障，OpenShift Dedicated 为在三个可用区（称为多可用区）的集群提供选项。只要有足够的容量，在停机停机时将现有无状态工作负载重新分发到不受影响的区域。

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