通过

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

Azure Kubernetes 服务 (AKS) 中大型工作负载的性能和缩放最佳做法

  • 项目

注意

本文重点介绍了“大型工作负载”的一般最佳做法。 有关特定于“中小型工作负载”的最佳做法，请参阅 Azure Kubernetes 服务 (AKS) 中的中小型工作负载的性能和缩放最佳做法。

在 AKS 中部署和维护群集时，可以使用以下最佳做法来帮助优化性能和缩放。

请记住，“大”是一个相对的术语。 Kubernetes 具有多维度的缩放范围，而工作负载的缩放范围取决于你使用的资源。 例如，具有 100 个节点和数千个 Pod 或 CRD 的群集可能被认为是大群集。 而从控制平面的角度来看，1,000 个节点的群集具有 1,000 个 Pod 和其他各种资源可能被认为是小群集。 Kubernetes 控制平面的最佳缩放信号是 API 服务器 HTTP 请求成功率和延迟，因为它是控制平面负载量的代理。

本文介绍：

  • AKS 和 Kubernetes 控制平面可伸缩性。
  • Kubernetes 客户端最佳做法，包括退避、监视和分页。
  • Azure API 和平台带宽限制。
  • 功能限制。
  • 网络和节点池缩放最佳做法。

AKS 和 Kubernetes 控制平面可伸缩性

在 AKS 中，“群集”由一组运行 Kubernetes 代理的节点（物理或虚拟机 (VM)）组成，这组节点由 AKS 托管的 Kubernetes 控制平面管理。 虽然 AKS 优化了 Kubernetes 控制平面及其组件，用以实现可伸缩性和性能优化，但其仍受到上游项目限制的约束。

Kubernetes 具有多维度的缩放范围，每个资源类型代表一个维度。 并非所有资源都一样。 例如，“监视”通常设置在机密上，这会导致对 kube-apiserver 的列表调用，而这增加了成本，并且与没有监视的资源相比，导致控制平面的负载不成比例地增加。

控制平面管理群集中的所有资源缩放，因此在给定维度内缩放群集越多，在其他维度内缩放群集就越少。 例如，在 AKS 群集中运行数十万个 Pod 会影响控制平面支持的 Pod 流失率（每秒 Pod 突变数）的多少。

缩放范围的大小与 Kubernetes 控制平面的大小成正比。 AKS 支持三个控制平面层作为基本 SKU 的一部分：免费层、标准层和高级层。 有关详细信息，请参阅 AKS 群集管理的免费、标准和高级定价层。

重要

我们强烈建议将标准层或高级层用于生产或大规模工作负载。 AKS 会自动纵向扩展 Kubernetes 控制平面以支持以下缩放限制：

  • 每个 AKS 群集最多有 5,000 个节点
  • 每个 AKS 群集有 200,000 个 Pod（使用 Azure CNI 覆盖）

在大多数情况下，超过缩放限制阈值会导致性能下降，但不会导致群集立即进行故障转移。 若要管理 Kubernetes 控制平面上的负载，请考虑按批次缩放，最大缩放比例为当前缩放的 10-20%。 例如，对于 5,000 个节点的群集，按增量缩放 500-1,000 个节点。 虽然 AKS 可以自动缩放控制平面，但它不会立即发生。

可以利用 API 优先级和公平性 (APF) 来限制特定的客户端和请求类型，以在高流失和负载的情况下保护控制平面。

Kubernetes 客户端

Kubernetes 客户端是在 Kubernetes 群集中部署的应用程序客户端（例如操作员或监视代理），需要与 kube-api 服务器通信以执行读取或修改操作。 优化这些客户端的行为，以最大程度地减少给 kube-api 服务器和 Kubernetes 控制平面增加的负载，这一点很重要。

你可以通过 Kube 审核日志来分析 API 服务器流量和客户端行为。 有关详细信息，请参阅 Kubernetes 控制平面故障排除。

LIST 请求可能会非常昂贵。 当处理可能包含数千个小型对象或超过几百个大型对象的列表时，应考虑以下准则：

  • 在定义新资源类型 (CRD) 时，请考虑最终期望存在的对象数 (CR)。
  • etcd 和 API 服务器上的负载主要依赖于存在的对象数，而不是返回的对象数。 即使使用字段选择器筛选列表并仅检索少量结果，这些准则仍然适用。 唯一的例外是按 metadata.name 检索单个对象。
  • 如果代码需要维护内存中对象的更新列表，请尽可能避免重复的 LIST 调用。 相反，请考虑使用大多数 Kubernetes 库中提供的 Informer 类。 通知器会自动合并 LIST 和 WATCH 功能，以有效维护内存中集合。
  • 如果通知器不能满足需求，请考虑你是否需要高度一致性。 是否需要查看最新的数据，直至查询发出时的确切时间点？ 如果不，请设置 ResourceVersion=0。 这会导致 API 服务器缓存服务于请求，而不是 etcd。
  • 如果无法使用通知器或 API 服务器缓存，则请分区块读取大型列表。
  • 避免高于需求的频繁列出。 如果无法使用通知器，请考虑应用程序列出资源的频率。 在读取大型列表中的最后一个对象后，请不要立即重新查询同一列表。 应等待一段时间。
  • 请考虑客户端应用程序正在运行的实例数。 让单个控制器列出对象与让每个节点上的 Pod 执行相同操作，这之间存在很大差异。 如果计划让客户端应用程序的多个实例定期列出大量对象，则解决方案不会扩展到大型群集。

Azure API 和平台带宽限制

云应用程序上的负载可能随着时间的推移而变化，这取决于活动用户数或用户执行的操作类型等因素。 如果系统的处理要求超过可用资源的容量，则系统可能会过载，导致性能下降和故障。

若要在云应用程序中处理不同负载大小，可以允许应用程序使用最多指定限制的资源，然后在达到限制时对其进行限制。 在 Azure 上，带宽限制在两个级别发生。 Azure 资源管理器 (ARM) 限制对订阅和租户的请求。 如果请求低于订阅和租户的带宽限制阈值，ARM 会将该请求路由到资源提供程序。 然后，资源提供程序将应用针对其操作定制的带宽限制。 有关详细信息，请参阅 ARM 带宽限制请求。

管理 AKS 中的带宽限制

Azure API 限制通常在订阅区域组合级别上定义。 例如，给定区域中订阅的所有客户端共享指定 Azure API（例如虚拟机规模集 PUT API）的 API 限制。 每个 AKS 群集都有多个 AKS 拥有的客户端，例如云提供商或群集自动缩放程序，或客户拥有的客户端，例如 Datadog 或自托管 Prometheus，它们都可调用 Azure API。 在给定区域内的订阅中运行多个 AKS 群集时，群集内所有 AKS 拥有的和客户拥有的客户端共享一组常见的 API 限制。 因此，可以在订阅区域中部署的群集数取决于已部署的客户端数、其调用模式以及群集的总体规模和弹性。

请记住上述的注意事项，客户通常能够在每个订阅区域部署 20-40 个中小型群集。 可以使用以下最佳做法使订阅规模最大化：

始终将 Kubernetes 群集升级到最新版本。 较新版本包含许多改进，可解决性能和带宽限制方面的问题。 如果使用已升级版本的 Kubernetes，但由于实际负载或订阅中的客户端数而导致仍然看到带宽限制，可以尝试以下选项：

  • 使用 AKS 诊断并解决问题来分析错误：可以使用 AKS 诊断并解决问题来分析错误、确定根本原因并获取解决方法建议。
  • 将群集拆分为不同的订阅或区域：如果有大量使用虚拟机规模集的群集和节点池，则可以将它们拆分为不同的订阅或同一订阅中的不同区域。 大多数 Azure API 限制在订阅区域级别共享，因此可以将群集移动或缩放到不同的订阅或区域，以便解除 Azure API 带宽限制阻止。 如果希望群集具有高活动性，此选项特别有用。 这些限制没有通用准则。 如果想要特定指导，可以创建支持票证。

功能限制

将 AKS 群集缩放到更大的规模点时，请记住以下功能限制：

注意

在缩放控制平面的操作期间，可能会遇到 API 服务器延迟增加或超时长达 15 分钟的情况。 如果在缩放到支持的限制时始终存在问题，请提交支持工单。

  • Azure 网络策略管理器 (Azure npm) 最多支持 250 个节点。
  • 某些 AKS 节点指标（包括节点磁盘使用情况、节点 CPU/内存使用情况和网络流入量/流出量）在控制平面纵向扩展后，无法在 Azure Monitor 平台指标中访问。 若要确认控制平面是否已纵向扩展，请查找 configmap“control-plane-scaling-status”
kubectl describe configmap control-plane-scaling-status -n kube-system
  • 对于具有 100 个以上节点的群集，不能使用“停止”和“启动”功能。 有关详细信息，请参阅停止和启动 AKS 群集。

网络

将 AKS 群集缩放到更大的规模点时，请记住以下网络最佳做法：

  • 对群集流出量使用托管 NAT，并且 NAT 网关上至少有 2 个公共 IP。 有关详细信息，请参阅为 AKS 群集创建托管 NAT 网关。
  • 使用 Azure CNI 覆盖以纵向扩展到每个群集的 200,000 个 Pod 和 5,000 个节点。 有关详细信息，请参阅在 AKS 中配置 Azure CNI 覆盖网络。
  • 如果应用程序需要跨群集的直接 Pod 到 Pod 通信，请使用具有动态 IP 分配的 Azure CNI，并纵向扩展到每个群集 50,000 个应用程序 Pod，并且每个 Pod 有一个可路由 IP。 有关详细信息，请参阅为 AKS 中的动态 IP 分配配置 Azure CNI 网络。
  • 在内部负载均衡器后面使用内部 Kubernetes 服务时，建议创建一个低于 750 节点规模的内部负载均衡器或服务，以获得最佳的缩放性能和负载均衡器弹性。
  • Azure npm 最多仅支持 250 个节点。 若要为较大的群集强制实施网络策略，请考虑使用由 Cilium 提供支持的 Azure CNI，它将 Azure CNI 的可靠控制平面与 Cilium 数据平面相结合，以提供高性能的网络和安全性。

节点池缩放

将 AKS 群集缩放到更大的规模点时，请记住以下节点池缩放最佳做法：

  • 对于系统节点池，请使用“Standard_D16ds_v5”SKU 或等效的具有临时 OS 磁盘的核心/内存 VM SKU，为 kube-system Pod 提供足够的计算资源。
  • 由于 AKS 对每个节点池的节点数限制为 1000 个，因此我们建议至少创建五个用户节点池以纵向扩展到 5000 个节点。
  • 在运行大规模 AKS 群集时，尽可能使用群集自动缩放程序，以确保根据计算资源的需求动态缩放节点池。 有关详细信息，请参阅自动缩放 AKS 群集以满足应用程序需求。
  • 如果在不使用群集自动缩放程序的情况下缩放到超过 1000 个节点，我们建议一次最多分批缩放 500 到 700 个节点。 这些缩放操作应在纵向扩展操作之间有两到五分钟的等待时间，以避免受到 Azure API 带宽限制。 有关详细信息，请参阅 API 管理：缓存和带宽限制策略。

群集升级注意事项和最佳做法

  • 当群集达到 5,000 个节点限制时，会阻止群集升级。 此限制会阻止升级，因为最大激增属性限制中没有可用节点容量来执行滚动更新。 如果你的群集达到此限制，建议在尝试群集升级之前将群集缩减为 3,000 个节点以下。 这将为节点变动提供额外的容量，并最大限度地减少控制平面上的负载。
  • 升级具有 500 个以上节点的群集时，建议将最大激增配置设置为节点池容量的 10-20%。 AKS 会将升级配置为使用最大激增的默认值 (10%)。 可以为每个节点池自定义最大激增设置，以便在升级速度与工作负载中断之间进行权衡。 如果增大最大激增设置，则升级过程可以更快完成，但你可能会在升级过程中遇到中断。 更多信息，请参阅自定义节点激增升级。
  • 有关群集升级的详细信息，请参阅升级 AKS 群集。