Problemas comunes al ejecutar o escalar clústeres de AKS de gran tamaño

  • Artículo

En este artículo se responden las preguntas más frecuentes sobre los problemas comunes que pueden producirse al ejecutar o escalar clústeres grandes en Microsoft Azure Kubernetes Service (AKS). Un clúster grande es cualquier clúster que se ejecute a más de 500 nodos.

Obtengo un error de "cuota superada" durante la creación, el escalado vertical o la actualización

Para resolver este problema, cree una solicitud de soporte técnico en la suscripción en la que intenta crear, escalar o actualizar y solicitar una cuota para el tipo de recurso correspondiente. Para obtener más información, vea Cuotas de proceso regionales.

Obtengo un error "insufficientSubnetSize" al implementar un clúster de AKS que usa redes avanzadas.

Este error indica que una subred que está en uso para un clúster ya no tiene direcciones IP disponibles en su CIDR para la asignación de recursos correcta. Este problema puede producirse durante las actualizaciones, el escalado horizontal o la creación del grupo de nodos. Este problema se produce porque el número de direcciones IP libres de la subred es menor que el resultado de la fórmula siguiente:

número de nodos solicitados * valor del grupo de --max-pod nodos

Requisitos previos

Solución

Dado que no puede actualizar el intervalo CIDR de una subred existente, debe tener permiso para crear una nueva subred para resolver este problema. Siga estos pasos:

  1. Recompile una nueva subred que tenga un intervalo CIDR más grande que sea suficiente para los objetivos de la operación.

  2. Create una nueva subred que tiene un nuevo intervalo no superpuesto.

  3. Create un nuevo grupo de nodos en la nueva subred.

  4. Purgar pods del grupo de nodos antiguo que reside en la subred antigua que se reemplazará.

  5. Elimine la subred antigua y el grupo de nodos antiguo.

Tengo errores de conectividad de salida esporádicos debido al agotamiento del puerto SNAT

Para los clústeres que se ejecutan a una escala relativamente grande (más de 500 nodos), se recomienda usar la puerta de enlace de traducción de direcciones de red administrada (NAT) de AKS para una mayor escalabilidad. Azure NAT Gateway permite hasta 64 512 flujos de tráfico UDP y TCP salientes por dirección IP y un máximo de 16 direcciones IP.

Si no usa NAT administrada, consulte Solución de problemas de agotamiento de la traducción de direcciones de red de origen (SNAT) y tiempos de espera de conexión para comprender y resolver problemas de agotamiento del puerto SNAT.

No puedo escalar verticalmente hasta 5000 nodos mediante el Azure Portal

Siga estos pasos para usar la CLI de Azure para escalar verticalmente hasta un máximo de 5 000 nodos:

  1. Create un número mínimo de grupos de nodos en el clúster (porque el límite máximo de nodos del grupo de nodos es 1000) mediante la ejecución del siguiente comando:

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

  2. Escale verticalmente los grupos de nodos de uno en uno. Idealmente, establezca cinco minutos de tiempo de suspensión entre escalados consecutivos de 1000. Ejecute el siguiente comando:

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

Mi actualización se está ejecutando, pero es lenta.

En su configuración predeterminada, AKS aumenta durante una actualización realizando las siguientes acciones:

  • Crear un nodo nuevo.
  • Escalado del grupo de nodos más allá del número deseado de nodos por un nodo.

Para la configuración de sobrecarga máxima, un valor predeterminado de un nodo significa que AKS crea un nuevo nodo antes de purgar las aplicaciones existentes y reemplazar un nodo con versiones anteriores. Este nodo adicional permite que AKS minimice la interrupción de la carga de trabajo.

Al actualizar clústeres que tienen muchos nodos, puede tardar varias horas en actualizar todo el clúster si usa el valor predeterminado de max-surge. Puede personalizar la max-surge propiedad por grupo de nodos para habilitar un equilibrio entre la velocidad de actualización y la interrupción de la actualización. Al aumentar el valor máximo de sobrecarga, permite que el proceso de actualización finalice antes. Sin embargo, un valor grande para el pico máximo también puede provocar interrupciones durante el proceso de actualización.

Ejecute el siguiente comando para aumentar o personalizar el pico máximo de un grupo de nodos existente:

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

Mi actualización está alcanzando el límite de cuota (5000 clústeres)

Para resolver este problema, consulte Aumento de las cuotas de vCPU regionales.

La creación de un servicio interno en más de 750 nodos es lenta o produce errores debido a un error de tiempo de espera.

Standard Load Balancer (SLB) las actualizaciones del grupo de back-end son un cuello de botella de rendimiento conocido. Estamos trabajando en una nueva funcionalidad que permitirá la creación más rápida de servicios y SLB a escala. Para enviarnos sus comentarios sobre este problema, consulte Compatibilidad de Azure Kubernetes con el equilibrador de carga con un grupo de back-end basado en IP.

Solución

Se recomienda reducir verticalmente el clúster a menos de 750 nodos y, a continuación, crear un equilibrador de carga interno para el clúster. Para crear un equilibrador de carga interno, cree un tipo de servicio y azure-load-balancer-internal una LoadBalancer anotación, según el procedimiento de ejemplo siguiente.

Paso 1: Create un equilibrador de carga interno

Para crear un equilibrador de carga interno, cree un manifiesto de servicio denominado internal-lb.yaml y que contenga el LoadBalancer tipo de servicio y la azure-load-balancer-internal anotación, como se muestra en el ejemplo siguiente:

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

Paso 2: Implementación del equilibrador de carga interno

Implemente el equilibrador de carga interno mediante el kubectl apply comando y especifique el nombre del manifiesto YAML, como se muestra en el ejemplo siguiente:

kubectl apply -f internal-lb.yaml

Una vez creado el clúster, también puede aprovisionar un equilibrador de carga interno (según este procedimiento) y mantener un servicio interno con equilibrio de carga en ejecución. Esto le permite agregar más servicios al equilibrador de carga a escala.

La creación del servicio SLB a escala tarda horas en ejecutarse

Las actualizaciones del grupo de back-end de SLB son un cuello de botella de rendimiento conocido. Estamos trabajando en una nueva funcionalidad que le permitirá ejecutar servicios de carga equilibrada a escala con un rendimiento considerablemente más rápido para las operaciones de creación, actualización y eliminación. Para enviarnos sus comentarios, consulte Compatibilidad de Azure Kubernetes con el equilibrador de carga con un grupo de back-end basado en IP.

Aviso de declinación de responsabilidades sobre la información de terceros

Los productos de otros fabricantes que se mencionan en este artículo han sido creados por compañías independientes de Microsoft. Microsoft no ofrece ninguna garantía, ya sea implícita o de otro tipo, sobre la confiabilidad o el rendimiento de dichos productos.

Ponte en contacto con nosotros para obtener ayuda

Si tiene preguntas o necesita ayuda, cree una solicitud de soporte o busque consejo en la comunidad de Azure. También puede enviar comentarios sobre el producto con los comentarios de la comunidad de Azure.