运行或缩放大型 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 反馈社区