Guía Práctica para el Ajuste del Escalador Automático Horizontal de Pods (HPA) de Kubernetes

El Escalador Automático Horizontal de Pods (HPA) de Kubernetes puede mantener tu aplicación receptiva durante picos de tráfico, pero solo si las métricas y los límites reflejan cómo se comporta la aplicación. Un HPA mal ajustado puede escalar demasiado tarde, reducir la escala demasiado rápido o nunca escalar porque faltan solicitudes de recursos.

Esta guía te muestra cómo ajustar el HPA de Kubernetes con CPU, memoria, métricas personalizadas, métricas externas y controles de comportamiento de escalado.

Comprendiendo el Escalador Automático Horizontal de Pods (HPA)

El HPA escala automáticamente el número de pods en tu aplicación hacia arriba o hacia abajo para igualar la demanda actual. Monitorea continuamente métricas especificadas y las compara con valores objetivo. Si la métrica observada supera el objetivo, HPA inicia un evento de escalado hacia arriba; si cae por debajo, desencadena un escalado hacia abajo. Este ajuste dinámico asegura que tu aplicación tenga suficientes recursos para rendir de manera óptima sin sobreaprovisionar.

El HPA puede escalar basándose en:

Métricas de Recursos: Principalmente utilización de CPU y memoria (disponibles a través de la API metrics.k8s.io, generalmente servida por el Servidor de Métricas de Kubernetes).
Métricas Personalizadas: Métricas específicas de la aplicación expuestas a través de la API custom.metrics.k8s.io (por ejemplo, solicitudes por segundo, profundidad de cola, conexiones activas). Estas generalmente requieren un adaptador como prometheus-adapter.
Métricas Externas: Métricas provenientes de fuentes fuera del clúster expuestas a través de la API external.metrics.k8s.io (por ejemplo, tamaño de cola de Google Cloud Pub/Sub, longitud de cola de AWS SQS). Estas también requieren un servidor de API de métricas personalizadas capaz de obtener métricas externas.

Prerrequisitos para un Ajuste Efectivo del HPA

Antes de sumergirte en las configuraciones del HPA, asegúrate de que estos elementos fundamentales estén en su lugar:

1. Definir Solicitudes y Límites de Recursos Precisos

Este es quizás el prerrequisito más crucial. El HPA depende en gran medida de las solicitudes de CPU y memoria correctamente definidas para calcular los porcentajes de utilización. Si un pod no tiene solicitudes de CPU definidas, el HPA no puede calcular su utilización de CPU, haciendo imposible el escalado basado en CPU.

Solicitudes: Define los recursos mínimos garantizados para tus contenedores. El HPA usa estos valores para determinar la utilización objetivo por pod.
Límites: Define los recursos máximos que un contenedor puede consumir. Los límites evitan que un solo pod consuma recursos excesivos e impacte a otros pods en el mismo nodo.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-container
        image: my-image:latest
        resources:
          requests:
            cpu: "200m"  # 20% de un núcleo de CPU
            memory: "256Mi"
          limits:
            cpu: "500m"
            memory: "512Mi"

2. Instalar el Servidor de Métricas de Kubernetes

Para que el HPA use métricas de utilización de CPU y memoria, el Servidor de Métricas de Kubernetes debe estar instalado en tu clúster. Recopila métricas de recursos de los Kubelets y las expone a través de la API metrics.k8s.io.

3. Observabilidad de la Aplicación

Para métricas personalizadas o externas, tu aplicación debe exponer métricas relevantes (por ejemplo, a través de un endpoint de Prometheus) y necesitarás una forma de recopilar y exponer estas métricas a la API de Kubernetes, generalmente usando un adaptador de Prometheus o un servidor de API de métricas personalizadas.

Configurando el HPA: Parámetros Principales

Veamos la estructura básica de un manifiesto de HPA:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

Parámetros clave:

scaleTargetRef: Define el recurso objetivo (por ejemplo, Deployment) que el HPA escalará. Especifica su apiVersion, kind y name.
minReplicas: El número mínimo de pods al que el HPA reducirá la escala. Es una buena práctica establecer esto al menos en 1 o 2 para alta disponibilidad, incluso bajo carga cero.
maxReplicas: El número máximo de pods al que el HPA aumentará la escala. Actúa como un salvaguarda contra el escalado descontrolado y limita el costo.
metrics: Un array que define las métricas que el HPA debe monitorear.
- type: Puede ser Resource, Pods, Object o External.
- resource.name: Para el tipo Resource, especifica cpu o memory.
- target.type: Para el tipo Resource, Utilization (porcentaje del recurso solicitado) o AverageValue (valor absoluto).
- averageUtilization: Para el tipo Utilization, el porcentaje objetivo. El HPA calcula el número deseado de pods basado en utilización_actual / utilización_objetivo * conteo_actual_de_pods.

Ajustando el HPA para Capacidad de Respuesta y Estabilidad

Más allá de la configuración básica, el HPA ofrece opciones de ajuste avanzadas, especialmente con autoscaling/v2 (o v2beta2 en versiones anteriores), para gestionar el comportamiento de escalado de manera más granular.

1. Objetivos de CPU y Memoria (`averageUtilization` / `averageValue`)

Establecer la utilización objetivo correcta es crucial. Un objetivo más bajo significa un escalado más temprano (más receptivo, potencialmente más costoso), mientras que un objetivo más alto significa un escalado más tardío (menos receptivo, potencialmente más barato pero con riesgo de degradación del rendimiento).

Cómo Determinar Objetivos Óptimos: Las pruebas de carga y la creación de perfiles son tus mejores aliados. Aumenta gradualmente la carga en tu aplicación mientras monitoreas el uso de recursos y las métricas de rendimiento (latencia, tasas de error). Identifica la utilización de CPU/memoria en la que tu aplicación comienza a degradar el rendimiento. Establece tu objetivo de HPA por debajo de este umbral, típicamente en el rango del 60-80% para CPU.
Acto de Equilibrio: Apunta a un objetivo que deje suficiente margen para picos inesperados pero que no sea tan bajo como para estar constantemente sobreaprovisionado.

2. Comportamiento de Escalado (campo `behavior`)

Introducido en HPA autoscaling/v2, el campo behavior proporciona un control detallado sobre los eventos de escalado hacia arriba y hacia abajo, evitando "thrashing" (ciclos rápidos de escalado hacia arriba y hacia abajo).

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 60 # Esperar 60s antes de escalar hacia arriba nuevamente
      policies:
      - type: Pods
        value: 4
        periodSeconds: 15 # Agregar máximo 4 pods cada 15 segundos
      - type: Percent
        value: 100
        periodSeconds: 15 # O duplicar los pods actuales cada 15 segundos (lo que sea menos restrictivo)
    scaleDown:
      stabilizationWindowSeconds: 300 # Esperar 5 minutos antes de escalar hacia abajo
      policies:
      - type: Percent
        value: 50
        periodSeconds: 60 # Eliminar máximo el 50% de los pods cada 60 segundos
      selectPolicy: Max # Elegir la política que permita el cambio de escalado hacia abajo más grande permitido

Configuración de `scaleUp`:

stabilizationWindowSeconds: Suaviza las recomendaciones de escalado durante una ventana de tiempo reciente. El escalado hacia arriba generalmente usa una ventana corta para que la aplicación pueda reaccionar rápidamente.
policies: Define cómo se agregan los pods durante un evento de escalado hacia arriba. Puedes definir múltiples políticas, y el HPA usará la que permita el mayor número de pods (escalado hacia arriba más agresivo).
- type: Pods: Escala hacia arriba por un número fijo de pods. value especifica el número de pods a agregar. periodSeconds define la ventana de tiempo durante la cual se aplica esta política.
- type: Percent: Escala hacia arriba por un porcentaje del conteo actual de pods. value es el porcentaje.

Configuración de `scaleDown`:

stabilizationWindowSeconds: Más crítico para scaleDown, esto especifica cuánto tiempo debe observar el HPA métricas por debajo del objetivo antes de considerar escalar hacia abajo. Una ventana más larga (por ejemplo, 300-600 segundos) previene el escalado hacia abajo prematuro durante pausas temporales, evitando "arranques en frío" y caídas de rendimiento. Esta es una configuración crucial para entornos estables.
policies: Similar a scaleUp, define cómo se eliminan los pods. El HPA usa la política que resulta en el menor número de pods (escalado hacia abajo más agresivo) si selectPolicy es Min, o la política que resulta en el mayor número de pods si selectPolicy es Max.
- type: Pods: Elimina un número fijo de pods.
- type: Percent: Elimina un porcentaje de los pods actuales.
selectPolicy: Determina qué política aplicar cuando se definen múltiples políticas de scaleDown. Max es el valor predeterminado y selecciona la política que permite el cambio de escala más grande. Usa Min cuando quieras un escalado hacia abajo más conservador.
Advertencia: Ten cuidado con políticas agresivas de scaleDown o stabilizationWindowSeconds cortos para scaleDown. Si tu aplicación tiene tiempos de inicialización largos o maneja conexiones con estado, el escalado hacia abajo rápido puede llevar a interrupciones del servicio o mayor latencia para los usuarios.

Métricas y Estrategias Avanzadas de HPA

Si bien la CPU y la memoria son comunes, muchas aplicaciones escalan mejor con métricas personalizadas o externas que reflejen su carga de trabajo real.

1. Métricas Personalizadas

Usa métricas personalizadas cuando la CPU/memoria no sea un indicador directo de la carga de tu aplicación o del cuello de botella de rendimiento. Ejemplos: solicitudes HTTP por segundo (QPS), conexiones activas, longitud de cola de mensajes, acumulación de trabajos por lotes.

Para usar métricas personalizadas:

Tu aplicación debe exponer estas métricas (por ejemplo, a través de un exportador de Prometheus).
Implementa un adaptador de métricas personalizadas (por ejemplo, prometheus-adapter) que pueda recopilar estas métricas y exponerlas a través de la API custom.metrics.k8s.io.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa-qps
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 2
  maxReplicas: 15
  metrics:
  - type: Pods # O Object si la métrica es para el deployment en su conjunto
    pods:
      metric:
        name: http_requests_per_second # El nombre de la métrica expuesta por tu aplicación/adaptador
      target:
        type: AverageValue
        averageValue: "10k" # Objetivo de 10,000 solicitudes por segundo por pod

2. Métricas Externas

Las métricas externas son útiles cuando la carga de trabajo de tu aplicación es impulsada por un sistema externo que no se ejecuta directamente en Kubernetes. Ejemplos: profundidad de cola de AWS SQS, retraso de tema de Kafka, acumulación de suscripciones de Pub/Sub.

Para usar métricas externas:

Necesitas un servidor de API de métricas personalizadas que pueda obtener métricas de tu sistema externo (por ejemplo, un adaptador específico para AWS CloudWatch o GCP Monitoring).

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-worker-hpa-sqs
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-worker
  minReplicas: 1
  maxReplicas: 20
  metrics:
  - type: External
    external:
      metric:
        name: aws_sqs_queue_messages_visible # Nombre de la métrica de tu fuente externa
        selector:
          matchLabels:
            queue: my-queue-name
      target:
        type: AverageValue
        averageValue: "100" # Objetivo de 100 mensajes visibles en la cola por pod

3. Múltiples Métricas

El HPA puede configurarse para monitorear múltiples métricas simultáneamente. Cuando se especifican múltiples métricas, el HPA calcula el número deseado de réplicas para cada métrica de forma independiente y luego selecciona el mayor de estos números deseados de réplicas. Esto asegura que la aplicación escale suficientemente para todas las dimensiones de carga observadas.

# ... (código repetitivo del HPA)
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Pods
    pods:
      metric:
        name: http_requests_per_second
      target:
        type: AverageValue
        averageValue: "10k"

Monitoreo y Validación

El ajuste efectivo del HPA es un proceso iterativo que requiere monitoreo y validación continuos:

Observa los Eventos del HPA: Usa kubectl describe hpa <nombre-del-hpa> para ver el estado, eventos y decisiones de escalado del HPA. Esto proporciona información valiosa sobre por qué el HPA escaló hacia arriba o hacia abajo.
Monitorea Métricas y Réplicas: Usa tu pila de observabilidad (por ejemplo, Prometheus, Grafana) para visualizar el uso de recursos de tu aplicación (CPU, memoria), métricas personalizadas/externas y el número real de réplicas de pods a lo largo del tiempo. Correlaciona estos con cambios en la carga entrante.
Pruebas de Carga: Simula cargas esperadas y pico para validar la capacidad de respuesta del HPA y asegurarte de que tu aplicación rinda como se espera bajo estrés. Ajusta los parámetros del HPA basándote en estas pruebas.

Mejores Prácticas para el Ajuste del HPA

Comienza con Solicitudes/Límites de Recursos Bien Definidos: Son la base de un HPA preciso basado en recursos. Sin ellos, el HPA no puede funcionar efectivamente para CPU/memoria.
Establece minReplicas y maxReplicas Realistas: minReplicas proporciona una línea base para la disponibilidad, mientras que maxReplicas actúa como una red de seguridad contra costos descontrolados y agotamiento de recursos.
Ajusta Gradualmente la Utilización Objetivo: Comienza con un objetivo de CPU ligeramente conservador (por ejemplo, 60-70%) e itera. No apuntes al 100% de utilización, ya que no deja margen para picos de latencia o procesamiento.
Aprovecha stabilizationWindowSeconds: Esencial para prevenir oscilaciones rápidas de escalado. Usa una ventana más larga para scaleDown (por ejemplo, 5-10 minutos) que para scaleUp (por ejemplo, 1-2 minutos) para asegurar estabilidad.
Prioriza Métricas Específicas de la Aplicación: Si la CPU o la memoria no se correlacionan directamente con los cuellos de botella de rendimiento de tu aplicación, usa métricas personalizadas o externas para un escalado más preciso y eficiente.
Monitorea, Prueba, Itera: El ajuste del HPA no es una configuración única. El comportamiento de la aplicación, los patrones de tráfico y la infraestructura subyacente pueden cambiar. Revisa regularmente el rendimiento del HPA y ajusta la configuración según sea necesario.
Comprende las Características de Escalado de tu Aplicación: ¿Escala linealmente con las solicitudes? ¿Tiene tiempos de inicio largos? ¿Tiene estado? Estas características influyen en tu estrategia de HPA.

Conclusión Final

Trata el ajuste del HPA como un bucle de retroalimentación. Comienza con solicitudes de recursos precisas, establece minReplicas y maxReplicas realistas, elige una métrica que rastree la demanda real y valida el comportamiento de escalado hacia arriba y hacia abajo con pruebas de carga antes de que el tráfico de producción dependa de ello.