El Helm chart del Cluster Autoscaler es una forma de instalar el Cluster Autoscaler de Kubernetes, que agrega nodos de trabajo cuando tus pods no se pueden programar y los elimina cuando ya no se necesitan. Puedes instalarlo con un solo comando helm install, pero hay dos cosas que influyen mucho en que funcione bien: la configuración que definas y los resource requests de tus pods.
Esta guía cubre ambos aspectos, junto con la forma en que el Cluster Autoscaler toma sus decisiones de escalado. Aprenderás cómo decide cuándo agregar o quitar nodos, qué chart instalar, cómo instalarlo y verificarlo en EKS, AKS y GKE, qué valores de Helm controlan su comportamiento, cómo ajustarlo para clústeres grandes y cómo resolver los problemas de escalado más comunes.
¿Qué es el Helm chart del Cluster Autoscaler?
El Cluster Autoscaler ajusta la cantidad de nodos de tu clúster según lo que necesitan tus pods. Agrega nodos cuando los pods no se pueden programar por falta de capacidad y elimina los que ya no se necesitan cuando sus pods pueden ejecutarse en otros nodos.
Lo hace modificando el tamaño de los grupos de nodos de tu proveedor de nube, como los Auto Scaling Groups (ASG) de AWS, los Virtual Machine Scale Sets (VMSS) de Azure o los Managed Instance Groups (MIG) de Google Compute Engine.
El Helm chart empaqueta el Deployment del Cluster Autoscaler, sus permisos RBAC y su configuración en una sola instalación. Esto facilita instalarlo, administrarlo y actualizarlo. El Cluster Autoscaler escala nodos, mientras que el HPA y KEDA escalan pods.
¿Cómo decide el Cluster Autoscaler cuándo agregar o quitar nodos?
Estos son los factores principales que el Cluster Autoscaler usa para decidir cuándo agregar o quitar nodos:
Los pods en Pending activan el scale-up
Cada 10 segundos, según el parámetro --scan-interval, el autoscaler busca pods atascados en estado Pending porque no caben en los nodos existentes. Comprueba si un nuevo nodo de cada grupo de nodos podría ejecutar esos pods, elige un grupo adecuado y aumenta su tamaño deseado para que el proveedor de nube agregue un nodo. Si no hay pods sin programar, el Cluster Autoscaler no agrega nodos.
La baja utilización y un tiempo de espera activan el scale-down
Cuando no hace falta agregar nodos, el autoscaler verifica si alguno se puede eliminar. Un nodo se vuelve candidato cuando los requests de CPU y memoria de sus pods están por debajo del --scale-down-utilization-threshold, cuyo valor predeterminado es 0.5 (50%). El nodo debe mantenerse subutilizado durante el tiempo definido en --scale-down-unneeded-time, que por defecto es de 10 minutos. El autoscaler también espera después de un scale-up antes de eliminar nodos, según --scale-down-delay-after-add, que también tiene un valor predeterminado de 10 minutos. Por eso el scale-down suele ser más lento que el scale-up.
Los grupos de nodos y los expanders deciden de dónde salen los nuevos nodos
El autoscaler necesita saber qué grupos de nodos debe administrar. Puede descubrirlos automáticamente o usar una lista explícita. Si varios grupos de nodos pueden ejecutar los pods pendientes, el parámetro --expander decide qué grupo debe crecer. Las opciones son random, most-pods, least-waste, price y priority.
Los resource requests determinan las decisiones de escalado
Este es uno de los puntos más importantes que debes entender. El Cluster Autoscaler usa los resource requests de los pods, no el uso real de CPU y memoria. Agrega nodos cuando los recursos solicitados no caben y considera que un nodo está subutilizado según los requests de sus pods. Por ejemplo, si los pods solicitan el 80% de la capacidad de un nodo pero solo usan el 20%, el autoscaler sigue viendo el nodo al 80% de uso y puede no eliminarlo. Por eso, unos requests sobredimensionados pueden mantener nodos de más en ejecución y aumentar tus costos de nube.
¿Qué chart del Cluster Autoscaler instalar?
Para instalaciones nuevas, usa el chart oficial autoscaler/cluster-autoscaler del repositorio kubernetes/autoscaler.
Es posible que todavía encuentres los charts antiguos stable/aws-cluster-autoscaler y stable/cluster-autoscaler. Están obsoletos y ya no reciben mantenimiento, así que evítalos.
Helm no es la única opción. Los servicios gestionados de Kubernetes pueden ofrecer el Cluster Autoscaler a través de sus propias herramientas, y algunos equipos lo administran con Terraform. La opción correcta depende de cómo administres tu clúster.
Requisitos previos y compatibilidad de versiones
Antes de instalar, estas son las dos cosas que debes verificar:
Alinea la versión del Cluster Autoscaler con tu versión de Kubernetes
Debes usar Cluster Autoscaler v1.30.x con Kubernetes 1.30, v1.31.x con Kubernetes 1.31, y así sucesivamente. El autoscaler usa su propia lógica de programación para comprobar si un pod cabe en un nodo nuevo, así que una versión que no coincida puede llevar a decisiones de escalado incorrectas. Revisa la etiqueta de imagen predeterminada del chart y fíjala en la versión correcta si es necesario.
Dale al Cluster Autoscaler acceso a tu proveedor de nube
El autoscaler necesita permisos para cambiar el tamaño de tus grupos de nodos y saber qué grupos administra. En AWS, esto implica contar con los permisos de IAM necesarios y Auto Scaling Groups (ASG) correctamente etiquetados. En Azure y GCE, necesitas los permisos equivalentes y VM Scale Sets (VMSS) o Managed Instance Groups (MIG) configurados correctamente.
Asegúrate de que estos permisos y la configuración de los grupos de nodos sean correctos antes de instalar. El chart puede iniciarse sin problemas aunque estén mal, pero el Cluster Autoscaler no podrá escalar los nodos.
Instalar el chart en un clúster en ejecución
Primero, agrega el repositorio oficial:
helm repo add autoscaler https://kubernetes.github.io/autoscalerhelm repo updateAntes de instalar, debes indicarle al Cluster Autoscaler qué grupos de nodos debe administrar. La configuración depende de tu proveedor de nube.
En AKS y GKE gestionados, el autoescalado de nodos ya está disponible como función integrada que se habilita a nivel de node pool, así que normalmente no necesitas instalar este Helm chart allí. El chart es útil sobre todo para Amazon EKS y clústeres autogestionados.
Instalación en EKS
En EKS, el auto-discovery es el enfoque más simple. Primero, etiqueta cada Auto Scaling Group (ASG) que quieras que el Cluster Autoscaler administre con k8s.io/cluster-autoscaler/enabled y k8s.io/cluster-autoscaler/<your-cluster-name>.
Luego instala el chart:
helm install cluster-autoscaler autoscaler/cluster-autoscaler \ --namespace kube-system \ --set cloudProvider=aws \ --set autoDiscovery.clusterName=<your-cluster-name> \ --set awsRegion=<your-region>Instalación en Azure o GCE autogestionados
Para un clúster autogestionado de Azure o GCE, configura cloudProvider=azure o cloudProvider=gce y proporciona los detalles de los scale sets o instance groups que quieras que administre el Cluster Autoscaler.
Los parámetros exactos varían según el proveedor de nube, pero la configuración básica es la misma: especifica el proveedor de nube, los grupos de nodos y las credenciales o la identidad que debe usar el Cluster Autoscaler.
Después de instalar, verifica que el pod del Cluster Autoscaler esté en ejecución:
kubectl get pods -n kube-system -l app.kubernetes.io/instance=cluster-autoscalerLuego revisa su estado:
kubectl describe configmap cluster-autoscaler-status -n kube-systemEl ConfigMap de estado muestra el tamaño de cada grupo de nodos y la actividad reciente de scale-up o scale-down. Esto te da una vista rápida de si el Cluster Autoscaler está funcionando y tomando decisiones de escalado.
Valores de Helm que cambian el comportamiento del autoscaler
Estos son los valores importantes:
cloudProvider y autoDiscovery
Le indican al Cluster Autoscaler qué proveedor de nube usas y cómo encontrar los grupos de nodos que debe administrar. Si están mal configurados, el autoscaler no tiene grupos de nodos que escalar.
Anotaciones de la service account para el acceso a la nube
Puedes darle al Cluster Autoscaler sus propios permisos de nube a través de su service account, en lugar de otorgar permisos amplios a todos los nodos. En EKS, esto se suele hacer con IAM Roles for Service Accounts (IRSA). En Azure y GCE, se puede usar Workload Identity. Las anotaciones de la service account se configuran con rbac.serviceAccount.annotations.
extraArgs para el comportamiento de escalado
Con extraArgs defines opciones del Cluster Autoscaler como scan-interval, scale-down-utilization-threshold, scale-down-unneeded-time y expander. También puedes usar expendable-pods-priority-cutoff para definir la prioridad por debajo de la cual los pods pueden tratarse como prescindibles. Estos parámetros controlan con qué frecuencia el autoscaler revisa el clúster y cómo elige los nodos que agrega o elimina.
Cantidad de réplicas, leader election y recursos
Para alta disponibilidad, puedes ejecutar más de una réplica. El Cluster Autoscaler usa leader election, así que solo una réplica está activa a la vez mientras las demás quedan listas para tomar el relevo. Define también requests y límites de CPU y memoria para el autoscaler. Los clústeres grandes pueden necesitar más memoria, porque el autoscaler mantiene el estado del clúster en memoria.
Puedes definir estos valores en un archivo values.yaml e instalar el chart con -f:
cloudProvider: awsautoDiscovery: clusterName: my-clusterawsRegion: us-east-1replicaCount: 2extraArgs: scan-interval: 10s scale-down-utilization-threshold: "0.5" expander: least-waste balance-similar-node-groups: "true"resources: requests: cpu: 100m memory: 300Mi limits: cpu: 200m memory: 500MiAjustar el chart para clústeres grandes o multi-tenant
Los clústeres grandes requieren ajustes adicionales, porque el Cluster Autoscaler tiene más pods, nodos y grupos de nodos que revisar en cada escaneo. Algunos parámetros y patrones ayudan a mantenerlo en buen estado a medida que el clúster crece:
Reduce la cantidad de grupos de nodos
Cuantos más grupos de nodos administre el autoscaler, más trabajo hace en cada escaneo. Siempre que sea posible, mantén un número menor de grupos de nodos y usa etiquetas de auto-discovery para incluir solo los grupos que necesitan autoescalado.
Usa sharding en clústeres muy grandes
Puedes ejecutar varias instancias del Cluster Autoscaler, cada una administrando un conjunto distinto de grupos de nodos. Así se reparte el trabajo entre varias instancias del autoscaler. La contrapartida es que estas instancias no se coordinan entre sí, por lo que dos de ellas pueden responder al mismo pod pendiente y agregar temporalmente más nodos de los necesarios. Esos nodos extra se pueden eliminar más tarde durante el scale-down.
Usa nodos spot con el expander priority
Puedes combinar grupos de nodos spot con el expander priority en clústeres enfocados en el costo. Esto permite que el autoscaler prefiera la capacidad spot de menor costo y recurra a nodos on-demand cuando sea necesario.
Usa overprovisioning para escalar más rápido
El overprovisioning usa pods de relleno de baja prioridad para reservar capacidad extra en el clúster. Cuando llegan los workloads reales, estos pods de relleno se eliminan para dejarles espacio mientras el autoscaler agrega nodos nuevos.
Escala grupos de nodos desde cero
Un grupo de nodos puede reducirse a cero cuando no se está usando. Esto es especialmente útil para grupos de nodos con GPU, que son costosos. En EKS, asegúrate de que el grupo de nodos tenga las labels y taints necesarios en sus etiquetas de autoscaler, para que el Cluster Autoscaler sepa qué pueden ofrecer los nodos incluso cuando el grupo tiene cero nodos.
Diagnosticar una instalación que no escala
Cuando el Cluster Autoscaler no escala como se espera, el ConfigMap de estado y los logs del pod son el mejor punto de partida. Estos son los casos más comunes:
Los pods quedan en Pending y no se agregan nodos
Empieza con kubectl describe pod <pod-name> y revisa los eventos del pod. Luego revisa los logs del Cluster Autoscaler. Las causas comunes incluyen que el grupo de nodos ya esté en su tamaño máximo, que ningún grupo de nodos tenga capacidad suficiente para los resource requests del pod, o que el node selector o la afinidad del pod no coincidan con ningún grupo de nodos disponible. La falta de permisos de nube o de etiquetas en los grupos de nodos también puede impedir que el autoscaler encuentre o modifique el grupo de nodos.
Los nodos quedan subutilizados y no se eliminan
El Cluster Autoscaler omite algunos nodos de forma predeterminada. Por ejemplo, omite los nodos que ejecutan pods de kube-system cuando --skip-nodes-with-system-pods está habilitado, y los nodos con pods que usan almacenamiento local cuando --skip-nodes-with-local-storage está habilitado. También espera durante el retraso de scale-down. Más importante aún: recuerda que el Cluster Autoscaler usa los resource requests, no el uso real. Si los requests mantienen un nodo por encima del umbral de utilización, el nodo no se convertirá en candidato a eliminación aunque el uso real de CPU y memoria sea bajo.
Las anotaciones y los PodDisruptionBudgets bloquean la eliminación de nodos
El Cluster Autoscaler no eliminará un nodo si al hacerlo se viola un PodDisruptionBudget (PDB). También omite los pods con cluster-autoscaler.kubernetes.io/safe-to-evict: "false" y los nodos con la anotación scale-down-disabled. Estos ajustes protegen a los workloads de desalojos no deseados, pero una configuración antigua o innecesaria puede mantener un nodo en ejecución más tiempo del esperado. Revisa kubectl describe configmap cluster-autoscaler-status -n kube-system para ver qué nodos no se pueden eliminar y por qué.
Herramientas que complementan al Cluster Autoscaler
El Cluster Autoscaler administra la cantidad de nodos, pero las siguientes herramientas pueden ayudarte con el dimensionamiento de pods y el aprovisionamiento de nodos.
PerfectScale
El Cluster Autoscaler toma sus decisiones de escalado a partir de los resource requests de los pods, no del uso real de CPU y memoria. Si los requests son demasiado altos, puede agregar nodos que no necesitas y mantener nodos que de otro modo se podrían eliminar. PerfectScale monitorea el uso real de los workloads y propone recomendaciones automatizadas de right-sizing para acercar los requests de CPU y memoria al uso real. Esto ayuda al Cluster Autoscaler a tomar mejores decisiones de escalado. Puedes probarlo o agendar una sesión técnica.
Vertical Pod Autoscaler (VPA) y Goldilocks
El VPA ajusta los resource requests de los pods según el uso observado. Goldilocks ofrece un dashboard para ver las recomendaciones del VPA. Ambos ayudan a mantener los resource requests más cerca del uso real, lo que le da al Cluster Autoscaler mejor información para sus decisiones de escalado.
Karpenter
Karpenter adopta un enfoque distinto para el escalado de nodos. En lugar de redimensionar grupos de nodos fijos, puede aprovisionar nodos según los requisitos de los pods pendientes.
Buenas prácticas para ejecutar el Cluster Autoscaler en producción
Estas son las prácticas que ayudan a que el autoescalado de nodos sea eficiente y seguro:
1. Aplica right-sizing a los requests de los pods antes de ajustar el autoscaler
El Cluster Autoscaler toma sus decisiones según los resource requests de los pods, así que tener requests precisos importa más que cambiar la configuración del autoscaler. Primero hay que corregir los resource requests y luego ajustar los temporizadores y los expanders.
2. Mantén los grupos de nodos similares en CPU, memoria y zona de disponibilidad
Se espera que los nodos de un mismo grupo sean similares. Tipos de instancia o zonas de disponibilidad distintos pueden hacer menos precisa la simulación de programación del autoscaler. Los grupos de nodos similares se pueden balancear con balance-similar-node-groups.
3. Define PodDisruptionBudgets para los workloads que no deben interrumpirse
Un PodDisruptionBudget (PDB) define cuántos pods pueden no estar disponibles al mismo tiempo. Esto ayuda al Cluster Autoscaler a eliminar nodos manteniendo suficientes réplicas disponibles para el workload.
4. Fija la versión del chart y prueba las actualizaciones
La versión del Cluster Autoscaler debe coincidir con tu versión de Kubernetes. Por eso, una actualización de Kubernetes debe probarse con la versión correspondiente del autoscaler antes de que el cambio llegue a producción.
5. Exporta las métricas del autoscaler a Prometheus y crea alertas para scale-ups fallidos
El Cluster Autoscaler expone métricas de Prometheus que muestran la actividad de escalado y las fallas. Las alertas por scale-ups fallidos y pods que permanecen en Pending ayudan a detectar problemas antes de que afecten a los workloads durante mucho tiempo.
6. Revisa los umbrales de scale-down frente al ahorro real de costos
Un scale-down agresivo puede reducir los costos, pero los workloads con picos de tráfico repentinos pueden escalar y reducirse con demasiada frecuencia. El scale-down-utilization-threshold y los temporizadores de scale-down se pueden ajustar a tus patrones de tráfico reales, en lugar de calibrarse solo para reducir la cantidad de nodos.