通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

Azure Kubernetes 服务 (AKS) 的高可用性和灾难恢复概述

  • 项目

在云中创建和管理应用程序时，始终存在因故障和灾难而造成中断的风险。 为了确保业务连续性 (BC)，需要规划高可用性 (HA) 和灾难恢复 (DR)。

HA 是指高度可靠且故障时间最短的系统或服务的设计和实施。 HA 是工具、技术和流程的组合，可确保系统或服务能够执行其预期功能。 HA 是 DR 规划的重要组成部分。 DR 是从灾难中恢复并将业务运营恢复到正常状态的过程。 DR 是 BC 的一部分，后者是维持业务功能或在发生重大中断时快速恢复业务功能的过程。

本文介绍部署到 AKS 的应用程序的一些建议做法，但并未详尽列出所有可能的解决方案。

技术概述

Kubernetes 群集分为两个组件：

  • 控制平面，提供核心 Kubernetes 服务和应用程序工作负载的编排，以及
  • 运行应用程序工作负载的节点。

此图显示 Kubernetes 控制平面和节点组件。

创建 AKS 群集时，Azure 平台会自动创建并配置控制平面。 AKS 为群集管理提供两个定价层：免费层和标准层。 有关详细信息，请参阅 AKS 群集管理的免费和标准定价层。

控制平面及其资源仅驻留在创建群集的区域。 AKS 提供单租户控制平面、专用 API 服务器、计划程序等。你定义节点的数量和大小，Azure 平台配置控制平面和节点之间的安全通信。 通过 Kubernetes API（例如 kubectl 或 Kubernetes 仪表板）与控制平面进行交互。

要运行应用程序和支持服务，需要 Kubernetes 节点。 一个 AKS 群集至少有一个节点，这是运行 Kubernetes 节点组件和容器运行时的 Azure 虚拟机 (VM)。 节点的 Azure VM 大小定义了 CPU、内存大小以及可用存储类型（如高性能 SSD 或常规 HDD）。 围绕应用程序是否需要大量 CPU、内存或高性能存储来计划 VM 和存储大小。 在 AKS 中，群集节点的 VM 映像基于 Ubuntu Linux、Azure Linux 或 Windows Server 2022。 创建 AKS 群集或横向扩展节点数时，Azure 平台会自动创建和配置所请求数量的 VM。

有关 AKS 中的群集和工作负载组件的详细信息，请参阅AKS 的 Kubernetes 核心概念。

重要注意事项

区域和全球资源

区域资源作为部署标记的一部分预配到单个 Azure 区域。 这些资源与其他区域的资源不共享，并且可以独立删除或复制到其他区域。 有关详细信息，请参阅区域资源。

全局资源共享系统的生命周期，并且可以在多区域部署的上下文中全局可用。 有关详细信息，请参阅全局资源。

恢复目标

完整的灾难恢复计划必须指定应用程序实施的每个流程的业务要求：

  • 恢复点目标 (RPO) 是可接受数据丢失的最长持续时间。 RPO 以时间（例如分钟、小时或天）为单位进行度量。
  • 恢复时间目标 (RTO) 是可接受故障时间的最大持续时间，其中故障时间由规范定义。 例如，如果灾难中可接受的故障时间为八小时，则 RTO 为八小时。

可用性区域

可以使用可用性区域将数据分布到同一区域的多个可用性区域。 在一个区域内，可用性区域足够近，可以与其他可用性区域建立低延迟连接，但它们相距甚远，可以降低多个可用性区域受到本地中断或天气影响的可能性。 有关详细信息，请参阅有关使用可用性区域和区域的建议。

区域复原能力

AKS 群集能够抵御区域故障。 如果某个区域发生故障，群集仍然可以在其余区域运行。 群集的控制平面和节点分布在各个区域，Azure 平台会自动处理节点的分布。 有关详细信息，请参阅 AKS 区域复原能力。

负载均衡

全局负载均衡

全局负载均衡服务跨区域后端、云或混合本地服务分发流量。 这些服务将最终用户流量路由到最近的可用后端。 它们还对服务可靠性或性能的变化做出反应，以最大程度地提高可用性和性能。 以下 Azure 服务提供全局负载均衡：

区域负载均衡

区域负载均衡服务在虚拟网络中跨虚拟机或区域中的区域和区域冗余服务终结点分发流量。 以下 Azure 服务提供区域负载均衡：

可观察性

需要从应用程序和基础结构收集数据，以便有效操作并最大程度地提高可靠性。 Azure 提供用于监视和管理 AKS 工作负载的工具。 有关详细信息，请参阅可观测性资源。

范围定义

在管理 AKS 群集时，应用程序正常运行时间变得非常重要。 默认情况下，AKS 通过在虚拟机规模集中使用多个节点来提供高可用性，但这些节点不能保护系统免受区域故障的影响。 为了最大限度地延长正常运行时间，请提前规划以保持业务连续性，并遵循以下最佳做法，为灾难恢复做好准备：

  • 在多个区域规划 AKS 群集。
  • 使用 Azure 流量管理器跨多个群集路由流量。
  • 为容器映像注册表使用异地复制。
  • 跨多个群集计划应用程序状态。
  • 跨多个区域复制存储。

部署模型实施

部署模型 优点 缺点
主动-主动 • 故障转移期间不会出现数据丢失或不一致的情况
• 高复原能力
• 资源利用更充分，性能更高		 • 复杂的实施和管理
• 成本更高
• 需要负载均衡器和流量路由形式
主动-被动 • 实施和管理更简单
• 成本更低
• 不需要负载均衡器或流量管理器		 • 故障转移期间可能会出现数据丢失或不一致的情况
• 恢复时间和故障时间更长
• 资源利用不足
被动-寒 • 成本最低
• 不需要同步、复制、负载均衡器或流量管理器
• 适用于低优先级非关键工作负载		 • 故障转移期间出现数据丢失或不一致情况的风险很高
• 恢复时间和故障时间最长
• 需要手动干预来激活群集并触发备份

主动-主动高可用部署模型

在主动-主动高可用性 (HA) 部署模型中，在两个不同的 Azure 区域（通常是配对区域，例如加拿大中部和加拿大东部或美国东部 2 和美国中部）部署了两个独立的 AKS 群集，用于主动提供流量服务。

在此示例体系结构中：

  • 你在不同的 Azure 区域中部署两个 AKS 群集。
  • 在正常操作期间，网络流量在两个区域之间路由。 如果一个区域不可用，流量将被自动路由到离发出请求的用户最近的区域。
  • 每个区域 AKS 实例都有一个已部署的中心辐射对。 Azure 防火墙管理器策略管理跨区域的防火墙规则。
  • 每个区域都预配了 Azure Key Vault，用于存储机密和密钥。
  • Azure Front Door 对流量进行负载均衡并将流量路由到位于每个 AKS 群集前面的区域级 Azure 应用程序网关实例。
  • 区域级 Log Analytics 实例存储区域网络指标和诊断日志。
  • 工作负载的容器映像存储在托管容器注册表中。 单个 Azure 容器注册表用于群集中的所有 Kubernetes 实例。 Azure 容器注册表的异地复制支持将映像复制到所选 Azure 区域，并且即使某个区域遇到服务中断，也可继续访问映像。

若要在 AKS 中创建主动-主动部署模型，请执行以下步骤：

  1. 在两个不同的 Azure 区域中创建两个相同的部署。

  2. 创建两个 Web 应用实例。

  3. 使用以下资源创建 Azure Front Door 配置文件：

    • 一个终结点。
    • 两个源组，每个源组的优先级为 1。
    • 路由。

  4. 将网络流量限制为仅从 Azure Front Door 实例流向 Web 应用。 5. 配置所有其他后端 Azure 服务，例如数据库、存储帐户和身份验证提供程序。

  5. 通过持续部署将代码部署到这两个 Web 应用。

有关详细信息，请参阅 AKS 的建议主动-主动高可用性解决方案概述。

主动-被动灾难恢复部署模型

在主动-被动灾难恢复 (DR) 部署模型中，在两个不同的 Azure 区域（通常是配对区域，例如加拿大中部和加拿大东部或美国东部 2 和美国中部）部署了两个独立的 AKS 群集，用于主动提供流量服务。 在任何给定时间，只有一个群集主动提供流量服务。 另一个群集包含与主动群集相同的配置和应用程序数据，但除非流量管理器指示，否则不接受流量。

在此示例体系结构中：

  • 你在不同的 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 中创建主动-被动部署模型，请执行以下步骤：

  1. 在两个不同的 Azure 区域中创建两个相同的部署。

  2. 为辅助应用程序配置自动缩放规则，以便在主要区域变为非活动状态时，该计划缩放到与主要计划相同的实例计数。 处于非活动状态时，无需纵向扩展。 这有助于降低成本。

  3. 创建 Web 应用程序的两个实例，每个群集一个。

  4. 使用以下资源创建 Azure Front Door 配置文件：

    • 一个终结点。
    • 主要区域拥有一个优先级为 1 的源组。
    • 次要区域拥有一个优先级为 2 的次要源组。
    • 路由。

  5. 将网络流量限制为仅从 Azure Front Door 实例流向 Web 应用程序。

  6. 配置所有其他后端 Azure 服务，例如数据库、存储帐户和身份验证提供程序。

  7. 通过持续部署将代码部署到这两个 Web 应用程序。

有关详细信息，请参阅 AKS 的建议主动-被动灾难恢复解决方案概述。

被动-寒故障转移部署模型

被动-寒故障转移部署模型的配置方式与主动-被动灾难恢复部署模型相同，不同之处在于群集将保持非活动状态，直到用户在发生灾难时激活它们。 我们认为这种方法超出范围，因为它涉及与主动-被动类似的配置，但增加了激活群集和触发备份的手动干预的复杂性。

在此示例体系结构中：

  • 创建两个 AKS 群集，它们最好位于不同的区域或区域，以增强复原能力。
  • 需要进行故障转移时，可以激活部署来接管流量流。
  • 当主要被动群集出现故障时，需要手动激活寒群集来接管流量流。
  • 该条件需要通过每次手动输入或由指定的特定事件来设置。
  • 每个区域都预配了 Azure Key Vault，用于存储机密和密钥。
  • 区域 Log Analytics 实例存储每个群集的区域网络指标和诊断日志。

若要在 AKS 中创建被动-寒故障转移部署模型，请执行以下步骤：

  1. 在不同的分区/区域中创建两个相同的部署。
  2. 为辅助应用程序配置自动缩放规则，以便在主要区域变为非活动状态时，该计划缩放到与主要计划相同的实例计数。 处于非活动状态时，无需纵向扩展，这有助于降低成本。
  3. 创建 Web 应用程序的两个实例，每个群集一个。
  4. 配置所有其他后端 Azure 服务，例如数据库、存储帐户和身份验证提供程序。
  5. 设置应触发寒群集的条件。 如果需要，可以使用负载均衡器。

有关详细信息，请参阅 AKS 的建议被动-寒灾难恢复解决方案概述。

服务配额和限制

AKS 为资源和功能设置默认限制和配额，包括特定 VM SKU 的使用限制。

资源 限制
全局范围内每个订阅的最大群集数 5,000
每个区域每个订阅的最大群集数 1 100
包含虚拟机规模集和标准负载均衡器 SKU 的每个群集的最大节点数 5,000（所有节点池的总上限）
注意：如果无法将每个群集纵向扩展到 5,000 个节点，请参阅大型群集的最佳做法。
每个节点池的最大节点数（虚拟机规模集节点池） 1000
每个群集的最大节点池数 100
每个节点的最大 Pod 数：带 Kubenet 网络插件1 最大值：250
Azure CLI 默认值：110
Azure 资源管理器模板默认值：110
Azure 门户部署默认值：30
每个节点的最大 Pod 数：带 Azure 容器网络接口 (Azure CNI)2 最大值：250
建议用于 Windows Server 容器的最大数量：110
默认值：30
Open Service Mesh (OSM) AKS 加载项 Kubernetes 群集版本：AKS 支持的版本
每个群集的 OSM 控制器数：1
每个 OSM 控制器的 Pod 数：1600
由 OSM 管理的 Kubernetes 服务帐户数：160
具有标准负载均衡器 SKU 的每个群集的最大负载均衡 kubernetes 服务 300
包含虚拟机可用性集和基本负载均衡器 SKU 的每个群集的最大节点数 100

1 请求时允许更多。
2 Windows Server 容器必须使用 Azure CNI 网络插件。 Windows Server 容器不支持 Kubenet。

Kubernetes 控制平面层 限制
标准层 根据负载自动缩放 Kubernetes API 服务器。 更大的控制平面组件限制和 API 服务器/etcd 实例。
免费层 资源有限，即时请求限制为 50 个变动调用和 100 个只读调用。 建议的节点限制为每个群集 10 个节点。 最适合试验、学习和简单测试。 不建议用于生产/关键工作负载。

有关详细信息，请参阅 AKS 服务的配额和限制。

备份

Azure 备份支持使用备份扩展备份 AKS 群集资源和附加到群集的永久性卷。 备份保管库通过扩展与 AKS 群集通信以执行备份和还原操作。

有关详细信息，请参阅以下文章：