3.4. 了解 OpenShift Dedicated 的可用性

可用性和灾难性是任何应用平台的重要方面。OpenShift Dedicated 在多个级别提供了很多对故障的保护,但必须适当地配置客户部署的应用程序才能实现高可用性。另外,为了考虑到可能发生的云供应商中断,还有其它选项可用,例如在多个可用区间部署集群,或维护带有故障转移机制的多个集群。

3.4.1. 潜在的故障点

OpenShift Container Platform 提供了很多功能和选项来保护您的工作负载停机,但必须适当地设计应用程序才能利用这些功能。

OpenShift Dedicated 可通过添加红帽站点可靠性工程师(SRE)支持和选项来部署多区集群来进一步防止您排除许多常见的 Kubernetes 问题,但有多种方法仍可失败。通过了解潜在的故障点,您可以理解风险并适当地将应用程序和集群架构成每个特定级别的弹性。

注意

在多个不同级别的基础架构和集群组件中可能会发生中断。

3.4.1.1. 容器或 pod 失败

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

在考虑可能的 pod 失败时,务必要了解如何在您的应用程序中附加存储。附加到单个 pod 的单个持久性卷无法利用 Pod 扩展的完整优势,而复制的数据库、数据库服务或共享存储可以:

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

3.4.1.2. Worker 节点失败

Worker 节点是包含应用程序 pod 的虚拟机。默认情况下,OpenShift Dedicated 集群至少有四个 worker 节点,用于单个 availability-zone 集群。如果 worker 节点出现故障,pod 会被重新定位到可正常工作的 worker 节点(只要有足够的容量),直到现有节点出现任何问题,或节点已被替换。更多 worker 节点意味着防止单一节点中断,并在节点失败时为重新调度 pod 保障适当的集群容量。

注意

在考虑可能的节点故障时,务必要了解存储受到影响。

3.4.1.3. 集群故障

OpenShift Dedicated 集群至少有三个 control plane 节点,以及三个已预配置高可用性的基础架构节点,可在单个区中,或多个区(根据您选择的集群类型)。这意味着,control plane 和基础架构节点具有相同的 worker 节点的弹性,增加了红帽的完全管理的好处。

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

红帽将运行在基础架构节点上运行的所有服务都配置为具有高可用性,并在基础架构节点之间分布。如果完全中断基础架构,在这些节点恢复之前,这些服务将不可用。

3.4.1.4. 区域失败

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

3.4.1.5. 存储故障

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