Overview of node scaling in ACK clusters - Container Service for Kubernetes

Cuando su clúster de ACK no puede programar los pods pendientes, utilice el node scaling para agregar o quitar nodos automáticamente. ACK ofrece node auto scaling y node instant scaling. En comparación con node auto scaling, node instant scaling es más rápido y sencillo.

Antes de empezar

Lea este tema para comprender las soluciones de node scaling de ACK. Elija la que mejor se adapte a su carga de trabajo antes de habilitar el node scaling.

Familiarícese con el escalado manual, el autoescalado, el escalado horizontal y el escalado vertical en la documentación oficial de Kubernetes.

Cómo funciona el escalado de nodos

El escalado de nodos en Kubernetes difiere del modelo tradicional basado en umbrales de utilización de recursos. Es posible que deba considerar esta diferencia al migrar desde centros de datos u otros sistemas de orquestación hacia Kubernetes.

El modelo de escalado tradicional agrega nodos cuando la utilización de CPU o memoria supera un umbral. Sin embargo, este modelo presenta los siguientes problemas.

¿Cómo se determinan los umbrales de escalado?

Los nodos activos suelen tener una utilización de recursos mayor que el resto de los nodos.

Si el escalado se activa por la utilización promedio, la demanda de los nodos activos queda oculta por los nodos subutilizados. Esto impide un escalado horizontal oportuno.
Si el escalado se activa por la utilización máxima, generalmente se desperdician recursos en todo el clúster.

¿Cómo se reduce la carga después de agregar nodos?

En Kubernetes, los pods son las unidades de despliegue más pequeñas. Agregar nodos no redistribuye la carga de los pods existentes: la cantidad de pods y sus límites de recursos permanecen sin cambios, por lo que los nuevos nodos no reciben tráfico de los pods sobrecargados.

¿Cómo se activa y ejecuta el escalado de nodos?

El escalado basado en utilización puede expulsar pods que solicitan muchos recursos pero consumen pocos en realidad. Si existen muchos pods de este tipo, los recursos programables se agotan y algunos pods quedan sin posibilidad de programación.

ACK utiliza el node scaling (capa de recursos) y el workload scaling (capa de programación) para resolver estos problemas. El node scaling activa el escalado según la utilización de recursos de los pods.

¿Cómo se activan las actividades de escalado horizontal?

El modelo de escalado de nodos supervisa los pods que no se pueden programar. Cuando los pods no se programan por falta de recursos, simula la programación, selecciona un node pool compatible con autoescalado y agrega nodos al clúster.

Nota

La simulación abstrae cada node pool con autoescalado como un nodo virtual. Este nodo incluye la capacidad de CPU, memoria y GPU de los tipos de instancia configurados, además de las etiquetas y taints del node pool. El programador agrega este nodo virtual a la lista de recursos programables, calcula la cantidad de nodos necesarios y aprovisiona los nodos correspondientes.

¿Cómo se activan las actividades de reducción horizontal?

La reducción horizontal solo aplica a los nodos de los node pools con autoescalado; los nodos estáticos no se gestionan. Cuando la utilización de un nodo cae por debajo del umbral de reducción, el modelo simula la expulsión de pods para comprobar si el nodo se puede vaciar. Se omiten los pods que no pertenecen a DaemonSet en el namespace kube-system y los pods protegidos por PodDisruptionBudget. Una vez que todos los pods elegibles se expulsan a otros nodos, se elimina el nodo.

¿Cómo se selecciona un node pool cuando existen varios con la función de autoescalado habilitada?

Los múltiples node pools con autoescalado se tratan como nodos abstractos. El autoscaler los evalúa mediante la política de programación estándar y prioriza las reglas de afinidad, como node affinity.

Si ninguna regla de afinidad coincide, node auto scaling recurre al principio de menor desperdicio. Con este criterio, selecciona el node pool que deja menos recursos inactivos tras el escalado horizontal.

Nota

Cuando los node pools con autoescalado acelerados por GPU y por CPU cumplen las condiciones de escalado horizontal, se prioriza el pool acelerado por CPU.

De forma predeterminada, node instant scaling evalúa la disponibilidad y el costo de las instancias. Prioriza los tipos con capacidad suficiente y el precio más bajo.

¿Cómo puedo mejorar la tasa de éxito del autoescalado?

La tasa de éxito del autoescalado depende de los siguientes factores:

Si se cumplen las condiciones de programación.

Después de crear un node pool con autoescalado, confirme la política de programación de pods del node pool. Si no está seguro, configure nodeSelector con la etiqueta del node pool y ejecute una simulación de programación.
Si los recursos son suficientes.

Tras la simulación, el sistema selecciona un node pool con autoescalado y agrega nodos. Sin embargo, el inventario de tipos de instancia de ECS en la configuración del node pool afecta la tasa de éxito del escalado horizontal. Especifique varios tipos de instancia en distintas zonas para mejorar dicha tasa.

¿Cómo puedo acelerar el autoescalado?

Método 1: use el modo rápido. Un node pool con autoescalado entra en modo rápido después de completar un ciclo de escalado horizontal y uno de reducción horizontal. Consulte Enable node autoscaling.
Método 2: use una imagen personalizada basada en Alibaba Cloud Linux 3 para mejorar la eficiencia de entrega de recursos de IaaS en un 50 %. Consulte Optimize scaling with custom images.

Soluciones de escalado: node auto scaling y node instant scaling

El node scaling es una función a nivel de recursos que ajusta automáticamente la cantidad de nodos del clúster. Cuando la capacidad existente no basta para programar los pods, el autoscaler aprovisiona nodos adicionales.

ACK ofrece dos soluciones para el node scaling.

Introducción

Importante

Solo un componente de escalado puede ejecutarse en un clúster. Las dos soluciones no pueden coexistir. Para habilitar el node scaling, consulte Enable node autoscaling y Enable node instant scaling.
Las estadísticas de escalado de este tema son valores teóricos basados en imágenes personalizadas. Los resultados reales en su entorno pueden variar. Consulte Optimize scaling with custom images.
Ambas soluciones de escalado aplican a los nodos dentro de los node pools con autoescalado.

Solución	Componente	Descripción
Solución 1: node auto scaling	cluster-autoscaler	Comprueba el estado del clúster en un ciclo round-robin y escala los nodos cuando se cumplen las condiciones.
Solución 2: node instant scaling	ACK GOATScaler	Autoscaler de nodos basado en eventos que garantiza una entrega eficiente de recursos en clústeres grandes y escenarios de escalado horizontal consecutivo. Un clúster se considera grande si un node pool con la función de autoescalado contiene más de 100 nodos, o si más de 20 node pools del clúster tienen habilitada esta función. Velocidad de escalado: 45 segundos; tasa de éxito: 99 %; reducción de fragmentación de recursos: 30 %. Admite políticas de escalado personalizadas para mayor extensibilidad.

Comparación de soluciones

Para los node pools con autoescalado habilitado (sin modo rápido), la función de node instant scaling es compatible con la configuración existente del node pool y admite todos los tipos de pods. La siguiente tabla compara node instant scaling con node auto scaling.

Ventaja	Node auto scaling	Node instant scaling
Velocidad y eficiencia de escalado	60 segundos en modo estándar, 50 segundos en modo rápido.	Con el escalado basado en eventos y Alibaba Cloud ContainerOS, cada actividad de escalado toma entre 35 y 55 segundos.
	El autoescalado alcanza un cuello de botella de rendimiento en 1 minuto. La eficiencia fluctúa según la cantidad de node pools y los escenarios de escalado: superar los 100 node pools aumenta la duración a entre 100 y 150 segundos.	La duración del escalado se mantiene estable aunque aumente la cantidad de node pools o de pods. Por ello, resulta adecuado para escenarios de escalado rápido.
	Modo round-robin con actualizaciones del estado del clúster. Latencia mínima: 5 segundos.	Basado en eventos. Latencia: de 1 a 3 segundos.
Tasa de éxito del escalado de recursos	Debido a las fluctuaciones en el inventario de recursos de la nube y a la variabilidad de los tipos de instancia, la tasa de éxito de node auto scaling es de aproximadamente el 97 %.	Una política de selección automática de inventario filtra miles de tipos de instancia de Alibaba Cloud según condiciones y prioridades predefinidas. Selecciona automáticamente los tipos óptimos o alternativas de respaldo cuando los tipos especificados no están disponibles. Esto simplifica la operación y el mantenimiento, y eleva la tasa de éxito al 99 %.
	El escalado horizontal utiliza los tipos de instancia de la configuración del node pool. Cuando se especifican varios tipos, se prefiere el de menores especificaciones.	Puede especificar varios tipos de instancia para las actividades de escalado horizontal.
	El autoscaler reintenta periódicamente cuando falla el escalado de recursos.	El autoscaler puede generar alertas cuando los tipos de instancia especificados son insuficientes.
Uso y operación y mantenimiento	En comparación con node auto scaling, node instant scaling es más fácil de usar en los siguientes aspectos: Mantenimiento de la configuración del node pool: node instant scaling selecciona automáticamente instancias de distintos tipos y zonas para alojar los pods pendientes. Con node auto scaling, debe mantener manualmente las configuraciones del node pool y actualizarlas cada vez que cambie la configuración de los pods. Operación y mantenimiento de nodos: las excepciones de escalado se exponen mediante eventos de pod, lo que permite a los desarrolladores centrarse en la gestión del ciclo de vida de los pods. Extensión de funciones: ambas soluciones funcionan con Descheduler para preparar recursos elásticos. Node instant scaling no genera intrusiones y admite acciones personalizadas en las políticas de aprovisionamiento de recursos y en la gestión del ciclo de vida de los nodos para desarrollo secundario.
Política de programación	Además de las funciones de programación de node auto scaling, node instant scaling también admite: Topología: cumple los requisitos de alta disponibilidad entre zonas. Pod Disruption Budgets: limita las expulsiones voluntarias simultáneas de pods en aplicaciones multipod, lo que garantiza la estabilidad durante las interrupciones planificadas.
Política de programación	Node instant scaling reduce la tasa de fragmentación de recursos en un 30 % mediante las políticas Bin Packing y PreBind (función personalizada).

Límites de node instant scaling

A continuación se describen los límites de node instant scaling. Revíselos antes de habilitar node instant scaling.

Node instant scaling no admite el modo rápido.
Un node pool puede contener hasta 180 nodos por lote de escalado horizontal.
No se puede deshabilitar la reducción horizontal para un clúster específico.

Nota
Para deshabilitar la reducción horizontal de un nodo específico, consulte How to prevent a node from being scaled in by node instant scaling?.
La solución de node instant scaling no comprueba el inventario de preemptible instances. Si el Billing Method del node pool está configurado como preemptible instances y Use Pay-as-you-go Instances When Spot Instances Are Insufficient está habilitado, podrían agregarse instancias pay-as-you-go incluso si hay preemptible instances suficientes.

Seleccione una solución de escalado de nodos

Consulte Solution comparison y Limits of node instant scaling. Elija node auto scaling si su carga de trabajo tiene menores exigencias de velocidad de escalado y certeza de entrega, y los límites de node instant scaling resultan inaceptables.

Se recomienda utilizar node instant scaling si su carga de trabajo presenta alguno de los siguientes requisitos:

Los clústeres grandes degradan gravemente la eficiencia de node auto scaling. Elija node instant scaling, ya que el tamaño del clúster apenas afecta su eficiencia de escalado. Un clúster se considera grande si un node pool con la función de autoescalado contiene más de 100 nodos, o si más de 20 node pools del clúster tienen habilitada esta función.
Se requiere mayor velocidad de escalado. En modo estándar, node auto scaling tarda 60 segundos, mientras que node instant scaling tarda 45 segundos.
Los lotes consecutivos de escalado horizontal son frecuentes. En escenarios de escalado consecutivo, el rendimiento de node auto scaling se degrada y fluctúa, mientras que node instant scaling mantiene un tiempo de escalado constante de aproximadamente 45 segundos.

Notas de uso

Cuotas y límites

Una tabla de rutas de VPC admite hasta 200 entradas de ruta personalizadas. Para aumentar este límite, envíe una solicitud en la consola de Quota Center. Para conocer otras cuotas de recursos, consulte Underlying Cloud Product Quotas.
Configure con cuidado la cantidad máxima de nodos en un node pool con autoescalado. Asegúrese de que los recursos y las cuotas dependientes sean suficientes, como los bloques CIDR de VPC y los vSwitches; de lo contrario, las actividades de escalado horizontal podrían fallar. Para consultar los límites de los node pools, vea Enable node autoscaling. Para la planificación de red, vea ACK managed cluster network planning.
El node scaling no admite nodos de suscripción. No establezca el método de facturación como suscripción al crear un node pool con autoescalado. En los node pools existentes, asegúrese de que no haya nodos de suscripción antes de habilitar el autoescalado.
La función de node scaling no es compatible con SideCar Containers. Despliegue las cargas de trabajo de Sidecar Container en node pools con el autoescalado deshabilitado.

Mantenimiento de recursos dependientes

Si hay direcciones IP elásticas (EIP) asociadas a nodos de ECS agregados por el escalado de nodos, no elimine estos nodos directamente desde la consola de ECS. De hacerlo, las EIP no se liberarán automáticamente.

Referencias

Consulte Enable node autoscaling y Enable node instant scaling.

Consulte Node auto scaling FAQ.

Expanda para ver el índice de preguntas frecuentes sobre node auto scaling

Categoría	Subcategoría	Enlaces
Comportamiento de node auto scaling	Known limitations
	Scale-out behavior	Scheduling policies Resource types Scale-out failures Multiple instance types Node pool selection Custom resources Enabling Auto Scaling
	Scale-in behavior	Scale-in failures DaemonSet eviction Pods that prevent node removal
	Extension support	CustomResourceDefinitions (CRDs)
Comportamiento de escalado personalizado	Pod-level control	Delay scale-out
Comportamiento de escalado personalizado	Node-level control	Prevent scale-in
Gestión de complementos		Upgrade cluster-autoscaler Automatic updates Role authorization

Expanda para ver el índice de preguntas frecuentes sobre node instant scaling

Categoría	Subcategoría	Enlace
Node instant scaling behavior	Known limitations
	Scale-out behavior	What resource types does node instant scaling use for scaling simulations? Does node instant scaling select an appropriate instance type from a node pool based on pod resource requests? How does node instant scaling select an instance type from a node pool with multiple types? How do I monitor the inventory of instance types in a node pool when using node instant scaling? How can I optimize the node pool configuration to avoid scale-out failures from insufficient inventory? Why does node instant scaling fail to scale out nodes? How do I configure custom resources for a node pool with node instant scaling enabled?
	Scale-in behavior	Why does node instant scaling fail to scale in nodes? What types of pods can prevent node instant scaling from removing a node?
Comportamiento de escalado personalizado	Controlling scaling with pods	How can I control node scale-in by using pods?
Comportamiento de escalado personalizado	Controlling scaling with nodes	How do I specify which node to delete during a scale-in? How do I prevent a specific node from being scaled in? Can node instant scaling be configured to scale in only empty nodes?
Node instant scaling add-on		Does the node instant scaling add-on update automatically? Why does node scaling fail on my ACK managed cluster after I granted the required permissions?