通过

将 Azure Kubernetes 服务 (AKS) 和 MySQL 灵活服务器工作负载迁移到可用性区域支持

  • 项目

本指南介绍如何在所有相关服务中将 Azure Kubernetes 服务和 MySQL 灵活服务器工作负载迁移到完整的可用性区域支持。 有关所有工作负载依赖项的完整列表，请参阅工作负载服务依赖项。

必须在创建 AKS 群集或 MySQL 灵活服务器期间为此工作负载启用可用性区域支持。 如果你想要为现有 AKS 群集和 MySQL 灵活服务器提供可用性区域支持，需要重新部署这些资源。

本迁移指南重点介绍在 Azure 上运行以下体系结构的基础结构和可用性注意事项：

显示工作流体系结构第一部分的插图

显示工作流体系结构第二部分的插图

工作负载服务依赖项

若要为可用性区域提供完整的工作负载支持，工作负载中的每个服务依赖项都必须支持可用性区域。

可用性区域支持的服务有两种方法类型：区域或区域冗余。 大多数服务支持其中一种。 但在某些情况下，可为该服务选择区域资源或区域冗余资源。 以下建议中指出了哪些服务支持区域资源，哪些服务支持区域冗余资源。 我们还指出了哪些服务是全局服务，哪些是区域服务。

AKS 和 MySQL 工作负载体系结构包含以下组件依赖项：

Azure Kubernetes 服务 (AKS)

  • 区域：在创建期间预先选择部署节点池的区域时，系统节点池和用户节点池是区域性的。 我们建议预先选择所有三个区域以获得更好的复原能力。 通过为 zones 参数提供值，可将更多支持可用性区域的用户节点池添加到现有 AKS 群集。

  • 区域冗余：Kubernetes 控制平面组件（例如 etcd、API 服务器、计划程序和控制器管理器）会自动跨区域复制或分布。

    注意

    若要启用 AKS 群集控制平面组件的区域冗余，必须在创建 AKS 群集时使用区域定义默认系统节点池。 将更多区域节点池添加到现有的非区域 AKS 群集不会使 AKS 群集变得区域冗余，因为该操作不会在事后跨区域分布控制平面组件。

Azure Database for MySQL 灵活服务器

  • 区域：区域可用性模式意味着备用服务器始终在主服务器所在的同一区域中可用。 虽然此选项减少了故障转移时间和网络延迟，但由于单个区域服务中断会同时影响主服务器和备用服务器，因此它的复原能力较差。

  • 区域冗余：区域冗余可用性模式意味着备用服务器始终在主服务器所在的同一地区中的另一个区域内可用。 将为主服务器和备用服务器的区域冗余启用两个区域。 我们建议使用此配置来获得更好的复原能力。

Azure 标准负载均衡器或 Azure 应用程序网关

标准负载均衡器

若要了解标准负载均衡器资源相关的注意事项，请参阅负载均衡器和可用性区域。

  • 区域冗余：选择区域冗余是使用现有负载均衡器配置前端 IP 的建议方式。 区域冗余前端对应于分布在多个区域的 AKS 群集后端池。

  • 区域：如果将节点池固定到特定区域（例如区域 1 和 2），可以在现有负载均衡器中为前端 IP 预先选择区域 1 和 2。 你想要将节点池固定到特定区域的原因可能是可以使用专用的 VM SKU 系列（例如 M 系列）。

Azure 应用程序网关

仅在应用程序网关 v2 SKU（标准和 WAF）上支持将应用程序网关入口控制器加载项与 AKS 群集配合使用。 若要了解 Azure 应用程序网关相关的更多注意事项，请参阅缩放应用程序网关 v2 和 WAF v2。

区域：若要利用可用性区域的优势，我们建议在多个区域（例如区域 1、2 和 3）中创建应用程序网关资源。 选择所有三个区域以获得最佳的区域内复原能力策略。 但是，为了与后端节点池相对应，可以在创建应用程序网关资源期间通过预先选择区域 1 和 2 将节点池固定到特定区域。 你想要将节点池固定到特定区域的原因可能是可以使用专用的 VM SKU 系列（例如 M-series）。

区域冗余存储 (ZRS)

  • 我们建议使用托管 ZRS 磁盘配置 AKS 群集，因为它们是区域冗余资源。 可以在所有区域上计划卷。

  • 自版本 1.12 起，Kubernetes 开始注意到 Azure 可用性区域。 可以在多区域 AKS 群集中部署引用 Azure 托管磁盘的 PersistentVolumeClaim 对象。 Kubernetes 将负责在正确的可用性区域中计划任何声明此 PVC 的 pod。

  • 对于适用于 SQL 的 Azure 数据库，我们建议将数据和日志文件托管在区域冗余存储 (ZRS) 中。 将通过 ZRS 提供的存储级复制将这些文件复制到备用服务器。

Azure 防火墙

区域：若要使用可用性区域的优势，我们建议在多个区域（例如区域 1、2 和 3）中创建 Azure 防火墙资源。 建议选择所有三个区域，以获得最佳区域内部复原策略。

Azure Bastion

地区：Azure Bastion 是在 VNet 或对等的 VNet 中部署的，与 Azure 区域相关联。

Azure 容器注册表 (ACR)

区域冗余：我们建议在高级服务层级中创建区域冗余注册表。 还可以通过设置副本的 zoneRedundancy 属性来创建区域冗余注册表副本。 若要了解如何为 ACR 启用区域冗余，请参阅在 Azure 容器注册表中启用区域冗余以实现复原能力和高可用性。

用于 Redis 的 Azure 缓存

区域冗余：Azure Cache for Redis 支持高级层和企业层中的区域冗余配置。 区域冗余缓存将其节点置于同一区域中的不同可用性区域上。

Microsoft Entra ID

全球：Microsoft Entra ID 是一项全球服务，具有多层内部冗余和自动可恢复性。 Microsoft Entra ID 部署在全球的 30 多个数据中心，这些数据中心提供现有可用性区域。 随着更多区域的部署，此数字正迅速增长。

Azure Key Vault

区域：Azure 密钥保管库部署在区域中。 为保持密钥和机密的高度持久性，密钥保管库的内容将在区域内复制，并复制到同一地理位置的次要区域。

区域冗余：对于具有可用性区域但没有区域对的 Azure 区域，密钥保管库使用区域冗余存储 (ZRS) 在单个位置/区域内将密钥保管库的内容复制三次。

工作负载注意事项

Azure Kubernetes 服务 (AKS)

  • Pod 可与其他 Pod 进行通信，不管 Pod 位于哪个节点或该节点上的哪个可用性区域。 如果 Pod 位于不同的可用性区域，应用程序的响应时间可能较长。 虽然 Pod 之间的额外往返延迟预计会在大多数应用程序的可接受范围内，但有些应用程序方案需要低延迟，特别是对于 Pod 之间的闲聊通信模式。

  • 我们建议测试应用程序以确保它在不同的可用性区域中正常执行。

  • 由于低延迟等性能原因，Pod 可以位于同一可用性区域中的同一数据中心。 若要将 Pod 放在同一可用性区域中的同一数据中心，可以创建具有唯一区域和邻近放置组的用户节点池。 可以通过创建新代理节点池并指定 PPG 将邻近放置组 (PPG) 添加到现有 AKS 群集。 使用 Pod 拓扑分散约束来控制 Pod 在 AKS 群集中跨可用性区域、节点和地区的分散方式。

  • 将需要低延迟通信的 Pod 定位在同一可用性区域后，Pod 之间的通信不会直接进行。 相反，Pod 通信是通过一个服务进行的，该服务在 AKS 群集中定义一组逻辑 Pod。 可将 Pod 配置为与 AKS 通信，与服务的通信将自动负载均衡到作为服务成员的所有 Pod。

  • 为了利用可用性区域，节点池包含作为区域资源的基础 VM。 为了支持具有不同计算或存储需求的应用程序，可以在创建用户节点池时使用特定 VM 大小创建用户节点池。

    例如，你可能决定为用户节点使用 M-series 下的 Standard_M32ms，因为应用程序中的微服务需要高吞吐量、低延迟和内存优化的 VM 大小，以提供高 vCPU 计数和大量内存。 根据部署区域，在 Azure 门户中选择 VM 大小时，你可能会看到此 VM 大小仅在区域 1 和 2 中受支持。 可以接受此复原能力配置作为高性能的折衷方案。

  • 创建节点池后，无法更改其 VM 大小。 有关节点池限制的详细信息，请参阅限制。

Azure Database for MySQL 灵活服务器

在特定区域（例如区域 1 和 2）中部署节点池意味着 AKS 群集的所有服务依赖项也必须支持区域 1 和 2。 在此工作负载体系结构中，AKS 群集的某个服务依赖于具有区域复原能力的 Azure Database for MySQL 灵活服务器。 需要为主服务器选择区域 1，为备用服务器选择区域 2，以便与 AKS 用户节点池位于同一位置。

显示 MySQL 灵活服务器区域选择的插图

用于 Redis 的 Azure 缓存

  • Azure Cache for Redis 在你选择的可用性区域上将节点以循环方式分布在区域冗余缓存中。

  • 无法更新现有的高级缓存来使用区域冗余。 若要使用区域冗余，必须重新创建 Azure Cache for Redis。

  • 为获得最佳复原能力，我们建议创建包含三个或更多副本的 Azure Cache for Redis，以便可以跨三个可用性区域分布副本。

显示 Azure Cache for Redis 的三个副本的插图

灾难恢复注意事项

可用性区域用于提高复原能力，以在部署的主要区域内实现工作负载的高可用性。

灾难恢复包括业务连续性计划中定义的恢复操作和实践。 业务连续性计划考虑到了工作负载在中断事件期间如何恢复，以及在事件过后如何完全恢复。 考虑将部署扩展到备用区域。

显示次要区域部署体系结构的插图

对于应用层，请查看本文中有关 AKS 的业务连续性和灾难恢复注意事项的部分。

  • 考虑在备用区域中运行多个 AKS 群集。 备用区域可以使用配对的次要区域。 或者，如果主要区域没有区域配对，你可以根据可用服务、容量、地理邻近性和数据主权考虑因素来选择备用区域。 请查看 Azure 区域决策指南。 另请查看部署缩放单元模式。

  • 可以选择为 AKS 群集配置主动-主动、主动-备用、主动-被动模式。

  • 对于数据库层，灾难恢复功能包括异地冗余备份，此功能可以在其他区域中启动异地还原和只读副本部署。

  • 在服务中断期间，需要确定是否要启动恢复。 仅当服务中断的持续时间可能超过工作负荷的恢复时间目标 (RTO) 时，才需要启动恢复操作。 否则，将通过检查 Azure 服务运行状况仪表板上的服务状态来等待服务恢复。 在 Azure 门户的“服务运行状况”边栏选项卡上，可以查看与订阅关联的任何通知。

  • 通过 Azure Database for MySQL 中的异地还原功能启动恢复时，将使用从另一区域复制的备份数据创建新的数据库服务器。

后续步骤

了解有关以下方面的详细信息：

支持可用性区域的 Azure 服务