Los autoscalers de Kubernetes entran en conflicto por la falta de un plano de control unificado

Cuando los ingenieros de fiabilidad del sitio (SRE) solicitan el tamaño correcto de un servicio como checkout-api, reciben respuestas contradictorias de su propia infraestructura. El Horizontal Pod Autoscaler (HPA) puede exigir once réplicas debido a la carga de CPU, mientras que el Vertical Pod Autoscaler (VPA) afirma que los pods están sobreprovisionados. Simultáneamente, KEDA solicita veinticuatro réplicas para vaciar una cola de Kafka, y Karpenter añade nuevos nodos basándose en solicitudes de recursos infladas. Este caos ocurre porque cinco controladores diferentes actúan lógicamente de forma aislada, pero ninguno posee una visión completa de las necesidades reales del sistema.

Qué ocurrió

Las operaciones modernas de Kubernetes dependen de un conjunto de herramientas especializadas construidas bajo la filosofía Unix: componentes pequeños y modulares que realizan tareas únicas con eficacia. HPA gestiona la elasticidad horizontal, VPA maneja el dimensionamiento vertical, KEDA conecta fuentes de eventos con recuentos de réplicas, y autoscalers de nodos como Karpenter gestionan la capacidad física. Herramientas GitOps como Argo CD imponen estados base desde el control de versiones. En las pipelines tradicionales de Unix, las herramientas procesan datos secuencialmente, pasando salidas inmutables de una etapa a la siguiente. Sin embargo, los autoscalers de Kubernetes operan concurrentemente, modificando los mismos campos de la API, como .spec.replicas y .resources.requests, sin visibilidad sobre las acciones de los demás.

Esta brecha arquitectónica crea una situación donde determinar la capacidad de la carga de trabajo se convierte en un proceso fragmentado. En lugar de resolver una única ecuación matemática acoplada para un rendimiento y coste óptimos, el sistema divide el problema entre controladores desacoplados. Cada controlador asume el control exclusivo sobre su dominio específico, lo que lleva al thrashing (oscilación excesiva) en lugar de a la eficiencia. El resultado es un clúster donde ninguna entidad individual comprende los compromisos entre latencia, coste y capacidad, causando inestabilidad operativa.

Cómo funciona

El conflicto surge porque bucles de control independientes manipulan variables interdependientes, creando cuatro modos de fallo comunes. Primero, HPA y VPA colisionan mediante el colapso del denominador. HPA calcula las réplicas objetivo dividiendo el uso real entre las solicitudes de recursos declaradas. Cuando VPA reduce estas solicitudes para minimizar el desperdicio, el denominador se encoge. Incluso aumentos menores de tráfico empujan entonces los porcentajes de utilización más allá de los umbrales de HPA, desencadenando un escalado agresivo hacia afuera. A medida que más pods comparten la carga, el uso por pod disminuye, lo que induce a VPA a reducir aún más las solicitudes, creando una espiral de muerte de contenedores microscópicos.

Segundo, HPA nativo y KEDA entran en una condición de carrera de múltiples escritores. Si una cola de eventos experimenta un pico, KEDA escala hacia arriba el despliegue para vaciar la acumulación. Sin embargo, si los pods de workers son intensivos en E/S con bajo uso de CPU, HPA observa baja utilización y escala el despliegue hacia abajo. El servidor de API registra eventos alternantes de reescalado mientras el throughput real de procesamiento se estanca. Tercero, los motores GitOps crean un ping-pong de desviaciones (drift). Cuando HPA escala un despliegue durante un pico, las herramientas GitOps marcan la aplicación como fuera de sincronización. Si el auto-sync está habilitado, el sistema restablece el despliegue a su estado base, privando a la aplicación de capacidad durante la demanda máxima.

Finalmente, los autoscalers de nodos amplifican estas ineficiencias. Herramientas como Karpenter aprovisionan instancias físicas basándose estrictamente en las solicitudes de contenedores declaradas, no en el consumo real. Si un contenedor solicita un núcleo de CPU pero usa solo 150 millicores, el planificador reserva el núcleo entero. Esto multiplica los errores de dimensionamiento aguas arriba en facturas masivas de nube, dejando la utilización media de CPU del clúster rondando el ocho por ciento a pesar del pesado aprovisionamiento.

Detalles clave

• Cinco controladores distintos (HPA, VPA, KEDA, Karpenter, GitOps) a menudo proporcionan recomendaciones de dimensionamiento contradictorias para la misma carga de trabajo.
• HPA y VPA entran en conflicto porque VPA reduce las solicitudes de recursos, lo que infla artificialmente el porcentaje de utilización utilizado por HPA.
• KEDA y HPA compiten por escribir en el mismo sub-recurso /scale, causando recuentos de réplicas oscilantes cuando el uso de CPU no coincide con la profundidad de la cola.
• Las herramientas GitOps pueden revertir cambios de escalado dinámico realizados por HPA, restaurando configuraciones base que no pueden manejar las cargas de tráfico actuales.
• Los autoscalers de nodos aprovisionan capacidad basándose en solicitudes declaradas en lugar de uso real, llevando a un sobreaprovisionamiento significativo y baja utilización del clúster.
• Los autoscalers actuales funcionan como reflejos automatizados que carecen de un sistema nervioso central para coordinar sus acciones.

Por qué importa

Para ingenieros de software y equipos de plataforma, estos conflictos se traducen directamente en servicios poco fiables y costes inflados. El thrashing causado por controladores competitivos conduce a picos de latencia durante oleadas de demanda, ya que el escalado reactivo espera a que se superen los umbrales antes de actuar. Esta naturaleza reactiva significa que los nuevos recursos de cómputo se inicializan solo después de que el rendimiento ya ha degradado, violando los objetivos de nivel de servicio (SLO). Además, la incapacidad de GitOps para reflejar con precisión la realidad de producción rompe los principios de infraestructura declarativa, haciendo que los futuros despliegues sean arriesgados y difíciles de auditar.

El impacto financiero es igualmente severo. Debido a que los autoscalers de nodos dependen de solicitudes declaradas que a menudo se inflan para prevenir conflictos entre HPA y VPA, los clústeres funcionan con vastas cantidades de capacidad no utilizada. Los ingenieros pasan tiempo significativo ajustando manualmente umbrales y reconciliando diffs de Git en lugar de enfocarse en el desarrollo de funcionalidades. La falta de un plano de control unificado significa que cada decisión de escalado es una optimización local que puede dañar el estado global del sistema, impidiendo que los equipos logren simultáneamente eficiencia de costes y alta disponibilidad.

Qué puedes hacer

• Audita tu clúster buscando controladores concurrentes que apunten a los mismos recursos, verificando específicamente el uso simultáneo de HPA y VPA en los mismos despliegues.
• Evalúa si las políticas de auto-sync de GitOps están revirtiendo eventos legítimos de escalado, y considera configurar cuidadosamente ignorar diferencias para los recuentos de réplicas.
• Monitorea la proporción de solicitudes de recursos declaradas frente al uso real para identificar dónde los autoscalers de nodos están aprovisionando capacidad excesiva.
• Consolida señales de escalado utilizando exclusivamente autoscaling basado en eventos para cargas de trabajo basadas en colas, deshabilitando HPA basado en CPU para esos servicios específicos.
• Implementa estrategias de escalado predictivo que analicen patrones históricos de consumo para precalentar capacidad antes de que ocurran picos de tráfico.
• Busca soluciones que ofrezcan un plano de control unificado capaz de ingerir múltiples señales y tomar decisiones conjuntas sobre el dimensionamiento horizontal y vertical.