Calcula umbrales del Horizontal Pod Autoscaler (HPA) de Kubernetes, bandas de tolerancia y decisiones de escalado basadas en valores de métricas actuales. Visualiza zonas de scale-up, scale-down y zona muerta para configuración óptima de autoescalado.
También podrías encontrar útiles estas calculadoras
Calcula las réplicas óptimas de pods Kubernetes para tu carga de trabajo
Calcula tamaños óptimos de nodos K8s y configuración del clúster
Calcula límites de tasa, métricas de token bucket y análisis de throttling para APIs
Convierte entre binario, decimal, hex y octal
El Horizontal Pod Autoscaler (HPA) usa umbrales y bandas de tolerancia para determinar cuándo escalar tus cargas de trabajo. Nuestra Calculadora de Umbral de Autoescalado te ayuda a visualizar estas zonas, entender las decisiones de escalado y configurar el comportamiento óptimo de autoescalado para tus deployments de Kubernetes.
Los umbrales de autoescalado definen los límites de métricas que disparan acciones de escalado en Kubernetes HPA. El algoritmo HPA incluye una banda de tolerancia (10% por defecto) alrededor del valor objetivo para prevenir thrashing—escalado constante hacia arriba y abajo debido a fluctuaciones menores de métricas. El umbral de scale-up es el objetivo multiplicado por (1 + tolerancia), mientras que el umbral de scale-down es el objetivo multiplicado por (1 - tolerancia).
Algoritmo de Escalado HPA
réplicasDeseadas = ceil(réplicasActuales × (métricaActual / métricaObjetivo))La banda de tolerancia crea una 'zona muerta' donde no ocurre escalado. Sin configuración de tolerancia apropiada, pequeñas fluctuaciones de métricas causan ciclos constantes de scale-up y scale-down, desperdiciando recursos y potencialmente causando interrupciones del servicio.
Elegir los umbrales correctos equilibra capacidad de respuesta con estabilidad. Valores de tolerancia más bajos hacen que HPA sea más responsivo a cambios de carga pero arriesgan thrashing. Valores más altos proporcionan estabilidad pero pueden retrasar el escalado durante aumentos rápidos de carga.
Las políticas de comportamiento HPA (ventanas de estabilización, políticas de escalado) refinan aún más cuándo y qué tan rápido ocurre el escalado. Scale-up típicamente no tiene retraso de estabilización, mientras que scale-down usa una ventana de 300 segundos por defecto para prevenir reducción prematura.
Entender los umbrales te ayuda a evitar sobre-aprovisionamiento (demasiadas réplicas) y sub-aprovisionamiento (capacidad insuficiente durante picos de carga). La calculadora muestra exactamente qué niveles de utilización disparan decisiones de escalado.
Experimenta con diferentes valores de tolerancia para encontrar el equilibrio correcto entre capacidad de respuesta y estabilidad. Las aplicaciones web a menudo usan 10% de tolerancia, mientras que los servicios en tiempo real pueden necesitar 5% para reacciones más rápidas.
Cuando HPA no escala como se espera, usa la calculadora para verificar que las métricas actuales realmente exceden los umbrales. Muchos problemas de 'HPA no funciona' son simplemente métricas cayendo dentro de la banda de tolerancia.
Antes de eventos de tráfico pico, calcula qué niveles de utilización dispararán scale-up y asegura que tus réplicas máximas puedan manejar la carga esperada. Pre-escala si las métricas podrían no reaccionar lo suficientemente rápido.
Analiza si tu configuración de umbral actual lleva a sobre-aprovisionamiento durante períodos de bajo tráfico. Ajusta los umbrales de scale-down y ventanas de estabilización para reducir costos sin sacrificar disponibilidad.
La banda de tolerancia (10% por defecto) crea una 'zona muerta' alrededor de la métrica objetivo donde no ocurre escalado. Para un objetivo de 70% con 10% de tolerancia, HPA no escalará a menos que las métricas caigan por debajo de 63% (scale-down) o excedan 77% (scale-up). Esto previene thrashing de fluctuaciones menores.
Verifica si la métrica actual está realmente por encima del umbral de scale-up (objetivo × 1.1 por defecto). También verifica que no hayas llegado a maxReplicas, que metrics-server esté funcionando, y que el promedio de métricas en todos los pods esté por encima del umbral—no solo un pod.
La ventana de estabilización previene escalado rápido al observar métricas durante un período de tiempo. Scale-up tiene una ventana predeterminada de 0 (inmediato), mientras que scale-down usa 300 segundos. Esto significa que HPA espera 5 minutos de utilización baja sostenida antes de reducir escala.
Las políticas definen el cambio máximo por período de tiempo. Por ejemplo, 'Porcentaje: 100 por 15s' permite duplicar réplicas cada 15 segundos. 'Pods: 4 por 15s' permite agregar/eliminar 4 pods por período. El selectPolicy (Max/Min) determina qué política usar cuando hay múltiples definidas.
CPU es preferido para cargas basadas en solicitudes porque se correlaciona con la carga. Memoria es mejor para trabajos batch o aplicaciones con sobrecarga significativa de memoria. Para la mayoría de servicios web, CPU al 70% objetivo es un buen punto de partida.
10% (predeterminado) funciona bien para la mayoría de cargas de trabajo. Usa valores más bajos (5%) para servicios sensibles a latencia que necesitan escalado rápido. Usa valores más altos (15-20%) para cargas batch donde la estabilidad importa más que la capacidad de respuesta. Nunca uses 0%—causa thrashing excesivo.