En un entorno Kubernetes moderno, la pregunta sobre el tamaño adecuado para una aplicación y cuántas réplicas debería ejecutar en un momento dado no tiene una respuesta sencilla. Por ejemplo, un equipo puede definir en Helm 3 réplicas con 1000m de CPU y 2Gi de memoria, pero en tiempo real el clúster muestra múltiples escalados simultáneos que empeoran la coherencia. El Horizontal Pod Autoscaler (HPA) puede aumentar el despliegue hasta 11 réplicas basándose en la carga de CPU, mientras que el Vertical Pod Autoscaler (VPA) recomienda reducir la CPU a 350m y aumentar memoria a 3.1Gi, y KEDA puede exigir 24 réplicas por retrasos en la cola de Kafka. A su vez, un autoscalador de nodos como Karpenter provisiona nodos basándose exclusivamente en las solicitudes declaradas, sin tener en cuenta el uso real.
Esta disparidad genera cinco respuestas contradictorias que reflejan un fallo arquitectónico: cada controlador funciona de forma lógica e independiente, pero ninguno posee la visión global necesaria para una gestión óptima.
La pérdida de coherencia del paradigma Unix en sistemas elásticos
Kubernetes y sus componentes se desarrollaron siguiendo la filosofía Unix, que propone construir herramientas pequeñas y modulares especializadas en una única tarea. Así, el HPA se encarga de la elasticidad horizontal basada en la carga de CPU, el VPA ajusta el tamaño vertical según consumo histórico, KEDA adapta la cantidad de réplicas en función de eventos externos como las colas de mensajes, mientras que Karpenter y Cluster Autoscaler gestionan la capacidad de nodos. Finalmente, herramientas GitOps, como Argo CD o Flux, mantienen el estado deseado del clúster mediante control de versiones. 
El problema surge porque estas herramientas operan de forma simultánea, afectando las mismas propiedades del despliegue, como el número de réplicas y las solicitudes de recursos, sin coordinación entre ellas. Cada autoscalador se ejecuta en un ciclo de reconciliación independiente y considera que tiene control exclusivo, lo que frena una gestión conjunta y coherente de la capacidad.
Los principales conflictos entre autoscaladores
La interacción entre diversas fuentes de control genera cuatro mecanismos de fallo recurrentes:
1. Colapso del denominador: conflicto entre HPA y VPA
El HPA determina cuántas réplicas ejecutar midiendo el porcentaje de utilización de CPU en relación con las solicitudes declaradas. Cuando el VPA reduce dichas solicitudes para evitar sobreaprovisionamiento, el denominador se hace más pequeño. Por tanto, un pequeño aumento en la carga hace que el HPA escale agresivamente el número de réplicas. Más pods presentes reducen la carga media, induciendo al VPA a disminuir aún más recursos declarados. Se genera un ciclo vicioso donde el VPA achica los pods y el HPA los multiplica indefinidamente.
2. Condición de carrera entre HPA y KEDA
El HPA ajusta la escala en función del uso de CPU, mientras que KEDA responde a eventos externos como picos en las colas de mensajes. Cuando ambos operan sobre el mismo recurso, KEDA puede incrementar las réplicas para procesar la cola, pero si esos pods tienen bajo uso de CPU, el HPA los reduce. El resultado es una carrera de escalados que confunde a la API de Kubernetes y puede bloquear el procesamiento real.
3. Ping-pong entre GitOps y autoscalado dinámico
GitOps asume que el repositorio Git es la fuente única de la verdad. Cuando el HPA escala un despliegue por aumento de tráfico, Argo CD puede marcar el estado como «OutOfSync» y, si está configurado para auto-sincronizar, revertir estos cambios. Esto elimina la capacidad extra y genera riesgos de que el estado en Git no refleje el estado real de producción, afectando futuros despliegues.
4. Efecto multiplicador a nivel de nodos
Automatizaciones como las de Karpenter crean nodos nuevos basándose en solicitudes de recursos declaradas, no en el uso real. Si un contenedor solicita 1000m de CPU pero solo consume 150m, el planificador reserva la capacidad completa, lo que produce una enorme infrautilización y costes excesivos en la nube, con tasas de utilización promedio del 8%.
Hacia un autoscalador unificado y autónomo
Los autoscaladores actuales responden a preguntas muy específicas: «¿Cuál debe ser mi configuración individual?». Pero la verdadera cuestión es holística: «¿Qué combinación de réplica, solicitudes y límites satisface los acuerdos de nivel de servicio (SLO) al menor coste y cuándo debe cambiar?»
El escalado horizontal y vertical son variables interdependientes de un mismo problema de optimización. Por eso, un sistema eficaz debe integrar cinco capacidades clave:
- Ingesta unificada de señales: Analizar simultáneamente métricas de CPU/memoria, profundidad de colas, tasa de transacciones, cumplimiento de SLO, coste de nodos y estado en IaC.
- Decisiones conjuntas: Calcular un vector de acción única que sincronice cambios horizontales y verticales en lugar de delegarlos a herramientas independientes.
- Sincronización continua con GitOps: Generar pull requests automatizados y coherentes para mantener el repositorio actualizado con el estado real del clúster, evitando divergencias.
- Planificación predictiva y proactiva: Incorporar algoritmos que pronostiquen demanda según patrones históricos para dimensionar recursos antes de que lleguen picos de tráfico, eliminando respuestas reactivas tardías.
- Auditoría transparente: Ofrecer un registro claro y explicable que permita a los equipos entender las decisiones tomadas y el balance entre costes, rendimiento y SLOs.
De la automatización reactiva a la autonomía real
Actualmente, los autoscaladores actúan como reflejos automatizados, predefinidos para responder a señales aisladas sin coordinación centralizada. Esto genera conflictos y comportamientos erráticos cuando varias respuestas se disparan a la vez. La autonomía exige un sistema de control cerrado que perciba el entorno completo, comprenda las compensaciones y asuma responsabilidad integral por los resultados.
La filosofía Unix sigue siendo válida para la capa de ejecución: cada autoscalador debe mantener su función específica. Pero Kubernetes necesita una capa superior de inteligencia central que oriente estas acciones de forma coordinada y global.
Para los equipos de plataforma, la clave no es decidir entre HPA o VPA, sino determinar quién tiene la visión completa para decidir el tamaño óptimo de las cargas de trabajo y cómo mantener esa coherencia.
En los clústeres actuales, nadie posee esa perspectiva unificada. Resolver la correcta dimensionamiento en Kubernetes requiere construir un sistema que finalmente la tenga.
