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

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 más información, consulte 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 correcta de recursos. Este problema puede producirse durante las actualizaciones, las escalas horizontales o la creación del grupo de nodos. Este problema se produce porque el número de direcciones IP gratuitas de la subred es menor que el resultado de la fórmula siguiente:

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

Requisitos previos

• Para escalar más allá de 400 nodos, debe usar el complemento de red de Azure CNI.

• Para ayudar a planear la red virtual y las subredes para dar cabida al número de nodos y pods que va a implementar, consulte Planeamiento de direcciones IP para el clúster. Para reducir la sobrecarga de planeación de subredes o re-creación de clústeres que haría debido al agotamiento de IP, consulte Asignación dinámica de IP.

Solución

Dado que no se 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 mayor que sea suficiente para los objetivos de operación.

2. Cree una nueva subred que tenga un nuevo intervalo no superpuesto.

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

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

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

Tengo errores de conectividad de salida esporádicos debido al agotamiento de puertos 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 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 administrado, consulte Solución de problemas de agotamiento de direcciones de red de origen (SNAT) y tiempos de espera de conexión para comprender y resolver problemas de agotamiento de puertos SNAT.

No puedo escalar verticalmente hasta 5000 nodos mediante Azure Portal

Use la CLI de Azure para escalar verticalmente hasta un máximo de 5000 nodos siguiendo estos pasos:

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

   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 mediante las siguientes acciones:

• Creación de un nuevo nodo.
• 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 reemplaza un nodo con versiones anteriores. Este nodo adicional permite a AKS minimizar 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, se habilita el proceso de actualización para que finalice antes. Sin embargo, un valor grande para el aumento máximo también podría provocar interrupciones durante el proceso de actualización.

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

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

También es importante tener en cuenta cómo la configuración de implementación podría retrasar la finalización de la operación de actualización o escalado:

• AKS no admite máquinas virtuales de la serie B de la familia de SKU en el grupo de nodos del sistema y puede experimentar un bajo rendimiento durante y después de las actualizaciones.
• Compruebe la configuración de recursos de PDB de la implementación para asegurarse de que son precisas para una actualización correcta. Para más información, consulte Procedimientos recomendados para cargas de trabajo de AKS.

Sugerencia

Para obtener más información sobre este comportamiento, puede ver los detalles del error en la página Registro de actividad de Azure Portal o revisar los registros de recursos del clúster.

Mi actualización alcanza el límite de cuota (5000 clústeres).

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

La creación del servicio interno en más de 750 nodos es lenta o no se puede realizar debido a un error de tiempo de espera

Las actualizaciones del grupo de back-end estándar de Load Balancer (SLB) 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 el 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: Crear 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 (por este procedimiento) y mantener en ejecución un servicio interno con equilibrio de carga. 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 con equilibrio de carga 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 el 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.