Azure Kubernetes 服务（AKS）提供托管的 Kubernetes 环境，用于部署、管理和缩放容器化应用程序。 若要为 AKS 上运行的应用程序提供区域中断的复原能力，可以实施各种多区域部署模型。 本文概述了这些模型、其优点和缺点，以及维护应用程序运行时间的最佳做法。
AKS 提供一系列功能，支持群集的高可用性（HA）和灾难恢复（DR）以及 AKS 上运行的应用程序。 有关 AKS 如何支持可靠性要求的详细信息，请参阅 AKS 中的可靠性。
注意事项
下面是在 AKS 中实现多区域部署模型时的一些重要注意事项：
区域和全球资源
区域资源 作为 部署标记 的一部分预配到单个 Azure 区域。 这些资源与其他区域中的资源不共享，并且可以独立删除或复制到其他区域。
全局资源 共享系统的生存期，并且可以在多区域部署的上下文中全局提供它们。
全局负载均衡
全局负载均衡服务跨区域后端、云或混合本地服务分配流量。 这些服务将最终用户流量路由到最近的可用后端。 他们还对服务可靠性或性能的变化做出反应，以最大程度地提高可用性和性能。 以下 Azure 服务提供全局负载均衡：
范围定义
管理 AKS 群集时，应用程序运行时间变得非常重要。 默认情况下，AKS 通过使用 虚拟机规模集中的多个节点提供高可用性，但这些节点不会保护系统免受区域故障的影响。 若要最大程度地提高运行时间，请提前计划，以保持业务连续性，并使用以下最佳做法为灾难恢复做好准备：
- 规划多个区域中的 AKS 群集。
- 使用 Azure 流量管理器跨多个群集路由流量。
- 对容器映像注册表使用异地复制。
- 跨多个群集规划应用程序状态。
- 跨多个区域复制存储。
多区域部署模型实现
下表总结了 AKS 中的三个主要多区域部署模型及其优点和缺点：
| 部署模型 | Pros | Cons |
|---|---|---|
| Active-active | • 故障转移期间不会丢失数据或不一致 • 高复原能力 • 提高性能的资源利用率 |
• 复杂的实现和管理 • 成本较高 • 需要负载均衡器和流量路由形式 |
| 主动-被动 | • 更简单的实现和管理 • 成本较低 • 不需要负载均衡器或流量管理器 |
• 在故障转移期间可能导致数据丢失或不一致 • 恢复时间和停机时间更长 • 资源使用不足 |
| 被动冷 | • 成本最低 • 不需要同步、复制、负载均衡器或流量管理器 • 适用于低优先级、非关键工作负荷 |
• 故障转移期间数据丢失或不一致的风险很高 • 最长的恢复时间和停机时间 • 需要手动干预才能激活群集和触发备份 |
主动-主动高可用性部署模型
在主动-主动高可用性（HA）部署模型中，有两个独立的 AKS 群集部署在两个不同的 Azure 区域（通常配对区域，如 ChinaNorth3 和中国North2）中，它们为流量提供服务。
使用此示例体系结构：
- 在单独的 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）部署模型中，有两个独立的 AKS 群集部署在两个不同的 Azure 区域（通常配对区域，如 ChinaNorth3 和中国North2）中，它们为流量提供服务。 在任何给定时间，只有一个群集主动为流量提供服务。 其他群集包含与活动群集相同的配置和应用程序数据，但除非流量管理器指示，否则不接受流量。
使用此示例体系结构：
- 在单独的 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 配置文件：
- 终结点。
- 一个源组，其优先级为 主要区域之一 。
- 第二个源组，次要区域的优先级为 2 。
- 路由。
仅将网络流量从 Azure Front Door 实例限制到 Web 应用程序。
配置所有其他后端 Azure 服务，例如数据库、存储帐户和身份验证提供程序。
使用持续部署将代码部署到这两个 Web 应用程序。
有关详细信息，请参阅 AKS 的建议主动-被动灾难恢复解决方案概述。
被动冷故障转移部署模型
被动冷故障转移部署模型的配置方式与 主动-被动灾难恢复部署模型相同，但群集在发生灾难时激活群集之前保持非活动状态。 我们认为此方法 的范围不足 ，因为它涉及与主动-被动类似的配置，但增加了手动干预的复杂性来激活群集并触发备份。
使用此示例体系结构：
- 可以创建两个 AKS 群集，最好在不同的区域或区域中实现更好的复原能力。
- 需要故障转移时，激活部署以接管流量流。
- 如果主被动群集出现故障，需要手动激活冷群集以接管流量流。
- 此条件需要由每次手动输入或由你指定的特定事件设置。
- Azure Key Vault 在每个区域中预配，用于存储机密和密钥。
- 区域 Log Analytics 实例存储每个群集的区域网络指标和诊断日志。
若要在 AKS 中创建被动冷故障转移部署模型，请执行以下步骤：
- 在不同的区域/区域中创建两个相同的部署。
- 为辅助应用程序配置自动缩放规则，以便在主要区域处于非活动状态时将其缩放为与主要实例相同的实例计数。 虽然处于非活动状态，但不需要纵向扩展，这有助于降低成本。
- 创建 Web 应用程序的两个实例，每个群集上有一个实例。
- 配置所有其他后端 Azure 服务，例如数据库、存储帐户和身份验证提供程序。
- 设置应触发冷群集的条件。 如果需要，可以使用负载均衡器。
有关详细信息，请参阅 AKS 的建议被动冷故障转移解决方案概述。
如需了解更多信息，请参阅以下文章：