你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
适用于 Azure Kubernetes 服务 (AKS) 的建议主动-主动高可用性解决方案概述
在 Azure Kubernetes 服务 (AKS) 中创建应用程序并在资源创建期间选择 Azure 区域时，它是单一区域应用。 如果发生导致区域不可用的灾难，应用程序也会变得不可用。 如果在次要 Azure 区域中创建相同的部署，应用程序就不太容易受到单一区域灾难的影响，从而保证业务连续性，并且跨区域的任何数据复制让你能够恢复最近的应用状态。
虽然可以通过多种模式为 AKS 解决方案提供可恢复性，但本指南概述了适用于 AKS 的建议主动-主动高可用性解决方案。 在此解决方案中，我们将两个独立且相同的 AKS 群集部署到两个配对 Azure 区域，这两个群集将主动为流量提供服务。
注意
在 AKS 中，可将以下用例视为标准做法。 它已经过内部审查，并与 Microsoft 合作伙伴一起审查。
主动-主动高可用性解决方案概述
此解决方案依赖于配置为主动为流量提供服务的两个相同的 AKS 群集。 将全局流量管理器（如 Azure Front Door）放置在两个群集前面，以在两个群集之间分配流量。 必须一致地配置群集，以托管解决方案正常运行所需的全部应用程序的实例。
可用性区域是确保同一区域中 AKS 群集的高可用性和容错的另一种方法。 借助可用性区域，可以在 Azure 区域中的多个隔离位置之间分配群集节点。 通过此操作，如果一个区域由于停电、硬件故障或网络问题出现故障，群集可以继续运行并为应用程序提供服务。 可用性区域还可以通过减少节点之间的延迟和争用来提高群集的性能和可伸缩性。 要为 AKS 群集设置可用性区域，需要在创建或更新节点池时指定区域编号。 有关详细信息，请参阅什么是 Azure 可用性区域？
注意
许多地区支持可用性区域。 请考虑使用具有可用性区域的区域，以便为工作负载提供更强的复原能力和可用性。 有关详细信息，请参阅从区域范围的服务中断中恢复。
方案和配置
在托管无状态应用程序和/或使用跨两个区域部署的其他技术（例如水平缩放）的情况下，最适合实施此解决方案。 在托管应用程序依赖于仅在一个区域中主动的资源（如数据库）的情况下，我们建议改为实施 主动-被动解决方案，以实现可能的成本节省，因为主动-被动的停机时间多于主动-主动。
组件
主动-主动高可用性解决方案使用许多 Azure 服务。 本部分仅介绍此多群集体系结构特有的组件。 有关其余组件的详细信息，请参阅 AKS 基线体系结构。
多个群集和区域：可部署多个 AKS 群集，其中每个群集位于一个单独 Azure 区域中。 在正常操作期间，Azure Front Door 配置会在所有区域之间路由网络流量。 如果一个区域不可用，则流量会路由到用户加载时间最快的区域。
每个区域的中心辐射型网络：为每个区域 AKS 实例部署区域中心辐射型网络配对。 Azure 防火墙管理器策略可管理所有区域的防火墙策略。
区域密钥存储：在每个区域中预配 Azure Key Vault，以存储特定于 AKS 实例的敏感值和密钥，并支持在该区域中找到的服务。
Azure Front Door：Azure Front Door 可均衡负载并将流量路由到位于每个 AKS 群集前面的区域 Azure 应用程序网关实例。 Azure Front Door 允许使用第七层全局路由。
Log Analytics：区域 Log Analytics 实例可存储区域网络指标和诊断日志。 共享实例可存储所有 AKS 实例的指标和诊断日志。
容器注册表：工作负载的容器映像存储在托管容器注册表中。 使用此解决方案，单个 Azure 容器注册表实例可用于群集中的所有 Kubernetes 实例。 使用适用于 Azure 容器注册表的异地复制，可以将映像复制到所选 Azure 区域，并且即使某个区域遇到服务中断，也可继续访问映像。
故障转移过程
如果某个服务或服务组件在一个区域中不可用，则流量应会路由到该服务可用的区域。 多区域体系结构包含许多不同的故障点。 在本部分中，我们将介绍潜在的故障点。
应用程序 Pod（区域）
Kubernetes 部署对象可创建 Pod 的多个副本 (ReplicaSet)。 如果其中一个不可用，则会在剩余的副本之间路由流量。 Kubernetes ReplicaSet 会尝试启动指定数量的副本并使其保持正常运行。 如果一个实例出现故障，应会重新创建一个新实例。 运行情况探测可检查 Pod 中运行的应用程序或进程的状态。 如果 Pod 无响应，则运行情况探测将移除 Pod，这会强制 ReplicaSet 创建新的实例。
有关详细信息，请参阅 Kubernetes ReplicaSet。
应用程序 Pod（全局）
当整个区域不可用时，群集中的 Pod 将无法再为请求提供服务。 在这种情况下，Azure Front Door 实例会将所有流量路由到剩余的正常区域。 这些区域中的 Kubernetes 群集和 Pod 将继续为请求提供服务。 为了对剩余群集增加的流量和请求进行补偿，请记住以下指导：
- 确保网络和计算资源的大小正确，可承受区域故障转移导致的流量突增。 例如，使用 Azure 容器网络接口 (CNI) 时，请确保有一个子网可以支持所有具有峰值流量负载的 Pod IP。
- 使用水平 Pod 自动缩放程序来增加 Pod 副本计数，以对增加的区域需求进行补偿。
- 利用 AKS 群集缩放程序增加 Kubernetes 实例节点计数，以对增加的区域需求进行补偿。
Kubernetes 节点池（区域）
计算资源有时可能会发生局部故障，例如当一个机架的 Azure 服务器的电源不可用时。 要保护 AKS 节点免受单点区域故障的影响，请使用 Azure 可用性区域。 可用性区域可确保每个可用性区域中的 AKS 节点与另一个可用性区域中定义的节点在物理上分离。
Kubernetes 节点池（全局）
在完全区域故障中，Azure Front Door 会将流量路由到剩余正常的区域。 同样，请确保对剩余群集增加的流量和请求进行补偿。
故障转移测试策略
虽然 AKS 中目前没有可用的机制来出于测试目的关闭整个部署区域，但 Azure Chaos Studio 提供了在群集上创建混沌试验的功能。
后续步骤
如果要考虑其他解决方案，请参阅以下文章：
