此参考体系结构详细介绍了如何在主动/主动和高可用性配置中跨多个区域运行 Azure Kubernetes 服务 (AKS) 群集的多个实例。
此体系结构基于 AKS 基线体系结构（Microsoft 建议的 AKS 基础结构起点）构建。 AKS 基线详细说明了 Microsoft Entra 工作负载 ID、入口和出口限制、资源限制和其他安全 AKS 基础结构配置等基础结构功能。 本文档未涵盖这些基础结构详细信息。 建议先熟悉 AKS 基线，然后再继续处理多区域内容。
体系结构
下载此体系结构的 Visio 文件。
组件
许多组件和 Azure 服务都用于此多区域 AKS 体系结构。 此处仅列出了对此多群集体系结构具有唯一性的组件。 对于其他组件，请参考 AKS 基线体系结构。
- 区域 AKS 群集：可部署多个 AKS 群集，每个群集位于单独的 Azure 区域中。 在正常操作期间，网络流量在所有区域之间路由。 如果一个区域不可用，流量将被路由到离发出请求的用户最近的区域。
- 区域中心辐射型网络：为每个区域 AKS 实例部署区域中心辐射型网络配对。 Azure 防火墙管理器策略用于管理所有区域的防火墙策略。
- 区域密钥保管库：在每个区域中都预配了 Azure 密钥保管库。 密钥保管库用于存储特定于 AKS 群集的敏感值和密钥，以及该区域中的支持服务。
- 多个日志工作区：区域 Log Analytics 工作区用于存储区域网络指标和诊断日志。 此外，共享的 Log Analytics 实例用于存储所有 AKS 实例的指标和诊断日志。
- 全局 Azure Front Door 配置文件：Azure Front Door 用于对流量进行负载均衡并将流量路由到位于每个 AKS 群集前面的区域级 Azure 应用程序网关实例。 Azure Front Door 允许第 7 层全局路由，它们都是此体系结构所必需的。
- 全局容器注册表：工作负载的容器映像存储在托管容器注册表中。 在此体系结构中，单个 Azure 容器注册表用于群集中的所有 Kubernetes 实例。 Azure 容器注册表的异地复制支持将映像复制到所选 Azure 区域，并且即使某个区域遇到服务中断，也可继续访问映像。
设计模式
此体系结构使用两种云设计模式：
- Geodes（地理节点），任何区域都可以为任何请求提供服务。
- 部署缩放单元，其中从单个源（例如部署模板）部署应用程序或应用程序组件的多个独立副本。
地理节点模式注意事项
在选择区域来部署每个 AKS 群集时，请考虑接近工作负载使用者或客户的区域。 另外，考虑使用跨区域复制。 跨区域复制可跨其他 Azure 区域异步复制相同的应用程序和数据，以进行灾难恢复保护。 当群集扩展到两个区域以上时，请继续规划每对 AKS 群集的跨区域复制。
在每个区域中，AKS 节点池中的节点分布在多个可用性区域中，以帮助防止因区域故障导致的问题。 可用性区域在一组有限的区域中受支持，这会影响区域群集放置。 有关 AKS 和可用性区域的详细信息（包括受支持区域的列表），请参阅 AKS 可用性区域。
部署缩放单元注意事项
当管理多区域 AKS 解决方案时，需要在多个区域部署多个 AKS 群集。 其中每个群集都被视为一个缩放单元。 如果出现区域性故障或如果需要为群集添加更多容量或区域状态，可能需要创建新的缩放单元实例。 选择创建和管理部署缩放单元的过程时，请务必考虑以下事项：
- 为缩放单元定义选择相应的技术，以允许使用通用配置。 例如，可以使用 Bicep 将基础结构定义为代码。
- 使用部署输入机制（如变量或参数文件）提供特定于实例的值。
- 选择允许灵活、可重复和幂等部署的部署工具。
- 在主动/主动缩放单元配置中，考虑流量如何跨每个缩放单元进行均衡。 此体系结构使用 Azure Front Door 进行全局负载均衡。
- 在集合中添加和移除缩放单元时，请考虑容量和成本问题。
- 考虑如何将缩放单元集合作为一个整体进行直观查看和/或监视。
以下部分将详细介绍其中的每一项，并提供具体的指导。
车队管理
此解决方案表示一个多群集和多区域拓扑，未包含将所有群集视为统一舰队的一部分的高级业务流程协调程序。 群集计数增加时，请考虑在 Azure Kubernetes 舰队管理器中注册成员，以便更好地大规模管理参与的群集。 此处显示的基础体系结构不会因注册到舰队管理器而发生根本性变更，但 Day-2 精细运营和类似活动将受益于一个可同时面向多个群集的控制平面。
注意事项
这些注意事项实施 Azure 架构良好的框架的支柱原则，即一套可用于改善工作负荷质量的指导原则。 有关详细信息，请参阅 Microsoft Azure 架构良好的框架。
群集部署和启动
在高度可用和地理上分散的配置中部署多个 Kubernetes 群集时，必须将每个 Kubernetes 群集的总和视为一个耦合单元。 你可能希望为自动化部署和配置开发代码驱动的策略，以确保每个 Kubernetes 实例尽可能相同。 考虑横向扩展和缩减的策略，包括通过添加或移除其他 Kubernetes 群集。 您的设计、部署和配置计划应考虑到可用性区域中断、区域故障和其他常见情况。
群集定义
用于部署 Azure Kubernetes 服务群集的选项有很多。 Azure 门户、Azure CLI、Azure PowerShell 模块都是用于部署单个或非耦合 AKS 群集的合适选项。 但这些方法在处理许多紧密耦合的 AKS 群集时可能会遇到困难。 例如，如果使用 Azure 门户，将有可能由于缺少步骤或配置选项不可用而漏掉配置。 使用门户部署和配置多个群集是一个非常耗时的过程，需要一名或多名工程师关注。 如果使用 Azure CLI 或 Azure PowerShell，则可以使用命令行工具构建可重复和自动化的过程。 不过，幂等性、部署故障控制和故障恢复由你和你构建的脚本负责。
处理多个 AKS 实例时，我们建议考虑使用基础结构即代码解决方案，例如 Bicep、Azure 资源管理器模板或 Terraform。 基础结构即代码解决方案提供自动化、可缩放和幂等部署解决方案。 例如，可以将一个 Bicep 文件用于解决方案的共享服务，另一个用于 AKS 群集和其他区域服务。 如果你使用基础结构即代码时，那么可以使用通用配置（如网络、授权和诊断）来定义部署缩放单元。 可以向部署参数文件提供特定于区域的值。 通过此配置，可使用一个模板跨任何区域部署几乎完全相同的缩放单元。
开发和维护基础结构即代码资产的成本可能很高。 在某些情况下，将基础结构定义为代码的开销可能超过收益，例如当您有非常小（比如 2 或 3 个）且数量不变的 AKS 实例时。 对于这些情况，使用更命令性的方法是可以接受的，例如使用命令行工具，甚至是使用 Azure 门户的手动方法。
群集部署
定义群集缩放单元后，有许多选项都可以部署单个或多个缩放单元实例。 建议使用新式持续集成技术，如 GitHub Actions 或 Azure Pipelines。 持续集成部署解决方案的优点包括：
- 基于代码的部署，允许使用代码添加和移除缩放单元
- 集成测试功能
- 集成环境和暂存功能
- 集成机密管理解决方案
- 与源代码管理集成，适用于应用程序代码和部署脚本和模板
- 部署历史记录和日志记录
- 访问控制和审核功能，以控制谁可以进行更改以及在什么条件下进行更改
在从全局群集添加或移除新缩放单元时，需要更新部署管道才能保持一致。 一种方法是在 GitHub Actions 工作流中将每个区域的资源部署为单个步骤。 此配置很简单，因为每个群集实例都在部署管道中明确定义。 在从部署中添加和移除群集时，此配置缺失会产生一些管理开销。
另一种方法是创建业务逻辑以根据一列所需的位置或其他指示的数据点创建群集。 例如，部署管道可以包含所需区域的列表；然后，管道中的步骤可以循环访问此列表，将群集部署到列表中找到的每个区域。 此配置的缺点是部署通用化很复杂，并且部署管道中未明确详述每个群集缩放单元。 好处是，添加或移除管道中的群集缩放单元后，所需区域列表会进行简单的更新。
此外，从部署管道中删除集群缩放单元并不总是会停用缩放单元的资源。 根据部署解决方案和配置，可能还需要执行额外的一个步骤来停用 AKS 实例和其他 Azure 资源。 请考虑使用部署堆栈来启用 Azure 资源的完整生命周期管理，包括在不再需要时进行清理。
群集引导
部署每个 Kubernetes 实例或缩放单元后，需要部署和配置入口控制器、标识解决方案和工作负载组件等群集组件。 还需要考虑跨群集应用安全性、访问和治理策略。
与部署类似，这些配置可能会使手动管理多个 Kubernetes 实例的过程变得困难。 可考虑以下大规模配置和策略选项。
GitOps
由于这些配置已签入源存储库，因此建议使用自动化方法将配置应用到 Kubernetes 群集，而不是手动配置 Kubernetes 组件。 此过程通常称为 GitOps，适用于 Kubernetes 的常用 GitOps 解决方案包括 Flux 和 Argo CD。 例如，AKS 的 Flux 扩展允许在部署群集后立即自动引导群集。
AKS 基线参考体系结构中将更深入地介绍 GitOps。 使用基于 GitOps 的方法进行配置，需要确保每个 Kubernetes 实例采用相似的配置而无需定制。 随着舰队规模的增长，简化的配置过程变得更加重要。
Azure Policy
随着添加多个 Kubernetes 实例，策略驱动的治理、合规性和配置的优势将增多。 利用策略（特别是 Azure Policy）可提供可缩放的集中式群集控制方法。 AKS 基线参考体系结构中将详细介绍 AKS 策略的优势。
创建 AKS 群集时，应启用 Azure Policy。 在审核模式下分配计划，以了解不合规情况。 还可以设置更多不属于任何内置计划的策略。 这些策略设置为拒绝模式。 例如，有一个策略可以确保只有已批准的容器映像在群集中运行。 请考虑创建自己的自定义计划。 将适用于工作负载的策略组合到一个分配中。
策略范围是指每个策略和策略计划的目标。 可以使用 Bicep 将策略分配给部署每个 AKS 群集的资源组。 随着全局群集的占用量增长，这会导致出现许多重复的策略。 还可将策略范围限定为 Azure 订阅或 Azure 管理组。 通过此方法，可将一组策略应用于一个订阅范围内的所有 AKS 群集，或者在一个管理组下找到的所有订阅。
为多个 AKS 群集设计策略时，请考虑以下几点：
- 将应全局应用于所有 AKS 实例的策略应用于管理组或订阅。
- 将每个区域群集放在其自己的资源组中后，特定于区域的策略将可以应用到相应资源组。
如需帮助制定策略管理战略的材料，请参阅云采用框架资源组织。
工作负载部署
除了 AKS 实例配置外，还应考虑部署到每个区域实例或缩放单元中的工作负载。 部署解决方案或管道需要配置才能容纳每个区域缩放单元。 随着向全局群集添加更多缩放单元，部署过程需要扩展或足够灵活才能容纳新的区域实例。
规划工作负载部署时，请考虑以下几点。
- 实现部署通用化（例如使用 Helm 图表），确保可以在多个群集缩放单元中使用单个部署配置。
- 使用配置为可跨所有群集缩放单元部署工作负载的单个持续部署管道。
- 以部署参数的形式提供特定于缩放单元的实例详细信息。
- 考虑如何配置应用程序诊断日志记录和分布式跟踪以获得应用程序范围的可观测性。
可用性和故障转移
选择多区域 Kubernetes 体系结构的一个重要动机是服务可用性。 也就是说，如果某个服务或服务组件在一个区域中不可用，则应将流量路由到该服务的另一个实例仍然可用的区域。 多区域体系结构包含许多不同的故障点。 在本部分中，将讨论每个潜在的故障点。
应用程序 Pod 失败
Kubernetes 部署对象用于创建 ReplicaSet（管理 Pod 的多个副本）。 如果其中一个 Pod 不可用，则会在剩余的副本之间路由流量。 Kubernetes ReplicaSet 会尝试启动指定数量的副本并使其保持正常运行。 如果一个实例出现故障，会自动重新创建一个新实例。 运行情况探测可用于检查 Pod 中运行的应用程序或进程的状态。 如果服务无响应，则运行情况探测将移除 Pod，这会强制 ReplicaSet 创建新的实例。
有关详细信息，请参阅 Kubernetes ReplicaSet。
数据中心硬件故障
本地化故障偶尔会发生。 例如，可能无法为单个 Azure 服务器机架供电。 若要保护 AKS 节点免受单点区域故障的影响，请使用 Azure 可用性区域。 使用可用性区域可确保一个可用性区域中的 AKS 节点与另一个可用性区域中定义的节点在物理上分离。
有关详细信息，请参阅 AKS 和 Azure 可用性区域。
Azure 区域故障
当整个区域不可用时，群集中的 Pod 将无法再为请求提供服务。 在这种情况下，Azure Front Door 会将所有流量路由到剩余的正常区域。 运行正常区域中的 Kubernetes 群集和 Pod 将继续为请求提供服务。
在这种情况下，请注意对剩余群集增加的请求和流量进行补偿。 请考虑以下几点：
- 确保网络和计算资源的大小正确，可承受区域故障转移导致的流量突增。 例如，使用 Azure CNI 时，请确保子网足够大，可以在流量激增时支持所有 Pod IP 地址。
- 使用水平 Pod 自动缩放程序来增加 Pod 副本计数，以对增加的区域需求进行补偿。
- 利用 AKS 群集缩放程序增加 Kubernetes 实例节点计数，以对增加的区域需求进行补偿。
有关详细信息，请参阅水平 Pod 自动缩放程序和 AKS 群集自动缩放程序。
网络拓扑
与 AKS 基线参考体系结构类似，此体系结构使用中心辐射型网络拓扑。 除了 AKS 基线参考体系结构中指定的注意事项外，还应考虑下列最佳做法：
- 为每个区域 AKS 实例实现一组中心辐射型虚拟网络。 在每个区域中，对等方每个分支都与中心虚拟网络对接。
- 通过每个区域中心网络中找到的 Azure 防火墙实例路由所有出站流量。 利用 Azure 防火墙管理器策略管理所有区域的防火墙策略。
- 遵循 AKS 基线参考体系结构中的 IP 大小，并为节点和 Pod 缩放操作提供更多 IP 地址，以防在另一个区域遇到区域故障，流向其余区域的流量大幅增加。
流量管理
借助 AKS 基线参考体系结构，工作负载流量直接路由到 Azure 应用程序网关实例，然后转发到后端负载均衡器和 AKS 入口资源。 处理多个群集时，客户端请求将通过 Azure Front Door 实例进行路由，从而路由到 Azure 应用程序网关实例。
下载此图的 Visio 文件。
用户将请求发送到域名（例如
https://contoso-web-a1bc2de3fh4ij5kl.z01.azurefd.net），该域名解析为 Azure Front Door 配置文件。 此请求使用为 Azure Front Door 的所有子域颁发的通配符证书 (*.azurefd.net) 进行加密。 Azure Front Door 实例根据 Web 应用程序防火墙策略验证请求，选择最快的源（根据运行状况和延迟），并使用公共 DNS 解析源 IP 地址（Azure 应用程序网关实例）。Azure Front Door 将请求转发到所选的相应应用程序网关实例，该实例充当区域缩放单元的入口点。 流量通过 Internet 流动。 Azure Front Door 确保对发往源的流量进行加密。
请考虑采用某种方法来确保应用程序网关实例仅接受 Front Door 实例的流量。 一种方法是在包含应用程序网关的子网上使用网络安全组。 这些规则可以根据源、端口、目标等属性筛选入站（或出站）流量。 利用源属性，可以设置一个内置服务标记，用于指示 Azure 资源的 IP 地址。 通过此抽象，可以更轻松地配置和维护规则并跟踪 IP 地址。 此外，请考虑利用
X-Azure-FDID标头，Azure Front Door 在将请求发送到源之前将其添加到请求中，以确保应用程序网关实例仅接受来自 Front Door 实例的流量。 有关 Front Door 标头的详细信息，请参阅 Azure Front Door 中 HTTP 标头的协议支持。
共享资源注意事项
虽然此方案的重点是让多个 Kubernetes 实例分布在多个 Azure 区域，但在所有区域之间共用一些资源确实有意义。 一种方法是使用单个 Bicep 文件来部署所有共享资源，然后使用另一种方法部署每个区域标记。 本部分详细介绍了每项共享资源和跨多个 AKS 实例使用每项资源的注意事项。
容器注册表
此体系结构中使用 Azure 容器注册表来提供容器映像服务。 群集从注册表中拉取容器映像。 在多区域群集部署中使用 Azure 容器注册表时，请考虑以下几点。
上市地区
在部署了 AKS 群集的每个区域中放置一个容器注册表。 此方法允许低延迟网络操作，实现快速、可靠的图像层传输。 这也意味着当区域服务不可用时，有多个映像服务终结点提供可用性。 使用 Azure 容器注册表异地复制功能，可以管理一个自动复制到多个区域的容器注册表。
请考虑创建单个注册表，其中副本会复制到包含群集的每个 Azure 区域。 有关 Azure 容器注册表复制的详细信息，请参阅 Azure 容器注册表中的异地复制。
显示 Azure 门户中的多个 Azure 容器注册表副本的图像。
群集访问
每个 AKS 群集都需要访问容器注册表，以便它可以拉取容器映像层。 可通过多种方式建立对 Azure 容器注册表的访问权限。 此参考体系结构为每个群集创建一个托管标识，然后在容器注册表上授予其 AcrPull 角色。 如需有关使用托管标识进行 Azure 容器注册表访问的详细信息和建议，请查看 AKS 基线参考体系结构。
此配置在群集缩放单元 Bicep 文件中进行定义，以便每次部署新缩放单元时，都会为新的 AKS 实例授予访问权限。 由于容器注册表是共享资源，因此请确保部署包含容器注册表的资源 ID 作为参数。
Azure Monitor
建议使用 Azure Monitor 容器见解功能来监视和了解群集与容器工作负载的性能和健康状况。 容器见解可利用 Log Analytics 工作区存储日志数据，还利用 Azure Monitor 指标存储数字时序数据。 容器见解还可以收集 Prometheus 指标，并将数据发送到面向 Prometheus 的 Azure Monitor 托管服务或 Azure Monitor 日志。 有关详细信息，请参阅 AKS 基线参考体系结构。
你还可以配置 AKS 群集诊断设置来收集和分析来自 AKS 控制平面组件的资源日志，并转发到 Log Analytics 工作区。
设计多区域体系结构的监视解决方案时，请务必考虑每个缩放单元之间的耦合。 可以部署每个 Kubernetes 群集共享的单个 Log Analytics 工作区。 与其他共享资源一样，定义区域缩放单元以使用有关单个全局共享 Log Analytics 工作区的信息，并将每个区域群集连接到该共享工作区。 当每个区域群集向该单个 Log Analytics 工作区发出诊断日志时，可以使用这些数据以及资源指标来更轻松地生成报表和仪表板，帮助你了解整个多区域解决方案的运行情况。
Azure Front Door
Azure Front Door 用于对流量进行负载均衡，并将流量路由到每个 AKS 群集。 Azure Front Door 还支持第 7 层全局路由。 此方案需要这些功能。
群集配置
添加每个区域 AKS 实例时，需要将与 Kubernetes 群集一起部署的应用程序网关注册为 Azure Front Door 中的源，这使其可用于路由。 此操作需要更新基础结构即代码资产。 或者，可以将此操作与部署配置分离，并使用 Azure CLI 等工具进行管理。
Certificates
Azure Front Door 不支持使用自签名证书的源，即使在开发或测试环境中也是如此。 若要启用 HTTPS 流量，需要创建由证书颁发机构 (CA) 签名的 TLS/SSL 证书。 有关 Front Door 支持的其他 CA 的信息，请参阅可在 Azure Front Door 上启用自定义 HTTPS 的获准的证书颁发机构。
对于测试或非生产群集，可以考虑使用 Certbot 为每个应用程序网关创建 Let's Encrypt Authority X3 证书。
规划生产群集时，请使用组织的首选方法来购买 TLS 证书。
群集访问和标识
如 AKS 基线参考体系结构中所述，建议使用 Microsoft Entra ID 作为群集的标识提供者。 然后，可以使用 Microsoft Entra 组来控制对群集资源的访问。
管理多个群集时，需要确定访问架构。 选项包括：
- 创建全局群集范围的访问组，其中成员可以在群集中的每个 Kubernetes 实例上访问所有对象。 此选项提供最少的管理需求；但它向任何组成员授予重要权限。
- 为每个 Kubernetes 实例创建单个访问组，它用于向单个群集实例中的对象授予访问权限。 使用此选项时，管理开销会增加；但是，它还提供更精细的群集访问权限。
- 定义 Kubernetes 对象类型和命名空间的精细化访问控制，并将结果关联到 Microsoft Entra 组结构。 使用此选项时，管理开销会显著增加；但是，它不仅提供每个群集的精细化访问权限，还提供在每个群集中找到的命名空间和 Kubernetes API 的精细化访问权限。
对于管理访问权限，请考虑为每个区域创建 Microsoft Entra 组。 向每个组授予对该区域中相应群集戳的完全访问权限。 然后，每个组的成员都可以对相应的群集进行管理访问。
若详细了解如何使用 Microsoft Entra ID 管理 AKS 群集，请参阅 AKS Microsoft Entra 集成。
数据、状态和缓存
使用 AKS 群集集的全球分布式群集时，请考虑应用程序、进程或其他可能跨群集运行的工作负载的体系结构。 如果基于状态的工作负载分散在群集中，它们是否需要访问状态存储？ 如果由于故障在群集中的其他位置重新创建进程，工作负载或进程是否仍然有权访问依赖状态存储或缓存解决方案？ 状态可以以多种方式存储，但即使在单个 Kubernetes 群集中管理也很复杂。 如果在多个 Kubernetes 群集中添加，会更加复杂。 由于区域访问权限和复杂性问题，请考虑设计可使用全球分布式状态存储服务的应用程序。
此体系结构的设计不包括针对状态问题的配置。 如果在多个 AKS 群集上运行单个逻辑应用程序，请考虑构建工作负载来使用全球分布式数据服务，例如 Azure Cosmos DB。 Azure Cosmos DB 是一个全球分布式数据库系统，允许你从数据库的本地副本读取和写入数据，而 Cosmos DB 服务为你管理异地复制。 有关详细信息，请参阅 Azure Cosmos DB。
如果工作负载使用缓存解决方案，请确保对缓存服务进行架构设计，以便即使在故障转移事件期间也能保持其功能。 请确保工作负载本身能够灵活应对与缓存相关的故障转移，并且所有区域 AKS 实例都有相应的缓存解决方案。
成本优化
使用 Azure 定价计算器估算体系结构使用的服务的成本。 有关其他最佳做法，请参阅《Microsoft Azure 架构良好的框架》中的成本优化部分，如需了解具体的成本优化配置选项，请参阅《优化成本》一文。
考虑启用 AKS 成本分析，以便通过 Kubernetes 特定构造进行精细群集基础结构成本分配。