Autoscaling más inteligente en GKE: métricas personalizadas más allá de CPU y memoria

El autoscaling en Kubernetes suele apoyarse en el Horizontal Pod Autoscaler (HPA). Por defecto, el HPA escala los workloads en función del uso de recursos como CPU o memoria. Si bien esto funciona bien en muchos casos, no siempre refleja la demanda real que recibe una aplicación.

Por ejemplo:

• Una API web puede recibir un alto volumen de solicitudes sin que el uso de CPU sea elevado.
• Un servicio que procesa una cola puede necesitar más workers cuando crece el backlog.
• Los workloads de inferencia de IA pueden depender más del uso de GPU que del de CPU.
• Los servicios de streaming pueden necesitar escalar según las solicitudes por segundo.

Estos escenarios requieren escalar a partir de métricas a nivel de aplicación, no de métricas de infraestructura.

Kubernetes admite el autoscaling basado en métricas personalizadas, pero históricamente implementarlo requería componentes adicionales como:

• Adaptadores de Prometheus: un deployment aparte que conecta las métricas de Prometheus con la API de métricas de Kubernetes
• Pipelines de métricas personalizadas: capas de ingesta, almacenamiento y consulta entre tu aplicación y el HPA
• Configuración compleja de IAM y service accounts, sobre todo en entornos administrados como GKE

Fuente: Gemini Nano Banana Pro

La carga operativa de estos componentes era alta: los equipos tenían que gestionar la compatibilidad de los adaptadores entre versiones de Kubernetes, depurar pipelines de métricas con múltiples saltos y lidiar con la latencia de las capas de infraestructura. Toda esa fricción frenaba la adopción y hacía que muchos equipos terminaran volviendo al escalado por CPU.

GKE ahora ofrece una integración nativa para exponer métricas personalizadas y simplifica la forma en que las aplicaciones comparten métricas con el sistema de autoscaling. En lugar de enrutar las métricas a través de adaptadores externos y sistemas de monitoreo, ahora se recopilan directamente desde los pods y se envían al HPA.

Así, el sistema de autoscaling puede reaccionar al comportamiento real de la aplicación, como el throughput de solicitudes o el uso de recursos. Esto simplifica de forma notable el proceso de incorporar métricas de aplicación a las estrategias de escalado.

Fuente: Gemini Nano Banana Pro

La nueva capacidad funciona a través de un recurso llamado AutoscalingMetric.

Este recurso define:

• Qué pods exponen las métricas (mediante selectores de etiquetas)
• Dónde se encuentra el endpoint de las métricas (puerto y ruta)
• Qué métrica específica debe recopilarse
• Cómo debe exportarse la métrica al sistema de autoscaling

Una vez definido, GKE recopila estas métricas y las pone a disposición de componentes como el load balancer o el autoscaler.

Algunos requisitos clave:

• Las métricas deben estar disponibles a través de un endpoint HTTP
• El formato debe seguir los estándares de Prometheus
• Solo se admiten métricas de tipo gauge.
• Se puede exponer un máximo de 20 métricas únicas por cluster.

Gauge vs. otros tipos de métricas: un gauge representa un valor que puede subir o bajar en cualquier momento (por ejemplo, largo actual de la cola = 45). Los counters solo aumentan (por ejemplo, total de solicitudes procesadas = 10.432) y no sirven como objetivos directos de autoscaling. Si tu aplicación hoy expone counters, vas a tener que derivar un gauge (por ejemplo, una tasa de solicitudes derivada) antes de usarlo con esta funcionalidad.

Una vez registrada la métrica, GKE la lee de forma continua y alimenta su valor en la lógica de escalado.

Veamos un ejemplo completo y autocontenido.

Escenario: un servicio worker en segundo plano procesa trabajos desde una cola. Queremos escalar la cantidad de pods worker en función del largo actual de la cola, no del uso de CPU.

Paso 1: exponer la métrica desde la aplicación

Despliega tu aplicación de modo que exponga una métrica gauge en formato Prometheus en su endpoint /metrics:

# HELP job_queue_length Current number of jobs waiting in the queue
# TYPE job_queue_length gauge
job_queue_length 45

Supongamos que las métricas están disponibles en http://worker-service:9090/metrics

Paso 2: crear un recurso AutoscalingMetric

Define un recurso AutoscalingMetric que le indique a GKE dónde encontrar la métrica y cómo exportarla:

apiVersion: autoscaling.gke.io/v1beta1
kind: AutoscalingMetric
metadata:
  name: worker-queue-metric
  namespace: default
spec:
  selector:
    matchLabels:
      app: job-worker #The label name and value matching the Pods
  endpoints:
  - port: 9090 #The metrics port number
    path: /metrics #The path to the metric
    metrics:
    - gauge:
      name: job_queue_length #The name of the metric that you are exposing.
      prometheusMetricName: job_queue_length #optional: The Prometheus metric name as exposed by the Pod.

Una vez aplicado, la métrica queda disponible para el sistema de autoscaling.

Ahora creamos un HPA que utiliza la métrica personalizada.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: worker-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: job-worker
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Pods
    pods:
      metric:
        name: autoscaling.gke.io|worker-queue-metric|queue_utilization
      target:
        type: AverageValue
        averageValue: 20

Esta configuración implica que:

• Si el tamaño promedio de la cola supera los 20 trabajos por pod, el sistema escala hacia arriba.
• Si la cola se reduce, el sistema escala hacia abajo.

Esta funcionalidad ofrece varias ventajas clave.

• Escalado consciente de la aplicación: las decisiones de escalado reflejan la demanda real, no proxies de infraestructura.
• Menor complejidad operativa: no se necesitan adaptadores externos ni pipelines de métricas complicados.
• Mejor rendimiento: las aplicaciones escalan con más precisión y responden más rápido a los picos de carga.
• Mejor uso de recursos: los costos de infraestructura bajan porque el escalado se alinea con la demanda real.
• Estrategias de autoscaling flexibles: los equipos pueden diseñar políticas en torno a cualquier métrica gauge que exponga su aplicación, como el largo de la cola, las sesiones activas, los renders pendientes y más.