Black Friday: el HPA pasa de cuatro a veinte módulos API: gráfico verde, equipo tranquilo. Sin embargo, el tiempo de espera de pago: PostgreSQL alcanza max_connections, el hilo único de Redis está saturado. Los nuevos pods multiplican las conexiones sin aumentar la capacidad transaccional. El escalado automático es “exitoso” en el lado de Kubernetes, fracaso en el lado empresarial.
El escalado de pods resuelve los cuellos de botella sin estado. A menudo, los cuellos de botella con estado o compartidos empeoran si nadie ha mapeado la cadena completa. Antes de automatizar algo, identifique qué recurso falla primero en el pico (base, corredor, API de terceros, ancho de banda saliente) y quién tiene la autoridad para escalarlo.
HPA: la métrica predeterminada y sus puntos ciegos
El escalador automático de pod horizontal compara una métrica (CPU, memoria, métrica personalizada) con un objetivo y cambia la cantidad de réplicas. Sobre el papel, es sencillo. En producción, la CPU es sólo un proxy imperfecto de la carga real.
| Métrica | Buena señal cuando | Mala señal cuando |
|---|---|---|
| % de CPU | Computación intensiva (renderizado, cifrado) | Esperando disco o base de datos |
| Memoria | Esconderse en la cápsula | Fuga oculta por escala |
| Solicitudes/s o latencia (personalizada) | API sin estado | Saturación aguas arriba |
| Profundidad de cola (KEDA) | Trabajadores asincrónicos | Línea sin consumidores sanos |
Sin metrics-server y un adaptador Prometheus (o equivalente), HPA permanece ciego al negocio. Un pod puede mostrar un veinte por ciento de CPU mientras espera una respuesta de PostgreSQL que ha estado bloqueada durante ocho segundos. La métrica aumenta demasiado tarde, o no aumenta en absoluto.
Agregar pods basándose en el cien por ciento de las conexiones utilizadas solo crea más clientes en espera.
Para alejarse de la CPU predeterminada, exponga señales que reflejen la experiencia del usuario: latencia percentil 95 en /api/checkout, longitud de la cola de Redis, cantidad de mensajes retrasados en RabbitMQ. El HPA solo resulta útil cuando la métrica elegida se correlaciona con los tiempos de espera observados bajo carga.
VPA y cambio de tamaño antes de multiplicar
Vertical Pod Autoscaler recomienda o aplica límites y solicitudes de memoria de CPU. Las solicitudes que son demasiado bajas provocan una aceleración de la CPU y hacen que el HPA escale innecesariamente. Las solicitudes demasiado altas llenan los nodos: los nuevos pods permanecen pendientes, el clúster del escalador automático se activa con urgencia y la factura sigue.
Flujo de trabajo pragmático: primero estabilice las solicitudes (VPA en modo "Desactivado" para recopilar recomendaciones) y luego habilite HPA en las réplicas. En un clúster administrado en Europa, supervise el costo por nodo: un clúster de escalador automático sin alerta de presupuesto convierte un pico de tráfico en una sorpresa a final de mes.
Escalador automático de clústeres y pods pendientes
Cuando HPA crea pods sin espacio en los nodos existentes, permanecen pendientes. El clúster de escalador automático aprovisiona un nodo, con un retraso de varios minutos (descarga de imágenes, inicio, guardado). Durante este tiempo, el tráfico continúa llegando a los módulos existentes, que ya están saturados.
Anticípese con un PodDisruptionBudget para no agotar una implementación crítica durante la reducción de escala de un nodo. Planifique varios grupos de nodos (computación general versus intensiva) si sus cargas son heterogéneas. Establezca un límite máximo de nodos para evitar una factura incontrolada durante un ciclo de escala mal configurado.
##KEDA para trabajadores y archivos
Trabajadores de Symfony Messenger, archivos Laravel, consumidores de Kafka: la señal correcta es retraso o profundidad de la cola, no una CPU al quince por ciento mientras miles de mensajes esperan. KEDA puede escalar desde cero, algo práctico para cargas por lotes, pero tenga cuidado con el arranque en frío, incompatible con un compromiso de disponibilidad en tiempo real.
Documente la topología de los intercambios y archivos antes de automatizar. Un escalador mal conectado en la cola equivocada escala a los trabajadores mientras la cola crítica crece en otros lugares.
Servicios con estado: no escale automáticamente a ciegas
PostgreSQL, Elasticsearch, ciertas implementaciones de Redis: el escalado horizontal no es trivial. A veces, la respuesta es un nodo más grande (cambio de tamaño de la máquina virtual), una réplica de lectura o un caché ascendente, no más pods de API que multipliquen las conexiones.
Mapee la cadena: para mil solicitudes adicionales por segundo, ¿qué recurso se rompe primero? Mida en la prueba de carga antes de automatizar la palanca incorrecta. El escalado automático de Kubernetes no reemplaza la arquitectura de datos bien pensada.
La cumbre: el gráfico que tranquiliza falsamente
La pregunta correcta no es “¿cuántas vainas?” » pero “¿qué recurso es el primero en llegar al pico y quién lo escala?”
Decide y avanza sin puntos ciegos
Comience con una prueba de carga con métricas por capa: aplicación, base, broker, red. Elija el escalador apropiado (HPA, KEDA, escalador automático de clúster) en la señal que se correlacione con los tiempos de espera del usuario, no en la métrica más fácil de representar gráficamente. Establezca réplicas máximas, presupuestos de interrupción y alertas de latencia del percentil 95.
Compare clústeres administrados y grupos de nodos a través del directorio y la comparación. Las guías completan el marco de la arquitectura de la nube. Validar bajo carga: si la latencia en el percentil 95 permanece estable cuando aumentan las réplicas, el cuello de botella está en otra parte, y ahí es donde hay que invertir.
Preguntas frecuentes
¿HPA en CPU es suficiente en producción?
Rara vez solo. Una CPU estable puede ocultar una cola de Redis en crecimiento o una base de datos con conexiones agotadas. Combine métricas de aplicaciones (retardo de cola, solicitudes por segundo, latencia percentil 95) a través del adaptador Prometheus o KEDA para escalar lo que se correlaciona con los tiempos de espera de los usuarios.
¿Cuál es la diferencia entre HPA, VPA y clúster de escalador automático?
El HPA ajusta el número de réplicas de pods según una métrica objetivo. El VPA recomienda o impone solicitudes y límites de memoria de CPU. El clúster de escalador automático agrega nodos cuando los pods permanecen pendientes debido a la falta de recursos en el clúster existente.
¿Qué aporta KEDA en comparación con el HPA clásico?
KEDA ofrece escaladores basados en la profundidad del archivo, activadores cron y métricas externas. Para los trabajadores asincrónicos, estas señales suelen ser más expresivas que una CPU promedio baja mientras miles de mensajes esperan.
¿Cómo evitar los aleteos?
Configure stabilizationWindowSeconds, umbrales con histéresis, un retraso de enfriamiento entre dos eventos de escala y un mínimo realista de réplicas. Sin estas barreras, el HPA oscila y desestabiliza las conexiones persistentes.
El escalado automático maduro escala el recurso que le está fallando al usuario, no el que ya está en Grafana.