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