Procedimientos recomendados para el rendimiento y el escalado de cargas de trabajo de gran tamaño 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:

Escalado 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 nodos:

• Al ejecutar clústeres de AKS a escala, use el escalador automático del clúster o el aprovisionamiento automático de nodos siempre que sea posible para garantizar el escalado dinámico de nodos en función de la demanda de recursos de proceso.
• 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 un tiempo de espera de entre dos y cinco minutos entre operaciones 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é.
• 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.

Escalabilidad del plano de control de AKS y Kubernetes

En Kubernetes, todos los objetos que se ejecutan en un clúster son gestionados por el plano de control, el cual es administrado 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 y no todos los recursos están iguales en su costo. Por ejemplo, los Secretos suelen ser observados por múltiples controladores y pods, cada uno de los cuales realiza una llamada inicial a LIST para sincronizar el estado. Dado que los secretos suelen ser grandes y se actualizan con frecuencia, colocan más carga en el plano de control que los recursos vistos con menos frecuencia.

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.

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.

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.

Para confirmar si tu plano de control ha sido escalado, busca el configmap large-cluster-control-plane-scaling-status.

kubectl describe configmap large-cluster-control-plane-scaling-status -n kube-system

Consideraciones sobre el límite de escalado y plano de control de Kubernetes

Los clientes de Kubernetes son componentes de aplicación, como operadores o agentes de supervisión, que se ejecutan en el clúster y se comunican con kube-apiserver para leer o modificar recursos. Es importante optimizar cómo se comportan estos clientes para reducir la carga que colocan en kube-apiserver y en el plano de control de Kubernetes.

El número de solicitudes procesadas activamente por el servidor de API en cualquier momento determinado viene determinado por --max-requests-inflight y --max-mutating-requests-inflight. AKS usa los valores predeterminados de 400 y 200 solicitudes para estas marcas, lo que permite enviar un total de 600 solicitudes en un momento dado. A medida que escalamos el servidor API a tamaños mayores, aumentamos correspondientemente también las solicitudes en vuelo.

Dos tipos de objetos de Kubernetes, PriorityLevelConfiguration y FlowSchema (APF) determinan cómo el servidor de API divide la capacidad total de las solicitudes entre los tipos de solicitud. AKS usa la configuración predeterminada.

A cada PriorityLevelConfiguration se le asigna una parte de las solicitudes totales permitidas. Para ver los objetos PriorityLevelConfiguration en tu clúster y sus compartidos de solicitudes asignados, ejecuta el siguiente comando.

kubectl get --raw /metrics | grep apiserver_flowcontrol_nominal_limit_seats

FlowSchema asigna solicitudes del servidor de API a PriorityLevelConfiguration. Si varios objetos FlowSchema coinciden con una solicitud, el servidor de API selecciona el que tiene la prioridad de coincidencia más baja.

La asignación de FlowSchemas a PriorityLevelConfigurations se puede ver mediante este comando:

kubectl get flowschemas

Para confirmar si se están descartando solicitudes debido a APF, ejecute el siguiente comando:

kubectl get --raw /metrics | grep apiserver_flowcontrol_rejected_requests_total

Procedimientos recomendados de cliente de Kubernetes

Las llamadas LIST emitidas por clientes no optimizados suelen ser uno de los factores más importantes que limitan la escalabilidad de un clúster. 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 tamaño de la respuesta. Esta guía se aplica si el cliente emite un pequeño número de solicitudes LIST para objetos grandes o un gran número de solicitudes LIST para objetos más pequeños.

Uso de informadores

• Si el código necesita mantener una lista actualizada de objetos en la memoria, el uso de un informador de la biblioteca de cliente le proporcionará ventajas de observar los cambios en los recursos en función de los eventos en lugar de sondear los cambios. Este es el mejor enfoque para evitar LIST no optimizados y repetidos.

Uso de la caché del servidor de API

• Use resourceVersion=0 para devolver los resultados de la caché del servidor de API. Esto puede impedir que se capturen objetos de etcd, lo que reduce la carga etcd, pero no admite la paginación.

  /api/v1/namespaces/default/pods?resourceVersion=0
  

Uso eficaz de la API de Kubernetes

• Se recomienda usar el argumento watch siempre que sea posible. Sin argumentos, el comportamiento predeterminado es enumerar objetos. Consulte el ejemplo siguiente.

  /api/v1/namespaces/default/pods?watch=true
  

  Usa reloj con un resourceVersion conjunto como el valor más reciente conocido recibido de la lista o reloj anterior. Esto se gestiona automáticamente en client-go. Pero compruebe si usa un cliente de Kubernetes en otros lenguajes.

  /api/v1/namespaces/default/pods?watch=true&resourceVersion=<resourceversion>
  

• Si los controladores o operadores deben usar llamadas LIST, deben evitar sondear los recursos de todo el clúster sin selectores de etiquetas o campos, especialmente en clústeres grandes. En los ejemplos siguientes se muestran llamadas LIST optimizadas y no optimizadas.

  LISTA optimizada:

  /api/v1/namespaces/default/pods?fieldSelector=status.phase=Running
  

  Lista no optimizada:

  /api/v1/pods
  

• Utiliza la paginación para reducir el tamaño de las respuestas LIST si el cliente debe obtener datos de etcd. En el ejemplo siguiente se usa el argumento limit para restringir la respuesta a 100 objetos.

  /api/v1/namespaces/default/pods?fieldSelector=status.phase=Running&limit=100
  

  Si desea que LIST siga devolviendo todos los objetos de pod del ejemplo anterior, use el argumento continue con límite.

  /api/v1/namespaces/default/pods?fieldSelector=status.phase=Running&limit=100&continue=<continue_token>
  

  Si se usa kubectl, el --chunk-size argumento se puede aplicar directamente a las respuestas paginadas.

  kubectl get pods -n default --chunk-size=100
  

• Si tus controladores u operadores usan actualizaciones de arrendamiento para la elección de líderes, asegúrate de que sean resistentes a problemas de conectividad transitoria ajustando leaseDuration, renewDeadline, y retryPeriod que sean óptimas para tus cargas de trabajo. Para los controladores de Kubernetes que utilizan la elección de líder de client-go, use la siguiente fórmula:

  lease_duration > renew_deadline > retry_period
  

Daemonsets

• Hay una diferencia significativa entre un único controlador que enumera los objetos y un DaemonSet que se ejecuta en cada nodo haciendo lo mismo. Si varias instancias de la aplicación cliente enumeran periódicamente un gran número de objetos, la solución no se escalará bien en clústeres grandes.

• En clústeres con miles de nodos, crear un nuevo DaemonSet, actualizar un DaemonSet o aumentar el número de nodos puede dar lugar a una carga elevada colocada en el plano de control. Si los pods DaemonSet emiten solicitudes costosas al servidor de API en el inicio del pod, pueden provocar un uso elevado de recursos en el plano de control debido a un gran número de solicitudes simultáneas.

• Utiliza una estrategia RollingUpdate para desplegar nuevos pods de DaemonSet de forma gradual. Cuando se actualiza la plantilla DaemonSet, el controlador reemplaza los pods antiguos por los nuevos de forma controlada. Cuando la estrategia de actualización gradual no está configurada explícitamente, Kubernetes creará de forma predeterminada una rollingUpdate con maxUnavailable como 1, maxSurge como 0 y minReadySeconds como 0s. Consulte el ejemplo siguiente.

    minReadySeconds: 30
    updateStrategy:
      type: RollingUpdate
      rollingUpdate:
        maxSurge: 0
        maxUnavailable: 1
  

• La estrategia RollingUpdate solo se aplica a los pods de DaemonSet existentes. No limita el impacto de añadir nuevos nodos, lo que crea pods adicionales de DaemonSet, ni de desplegar DaemonSets completamente nuevos.

• Para evitar que los DaemonSets emitan solicitudes LIST simultáneas al servidor API durante el arranque tras el escalamiento de nodos o nuevos despliegues de DaemonSets, implementar jitter de arranque en el punto de entrada del contenedor y configurar políticas exponenciales adecuadas de retroceso y reintento para respuestas 5xx o 429 para evitar repetidos intentos de peticiones LIST grandes.

    spec:
      template:
        spec:
          containers:
          - name: my-daemonset-container
            image: <image>
            command: ["/bin/sh", "-c", "sleep $(( (RANDOM % 60) + 1 )); exec /path/to/your/app --args"]
  

Optimizaciones de "etcd"

• Mantenga el tamaño general de etcd pequeño y no use etcd como base de datos de uso general. AKS proporciona 8 GB de almacenamiento etcd de forma predeterminada, pero las bases de datos etcd más grandes aumentan el tiempo de desfragmentación, lo que puede provocar problemas de rendimiento de lectura y escritura. Las bases de datos etcd más grandes también pueden aumentar la probabilidad de problemas de confiabilidad del servidor de API y etcd si un cliente no optimizado captura un gran número de objetos de etcd con frecuencia. Si el tamaño de la base de datos etcd supera los 2 GB, considere la posibilidad de usar las técnicas de reducción de tamaño de objeto que se enumeran a continuación.
• Para reducir el tamaño de las especificaciones de pods, traslada las variables de entorno de las especificaciones de pod a los ConfigMaps.
• Divida secretos grandes o ConfigMaps en partes más pequeñas y manejables.
• Almacene secretos en Azure Key Vault en lugar de secretos de Kubernetes cuando sea posible para reducir el número de secretos almacenados en etcd.
• Limpieza de objetos sin usar
  • Elimina los trabajos obsoletos y los pods completados. Usen ttlSecondsAfterFinished en Jobs para que los objetos terminados se quiten automáticamente.
  • Asegúrese de que los controladores establezcan ownerReferences. Esto permite que la recolección de elementos no utilizados de Kubernetes quite objetos dependientes automáticamente cuando se elimina el recurso primario.
  • Limite el historial de CronJob estableciendo successfulJobsHistoryLimit y failedJobsHistoryLimit para mantener solo un pequeño número de registros de trabajo completados.
  • Reduzca el historial de lanzamientos de implementación. Los antiguos RéplicaSets también se almacenan como objetos API. El valor predeterminado es 10.
• Reduzca el historial de revisiones de Helm con el --history-max argumento . En clústeres grandes, manténgalo por debajo de 5.

Supervisión de métricas y registros del plano de control de AKS

La supervisión de las métricas del plano de control en clústeres de AKS de gran tamaño es fundamental para garantizar la estabilidad y el rendimiento de las cargas de trabajo de Kubernetes. Estas métricas proporcionan visibilidad sobre el estado y el comportamiento de los componentes críticos, como el servidor de API, etcd, el administrador de controladores y el programador. En entornos a gran escala, donde la contención de recursos y los grandes volúmenes de llamadas API son comunes, la supervisión de métricas del plano de control ayuda a identificar cuellos de botella, detectar anomalías y optimizar el uso de recursos. Al analizar estas métricas, los operadores pueden abordar de forma proactiva problemas como la latencia del servidor de API, objetos etcd altos o el consumo excesivo de recursos del plano de control, lo que garantiza una operación eficaz del clúster y minimiza el tiempo de inactividad.

Azure Monitor ofrece métricas y registros completos sobre el estado del plano de control a través de Azure Managed Prometheus y Configuración de diagnóstico.

• Para obtener una lista de alertas para configurar el estado del plano de control, consulte Procedimientos recomendados para la supervisión del plano de control de AKS.
• Para obtener la lista de agentes de usuario que tienen la latencia más alta, puede usar los registros del plano de control o la configuración de diagnóstico.

Métricas principales de la plataforma del plano de control

AKS expone las siguientes métricas de plataforma en Azure Monitor para supervisar el estado del servidor de API y etcd. Estas métricas están disponibles sin habilitar Managed Prometheus y se pueden ver directamente en el portal de Azure en Metrics para el clúster de AKS.

Métricas de API Server:

Métricas de Etcd:

Supervise constantemente apiserver_cpu_usage_percentage y apiserver_memory_usage_percentage para detectar la presión de recursos en el servidor API. Si etcd_database_usage_percentage está constantemente por encima de 50%, revise la sección Optimizaciones de Etcd para reducir el tamaño de la base de datos. Para obtener la lista completa de métricas disponibles, consulte Referencia de datos de supervisión de AKS.

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:

• AKS admite el escalado vertical de hasta 5000 nodos de forma predeterminada para todos los clústeres de nivel Estándar o LTS. AKS escala el plano de control del clúster en tiempo de ejecución en función del tamaño del clúster y el uso del recurso de servidor de API. Si no puede escalar hasta el límite admitido, habilite las métricas del plano de control (versión preliminar) con el servicio administrado Azure Monitor para Prometheus para supervisar el plano de control. Para ayudar a solucionar problemas de rendimiento o confiabilidad de escalado, consulte los siguientes recursos:

  • Guía de solución de problemas de AKS a gran escala
  • Solución de problemas del plano de control de Kubernetes

  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 un ticket de soporte.

• Azure Network Policy Manager (Azure npm) solo admite hasta 250 nodos.

• Algunas métricas del nodo de AKS, como el uso del disco del nodo, el uso de CPU/memoria del nodo y las métricas de entrada/salida de red, no serán accesibles en las Métricas de plataforma de Azure Monitor después de que el plano de control se escale verticalmente.

• No puede usar la característica Detener e iniciar con clústeres que tengan más de 100 nodos. Para obtener más información, consulte Detener e iniciar un clúster de AKS.

API de Azure y regulación de plataforma

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

Los límites de la API de Azure normalmente se definen en un nivel de combinación de región de suscripción. Por ejemplo, todos los clientes dentro de una suscripción de una región determinada comparten límites de API para una API de Azure determinada, como Virtual Machine Scale Sets PUT API. Cada clúster de AKS tiene varios clientes 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 Diagnóstico y solución de problemas de AKS para analizar errores, identificar la causa principal y obtener recomendaciones de resolución.
  • Aumentar el intervalo de examen del escalador automático de clústeres: si los informes de diagnóstico muestran que se ha detectado la limitación del escalador automático de clústeres, puede aumentar el intervalo de examen para reducir el número de llamadas a Virtual Machine Scale Sets desde Cluster Autoscaler.
  • Volver a configurar las aplicaciones de terceros para realizar menos llamadas: si filtra por agentes de usuario en el diagnóstico Visualización de la tasa de solicitudes y limitar los detalles y ver que una aplicación de terceros, como una aplicación de supervisión, realiza un gran número de solicitudes GET, puede cambiar la configuración de estas aplicaciones para reducir la frecuencia de las llamadas GET. Asegúrese de que los clientes de aplicaciones usen retroceso exponencial cuando llamen a las API de Azure.
• Split 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.

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.

• Si usa Azure Standard Load Balancer, use al menos 2 direcciones IP públicas salientes. Considere también los límites de las reglas de back-end del servicio LoadBalancer al planear clústeres de gran tamaño. Azure equilibradores de carga estándar admiten hasta 10 000 configuraciones de IP de back-end por IP de front-end. Cada tipo: el servicio LoadBalancer crea una regla de equilibrio de carga por puerto expuesto y asocia todos los nodos de clúster al grupo de back-end del equilibrador de carga. Por ejemplo, exponer 5 puertos para un único servicio alcanzará este límite en 2000 nodos.

  1 service * 5 ports * 2000 nodes = 10000 backend IP configurations
  

• Use Azure CNI Overlay para escalar hasta 200.000 pods y 5.000 nodos por clúster. Para obtener más información, consulte Configurar la red de superposición de CNI de Azure en AKS.

• Si la aplicación necesita comunicación directa de pod a pod entre clústeres, use Azure CNI con asignación de IP dinámica y escale hasta 50 000 pods por clúster con una IP enrutable por pod. Para obtener más información, consulte Configurar el networking 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 Administrador de directivas de red (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.

• Habilite LocalDNS en sus grupos de nodos para reducir la latencia de resolución DNS y descargar trabajo de los pods centralizados de CoreDNS. En clústeres grandes con elevados volúmenes de solicitudes DNS, la resolución DNS centralizada puede convertirse en un cuello de botella. LocalDNS implementa un proxy DNS como un servicio de systemd en cada nodo, resolviendo consultas localmente, eliminando la presión en la tala conntrack y actualizando las conexiones a TCP para evitar condiciones de carrera de conntrack. LocalDNS también admite el servicio de respuestas almacenadas en caché obsoletas cuando el DNS ascendente no está disponible, lo que mejora la resistencia de la carga de trabajo durante errores transitorios. Para más información, consulte Resolución DNS en AKS.

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. Este límite impide una actualización porque no hay capacidad de nodo disponible para realizar actualizaciones graduales dentro del límite máximo de propiedades de sobrecarga. 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 de 10 a 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.