Procedimientos recomendados para el rendimiento y el escalado de cargas de trabajo de gran tamaño en Azure Kubernetes Service (AKS)

  • Artículo

Nota:

Este artículo se centra en los procedimientos recomendados generales para cargas de trabajo de gran tamaño. Para conocer los procedimientos recomendados específicos de cargas de trabajo pequeñas y medianas, consulteProcedimientos recomendados de rendimiento y escalado para cargas de trabajo pequeñas a medianas en Azure Kubernetes Service (AKS).

A medida que implementa y mantiene clústeres en AKS, puede usar los siguientes procedimientos recomendados para ayudarle a optimizar el rendimiento y el escalado.

Tenga en cuenta que de gran tamaño es un término relativo. Kubernetes tiene un sobre de escala multidimensional y el sobre de escala de la carga de trabajo depende de los recursos que use. Por ejemplo, un clúster con 100 nodos y miles de pods o CRD puede considerarse de gran tamaño. Un clúster de 1000 nodos con 1000 pods y otros recursos podría considerarse pequeño desde la perspectiva del plano de control. La mejor señal para la escala de un plano de control de Kubernetes es la tasa de éxito y la latencia de solicitudes HTTP del servidor de API, ya que es un proxy para la cantidad de carga en el plano de control.

En este artículo, aprenderá lo siguiente:

  • Escalabilidad del plano de control de AKS y Kubernetes.
  • Procedimientos recomendados de cliente de Kubernetes, como retroceso, inspecciones y paginación.
  • Límites de la regulación de la API y la plataforma de Azure.
  • Limitaciones de característica.
  • Procedimientos recomendados de escalado de grupos de nodos y redes.

Escalabilidad del plano de control de AKS y Kubernetes

En AKS, un clúster consta de un conjunto de nodos (máquinas virtuales o físicas) que ejecutan agentes de Kubernetes y se administran mediante el plano de control de Kubernetes hospedado por AKS. Aunque AKS optimiza el plano de control de Kubernetes y sus componentes para la escalabilidad y el rendimiento, sigue enlazado por los límites del proyecto ascendente.

Kubernetes tiene un sobre de escala multidimensional con cada tipo de recurso que representa una dimensión. No todos los recursos son iguales. Por ejemplo, las inspecciones suelen establecerse en secretos, lo que da lugar a llamadas de lista al kube-apiserver que agregan costo y una carga desproporcionadamente mayor en el plano de control en comparación con los recursos sin inspecciones.

El plano de control administra todo el escalado de recursos del clúster, por lo que cuanto más escale el clúster dentro de una dimensión determinada, menos se puede escalar dentro de otras dimensiones. Por ejemplo, ejecutar cientos de miles de pods en un clúster de AKS afecta a la tasa de renovación de pods (mutaciones de pod por segundo) que el plano de control puede admitir.

El tamaño del sobre es proporcional al tamaño del plano de control de Kubernetes. AKS admite tres niveles de plano de control como parte de la SKU base: los niveles Gratis, Estándar y Premium. Para obtener más información, consulte Planes de tarifa Gratis, Estándar y Premium para la administración de clústeres de AKS.

Importante

Se recomienda encarecidamente usar el nivel Estándar o Premium para cargas de trabajo de producción o a gran escala. AKS escala en vertical automáticamente el plano de control de Kubernetes para admitir los siguientes límites de escalado:

  • Hasta 5000 nodos por clúster de AKS
  • 200 000 pods por clúster de AKS (con superposición de Azure CNI)

En la mayoría de los casos, cruzar el umbral de límite de escala da como resultado un rendimiento degradado, pero no hace que el clúster conmute inmediatamente por error. Para administrar la carga en el plano de control de Kubernetes, considere la posibilidad de escalar en lotes de hasta un 10-20 % de la escala actual. Por ejemplo, para un clúster de 5000 nodos, escale verticalmente los incrementos de 500 a 1000 nodos. Aunque AKS escala automáticamente el plano de control, no se produce de forma instantánea.

Puede aprovechar la prioridad de la API y la equidad (APF) para limitar los clientes específicos y los tipos de solicitud para proteger el plano de control durante la renovación y la carga elevadas.

Clientes de Kubernetes

Los clientes de Kubernetes son los clientes de aplicaciones, como operadores o agentes de supervisión, implementados en el clúster de Kubernetes que necesitan comunicarse con el servidor kube-api para realizar operaciones de lectura o mutación. Es importante optimizar el comportamiento de estos clientes para minimizar la carga que agregan al servidor kube-api y al plano de control de Kubernetes.

Puede analizar el tráfico del servidor de API y el comportamiento del cliente a través de los registros de auditoría de Kube. Para más información, consulte Solución de problemas del plano de control de Kubernetes.

Las solicitudes LIST pueden ser costosas. Al trabajar con listas que pueden tener más de unos pocos miles de objetos pequeños o más de unos pocos cientos de objetos grandes, debe tener en cuenta las siguientes directrices:

  • Tenga en cuenta el número de objetos (CR) que espera que existan finalmente al definir un nuevo tipo de recurso (CRD).
  • La carga en etcd y el servidor de API se basa principalmente en el número de objetos que existen, no en el número de objetos que se devuelven. Incluso si usa un selector de campos para filtrar la lista y recuperar solo un pequeño número de resultados, estas directrices se siguen aplicando. La única excepción es la recuperación de un único objeto por metadata.name.
  • Evite las llamadas LIST repetidas si es posible si el código necesita mantener una lista actualizada de objetos en memoria. En su lugar, considere la posibilidad de usar las clases de informadores proporcionadas en la mayoría de las bibliotecas de Kubernetes. Los informadores combinan automáticamente las funcionalidades LIST y WATCH para mantener eficazmente una colección en memoria.
  • Considere si necesita una coherencia fuerte si los informadores no satisfacen sus necesidades. ¿Necesita ver los datos más recientes, hasta el momento exacto en el que emitió la consulta? Si no es así, establezca ResourceVersion=0. Esto hace que la caché del servidor de API sirva la solicitud en lugar de etcd.
  • Si no puede usar informadores o la memoria caché del servidor de API, lea listas grandes en fragmentos.
  • Evite enumerar con más frecuencia de lo necesario. Si no puede usar informadores, considere la frecuencia con la que la aplicación enumera los recursos. Después de leer el último objeto de una lista grande, no vuelva a consultar inmediatamente la misma lista. Debería esperar un tiempo.
  • Tenga en cuenta el número de instancias en ejecución de la aplicación del cliente. Hay una gran diferencia entre tener un único controlador enumerando objetos frente a tener pods en cada nodo haciendo lo mismo. Si tiene previsto tener varias instancias de la aplicación cliente enumerando periódicamente un gran número de objetos, la solución no se escalará a clústeres grandes.

Limitación de la API y la plataforma de Azure

La carga en una aplicación en la nube puede variar con el tiempo en función de factores como el número de usuarios activos o los tipos de acciones que realizan los usuarios. Si los requisitos de procesamiento del sistema superan la capacidad de los recursos disponibles, el sistema puede sobrecargarse y sufrir un rendimiento deficiente y errores.

Para controlar los distintos tamaños de carga en una aplicación en la nube, puede permitir que la aplicación use recursos hasta un límite especificado y, a continuación, limitarlos cuando se alcance el límite. En Azure, la limitación se produce en dos niveles. Azure Resource Manager (ARM) regula las solicitudes para la suscripción y el inquilino. Si la solicitud está por debajo de los límites de regulación para la suscripción y el inquilino, ARM dirige la solicitud al proveedor de recursos. El proveedor de recursos aplica los límites de regulación adaptados a sus operaciones. Para más información, consulte Solicitudes de regulación de ARM.

Administración de la regulación en AKS

Normalmente, los límites de la API de Azure se definen en un nivel de combinación de región de suscripción. Por ejemplo, todos los clientes de una suscripción de una región determinada comparten límites de API para una API de Azure determinada, como las API PUT de Virtual Machine Scale Sets. Cada clúster de AKS tiene varios clientes de propiedad de AKS, como proveedor de nube o escalador automático de clústeres, o clientes propiedad del cliente, como Datadog o Prometheus autohospedado, que llaman a las API de Azure. Al ejecutar varios clústeres de AKS en una suscripción dentro de una región determinada, todos los clientes propiedad de AKS y propiedad del cliente dentro de los clústeres comparten un conjunto común de límites de API. Por lo tanto, el número de clústeres que puede implementar en una región de suscripción es una función del número de clientes implementados, sus patrones de llamada y la escala y elasticidad generales de los clústeres.

Teniendo en cuenta las consideraciones anteriores, los clientes suelen ser capaces de implementar entre 20 y 40 clústeres de pequeña y mediana escala por región de suscripción. Puede maximizar la escala de suscripciones mediante los siguientes procedimientos recomendados:

Actualice siempre los clústeres de Kubernetes a la versión más reciente. Las versiones más recientes contienen muchas mejoras que abordan los problemas de rendimiento y limitación. Si usa una versión actualizada de Kubernetes y sigue viendo la limitación debido a la carga real o al número de clientes de la suscripción, puede probar las siguientes opciones:

  • Análisis de errores mediante diagnóstico y solución de problemas de AKS: puede usar el Diagnóstico y solución de problemas de AKS para analizar errores, identificar la causa principal y obtener recomendaciones de resolución.
  • Dividir los clústeres en distintas suscripciones o regiones: si tiene un gran número de clústeres y grupos de nodos que usan Virtual Machine Scale Sets, puede dividirlos en distintas suscripciones o regiones dentro de la misma suscripción. La mayoría de los límites de la API de Azure se comparten en el nivel de suscripción, por lo que puede mover o escalar los clústeres a distintas suscripciones o regiones para desbloquearse en la limitación de la API de Azure. Esta opción es especialmente útil si espera que los clústeres tengan una gran actividad. No hay ninguna guía genérica para estos límites. Si quiere instrucciones específicas, puede crear una incidencia de soporte técnico.

Limitaciones de característica

A medida que escale los clústeres de AKS a puntos de escala más grandes, tenga en cuenta las siguientes limitaciones de características:

Nota:

Durante la operación para escalar el plano de control, es posible que encuentre latencia o tiempos de espera elevados en el servidor de API durante un máximo de 15 minutos. Si sigue teniendo problemas al escalar al límite admitido, abra una incidencia de soporte técnico.

  • Azure Network Policy Manager (Azure npm) solo admite hasta 250 nodos.
  • Algunas métricas de nodo de AKS, incluidas el uso del disco del nodo, el uso de CPU y memoria del nodo, y la salida/entrada de red, no estarán accesibles en las métricas de la plataforma de Azure Monitor después de escalar verticalmente el plano de control. Para confirmar si el plano de control se ha escalado verticalmente, busque el mapa de configuración "control-plane-scaling-status".
kubectl describe configmap control-plane-scaling-status -n kube-system

Redes

A medida que escale los clústeres de AKS a puntos de escala más grandes, tenga en cuenta los siguientes procedimientos recomendados de red:

  • Use NAT administrado para la salida del clúster con al menos 2 direcciones IP públicas en NAT Gateway. Para más información, consulte Creación de una puerta de enlace NAT administrada para el clúster de AKS.
  • Use Superposición de Azure CNI para escalar verticalmente hasta 200 000 pods y 5000 nodos por clúster. Para obtener más información, consulte Configuración de redes de Azure CNI en AKS.
  • Si la aplicación necesita comunicación directa entre pods entre los clústeres, use Azure CNI con asignación de IP dinámica y escale verticalmente hasta 50 000 pods de aplicación por clúster con una dirección IP enrutable por pod. Para más información, consulte Configuración de redes de Azure CNI para la asignación dinámica de IP en AKS.
  • Si usa servicios internos de Kubernetes detrás de un equilibrador de carga interno, se recomienda crear un equilibrador de carga interno o un servicio con un escalado por debajo de 750 nodos para garantizar un rendimiento óptimo del escalado y la elasticidad del equilibrador de carga.
  • Azure npm solo admite hasta 250 nodos. Si desea aplicar directivas de red para clústeres más grandes, considere la posibilidad de usar Azure CNI con tecnología de Cilium, que combina el sólido plano de control de Azure CNI con el plano de datos de Cilium para proporcionar redes y seguridad de alto rendimiento.

Escalado de grupos de nodos

A medida que escale los clústeres de AKS a puntos de escalado más grandes, tenga en cuenta los siguientes procedimientos recomendados de escalado de grupos de nodos:

  • En el caso de los grupos de nodos del sistema, use la SKU Standard_D16ds_v5 o una SKU de máquina virtual de núcleo o memoria equivalente con discos de SO efímeros para proporcionar recursos de proceso suficientes para los pods de kube-system.
  • Dado que AKS tiene un límite de 1000 nodos por grupo de nodos, se recomienda crear al menos cinco grupos de nodos de usuario para escalar hasta 5000 nodos.
  • Al ejecutar clústeres de AKS a gran escala, use el escalador automático de clústeres siempre que sea posible para garantizar el escalado dinámico de los grupos de nodos en función de la demanda de recursos de proceso. Para obtener más información, consulte Escalado automático de un clúster de AKS para satisfacer las necesidades de la aplicación.
  • Si va a escalar a más de 1000 nodos sin el escalador automático de clústeres, se recomienda escalar por lotes de un máximo de 500-700 nodos de cada vez. Las operaciones de escalado deben tener de dos a cinco minutos de tiempo de espera entre operaciones de escalado para evitar la limitación de la API de Azure. Para obtener más información, consulte Gestión de la API: directivas de limitación y almacenamiento en caché.

Consideraciones de actualización de clústeres y procedimientos recomendados

  • Cuando un clúster alcanza el límite de 5000 nodos, se bloquean las actualizaciones del clúster. Estos límites impiden una actualización porque no hay capacidad de nodo disponible para realizar actualizaciones graduales dentro del límite de la propiedad de sobrecarga máxima. Si tiene un clúster en este límite, se recomienda reducir verticalmente el clúster a menos de 3000 nodos antes de intentar actualizar un clúster. Esto proporcionará capacidad adicional para el abandono de nodos y minimizará la carga en el plano de control.
  • Al actualizar clústeres con más de 500 nodos, se recomienda usar una configuración de sobrecarga máxima del 10 al 20 % de la capacidad del grupo de nodos. AKS configura las actualizaciones con un valor predeterminado del 10 % para la sobrecarga máxima. Puede personalizar el valor de la sobrecarga máxima por grupo de nodos para permitir un equilibrio entre la velocidad de actualización y la interrupción de las cargas de trabajo. Al aumentar el valor de sobrecarga máxima, el proceso de actualización se completa más rápido, pero podría experimentar interrupciones durante el proceso de actualización. Para más información, consulte Personalización de la actualización de sobrecarga de nodos.
  • Para obtener más información sobre la actualización de clústeres, consulte Actualización de un clúster de AKS.