你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure Kubernetes 服务（AKS）提供托管的 Kubernetes 环境，用于部署、管理和缩放容器化应用程序。 若要为 AKS 上运行的应用程序提供区域中断的复原能力，可以实施各种多区域部署模型。 本文概述了这些模型、其优点和缺点，以及维护应用程序运行时间的最佳做法。
AKS 提供一系列功能，支持群集的高可用性（HA）和灾难恢复（DR）以及 AKS 上运行的应用程序。 有关 AKS 如何支持可靠性要求的详细信息，请参阅 AKS 中的可靠性。
注意事项
下面是在 AKS 中实现多区域部署模型时的一些重要注意事项：
区域和全球资源
区域资源作为部署标记的一部分预配到单个 Azure 区域。 这些资源与其他区域的资源不共享，并且可以独立删除或复制到其他区域。 有关详细信息，请参阅区域资源。
全局资源共享系统的生命周期，并且可以在多区域部署的上下文中全局可用。 有关详细信息，请参阅全局资源。
全局负载均衡
全局负载均衡服务跨区域后端、云或混合本地服务分发流量。 这些服务将最终用户流量路由到最近的可用后端。 它们还对服务可靠性或性能的变化做出反应，以最大程度地提高可用性和性能。 以下 Azure 服务提供全局负载均衡：
范围定义
在管理 AKS 群集时，应用程序正常运行时间变得非常重要。 默认情况下，AKS 通过在虚拟机规模集中使用多个节点来提供高可用性，但这些节点不能保护系统免受区域故障的影响。 为了最大限度地延长正常运行时间，请提前规划以保持业务连续性，并遵循以下最佳做法，为灾难恢复做好准备：
- 在多个区域规划 AKS 群集。
- 使用 Azure 流量管理器跨多个群集路由流量。
- 为容器映像注册表使用异地复制。
- 跨多个群集计划应用程序状态。
- 跨多个区域复制存储。
多区域部署模型实现
下表总结了 AKS 中的三个主要多区域部署模型及其优点和缺点：
| 部署模型 | 优点 | 缺点 |
|---|---|---|
| 主动-主动 | • 故障转移期间不会出现数据丢失或不一致的情况 • 高复原能力 • 资源利用更充分，性能更高 |
• 复杂的实施和管理 • 成本更高 • 需要负载均衡器和流量路由形式 |
| 主动-被动 | • 实施和管理更简单 • 成本更低 • 不需要负载均衡器或流量管理器 |
• 故障转移期间可能会出现数据丢失或不一致的情况 • 恢复时间和故障时间更长 • 资源利用不足 |
| 被动-寒 | • 成本最低 • 不需要同步、复制、负载均衡器或流量管理器 • 适用于低优先级非关键工作负载 |
• 故障转移期间出现数据丢失或不一致情况的风险很高 • 恢复时间和故障时间最长 • 需要手动干预来激活群集并触发备份 |
主动-主动高可用部署模型
在主动-主动高可用性 (HA) 部署模型中，在两个不同的 Azure 区域（通常是配对区域，例如加拿大中部和加拿大东部或美国东部 2 和美国中部）部署了两个独立的 AKS 群集，用于主动提供流量服务。
在此示例体系结构中：
- 你在不同的 Azure 区域中部署两个 AKS 群集。
- 在正常操作期间，网络流量在两个区域之间路由。 如果一个区域不可用，流量将被自动路由到离发出请求的用户最近的区域。
- 每个区域 AKS 实例都有一个已部署的中心辐射对。 Azure 防火墙管理器策略管理跨区域的防火墙规则。
- 每个区域都预配了 Azure Key Vault，用于存储机密和密钥。
- Azure Front Door 对流量进行负载均衡并将流量路由到位于每个 AKS 群集前面的区域级 Azure 应用程序网关实例。
- 区域级 Log Analytics 实例存储区域网络指标和诊断日志。
- 工作负载的容器映像存储在托管容器注册表中。 单个 Azure 容器注册表用于群集中的所有 Kubernetes 实例。 Azure 容器注册表的异地复制支持将映像复制到所选 Azure 区域，并且即使某个区域遇到服务中断，也可继续访问映像。
若要在 AKS 中创建主动-主动部署模型，请执行以下步骤：
在两个不同的 Azure 区域中创建两个相同的部署。
创建两个 Web 应用实例。
使用以下资源创建 Azure Front Door 配置文件：
- 一个终结点。
- 两个源组，每个源组的优先级为 1。
- 路由。
将网络流量限制为仅从 Azure Front Door 实例流向 Web 应用。 5 配置所有其他后端 Azure 服务，例如数据库、存储帐户和身份验证提供程序。
通过持续部署将代码部署到这两个 Web 应用。
有关详细信息，请参阅 AKS 的建议主动-主动高可用性解决方案概述。
主动-被动灾难恢复部署模型
在主动-被动灾难恢复 (DR) 部署模型中，在两个不同的 Azure 区域（通常是配对区域，例如加拿大中部和加拿大东部或美国东部 2 和美国中部）部署了两个独立的 AKS 群集，用于主动提供流量服务。 在任何给定时间，只有一个群集主动提供流量服务。 另一个群集包含与主动群集相同的配置和应用程序数据，但除非流量管理器指示，否则不接受流量。
在此示例体系结构中：
- 你在不同的 Azure 区域中部署两个 AKS 群集。
- 在正常操作期间，网络流量将路由到在 Azure Front Door 配置中设置的主 AKS 群集。
- 优先级需要设置在 1-5 之间，其中 1 为最高，5 为最低。
- 可以将多个群集设置为相同的优先级，并可以指定每个群集的权重。
- 如果主群集不可用（发生灾难），流量会自动路由到在 Azure Front Door 中选择的下一个区域。
- 所有流量都必须通过 Azure Front Door 流量管理器才能使该系统正常工作。
- Azure Front Door 会将流量路由到主要区域中的 Azure 应用程序网关（群集必须标记为优先级 1）。 如果该区域出现故障，服务会将流量重定向到优先级列表中的下一个群集。
- 规则来自 Azure Front Door。
- 为每个区域 AKS 实例部署了一个中心辐射对。 Azure 防火墙管理器策略管理跨区域的防火墙规则。
- 每个区域都预配了 Azure Key Vault，用于存储机密和密钥。
- 区域级 Log Analytics 实例存储区域网络指标和诊断日志。
- 工作负载的容器映像存储在托管容器注册表中。 单个 Azure 容器注册表用于群集中的所有 Kubernetes 实例。 Azure 容器注册表的异地复制支持将映像复制到所选 Azure 区域，并且即使某个区域遇到服务中断，也可继续访问映像。
若要在 AKS 中创建主动-被动部署模型，请执行以下步骤：
在两个不同的 Azure 区域中创建两个相同的部署。
为辅助应用程序配置自动缩放规则，以便在主要区域变为非活动状态时，该计划缩放到与主要计划相同的实例计数。 处于非活动状态时，无需纵向扩展。 这有助于降低成本。
创建 Web 应用程序的两个实例，每个群集一个。
使用以下资源创建 Azure Front Door 配置文件：
- 一个终结点。
- 主要区域拥有一个优先级为 1 的源组。
- 次要区域拥有一个优先级为 2 的次要源组。
- 路由。
将网络流量限制为仅从 Azure Front Door 实例流向 Web 应用程序。
配置所有其他后端 Azure 服务，例如数据库、存储帐户和身份验证提供程序。
通过持续部署将代码部署到这两个 Web 应用程序。
有关详细信息，请参阅 AKS 的建议主动-被动灾难恢复解决方案概述。
被动-寒故障转移部署模型
被动-寒故障转移部署模型的配置方式与主动-被动灾难恢复部署模型相同，不同之处在于群集将保持非活动状态，直到用户在发生灾难时激活它们。 我们认为这种方法超出范围，因为它涉及与主动-被动类似的配置，但增加了激活群集和触发备份的手动干预的复杂性。
在此示例体系结构中：
- 创建两个 AKS 群集，它们最好位于不同的区域或区域，以增强复原能力。
- 需要进行故障转移时，可以激活部署来接管流量流。
- 当主要被动群集出现故障时，需要手动激活寒群集来接管流量流。
- 该条件需要通过每次手动输入或由指定的特定事件来设置。
- 每个区域都预配了 Azure Key Vault，用于存储机密和密钥。
- 区域 Log Analytics 实例存储每个群集的区域网络指标和诊断日志。
若要在 AKS 中创建被动-寒故障转移部署模型，请执行以下步骤：
- 在不同的分区/区域中创建两个相同的部署。
- 为辅助应用程序配置自动缩放规则，以便在主要区域变为非活动状态时，该计划缩放到与主要计划相同的实例计数。 处于非活动状态时，无需纵向扩展，这有助于降低成本。
- 创建 Web 应用程序的两个实例，每个群集一个。
- 配置所有其他后端 Azure 服务，例如数据库、存储帐户和身份验证提供程序。
- 设置应触发寒群集的条件。 如果需要，可以使用负载均衡器。
有关详细信息，请参阅 AKS 的建议被动-寒灾难恢复解决方案概述。
如需了解更多信息，请参阅以下文章：
