2.5. 了解 OpenShift Dedicated 的可用性
可用性和灾难性对于任何应用平台至关重要。OpenShift Dedicated 在多个级别为故障提供了许多保护，但必须为高可用性配置客户部署的应用程序。另外，要考虑可能会出现云供应商中断，可以使用其他选项，例如在多个可用区间部署集群或使用故障转移机制维护多个集群。
2.5.1. 潜在的故障点
OpenShift Container Platform 为防止您的工作负载停机提供了许多功能和选项，但必须正确设计应用程序才能利用这些功能。
OpenShift Dedicated 通过添加 Red Hat Site Reliability engineers (SRE) 支持以及部署多区集群的选项，但存在许多容器或基础架构仍失败的方法，您可以进一步保护您出现常见的 Kubernetes 问题。通过了解潜在的故障点，您可以了解应用程序和集群在各个特定级别上具有弹性的风险，并适当地进行架构。
中断可能会在多个不同的基础架构和集群组件中发生。
2.5.1.1. 容器或 pod 失败
按照设计，Pod 将在短时间内存在。适当扩展服务，以便运行应用程序 pod 的多个实例可防止任何 pod 或容器的问题。节点调度程序还可确保这些工作负载在不同的 worker 节点上分布，以进一步提高弹性。
在考虑可能的 pod 故障时，了解存储如何附加到应用程序上非常重要。连接到单个 pod 的单个持久性卷无法利用 pod 扩展的完整优点，而复制的数据库、数据库服务或共享存储可以：
为了避免在计划维护（如升级）期间中断应用程序，定义 pod 中断预算非常重要。这些是 Kubernetes API 的一部分，可以像其他对象类型一样通过 OpenShift CLI (oc)进行管理。它们允许在操作过程中指定 pod 的安全约束，比如为维护而清空节点。
2.5.1.2. Worker 节点失败
Worker 节点是包含应用程序 pod 的虚拟机。默认情况下，对于单个可用区集群，OpenShift Dedicated 集群至少有四个 worker 节点。如果 worker 节点失败，pod 会重新定位到可正常工作的 worker 节点，只要有足够的容量，直到现有节点出现任何问题解决或节点被替换。更多 worker 节点意味着可以更好地保护单节点停机，并确保在出现节点失败时重新调度 pod 容量。
当对可能的节点故障进行核算时，了解存储如何影响程度也很重要。
2.5.1.3. 集群故障
根据您选择的集群类型，OpenShift Dedicated 集群至少有三个 control plane 节点，以及为高可用性（在一个区或多个区域）预先配置的三个基础架构节点。这意味着 control plane 和基础架构节点对 worker 节点具有相同的弹性，并添加了由红帽完全管理的好处。
如果出现完整的 control plane 节点中断，OpenShift API 将无法正常工作，现有的 worker 节点 pod 不受影响。但是，如果同时存在 pod 或节点中断，则 control plane 节点必须在添加新 pod 或节点前恢复。
在基础架构节点上运行的所有服务都由红帽配置成高度可用，并分布到基础架构节点。如果出现完整的基础架构中断，则这些服务将不可用，直到节点恢复为止。
2.5.1.4. 区失败
来自公有云供应商的区故障会影响所有虚拟组件，如 worker 节点、块存储或共享存储以及特定于单个可用区的负载均衡器。为了防止区故障，OpenShift Dedicated 为在三个可用区（称为多可用区）的集群提供选项。只要有足够的容量，在停机停机时将现有无状态工作负载重新分发到不受影响的区域。
2.5.1.5. 存储故障
如果您部署了有状态应用程序，则存储是一个关键组件，在考虑高可用性时必须考虑这一点。单个块存储 PV 无法发生中断，即使在 pod 级别上也是如此。维护存储的最佳方式是使用复制存储解决方案、不受中断影响的共享存储或独立于集群的数据库服务。
