通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

Azure Red Hat OpenShift 操作基线指南

Azure Red Hat OpenShift 按需提供高度可缩放的完全托管的 OpenShift 群集。 通过正确设计解决方案并考虑到管理和监视，可以努力实现卓越运营和客户的成功。

设计注意事项

请考虑下列因素：

  • 查看 Azure Red Hat OpenShift 责任矩阵 ，了解如何在 Microsoft、Red Hat 和客户之间共享群集的责任。
  • 请注意 Azure 虚拟机限制 和支持 的区域。 确保有容量可用于部署资源。
  • 请注意在群集中以逻辑方式隔离工作负荷的方法，并在单独的群集中以物理方式隔离工作负荷。
  • 请留意如何帮助 Kubernetes 了解您的工作负载的运行状况。
  • 请注意各种 虚拟机大小 以及使用一个或多个虚拟机的效果。
  • 请注意监视和记录 Azure Red Hat OpenShift 的方法，以便深入了解资源的运行状况并预见到潜在问题。 群集和上面运行的应用程序都可以生成许多事件。 使用警报有助于区分用于历史目的的日志条目和需要立即作的条目。
  • 请注意重要的系统更新和升级。 关键修补程序更新由 Azure Red Hat OpenShift 站点可靠性工程师（SRE）自动应用到群集。 希望预先安装补丁更新的客户可以自由进行。
  • 请注意群集和单个工作负荷的资源限制。
  • 请注意 水平 Pod 自动缩放程序 与 群集自动缩放之间的差异。
  • 查看 支持生命周期 并了解版本支持策略。 Azure Red Hat OpenShift 仅支持 Red Hat OpenShift 容器平台 的当前和以前正式发布的次要版本 。 支持请求要求群集位于受支持的版本中。
  • 查看 群集配置要求 ，以保持群集可支持性。
  • 查看跨命名空间网络，以使用 网络策略保护群集中的流量。

设计建议

  • Azure Red Hat OpenShift 具有丰富的操作员生态系统，应该用于以效率和准确性执行和自动化作活动。
  • 将健康探针添加到 Pod 以监视应用程序运行状况。 确保 Pod 包含 livenessProbe 和 readinessProbe。 使用启动探测来确定应用程序启动的点。
  • 使用足够大的虚拟机规格来容纳多个容器实例，以获取更高密度的优势，但不要大到使群集无法应对节点故障的工作负荷。
  • 使用 允许插件来规范群集功能，这些插件通常用于强制实施安全策略、资源限制或配置要求。
  • 使用 Pod 请求和限制来管理群集中的计算资源。 Pod 的请求和限制会告知 Kubernetes 调度器，后者负责为 Pod 分配计算资源。 使用 限制范围限制项目中的资源消耗。
  • 优化 CPU 和内存请求值，并使用 垂直 Pod 自动缩放程序最大程度地提高群集资源的效率。
  • OpenShift Web 控制台包含节点级别的所有指标。 使用内置 Prometheus 或 Container Insights 集成建立监视过程。
    • Prometheus 已预安装并配置用于 Azure Red Hat OpenShift 4.x 集群。
    • 通过将群集加入到启用 Azure Arc 的 Kubernetes 中，可以启用容器洞察。
    • OpenShift 日志记录 部署日志聚合器、存储和可视化组件。
  • 通过 DevOps 做法和 CI/CD 解决方案（例如 OpenShift 容器平台提供的 Pipelines/GitOps）自动执行应用程序交付过程。
  • 定义 ClusterAutoscaler 和 MachineAutoscaler 资源定义，以描述当资源不足时如何调整群集，从而支持持续运行。 ClusterAutoscaler 考虑群集上所有节点的资源，包括控制平面节点。 扩大群集中的控制平面节点时，会减少自动缩放工作节点的剩余容量。
  • 部署计算机运行状况检查以自动修复计算机池中损坏的计算机。
  • 使用 水平 Pod 自动缩放程序缩放 Pod 以满足需求。
  • 当需要立即采取行动时，请使用警报系统来提供通知：Container Insights 指标警报 或内置的 警报用户界面。

业务连续性和灾难恢复 (BCDR)

你的组织需要设计合适的 Azure Red Hat OpenShift 平台级功能来满足其特定要求。 这些应用程序服务具有与恢复时间目标（RTO）和恢复点目标（RPO）相关的要求。 有多种注意事项可以解决灾难恢复问题。 第一步是为基础结构和应用程序定义服务级别协议（SLA）。 了解 Azure Red Hat OpenShift 的 SLA。 有关每月运行时间计算的信息，请参阅 SLA 详细信息 部分。

BCDR 的设计注意事项

请考虑下列因素：

  • Azure Red Hat OpenShift 群集应使用多个计算机集来提供应用程序的最低可用性级别。
  • 设置 Pod 请求和限制。 设置这些限制可让 Kubernetes：
    • 有效地将 CPU 和内存资源分配给 Pods。
    • 节点上的容器密度更高。
    • 提高硬件使用效率来提高可靠性并降低成本。
  • 将节点分散到所有可用区域，以实现更高的可用性。
    • 选择支持可用性区域的区域。
    • 为了获得完整的区域优势，所有服务依赖项还必须支持区域。 如果依赖服务不支持区域，则区域故障可能会导致该服务失败。 查看在跨区域分布工作负荷时使用的磁盘类型。
    • 为了提高超出可用性区域所能提供的水平的可用性，请在不同的配对地区中运行多个群集。 如果 Azure 资源支持异地冗余，请提供冗余服务所在的次要区域的位置。
  • 始终为应用程序和数据创建备份。
    • 可以有效地复制非有状态服务。
    • 如果需要在群集中存储 状态 ，请经常在配对区域中备份数据。
  • 升级和维护群集。
    • 始终使群集保持最新状态。 检查 群集升级。
    • 请注意发布和弃用流程。
    • 通过时间表控制升级。
    • 查看关键工作负荷的 Canary 推出更新 的需求。
  • 网络连接在故障转移时的处理方式：
  • 对于故障转移的计划内和计划外情况：
    • 设置每个 Azure 服务时，请选择支持灾难恢复的功能。 例如，如果选择 Azure 容器注册表 ，请启用它进行异地复制。 如果某个区域出现故障，仍可以从复制区域拉取映像。
  • 维护工程 DevOps 功能，以实现服务级别目标。

业务连续性和灾难恢复的设计建议

以下是设计最佳做法：

  • Azure Red Hat OpenShift 群集预配了三个控制平面节点和三个或更多个工作器节点。 确保群集是在支持可用性区域的区域中创建的，以便节点分散到各个区域。
  • 若要实现高可用性，请将这些节点部署到不同的可用性区域。 由于每个可用性区域需要不同的计算机集，请至少创建三个计算机集。
  • 不要在控制平面节点上运行额外的工作负荷。 虽然可以在控制平面节点上计划它们，但它将导致额外的资源使用和稳定性问题，这些问题可能会影响整个群集。
  • 创建基础结构计算机集以保存基础结构组件。 将这些计算机应用特定的 Kubernetes 标签，然后更新基础结构组件以仅在这些计算机上运行。
  • 尽可能从容器内部删除服务状态。 而是使用支持多区域复制的 Azure 平台即服务（PaaS）。
  • 部署应指定 Pod 的资源要求。 然后，计划程序可以适当地计划 Pod。 当 Pod 未被调度时，可靠性将显著下降。
  • 在部署中设置多个副本以处理硬件故障等中断。 对于计划内事件（如更新和升级），中断预算可以确保存在所需的 Pod 副本数来处理预期的应用程序负载。
  • 在整个群集中的节点上使用Pod 拓扑约束来自动调度 Pod。
  • 您的应用程序可能会使用存储空间来保存数据，如果需要，应确保跨区域的可用性。
    • 将 RWX 存储与内置 Azure 文件存储类配合使用。
    • 使用 CSI 驱动程序进行存储预配。
  • 创建应用程序备份并计划还原：
  • 估算 Pod 资源限制。 测试和建立基线。 从请求和限制的相等值开始。 然后，逐步调整这些值，直到你建立了可能导致群集不稳定的阈值。 可以在部署清单中指定 Pod 限制。 垂直 Pod 自动缩放程序 优化 CPU 和内存请求值，并可以最大程度地提高群集资源的效率。
    • 内置功能可以处理服务体系结构中的故障和中断。 这些配置有助于简化设计和部署自动化。 当组织为 SLA、RTO 和 RPO 定义标准时，它可以使用 Kubernetes 和 Azure 中内置的服务来实现业务目标。
  • 考虑使用蓝绿发布或金丝雀策略来部署应用程序的新版本。
  • 设置 Pod 优先级 / Pod 中断预算，以限制群集在维护操作中允许关闭的 Pod 副本数量，从而确保服务的可用性。
  • 对服务命名空间强制实施资源配额。 命名空间上的资源配额可确保在部署上正确设置 Pod 请求和限制。
    • 在群集级别设置资源配额可能会导致部署没有适当请求和限制的合作伙伴服务时出现问题。
  • 将容器映像存储在 Azure 容器注册表 中，并将注册表 异地复制到 每个区域。
  • 使用多个区域和对等互连位置来实现 Azure ExpressRoute 连接。 如果发生影响 Azure 区域或对等互连提供程序位置的中断，冗余架构的混合网络体系结构可以帮助确保跨场所互联的不间断。
  • 将区域与全局虚拟网络对等互连。 如果群集需要相互通信，可以通过虚拟网络对等互连将两个虚拟网络相互连接。 此技术将虚拟网络相互互连，以跨Microsoft主干网络（甚至跨不同地理区域）提供高带宽。
  • 使用基于 TCP 的拆分任意广播协议 Azure Front Door，将最终用户及时连接到最近的 Front Door POP（状态点）。 Azure Front Door 的更多功能包括：
    • TLS 终止
    • 自定义域
    • Web 应用程序防火墙
    • URL 重写
    • 会话亲和性

后续步骤

了解 Azure 登陆区域中 平台自动化和 DevOps 的设计注意事项和建议 。

  • Last updated on