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

Azure 容器应用中的可靠性

Azure 容器应用 是一项完全托管的无服务器容器托管服务,用于部署微服务和容器化应用程序。

使用 Azure 时, 可靠性是共同的责任。 Microsoft提供了一系列功能来支持复原和恢复。 你负责了解这些功能如何在你使用的所有服务中工作,并选择满足业务目标和运行时间目标所需的功能。

本文介绍如何使容器应用能够灵活应对各种潜在的中断和问题,包括暂时性故障、可用性区域中断、区域中断和服务维护。 它还介绍如何使用备份从其他类型的问题中恢复,并突出显示有关容器应用服务级别协议(SLA)的关键信息。

生产部署建议

若要了解如何部署容器应用以支持解决方案的可靠性要求,以及可靠性如何影响体系结构的其他方面,请参阅 Azure Well-Architected Framework 中容器应用的体系结构最佳做法

可靠性体系结构概述

使用容器应用时,部署充当基础部署单元 的环境 ,并在一组容器应用周围定义安全边界。 环境用于配置核心设置,包括可用性区域支持和网络配置。 这两种类型的环境是工作负荷配置环境和消耗型环境。 有关详细信息,请参阅 容器应用中的计算和计费结构

可以在单个环境中部署多个 应用 。 每个应用运行一个或多个 容器。 环境还可以运行一个或多个表示非交互任务的 作业。 有关详细信息,请参阅 容器应用中的容器容器应用中的作业

每个应用都有一个或多个副本,这些 副本表示应用的运行实例。 可以控制应用缩放方式,包括副本的最小和最大数量,以及应用如何动态添加和删除副本。 平台计划程序可确保在满足最低副本计数要求的同时,在物理主机之间实现最佳分布。 有关详细信息,请参阅在容器应用中设置缩放规则

此图显示了运行具有三个副本的应用的容器应用环境。

容器应用使用不同的功能支持应用程序的可靠性:

  • 自动运行状况监视: 内置入口控制器自动对正常副本的流量进行负载均衡。 如果副本运行状况检查失败或其底层基础结构长时间不可用,服务会自动重启失败的容器或创建替换副本。 它还将流量从运行不正常的副本重新分发,并管理群集中的网络重试操作。 此自动恢复过程无需客户干预并维护指定的副本计数。 有关详细信息,请参阅 健康探测

  • 通过 Dapr 实现应用程序复原能力: 容器应用提供与 Dapr 的紧密集成,该框架支持生产级微服务和容器化应用程序。 Dapr 包括有助于提高复原能力的功能,包括处理其他服务中的故障。 有关详细信息,请参阅 使用容器应用的微服务

  • 系统组件的基础结构复原能力: 此复原能力包括控制平面、入口控制器和容器运行时。 在具有可用性区域的区域中,容器应用提供区域冗余。 有关详细信息,请参阅 可用性区域故障的复原能力

暂时性故障的复原能力

暂时性故障是指组件发生短暂的间歇性故障。 这些故障经常出现在云之类的分布式环境中,在运营过程中比较常见。 暂时性故障在短时间内自行纠正。 应用程序通常可以通过重试受影响的请求来处理暂时性故障,这一点很重要。

与任何云托管的 API、数据库和其他组件通信时,所有云托管的应用程序都应遵循 Azure 暂时性故障处理指南。 有关详细信息,请参阅 处理暂时性故障的建议

容器应用通过其平台级重试机制和运行状况监视自动处理许多暂时性故障。 为了确保您的应用程序能够抵抗暂时性故障,请执行以下操作:

  • 配置运行状况探测 ,使平台能够检测和响应特定于应用程序的故障条件。 根据应用程序的启动特征设置适当的故障阈值和超时值。 例如,为了避免在出现临时问题期间过早重启容器,请使用故障阈值 3,并将运行情况探测期间设置为 10 秒。 有关详细信息,请参阅 健康探测

  • 使用服务发现复原策略(预览版) 主动防止、检测和恢复服务请求失败。 例如,使用复原策略时,如果出现暂时性故障,则可能会自动重试对应用的每个传入请求,以防止应用响应。 有关详细信息,请参阅 服务发现复原能力(预览版)。

  • 在应用程序中实现外部服务调用、数据库连接和 API 请求的重试逻辑

    如果应用程序使用 Dapr 与云服务集成,请使用 Dapr 组件复原能力(预览版) 配置重试、超时和断路器。

    对于其他依赖项,应用程序必须处理暂时性故障。 调用外部服务时,使用指数退避策略和断路器模式,以防止下游服务中断期间出现级联故障。 容器应用内置服务发现和负载均衡功能会自动将流量路由到失败实例之外,但应用程序级重试策略可确保在平台级运行状况检查触发容器重启之前妥善处理暂时性问题。

  • 将作业设计为能够抵御暂时性故障,包括作业执行期间或依赖项中的故障。 将作业设计为可以在重启时继续运行,或将其设计为幂等性,以便可以安全地重新运行作业。

应对可用区故障的弹性

可用性区域 是在物理上彼此独立的数据中心群组,位于同一个 Azure 区域内。 当某个区域发生故障时,服务可以切换到其他可用的区域。

创建容器应用环境时,可以启用 区域冗余 ,以便在所选 Azure 区域中的多个可用性区域之间分配底层基础结构。 容器应用会自动调度应用实例的跨区域部署。 此分发以透明方式发生,这意味着无需为单个副本指定区域放置。

区域冗余通过确保容器应用的副本分散到多个区域,增强了应用程序对区域级故障的复原能力。

下图显示了具有三个副本的区域冗余容器应用。 每个副本在单独的可用性区域中运行。

显示具有三个副本的区域冗余容器应用的关系图。每个副本在单独的可用性区域中运行。

要求

  • 检查区域支持。 区域冗余可用于支持容器应用和可用区的所有区域。

    若要查看哪些区域支持可用性区域,请参阅 具有可用性区域支持的 Azure 区域

    若要查看哪些区域支持容器应用,请参阅 产品可用性(按区域)。

  • 使用工作负荷配置文件。 区域冗余适用于所有容器应用计划,包括消费型和专用型工作负荷配置文件。

  • 在创建环境期间启用区域冗余。 创建环境后,无法更改此设置。

  • 在虚拟网络中部署容器应用环境。 虚拟网络必须位于支持可用性区域的区域中。 确保虚拟网络具有足够大小的子网。 纯消耗型环境需要一个具有 /23 无类域间路由 (CIDR) 范围或更大范围的子网,而工作负载配置文件环境需要 /27 CIDR 范围或更大范围。

  • 将最小副本数至少设置为两个,以确保在多个可用区之间进行分布。 如果满足以下任一条件,请考虑设置更高的最小副本计数:

    • 预期峰值负载需要两个以上的副本。

    • 必须具备抵御多个同时发生的区域故障的能力。

    • 你想要尽量缩短区域中断期间等待在其他区域中创建新副本的时间。

成本

启用区域冗余时,不会产生超出标准容器应用定价的额外费用。 无论是否启用区域冗余,都为计算资源、请求和 vCore 秒支付相同的费率。 有关详细信息,请参阅 容器应用定价容器应用计费

配置可用性区域支持

  • 创建区域冗余的容器应用环境。 有关涵盖 Azure 门户、Azure CLI 和 Azure PowerShell 的部署说明,请参阅 创建区域冗余容器应用

  • 迁移到区域冗余部署。 无法在现有容器应用环境中启用区域冗余。 若要升级非区域冗余的现有环境,请在受支持的区域中创建启用了区域冗余的新环境。 然后重新部署容器应用。

  • 禁用区域冗余。 在创建环境期间启用区域冗余后,无法禁用区域冗余。 如果需要非区域冗余部署,则必须创建新的环境,而无需启用区域冗余选项或部署到不支持可用性区域的区域。

  • 验证区域冗余。 可以使用 Azure 门户、Azure CLI 和 Azure PowerShell 来验证环境的区域冗余状态

容量计划和管理

如果可用性区域不可用,容器应用平台将使用缩放规则来决定何时替换该区域中的任何丢失副本。 正确配置缩放规则以便计划程序可以做出合适的计划决策非常重要。

若要正确配置缩放规则,请遵循以下原则:

  • 设置应用程序可以容忍的最小副本数。 由于平台必须检测到旧副本已消失,因此可能需要一段时间才能替换丢失的副本。 然后,新副本必须启动并返回正常就绪情况探测状态,然后它们才能接收传入请求。 如果不能容忍任何少于指定的最小副本数的时间段,请考虑 过度预配 以保持应用程序性能,即使某个区域变得不可用也是如此。

  • 设置资源请求和限制 ,以帮助容器应用计划程序跨区域做出最佳放置决策。 资源需求规格不足可能导致在负载过高时出现分配不均或放置失败。

有关配置选项的详细信息,请参阅 “设置缩放规则”。

所有区域正常时的行为

本部分介绍当容器应用资源配置为区域冗余且所有可用性区域均正常运行时可能遇到的情况。

  • 区域之间的流量路由: 使用区域冗余容器应用,平台在主动-主动模型中运行,其中多个副本同时为流量提供服务。 入口控制器在所有正常运行的副本之间分配传入请求,而不考虑其区域,并默认使用轮循机制负载均衡。 每个区域独立处理请求,平台不会优先处理任何特定区域进行流量分配。 健康探测源自所有区域,以确保从各个角度准确地评估每个副本的健康状况。

  • 区域之间的数据复制: 容器应用不会在区域之间复制应用程序数据,因为它专为无状态工作负荷而设计。 当容器或副本关闭时,应用存储在 临时存储(包括容器范围的存储和副本范围的存储中)中的任何数据都被删除。

    对于有状态数据要求,请装载 Azure 文件存储文件共享(已针对区域冗余存储进行配置),或使用其他 Azure 服务(如 Azure Cosmos DB 或 Azure SQL 数据库)来提供其自己的跨区域复制功能。

    平台仅复制控制平面元数据,包括应用配置、缩放规则和跨区域机密以实现高可用性。 创建副本时,容器映像会根据需要从容器注册表拉取到每个区域中。

区域故障期间的行为

本部分介绍为区域冗余配置容器应用资源,以及可用性区域发生中断时应发生的情况。

  • 检测和响应: Azure 会自动检测区域故障。 容器应用会立即停止将新副本调度到失败的区域,并开始将流量重新分发到剩余的区域中的正常副本。 平台会自动处理所有故障转移操作,而无需您的干预。

  • 通知: Microsoft不会在区域关闭时自动通知你。 但是,可以使用 Azure 服务运行状况 来了解服务的总体运行状况,包括任何区域故障,并且可以设置 服务运行状况警报 来通知问题。

    还可以通过 Azure Monitor 中的容器应用指标监视应用的运行状况。 配置警告以监测副本计数下降和请求失败率,这样在出现与区域相关的问题时可以立即收到通知。

  • 活动请求:发往故障区域中的副本的正在进行的请求可能会被丢弃,或者出现超时或连接错误。 在受影响区域中运行的任何作业执行都会中止,并标记为失败。

  • 预期数据丢失: 容器应用平台级别不会发生数据丢失,因为该服务专为无状态工作负荷而设计。 在终止副本时,存储在可用性区域中 的临时存储 中的任何数据都将丢失,临时存储只能用于临时数据。

  • 预期的停机时间: 应用程序在发生区域故障期间几乎没有停机时间。 实际影响取决于应用程序的运行状况探测设置与正常区域中的副本数。 确保客户端遵循 暂时性故障处理指南 来最大程度地减少任何影响。

    在受影响区域中运行的任何作业都会中止,并标记为失败。 如果需要作业在区域故障中保持弹性,可以配置重试或增加并行度,使作业能够运行多个相同执行的副本。 有关详细信息,请参阅 高级作业配置

  • 流量重新路由: 入口控制器的运行状况探测可快速检测无法访问的副本,并将其从负载均衡池中删除。 根据应用的运行状况探测配置,此故障转移过程通常在大约 30 秒内发生。 后续流入的流量在剩余的可用副本之间分配。 此流量重定向以透明方式向继续使用同一应用程序 URL 的客户端进行。

    如果启用了 会话相关性 ,并且某个区域出现故障,则以前路由到该区域中副本的客户端将路由到新副本,因为以前的副本不再可用。 与以前的副本关联的任何状态都会丢失。

    不会在故障区启动新的作业实例。

  • 实例管理: 如果自动缩放规则根据负载增加触发,则可能会在正常的区域中创建新的副本实例。

区域恢复

当可用性区域从故障中恢复时,容器应用会自动将区域重新集成到活动服务中,而无需干预。 平台的运行状况探测操作检测恢复区域中的基础结构何时可用,容器应用会根据缩放配置开始对该区域计划新副本。 正常区域中的现有副本在重新集成过程中继续为流量提供服务,这有助于防止服务中断。

容器应用程序在正常缩放操作过程中逐渐重新平衡所有可用区的副本分布。 在因扩展事件而创建副本时,或者在替换运行不正常的副本时,会发生此自动重新均衡。 平台不会强制立即重新分配现有完好运行的副本,从而防止不必要的容器重启,并在恢复过程中维持应用程序的稳定性。

针对局部区域故障进行测试

容器应用平台管理区域冗余容器应用的流量路由、故障转移和故障回复。 此功能是完全托管的,因此无需启动或验证可用性区域故障流程。

若要验证应用程序对区域故障的复原能力,请使用受控的测试方法模拟应用程序层的区域级中断。 通过缩减应用程序来停止或删除特定区域中的副本,并监视剩余副本如何处理增加的负载。 在复原测试期间监视关键指标,包括副本计数、请求成功率、响应时间和自动缩放行为。 确保删除副本时,最小副本计数会保持服务可用性,并验证缩放规则是否可以处理剩余副本上增加的负载。 通过故意让正常终结点出现故障来测试运行状况探测配置,以确认平台是否会在预期时间范围内从轮换中移除不正常的实例。

对区域范围的故障的复原能力

容器应用是单区域服务。 如果区域不可用,则环境和应用也不可用。

用于复原的自定义多区域解决方案

若要降低影响应用程序的单区域故障的风险,可以跨多个区域部署环境。 以下步骤有助于增强复原能力:

  • 将应用程序部署到每个区域中的环境。 每个环境都需要自己的虚拟网络配置,子网要求将独立应用于每个区域部署。 容器映像必须可从所有区域访问,您可以通过使用已启用异地复制的 Azure 容器注册表来实现这一点。

  • 使用 Azure Front Door 或 Azure 流量管理器等服务配置负载均衡和故障转移策略。

  • 跨区域复制数据,以便恢复最后一个应用程序状态。

备份和还原

容器应用不提供应用程序的内置备份功能或数据。 作为无状态容器托管平台,容器应用希望应用程序通过外部服务管理自己的数据持久性和恢复策略。 应用程序容器及其本地文件系统是临时的,副本重启或移动时,本地存储的任何数据都将丢失。

应用程序更新期间的复原能力

使用修订管理将更新部署到应用程序,而无需停机。 您可以使用更新的容器镜像来创建新的修订版本,并使用蓝绿部署策略执行切换,或使用流量拆分规则逐步转移流量。 在应用程序更新期间,平台通过在停用旧容器之前创建新容器来维护最小副本计数,这有助于防止服务中断。

有关详细信息,请参阅 更新和部署容器应用中的更改

服务维护期间的系统弹性能力

容器应用执行自动平台维护以应用安全更新、部署新功能并提高服务可靠性。 该平台使用跨容错域和可用性区域的滚动更新来减少对正在运行的应用程序的中断。 在维护时段期间,容器将继续运行,而不会中断,因为分阶段将更新应用到底层基础结构。

可以指定自己的维护时段,这是你想要对应用执行维护的时间段。 请记住,关键更新可能在维护时段之外发生。 有关详细信息,请参阅 容器应用计划内维护

服务级别协议

Azure 服务的服务级别协议(SLA)描述了每个服务的预期可用性,以及解决方案为实现该可用性预期而必须满足的条件。 有关详细信息,请参阅 联机服务的 SLA

容器应用的可用性 SLA 基于你在应用上设置的规模规则。