Introducción al escalado automático de clústeres en Azure Kubernetes Service (AKS)

Para satisfacer las necesidades de la aplicación en Azure Kubernetes Service (AKS), es posible que deba ajustar el número de nodos que ejecutan las cargas de trabajo. El componente de escalado automático de clústeres supervisa los pods del clúster que no pueden programarse debido a las restricciones de los recursos. Cuando la escalabilidad automática de clústeres detecta problemas, escala verticalmente el número de nodos del grupo de nodos para satisfacer la demanda de la aplicación. Además, comprueba periódicamente los nodos por si faltan pods en ejecución y reduce verticalmente la cantidad de nodos según sea necesario.

Este artículo le ayuda a comprender cómo funciona el escalador automático de clústeres en AKS. También proporciona instrucciones, procedimientos recomendados y consideraciones al configurar el escalador automático del clúster para las cargas de trabajo de AKS. Si desea habilitar, deshabilitar o actualizar el escalador automático del clúster para las cargas de trabajo de AKS, consulte Uso del escalador automático de clústeres en AKS.

Acerca del escalado automático de clústeres

Para adaptarse a las cambiantes necesidades de las aplicaciones, como en las jornadas laborales y las noches o los fines de semana, los clústeres a menudo necesitan una forma de escalado automático. Los clústeres de AKS se pueden escalar de las siguientes maneras:

• El escalado automático de clústeres comprueba, de manera periódica, pods que no puedan programarse en nodos debido a las restricciones de los recursos. Luego, el clúster aumenta automáticamente la cantidad de nodos. El escalado manual está deshabilitado cuando se usa el escalado automático de clústeres. Para obtener más información, consulte ¿Cómo funciona el escalado vertical?.
• El escalado automático horizontal de pods usa el servidor de métricas en un clúster de Kubernetes para supervisar la demanda de recursos de los pods. Si una aplicación necesita más recursos, el número de pods aumenta automáticamente para satisfacer la demanda.
• El escalado automático vertical de pods establece automáticamente las solicitudes de recursos y los límites de los contenedores por carga de trabajo en función del uso pasado para asegurarse de que los pods están programados en los nodos que tienen los recursos de CPU y memoria necesarios.

Es habitual habilitar el escalado automático de clústeres para los nodos y el escalado automático vertical u horizontal de pods para pods. Al habilitar el escalador automático del clúster, aplica las reglas de escalado especificadas cuando el tamaño del grupo de nodos es inferior al mínimo o mayor que el máximo. A continuación, el escalador automático del clúster espera a activarse hasta que se necesita un nuevo nodo en el grupo de nodos o hasta que el nodo se puede eliminar de forma segura del grupo de nodos actual. Para obtener más información, consulte ¿Cómo funciona la reducción vertical?

Procedimientos recomendados y consideraciones

• Al implementar zonas de disponibilidad con el escalador automático del clúster, se recomienda usar un único grupo de nodos para cada zona. Puede establecer el parámetro --balance-similar-node-groups en True para mantener una distribución equilibrada de nodos entre zonas para las cargas de trabajo durante las operaciones de escalado vertical. Cuando este enfoque no se implementa, las operaciones de reducción vertical pueden interrumpir el equilibrio de nodos entre zonas.
• En el caso de los clústeres con más de 400 nodos, se recomienda usar Azure CNI o la superposición de Azure CNI.
• Para ejecutar de forma eficaz las cargas de trabajo simultáneamente en grupos de nodos fijos y puntuales, considere la posibilidad de usar los ampliadores de prioridad. Este enfoque permite programar pods en función de la prioridad del grupo de nodos.
• Tenga cuidado al asignar solicitudes de CPU o memoria en pods. El escalador automático del clúster se escala verticalmente en función de los pods pendientes en lugar de la presión de CPU/memoria en los nodos.
• En el caso de los clústeres que hospedan simultáneamente cargas de trabajo de ejecución prolongada, como las aplicaciones web y las cargas de trabajo de corta o ráfaga, se recomienda separarlas en grupos de nodos distintos con Reglas de afinidad/Ampliadores o usar PriorityClass para ayudar a evitar las operaciones innecesarias de purga o reducción vertical de nodos.
• En un grupo de nodos habilitado para el escalado automático, reduzca verticalmente los nodos mediante la eliminación de cargas de trabajo, en lugar de reducir manualmente el número de nodos. Esto puede ser problemático si el grupo de nodos ya está en capacidad máxima o si hay cargas de trabajo activas que se ejecutan en los nodos, lo que puede provocar un comportamiento inesperado por el escalador automático del clúster
• Los nodos no se escalan verticalmente si los pods tienen un valor PriorityClass por debajo de -10. Priority -10 está reservado para pods de sobreaprovisionamiento. Para obtener más información, consulte Uso del escalador automático de clústeres con prioridad de pod y adelantamiento.
• No combine otros mecanismos de escalado automático de nodos, como los escaladores automáticos del conjunto de escalado de máquinas virtuales, con el escalador automático del clúster.
• El escalado automático de clústeres no se puede reducir verticalmente si no se pueden mover los pods, tal como se detalla en las situaciones siguientes:
  • Un pod creado directamente y no respaldado por un objeto de controlador, como una implementación o un conjunto de réplicas.
  • Un presupuesto de interrupción de pods (PDB) es demasiado restrictivo y no permite que la cantidad de pods caiga por debajo de cierto umbral.
  • Un pod usa selectores de nodo o antiafinidad que no se pueden respetar si se programan en un nodo diferente. Para obtener más información, consulte ¿Qué tipos de pods pueden evitar que el escalador automático de clústeres elimine un nodo?

Importante

No realice cambios en nodos individuales dentro de los grupos de nodos de escalado automático. Todos los nodos del mismo grupo de nodos deben tener capacidad uniforme, etiquetas, intolerancias y pods del sistema que se ejecutan en ellos.

Perfil del escalador automático de clústeres

El perfil del escalador automático del clúster es un conjunto de parámetros que controlan el comportamiento del escalador automático del clúster. Puede configurar el perfil del escalador automático del clúster al crear un clúster o actualizar un clúster existente.

Optimización del perfil del escalador automático del clúster

Debe ajustar la configuración del perfil del escalador automático del clúster según los escenarios de carga de trabajo específicos, a la vez que tiene en cuenta las contrapartidas entre el rendimiento y el costo. En esta sección se proporcionan ejemplos que muestran esas contrapartidas.

Es importante tener en cuenta que la configuración del perfil del escalador automático del clúster es en todo el clúster y se aplica a todos los grupos de nodos habilitados para escalabilidad automática. Las acciones de escalado que se realizan en un grupo de nodos pueden afectar al comportamiento de escalado automático de otros grupos de nodos, lo que puede provocar resultados inesperados. Asegúrese de aplicar configuraciones de perfil coherentes y sincronizadas en todos los grupos de nodos pertinentes para asegurarse de obtener los resultados deseados.

Ejemplo 1: Optimización del rendimiento

En el caso de los clústeres que controlan cargas de trabajo sustanciales y ampliables con un enfoque principal en el rendimiento, se recomienda aumentar scan-interval y reducir scale-down-utilization-threshold. Esta configuración ayuda a procesar por lotes varias operaciones de escalado en una sola llamada, optimizando el tiempo de escalado y el uso de cuotas de lectura y escritura de proceso. También ayuda a mitigar el riesgo de reducir verticalmente rápidamente las operaciones en nodos infrautilizados, lo que mejora la eficacia de la programación de pods. Aumente también ok-total-unready-count y max-total-unready-percentage.

En el caso de los clústeres con pods daemonset, se recomienda establecer ignore-daemonset-utilization en true, que omite eficazmente el uso del nodo por los pods daemonset y minimiza las operaciones de reducción vertical innecesarias. Consulte perfil para cargas de trabajo de ráfaga

Ejemplo 2: Optimización del costo

Si desea una perfil optimizado para costos, se recomienda establecer las siguientes configuraciones de parámetros:

• Reduzca scale-down-unneeded-time, que es la cantidad de tiempo que un nodo debe ser innecesario antes de que sea apto para reducirlo verticalmente.
• Reduzca scale-down-delay-after-add, que es la cantidad de tiempo que se va a esperar después de agregar un nodo antes de considerarlo para reducirlo verticalmente.
• Aumente scale-down-utilization-threshold, que es el umbral de uso para quitar nodos.
• Aumente max-empty-bulk-delete, que es el número máximo de nodos que se pueden eliminar en una sola llamada.
• Establezca skip-nodes-with-local-storage en false.
• Aumente ok-total-unready-count y max-total-unready-percentage

Problemas comunes y recomendaciones de mitigación

Vea los errores de escalado y de escalado vertical no desencadenados a través de la CLI o el Portal.

No se desencadenan las operaciones de escalado vertical

Causas comunes	Recomendaciones de mitigación
Conflictos de afinidad de nodo PersistentVolume, que pueden surgir al usar el escalador automático del clúster con varias zonas de disponibilidad o cuando la zona de un pod o volumen persistente difiere de la zona del nodo.	Use un grupo de nodos por zona de disponibilidad y habilite --balance-similar-node-groups. También puede establecer el campo volumeBindingMode en WaitForFirstConsumer en la especificación del pod para evitar que el volumen se enlace a un nodo hasta que se cree un pod mediante el volumen.
Conflictos de afinidad entre intolerancias y tolerancias/nodo	Evalúe las intolerancias asignadas a los nodos y revise las tolerancias definidas en los pods. Si es necesario, realice ajustes en las intolerancias y tolerancias para asegurarse de que los pods se pueden programar de forma eficaz en los nodos.

Errores de operación de escalado vertical

Causas comunes	Recomendaciones de mitigación
Agotamiento de direcciones IP en la subred	Agregue otra subred en la misma red virtual y agregue otro grupo de nodos a la nueva subred.
Agotamiento de cuotas principales	Se ha agotado la cuota de núcleos aprobada. Solicite un aumento de cuota. El escalador automático del clúster entra en un estado de retroceso exponencial dentro del grupo de nodos específico cuando experimenta varios intentos de escalado vertical erróneos.
Tamaño máximo del grupo de nodos	Aumente el número máximo de nodos del grupo de nodos o cree un nuevo grupo de nodos.
Solicitudes o llamadas que superan el límite de velocidad	Consulte Errores 429: Demasiadas solicitudes.

Errores de operación de reducción vertical

Causas comunes	Recomendaciones de mitigación
Pod que impide la purga de nodos o no se puede expulsar el pod	• Vea qué tipos de pods pueden evitar la reducción vertical. • En el caso de los pods que usan almacenamiento local, como hostPath y emptyDir, establezca la marca de perfil del escalador automático del clúster skip-nodes-with-local-storage en false. • En la especificación del pod, establezca la anotación cluster-autoscaler.kubernetes.io/safe-to-evict en true. • Compruebe su PDB, ya que podría ser restrictivo.
Tamaño mínimo del grupo de nodos	Reduzca el tamaño mínimo del grupo de nodos.
Solicitudes o llamadas que superan el límite de velocidad	Consulte Errores 429: Demasiadas solicitudes.
Operaciones de escritura bloqueadas	No realice ningún cambio en el grupo de recursos de AKS totalmente administrado (consulte Directivas de soporte técnico de AKS). Quite o restablezca los bloqueos de recursos que haya aplicado anteriormente al grupo de recursos.

Otros problemas

Causas comunes	Recomendaciones de mitigación
PriorityConfigMapNotMatchedGroup	Asegúrese de agregar todos los grupos de nodos que requieren el escalado automático al archivo de configuración del ampliador.

Grupo de nodos en retroceso

El grupo de nodos en el retroceso se introdujo en la versión 0.6.2 y hace que el escalador automático del clúster se desactive del escalado de un grupo de nodos después de un error.

Dependiendo de cuánto tiempo se hayan producido errores en las operaciones de escalado, puede tardar hasta 30 minutos antes de realizar otro intento. Para restablecer el estado de retroceso del grupo de nodos, deshabilite y vuelva a habilitar el escalado automático.