运行或缩放大型 AKS 群集时出现的常见问题常见问题解答

  • 项目

本文解答了有关在 Microsoft Azure Kubernetes 服务（AKS）中运行或缩放大型群集时可能出现的常见问题的常见问题。 大型群集是任何以 500 节点以上的规模运行的群集。

创建、纵向扩展或升级期间出现“超出配额”错误

若要解决此问题，请在尝试在其中创建、缩放或升级的订阅中创建支持请求，并请求相应资源类型的配额。 有关详细信息，请参阅 区域计算配额。

部署使用高级网络的 AKS 群集时，出现“insufficientSubnetSize”错误

此错误指示用于群集的子网在其 CIDR 中不再具有可用的 IP，以便成功分配资源。 在升级、横向扩展或节点池创建过程中可能会出现此问题。 出现此问题的原因是子网中的可用 IP 数小于以下公式的结果：

请求的节点数 * 节点池 --max-pod 值

先决条件

  • 若要扩展到超过 400 个节点，必须使用 Azure CNI 网络插件。

  • 若要帮助规划虚拟网络和子网以容纳要部署的节点数和 Pod 数，请参阅 为群集规划 IP 地址。 若要减少由于 IP 耗尽而创建的子网规划或群集重新创建的开销，请参阅 动态 IP 分配。

解决方案

由于无法更新现有子网的 CIDR 范围，因此必须具有创建新子网以解决此问题的权限。 执行以下步骤：

  1. 重新生成一个具有更大 CIDR 范围的新子网，该范围足以满足操作目标。

  2. 创建具有新非重叠范围的新子网。

  3. 在新子网上创建新的节点池。

  4. 从驻留在要替换的旧子网中的旧节点池中清空 Pod。

  5. 删除旧子网和旧节点池。

由于 SNAT 端口耗尽，我出现零星的出口连接失败

对于规模相对较大（超过 500 个节点）运行的群集，建议使用 AKS 托管网络地址转换（NAT）网关 提高可伸缩性。 Azure NAT 网关允许每个 IP 地址最多 64,512 个出站 UDP 和 TCP 流量流，最多允许 16 个 IP 地址。

如果不使用托管 NAT，请参阅 排查源网络地址转换（SNAT）耗尽和连接超时问题 ，以了解和解决 SNAT 端口耗尽问题。

我无法使用 Azure 门户 纵向扩展到 5,000 个节点

执行以下步骤，使用 Azure CLI 最多可扩展到 5,000 个节点：

  1. 在群集中创建最小节点池数（因为最大节点池节点限制为 1,000），方法是运行以下命令：

    az aks nodepool add --resource-group MyResourceGroup --name nodepool1 --cluster-name MyManagedCluster

  2. 一次纵向扩展一个节点池。 理想情况下，在连续纵向扩展 1,000 之间设置 5 分钟的睡眠时间。 运行下面的命令：

    az aks nodepool scale --resource-group MyResourceGroup --name nodepool1 --cluster-name MyManagedCluster

我的升级正在运行，但速度很慢

在其默认配置中，AKS 通过执行以下操作在升级期间激增：

  • 创建一个新节点。
  • 将节点池扩展到所需节点数以外的节点数（一个节点）。

对于最大激增设置，默认值为一个节点意味着 AKS 会在清空现有应用程序之前创建一个新节点，并替换早期版本的节点。 此额外节点允许 AKS 最大程度地减少工作负荷中断。

升级具有多个节点的群集时，如果使用默认值 max-surge，可能需要几个小时才能升级整个群集。 可以自定义 max-surge 每个节点池的属性，以便在升级速度和升级中断之间进行权衡。 通过增加最大激增值，可以更快地完成升级过程。 但是，最大激增的较大值也可能导致升级过程中的中断。

运行以下命令来增加或自定义现有节点池的最大激增：

az aks nodepool update --resource-group MyResourceGroup --name mynodepool --cluster-name MyManagedCluster --max-surge 5

还必须考虑部署设置如何延迟升级或缩放操作的完成：

提示

若要获取有关此行为的更多见解，可以在Azure 门户的“活动日志”页上查看错误详细信息，或查看群集上的资源日志。

我的升级已达到配额（5,000 个群集）限制

若要解决此问题，请参阅 “增加区域 vCPU 配额”。

由于超时错误，在超过 750 个节点创建内部服务时速度缓慢或失败

标准负载均衡器（SLB）后端池更新是已知的性能瓶颈。 我们正在努力实现一项新功能，以便更快地大规模创建服务和 SLB。 若要向我们发送有关此问题的反馈，请参阅 Azure Kubernetes 对具有基于 IP 的后端池的负载均衡器的支持。

解决方案

建议将群集缩减到少于 750 个节点，然后为群集创建内部负载均衡器。 若要创建内部负载均衡器，请根据以下示例过程创建 LoadBalancer 服务类型和 azure-load-balancer-internal 批注。

步骤 1：创建内部负载均衡器

若要创建内部负载均衡器，请创建一个名为 internal-lb.yaml 的服务清单，其中包含 LoadBalancer 服务类型和 azure-load-balancer-internal 批注，如以下示例所示：

apiVersion: v1
kind: Service
metadata:
  name: internal-app
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-internal: "true"
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: internal-app

步骤 2：部署内部负载均衡器

使用 kubectl apply 命令部署内部负载均衡器，并指定 YAML 清单的名称，如以下示例所示：

kubectl apply -f internal-lb.yaml

创建群集后，还可以预配内部负载均衡器（按照此过程），并保持内部负载均衡服务运行。 通过执行此操作，可以大规模向负载均衡器添加更多服务。

大规模创建 SLB 服务需要数小时才能运行

SLB 后端池更新是已知的性能瓶颈。 我们正在开发一项新功能，使你能够大规模运行负载均衡服务，同时提高创建、更新和删除操作的性能。 若要向我们发送反馈，请参阅 Azure Kubernetes 对具有基于 IP 的后端池的负载均衡器的支持。

第三方信息免责声明

本文中提到的第三方产品由 Microsoft 以外的其他公司提供。 Microsoft 不对这些产品的性能或可靠性提供任何明示或暗示性担保。

联系我们寻求帮助

如果你有任何疑问或需要帮助，请创建支持请求或联系 Azure 社区支持。 你还可以将产品反馈提交到 Azure 反馈社区。