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